第 1 篇：服务型机器人整体软件架构：Android、Linux 主控、MCU 与云端到底如何分工？
做 Android App 的时候我们通常面对的系统比较简单Android App ↓ HTTPS / WebSocket ↓ 云端服务器但是到了服务机器人项目里系统一下子就变复杂了。机器人里面不仅有 Android还有 Linux 主控、MCU、底盘、电机、传感器机器人外面还有手机 App 和云端平台。一个比较典型的服务机器人整体可能是这样的云端平台 ↑ MQTT / HTTPS / WebSocket ↓ Linux 机器人主控 ↑ ↓ TCP 串口 / CAN ↑ ↓ Android 控制屏 MCU ↓ 电机 / 灯光 / 柜门 传感器 / 底盘 / 执行器理解这张图基本就理解了服务机器人软件架构的一半。这也是这一季首先要解决的问题一台服务机器人里面到底有哪些计算单元它们分别负责什么一、为什么机器人里面会同时存在 Android、Linux 和 MCU刚开始接触机器人项目的时候很容易产生一个疑问既然机器人上已经有 Android 平板了为什么不能所有功能都直接由 Android 来控制比如Android ↓ 控制电机 ↓ 读取传感器 ↓ 控制灯光 ↓ 控制柜门理论上不是完全做不到。但在真正的机器人系统里一般不会这么设计。原因在于机器人不同的软件模块对实时性、稳定性、硬件访问能力和业务复杂度的要求完全不同。所以通常会把系统拆成不同层级。业务交互层 Android ↓ 机器人控制层 Linux 主控 ↓ 硬件控制层 MCU ↓ 物理设备 电机 / 传感器 / 灯光 / 柜门 / 底盘每一层解决不同的问题。而不是让一个系统把所有事情全干了。二、Android机器人的业务与交互控制端服务机器人上最容易看到的部分通常就是机身上的 Android 屏幕。比如首页任务选择地图展示视频画面设备状态用户交互设置页面运维页面这些功能非常适合 Android。所以在整个机器人架构里Android 更像是机器人上层业务控制端 人机交互端。它负责的是“业务”。例如用户点击前往会议室Android 并不会直接告诉左轮左轮转速 120rpm 右轮转速 115rpm它更可能发送的是GO_TO_POINT pointId meeting_room_01也就是说Android 关心的是机器人要做什么而不是电机具体怎么转这两个层级一定要分开。因此在你的这套系列规划里Android 被明确定位为业务与交互控制端而不是底盘控制器。三、Linux 主控机器人的“大脑”Android 下面通常还有一块真正的机器人主控。很多机器人主控运行 Linux。这一层可以理解为机器人的核心控制中心。比如 Android 发出导航到 A 点真正处理这个任务的通常不是 Android。而是 Linux 主控。它可能需要协调地图 定位 导航 底盘 传感器 任务状态 异常状态整个过程可能类似Android │ │ GO_TO_POINT ↓ Linux 主控 │ ├── 查询当前定位 ├── 获取地图 ├── 计算/调用导航 ├── 控制底盘移动 ├── 检测障碍物 └── 判断任务是否完成然后主控再把状态告诉 AndroidNAVIGATION_START NAVIGATING ARRIVED NAVIGATION_FAILEDAndroid 根据这些状态更新 UI。所以两者的职责其实非常清楚Android 负责 用户想让机器人做什么 Linux 主控 负责 机器人怎么把这件事情完成四、MCU真正贴近硬件的一层再往下就是 MCU。例如STM32 ESP32 其他单片机MCU 更接近真实硬件。它可能负责电机 编码器 灯光 传感器 柜门 锁控 托盘 急停 电源这些设备往往通过UART RS485 CAN GPIO之类的方式连接。所以机器人里面很常见的一条链路就是Android ↓ TCP Linux 主控 ↓ 串口 / CAN MCU ↓ 硬件例如用户在 Android 上点击打开柜门真正的执行链路可能是Android ↓ OPEN_DOOR ↓ Linux 主控 ↓ 转换成底层硬件指令 ↓ MCU ↓ 驱动锁控模块 ↓ 柜门打开执行完成以后再逐层回传MCU ↓ Linux 主控 ↓ Android最终界面显示柜门已打开这就是一个非常典型的机器人控制链路。五、为什么 Android 不直接控制 MCU看到这里很容易想到既然 Android 最后还是要控制 MCU那能不能直接变成Android ↓ 串口 ↓ MCU有些简单设备确实可以这么做。但对于完整机器人来说一般还是会保留 Linux 主控这一层。因为一旦系统复杂起来Android 很快就会承担过多职责。例如地图 导航 定位 底盘 传感器 任务 硬件协议 UI 视频 网络 云端全部堆到 Android 上系统会变得非常难维护。而引入 Linux 主控以后就可以形成非常清晰的职责边界。┌──────────────────────┐ │ Android │ │ UI / 业务 / 用户交互 │ └──────────┬───────────┘ │ TCP ┌──────────▼───────────┐ │ Linux 主控 │ │ 导航 / 任务 / 设备控制│ └──────────┬───────────┘ │ CAN / 串口 ┌──────────▼───────────┐ │ MCU │ │ 实时硬件控制 / IO │ └──────────┬───────────┘ ↓ 真实硬件这样每一层只负责自己擅长的事情。六、云端在机器人系统里负责什么除了机器人本体还有一个非常重要的部分云端平台。云端和机器人本体的职责又不一样。比如设备管理 用户管理 机器人绑定 远程任务 历史记录 告警 OTA 日志 远程状态这些能力通常不会只存在机器人本地。而是放到云端。因此整个系统开始变成手机 App │ HTTPS │ ↓ 云平台 │ MQTT / HTTPS │ ↓ Linux 主控 │ ┌────────┴────────┐ │ │ TCP 串口 / CAN │ │ ↓ ↓ Android 控制屏 MCU │ ↓ 硬件这时候实际上已经出现了三个控制入口机身 Android 屏 手机 App 云端平台后面甚至还会有机器人自主任务所以服务机器人并不是简单的App → 机器人而是一个多端协同系统。七、服务机器人实际上存在三条控制链路从整体架构来看可以把机器人控制大致理解成三条链路。第一条是1. 本地控制Android 控制屏 ↓ TCP Linux 主控 ↓ 机器人例如点击开始巡航 打开柜门 回充 停止任务 切换模式特点是距离近、实时性高、不依赖公网。第二条是2. 机器人自主运行Linux 主控 ↓ 任务系统 ↓ 导航 / 底盘 / 传感器例如自主巡航 自动回充 自动避障 执行预设路线这时候即使 Android 页面退出了机器人也不应该停止工作。因为真正执行任务的是机器人主控。第三条是3. 远程云控手机 App ↓ 云端 ↓ 机器人主控例如远程查看状态 远程创建任务 远程查看视频 远程控制设备这三条链路也是你这份第二季规划里第一篇要先建立起来的整体认知。八、一个完整指令到底是怎么跑起来的例如用户站在机器人面前在 Android 屏幕点击“前往前台”整个过程可能是① Android 用户点击 前往前台 ↓ ② Android 业务层 构造指令 GO_TO_POINT pointId FRONT_DESK ↓ ③ TCP 发送给机器人主控 ↓ ④ Linux 主控 接收指令 ↓ 创建导航任务 ↓ 启动定位 / 导航 ↓ 控制机器人移动 ↓ ⑤ MCU / 底盘 控制电机 读取传感器 ↓ ⑥ Linux 主控 持续产生状态 NAVIGATING ARRIVED ↓ ⑦ TCP 状态回传 Android ↓ ⑧ Android 更新页面 正在前往前台 ↓ 已到达前台从这个过程就能看到Android 并没有控制电机。它做的是用户交互 ↓ 业务指令 ↓ 状态展示Linux 主控负责真正执行任务MCU负责真正驱动硬件九、理解这套分层以后很多机器人问题都会变简单以前看机器人项目很容易感觉TCP MQTT CAN 串口 Android Linux MCU 云端东西特别多。但把它们放进软件分层以后其实就清楚了。用户 / 运维人员 ↓ ┌─────────────────────┐ │ Android / 手机 App │ │ 业务与交互层 │ └──────────┬──────────┘ ↓ ┌─────────────────────┐ │ Linux 主控 │ │ 机器人核心控制层 │ └──────────┬──────────┘ ↓ ┌─────────────────────┐ │ MCU │ │ 硬件控制层 │ └──────────┬──────────┘ ↓ 电机 / 底盘 / 灯光 / 柜门 / 传感器云端则在机器人之外为整个机器人系统提供设备 任务 状态 数据 远程控制能力。这也是为什么服务机器人软件不能只从 Android App 的角度去理解。真正的软件架构是Android Linux 主控 MCU 云端共同组成的一套系统。十、总结这一篇最重要的不是记住某一种协议。而是先建立服务机器人软件的分层模型Android 负责业务与人机交互 ↓ Linux 主控 负责机器人任务与核心控制 ↓ MCU 负责实时硬件控制 ↓ 硬件 负责真正执行动作同时云端 负责设备、任务、状态和远程管理因此一台完整的服务机器人本质上并不是一个 Android 设备。它更像一个由多个计算单元组成的分布式小型系统。而 Android只是其中非常重要的一层。理解了这一层关系以后下一个问题自然就出现了Android 控制屏和 Linux 机器人主控之间到底应该怎么通信在实际服务机器人项目里一个非常典型的方案就是Android ↕ TCP 长连接 ↕ Linux 主控那么问题来了为什么这里经常选择原生 TCP而不是 HTTP、WebSocket 或 MQTT这就是下一篇要讲的内容下一篇《Android 控制屏为什么与机器人主控使用 TCP 长连接》
