企业官网建设流程全解析

• 智能硬件
• 机器人
• 嵌入式
• 物联网

OOMWOO（Open-source robot vacuum cleaner）以"模块化并行开发"的方式组织社区协作，每项可独立承接的工作都被封装为一个 RFC（Request for Contribution）。本文以仓库中的 RFC_BACKLOG.md 为骨架，系统梳理那些尚未成为活跃 RFC 的规划中模块——包括尘盒与风机总成两个"待命"模块、14 项机械设计硬件模块、5 项后续软件模块以及非工程类贡献方向，并说明一个 Backlog 条目如何"解锁"并升格为活跃 RFC 的完整机制。读完本文，你将掌握 OOMWOO 的模块阶段体系（MVP / P2 / P3+）、每个规划模块的技术要点，以及从源码与 RFC 文档中可验证的参与路径。

一、RFC Backlog 在项目中的定位

在 OOMWOO 的协作体系中，模块工作被划分为三层：

• 活跃 RFC：当前可着手实现的模块，每个拥有独立的contributions/<module>/文件夹，包含完整规格。权威状态看板位于 contributions/README.md（即"RFC board"）。
• RFC Backlog（本文主体）：计划中但尚未激活的模块清单。这些条目一旦"解锁并准备好"，就会毕业（graduates）为活跃 RFC，拥有自己的contributions/<module>/文件夹。
• 核心机械设计：不属于 RFC 范畴——底盘、刷子、拖地、轮架与外壳由项目内部设计（见 contributions/README.md 中的说明），因此不通过社区共识缓慢推进，而是以紧密耦合的参考设计方式在维护者侧完成。

RFC_BACKLOG.md 正是这条"规划 → 解锁 → 毕业"流水线的入口文档：活跃 RFC 的完整规格在 contributions/ 目录下，而 Backlog 负责记录那些"还差一个前提条件"的模块。

二、阶段体系：MVP / P2 / P3+ 与 Safety 标记

Backlog 用统一的阶段图例（Phase legend）给每个条目定级：

理解这一体系需要注意：OOMWOO 存在两种构建形态（见 contributions/README.md 中的 "Two builds" 说明）——basic版（仅吸尘、简单组装、只充电的底座）与full-featured版（拖地、自动集尘、可扩展边刷）。某些 RFC 只服务于 full 构建，例如 floor-care 中的拖布抬升、dock-cycle 中的自动集尘底座，开始工作前需要先确认自己瞄准的是哪种形态。

三、On hold：已具备 RFC、暂被搁置的两个机械模块

Backlog 首先记录了两个已经写好 RFC、但因缺少"已采购零件 + 3D 参考设计"而暂停的模块。它们的完整规格已存在于仓库中，是"待命"状态而非"空白"状态。

1. 尘盒 3D 设计（contributions/dust-bin）

等待条件：已采购零件 + 一个 3D 参考设计。

依据 dust-bin 的 RFC 文档，该项目暂停的原因明确：项目已离开旧的拆解参考机型，尘盒必须围绕"已采购零件 + 即将到来的 3D 参考设计"（尚未绘制草图）来设计。恢复工作的前置输入是 source-3d-models（STEP 几何模型）与 part-specs（电气/机械规格）两个活跃 RFC。

RFC 中定义的尘盒职责与验收要点：

• 功能定义：可拆卸尘盒，负责收集灰尘、容纳空气滤芯，并从真空风机接收气流；盒体进风口与垫圈（gasket）配合密封；盒盖闩锁为弹簧加载式。
• 设计要求（恢复时）：
  • 与风机进风口和底盘实现密封配合（sealed）；
  • 容纳通用、可更换的滤芯——标准化为货源充足的滤芯尺寸，让玩家在任何地方都能复购（设计研究见 README.md）；
  • 可靠的弹簧闩锁，便于取出、插入与清空；
  • 可 3D 打印（假定 PETG），拆分后适配约 20 × 25 cm、高 20 cm 的打印空间；
  • 现阶段忽略拖地功能；
  • 交付物：STEP + 原生 CAD + 3MF/STL + 子组件 BoM + 文档/照片，提交至contributions/dust-bin/<你的GitHub用户名>/。
• 验收标准：气流密封无泄漏、易清空、闩锁可靠；适配未来的底盘与风机接口且不强制改动其他模块；采用通用易采购滤芯；提供文档与 STEP/原生 CAD 源文件。

