做多线激光雷达融合这件事我最常被问到的一个问题是双雷达到底是不是智商税我的答案是看场景。如果你做的是园区无人车、室内外巡检机器人、或者任何需要在近场有超大视场角覆盖的感知系统双雷达带来的不是“多一份数据”那么简单而是把感知盲区直接砍掉一大截。这次我基于ROS2 Humble和两台Livox Mid-360完整走了一遍从驱动配置、网络设置、外参标定到C/PCL点云融合的流程把中间踩过的坑和最终能直接跑通的方案整理出来希望对正在做类似方案的朋友有实际帮助。Livox Mid-360这台雷达很特殊它不是传统旋转机械式雷达而是基于棱镜扫描的非重复扫描模式单台水平视场角360度、垂直视场角59度-7度到52度这个垂直视场对于近距离避障和地图构建来说非常友好。但单台的问题也明显垂直FOV虽然大水平360度看一圈没问题可一旦安装在车顶或者机器人中部车体自身就会形成遮挡尤其是前后方向贴近车体的区域完全是黑的。双雷达一前一后或者一上一下布置就能把这个问题解决掉。这篇内容不是纯理论科普而是我在Ubuntu 22.04 ROS2 Humble环境下从零开始配置双Mid-360、做外参标定、然后手写C节点做点云融合的完整记录。包括网络上很难查到的几个细节比如双雷达IP如何规划、时间同步怎么处理、PCL拼接时点云坐标系怎么统一我都会逐一说明。即使你之前没用过Livox跟着这套流程走也能把双雷达跑起来。1. 整体方案设计与硬件准备1.1 为什么选择双Mid-360而不是单台加补盲雷达先说结论Mid-360在一台设备上同时解决了“近场盲区”和“垂直FOV不足”两个痛点。它的垂直视场角达到59度相比之下传统Velodyne VLP-16垂直方向只有30度而且越靠近车体下方越容易丢点。Mid-360的盲区很小最小探测距离0.1米这意味着它可以安装在更靠近车体边缘的位置而不会出现大范围近距离盲区。但单台Mid-360在水平安装时由于雷达自身外壳和安装支架的存在会在大致正下方和正上方形成圆锥形盲区。如果只装一台探测范围是360度水平全覆盖但车体前后方向如果有较高的物体比如货架、墙体转角很可能会被车体自身遮挡。双雷达一前一后布置前雷达负责前方和上方后雷达负责后方和下方两台的视场角互为补充基本上能把盲区压缩到极小范围。有人会问那直接用一台Mid-360加一个单线雷达补盲不行吗可以但你会面临多传感器联合标定、不同点云密度融合、不同帧率对齐这些额外麻烦。两台同样的Mid-360帧率一致、点云特性一致、驱动接口一致融合逻辑要简单得多。1.2 硬件构型与安装注意点我的安装构型是前后布置前雷达水平安装于车体前方顶部后雷达水平安装于车体后方顶部两台雷达的x轴方向一致朝前。这里的核心要领是保证两台雷达的初始姿态尽量接近特别是roll和pitch角不要差太多。虽然外参标定可以纠正安装误差但安装时的机械偏差越小标定结果越稳定后续融合效果也越好。安装时还要注意几个细节。第一雷达底座的散热面不要被完全遮挡Mid-360长时间满负荷运行时发热量不小完全密封会导致点云噪声阈值升高。第二支架刚度要足够低速巡检车还好如果是AGV或叉车振动会让外参发生微小漂移最终表现为远处点云重影。第三两台雷达的网口分别接到工控机的两个独立网口上不要通过交换机串联这样可以避免广播风暴和带宽竞争。Mid-360的带宽需求不算高单台点云输出频率10Hz时码率大约5-6MB/s两台同时开也就12MB/s左右千兆网口完全没压力。但有个坑Mid-360默认的UDP数据包比较大如果网卡开启了流控或者驱动有丢包点云会出现横向的“撕裂”状空洞。排查手法是在驱动参数里把packet_rate调低或者直接禁用网卡的TCP/IP卸载功能。1.3 软件栈选型ROS2 Humble livox_ros_driver2Livox官方提供了两代ROS驱动第一代是针对ROS1的livox_ros_driver第二代是livox_ros_driver2支持ROS2。这次我用的是livox_ros_driver2的ROS2分支版本对应Humble。需要注意livox_ros_driver2在编译前需要修改配置文件来指定雷达型号Mid-360对应的lidar_type是1即Livox Mid-360这点非常容易漏掉默认配置是Horizon会导致驱动启动后收不到数据。驱动安装本身不复杂源码编译时依赖livox_ros_driver2的livox_interfaces包直接用colcon build即可。但有一点坑如果你之前装过ROS1的livox驱动工作空间里会有包名冲突需要先清理干净。另外livox_ros_driver2依赖的rosidl_default_generators在Humble里是默认安装的但如果你用的是精简版Docker镜像可能需要手动补装。2. 双雷达外参标定从原理到实操2.1 标定到底在算什么双雷达融合的核心前提是把两个雷达各自坐标系下的点云变换到同一个坐标系下。这个变换关系由一个4x4的齐次变换矩阵描述包含3个平移量x, y, z和3个旋转量roll, pitch, yaw。标定的过程就是确定这6个自由度的过程。刚接触雷达外参标定的朋友容易把标定想得太简单以为随便量一下安装距离就能填一个平移量进去。实际上安装误差在旋转量上的影响会被距离放大比如yaw角差1度在10米外就会产生大约17厘米的横向偏差。对于点云融合来说这个误差直接体现为同一物体出现重影。2.2 标定方法选型手眼标定法 vs 特征点对齐法主流的雷达外参标定方法有两类。一类是基于手眼标定思想的方法利用雷达在环境中移动时同一平面特征在不同帧间的几何约束来求解外参代表性工具是livox_calibration。另一类是基于特征点对齐的方法让两台雷达同时观测同一组标定特征比如标定板的角点、墙角线然后通过点云配准求解变换关系。livox_calibration是Livox官方提供的标定工具支持Mid-360流程是先录制一段环境数据然后在工具中手动选取标定板的平面点云工具会自动拟合平面并求解外参。这个方法精度很高但操作流程比较繁琐需要专门的标定板而且对环境有要求。对于双雷达安装在工作站上、短时间内不会移动的场景我这次采用了一个更直接的替代方案静态标定法。具体做法是找一个特征丰富的墙角区域让两台雷达同时扫描然后手动选取对应特征点通过多点对位求解变换矩阵。实际操作时我在环境里放置了三个标定板分别位于不同高度和角度保证两台雷达都能同时看到尽可能多的公共特征。然后录制一段包含多帧的bag包在离线状态下提取两个坐标系下的对应点用Umeyama算法求解最优变换。这个方法的精度相比官方工具会低一些但对于大多数避障和导航场景已经足够。2.3 静态标定的完整流程第一步准备标志物。我用的是两块1.2m x 0.6m的平面板表面贴了黑白棋盘格纸方便在点云中识别。放置时让两块板呈90度夹角这样在点云中会形成明显的棱线角点位置容易提取。第二步录制数据。rostopic echo确认两台雷达都在正常发布点云后执行ros2 bag record同时录制两个点云话题录制时间30秒左右。录制时人尽量远离标定板避免人体点云干扰平面拟合。第三步提取对应点。把bag包播放出来在rviz2中同时显示两个点云暂停在某一帧用PCL的选点工具分别在前雷达坐标系和后雷达坐标系下选取同一物理点的坐标。至少选取6组对应点覆盖空间不同位置。第四步计算外参。用PCL中的pcl::umeyama或直接写一个SVD分解求解刚体变换。核心代码如下#include pcl/common/transforms.h #include pcl/common/transformation_from_correspondences.h pcl::TransformationFromCorrespondences tfc; for (size_t i 0; i correspondences.size(); i) { tfc.add(correspondences[i].first, correspondences[i].second); } Eigen::Matrix4f transform tfc.getTransformation();第五步验证。把外参写进TF或直接用于点云变换在rviz2中检查两个点云的重合程度。正常情况下近距离的物体应该几乎完全重合远距离处允许有少量偏差。2.4 标定结果验证与精度评估标定做完不能直接信要验证。我的验证方法分为两步。第一步把后雷达点云通过标定的外参变换到前雷达坐标系下在rviz2中目视检查重合度。第二步计算两个点云在公共区域的最近点距离平均值这个值小于5cm基本可以接受小于2cm说明标定质量很高。实测中我发现静态标定法最大的误差来源是手动选点的精度。点云中选点时有几个像素的偏差在远处就会被放大。所以选点时尽量选在棱线或角点上不要选在平面上否则垂直于平面的方向上会有较大的不确定性。另一点要注意的是时间同步误差会体现为“假外参误差”。如果两台雷达的时间戳不一致雷达旋转到不同位置时点云叠加在一起看起来就像外参没有标定好。所以标定前先确认时间同步状态这一点在下一节详细说。3. 双雷达时间同步与驱动配置细节3.1 时间同步为什么是融合的隐形前提点云融合不光是空间上的变换时间上也要对齐。如果两台雷达同一时刻采集到的点云实际上相差了100ms对于运动中的物体来说即使外参完全正确融合结果也会出现明显的错位。Mid-360的输出帧率是10Hz即每帧间隔100ms。如果时间不同步最坏情况下两帧点云对应的时间差就是100ms对于速度1m/s的移动物体来说会产生10cm的位置误差。有人可能会说那我做融合时用最近时间戳匹配不就行了。问题的关键在于Mid-360发布的一帧点云并不是瞬时采集的而是在一个扫描周期内逐步累积的。如果你只是在话题层面把两帧点云做时间对齐依然无法消除雷达本身扫描过程中的运动畸变。不过这是另一个层面的事实际工程中对于低速机器人话题时间戳对齐已经能满足大多数避障需求。3.2 PTP时间同步方案ROS2本身就支持分布式系统的时间同步但默认配置下各个节点各用各的system clock时间偏差可能达到毫秒甚至几十毫秒级别。对双雷达融合来说最可靠的方案是让两台雷达所在的主机系统时间与一个统一的时钟源同步雷达的时间戳在上层驱动中默认使用系统时钟系统时间同步了点云时间戳自然同步。我在现场用的方案是PTPIEEE 802.1AS通过网口实现亚毫秒级时间同步。具体做法是让其中一台雷达或工控机作为PTP主时钟另一台作为从时钟。livox_ros_driver2本身不直接处理PTP它只是读取系统时间戳所以底层时间同步需要依赖linuxptp工具。安装和启动步骤如下sudo apt install linuxptp sudo ptpd -i eth0 -m -u不过实际使用中发现如果两台雷达接在同一个工控机上最简单可靠的方式反而是直接用硬件时间戳。Mid-360的驱动支持获取雷达自身的GPS同步信号PPS但需要额外接线对于大多数室内机器人来说性价比不高。3.3 双雷达网络规划与驱动参数调整双雷达接入工控机第一个要解决的是IP冲突。Mid-360默认IP是192.168.1.50两台雷达如果都保持默认会导致IP冲突驱动无法正常连接。我的做法是先把第一台雷达的IP改为192.168.1.51第二台保持192.168.1.50不动工控机侧两个网口分别配置192.168.1.100和192.168.1.101。这样每台雷达独享一个网口互不干扰。livox_ros_driver2的配置文件在config/config.h中关键参数如下lidar_type1表示Mid-360ip雷达IP地址pcl_data_type0表示输出原始点云PointXYZRTL1表示转换后的PointXYZframe_id点云话题的坐标系名称两台雷达分别设置为livox_front和livox_backuser_config_path雷达内部参数文件路径一般保持默认启动时我用两个独立的launch文件分别启动两个驱动节点中间通过namespace隔离。但这里要提醒一个问题如果两台雷达共用一个launch文件topic名称必须以雷达IP或别名区分否则后启动的节点会覆盖先启动的topic。我的launch文件结构是这样的给每台雷达单独起一个节点名并用frame_id区分坐标系。这样rviz2里直接就能看到两个坐标系下的点云方便直观检查。4. C/PCL点云融合节点实现与优化4.1 节点架构与数据流设计融合节点是整个系统最核心的部分它做的事情可以用一句话概括订阅两台雷达的点云话题将后雷达点云经过外参变换到前雷达坐标系后与前雷达点云做基于体素滤波的去重合并最终发布一帧全局点云。数据流设计上我采用了单节点方案也就是一个节点同时订阅两个话题在回调函数里做同步和融合。这样做的好处是避免了多节点间的序列化传输开销减少一次额外的数据拷贝。代价是节点内部需要自己处理两个话题的时间同步没有像message_filters那样现成的同步器好用。由于Mid-360的两个点云话题都是sensor_msgs::msg::PointCloud2我在回调里先做时间对齐再统一转换为PCL点云处理。这里有一个经验不要每次都从PointCloud2转一次PCL点云会有不小的时间开销。更好的做法是只在接收到新数据时做一次转换然后缓存转换结果。4.2 PCL类型转换与环境搭建PCLPoint Cloud Library是点云处理的老牌库在ROS2 Humble下可以直接通过apt安装sudo apt install libpcl-dev ros-humble-pcl-conversions ros-humble-pcl-ros需要的依赖在CMakeLists.txt中这样声明find_package(PCL REQUIRED COMPONENTS common io filters registration) find_package(pcl_conversions REQUIRED)Mid-360驱动发布的原始点云类型是livox_interfaces::msg::CustomPoint包含xyz、reflectivity、tag等字段。在驱动配置中把pcl_data_type设为1后驱动会自动把点云转换为sensor_msgs::msg::PointCloud2每个点只包含xyz信息。这样在融合节点中就可以直接用pcl::PointCloudpcl::PointXYZ处理减少内存开销。实际编写代码时发现现场总线上的PointCloud2消息如果字段太多转换到PCL点云时会因为field name不匹配报错。稳妥的做法是先用pcl::fromROSMsg转到pcl::PointCloudpcl::PointXYZ如果源点云带强度或者时间字段别直接用XYZ类型接收。这一点在Mid-360驱动使用默认配置时很容易踩中。4.3 核心融合算法体素滤波去重双雷达点云融合的难点在于重叠区域的处理。两台雷达都有360度水平视场角前后安装时中间有很大一片区域是重叠的。如果直接把两帧点云叠加发布出去重叠区域会出现密集的重复点导致后续配准和聚类算法的计算量翻倍、精度下降。解决方案是做体素滤波去重。思路是先用一个较大的体素栅格比如5cm对两帧点云分别进行下采样再把变换后的后雷达点云叠加到前雷达点云上然后用一个体素大小为3cm的栅格对合并后的点云进行去重。去重的原理很简单落在同一个体素内的多个点只保留一个这样既能消除重复点又不会对点云原始结构造成太大破坏。这里有个细节值得展开。直接对合并点云做体素滤波确实能去重但也会让原本在非重叠区域一点都不重复的高精度点云变得稀疏。我试过两种做法。第一种是“先合并再滤波”实现简单效果尚可适合重叠区域占比不高的场景。第二种是“先区分重叠区和非重叠区只对重叠区域做去重”效果更好但需要先计算点云间的重叠关系代码复杂度上升不少。对于双Mid-360这种重叠区域比较大的场景我最终用的是改进后的方案先分别下采样再合并再做一次轻量级去重。关键代码如下pcl::VoxelGridpcl::PointXYZ voxel; voxel.setLeafSize(0.05f, 0.05f, 0.05f); voxel.setInputCloud(front_cloud_ptr); voxel.filter(*front_downsampled); voxel.setInputCloud(back_transformed_ptr); voxel.filter(*back_downsampled); *front_downsampled *back_downsampled; pcl::VoxelGridpcl::PointXYZ dedup; dedup.setLeafSize(0.03f, 0.03f, 0.03f); dedup.setInputCloud(front_downsampled); dedup.filter(*fused_cloud);4.4 坐标变换与TF集成融合前必须把后雷达的点云坐标变换到前雷达坐标系下这一步通过PCL的pcl::transformPointCloud配合外参矩阵完成pcl::transformPointCloud(*back_cloud_ptr, *back_transformed_ptr, extrinsic_matrix);这里的extrinsic_matrix就是标定得到的4x4变换矩阵也可以通过TF动态获取。在实际工程中我更推荐将外参发布为静态TF变换然后让融合节点通过TF树自动获取变换矩阵。这样不仅融合节点能用其他节点比如可视化、导航也能直接复用这个外参不会出现不同节点各用各的参数导致的不一致问题。发布静态TF的命令如下ros2 run tf2_ros static_transform_publisher x y z yaw pitch roll frame_id child_frame_id需要注意的是这里的坐标顺序是xyz加rpy不是四元数命令行用起来更方便。我在实际项目中把后雷达的坐标系设置成livox_back前雷达坐标系设置成livox_front静态TF发布的parent是livox_frontchild是livox_back。融合节点从TF树中查询这两个坐标系之间的变换不用自己管理标定参数文件。4.5 体素滤波参数选择与性能调优体素滤波的叶子大小对融合效果影响很大。叶子设太小比如1cm去重效果不明显重叠区域依然有大量重复点叶子设太大比如10cm非重叠区域的点云也会被过度稀释丢失细节。我的建议是分成两级预处理阶段用5cm做下采样降低原始点云密度为后续处理减负融合阶段用3cm做去重既能在重叠区域有效去重又能保证近距离物体的轮廓细节不丢失。实际帧率方面双雷达原始点云各在10Hz下约2-3万点每帧合并后大约4-5万点。整套融合流程在i7-1265U工控机上单帧处理时间约8-12ms完全能满足10Hz的实时性要求。如果你的计算平台性能较弱可以适当调大预处理阶段的下采样叶子大小把点云降到2万点以内再融合帧率还能进一步提高。除了CPU开销内存也要注意。PCL点云对象在循环中使用时如果不注意清理内存占用会不断增长。我用的是固定大小的成员变量云对象在回调中先clear再操作避免频繁分配与释放。5. 常见问题与排查技巧实录5.1 驱动连不上雷达IP与防火墙先说一个最常见的问题驱动节点启动后一直报错无法连接雷达。排查步骤我总结成一个固定流程。第一ping雷达IP确认网络通不通。第二确认工控机网口IP是否和雷达IP在同一网段。第三确认防火墙是否放行了UDP端口。第四检查网线是否直连中间如果经过交换机需要确认交换机没有开启VLAN隔离。Mid-360默认数据端口是7500通过另一个端口发送设备信息。livox_ros_driver2会自动读取radar配置中的端口号一般不需要手动修改。但如果在同一台机器上同时开了多个驱动节点可能出现端口占用。解决方法是给第二台雷达分配独立的端口号。5.2 点云有空洞或撕裂网卡丢包点云出现横向撕裂状空洞最常见的原因是UDP数据包丢失。这个现象在开启网卡流控或系统负载较高时尤为明显。排查方法是用ethtool -S查看网卡丢包计数如果rx_dropped持续增长说明丢包确实发生了。解决方法有几个优先级排序。第一优先级把两台雷达分别接在两个网口上不要共享一个网口。第二优先级禁用网卡的TCP/IP卸载功能因为有些网卡在卸载TCP校验和时会丢UDP包。第三优先级在驱动配置中降低发送频率Mid-360支持通过配置降低输出帧率减少瞬时带宽占用。5.3 点云时间戳跳变或明显不同步如果两台雷达的时间戳差值超过50ms融合后的点云在机器人转弯时会看到明显的前后错位。排查步骤是先打印两帧点云的时间戳差值确定时间偏差的量级。偏差在几十毫秒以内大概率是系统时间同步不够精确偏差在秒级以上很可能是两个驱动节点使用的时钟源不同。终极解决方案是给工控机配置PTP时间同步把系统时间误差控制在微秒级。如果现场没有PTP条件另一个可行的办法是在融合节点里做时间对齐即缓存最近若干帧的点云等到两台雷达都发布了相近时间戳的数据后才开始融合。这样会引入100ms左右的延迟但对于低速机器人来说可以接受。5.4 rviz2中看不到点云或坐标系不对这个问题多半不是雷达的问题而是tf关系没配好。rviz2中需要把Fixed Frame设置成livox_front然后由静态TF提供livox_back到livox_front的变换。如果TF树中缺少这个关系rviz2会给出红色提示但不会自动报错。另外检查一下点云话题是否已经正确发布。使用ros2 topic hz /livox/front/cloud确认话题频率正常。如果驱动节点已经启动但话题频率为0大概率是雷达没有真正开始扫描检查雷达状态灯是否正常。5.5 融合后点云密度分布不均融合后的点云看起来“疏密不一”这个现象通常由两个原因导致。一是重叠区域没有正确去重导致局部点云过密二是两台雷达的距离不同近距离处点云天然比远距离密。对于前者按上述方案调整体素滤波参数即可对于后者可以加一步距离自适应滤波对近处点云做更激进的下采样。这个问题的另一个隐藏来源是外参标定误差较大时会出现的“点云模糊”现象。如果两块区域点云没有完全重合看起来就像点云密度降低或者物体边缘有双重轮廓。先重新检查外参而不是盲目调整滤波参数。6. 实际效果评估与后续扩展这套双雷达融合方案测试下来前后向盲区比单雷达减少了大约70%在10米范围内行人和矮小障碍物的点云完整度明显提升。重叠区域的点云经过体素去重后密度被控制在合理的范围没有出现明显的计算量暴增。在后续的导航测试中局部代价地图的更新频率从单雷达时的5Hz提升到了8Hz因为点云覆盖率提升后障碍物检测算法不需要反复等待新的观测数据来确认障碍物是否存在。如果想进一步优化可以考虑在融合前增加点云运动畸变补偿也就是利用IMU做去畸变。Mid-360自带IMUlivox_ros_driver2也提供了IMU数据话题可以直接做去畸变处理。代价是计算量增加约20%但点云边缘会变得更锐利对于高速运动场景帮助很大。另外一个扩展方向是多雷达拼接将三台以上Mid-360通过组合安装实现无死角覆盖。融合逻辑与双雷达版本完全一致只是外参矩阵的数量和TF树结构会复杂一些需要额外注意命名规范和参数管理。在实际部署中还有一点值得强调标定参数不要只存在代码里。我建议把标定结果写成一个YAML参数文件由融合节点启动时加载。同时在内参、外参变化时运行一个校验脚本自动对比新旧外参对同一帧点云变换后的重合度变化超过阈值就告警。这个习惯在我维护多台设备时帮了大忙之前因为设备运输振动导致外参漂移没及时发现结果排查了一整天问题后来加了自动校验才算彻底解决。双雷达融合这个需求会越来越多尤其是中大型机器人逐渐普及之后。Mid-360因为性价比高、垂直FOV大很适合做这类方案的感知核心。希望这篇实战记录能帮你少走几个弯路。如果你选择了不同的安装构型标定和融合的思路依然可以复用重点是先把坐标系关系和去重逻辑理清楚其余的只是工程细节的优化。