速腾禾赛激光雷达点云格式转换：适配LIO-SAM与FAST-LIO2实战

激光雷达点云格式转换这件事，说大不大，说小也真不小。我见过太多人，雷达装好了、驱动跑通了、rostopic echo也能看到数据在刷，结果一接到 LIO-SAM 或者 FAST-LIO2 上就傻眼——要么直接报字段缺失，要么建出来的图飘得亲妈都不认识。问题往往不在算法本身，而是卡在最前面那一环：点云格式没对上。速腾聚创和禾赛这两家的雷达在市面上保有量极大，但它们的 ROS 驱动吐出来的点云结构、时间字段命名、坐标系定义各有各的习惯，而 LIO-SAM 和 FAST-LIO2 这两个主流激光SLAM框架对输入点云的要求又各不相同。这篇内容就是把我自己在速腾和禾赛雷达上做格式转换、适配这两个框架的完整过程拆开来讲，从点云字段的底层结构到转换代码的每一行逻辑，再到实测中遇到的坑和解决办法，尽量说透。不管你是刚拿到雷达的新手，还是已经跑通建图但想搞清楚底层细节的老手，应该都能从中找到有用的东西。

1. 先搞清楚两家雷达的点云到底长什么样

很多人拿到雷达驱动之后，直接就把 topic 接到 SLAM 节点上了，根本没看过点云里到底有哪些字段。这一步偷懒，后面就要用几倍的时间来还债。速腾和禾赛的 ROS 驱动输出的sensor_msgs/PointCloud2消息，虽然顶层类型一样，但里面的字段定义差别不小，而这些差别恰恰是导致 SLAM 框架报错或建图异常的根源。

1.1 速腾聚创点云的消息结构

速腾的 ROS 驱动（以 rslidar_sdk 为例）默认输出的点云格式通常是XYZI或者XYZIRT，取决于你选的输出模式。所谓XYZI，就是每个点包含 x、y、z 三个空间坐标加一个 intensity 强度值，每个字段一般是FLOAT32类型，单个点占 16 个字节。而XYZIRT在此基础上多了两个字段：ring（也叫 channel，表示这个点属于哪条激光线束）和timestamp（该点的精确采集时间），单个点占 24 个字节（有的版本 timestamp 用 FLOAT64，那就是 32 字节）。

这里有个很容易被忽略的细节：速腾不同型号的雷达，ring 的编号方式可能不一样。比如 RS-16 的 ring 是从 0 到 15，而有些型号是从 1 开始编号的。这个差异在单雷达建图时影响不大，但如果你做多雷达融合，ring 编号冲突就会导致特征提取出问题。

另外，速腾的 timestamp 字段，在早期驱动版本里是每个点相对于该帧起始时刻的偏移量（单位秒），后来有些版本改成了绝对时间戳。这个区别非常关键，因为 LIO-SAM 对时间戳的处理逻辑是强依赖的，如果你的 timestamp 是相对偏移而 LIO-SAM 以为是绝对时间，那整个 IMU 预积分和点云去畸变都会错得离谱。

1.2 禾赛点云的消息结构

禾赛的 ROS 驱动（hesai_lidar 或 hesai_ros_driver）输出的点云格式一般是XYZIRT，字段包括 x、y、z、intensity、ring、timestamp。看起来和速腾的XYZIRT差不多？但魔鬼在细节里。

禾赛的 timestamp 字段通常是FLOAT64类型，表示的是绝对时间（Unix 时间戳，单位秒），精确到微秒级别。而速腾的 timestamp 在很多配置下是FLOAT32，表示相对时间偏移。这两种时间语义完全不同，直接混用必然出问题。

禾赛的 ring 字段编号通常从 0 开始，按照激光线束的物理排列顺序递增。以 Pandar40 为例，ring 从 0 到 39；AT128 则是 0 到 127。这个编号方式本身没问题，但当你把禾赛的点云喂给 FAST-LIO2 时，如果 FAST-LIO2 的配置里没有正确处理 ring 字段，它可能会忽略这个信息，导致特征提取时无法区分不同线束的点，影响建图精度。

还有一点，禾赛的点云在默认配置下可能包含无效点（距离为 0 或 NaN 的点），这些点如果不滤掉，进入 SLAM 框架后会污染最近邻搜索，导致配准失败或者建图出现噪点。

1.3 两个 SLAM 框架对点云的真实需求

