资讯详情

OOMWOO 系统架构解析:ROS2 开源扫地机器人的 CPU/MCU 双处理器架构与接口合同

📅 2026/9/23 22:33:46 | 华诺云谱 👁 阅读
OOMWOO 系统架构解析:ROS2 开源扫地机器人的 CPU/MCU 双处理器架构与接口合同
智能硬件机器人嵌入式物联网【免费下载链接】oomwooOpen-source vacuum robot cleaner项目地址https://gitcode.com/gh_mirrors/oo/oomwoo点击查看免费下载本文以 OOMWOO 项目的权威架构文档 docs/ARCHITECTURE.md 为主线结合仓库内的串行协议实现、ROS2 软件接口、I/O 板规格与安全恢复源码完整讲解这套3D 打印 ROS2 2D LiDAR开源扫地机器人如何通过 CPU/MCU 双处理器拆分实现安全永不依赖 Linux/ROS2以及支撑社区并行开发的机械/电气/软件接口合同体系。读完你将掌握 OOMWOO 的模块边界划分、CPU 与 MCU 的自定义串行协议帧格式与消息目录、ROS2 桥接映射方法以及 MVP 边界与安全审查流程。1. 项目定位可自建的开源 ROS2 扫地机器人OOMWOO 是一个开源、可 3D 打印、基于 ROS2 的家用扫地机器人平台配备 2D LiDAR 并支持 Home Assistant。其核心定位是由社区从零开始、模块化地建造——既是一台能扫干净的清洁设备也是一个平价的 ROS2 开发与学习平台。项目愿景North Star非 MVP是成为更广泛机器人应用平台的参考硬件因此在 §6 应用层的边界设计上预留了扩展空间但 MVP 明确将其排除在外见 README.md。架构文档开篇即声明其状态为DRAFT / skeleton本文档的价值在于定义系统使各模块可以并行构建而不互相冲突。所有标注TBD的条目都是门控决策gating decisions——在这些决策落定之前需要相互配合的硬件模块无法最终定型。因此文档明确要求把接口规格当作每个模块都同意的合同。设计原则§2开放且可替换Open and swappable每个模块都有明确接口任何合规实现都可以替换另一个实现模块之间只依赖公开接口不依赖内部实现。仿真优先Simulation-first软件必须先能在 Gazebo 中运行之后才上硬件这样没有实体机器人的贡献者也能构建和测试。平价且可打印Affordable and printable目标使用现成零件CM4/CM5 级计算模块、常见扫地机 LiDAR、Roborock/Dreame/Xiaomi 的电机与易损件以及 FDM 可打印的底盘零件。安全由评审把关Safety is reviewed, not crowd-trusted电池、充电和电机驱动模块在合并前必须通过维护者的安全评审见 §8。参考设计背书Reference-design backed以一台已知可用的扫地机参见 README.md 的参考来源锚定几何尺寸并证明可行性。2. 系统总览CPU 与 MCU 的双处理器拆分架构文档 §3 给出了整个系统的顶层框图其核心思想是把计算与实时控制/安全拆到两颗芯片上LiDAR (UART, ~5 Hz) · MIPI camera(s) · IMU · serial audio | -------------v------------------------------- | CPU - CM4 / CM5 (or pin-compatible module) | | ROS2 · SLAM (slam_toolbox) · Nav2 · behavior | | educational variant: ESP32-S3 micro-ROS | | (SLAM offboard on a dev PC over Wi-Fi) | -------------^------------------------------- serial (cmds/telemetry) | custom serial protocol CPU-reset / health GPIO | (NOT micro-ROS) -----------------------------v--------------- | MCU - STM32G473 (FreeRTOS, static alloc) | | motors · encoders · sensors · charging ctrl | | SAFETY (no Linux/ROS2): bumper/cliff/wheel- | | drop stop · current limit · CPU watchdog | -------------------------------------------- | | -------------- ----------------- | L/R drive | | suction fan, | | wheels, brush | | bumper, cliff, | | | | IR, wheel-drop | --------------- ------------------ Power: off-the-shelf 4S2P Li-ion pack (built-in BMS). The CPU module MCU sit on one carrier I/O board.这一拆分的关键论断文档中反复强调所有硬安全都放在 MCU 上独立于 Linux/ROS2 运行。文档注明接口大体已定见 §5随 io-pcb 规格完善而细化。3. 坐标系与工程约定§4为保证机械安装点与 URDF 坐标系全局一致架构文档定义了以下约定其中前两条目前仍为TBD门控决策base_link原点与朝向TBD遵循 REP-103 规范x 向前、y 向左、z 向上。所有机械安装点与 URDF 坐标系都以此为准。参考平面与外形尺寸TBD定义地面接触参考平面、机器人直径与高度包络。文档强调这两个数字门控所有硬件模块需要从已采购零件加上一台 3D 扫描的捐赠扫地机中提取数据参见 contributions/source-3d-models当前基线是约349 mm 圆机身由 oomwoo-one URDF 承载。单位毫米、千克、SI 单位制右手坐标系角度使用弧度。这些约定在软件侧有对应落地 docs/SOFTWARE_INTERFACES.md 定义了map、odom、base_footprint、base_link、base_scan等 ROS2 坐标系及其归属同样要求 REP-103 帧与 SI 单位并注明base_link原点、参考平面、机器人直径和高度包络仍在 ARCHITECTURE.md 中定义——两个文档互相引用、保持一致。4. 硬件架构§54.1 底盘与参考系§5.1底盘是整个系统的集成骨干integration backbone它发布所有其他硬件模块要对接的安装接口。参考几何尺寸尺寸、轴距、电机规格、质量来自 BOM.md 中列出的已采购零件 捐赠扫地机的 3D 扫描数据当前约 349 mm 圆机身基线由 oomwoo-one URDF 承载。目前仍有三个TBD整体直径与高度预算、安装网格/螺栓孔标准如规定间距上的 M3、各模块质量预算与总目标质量。4.2 机械接口标准模块间的合同§5.2每个硬件模块的 RFC 都必须对照此标准说明安装点螺栓孔型、相对于base_link的位置包络尺寸模块允许占用的最大空间质量预算配合公差与打印方向TBD统一连接器/紧固件标准螺钉规格、热熔嵌件等使不同作者设计的零件能真正装配在一起这一点在 contributions/source-3d-models 中有非常具体的落地该项目要求社区为 BOM 中的现成零件驱动轮组件、吸尘风机、万向轮、边刷电机等制作精确的 STEP 3D 模型并明确要求捕获与接口相关的几何——总体包络、安装特征孔、凸台、卡扣、螺栓孔型及精确位置、功能接口轴/轴套位置与轴线、车轮接触面、风机进出风口、连接器/出线位置以及配合面同时记录零件来源与版本。可见接口合同不是纸面概念而是被建模工具链严格执行的工程规范。4.3 电气接口标准§5.3电池采用带内置 BMS 的现成电池包——4S2P 锂离子标称约14.4 V约5200 mAh / 75 WhOEM BRR-2P4S-5200 级别以16.8 V CC/CV充电并带 NTC 温度检测。电化学方案已确定见 BOM.md。contributions/io-pcb 的 RFC 也确认要把参考板从 3S 改为 4S并假设使用 Xiaomi/Roborock/Dreame BRR-2P4S-5200 电池。TBD分发到各模块的电源轨VBAT、5V、3.3V及连接器类型/引脚定义。CPU ↔ MCU 链路使用**自定义高速串行协议非 micro-ROS**承载命令/遥测另有离散 GPIO——CPU 电源开关以及 MCU 在错过健康包时断言的CPU 复位线。MCU 拥有电机与传感器CPU 永不直接驱动它们。传感器归属碰撞/悬崖/轮离地传感器和模拟 IR 归MCU 侧数字输入 / ADCLiDARUART约 5 Hz、MIPI 相机、IMU 和串行音频挂接在CPU上。4.4 计算单元CPU与实时控制器MCU§5.4这一节是全文的技术核心文档明确OOMWOO 将计算拆分到两颗处理器上——这模仿了消费级扫地机的构建方式更关键的是安全从不依赖 Linux/ROS2。CPU计算模块I/O 板是一块载体板carrier可插接Raspberry Pi Compute Module 4 或 5由于 CM4 引脚定义已成为事实标准还可兼容众多引脚兼容的替代模块Radxa CM3/CM4、Pine64 SOQuartz、LuckFox Core3566 等其中多款带NPU为未来端侧视觉预留。CPU 运行ROS2、SLAMslam_toolbox、Nav2、LiDAR 处理和高级行为。CM 模块低矮有利于高度预算且可更换可破解、更便宜、可选 NPU。最低目标4 GB 的 CM4/CM5或 Pi 4。文档引用的现实先例是 4 GB Pi 4 上可运行 slam_toolbox Nav2。将下限压到2 GB是一个目标ROS2 可组合节点、选择性将重负载 Python 节点用 Rust/C 重写——不承诺由 compute-benchmark 裁决不需要 8–16 GB 模块。这正对应 contributions/compute-benchmark 模块的使命通过可复现的测量RSS/PSS、CPU 空闲/建图/导航开销、启动时间、LiDAR 更新率、Nav2/SLAM 余量来判断 2 GB 是否现实。散热不设独立 CPU 风扇——利用吸尘风机的气流冷却计算板与消费级扫地机一致。早先定制的RK3562 参考原理图被放弃改为 CM4/CM5 载体方案。contributions/io-pcb 的贡献指南印证了这一决策要求完全移除 Rockchip 子系统SoC、LPDDR4、eMMC、SoC PMIC、DDR/USB/PCIe PHY、SoC 的 MIPI 相机接口与 WiFi/BT 模块AP6256新增 CM4/CM5 插座只保留 I/O 侧STM32G473VCT6、电机驱动、传感器前端、电池充电、音频、按键/LED。MCU实时/安全控制器采用STM32G473VCT6Cortex-M4FLQFP100多 ADC 与定时器资源由当前 I/O 板设计选定拥有电机、编码器、全部传感器、电池充电控制与安全。其角色是固定的功能不会迁移到 CPUCPU 的工作也不会迁移到 MCU。固件采用分层FreeRTOS设计静态分配、看门狗、有界响应时间、面向 CE 认证使用自定义串行协议——不是 micro-ROS这是经过验证的消费级扫地机路线参考了逆向工程的 3irobotix 协议。contributions/mcu-io-firmware 给出了更细的三层结构Layer 3 为 ArduinoSTM32duinoAPI 供贡献者开发新功能Layer 2 为 FreeRTOS 任务通信、控制、遥测、充电、安全监管Layer 1 为 HAL/定时器 ISR 实时内核电机控制、硬安全切断、CPU 看门狗由维护者持有并安全评审。其核心规则是安全与电机控制内核在结构上隔离于 Arduino 层——即使贡献者的草图死循环也无法打败悬崖停车、过流切断或 CPU 看门狗。硬安全在这里独立于 Linux/ROS2MCU 在碰撞、悬崖检测或轮离地时停止所有电机对卡住的毛刷做限流并看门狗监管 CPU——如果 CPU 的健康包停止它停止电机并可复位 CPU。约 60 个信号的引脚预算见 contributions/io-pcb 附录解释为何 MCU 需要高 GPIO 部件。CPU ↔ MCU 链路一条高速串行通道双向承载命令/遥测另有离散 GPIO——关键是 MCU 在错过健康包时断言的CPU-reset线以及 CPU 电源开/关。协议草案、ROS2 桥接映射和上电检查清单位于 contributions/io-board-interface。任何被kaiaai/LDS/lds2d支持的 LiDAR 都接口兼容。4.4.1 串行协议实现帧格式与消息目录contributions/io-board-interface/xbattlax/docs/cpu_mcu_serial_contract.md 给出了该自定义协议的完整草案其设计目标与架构文档完全对齐让安全关键固件保持小巧、确定、独立于 Linux让 CPU 跑 ROS2/Nav2/SLAM/建图/停靠行为与 UI让 MCU 拥有电机、编码器计数、电源切换、充电控制、悬崖/碰撞/轮离地响应与看门狗决策让过期或损坏的命令停止机器人而不是继续运动。链路参数草案属性草案值物理链路UART TTL 或 USB CDC使用相同组帧波特率首选 1 Mbaud早期台架测试支持 115200字节序载荷字段小端组帧二进制固定头 载荷 CRC-16/CCITT-FALSE传输重试快速设定点无重试仅配置类命令走 ACK/NACK运动超时心跳或设定点过期时MCU 停止驱动与清洁电机帧格式固定头魔数包含在 CRC 中解码器必须拒绝版本错误、长度不可能或 CRC 错误的数据流式解码器可丢弃噪声直到下一个OW魔数offset size field 0 2 magic: ASCII OW 2 1 protocol version: 1 3 1 flags 4 2 sequence number 6 2 message type 8 2 payload length 10 N payload 10N 2 CRC-16/CCITT-FALSE over header payload消息 ID 分区0x0001-0x00ff为 CPU→MCU 的控制/心跳/复位/配置0x0100-0x01ff为 CPU→MCU 的执行器设定点0x7000-0x70ff为双方共用的 ACK/NACK 与协议诊断0x8000-0x80ff为 MCU→CPU 的状态、遥测与安全事件。最小消息目录节选关键项ID名称方向频率载荷0x0001HEARTBEATCPU→MCU20–50 Hzu32 cpu_time_ms、u8 cpu_mode0x0002ESTOP_SETCPU→MCU事件u8 active、u16 reason0x0004IDENTIFY_REQUESTCPU→MCU连接/重连空MCU 回复MCU_HELLO0x0101DRIVE_SETPOINTCPU→MCU20–50 Hzi16 linear_mm_s、i16 angular_mrad_s、u16 duration_ms0x0102CLEANING_MOTORS_SETCPU→MCU1–10 Hzu8 main_brush_pct、u8 side_brush_pct、u8 fan_pct、u8 pump_pct0x8000MCU_HELLOMCU→CPU启动/事件固件版本与构建 ID0x8001FAST_TELEMETRYMCU→CPU50–100 Hz编码器计数 快速输入标志0x8002SAFETY_EVENTMCU→CPU事件 锁存u16 event、u8 active、u16 detail0x8005SAFETY_STATEMCU→CPU10 Hz 事件u32 timestamp_ms、u16 active_flags、u16 latched_flags安全事件码节选与 MCU 行为1/2左/右碰撞——立即停止驱动仅在悬崖/轮离地均无触发时允许有界恢复3/4左/右悬崖——停止驱动与清洁电机要求安全后退或人工干预5/6左/右轮离地——停止驱动与清洁电机锁存至车轮重新着地7毛刷过流——停止受影响的毛刷8风机过流——停止风机9CPU 心跳超时——停止所有可运动输出消抖后可选择复位 CPU10急停——停止所有可运动输出锁存至显式清除。时序规则草案CPU 在桥接激活期间以 20–50 Hz 发布HEARTBEATDRIVE_SETPOINT携带短duration_ms到期即归零驱动输出DRIVE_SETPOINT.duration_ms上限 250 ms错过心跳后 MCU 硬停时间草案为 150 ms。这些常量在参考编解码器 contributions/io-board-interface/xbattlax/tools/oomwoo_mcu_frame.py 中有精确对应MAX_LINEAR_MM_S 500、MAX_ANGULAR_MRAD_S 4000、MAX_SETPOINT_DURATION_MS 250。该文件是共享的可执行参考实现——实现了帧编解码encode_frame/decode_frame、流式解码器StreamDecoder自动丢弃噪声直至找到OW魔数、CRC-16/CCITT-FALSE 校验及DRIVE_SETPOINT、SAFETY_EVENT、FAST_TELEMETRY等载荷打包函数配套的 conformance 目录 将冻结的消息 ID 与载荷布局镜像为机器可读清单与黄金向量CI 要求同一帧字节在 Python、C11、C17 三处验证一致。4.4.2 ROS2 桥接从 ROS 话题到串行帧contributions/io-board-interface/xbattlax/docs/ros2_mapping.md 定义了未来oomwoo_mcu_bridge节点的映射方案其架构为Nav2/恢复/作业/诊断 →oomwoo_mcu_bridge→ CPU/MCU 串行帧 → STM32 I/O 板固件。桥接应保持薄ROS2 拥有高层行为MCU 拥有硬安全与电机 IO。订阅侧的关键映射/cmd_velgeometry_msgs/msg/Twist→ 转成有界设定点DRIVE_SETPOINT/oomwoo/safety/e_stop→ESTOP_SET四个清洁执行器百分比话题 →CLEANING_MOTORS_SET/oomwoo/io/clear_faults→CLEAR_LATCHED_FAULT停靠最后阶段/oomwoo/dock/final_cmd_vel→ 使用更紧钳位的DRIVE_SETPOINT。发布侧FAST_TELEMETRY派生出/odom与/joint_states轮编码器计数POWER_TELEMETRY→/battery_state安全相关位域发布为/oomwoo/io/bumper、/oomwoo/io/cliff、/oomwoo/io/wheel_dropMCU_DIAGNOSTIC→/oomwoo/io/mcu_status与/diagnostics。桥接被设计为生命周期节点unconfigured无串行连接、无执行器命令→inactive串口可开发IDENTIFY_REQUEST等MCU_HELLO但不发心跳与运动输出→active心跳运行、接受设定点、发布遥测→error心跳停止、设定点清零、诊断说明原因。桥接在低层强制安全钳位最大线速度/角速度与设定点时长、取消激活时发送零设定点、在急停/悬崖/轮离地/CPU 超时锁存期间停止转发运动命令。注意其仲裁原则——同时只有一个 ROS2 组件写/cmd_vel桥接不解决高层仲裁。4.5 两种构建配置§5.5同一块载体 I/O 板 MCU 支持两种可互换的计算配置消费版 / 常规版教育版 / 低成本版CPU 插槽模块CM4 / CM5或引脚兼容替代CM4 外形尺寸的ESP32-S3板ROS2 / SLAM 运行位置板载ROS2 slam_toolbox Nav2离板运行在本地开发 PCESP32-S3 运行micro-ROS连接自包含机器人机器人 ↔ 开发 PC 走Wi-Fi取舍对非专家即插即用更便宜但受 Wi-Fi 拥塞/死角影响——是学习平台不是精致的消费产品板载 SLAM 是消费版默认这样非专家无需搭建独立的 ROS2 开发机即可构建和使用。ESP32-S3 只能作为CPU 插槽选项——它缺少 MCU 角色所需的约 60 个 GPIO因此永远不能替代 STM32。5. 软件架构§65.1 ROS2 图MVP§6.1MVP 核心节点LiDAR 驱动、基座控制器差速驱动、里程计、teleop、SLAM手动建图、TF/URDF 发布器。接口合同每个软件模块的 RFC 必须声明其发布/消费的 ROS2 话题、服务、消息类型与参数模块之间依赖这些接口而非彼此的代码。当前草案见 docs/SOFTWARE_INTERFACES.md。该文档进一步定义了基线话题当前由 Gazebo 仿真或标准 Nav2/SLAM bringup 提供/cmd_velgeometry_msgs/msg/Twist由 teleop、Nav2 速度平滑器、恢复节点产生Gazebo 差速驱动消费、/odom、/tf、/joint_states、/scansensor_msgs/msg/LaserScan供 SLAM/AMCL/Nav2 代价地图/贴墙使用、/mapnav_msgs/msg/OccupancyGrid以及仿真中的/bumper_left、/bumper_rightros_gz_interfaces/msg/Contacts。它同时给出 Nav2 接口复用建议/navigate_to_pose、/navigate_through_poses、行为服务器、代价地图、地图保存器以及各模块合同表——例如urdf-gazebo-sim发布/scan//odom//tf//joint_states/bumper 并提供世界与机器人描述clean-and-map驱动首轮覆盖并产出完整地图recovery-safety停止或门控运动并运行有界恢复dock-cycle提供出坞/回坞/精确停靠/充电完成与找坞回退live-robot-bringup验证硬件暴露与仿真一致的公开接口。健康监控Stack Health Monitor草案也在该文档中ROS2 栈应通过/oomwoo/health/roster预期的组件清单、/oomwoo/health/component工作路径心跳、/oomwoo/health/stack聚合状态与/oomwoo/health/mcu_heartbeat仅当所有关键组件新鲜且健康时转发给 MCU 的单一心跳向 MCU 暴露聚合健康/死机路径。故障安全规则包括无 roster 即无 MCU 心跳关键组件缺失/过期/不健康即停止 MCU 心跳组件心跳必须来自有用工作路径而非独立定时器。参考实现见 contributions/health-monitor/xbattlax/README.md。5.2 仿真§6.2Gazebo URDF附带一组住宅布局世界用于导航与覆盖测试。仿真一致性是一等需求而非事后补救。对应的贡献模块是 contributions/urdf-gazebo-sim其 README 展示了kitchen_dining与living_room两个世界启动方式如ros2 launch oomwoo_gazebo world.launch.py world:kitchen_dining.world。5.3 应用层Phase 2 —— North Star不在 MVP 中§6.3一个与 ROS2 无关的应用层在本地隔离的Podman容器中运行第三方应用使应用开发者无需 ROS2 专业知识。此处记录仅为保持边界清晰明确排除在 2026-08-31 MVP 之外。5.4 安全恢复的软件侧佐证架构文档强调硬安全在 MCU永不依赖 Linux/ROS2而软件侧的恢复行为则由 contributions/recovery-safety 落地。恢复控制器核心 实现了恢复阶梯recovery ladder机制对每种情况定义有序的恢复步骤序列。例如左侧碰撞BUMPER_LEFT的阶梯为后退 0.8slinear_x-0.12→ 远离左碰撞旋转 1.0s → 晃动脱困 0.7s → 清除代价地图2s 超时LOCALIZATION_LOST则为停止等待 原地旋转收集扫描。代码同时区分了安全情形SAFETY_SITUATIONSCLIFF、WHEEL_DROP、PICKUP、E_STOP——这些直接进入 PAUSED 状态并标记recoverableFalse与串行协议中 MCU 的硬停语义相互呼应体现了MCU 是最终安全权威、ROS2 只做有界恢复的分层设计。6. MVP 定义§7目标 2026-08-31范围内CM4/CM5 级计算模块上的 ROS2 · LiDAR · 手动 SLAM/建图 · teleop 驱动 · 3D 打印底盘 · 带 URDF 的 Gazebo 仿真 · 评估 演示视频。不含停靠、自主探索、Home Assistant、应用层。明确的 MVP 非目标自主覆盖、停靠、自动集尘、拖地、Home Assistant、应用平台、配件——这些属于后续阶段。关键路径所有权维护者小团队持有底盘、接口规格与集成使 MVP 不依赖志愿者的交付时间。社区模块加速并改进 MVP但不阻塞它。7. 安全审查门§8电池、充电、电机驱动及市电相关模块在合并前必须通过维护者安全评审这些模块的 RFC 必须包含危险说明过流、热、短路、机械夹伤。电池风险通过采用带内置 BMS 的现成 4S2P 锂离子电池包过充/过放/短路保护而降低评审因此聚焦于16.8 V CC/CV 充电路径 NTC 温度检测。硬安全位于 MCU绝不放在 Linux/ROS2 上——它在碰撞/悬崖/轮离地时独立停止电机、对卡住的毛刷限流、并看门狗复位 CPU。这一原则在 contributions/mcu-io-firmware 的验收标准中被量化必须测量并记录每个安全切断的最坏情况反应时间一个故意挂死的 Arduino 层任务不得击败悬崖停车、过流切断或 CPU 看门狗充电按规格行为0.5C 上限、弱充电器优雅降级。8. 路线图§9MVP 后的阶段可充电电池 基础停靠站 自主建图。Home Assistant 集成。应用层Podman 应用运行时 首批应用。配件与创新应用集成如 LeRobot 机械臂。9. 开放问题与已决决策§10已决MCU 运行自定义串行协议非 micro-ROSCPU 运行板载 ROS2/SLAM/Nav2。micro-ROS 仅用于教育版ESP32-S3 配置SLAM 离板在开发 PC 上。见 §5.4–5.5。电池为带内置 BMS 的现成 4S2P 锂离子包16.8 V CC/CV 充电。见 §5.3、§8。参考 I/O 板使用STM32G473VCT6取代早期 STM32G070 候选引脚兼容替代品属于独立的板卡设计决策。仍待决OOMWOO 的板载 ROS2 栈能否压进2 GB可组合节点、选择性 Rust而非 4 GB由 compute-benchmark 回答。一个覆盖参考扫地机 DIY 构建的硬件无关 HAL社区想法模块选型流程由谁、按什么标准决定哪个竞争实现胜出参见各模块的验收标准。10. 如何进一步深入阅读完整架构文档docs/ARCHITECTURE.md含各TBD门控决策的最新状态软件接口合同docs/SOFTWARE_INTERFACES.md串行协议契约与 ROS2 映射contributions/io-board-interface/xbattlax/docs/cpu_mcu_serial_contract.md、contributions/io-board-interface/xbattlax/docs/ros2_mapping.md参考帧编解码实现contributions/io-board-interface/xbattlax/tools/oomwoo_mcu_frame.py 与一致性测试 contributions/io-board-interface/xbattlax/tests/test_oomwoo_mcu_frame.py、contributions/io-board-interface/xbattlax/conformanceI/O 板与 MCU 固件 RFCcontributions/io-pcb、contributions/mcu-io-firmware计算基准2 GB 可行性contributions/compute-benchmark安全恢复软件侧contributions/recovery-safety零件清单与 3D 模型BOM.md、contributions/source-3d-models提示当前架构仍处于DRAFT / skeleton状态多处TBDbase_link原点、机身直径/高度预算、安装标准、电源轨是门控决策引用本文时请以仓库最新文档与各 RFC 验收标准为准。赞分享智能硬件机器人嵌入式物联网【免费下载链接】oomwooOpen-source vacuum robot cleaner项目地址https://gitcode.com/gh_mirrors/oo/oomwoo点击查看免费下载相关推荐OOMWOO架构全解CPU/MCU双处理器分离为何是扫地机安全的终极答案OOMWOO架构全解CPU/MCU双处理器分离为何是扫地机安全的终极答案 OOMWOO 是一款开源、可自行 3D 打印组装的扫地机器人基于 ROS2 与 2智能硬件机器人嵌入式物联网OOMWOO 开源扫地机器人深度解析Raspberry Pi ROS2 2D LiDAR 的自研整机架构OOMWOO 开源扫地机器人深度解析Raspberry Pi ROS2 2D LiDAR 的自研整机架构 OOMWOO 是一个由社区协作、可完全自己动智能硬件机器人嵌入式物联网OOMWOO RFC Board 全解析ROS2 开源扫地机器人的模块化协作开发指南OOMWOO RFC Board 全解析ROS2 开源扫地机器人的模块化协作开发指南 OOMWOO 是一个可自己动手搭建的开源扫地机器人Raspberry智能硬件机器人嵌入式物联网创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。