做多线激光雷达融合这件事，我最常被问到的一个问题是：双雷达到底是不是智商税？我的答案是，看场景。如果你做的是园区无人车、室内外巡检机器人、或者任何需要在近场有超大视场角覆盖的感知系统，双雷达带来的不是“多一份数据”那么简单，而是把感知盲区直接砍掉一大截。这次我基于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_driver2
Livox官方提供了两代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，时间偏差可能达到毫秒甚至几十毫秒级别。对双雷达融合来说，最可靠的方案是让两台雷达所在的主机系统时间与一个统一的时钟源同步，雷达的时间戳在上层驱动中默认使用系统时钟，系统时间同步了，点云时间戳自然同步。
我在现场用的方案是PTP（IEEE 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_type：1表示Mid-360ip：雷达IP地址pcl_data_type：0表示输出原始点云（PointXYZRTL），1表示转换后的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类型转换与环境搭建
PCL（Point 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::PointCloud<pcl::PointXYZ>处理，减少内存开销。
实际编写代码时发现，现场总线上的PointCloud2消息如果字段太多，转换到PCL点云时会因为field name不匹配报错。稳妥的做法是先用pcl::fromROSMsg转到pcl::PointCloud<pcl::PointXYZ>，如果源点云带强度或者时间字段，别直接用XYZ类型接收。这一点在Mid-360驱动使用默认配置时很容易踩中。
4.3 核心融合算法：体素滤波去重
双雷达点云融合的难点在于重叠区域的处理。两台雷达都有360度水平视场角，前后安装时中间有很大一片区域是重叠的。如果直接把两帧点云叠加发布出去，重叠区域会出现密集的重复点，导致后续配准和聚类算法的计算量翻倍、精度下降。
解决方案是做体素滤波去重。思路是：先用一个较大的体素栅格（比如5cm）对两帧点云分别进行下采样，再把变换后的后雷达点云叠加到前雷达点云上，然后用一个体素大小为3cm的栅格对合并后的点云进行去重。去重的原理很简单：落在同一个体素内的多个点只保留一个，这样既能消除重复点，又不会对点云原始结构造成太大破坏。
这里有个细节值得展开。直接对合并点云做体素滤波确实能去重，但也会让原本在非重叠区域一点都不重复的高精度点云变得稀疏。我试过两种做法。第一种是“先合并再滤波”，实现简单，效果尚可，适合重叠区域占比不高的场景。第二种是“先区分重叠区和非重叠区，只对重叠区域做去重”，效果更好，但需要先计算点云间的重叠关系，代码复杂度上升不少。
对于双Mid-360这种重叠区域比较大的场景，我最终用的是改进后的方案：先分别下采样，再合并，再做一次轻量级去重。关键代码如下：
pcl::VoxelGrid<pcl::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::VoxelGrid<pcl::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_front，child是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自带IMU，livox_ros_driver2也提供了IMU数据话题，可以直接做去畸变处理。代价是计算量增加约20%，但点云边缘会变得更锐利，对于高速运动场景帮助很大。
另外一个扩展方向是多雷达拼接，将三台以上Mid-360通过组合安装实现无死角覆盖。融合逻辑与双雷达版本完全一致，只是外参矩阵的数量和TF树结构会复杂一些，需要额外注意命名规范和参数管理。
在实际部署中还有一点值得强调：标定参数不要只存在代码里。我建议把标定结果写成一个YAML参数文件，由融合节点启动时加载。同时在内参、外参变化时运行一个校验脚本，自动对比新旧外参对同一帧点云变换后的重合度，变化超过阈值就告警。这个习惯在我维护多台设备时帮了大忙，之前因为设备运输振动导致外参漂移，没及时发现，结果排查了一整天问题，后来加了自动校验才算彻底解决。
双雷达融合这个需求会越来越多，尤其是中大型机器人逐渐普及之后。Mid-360因为性价比高、垂直FOV大，很适合做这类方案的感知核心。希望这篇实战记录能帮你少走几个弯路。如果你选择了不同的安装构型，标定和融合的思路依然可以复用，重点是先把坐标系关系和去重逻辑理清楚，其余的只是工程细节的优化。