LIO-SAM 对输入点云的要求比较明确：它需要XYZI格式的点云，并且需要ring字段来做特征提取。时间戳方面，LIO-SAM 期望点云消息的 header.stamp 是该帧的起始采集时间，同时每个点的 timestamp 字段用于运动补偿（去畸变）。如果你用的是XYZI格式（没有逐点 timestamp），LIO-SAM 会退化为假设一帧内所有点在同一时刻采集，对于低速场景勉强能用，但快速运动时建图会明显飘。

FAST-LIO2 的要求又不一样。它支持XYZI和XYZIRT两种输入，但更推荐XYZIRT，因为它需要逐点时间戳来做精确的运动补偿。FAST-LIO2 对 ring 字段的依赖没有 LIO-SAM 那么强，但如果你要做基于线束的特征提取（比如提取地面点、边缘点），ring 就必不可少了。另外，FAST-LIO2 对点云的密度和分布比较敏感，如果点云中包含大量无效点，它的 ikd-Tree 构建效率会大幅下降。

总结一下，两家雷达的原始点云和两个框架的需求可以用下面这张表来对照：

这张表是我在实际适配过程中反复验证后总结的，不同型号和驱动版本可能有细微差异，但大方向是一致的。搞清楚这些差异之后，转换的思路就清晰了：把两家雷达的输出统一成目标框架需要的格式，该补的字段补上，该改的类型改掉，该滤的噪点滤掉。

2. 格式转换的核心逻辑与代码实现

格式转换这件事，听起来像是简单的字段映射，但真正写起来，坑比想象的多。我一开始也觉得不就是改个字段名吗，结果调了整整两天才跑通。下面把转换的核心逻辑和代码实现拆开讲，包括每一步为什么要这么做。

2.1 转换的整体思路：统一到中间格式

我的做法是先把两家雷达的点云统一转换成一个中间格式，然后再从这个中间格式分别适配 LIO-SAM 和 FAST-LIO2。这样做的好处是，如果你手头同时有速腾和禾赛的雷达，或者以后换了雷达型号，只需要改最前面那一层解析逻辑，后面的适配代码不用动。

中间格式我定义为：x, y, z, intensity, ring, time，其中 time 统一为相对于该帧起始时刻的偏移量，单位秒，类型 FLOAT32。ring 统一从 0 开始编号。这个格式兼顾了两个框架的需求，也方便后续扩展。

转换的流程大致是：订阅原始点云 topic → 解析 PointCloud2 的字段 → 逐点提取并转换 → 组装成新的 PointCloud2 → 发布到新 topic。整个过程在一个 ROS 节点里完成，用 C++ 写性能最好，Python 也能用但大点云下会有延迟。

2.2 解析 PointCloud2 的字段偏移

sensor_msgs/PointCloud2这个消息类型的设计比较底层，它把所有点的数据放在一个大的二进制 buffer 里，通过 fields 数组来描述每个字段的名称、偏移量、数据类型和数量。要正确解析，必须严格按照 fields 里的 offset 来读取，不能想当然地按顺序读。

举个例子，速腾的XYZIRT格式，fields 可能是这样的：

// 速腾 XYZIRT 的 fields 定义（示意） fields[0]: name="x", offset=0, datatype=FLOAT32, count=1 fields[1]: name="y", offset=4, datatype=FLOAT32, count=1 fields[2]: name="z", offset=8, datatype=FLOAT32, count=1 fields[3]: name="intensity", offset=12, datatype=FLOAT32, count=1 fields[4]: name="ring", offset=16, datatype=UINT16, count=1 fields[5]: name="timestamp", offset=18, datatype=FLOAT32, count=1

注意 ring 是 UINT16 类型，占 2 个字节，timestamp 的 offset 是 18 而不是 20，因为前面 ring 只占了 2 字节。如果你按 4 字节对齐去读，timestamp 就会读错。这种细节在官方文档里往往不会强调，但不注意就会导致数据错乱。

禾赛的 fields 定义又不同，timestamp 是 FLOAT64，offset 也不一样。所以解析代码必须动态读取 fields 数组，根据 name 找到对应的 offset 和 datatype，而不是硬编码偏移量。

2.3 时间戳的归一化处理

时间戳的处理是转换中最容易出错的地方。速腾的相对时间偏移和禾赛的绝对时间戳，需要统一成同一种语义。我的做法是：不管原始 timestamp 是什么类型和语义，统一转换成相对于该帧 header.stamp 的偏移量。

