RDKS100部署centerpoint模型

开发与问题
2

你好！针对你在 RDK S100 部署 CenterPoint 模型遇到的“PC 端推理正常，板端 HBM 推理无检测”问题，这是一个典型的端侧部署一致性问题。

根据社区已有的 CenterPoint 参考算法文档（【参考算法】地平线 Centerpoint 参考算法-V1.2.1）以及常见部署案例，问题通常集中在前处理对齐、输入数据格式、后处理阈值或量化精度损失上。

以下是针对性的排查步骤和建议：

核心排查方向

1. 检查 ROS2 节点的前处理逻辑 (最常见原因)

PC 端 infer_hbir.py 通常直接调用 Python 预处理脚本，而 ROS2 节点往往需要自己实现或调用 DSP 库进行体素化（Voxelization）。

  • 体素化参数对齐：确保 ROS2 节点中的 point_cloud_range、voxel_size、max_num_points、max_voxels 与训练 config 文件完全一致。任何一个浮点数精度差异都会导致特征图错位。
  • 归一化范围：CenterPoint 参考算法中对输入特征做了归一化（norm_range）。
    • 检查 ROS2 节点是否对 x, y, z, intensity 等维度做了相同的归一化处理？
    • 参考算法中默认归一化范围是 [-51.2, -51.2, -5.0, 0.0, 51.2, 51.2, 3.0, 255.0]（具体看你的 config）。如果板端没做归一化或范围不对，模型输入分布会偏移，导致置信度极低。
  • 数据维度顺序：
    • 确认输入 Tensor 的 Shape 是否为 (1, 5, max_voxels, max_points) 或 (1, 5, max_points, max_voxels)（参考算法中有过 H/W 维度转换优化）。
    • 确认 coors (体素坐标) 的生成逻辑是否与 PC 端一致（特别是坐标系的 origin 定义）。

2. 检查输入数据格式与坐标系

  • 点云维度：你提到是“自定义四维度数据集”。
    • 训练时如果是 4 维 (x,y,z,intensity)，但模型 Config 或板端输入配置成了 5 维（带时间戳 t），会导致通道错位。
    • 动作：检查编译生成的 HBM 模型的输入描述，确认通道数是 4 还是 5。ROS2 节点填充数据时，如果模型期待 5 维，你只填了 4 维，后面的数据会全部错位。
  • 坐标系转换：
    • PC 端可视化正常，说明点云本身没问题。但 ROS2 节点读取的点云坐标系（如 base_link 或 lidar_link）是否与模型训练时的坐标系一致？
    • CenterPoint 对位置非常敏感，如果点云整体偏移了 10 米，可能所有目标都跑出了 point_cloud_range 范围，导致检测为空。
    • 动作：在 ROS2 节点中打印一帧原始点云的 x, y 最大值和最小值，确认是否落在模型设定的检测范围内（如 [-51.2, 51.2]）。

3. 检查后处理阈值 (NMS & Score Threshold)

  • 置信度阈值：板端量化后，模型的输出分布可能发生变化。PC 端能检测到的阈值（如 0.1），在板端可能需要调整为 0.05 甚至更低。
    • 动作：暂时将后处理中的 score_threshold 调得非常低（如 0.01），看是否有输出。如果有但框很乱，说明是阈值问题；如果还是没有，说明是前处理或模型本身问题。
  • NMS 配置：检查板端后处理脚本中的 NMS 阈值是否与 PC 端一致。

4. 量化精度与模型转换验证

虽然你提到量化校准顺利，但“顺利”不代表“精度无损”。

  • 中间层对比：
    • 这是最硬核的排查方法。在 PC 端使用 infer_hbir.py 时，导出模型中间层（如 Backbone 输出、Heatmap 输出）的 Tensor 数据。
    • 在板端 ROS2 节点中，同样抓取对应层的输出数据。
    • 对比：计算两者的余弦相似度或均方误差。如果 Heatmap 输出差异巨大，说明前处理有问题；如果 Heatmap 相似但最后没框，说明后处理有问题。
  • Simulator 验证：
    • 使用工具链中的仿真工具（如 hrt_model_exec 或 Python 仿真脚本）在 PC 上模拟板端推理流程（加载 HBM 模型，使用与板端完全一致的预处理代码）。如果仿真也失败，说明是预处理代码写错了；如果仿真成功但板端失败，说明是板端环境或内存对齐问题。

建议的排查路径

  1. 第一步（最快验证）：

    • 在 ROS2 节点中，打印输入模型前的 Tensor 统计信息（Mean, Std, Max, Min）。
    • 在 PC 端 infer_hbir.py 中，打印同一帧数据输入模型前的 Tensor 统计信息。
    • 对比：如果两者差异明显（例如板端 Max 值是 PC 端的 10 倍，或者全是 0），直接定位到前处理代码。

  2. 第二步（参考官方实现）：

    • 地平线 OE 包中通常包含 CenterPoint 的参考 ROS2 节点或前处理库（DSP 库）。
    • 查看路径：ddk/samples/ai_benchmark/j5/qat/script/detection/centerpoint_pointpillar 或 ddk/samples/vdsp_rpc_sample。
    • 强烈建议：不要完全自己手写前处理，尽量复用官方提供的 pointpillars_preprocess 库或参考其参数配置。你的工具链版本是 v3.8.1，请确认该版本对应的参考代码路径。

  3. 第三步（可视化调试）：

    • 在板端 ROS2 节点中，将模型输出的 Heatmap 或原始 Box 结果发布为一个 Topic。
    • 在 PC 端通过 ros2 topic echo 或写一个简单的订阅节点，把板端的输出画出来。
    • 如果 Heatmap 全是接近 0 的值，肯定是前处理或模型权重问题；如果 Heatmap 有峰值但被过滤了，是后处理阈值问题。

关于 ROS2 节点参考

社区目前公开的完整 CenterPoint ROS2 源码较少，但你可以参考以下资源进行拼接：

  • 前处理参考：查阅 OE 包文档中关于 Voxelization 和 PillarFeatureNet 的 C++/DSP 实现说明。
  • 后处理参考：参考算法文档中 CenterPointPostProcess 的逻辑，确保 NMS 和阈值筛选逻辑一致。
  • 相关帖子：
    • 雷达点云预处理：这篇帖子详细介绍了 J5/RDK 上的点云前处理优化和 DSP 代码，务必阅读，里面提到了 centerpoint 预处理代码的文件名称修改和优化细节，可能你的版本正好对应这个变更。

总结

既然 infer_hbir.py (PC) 正常，说明模型权重和结构没问题。问题 90% 出在 ROS2 节点的前处理（体素化 + 归一化）与 PC 端 Python 脚本不一致。

优先检查：

  1. 输入特征的归一化范围 (norm_range) 是否硬编码错误？
  2. 点云坐标是否超出了 point_cloud_range？
  3. 是否复用了官方 DSP 库进行前处理？如果是手写的，建议切换为官方库测试。

如果需要更具体的代码片段对比，可以提供你 ROS2 节点中前处理部分的伪代码或关键参数配置。