SnowBot Beta阶段移动机器人导航控制系统软件外包主需求文档

PUB-2604-0038-SPEC · 1.3

Barcode ARC50GHJJMFQ7

ARCBOS

ENGINEERED FOR EXTREME CONDITIONS

SnowBot Beta阶段移动机器人导航控制系统软件外包需求文档

版本：v1.2

用途：第三方外包询价、技术评审、合同附件、交付验收基线

适用项目：SnowBot 工程样机 Beta 阶段移动机器人导航控制系统软件开发与系统集成

1. 项目背景

ARCBOS 正在开发面向极端环境的工业级自动除雪机器人 SnowBot。

本次外包需求仅针对 SnowBot 在 Beta 阶段所需的导航与基础自动化能力，不包含完整无人驾驶系统、量产级平台、云端车队调度、多机协同或长期商业运营系统。

本文件用于统一 ARCBOS 与第三方外包方在以下方面的理解：

本文件应作为第三方报价、技术方案、合同附件和验收依据的核心基础文件。

2. 阶段定位

本项目属于 SnowBot 自治演进路径中的 Phase 2 / Beta / Task 阶段。

ARCBOS 阶段路径如下：

本次外包严格限定在 Beta 阶段。

第三方不得：

本项目核心目标如下：

人定义路线 / 区域
→ 机器人完成定位
→ 机器人执行指定路径
→ 机器人识别障碍 / 约束边界
→ 需要时安全停车或进入降级模式
→ 日志可导出
→ 系统可演示、可验收、可交接

3. 一句话需求定义

外包方负责让 SnowBot 在 Beta 阶段实现固定场地内的路线录制与回放、基础定位、路径跟踪、基础避障、安全停车、降级处理和现场联调，确保工程样机能够完成可演示、可验收、可交接的基础自动作业闭环。

本项目在中国市场沟通中统一称为：

SnowBot Beta阶段移动机器人导航控制系统

对应英文工程叫法为：

SnowBot Beta Navigation & Autonomy Stack

为避免范围失控，原则上不使用“完整自动驾驶系统”“无人驾驶系统”作为本阶段外包名称。

4. 外包功能名称

SnowBot Beta阶段移动机器人导航控制系统

5. 技术需求范围

本项目技术范围包括以下七类能力。

5.1 定位模块

第三方需完成：

本定位模块仅用于固定场地、有边界、Beta 阶段作业。

不要求第三方在本阶段完成全场景 SLAM、无 GPS 兜底定位或任意复杂环境泛化定位。

5.2 路径执行模块

第三方需完成：

本阶段重点是稳定执行指定路线，不是自动生成复杂最优除雪路线。

5.3 感知与基础避障模块

第三方需完成：

原则：安全停车优先于激进绕行。

5.4 运行时与控制接口

第三方需完成：

5.5 任务状态机

第三方需实现至少以下状态：

5.6 调试与现场工具

第三方需提供：

5.7 最小联调闭环

第三方必须至少完成以下工程闭环：

RTK / IMU / odometry 输入
→ 融合定位
→ 选择路线
→ 路径规划输出
→ 控制器输出
→ 底盘运动
→ lidar 检测障碍
→ safety monitor 触发停车或降级
→ 日志可导出

如果该闭环没有完成，不得视为 Beta 阶段交付完成。

6. 推荐模块边界

第三方可以根据自身技术栈实现，但必须保证模块边界清晰、接口可审查、交付可接手。

建议最小模块拆分如下：

1. sensor_adapter
   ├─ RTK 输入
   ├─ IMU 输入
   ├─ odometry 输入
   └─ lidar 输入

2. localization
   ├─ 传感器融合
   └─ 位姿输出

3. route_manager
   ├─ 路线录制
   ├─ 路线存储
   └─ 路线回放输入

4. planner_beta
   ├─ 单路径规划
   ├─ 简单区域路径生成
   └─ 边界约束逻辑

5. controller_beta
   ├─ 路径跟踪
   ├─ 速度指令输出
   └─ 停车 / 降级输出

6. safety_monitor
   ├─ 障碍停车
   ├─ 边界越界检测
   ├─ 传感器健康监控
   └─ 降级触发

7. task_manager
   ├─ 状态机
   ├─ 模式切换
   └─ 执行协调

8. debug_tools
   ├─ 路线工具
   ├─ 参数工具
   └─ 日志导出

7. 必须冻结的接口清单

在正式开发进入 M2 前，以下接口必须书面冻结。