对于速腾的相对时间偏移，如果它本身就是相对于帧起始时刻的，那直接用就行。但要注意单位，有的驱动输出的是秒，有的是毫秒，还有的是微秒。这个必须查驱动文档或者实际打印几个值来判断。我遇到过一种情况，速腾某版本的驱动输出的 timestamp 单位是毫秒，但字段类型是 FLOAT32，值域在 0 到 100 之间，如果不注意，直接当秒用，去畸变就会完全失效。

对于禾赛的绝对时间戳，需要减去该帧的 header.stamp 才能得到相对偏移。这里有个精度问题：禾赛的 timestamp 是 FLOAT64，header.stamp 是 ROS 的 time 类型（sec + nsec），做减法时要注意精度损失。我的做法是先把两者都转成微秒级的整数再相减，最后转回秒的浮点数，这样精度损失最小。

// 禾赛绝对时间戳转相对偏移的示例 double abs_time = point_timestamp; // FLOAT64 绝对时间，单位秒 double frame_time = msg->header.stamp.toSec(); float relative_time = static_cast<float>(abs_time - frame_time); // 注意：如果精度不够，可以改用微秒整数运算

还有一个坑：如果点云的 header.stamp 设置得不准确（比如用了接收时刻而不是采集时刻），那即使逐点 timestamp 是对的，相对偏移也会整体偏移。所以最好确认驱动是否正确设置了 header.stamp。

2.4 组装新的 PointCloud2 消息

解析和转换完每个点的数据之后，需要重新组装成一个sensor_msgs/PointCloud2消息。这一步的关键是正确设置 fields、point_step、row_step 和 data 数组。

point_step 是每个点占用的字节数，必须等于所有字段大小之和，并且要考虑内存对齐。比如x, y, z, intensity都是 FLOAT32（各 4 字节），ring 是 UINT16（2 字节），time 是 FLOAT32（4 字节），那 point_step 就是 4+4+4+4+2+4 = 22 字节。但有些框架或库可能要求 4 字节对齐，那就需要 padding 到 24 字节。这个要看目标框架的具体要求，LIO-SAM 和 FAST-LIO2 一般对 padding 不敏感，但为了性能，建议对齐。

// 组装 PointCloud2 的关键代码片段 sensor_msgs::PointCloud2 output; output.header = input->header; output.height = 1; output.width = num_points; output.is_bigendian = false; output.is_dense = false; // 定义字段 sensor_msgs::PointField field; field.name = "x"; field.offset = 0; field.datatype = sensor_msgs::PointField::FLOAT32; field.count = 1; output.fields.push_back(field); // ... 依次添加 y, z, intensity, ring, time output.point_step = 22; // 或 24（对齐后） output.row_step = output.point_step * output.width; output.data.resize(output.row_step * output.height); // 逐点写入 for (size_t i = 0; i < num_points; ++i) { float* ptr = reinterpret_cast<float*>(&output.data[i * output.point_step]); ptr[0] = x; ptr[1] = y; ptr[2] = z; ptr[3] = intensity; uint16_t* ring_ptr = reinterpret_cast<uint16_t*>(&output.data[i * output.point_step + 16]); *ring_ptr = ring; float* time_ptr = reinterpret_cast<float*>(&output.data[i * output.point_step + 18]); *time_ptr = relative_time; }

这段代码看起来简单，但实际写的时候，offset 的计算必须和 fields 里定义的一致，否则数据就会错位。我建议在写完之后，用pcl::fromROSMsg把转换后的点云转成 PCL 格式，打印几个点的值，和原始点云对比，确认转换正确。

3. 适配 LIO-SAM 的完整操作链路

LIO-SAM 是我个人比较喜欢的一个框架，它的模块化设计很清晰，建图效果也稳定。但它对输入数据的要求比较严格，格式不对就直接罢工。下面把适配 LIO-SAM 的完整链路讲清楚。

3.1 LIO-SAM 的输入接口分析

LIO-SAM 的核心节点是imageProjection，它订阅的点云 topic 默认是/points_raw，消息类型是sensor_msgs/PointCloud2。在imageProjection.cpp里，它通过pcl::fromROSMsg把点云转成pcl::PointXYZI，然后做去畸变和特征提取。

关键来了：LIO-SAM 在去畸变时，需要每个点的时间信息。它读取时间的方式是查找点云中名为time或t或timestamp的字段（不同版本可能不同）。如果你的点云里没有这个字段，或者字段名不对，LIO-SAM 就会用默认值 0，导致去畸变失效。

