先明确主体定义：

• 芯片厂商：地瓜机器人（D-Robotics，地平线机器人产品线）
• 开源载体：GitHub 开源仓库（RDK Model Zoo、TogetheROS.Bot、各类 samples）、开发者社区论坛
• 开发者：分为高校学生、个人爱好者、机器人 / 工业视觉企业工程师、方案集成商

核心底层规则：

硬件 BPU 指令集、闭源工具链由厂商掌控；

上层应用案例、算法 Demo、业务方案开放共建。

结合之前研究的.bin 模型、RDK Model Zoo、X3/X5 硬件差异进行落地说明。

一、地瓜机器人（芯片原厂）核心职责【基座提供者】

一句话定位：搭建不可替代的底层技术底座，解决 “硬件能不能跑 AI” 的根本问题。

1. 硬件与底层闭源核心（不开放源码）

1. BPU 硬件架构（Bayes/Bayes-e）、芯片 IP、开发板硬件设计（RDK X3/X5/Ultra）；
2. OpenExplorer (OE) 工具链（hb_mapper）：模型量化、编译器、BPU 微指令生成器； ⚠️ 工具链二进制交付、不开源，负责把 ONNX 编译成平台专属.bin；
3. 板端底层 SDK：hrt_runtime、BPU 驱动、ISP、视频编解码硬件驱动；
4. RDK OS 系统镜像、BSP 板级支持包。

2. 官方开源项目维护（托管在 GitHub）

1. RDK Model Zoo：主导维护主干分支、新增主流模型 Demo（YOLO、分割、OCR）；
2. TogetheROS.Bot（TROS.B）机器人中间件、传感器驱动 Node、基础推理封装；
3. 发布标准 C++/Python 推理示例、官方文档、故障排查手册。

3. 生态运营与边界保障

1. 区分硬件分支：rdk_x3/rdk_x5，隔离 X3.bin与 X5.bin，规避跨硬件兼容坑；
2. 社区答疑、版本迭代、修复底层 SDK Bug；
3. 定义标准开发范式（NV12 输入、前后处理规范、模型编译 yaml 模板）；
4. 提供预编译模型云端资源（Model Zoodownload.sh拉取的.bin模型由原厂构建）。

4. 原厂不负责的工作

❌ 不为客户定制行业算法（工地检测、仓储识别等业务模型）；

❌ 不解决开发者自定义网络的极端算子适配问题（仅提供通用模型参考）；

❌ 不编写最终产品完整业务应用。

实例

原厂提供 YOLOv8 从 ONNX→X5.bin完整转换 yaml、推理代码；

但不会帮企业训练“物料缺陷检测”专属模型。

二、开源社区（GitHub 仓库 + 开发者论坛）职责【协作桥梁】

开源社区不是独立公司，是厂商托管、所有人共建的协作载体，是原厂和开发者中间的缓冲层。

1. 代码流通载体

• 托管所有上层开源 Demo（Model Zoo、TROS.B 源码）；
• 接收开发者 PR：新增算法 Demo、优化代码、补充文档、修复样例 bug。

重点区分：仓库上层应用代码开源；底层编译器、BPU 运行时库依然闭源。

2. 知识沉淀、经验互通

1. 收集通用踩坑方案（例如：X3 bin 无法在 X5 加载、NV12 图像格式错乱、量化精度对齐问题）；
2. 第三方开发者分享二次开发案例、教程、移植方案；
3. 社区论坛汇总 FAQ，减轻原厂重复答疑压力。

3. 社区反馈向上传递

把开发者普遍遇到的工具链缺陷、算子缺失、文档漏洞汇总，反馈给地瓜研发团队迭代优化。

社区边界限制

社区无法修改底层闭源组件： 比如遇到 hb_mapper 不支持某个自定义 ONNX 算子，社区只能提交 issue，等待原厂工具链升级，社区自身无法修复编译器。

实例开发者向 RDK Model Zoo 提交 PR，新增 YOLOv11 部署案例，审核通过后并入官方仓库，供给所有人使用； 但如果该模型转换时报算子不支持，社区无法修改 hb_mapper，只能等待厂商更新工具链。

三、开发者（个人 / 企业客户）职责【业务价值落地方】

一句话定位：基于原厂底座，开发面向自身场景的最终解决方案。 分为两大层级：

1. 通用开发者（学习、原型验证）

1. 克隆 Model Zoo 样板，跑通标准模型，掌握完整部署链路；
2. 复现官方案例，理解模型量化、NV12 预处理、BPU 推理、后处理整套规范；
3. 在社区提出问题、分享学习笔记，参与社区共建。

2. 商业项目开发者（企业工程师）

1. 基于官方模板，替换自研训练的 ONNX 模型，修改 yaml 重新编译生成.bin；
2. 基于开源 Demo 二次开发：修改类别、调整分辨率、改造前后处理逻辑；
3. 集成感知算法、运动控制、业务逻辑，开发成品机器人 / 工业视觉设备；
4. 遇到底层问题，规范复现问题并向社区 / 原厂提交反馈。

开发者典型红线（经常踩坑）

❌ 不能要求原厂把 X3 的.bin 直接转换成 X5 可用模型（底层指令集隔离，属于硬件底座限制）； ❌ 不能修改闭源 OE 工具链、hrt_runtime 底层库；

✅ 正确方式：复用 Model Zoo conversion 模板，用原始 ONNX 重新编译适配硬件。

实例

一家 AGV 企业：

复用 Model Zoo YOLOv8 推理代码；

自行训练 “人员、障碍物检测” 模型；

使用 OE 工具链重新量化编译 X5.bin；

结合 TROS.B 实现导航感知，做成 AGV 整机方案。

四、三方分工简明对比表

表格

五、完整业务链路实例串联（通俗理解分工）

场景：企业想要在 RDK X5 上做工业产线工件缺陷检测

1. 原厂：提供 RDK X5 开发板、OE 工具链、RDK Model Zoo YOLO 模板、X5 推理 SDK；规定只能使用bayes-e架构.bin模型；
2. 开源社区：提供大量开发者分享的量化调优经验、NV12 图像适配代码；遇到问题可以发帖交流；
3. 开发者：采集工件图片训练缺陷检测模型得到 ONNX；复制 Model Zoo 的转换 yaml；PC 端用 OE 编译出 X5.bin；修改推理代码，集成产线触发逻辑；最终部署到设备。

六、一句话总结生态分工

原厂修好 “公路与汽车底盘（芯片、工具链、底层 SDK）”；

开源社区是公路服务区，大家交流行车经验、共享导航模板；

开发者负责驾驶车辆，去往自己的目的地（行业产品方案）。