简介本资源是一份面向机器人、自动驾驶与无人机领域研发工程师及高校研究者的高精度LiDAR-SLAM系统集成实战指南聚焦Mid-360激光雷达在Ubuntu 18.04平台上的完整部署链路从Livox SDK2驱动安装、Livox-ROS-Driver2数据接入到FAST-LIO2紧耦合定位算法的编译配置与实时建图测试。资源以单个HTML文档形式呈现共1个文件21KB内容结构清晰覆盖环境依赖、源码编译、参数适配、话题发布验证及FAST-LIO2运行调试等关键环节尤其包含Mid-360点云格式适配、IMU时间同步、rviz可视化配置等易错细节的排错思路与实测参数。目前已有873人学习下载适合具备ROS基础和C编译经验的中高级开发者快速落地LiDAR惯性里程计方案。 第一次拿到Mid-360的时候我第一反应是这雷达怎么这么小。机身比巴掌还小一圈但配上FAST-LIO2跑起来的建图效果完全不像这个体积该有的表现。后来陆陆续续给好几台巡检车和AGV都配了这套组合到现在已经算是我装机清单里的默认项了。在开始之前先明确一下这篇内容能帮你解决什么问题从零开始在一台x86工控机上搭好mid360的驱动链路把点云数据接进FAST-LIO2完成实时建图并输出里程计。适合正在做移动机器人、无人机、室外测绘以及刚入坑SLAM的研究生和工程师参考。涉及的主要组件是Livox-SDK2、Livox-ros-driver2、FAST-LIO2都是目前官方和社区用得最广的版本不是那些被改到面目全非的魔改分支。1. 项目概述与方案选型思路1.1 mid360为什么值得选先说说选择mid360的原因。它是一颗非重复扫描的固态激光雷达垂直视场角是-7°到29°视场覆盖比绝大多数机械式单线雷达要大得多。虽然单帧点数不算多但它有个特性——随着时间积分视场内的覆盖密度会显著增加这一点对特征提取非常友好。FAST-LIO2在做特征匹配时用到的surface和edge特征对时间积累后的点云密度要求其实不算高这就让非重复扫描紧耦合LIO成了天然搭配。另一个关键点是它内置了一颗IMU。FAST-LIO2需要IMU做运动补偿和状态预测mid360内置IMU直接省去了外接IMU的安装和同步问题。实测下来内置IMU的零偏稳定性和噪声水平虽然比不上专门的高端IMU但对建图里程计来说是够用的前提是别在剧烈振动环境下指望它输出高精度姿态。1.2 为什么是FAST-LIO2FAST-LIO2的定位很明确紧耦合LiDAR-惯性里程计。它不是单纯的LOAM那种先后端优化路线而是把点云配准和IMU状态估计塞进同一个迭代ESEKF框架里。好处是在快速旋转、剧烈运动这些场景下有IMU的前向预测做支撑点云配准不容易丢。而且这套代码对平台要求不高我试过在Jetson Orin NX、i5-8250U这类低功耗CPU上也能跑到10Hz以上的实时帧率。另外它的外参模块做得比较友好mid360的安装方式变动之后只需要改配置里的R和T不需要改代码。对快速验证方案的人来说这能省下大量时间。1.3 整体架构整条数据链路是这样的mid360通过以太网将点云和IMU数据发给主机主机上运行Livox-SDK2和Livox-ros-driver2把UDP数据流转换成ROS的PointCloud2和Imu消息再交给FAST-LIO2做紧耦合状态估计与建图最终输出/Odometry和/cloud_registered。这里要特别注意Livox-SDK2对应的是driver2它俩是一套新架构和很多老教程里写的livox_ros_driver对应SDK1不是同一个东西。mid360虽然也能在老driver下工作但功能没有新架构完整部署时果断选SDK2driver2才是正路。2. 硬件准备与基础环境2.1 硬件清单一套可以稳定运行的方案硬件其实不用很豪华。我用过的最低配组合是mid360雷达本体含原装网线一台x86工控机或普通笔记本Ubuntu 20.04 ROS1 Noetic千兆交换机或雷达直连主机网口12V供电适配器有的开发板上还建议单独配隔离电源雷达自带的网线说实话有点短现场布局紧的话建议提前备一根质量好一点的六类网线传输距离控制在100米以内这基本是跑以太网雷达的常识但总有人栽在这上面。2.2 网络与IP配置mid360出厂静态IP是192.168.1.50这一点非常关键。我见过太多人的雷达不开机其实是本机IP没配对。你需要把主机的网口配置成192.168.1.x网段比如192.168.1.102掩码255.255.255.0不需要设网关。直连或走交换机都行。配置完可以用一条命令确认链路ping 192.168.1.50 -c 3如果ping不通先检查网线、网口再看防火墙。Ubuntu上偶尔需要关闭ufwsudo ufw disable另外雷达的UDP数据包使用2368号端口主机端不需要主动开端口但网卡如果启用了泛洪过滤偶尔会丢包。这个地方先留意后面第7节还会专门讲丢包怎么排查。2.3 系统与依赖安装雷达驱动和FAST-LIO2都依赖ROS建议直接用Ubuntu 20.04 ROS1 Noetic这是目前社区兼容性最好的组合。如果你用18.04 Melodic也没问题但很多三方依赖编译时会遇到麻烦。系统基础依赖按顺序装sudo apt update sudo apt install git cmake build-essential \ libeigen3-dev libpcl-dev ros-noetic-pcl-ros \ ros-noetic-cv-bridge ros-noetic-image-transportEigen和PCL是FAST-LIO2的硬性依赖缺了编译必炸。Sophus在FAST-LIO2的仓库里以submodule形式带了一份后面编译时会提到不需要自己额外装。这里多提一句装依赖的时候别图省事一次装一堆容易把ROS的python依赖搞乱我遇到过一次装ros-noetic-desktop-full后和自定义的python包冲突的情况教训就是基础环境越干净越好。3. Livox-SDK2与Livox-ros-driver2编译部署3.1 源码准备与版本匹配这里我给一个明确的建议直接从Livox官方GitHub拉取仓库别用第三方打包的版本。git clone https://github.com/Livox-SDK/Livox-SDK2.git git clone https://github.com/Livox-SDK/Livox-ros-driver2.git由于网络原因如果拉取超时可以改用仓库在Gitee上的同步镜像或者直接在网页端下载zip包再解压。但版本要盯住SDK2和driver2要配套别一个用release一个用latest遇到API不匹配大概率是版本错位。两个仓库克隆下来之后先确认一下目录结构。driver2里有ros1和ros2两个子目录我们用的是ROS1编译时进入ros1目录下的package即可。很多人不看README直接编译结果在ROS2目录里编译报一堆错白白浪费时间。3.2 编译SDK2SDK2的编译很简单cd Livox-SDK2 mkdir build cd build cmake .. make -j4 sudo make install编译过程中如果报缺少依赖最常见的是没有安装cmake或者没有curl库sudo apt install libcurl4-openssl-dev装完再重新编译一次。SDK2装到系统之后后续driver2编译时才能找到它。SDK2相比SDK1的主要变化是网络通信层和点云格式处理做了重构对mid360这类新雷达支持更稳定所以不要想着用老SDK1硬凑。3.3 编译ros-driver2把driver2放进你的ROS工作空间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如果你习惯catkin build也可以但要注意driver2的package里有个支持ROS2的目录结构用catkin build会比catkin_make更干净一些。编译结束后记得sourcesource ~/catkin_ws/devel/setup.bash编译通过后先不急着启动去config目录下看看配置文件。3.4 配置driver参数driver2的配置文件在src/livox_ros_driver2/config/默认叫livox_lidar_config.json。一块雷达最小化配置长这样{ lidar_configs: [ { broadcast_code: 000000000000001, enable_connect: true, lidar_ip: , cmd_port: 56000, msg_port: 56000, pcl_data_type: 1, frame_id: livox_frame, lidar_net_info: 192.168.1.50, host_net_info: 192.168.1.102 } ], config_path: , enable_lidar_sync: false }broadcast_code是个坑点。每颗mid360机身铭牌上有一串16位广播码填进去是稳定连接的关键。如果不填或填全0driver也能尝试自适应连接但在多雷达环境下就会出乱子所以务必填实。pcl_data_type这个字段要注意1表示输出点云2表示输出点云IMU。FAST-LIO2需要IMU数据所以这里必须设为2。很多人在这个字段上栽过跟头设成1之后启动FAST-LIO2程序一直等IMU数据看起来像死锁实际上是数据根本没发出来。host_net_info也要对上主机的IP地址。如果雷达和目标主机跨网段或者host_net_info填的是网关地址都会导致收不到数据。如果一台主机带两颗mid360那么lidar_configs数组里要写两个条目每个条目配不同的广播码frame_id也要区分比如第一颗用livox_frame第二颗用livox_frame_2。3.5 验证数据链路启动driver2roslaunch livox_ros_driver2 msg_MID360.launch如果一切正常会看到类似[Livox-LiDAR] Connect to Lidar 000000000000001 successfully的日志。然后开另一个终端验证点云rostopic hz /livox/lidar正常能看到10Hz左右。再看一下IMUrostopic echo /livox/imu -n 3如果有点云没IMU回去检查pcl_data_type。有IMU没点云检查广播码和网络。这里就完成了雷达侧的第一步部署。雷达数据已经进入ROS生态接下来是FAST-LIO2的编译和对接。4. FAST-LIO2编译配置4.1 源码准备FAST-LIO2的源码在港大MaRS实验室的GitHub仓库cd ~/catkin_ws/src git clone --recursive https://github.com/hku-mars/FAST_LIO.git这里--recursive不能省仓库里带了Sophus、ikd-Tree和livox_ros_driver2的submodule。如果没有递归拉取后面编译Sophus的时候必然报错。如果clone时submodule没拉全可以单独补cd FAST_LIO git submodule update --init --recursive另外要注意FAST_LIO里这个livox_ros_driver2 submodule和你自己拉的那个driver2在编译时会冲突吗实际上FAST_LIO的CMakeLists里通过find_package(catkin REQUIRED COMPONENTS livox_ros_driver2)寻找已安装的driver2并把它的pkg作为依赖而不是直接用它submodule里的那份。所以你必须确保工作空间里先成功编译了driver2否则FAST_LIO的cmake阶段就会挂掉。4.2 编译环境排查与编译进入FAST_LIO目录确认package.xml里依赖项齐全然后回到工作空间根目录编译cd ~/catkin_ws catkin_make -j4如果编译时提示找不到livox_ros_driver2这个package多半是因为driver2没有成功编译或者没有在同一个工作空间里。可以先用rospack find livox_ros_driver2确认能找到。找不到就去检查driver2是否source了。还有一类常见问题是Sophus没编出来。检查~/catkin_ws/src/FAST_LIO/src/thirdparty/Sophus目录是否为空如果是说明submodule没拉全执行上面那条git submodule update命令即可。编译成功的标志是build目录下出现了fastlio_mapping这个可执行文件。此时别急着跑先改配置。4.3 配置文件修改FAST-LIO2的配置在FAST_LIO/config/目录下推荐直接用mid360.yaml。打开后重点改以下几项common: lid_topic: /livox/lidar imu_topic: /livox/imu time_sync_en: falselid_topic和imu_topic要和你driver发布的话题名一致。我在默认配置上第一次跑的时候发现lid_topic写的是/livox/lidar而driver2发布的是/livox/lidar_1如果不注意程序会一直等数据。IMU配置preprocess: lidar_type: 1 scan_line: 4 blind: 0.5lidar_type: 1表示livox系列雷达这个不能动。scan_line: 4是mid360每帧4条扫描线的含义注意如果用的是双雷达融合后的合成点云scan_line这里不一定等于4要看你的处理节点怎么合并的。外参配置这块是重头戏单独开一节说。5. mid360坐标系对齐与倾斜/双雷达部署5.1 为什么会有倾斜雷达和坐标对齐问题mid360的垂直视场只有-7°到29°也就是说它天生往上看。如果你把雷达水平装在小车顶部那么近处地面和车周围的一圈盲区会比较大。很多方案为了兼顾地面和障碍物会把mid360向前倾斜30°到60°安装这样既能照到车前的地面又能看到远处的障碍物。问题就来了——雷达的几何坐标系是跟着雷达外壳方向走的一旦安装姿态变了输出点云的坐标系也变。FAST-LIO2默认把雷达坐标系当成X前Z上的约定系如果雷达本身是斜的就必须在配置里告诉它真实的旋转量否则建出来的地图会整个歪掉。5.2 坐标系约定与外参矩阵修改先说清楚mid360的坐标系定义。Livox的官方定义是X轴从雷达正面窗口向外Y轴由右手定则决定Z轴垂直向上。注意很多人以为mid360的X轴是朝向标签纸方向实际上并不一定不同型号的label方向有差异最好以官方文档和点云观察为准。FAST-LIO2里外参由两段配置决定calib: # extrinsics from lidar to imu R_ext: [1, 0, 0, 0, 1, 0, 0, 0, 1] T_ext: [0, 0, 0]这里R_ext是雷达坐标系到IMU坐标系的旋转矩阵T_ext是平移。mid360内置IMU在雷达内部理论上原点和雷达重合所以平移基本是0。如果雷达水平安装且和驱动代码默认方向一致R_ext保持单位阵没问题。但如果你把雷达前倾了45度绕Y轴旋转45度那么旋转矩阵就是cos(45°) 0 sin(45°) 0 1 0 -sin(45°) 0 cos(45°)也就是说配置里要填R_ext: [0.7071, 0, 0.7071, 0, 1, 0, -0.7071, 0, 0.7071]这里有个容易写反的地方FAST-LIO2的R_ext表达的是雷达坐标系到IMU坐标系的旋转如果雷达前倾意味着雷达的Z轴在世界系下也跟着前倾所以旋转矩阵的sin符号要仔细推导不是随手填进去。稳妥的做法是先在Rviz里看雷达点云确认当前点云坐标系下哪个轴朝前、哪个轴朝上再根据旋转公式填入。我可以给一个偷懒但可靠的方法先用单位阵跑一次点开Rviz的Axes显示看雷达点云的X轴实际朝哪个方向如果雷达是倾角安装你会看到地面点云的平面方向和Axes明显不垂直。这时按轴角或者欧拉角把R_ext补上重新启动就行。别指望一个公式搞定所有安装方式每台车的安装都不一样必须自己验证一遍。5.3 双雷达融合配置双激光雷达融合的需求在巡检和测绘项目里越来越常见一般是为了补足视场或者提高建图鲁棒性。但FAST-LIO2的代码默认只订阅一个lidar topic怎么接进第二颗雷达我这里说一种最简单、最不容易出错的方案合并点云后再送出。思路是这样把两台mid360接在同一个host上分别配置为不同的广播码和端口driver2会各自发布/livox/lidar和/livox/lidar_1两个topic。写一个小节点订阅两个PointCloud2按时间戳对齐后合并成一个PointCloud2再转发给FAST-LIO2。合并前后的tf和外参都要在同一个坐标系下表达。一个关键点两颗雷达之间的外参标定。如果你只是粗略合并两台雷达的点云在远处可能对不齐。严谨的做法是用标定板或手眼标定获取两台雷达之间的RT再把第二颗雷达的点云变换到第一颗雷达坐标系下合并。这里我建议先用ICP做一个初始对齐再人工微调工程上够用。合并节点的核心逻辑可以用这段伪代码表示// 伪代码实际代码需要处理消息时间同步和坐标系变换 void callbackLidar1(const PointCloud2::ConstPtr msg1) { latest_cloud1 transformToFrame(msg1, lidar1_T_base); mergeAndPublish(); } void callbackLidar2(const PointCloud2::ConstPtr msg2) { latest_cloud2 transformToFrame(msg2, lidar2_T_base); mergeAndPublish(); }代码的细节不多但时间戳对齐是避不开的坑。两个雷达的数据并非严格同时到达差值超过50ms就要考虑丢弃或插值。时间戳不对齐合成的点云会出现重影FAST-LIO2解算时地图直接糊掉。我在实际项目里用过的最省事方案是在合并节点里用message_filters::ApproximateTimeSynchronizer做近似时间同步效果比手动对齐稳妥得多。另外双雷达融合后如果两颗雷达的视场有重叠那个区域的点云密度会是别处的两倍特征提取时可能产生权重偏差。解决办法也不复杂在合并节点里对重叠区域做一次体素降采样把密度拉均匀我习惯用PCL的VoxelGrid在这片区域设0.3米的网格。5.4 IMU时间同步问题FAST-LIO2对IMU时间戳的分辨率要求挺高。mid360内置IMU的时间戳和点云时间戳在driver2内部已经做了对齐所以直接用没问题。但如果你外接IMU时间同步就麻烦很多需要硬件PPS或GPRMC。我建议一开始就使用内置IMU省去同步负担。如果发现FAST-LIO2启动后一直不输出里程计检查IMU消息的时间戳是否连续rostopic echo /livox/imu/header/stamp注意观察时间戳是否为递增且稳定的频率如果跳动严重多半是供电问题或网线质量差导致数据丢包。6. 实机建图与效果调试6.1 启动流程先启动雷达驱动roslaunch livox_ros_driver2 msg_MID360.launch确认点云和IMU都在发之后再启动FAST-LIOroslaunch fast_lio mapping_mid360.launchlaunch文件里默认会加载mid360.yaml如果改了配置文件名记得同步改launch。启动后的一瞬间程序会开始接收数据但里程计不一定马上输出——它得等IMU初始化稳定。IMU初始化的过程是这样的FAST-LIO2内部用静止或者低速晃动过程中的IMU数据估计零偏和重力方向如果传感器一直不动初始化可能很慢或者不准确。所以我每次上电后的标准操作是拿到遥控器先把小车手动晃动十几秒然后再起步让IMU快速收敛。这是一个很容易被忽略但影响很大的实操细节。启动时还有个细节launch里如果写了outputscreenFAST-LIO2会打印每帧处理时间、特征点数等信息。我建议第一次跑的时候保持这个配置方便看程序是否在正常迭代。等到正式跑任务时再改成outputlog避免日志刷屏影响性能。6.2 Rviz查看与地图质量评估启动后打开Rvizrosrun rviz rviz -d ~/catkin_ws/src/FAST_LIO/rviz_cfg/loam_livox.rviz正常能看到两个关键topic/Odometry里程计位姿/cloud_registered注册后的点云也就是实时地图评估建图质量我看三个地方地面是否平、墙面是否直、长时间运动后是否回环对齐。如果墙是弯的、地面是波浪的代表位姿漂移需要回头看IMU和特征提取。另外Rviz里可以顺手打开/path查看轨迹平滑度轨迹抖动明显说明IMU噪声或外参有问题。6.3 调参建议FAST-LIO2里比较常用调参项我列一下filter_size_surf面特征体素滤波尺寸默认0.5如果地图噪声大可以适当减小到0.3但会明显增加CPU占用。filter_size_map全局地图体素尺寸默认0.5改小会提升地图细节改大减少内存。max_iteration最大迭代次数默认3抖动大时可以提高到5但延迟会上升。time_sync_en如果雷达和IMU时间戳来自不同硬件设true但内置IMU一般不用。每次只改一个参数记录前后对比这是调参的基本纪律。我见过不少同学一次改三四个参数出了问题根本不知道是谁引起的。另外如果建图过程中发现地图漂移比较大可以先用一个小场景、短时间的bag包回放来复现问题。录制bag用rosbag record /livox/lidar /livox/imu /tf回放时再做参数调整比现场边跑边改高效得多。7. 常见问题与排查技巧实录这里整理一份我从实战里攒下来的排查清单基本覆盖了这套方案里80%的翻车场景。现象可能原因排查/解决方法ping不通192.168.1.50主机IP没配对、网线质量问题检查网口IP和掩码换一根六类网线driver2启动即退出广播码不对或lidar_ip配置错误核对雷达铭牌广播码填到json有/livox/lidar没/livox/imupcl_data_type设成了1改成2并重启driver有IMU没点云雷达被其他进程占用、broadcast code填错关闭其他占用节点核对广播码FAST-LIO2启动后一直等数据topic名不匹配或时间戳异常rostopic list对比实际topic确认lid_topic/imu_topic建图地图整体歪斜外参R_ext不对用Rviz确认雷达坐标系方向修正旋转矩阵双雷达本文还有配套的精品资源点击获取