RDK X5 YOLO 全链路工具集

要解决什么问题

把 Ultralytics 系 YOLO 从 x86+GPU 训练 落到 地瓜 RDK X5（bayes-e BPU） 上，常见卡点不在「能不能跑通脚本」，而在 ONNX 算子图、Detect head 结构 和 PTQ 校准分布 与 BPU 编译器的隐式假设不一致：unsupported op、量化 cosine 掉线、板端 forward 走 CPU fallback。

本技能面向 OpenExplore v1.2.8 / hb_mapper 1.24.x 工具链，覆盖 YOLOv5u / v8 / v9 / v11 / v13 / YOLO26 的检测、分割、姿态、OBB、分类等任务，并串到 TROS / ROS2（HobotDnn） 生产链路。

技能如何协作

Agent 按 训练环境（x86+GPU）→ 量化环境（x86 Linux）→ 板端（RDK X5 aarch64） 分阶段追问，未说明的环境不擅自假设；支持本机直跑或 SSH 远程执行。

典型主路径是 训练与量化在同一台 x86 机器：ONNX 不跨机，只有 *.bin 通过 scp 上板。

• 导出：export_monkey_patch.py 改写 Detect/Attention 前向，输出 BPU 友好的多 head ONNX，并保持 simplify=False，避免 layout 被折叠后编译器误判。
• 量化：mapper.py 驱动 PTQ（校准 .rgbchw、yaml 由脚本生成），对照官方中间产物与 cosine similarity 做验收，最终仍要以 mAP/recall 为准。
• 板端：Python 侧 NV12 letterbox + BPU 推理 + numpy 后处理（含 DFL 解码）；ROS2 侧配置 dnn_Parser（如 ultralytics_yolo）、hbmem topic 与摄像头/MIPI/回灌模式。

文档里单独的 「工艺原理速查」 解释 why：opset 10/11、NV12 _128 输入、校准集必须贴近真实场景、dnn_Parser 与 reg_max 对应关系等，便于定位根因而非反复试错。

适用边界

• v1.0 目标平台仅为 RDK X5；板端需 OS ≥ 3.5.0、dnn_node 等版本与 BPU 设备可用。
• 量化 cosine ≥0.8 只是官方下限，生产上建议更高并做量化 ONNX 与数据集评测；不能只看 cosine。
• TROS 配置勿照搬示例里面向厂内模型的 dnn_Parser；自训量化模型需与 parser、class_num、reg_max（YOLO26 为 1）一致。
• 国内网络、conda ToS、setuptools/Arial.ttf 等环境坑在技能里有明确 checklist，否则训练或 horizon_nn.build_onnx 阶段容易中断。