拓冰网站定制 
做移动机器人感知的同行应该都有这种体会第一次在 ROS2 里跑通 Livox-Mid-360 的官方驱动看到/livox/lidar话题里 PointCloud2 消息的字段列表时第一反应往往是“x、y、z 好说reflectivity 也能猜个大概但tag、line、offset_time到底是什么”如果这些点云格式细节不搞清楚后面做滤波、时间戳补偿、保存点云、跑 SLAM 建图都会踩一堆莫名其妙的坑。这篇文章我就把 Mid-360 的点云格式彻底拆开从硬件特性讲到字段定义再给出一套能直接搬走的数据提取流程最后整理连接设备、修改 IP、建图飘移等高频问题的排查方法。手里有 Mid-360、正在做点云处理或 SLAM 的同学可以直接对照着操作。1. Mid-360这套点云格式为什么值得单独拆开讲1.1 非重复扫描带来的格式差异Mid-360 算得上是 Livox 家族里比较特殊的一员。它采用非重复扫描方式水平视场角是完整的 360°垂直视场角是 59°-7° 到 52°最远探测距离在 90% 反射率目标下能到 90 米10% 反射率下约 40 米精度标称 ±3cm默认 10Hz 帧率下每秒输出约 20 万个点。很多第一次用它的人会下意识拿机械式激光雷达的“线数”去套它结果发现完全对不上因为 Mid-360 根本不存在固定的线束编号。这个硬件特性直接决定了点云格式的设计思路。机械雷达输出点云时每个点天然携带“第几线”这个信息所以数据结构里通常就是一个ring或者line就够了但 Mid-360 是光学棱镜加电机做非重复扫描每一帧内扫描轨迹会不断改变点云不再按固定线束排列。为了把点云描述清楚驱动层就必须额外引入一些字段来记录每个点的时间偏移、分类标签、回波来源等信息这就形成了我们看到的 Livox 特有的一套点结构。可以说理解这套格式本质上是在理解“非重复扫描雷达怎么表达一帧点云”。这种设计带来的一个直接好处是单帧点云在空间上的覆盖更均匀而且只要持续扫描一段时间比如 0.1 秒到 0.2 秒视场内的点云密度会显著增加这对建图、目标检测非常有利。但它也带来一个麻烦点与点之间的时间戳不是线性的因为棱镜扫描路径是类利萨茹曲线每一帧内点的生成顺序和空间位置没有严格的“从上到下”关系。所以驱动用offset_time来表示每个点相对帧起始时刻的偏移这是 Mid-360 点云格式里最需要重视的字段之一。1.2 完整工具链选型ROS2还是SDK直连做数据提取之前先要把工具链选型想清楚。我目前的方案是基于 Ubuntu 22.04 ROS2 Humble livox_ros_driver2 PCL 这套组合原因是实际项目里你大概率要接 Cartographer、FAST-LIO 或者自己的建图算法而以 ROS2 话题形式接收点云是最省事、最通用的方式。官方驱动已经把 UDP 数据包解析、坐标系定义、IMU 数据发布都处理好了我们只需要订阅/livox/lidar话题就能拿到组织好的点云。当然如果做的是嵌入式或者自研系统不想依赖 ROS也可以直接用官方 Livox SDK 2 的 C 接口在回调里拿原始点云结构体。但这样做的话时间戳同步、帧头拼接、丢包重传这些底层逻辑都要自己处理开发成本明显更高。对于大多数做导航、建图、感知的同学我建议直接走 ROS2 加官方驱动这条路线把精力放在业务算法上而不是重复造轮子。另外提醒一句livox_ros_driver2本身依赖livox_sdk2编译时还会用到 PCL 和 Eigen环境一定要提前装好。很多人在colcon build阶段报错基本都是缺依赖后面我会给出具体的安装命令。1.3 解析的整体思路从字节流到可用的点从传感器到最终能用的点云中间经历的过程可以理解成一条数据链Mid-360 通过网口把自定义协议的 UDP 数据包发出来驱动里的 SDK 负责解析数据包把原始字节还原成带坐标、反射率、标签的 Lidar 点结构再按帧封装成 PointCloud2 消息发布到 ROS2 话题上。我们从 ROS2 拿来 PointCloud2 之后还需要做一次“格式转换”因为 PointCloud2 本质上只是一段字节流加一组字段描述要真正做点云运算得转成 PCL 点云或者自定义结构体。解析整体的思路就是三步走先认识硬件特性搞清楚数据从哪来再逐字段拆解 PointCloud2 里每个字段的物理含义最后写代码把消息转成自己需要的点云类型并保存。后面几节我就按这个思路展开。2. 点云格式核心细节拆解字段没搞懂后面全白搭2.1 LivoxPointXyzrtl结构体逐字段拆解livox_ros_driver2里默认使用的是一个叫LivoxPointXyzrtl的结构体定义大致如下struct LivoxPointXyzrtl { float x; // X坐标单位m float y; // Y坐标单位m float z; // Z坐标单位m float reflectivity; // 反射率范围约0~255 uint8_t tag; // 点分类标签 uint8_t line; // 虚拟线号 uint16_t offset_time; // 相对帧起始时刻的偏移单位us };每个字段的含义可以整理成下面这张表字段类型单位含义使用建议x / y / zfloatm点云三维坐标直接用注意坐标系方向reflectivityfloat0~255目标反射率可视化、滤波但别指望它是标定后的物理量taguint8_t无0正常 1雨 2尘 3地面 4低反射预处理过滤非常好用lineuint8_t无虚拟线号别拿它当机械雷达的ring用offset_timeuint16_tus相对帧起始时间偏移去畸变和多传感器融合必须用先讲reflectivity。Mid-360 的反射率是驱动层根据回波强度归一化出来的一个值范围大致在 0 到 255 之间白色墙、高反射率标靶的值会比较高黑色车辆、深色织物则很低。但它不是一个严格物理定标后的反射率数值受距离、入射角影响很大所以做阈值过滤时不要从某个全局固定值上一刀切。我实测下来同样一块黑白棋盘格放在 2 米和 15 米处反射率值会有明显差异这在做目标检测数据清洗时要特别注意。然后是tag字段这是 Livox 点云里很实用的一个设计。SDK 会尝试对每个点做分类常见分类包括正常点、雨滴、灰尘、地面点、低反射率点等。实际使用中用这一位就能快速滤除大部分雨雾噪点比单纯用反射率阈值更稳因为雨滴和灰尘在某个距离范围内可能表现出较高反射率直接按反射率滤会误删目标点。后面问题排查部分我会给出具体过滤代码。line字段是很多新手容易误解的地方。Mid-360 没有物理线束这个字段严格来说是驱动为兼容协议而保留的虚拟线号。我遇到的情况是在某些固件版本下 Mid-360 的line值会一直为 0 或变化规律不明显所以如果你要跑依赖 ring 编号的地面分割算法需要先确认当前固件输出是否可靠不要默认它能像机械雷达那样用。最后是offset_time它记录了这个点相对当前帧数据起始时刻的时间偏移单位微秒。这个字段对于运动畸变矫正非常关键因为一帧 20 万个点并不是同一时刻采集的而是分布在 100ms 的扫描周期内如果忽略时间偏移把所有点当成同一时刻的数据车一动起来点云就会出现轻微拖影。2.2 时间戳、坐标系与IMU数据里真正值钱的隐藏信息坐标字段虽然直观但真正决定点云能不能用于建图融合的是时间戳和坐标系。ROS2 的 PointCloud2 消息里有一个header.stamp它表示帧起始时间而每个点自己的绝对时间应该是header.stamp offset_time * 1us。注意offset_time是uint16_t最大能表示 65535 微秒约 65.5ms刚好够覆盖 10Hz 的一帧周期这也是为什么帧率变化时它需要重新对齐。时间戳的来源取决于驱动和硬件配置。如果雷达启用了 PTP 或 PPS 时间同步header.stamp会基于雷达的硬件时钟精度很高如果完全没有外部同步驱动会用主机收到数据包的时间作为基准。后者在电脑负载高、网卡中断延迟大的时候会有抖动对低速场景影响不大但做高速移动或紧耦合融合时最好还是上 PTP 同步。坐标系同样容易踩坑。Mid-360 默认的frame_id一般是livox_frame如果你把雷达固定在车体上使用点云前必须通过 TF 发布从livox_frame到base_link或map的外参变换。外参不准确后面做的一切都建立在错误坐标上。另一个隐藏信息是 IMU。Mid-360 内置了 IMUlivox_ros_driver2会单独发布/livox/imu话题IMU 数据在 FAST-LIO 这类紧耦合 SLAM 里会直接参与状态估计在 Cartographer 里也能作为位姿预测的来源。建图前最好确认 IMU 话题频率正常并且 IMU 的坐标系和雷达坐标系的变换关系标定无误。2.3 单回波、双回波与点频影响占用率和处理时序Mid-360 默认工作在单回波模式每秒约 200k 点10Hz 下每帧大约 2 万个点。如果硬件支持并切换为双回波模式输出点频会成倍增加每帧点数可能到 4 万甚至更多。但这里要注意点云格式本身没有变化字段还是一样的只是数据量更大带宽和 CPU 占用会明显上升。对于只做建图的场景默认单回波通常就够用做感知或需要处理雨雾、遮挡边缘时双回波能提供更多回波信息但也要接受更高的处理成本。点频还影响offset_time的时间分布。单回波和双回波模式下一帧内点的时间跨度都接近 100ms但点数不同意味着每两个点之间的时间间隔不同。做运动补偿时不能假设一帧内点是均匀分布的最好逐点读取offset_time计算相对运动量。另外从数据带宽角度看20 万点/秒的 PointCloud2 消息体积约是每秒 20 万乘以 13 字节x/y/z/reflectivity 各 4 字节加 tag/line/offset_time 共 4 字节再加消息头实际量级在 3~5MB/s千兆网完全扛得住但如果你用 ROS2 的默认 QoS 订阅高频大点云丢帧风险很高所以订阅时要用SensorDataQoS()这点后面代码里会体现。3. 数据提取实战从ROS2话题到PCD全流程3.1 环境准备与驱动部署先把环境搭好。我以 Ubuntu 22.04 ROS2 Humble 为例终端里逐条执行# 安装基础依赖 sudo apt install ros-humble-pcl-ros ros-humble-pcl-conversions Livox Mid-360点云格式全解析：字段含义、数据提取与避坑指南
做移动机器人感知的同行应该都有这种体会第一次在 ROS2 里跑通 Livox-Mid-360 的官方驱动看到/livox/lidar话题里 PointCloud2 消息的字段列表时第一反应往往是“x、y、z 好说reflectivity 也能猜个大概但tag、line、offset_time到底是什么”如果这些点云格式细节不搞清楚后面做滤波、时间戳补偿、保存点云、跑 SLAM 建图都会踩一堆莫名其妙的坑。这篇文章我就把 Mid-360 的点云格式彻底拆开从硬件特性讲到字段定义再给出一套能直接搬走的数据提取流程最后整理连接设备、修改 IP、建图飘移等高频问题的排查方法。手里有 Mid-360、正在做点云处理或 SLAM 的同学可以直接对照着操作。1. Mid-360这套点云格式为什么值得单独拆开讲1.1 非重复扫描带来的格式差异Mid-360 算得上是 Livox 家族里比较特殊的一员。它采用非重复扫描方式水平视场角是完整的 360°垂直视场角是 59°-7° 到 52°最远探测距离在 90% 反射率目标下能到 90 米10% 反射率下约 40 米精度标称 ±3cm默认 10Hz 帧率下每秒输出约 20 万个点。很多第一次用它的人会下意识拿机械式激光雷达的“线数”去套它结果发现完全对不上因为 Mid-360 根本不存在固定的线束编号。这个硬件特性直接决定了点云格式的设计思路。机械雷达输出点云时每个点天然携带“第几线”这个信息所以数据结构里通常就是一个ring或者line就够了但 Mid-360 是光学棱镜加电机做非重复扫描每一帧内扫描轨迹会不断改变点云不再按固定线束排列。为了把点云描述清楚驱动层就必须额外引入一些字段来记录每个点的时间偏移、分类标签、回波来源等信息这就形成了我们看到的 Livox 特有的一套点结构。可以说理解这套格式本质上是在理解“非重复扫描雷达怎么表达一帧点云”。这种设计带来的一个直接好处是单帧点云在空间上的覆盖更均匀而且只要持续扫描一段时间比如 0.1 秒到 0.2 秒视场内的点云密度会显著增加这对建图、目标检测非常有利。但它也带来一个麻烦点与点之间的时间戳不是线性的因为棱镜扫描路径是类利萨茹曲线每一帧内点的生成顺序和空间位置没有严格的“从上到下”关系。所以驱动用offset_time来表示每个点相对帧起始时刻的偏移这是 Mid-360 点云格式里最需要重视的字段之一。1.2 完整工具链选型ROS2还是SDK直连做数据提取之前先要把工具链选型想清楚。我目前的方案是基于 Ubuntu 22.04 ROS2 Humble livox_ros_driver2 PCL 这套组合原因是实际项目里你大概率要接 Cartographer、FAST-LIO 或者自己的建图算法而以 ROS2 话题形式接收点云是最省事、最通用的方式。官方驱动已经把 UDP 数据包解析、坐标系定义、IMU 数据发布都处理好了我们只需要订阅/livox/lidar话题就能拿到组织好的点云。当然如果做的是嵌入式或者自研系统不想依赖 ROS也可以直接用官方 Livox SDK 2 的 C 接口在回调里拿原始点云结构体。但这样做的话时间戳同步、帧头拼接、丢包重传这些底层逻辑都要自己处理开发成本明显更高。对于大多数做导航、建图、感知的同学我建议直接走 ROS2 加官方驱动这条路线把精力放在业务算法上而不是重复造轮子。另外提醒一句livox_ros_driver2本身依赖livox_sdk2编译时还会用到 PCL 和 Eigen环境一定要提前装好。很多人在colcon build阶段报错基本都是缺依赖后面我会给出具体的安装命令。1.3 解析的整体思路从字节流到可用的点从传感器到最终能用的点云中间经历的过程可以理解成一条数据链Mid-360 通过网口把自定义协议的 UDP 数据包发出来驱动里的 SDK 负责解析数据包把原始字节还原成带坐标、反射率、标签的 Lidar 点结构再按帧封装成 PointCloud2 消息发布到 ROS2 话题上。我们从 ROS2 拿来 PointCloud2 之后还需要做一次“格式转换”因为 PointCloud2 本质上只是一段字节流加一组字段描述要真正做点云运算得转成 PCL 点云或者自定义结构体。解析整体的思路就是三步走先认识硬件特性搞清楚数据从哪来再逐字段拆解 PointCloud2 里每个字段的物理含义最后写代码把消息转成自己需要的点云类型并保存。后面几节我就按这个思路展开。2. 点云格式核心细节拆解字段没搞懂后面全白搭2.1 LivoxPointXyzrtl结构体逐字段拆解livox_ros_driver2里默认使用的是一个叫LivoxPointXyzrtl的结构体定义大致如下struct LivoxPointXyzrtl { float x; // X坐标单位m float y; // Y坐标单位m float z; // Z坐标单位m float reflectivity; // 反射率范围约0~255 uint8_t tag; // 点分类标签 uint8_t line; // 虚拟线号 uint16_t offset_time; // 相对帧起始时刻的偏移单位us };每个字段的含义可以整理成下面这张表字段类型单位含义使用建议x / y / zfloatm点云三维坐标直接用注意坐标系方向reflectivityfloat0~255目标反射率可视化、滤波但别指望它是标定后的物理量taguint8_t无0正常 1雨 2尘 3地面 4低反射预处理过滤非常好用lineuint8_t无虚拟线号别拿它当机械雷达的ring用offset_timeuint16_tus相对帧起始时间偏移去畸变和多传感器融合必须用先讲reflectivity。Mid-360 的反射率是驱动层根据回波强度归一化出来的一个值范围大致在 0 到 255 之间白色墙、高反射率标靶的值会比较高黑色车辆、深色织物则很低。但它不是一个严格物理定标后的反射率数值受距离、入射角影响很大所以做阈值过滤时不要从某个全局固定值上一刀切。我实测下来同样一块黑白棋盘格放在 2 米和 15 米处反射率值会有明显差异这在做目标检测数据清洗时要特别注意。然后是tag字段这是 Livox 点云里很实用的一个设计。SDK 会尝试对每个点做分类常见分类包括正常点、雨滴、灰尘、地面点、低反射率点等。实际使用中用这一位就能快速滤除大部分雨雾噪点比单纯用反射率阈值更稳因为雨滴和灰尘在某个距离范围内可能表现出较高反射率直接按反射率滤会误删目标点。后面问题排查部分我会给出具体过滤代码。line字段是很多新手容易误解的地方。Mid-360 没有物理线束这个字段严格来说是驱动为兼容协议而保留的虚拟线号。我遇到的情况是在某些固件版本下 Mid-360 的line值会一直为 0 或变化规律不明显所以如果你要跑依赖 ring 编号的地面分割算法需要先确认当前固件输出是否可靠不要默认它能像机械雷达那样用。最后是offset_time它记录了这个点相对当前帧数据起始时刻的时间偏移单位微秒。这个字段对于运动畸变矫正非常关键因为一帧 20 万个点并不是同一时刻采集的而是分布在 100ms 的扫描周期内如果忽略时间偏移把所有点当成同一时刻的数据车一动起来点云就会出现轻微拖影。2.2 时间戳、坐标系与IMU数据里真正值钱的隐藏信息坐标字段虽然直观但真正决定点云能不能用于建图融合的是时间戳和坐标系。ROS2 的 PointCloud2 消息里有一个header.stamp它表示帧起始时间而每个点自己的绝对时间应该是header.stamp offset_time * 1us。注意offset_time是uint16_t最大能表示 65535 微秒约 65.5ms刚好够覆盖 10Hz 的一帧周期这也是为什么帧率变化时它需要重新对齐。时间戳的来源取决于驱动和硬件配置。如果雷达启用了 PTP 或 PPS 时间同步header.stamp会基于雷达的硬件时钟精度很高如果完全没有外部同步驱动会用主机收到数据包的时间作为基准。后者在电脑负载高、网卡中断延迟大的时候会有抖动对低速场景影响不大但做高速移动或紧耦合融合时最好还是上 PTP 同步。坐标系同样容易踩坑。Mid-360 默认的frame_id一般是livox_frame如果你把雷达固定在车体上使用点云前必须通过 TF 发布从livox_frame到base_link或map的外参变换。外参不准确后面做的一切都建立在错误坐标上。另一个隐藏信息是 IMU。Mid-360 内置了 IMUlivox_ros_driver2会单独发布/livox/imu话题IMU 数据在 FAST-LIO 这类紧耦合 SLAM 里会直接参与状态估计在 Cartographer 里也能作为位姿预测的来源。建图前最好确认 IMU 话题频率正常并且 IMU 的坐标系和雷达坐标系的变换关系标定无误。2.3 单回波、双回波与点频影响占用率和处理时序Mid-360 默认工作在单回波模式每秒约 200k 点10Hz 下每帧大约 2 万个点。如果硬件支持并切换为双回波模式输出点频会成倍增加每帧点数可能到 4 万甚至更多。但这里要注意点云格式本身没有变化字段还是一样的只是数据量更大带宽和 CPU 占用会明显上升。对于只做建图的场景默认单回波通常就够用做感知或需要处理雨雾、遮挡边缘时双回波能提供更多回波信息但也要接受更高的处理成本。点频还影响offset_time的时间分布。单回波和双回波模式下一帧内点的时间跨度都接近 100ms但点数不同意味着每两个点之间的时间间隔不同。做运动补偿时不能假设一帧内点是均匀分布的最好逐点读取offset_time计算相对运动量。另外从数据带宽角度看20 万点/秒的 PointCloud2 消息体积约是每秒 20 万乘以 13 字节x/y/z/reflectivity 各 4 字节加 tag/line/offset_time 共 4 字节再加消息头实际量级在 3~5MB/s千兆网完全扛得住但如果你用 ROS2 的默认 QoS 订阅高频大点云丢帧风险很高所以订阅时要用SensorDataQoS()这点后面代码里会体现。3. 数据提取实战从ROS2话题到PCD全流程3.1 环境准备与驱动部署先把环境搭好。我以 Ubuntu 22.04 ROS2 Humble 为例终端里逐条执行# 安装基础依赖 sudo apt install ros-humble-pcl-ros ros-humble-pcl-conversions