仓库侧可以佐证"零件已就绪"的证据：BOM.md 中已列出多种 HEPA 滤芯选型（如约 110 × 48 × 22 mm、约 113 × 59 × 12 mm 等规格，价格约 $2–3），而 part-specs 的进度已标注为 85%，负责反向测绘各种零部件的引脚/尺寸数据。

2. 风机总成（contributions/vacuum-fan）

等待条件：风机已采购，剩余蜗壳/垫圈外壳等待 3D 参考设计——进展详见 RFC board。

真空风机的 RFC 给出了比 Backlog 更完整的状态：风机选项已采购——BOM.md 中列出了多个 Pa/价格档位的吸尘风机（Dreame、Nidec、Roborock 系列），例如：

• 2–2.5 kPa 档（Nidec 20N704P200 等，$12–25）；
• 5.1–6 kPa 档（Nidec 22N704W150 / 20N704S980 等，$17–28）；
• 10 kPa 档（Roborock BL24131616 等，$12–24）；
• 36 kPa 档（Roborock Saros 20，$34–45）。

该模块的组成（来自 RFC）：高速BLDC 风机电机 + 叶轮（已采购，见 BOM）、待设计的蜗壳（volute）外壳、风机排气垫圈、以及外壳橡胶减震座。RFC 中有一个重要的设计研究结论值得注意：真实清洁效果并不与吸力（Pa）直接挂钩——中档密封电机即可媲美旗舰机型；应优先保证密封良好的气流路径（尘盒/风机/主刷接缝无泄漏）和好的主刷，而非追求最大 Pa 值。

恢复后的设计任务：围绕 BOM 中选定的 BLDC 风机设计可 3D 打印的蜗壳外壳 + 垫圈，与尘盒和底盘干净配合。目标包括：可打印（假定 PETG，理想无支撑、可复现）、切片后适配约 20 × 25 cm、高 20 cm 空间（必要时拆分）、气流路径密封无泄漏、低振动且电机固定可靠、垫圈优先用现成件否则 TPU 打印。上游解锁工作正是 source-3d-models 中的风机建模与 part-specs 中的风机驱动规格（PWM / 转速 / 霍尔 / 三相驱动方式、软启动与保护行为等）。

四、计划中的硬件（机械设计）模块

Backlog 的第二大板块是计划中的硬件机械设计模块。这些条目等待"已采购零件 + 3D 参考设计草图"，之后会毕业为活跃的contributions/RFC；其中零件规格（specs）与 STEP 模型已经活跃（见 part-specs 和 source-3d-models），而电机驱动/电源 PCB 与电池充电已成为活跃的 io-pcb RFC。

完整模块表（含 ID 与阶段）：

要点解读：

• MVP 高度集中于"能跑起来"：底盘、轮座、算力座、LiDAR 座、主刷、保险杠、悬崖座、顶盖、线束、基础充电座全部排入 MVP——它们共同构成 v0"精简裸机版"（见 README.md 的 v0 目标：3D 打印底盘 + ROS2 Gazebo 仿真 + 基础清洁与建图 + Raspberry Pi CM4/CM5 运行 ROS2）。
• Safety标记：基础充电座（hw-dock, MVP）因为涉及电池充电与触点，被明确标记为需要维护者安全评审。
• 模块 ID 是稳定的工程标识：如hw-chassis、hw-lidar-mount、sw-diagnostics，便于跨文档引用与追踪。
• 底盘是维护者所有：hw-chassis的备注注明 "Maintainer-owned"——与 RFC board 中"核心机械设计不设 RFC、由内部设计并跟踪于 oomwoo-one-cad"的说明相互印证。
• P2 的拖地与扩展功能：双旋转拖布模块（弃用拖布式/自清洗滚筒，呼应 README.md 中"无传统拖布、双旋转旋转拖布或更优"的用户需求调研）、边刷与更高档位底座属于下一阶段。

与现有活跃 RFC 的衔接：这些机械模块的数据底座已经铺好——part-specs 负责驱动轮（编码器类型/PPR、减速比、电压电流、堵转扭矩、轮跌落传感器引脚等）、吸尘风机（驱动方式、气压/流量）、万向轮的规格数据；source-3d-models 负责 BOM 中现成零件的 STEP 几何模型，其 README 明确"每个打印安装座和底盘都引用这份几何——缺失模型会阻塞或迫使机械模块靠猜测设计"，且与 ARCHITECTURE.md §5.2 的机械接口标准对应。

