上一篇我们讲到机身 Android 与 Linux 主控通过 TCP 通信时一条可靠机器人指令不能只是send(command)它还需要管理CommandId / Sequence Pending Ack Timeout Retry Result 幂等当这些能力逐渐集中以后我们可以把 Android 里的这一层抽象成Command Center也就是指令中心。但是写到这里一个非常有意思的问题出现了。以前做割草机器人时手机 App 也会控制机器人开始割草暂停继续停止回充为什么当时手机 App 里似乎没有这样一个Command Center难道割草机器人不需要AckTimeoutRetry幂等这些机制吗当然不是。继续把两套架构放在一起看就会发现服务机器人和割草机器人都需要指令中心。真正不同的是指令中心部署在什么位置。一、先看服务机器人Android 就是直接控制端我们目前讨论的服务机器人是机身 Android ↓ TCP Linux 主控 ↓ MCU ↓ 硬件Android 本身就是机器人上的本地控制终端。用户点击打开柜门Android 直接生成OPEN_DOOR sequence 1001通过 TCP 发送给Linux 主控因此 Android 很自然就需要维护Sequence PendingCommand Ack Timeout Retry Result于是架构可以抽象成机身 Android ┌──────────────────┐ │ Command Center │ │ │ │ CommandId │ │ Pending │ │ Timeout │ │ Retry │ │ Lifecycle │ └────────┬─────────┘ │ TCP │ ┌────────▼─────────┐ │ Linux 主控 │ │ Command Handler │ └────────┬─────────┘ │ 机器人能力这里Command Center就在Android。二、为什么 Command Center 会放在 Android因为这个架构里Android就是直接指令发起端。它知道用户刚才点了什么。它知道这条 Command 的 Sequence。它也直接接收AckResult。因此维护PendingCommand非常自然。例如1001 OPEN_DOOR WAIT_ACKAndroid 收到ACK 1001更新ACKED收到RESULT 1001 SUCCESS结束Command Lifecycle所以在这种本地一对一直接控制场景下Command Center 可以放得非常靠近控制端。三、再看割草机器人架构完全不一样割草机器人远程控制通常不是手机 App ↓ TCP ↓ 割草机器人而更接近手机 App ↓ HTTPS 云端 ↓ MQTT 割草机器人机器人执行以后再割草机器人 ↓ 云端 ↓ 手机 App例如用户点击开始割草App 实际执行的可能更像POST /mowing/start也就是说手机 App 首先是在向Cloud发起一个业务请求。四、真正给割草机下发 Command 的是谁继续向下看。云端收到开始割草以后可能会执行校验用户 ↓ 校验设备 ↓ 创建任务 / 指令 ↓ 生成 commandId / taskId ↓ 保存状态 ↓ 通过 MQTT 下发机器人于是Cloud START_MOWING ──────────────── Robot这时候真正直接面对机器人执行端的其实已经不是手机 App而是Cloud所以CommandId Pending Timeout Retry Result这些能力真正更加合适的位置就变成了云端五、于是割草机器人也存在 Command Center只是位置不同。可以抽象成手机 App │ │ HTTPS ▼ ┌──────────────────┐ │ Cloud │ │ │ │ Command Center │ │ │ │ commandId │ │ Pending │ │ Timeout │ │ Retry │ │ Result │ │ Task State │ └────────┬─────────┘ │ MQTT │ ┌────────▼─────────┐ │ Mower Robot │ │ Command Handler │ └────────┬─────────┘ │ 执行任务所以割草机器人不是没有指令中心。而是指令中心从客户端移动到了云端。六、为什么不能让手机 App 自己做割草机 Command Center假设Pending Timeout Retry全部由手机 App 管理。会有什么问题比如用户点击开始割草然后手机退出 App。或者手机断网。甚至手机直接关机。难道机器人任务生命周期就没人管了吗显然不能。割草机器人执行任务可能持续几十分钟 几小时所以它的 Command 生命周期必须独立于手机 App 生命周期而云端本身长期在线非常适合承担指令状态 任务状态 超时 重试 历史结果所以对于远程机器人Command Center放在云端会更加合理。七、手机 App 在割草机器人里负责什么那手机 App 是不是就完全不管 Command 了不是。它仍然负责用户发起操作 展示操作中状态 显示任务结果 订阅机器人最新状态但是它不需要承担机器人指令生命周期的最终事实源例如手机 App ↓ 开始割草 ↓ CloudCloud 返回请求已接受 taskId 888后面 App 主要观察CREATED DISPATCHED RUNNING PAUSED RETURNING COMPLETED FAILED所以 App 更像任务操作端 状态展示端。八、服务机器人和割草机器人的区别终于清楚了把两套架构放在一起。服务机器人本地控制用户 ↓ 机身 Android ↓ Command Center ↓ TCP Linux 主控 ↓ Command Handler ↓ 机器人执行这里Command Center Android割草机器人远程控制用户 ↓ 手机 App ↓ HTTPS Cloud ↓ Command Center ↓ MQTT Robot ↓ Command Handler ↓ 机器人执行这里Command Center Cloud所以两者的本质差异并不是有没有指令中心 而是指令中心在哪里 。九、继续抽象所有指令系统都可以分成两端现在可以进一步把具体机器人去掉。抽象以后其实就是┌────────────────────┐ │ Command Center │ │ │ │ create │ │ commandId │ │ pending │ │ timeout │ │ retry │ │ lifecycle │ └──────────┬─────────┘ │ 通信协议 │ ┌──────────▼─────────┐ │ Command Handler │ │ │ │ receive │ │ validate │ │ deduplicate │ │ execute │ │ idempotency │ │ result │ └──────────┬─────────┘ │ 机器人能力一个负责管理指令。一个负责执行指令。十、Command Center 负责什么Command Center 更关注Command 怎么创建 CommandId 怎么生成 有没有 Pending 多久算 Timeout 是否允许 Retry 现在处于什么状态 最终 Result 是什么它关心的是指令生命周期。例如CREATED ↓ SENT ↓ ACKED ↓ EXECUTING ↓ SUCCESS或者SENT ↓ TIMEOUT ↓ RETRY ↓ FAILED十一、Command Handler 负责什么机器人执行侧更加关注收到 Command ↓ 解析 ↓ 校验 ↓ 判断是否重复 ↓ 判断当前机器人是否允许执行 ↓ 调用机器人能力 ↓ 返回 Result例如OPEN_DOORLinux 主控需要检查 sequence ↓ 是否已经执行过 ↓ 没有 ↓ DoorService.openDoor() ↓ MCU ↓ 返回 SUCCESS所以Command Handler 解决的是这条指令如何安全、正确地执行。十二、为什么两边都要保存 CommandId这是实现可靠性的关键。例如Command CentercommandId 1001第一次发送1001 OPEN_DOOR执行端Command Handler收到以后记录1001 → SUCCESS结果返回过程中丢失。Command CenterTIMEOUT于是重试1001 OPEN_DOORCommand Handler 发现1001已经执行过。于是不重复执行直接返回SUCCESS这时候Command Center Command Handler共同完成了可靠重试 幂等。十三、服务机器人和割草机器人只是部署位置不同现在再看两套系统。服务机器人Command Center 运行在 Android Command Handler 运行在 Linux 主控割草机器人Command Center 运行在 Cloud Command Handler 运行在机器人主控于是可以得到一个很重要的架构结论Command Center 是一个逻辑角色而不是固定属于某个平台的软件模块。它可以运行在Android Cloud Linux 主控 甚至独立的调度服务具体放哪里要看控制链路 网络拓扑 任务持续时间 客户端生命周期 可靠性要求十四、本地控制为什么更靠近机器人服务机器人机身 AndroidAndroid ↕ TCP Linux就在同一台机器人内部。特点是低延迟 长期连接 一对一 本地网络 控制实时性高所以 Command Center 放在 Android路径最短。十五、远程控制为什么更靠近云端割草机器人App ↓ Internet ↓ Cloud ↓ Internet ↓ Robot特点是设备长期在线 手机可能随时退出 任务持续时间长 需要历史记录 需要多客户端同步所以 Command Center 放在云端更稳定。十六、这也解释了为什么机器人云平台需要“指令中心”如果以后平台中只有一台割草机器人云端 Command Center 可能只是某个 Spring Boot 模块。但如果以后变成1000 台机器人 10000 台机器人那么Command Center本身就可能逐渐变成一个明确的平台能力。例如负责指令创建 设备路由 MQTT 下发 回执 超时 重试 幂等 状态持久化 指令历史这时候架构就可能变成App ↓ API ↓ Task Service ↓ Command Service ↓ MQTT Broker ↓ Robot也就是说我们现在从 Android TCP 里抽象出来的 PendingCommand最终可以一路演化成云平台里的 Command Service。十七、Task Center 和 Command Center 又是什么关系这里再提前埋一个后面云平台会遇到的问题。任务和指令不是同一个概念。例如巡航一圈是一个Task但这个任务执行过程中可能产生很多 CommandSTART_NAVIGATION GO_TO_POINT_A GO_TO_POINT_B RETURN_CHARGE所以可以理解成Task Center ↓ 产生 / 编排 ↓ Command Center ↓ RobotTask 关心业务目标。Command 关心具体控制动作。这两个概念以后到了机器人云平台里会越来越重要。十八、回头再看两种机器人很多东西其实已经统一了服务机器人Android Command Center ↓ TCP Linux Command Handler割草机器人Cloud Command Center ↓ MQTT Robot Command Handler虽然TCP和MQTT完全不同部署位置也不同。但上层架构其实都是指令产生 ↓ 生命周期管理 ↓ 可靠传输 ↓ 执行端去重 ↓ 机器人执行 ↓ 结果返回所以通信协议可以不同但可靠指令模型可以复用。十九、机器人指令架构真正应该关心什么当我们不再只盯着TCP MQTT以后会发现真正需要解决的是谁创建 Command 谁拥有 commandId 谁维护 Pending 谁判断 Timeout 谁负责 Retry 谁负责幂等 谁保存 Result 谁是这条指令的最终事实源这些问题确定以后Command Center 应该部署在哪里其实也就基本确定了。二十、总结服务机器人和割草机器人看起来采用了完全不同的通信架构。服务机器人机身 Android ↓ TCP Linux 主控割草机器人手机 App ↓ HTTPS Cloud ↓ MQTT Robot但继续抽象以后会发现两套系统都需要可靠的指令管理机制。可以统一成Command Center ↓ Communication ↓ Command Handler ↓ Robot Capability其中服务机器人Android Command CenterLinux 主控Command Handler而割草机器人Cloud Command CenterRobotCommand Handler因此真正的区别不是有没有指令中心。而是指令生命周期由谁负责以及这个指令中心部署在哪一层。本地强控制场景Command Center 更靠近机器人远程设备控制场景Command Center 更靠近云端大型机器人平台继续发展以后Command Center甚至可能进一步成为独立的平台服务。从这一点也能看到我们现在虽然是在讲Android TCP但真正逐渐建立起来的已经不是一个 Android 通信模块。而是一套可以从移动端一直复用到云平台的机器人可靠指令架构。下一篇回到原来的主线第 6 篇《Android、机器人主控、MCU 与硬件到底如何分层》