第三方不得把未定义接口默认为已包含内容。

必须冻结：

接口冻结后，如发生 ARCBOS 主动要求的重大变更，可作为变更项另行评估。

8. 明确排除范围

除非另行书面签约，下列内容不在本次范围内：

9. ARCBOS 提供或指定的条件

ARCBOS 预计提供或指定以下条件：

如缺少关键条件，第三方需在 M1 阶段书面提出，不得在后续阶段以“条件不清”为由否定已确认的里程碑责任。

10. 代码与技术交付要求

第三方不得只交付 demo 或二进制文件。

最低交付结构如下：

/navigation-beta-package
├─ /src
├─ /config
├─ /launch
├─ /docs
│  ├─ architecture.md
│  ├─ interfaces.md
│  ├─ deployment.md
│  ├─ tuning.md
│  └─ limitations.md
├─ /tests
│  ├─ route_replay
│  ├─ obstacle_stop
│  └─ degraded_mode
├─ /logs_sample
├─ /bags_or_replay_data
└─ /handover
   ├─ handover_notes.md
   └─ training_record.md

等效目录结构可以接受，但必须包含以下内容：

11. GitHub 仓库、代码规范与供应链安全要求

本项目所有源码、配置、文档、测试脚本、部署脚本和交付材料，原则上必须进入 ARCBOS 指定 GitHub 仓库，作为唯一正式交付源。

未进入 ARCBOS 指定仓库的内容，不视为正式交付。

11.1 GitHub 仓库归属

建议仓库命名：

snowbot-navigation-beta

最终以 ARCBOS 指定仓库为准。

11.2 每周提交规则

第三方必须每周至少提交一次正式 commit。

每周提交内容应包括：

未按周进入 GitHub 的工作，不视为已完成工作。

11.3 Commit 规则

Commit message 必须清晰说明本次提交内容。

建议格式：

module: short description

示例：

localization: add RTK input parser
controller: tune path tracking parameters
safety: add obstacle stop trigger

禁止使用以下无意义提交信息：

update
fix
test
new
final
latest
改一下
最终版

11.4 分支与版本规则

建议 tag 示例：

M1-interface-freeze
M2-localization-route-ready
M3-obstacle-boundary-ready
M4-beta-integration-demo
M5-final-handover

11.5 源码要求

第三方必须提交完整源码，而不是仅提交二进制文件、压缩包或演示程序。

源码必须包括：

不得将核心逻辑隐藏在：

如确需使用第三方库，必须提前披露并获得 ARCBOS 确认。

11.6 注释与语言规范

为保证后续北美团队、海外供应商、投资尽调和国际化交付的一致性，代码注释原则上必须使用英文。

要求如下：

推荐：

route_manager
safety_monitor
localization_fusion
obstacle_stop_handler

不推荐：

luxian
anquan
zhangai
ceshi1
xinban

11.7 编码与格式要求

所有源码、配置文件、脚本和文档必须使用 UTF-8 编码。

要求如下：

如使用 Python、C++、YAML、JSON、Markdown 等文件，应保证跨平台可读。

11.8 代码质量要求

第三方提交的代码应满足以下最低要求：

所有秘密信息必须通过环境变量、配置模板或 ARCBOS 指定方式管理。

11.9 外部 API、SDK 与云服务限制

为满足海外市场、数据安全、供应链安全、合规审查和后续北美部署要求，未经 ARCBOS 书面批准，第三方不得在本项目中调用或依赖特定国家或地区绑定的 API、SDK、云服务、地图服务、定位服务、AI服务、日志服务、对象存储服务或监控服务。

本项目应优先采用：

第三方不得引入会造成以下风险的组件：

11.10 外部依赖披露要求

第三方必须提交外部依赖清单，至少包括：

未披露依赖不得进入正式交付。

11.11 API、SDK 与云服务审批规则

任何外部 API、SDK、云服务、在线模型、地图服务、定位服务、日志服务、监控服务，在接入前必须由 ARCBOS 书面确认。

未经确认，不得以“测试方便”“行业常用”“临时调用”为理由接入。

如需临时测试，必须满足：

11.12 安全与密钥管理

严禁将以下内容提交到 GitHub：

如发现密钥泄露，第三方必须立即通知 ARCBOS，并配合完成更换、撤销和审查。

11.13 开源协议限制

第三方不得在未披露的情况下使用可能影响 ARCBOS 商业化、闭源交付或知识产权控制的开源协议组件。

重点审查：

可接受与否由 ARCBOS 最终确认。

