这篇作为“初步设计”的补充，重点把能落地实现的关键点写清楚：系统拆分、数据流/控制流、通信协议、电源与舵机控制、调试路径。

0x01 显示与人机交互（大显/状态灯）

魔方机器人本质上是个“自动化设备”，强烈建议做一个简单的状态显示，能极大降低调试难度。

建议显示的内容：

• 当前状态：待机 / 校准 / 识别中 / 求解中 / 执行中 / 完成 / 异常
• 计时：总用时、识别用时、执行用时
• 步数：求解步数、已执行步数
• 连接：蓝牙是否连接、丢包/重发次数（可选）

显示方案（从易到难）：

• 方案 A：LED + 蜂鸣器（最简单，够用）
• 方案 B：数码管（显示时间/步数）
• 方案 C：OLED/LCD（I2C/SPI，显示状态更完整）

0x02 系统设计（模块划分）

上位机（Android）负责“看 + 算”，下位机（MCU）负责“动 + 保证动作可靠”：

模块建议拆分：

• 视觉识别：采集、定位 9 宫格、颜色分类、白平衡/曝光处理
• 求解器：把状态矩阵转换为动作序列（例如 U R2 F' ...）
• 协议层：动作序列编码、分包、校验、重传
• 执行层：动作映射（每个转动对应哪几个舵机、推进/夹持/旋转顺序）
• 安全层：限位/超时/复位、异常回滚策略（至少做到“停机并松手”）

0x03 系统流程（识别 -> 求解 -> 执行）

核心流程建议按“可观测、可中断、可复现”的方式实现：

推荐的调试顺序：

1. 先离线验证求解器（同一状态是否稳定、步数是否合理）
2. 再验证协议与传输（带校验、带 ACK、可重发）
3. 最后做机械动作（先单轴，再组合动作）

0x04 通信协议（Android 与下位机）

通信尽量简单、可调试（串口助手能直接发）：

• 建议帧格式：STX + payload + checksum + ETX
• payload 建议就是 ASCII（前期好调），后期再压缩成二进制
• 下位机每执行完一个动作（或一组动作）返回 ACK + idx，上位机才能继续发下一条（避免动作堆积）

动作编码建议：

• U, U', U2 / R, R', R2 / F, F', F2 ...（标准魔方记号）
• 或者直接发“舵机动作宏”编号（更贴近机械）

0x05 电源与电路设计要点（避免“能动但不稳”）

机器人最常见的问题其实不是算法，是供电与干扰：

• 舵机供电建议独立：6V 大电流（根据舵机峰值电流选电源，宁可富余）
• 逻辑供电：5V/3.3V 用 DC-DC 降压（带足够电容）
• 地线处理：舵机地与逻辑地必须共地，但尽量走“粗地线/星形接地”，避免舵机电流把 MCU 拉挂
• 保护：反接保护、保险丝/自恢复保险、EMI/ESD（至少在电源入口做）

0x06 舵机控制与动作分解（推进/夹持/旋转）

建议把每一个“魔方动作”拆成固定序列，例如：

1. 伸出（推进到位）
2. 夹紧（夹持到位）
3. 旋转（按角度转动：90/180/-90）
4. 松开
5. 退回（回到安全位置）

配合限位/时间保护：

• 超时未到位 -> 停机并回到松手状态
• 夹持不到位 -> 不允许旋转（避免打滑/飞方块）

0x07 材料与器件选择

1. 魔方：5.7cm 三阶，优先顺滑/容错；需要能手动调紧度。
2. 蓝牙：HC-05（经典蓝牙，串口透明传输好用）或 HM-10（BLE），下位机通常做从机。
3. 舵机：主舵机优先扭矩与响应，辅舵机优先稳定；别忽视峰值电流。
4. 机械：亚克力板/铝型材、导轨/滑轮、螺丝、轴承；夹持面建议加硅胶垫。
5. 电源：优先选“舵机峰值电流足够”的电源适配器 + DC-DC。

0x08 其他

• 颜色识别鲁棒性：光照变化、黄/橙混淆、反光
• 机械误差：夹持偏心、推进不到位、转动回差
• 闭环纠错：执行若干步后重新识别校验（不必每一步都闭环）