另外，LIO-SAM 的特征提取依赖 ring 字段来区分不同线束。它在代码里通过ring字段来判断点的线束编号，进而提取边缘点和平面点。如果你的点云没有 ring 字段，特征提取会退化成把所有点当成同一线束处理，建图精度会明显下降。

3.2 转换节点的参数配置

我写了一个通用的转换节点，通过参数来适配不同的雷达和框架。对于 LIO-SAM，关键参数如下：

# 转换节点参数配置（适配 LIO-SAM） input_topic: "/rslidar_points" # 原始点云 topic output_topic: "/points_raw" # LIO-SAM 订阅的 topic input_format: "velodyne" # 输入格式：velodyne / hesai / robosense output_format: "lio_sam" # 输出格式：lio_sam / fast_lio time_field_name: "time" # 输出点云的时间字段名 ring_start_index: 0 # ring 起始编号 filter_invalid_points: true # 是否滤除无效点

这里input_format决定了用哪套解析逻辑，output_format决定了输出点云的字段布局。对于 LIO-SAM，输出点云的字段名建议用time，因为 LIO-SAM 的代码里默认查找这个名称。

ring_start_index这个参数容易被忽略。如果你的速腾雷达 ring 从 1 开始编号，而 LIO-SAM 期望从 0 开始，那就需要在这里做偏移。我遇到过一台 RS-16，ring 从 1 到 16，直接喂给 LIO-SAM 后，特征提取把第 16 线的点当成了不存在的线束，导致边缘点提取异常。后来把 ring 统一减 1 就正常了。

3.3 实测中的建图效果对比

为了验证转换的效果，我用同一段数据做了对比测试：一段是速腾 RS-16 采集的园区道路数据，分别用原始点云（未转换）和转换后的点云喂给 LIO-SAM，其他配置完全一致。

未转换的原始点云，LIO-SAM 能跑起来，但建图结果在转弯处有明显的重影，回环检测也经常失败。分析原因是去畸变没有生效，因为原始点云的 timestamp 字段名是timestamp而 LIO-SAM 找的是time，导致时间信息丢失。

转换后的点云，建图轨迹平滑，回环检测成功率明显提升。特别是在快速转弯的路段，重影基本消失。这说明逐点时间戳对 LIO-SAM 的去畸变确实至关重要。

还有一个细节：LIO-SAM 对点云的密度比较敏感。如果点云太密（比如禾赛 AT128 的原始点云），LIO-SAM 的处理速度会明显下降，甚至丢帧。我的做法是在转换节点里加一个降采样，用体素滤波把点云降到合适的密度。体素大小一般设 0.2 到 0.5 米，具体看场景。园区道路用 0.3 米效果不错，室内场景可以小一点。

4. 适配 FAST-LIO2 的差异化处理

FAST-LIO2 和 LIO-SAM 虽然都是激光惯性里程计，但它们对输入数据的处理方式差别不小。FAST-LIO2 基于 ikd-Tree 做增量式地图管理，对点云的实时性和密度要求更高，格式转换时需要注意的点也不一样。

4.1 FAST-LIO2 对时间戳的特殊要求

FAST-LIO2 在去畸变时，对时间戳的精度要求比 LIO-SAM 更高。它假设每个点的时间戳是相对于该帧起始时刻的偏移量，单位秒，类型可以是 FLOAT32 或 FLOAT64。如果你的时间戳精度不够（比如用 FLOAT32 表示绝对时间），去畸变就会产生误差。

我在适配禾赛 AT128 时遇到过这个问题：禾赛的原始 timestamp 是 FLOAT64 绝对时间，我一开始直接转成 FLOAT32 相对偏移，结果在高速运动时建图出现轻微飘移。后来改成先用 FLOAT64 计算相对偏移，再转成 FLOAT32 输出，精度就够了。原因是 FLOAT32 在表示较大的绝对时间时有效位数不够，但表示小范围的相对偏移时精度是足够的。

另外，FAST-LIO2 对 header.stamp 的准确性要求也高。它用 header.stamp 来做 IMU 和激光的时间对齐。如果 header.stamp 偏差超过几毫秒，IMU 预积分就会和激光点云对不上，导致建图飘移。所以转换节点里最好不要修改 header.stamp，直接透传原始值。

4.2 ring 字段在 FAST-LIO2 中的处理策略