11.14 代码验收标准

代码交付需满足：

代码不满足上述要求的，不视为最终交付完成。

12. 知识产权与产权要求

除非双方另有书面约定，ARCBOS 对本项目成果应至少拥有以下权利：

第三方不得：

如第三方使用已有模块、第三方库、开源库、预训练模型或外部组件，必须在集成前书面披露：

13. 里程碑节点

本项目建议分为五个里程碑进行管理和结算。

M1：架构与接口冻结

交付物：

验收重点：

M2：定位与路线执行可用

交付物：

验收重点：

M3：障碍处理与边界安全可用

交付物：

验收重点：

M4：Beta 整包集成完成

交付物：

验收重点：

M5：现场演示与交接收口

交付物：

验收重点：

14. 验收标准

14.1 功能验收

交付包必须至少演示：

14.2 工程验收

交付包必须至少证明：

14.3 文档验收

如未提交以下内容，则不得视为完成验收：

14.4 交接验收

交接不等于演示。

交接完成应满足：

15. 项目管理要求

第三方应按轻量但清晰的方式进行项目管理。

建议执行规则：

周报建议包含：

16. 报价要求

第三方不得只给一个总价。

报价必须至少拆成：

每个阶段需说明：

建议第三方提供的人员结构包括：

如果报价中不包含测试、现场联调、文档、交接、bug 修复窗口，则该报价视为不完整报价。

17. 结算建议

建议采用分阶段付款，不建议一次性支付。

参考付款结构：

10% ~ 20%：合同启动
20%：M1 完成
20%：M2 完成
20%：M3 完成
20%：M4 完成
10% ~ 20%：M5 完成并交接结束

关键原则：

付款不得仅依据第三方口头说明。

每个付款节点应至少对应：

18. 风险控制条款建议

建议在合同或订单中明确以下原则：

19. 推荐价格判断区间

基于当前 Beta 阶段范围，合理报价应重点看范围、团队、工期和交付深度，不应只看总价。

内部参考区间：

ARCBOS 的优先谈判目标建议为：

30 万 ~ 38 万人民币：重点谈判区间
45 万人民币左右：需有明确理由
50 万人民币以上：进入强审区间

最终价格仍应以实际团队能力、联调难度、交付深度和现场测试次数为准。

20. 关键判断清单

拿到任何报价或方案，应立即检查以下问题：

1. 是否严格对应本需求文档？
2. 是否限定在 Beta 阶段？
3. 是否按 M1~M5 拆分？
4. 是否包含测试和现场联调？
5. 是否包含文档和交接？
6. 是否承诺源码交付？
7. 是否存在黑盒或私有环境锁定？
8. 是否提前塞入未来阶段能力？
9. 是否明确排除项？
10. 尾款是否足以约束最终交付？

如果其中 3 项以上无法明确回答，不建议直接签约。

21. 责任边界

本需求文档仅定义 Beta 阶段导航与基础自动化外包范围。

第三方仅对约定的软件与集成范围负责。

第三方不是整机的最终责任主体。

第三方不承担以下最终责任：

ARCBOS 保留最终架构控制权、阶段控制权、里程碑控制权和系统集成方向控制权。

22. 最终交付定义

本项目最终交付不是“演示一次能跑”。

最终交付必须同时满足：

最终交付最低标准如下：

代码完整
文档完整
接口清晰
部署可复现
测试有证据
日志可导出
问题可追踪
ARCBOS 可接手

23. 术语边界说明

本项目中相关术语以《SnowBot 导航外包术语解释与甲方验收口径》为准。

特别强调：

导航 ≠ 完整无人驾驶
避障 ≠ 复杂动态绕行
源码交付 ≠ 系统交接
Demo成功 ≠ 项目完成
Beta能力 ≠ Gamma/Delta能力

所有外包方解释、报价和交付应以工程可交付为准，不接受概念化、平台化、黑盒化表述替代实际交付物。

24. 结语

本次外包的目标不是购买一个完整机器人自治平台，而是购买一套严格服从 SnowBot Beta 阶段纪律、里程碑明确、边界清楚、可演示、可验证、可交接、可进入下一阶段演进的基础导航与自动化能力。

第三方必须尊重 ARCBOS 的开发路径。

ARCBOS 对本项目的管理原则是：

范围清楚
接口清楚
里程碑清楚
源码清楚
验收清楚
付款清楚
责任清楚

ARCBOS

ENGINEERED FOR EXTREME CONDITIONS