做 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 主控
    │
    ├── 查询当前定位
    ├── 获取地图
    ├── 计算/调用导航
    ├── 控制底盘移动
    ├── 检测障碍物
    └── 判断任务是否完成

然后主控再把状态告诉 Android：

NAVIGATION_START
NAVIGATING
ARRIVED
NAVIGATION_FAILED

Android 根据这些状态更新 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 长连接？》