FAST-LIO2 本身对 ring 字段的依赖没有 LIO-SAM 那么强，它的特征提取主要基于局部几何特征，而不是线束编号。但这不意味着 ring 可以随便处理。

如果你的点云里 ring 字段的值域很大（比如禾赛 AT128 的 ring 从 0 到 127），而 FAST-LIO2 的某些配置里对 ring 的范围有限制，就可能导致问题。我一般建议在转换时把 ring 归一化到合理的范围，或者直接保留原始值但确保类型正确（UINT16 足够表示大多数雷达的线束数）。

还有一个实际经验：FAST-LIO2 在处理没有 ring 字段的点云时，会自动把所有点的 ring 设为 0。这本身不会导致报错，但如果你后续要做基于线束的点云分割（比如提取地面点），没有 ring 就会很麻烦。所以即使 FAST-LIO2 不强制要求 ring，我也建议在转换时保留这个字段。

4.3 点云降采样与无效点滤除的实操参数

FAST-LIO2 对点云密度比 LIO-SAM 更敏感。点云太密，ikd-Tree 的构建和查询会变慢，实时性下降；点云太稀，特征提取不够，建图精度下降。所以降采样是必须的。

我的做法是在转换节点里做两级处理：先用距离滤波去掉太近和太远的点（比如小于 0.5 米和大于 100 米的点），再用体素滤波降采样。体素大小根据雷达型号和场景调整：

无效点的滤除也很关键。禾赛的点云里经常有距离为 0 或 NaN 的点，这些点如果不滤掉，进入 FAST-LIO2 后会污染 ikd-Tree，导致最近邻搜索返回错误结果。滤除的方法很简单：在逐点转换时判断距离是否有效，无效就跳过。

// 无效点滤除示例 float range = std::sqrt(x*x + y*y + z*z); if (range < min_range || range > max_range || std::isnan(x) || std::isnan(y) || std::isnan(z)) { continue; // 跳过无效点 }

这里min_range一般设 0.5 米，max_range根据雷达型号设 50 到 200 米不等。太近的点可能是雷达自身的噪声，太远的点信噪比低，都不适合用于建图。

5. 踩过的坑与排查思路

这一部分是我觉得最有价值的内容，因为这些都是文档里不会写、只有实际跑过才会遇到的问题。每个坑我都尽量还原当时的排查过程，方便你遇到类似问题时参考。

5.1 建图飘移的排查链路

建图飘移是最常见的问题，但原因可能有很多。我的一般排查顺序是：先看时间戳，再看外参，最后看点云质量。

有一次用禾赛 Pandar40 跑 FAST-LIO2，建图在直道上还好，一转弯就飘。我先检查了时间戳，发现转换后的相对时间偏移都是对的。然后检查外参，雷达和 IMU 的外参是标定过的，应该没问题。最后把原始点云和转换后的点云分别可视化，发现转换后的点云里有一批点的 z 坐标异常，明显偏离了地面。

进一步排查发现，禾赛的原始点云里有一批点的距离值是负数（表示无效），我在转换时没有滤掉，直接保留了。这些负距离的点转换后 z 坐标变成了很大的负值，进入 FAST-LIO2 后被当成地面点，导致地面拟合错误，进而影响建图。加上无效点滤除后，问题解决。

这个坑的教训是：不要假设原始点云都是有效的，一定要做有效性检查。

5.2 字段类型不匹配导致的诡异报错

还有一个坑是字段类型不匹配。速腾某版本的驱动输出的 ring 字段是 UINT8 类型，而我在转换代码里按 UINT16 读取，结果读出来的 ring 值全是乱的。因为 UINT8 只占 1 字节，我按 2 字节读，把相邻的 timestamp 低字节也读进来了。

这种问题的排查方法是：打印原始点云的 fields 定义，确认每个字段的 datatype 和 offset。不要凭经验假设，不同驱动版本可能不一样。

// 打印 fields 定义的调试代码 for (const auto& field : msg->fields) { ROS_INFO("Field: %s, offset: %d, datatype: %d, count: %d", field.name.c_str(), field.offset, field.datatype, field.count); }

这段代码在调试阶段非常有用，建议在转换节点里加一个 debug 开关，打开时打印 fields 信息。

5.3 多雷达场景下的 ring 冲突

如果你同时用两台雷达（比如一台速腾加一台禾赛），ring 冲突是必须处理的问题。两台雷达的 ring 都从 0 开始，直接合并会导致线束编号重复，特征提取时无法区分哪些点来自哪台雷达。

