Maestro：从多型号设备到统一机器人控制台

当机器人型号、通信协议和执行设备不断增加时，控制台不能继续堆叠“某型号专属页面”。Maestro 的核心任务，是建立统一设备模型，同时允许每种设备保留自己的能力差异。

多型号系统的真正难点

不同灵巧手可能使用经典 CAN、CAN FD 或 CANopen 402；关节数量、角度范围、触觉能力和命令周期也不同。机械臂与乐器机器人还会引入位姿、动作序列和多设备拓扑。

如果前端直接理解所有协议细节，页面很快会变成条件分支集合。更合理的分层是：

• 通信层负责收发帧；
• 设备层负责型号与协议；
• 能力层描述关节、传感器、动作和状态；
• 控制台只消费统一能力模型。

用能力而不是型号驱动界面

type DeviceCapabilities struct {
    JointCount      int
    SupportsTactile bool
    SupportsCANFD   bool
    SupportsArmPose bool
    Actions         []ActionDescriptor
}

型号仍然重要，但它不应该成为所有 UI 判断的唯一入口。界面更关心“是否有触觉数据”“是否支持全关节控制”“是否存在 ready / execute / return 动作”。

控制台的信息层级

机器人控制台中的信息很多，但不应该全部同时占据视觉中心。Maestro 将页面按操作频率和故障价值排序：

1. 设备管理：接口、型号、左右手、连接状态；
2. 执行控制：就绪、动作、循环、停止与回位；
3. 精细控制：关节滑条、速度、机械臂位姿；
4. 状态与日志：响应、错误、CAN ID 和原始数据。

这种布局可以让现场人员先确认设备是否正确，再执行动作；发生异常时，日志仍然在同一页面提供证据。

动作不是按钮，而是状态机

对于机械臂、灵巧手和乐器机器人，动作通常包含多个阶段：到达预设位姿、手部就绪、执行、保持、返回。一个“播放”按钮背后需要明确：

• 当前设备是否已连接；
• 是否满足动作需要的臂与手；
• 上一个动作是否结束；
• 失败后停止、重试还是回位；
• 循环次数和间隔如何生效。

READY → EXECUTING → HOLDING → RETURNING → IDLE
             ↓ error
          RECOVERING

把状态显式化后，前端按钮禁用、进度展示和后端错误恢复才能保持一致。

可观测性决定现场效率

现场最怕“看起来没反应”。因此日志需要包含时间、设备、接口、方向、CAN ID、数据和解析结果。设备拓扑检测失败时，还应逐接口说明缺少的是机械臂、灵巧手，还是预期的 CAN 口。

好的控制台不是隐藏复杂性，而是让复杂性在需要时可见。

跨平台不是最后再做

Windows 与 Linux 在 CAN 驱动、进程管理、路径和发布方式上差异明显。控制台若要真正跨平台，需要尽早隔离这些差异，并让前端只调用稳定 HTTP / WebSocket API。

前端使用 TypeScript 与 Vite，后端使用 Go，设备通信由统一库接管。这样 UI 可以在不同平台保持一致，平台相关问题集中在后端和发布层处理。

阶段性结论

统一控制台的关键不是让所有设备“看起来完全一样”，而是建立一致的操作语言：连接、能力、动作、状态、日志。差异被保留，但差异出现的位置是受控的。