五、计划中的软件模块（后续阶段）

Backlog 明确指出：基础软件已被活跃 RFC 覆盖——URDF、仿真、SLAM、Nav2、覆盖清扫、teleop、传感器分别由活跃 RFC 承接（可在 RFC board 验证，例如 clean-and-map、nav-localize、floor-care、obstacle-avoidance、urdf-gazebo-sim 等）。因此剩下的只是更后期的软件工作：

结合项目背景可以推断（依据 README.md 的 Goals 与软件接口文档）：这些模块直接服务于项目的产品愿景——本地化、无云依赖、原生 Home Assistant 集成、以及"在 ROS2 之上叠加应用定制吸尘行为"的北极星目标。其中sw-regression-tests的"仿真测试作为 PR 门禁"理念，与 CONTRIBUTING.md 中"任何合并都必须经过仿真或硬件测试"的人工审查原则一致。ROS2 接口契约的统一性由 SOFTWARE_INTERFACES.md 保障，它是独立构建的各模块保持互操作的关键（见 CONTRIBUTING.md）。

六、非工程类贡献：同样被规划的协作方向

Backlog 的最后一个板块提醒：OOMWOO 不止需要工程师：

这些方向与 CONTRIBUTING.md 中"你不需要是机器人专家也能贡献"的立场一致——例如"真实家庭测试"直接对应 README.md 用户需求调研中"从不卡住、防缠绕、无尘袋"等真实痛点，而"文档 / 构建指南"正是 BUILD_INSTRUCTIONS.md 与 blog/ 目录的长期来源。

七、从 Backlog 到活跃 RFC：升级与退役机制

Backlog 条目的生命周期机制（综合 RFC_BACKLOG.md 与 CONTRIBUTING.md 的 RFC lifecycle 章节）可以概括为：

1. 解锁：一个 Backlog 条目的前置条件（已采购零件 + 3D 参考设计草图等）满足后，即可"毕业"为活跃 RFC，获得自己的contributions/<module>/文件夹。
2. 活跃期：RFC 按exploratory→ready to start work/design-first→in progress推进，开放新贡献。
3. 退役（维护者动作）：RFC 以四种原因之一退役并原地保留（永不删除或移动，以维持外部链接）：
   • completed（选中的贡献已交付）、superseded（被其他方案取代并链接后继者）、descoped（搁置/移出范围）、merged（并入其他 RFC）。
4. 状态权威：RFC board（contributions/README.md）是所有 RFC 状态与进度的唯一权威来源——当 RFC 自身 README 的 Status 行与看板不一致时，以看板行为准。

从看板可以观察到该机制的实时运行证据：例如 vacuum-fan 已处于 50% 进度（风机已数字化为 STEP、已采购并上工作台测试），dust-bin 为 5%（底盘 CAD 已加入基础端口，盒体设计待解锁），而 urdf-gazebo-sim、part-specs、source-3d-models 等活跃 RFC 已分别达到 90%、85%、85%——这些正是机械设计模块"解锁"所依赖的上游数据。

八、总结：这份 Backlog 告诉你的三件事

1. 项目处于"数据先行"阶段：机械模块虽未开工，但其解锁所需的零件采购（BOM、part-specs）与几何数据（source-3d-models）已在活跃推进，硬件设计是"万事俱备、只差参考设计草图"。
2. 模块阶段清晰可追踪：MVP 聚焦"精简裸机版"的机械完整性，P2/P3+ 容纳扩展功能与上层软件，Safety标记的模块（如基础充电座）必须过维护者安全评审。
3. 参与路径明确：随时可以在 RFC board 挑选活跃模块开工；对 Backlog 中的机械条目，可以先通过 part-specs 与 source-3d-models 补齐缺失的规格与 STEP 模型来"解锁"它们——这正是文档标注的、当前最有价值的输入。

参考文件速查：RFC_BACKLOG.md（本文主体）｜ RFC board（状态权威）｜ dust-bin RFC 与 vacuum-fan RFC（两个待命模块规格）｜ part-specs / source-3d-models（数据底座）｜ BOM.md（零件采购与风机/滤芯选型）｜ CONTRIBUTING.md（RFC 生命周期）｜ ARCHITECTURE.md 与 SOFTWARE_INTERFACES.md（系统设计与 ROS2 接口契约）。

• 智能硬件
• 机器人
• 嵌入式
• 物联网