我的做法是在转换时为不同雷达的 ring 加不同的偏移。比如速腾的 ring 保持 0 到 15，禾赛的 ring 加 16，变成 16 到 55。这样合并后的点云里，ring 编号唯一，特征提取就能正确区分。

这个偏移量需要根据实际使用的雷达线束数来定，确保不重叠。如果线束数很多（比如两台 AT128），ring 值域会很大，但 UINT16 足够表示，不用担心溢出。

6. 转换节点的性能优化与工程化建议

格式转换节点虽然逻辑不复杂，但在实际部署中，性能问题不容忽视。特别是高线束雷达（如禾赛 AT128），单帧点云可能有十几万个点，如果转换效率不高，会成为整个系统的瓶颈。

6.1 减少内存拷贝的技巧

ROS 的 PointCloud2 消息在发布和订阅时，默认会做一次内存拷贝。对于大点云，这个拷贝开销不小。我的做法是使用nodelet或者intra-process communication来减少拷贝。如果条件不允许，至少在转换节点内部避免不必要的拷贝。

具体来说，解析原始点云时，直接用指针读取 data 数组，不要先把 data 转成 vector 再处理。组装新点云时，一次性 resize 好 data 数组，然后逐点写入，不要频繁 push_back。

// 高效的内存操作示例 output.data.resize(num_valid_points * output.point_step); uint8_t* dst = output.data.data(); for (size_t i = 0; i < num_valid_points; ++i) { // 直接写入 dst，避免中间拷贝 memcpy(dst, &point_data, output.point_step); dst += output.point_step; }

6.2 多线程与流水线处理

如果单线程转换跟不上雷达的出帧率，可以考虑多线程。一个线程负责解析原始点云，另一个线程负责组装和发布。两者之间用无锁队列或者双缓冲来传递数据。

不过要注意，多线程会引入线程安全问题，特别是 ROS 的消息回调本身可能在不同线程里执行。我的建议是先用单线程跑，确认性能瓶颈确实在转换节点上，再考虑多线程优化。很多时候，瓶颈其实在 SLAM 算法本身，而不是转换节点。

6.3 参数化配置与多雷达适配

最后一点工程化建议：把转换节点做成高度参数化的，通过 YAML 配置文件来适配不同的雷达和框架。这样换雷达或者换框架时，只需要改配置，不用重新编译代码。

我目前的配置结构是这样的：

# 雷达配置 lidar: type: "robosense" # robosense / hesai model: "RS-16" input_topic: "/rslidar_points" ring_start: 0 time_unit: "seconds" # seconds / milliseconds / microseconds # 输出配置 output: topic: "/points_raw" format: "lio_sam" # lio_sam / fast_lio time_field: "time" ring_offset: 0 # 滤波配置 filter: min_range: 0.5 max_range: 100.0 voxel_size: 0.3 filter_invalid: true

这套配置在我用过的几种雷达和框架组合上都能跑通，切换时只需要改几行 YAML，非常方便。

7. 一些实测数据与效果验证

说了这么多理论，最后还是得看实际效果。我用速腾 RS-16 和禾赛 Pandar40 分别采集了同一段园区道路的数据，分别适配 LIO-SAM 和 FAST-LIO2，做了几组对比测试。

从建图轨迹的平滑度来看，转换后的点云在两个框架上都明显优于未转换的原始点云。特别是在快速转弯和上下坡路段，转换后的轨迹没有出现明显的跳变。从回环检测的成功率来看，LIO-SAM 在转换后基本能稳定检测到回环，而转换前经常失败。FAST-LIO2 本身对回环的依赖不强，但转换后的建图精度也有提升。

从 CPU 占用来看，转换节点本身的开销大约占单核的 10% 到 20%，对于高线束雷达会更高一些。如果加上降采样和滤波，开销会增加到 20% 到 30%。这个开销在大多数平台上是可以接受的，但如果你的计算平台资源紧张，可以考虑把转换和滤波分开到不同节点，或者用 GPU 加速。

我个人在实际操作中的体会是，格式转换这件事，看起来是脏活累活，但它决定了整个 SLAM 系统的上限。点云格式不对，后面的算法再优秀也发挥不出来。所以花时间把这一层做扎实，是非常值得的。另外，不同雷达和驱动的版本差异很大，遇到问题时不要凭经验假设，多打印、多对比、多验证，往往能更快定位问题。