上一篇我们讨论了服务机器人为什么会存在多个控制入口。例如机身 Android 手机 App Cloud AUTO Task Maintenance这些入口最终可能都会要求机器人开始任务 停止任务 前往某个点位 返回充电 打开柜门所以机器人不能简单采用谁最后发送 Command 就执行谁而需要Control Arbiter也就是控制权仲裁。但是继续往下分析以后又会出现一个新的问题。手机远程控制机器人时本身就要经过 Cloud手机 App ↓ Cloud ↓ Robot那么 Cloud 要不要做一次控制权仲裁如果 Cloud 已经判断ALLOW机器人本地为什么还要再判断一次再往下Linux 主控已经允许执行为什么 MCU 还可能拒绝电机动作也就是说为什么一条机器人指令可能要经过不止一次“允许 / 拒绝”判断这一篇我们就把这个问题彻底拆开。一、先看一个最简单的远程控制场景假设用户在手机 App 上点击RETURN_TO_CHARGE控制链路手机 App ↓ Cloud ↓ MQTT 机器人 Linux 主控 ↓ Navigation ↓ Chassis ↓ MCU ↓ Motor表面上看这似乎只是一条RETURN_TO_CHARGE指令。但真正执行过程中至少会遇到三个完全不同的问题。第一个问题这个用户有没有资格让这台机器人回充第二个问题机器人当前状态允不允许执行回充第三个问题底盘当前物理状态允不允许移动这三个问题显然不是一个层级的问题。所以Control Arbitration天然就会出现分层。二、可以把它先抽象成三级一个比较完整的机器人控制体系可以理解成第一级 Cloud Global Arbiter “业务上能不能下发” ↓ 第二级 Robot / Linux Arbiter “机器人现在能不能执行” ↓ 第三级 MCU Safety Interlock “物理上能不能安全执行” ↓ Hardware这三层看起来都在做ALLOW / REJECT但是它们检查的条件完全不同。所以这不是重复判断而是分层防线。三、第一级Cloud Control Arbiter先看 Cloud。手机 App 发起RETURN_TO_CHARGECloud 首先掌握的是全局业务信息。例如当前用户是谁 机器人属于谁 这个用户有没有控制权限 当前是否已经有人在远程控制 当前是不是已经存在冲突任务 是不是另一个 App 已经获得控制权 设备是否在线 远程控制租约是否有效这些信息最适合谁判断当然是Cloud因为机器人本地通常根本不知道这个用户的账号权限。四、Cloud 仲裁解决的是“全局业务问题”例如用户 A 和用户 B 同时打开 App。用户 ASTART_TASK用户 BRETURN_TO_CHARGE机器人本地可能只看到Command A Command B但 Cloud 知道User A 设备管理员 User B 普通查看用户所以 Cloud 可以直接User A → ALLOW User B → REJECT机器人根本不需要收到用户 B 的控制指令。这就是 Cloud Arbiter 的价值。五、Cloud 还可以管理“远程控制权”假设一个服务机器人支持远程人工控制。用户 A 已经获得REMOTE CONTROL此时用户 B 又尝试接管。Cloud 可以维护Control Owner例如owner userA mode REMOTE leaseId abc123用户 B 请求TAKE_CONTROLCloud 判断当前已有远程控制者于是REJECT reason REMOTE_CONTROL_OCCUPIED这种多用户 多 App 账号权限 控制租约问题显然非常适合在云端解决。六、为什么可能还需要 Control Lease假设用户 A 获得了远程控制权。然后手机断网Cloud 不能永久认为userA还在控制机器人。所以可以设计Control Lease例如owner userA expiresAt 10s later客户端需要持续renew如果长时间没有续约Control Lease ExpiredCloud 就可以释放REMOTE CONTROL这和分布式系统中的Lease思想非常接近。七、Cloud ALLOW 到底意味着什么这里一定要建立一个重要认知。Cloud 返回ALLOW并不代表机器人必须执行。它真正表示的是从云端当前掌握的全局业务状态来看这条指令允许被下发。也就是Cloud ALLOW 允许发送给 Robot而不是Cloud ALLOW Robot 必须执行这两个概念完全不同。八、为什么 Robot 还必须再做一次仲裁因为 Cloud 不掌握机器人此刻最真实的本地状态。例如 Cloud 当前记录mode REMOTE state IDLE于是允许RETURN_TO_CHARGE但是就在几百毫秒前现场用户通过机身 Android切换 LOCALLinux 当前真实状态已经变成mode LOCAL只是最新状态还没有来得及同步到 Cloud。这时候如果机器人完全相信 CloudCloud ALLOW ↓ 直接执行远程命令就可能和现场控制发生冲突。所以机器人本地必须重新判断一次。九、第二级Robot / Linux Control Arbiter对于服务机器人来说真正的本地控制入口可能是Cloud │ │ 机身 Android ──────┼──→ Linux │ AUTO Task ─────────┤ │ Maintenance ───────┘这几个入口最终真正汇聚的位置是Linux 主控所以 Linux 这一层应该知道当前 ControlMode 当前 ControlOwner 当前任务 当前 Navigation 状态 当前是否 Maintenance 当前是否有人 Local 接管 当前机器人实际运行状态因此机器人本地 Control Arbiter 通常应该靠近 Linux 主控。十、Linux Arbiter 判断的不是“这个用户是谁”例如远程收到RETURN_TO_CHARGELinux 通常没有必要重新判断这个用户是不是 VIP 账号是否过期 设备是不是属于这个用户这些 Cloud 已经处理。Linux 真正关心的是当前是不是 LOCAL 机器人是不是正在 MAINTENANCE 当前 AUTO Task 能不能被打断 机器人是不是正在执行另一项高优先级任务 当前 Navigation 是否允许启动新目标 当前状态是不是 CHARGING 是不是已经处于 RETURNING这些属于本地机器人状态。十一、服务机器人为什么尤其依赖本地仲裁因为它有一个非常重要的入口机身 Android ↓ TCP Linux这条链路根本不经过 Cloud。例如手机 App ↓ Cloud ↓ RETURN_TO_CHARGECloud 判断ALLOW但与此同时现场用户机身 Android ↓ STOP_TASK甚至切换到 LOCALCloud 很可能还不知道这件事情。但是 Linux 知道。所以Linux Control Arbiter必须成为机器人本地控制状态的最终事实源。十二、一个服务机器人指令可以这样走例如手机远程点击RETURN_TO_CHARGE第一步手机 App ↓ CloudCloud 判断用户权限 ✓ 设备归属 ✓ 远程控制权 ✓ 任务冲突 ✓于是Cloud Arbiter → ALLOW然后Cloud Command Center ↓ MQTT LinuxLinux 收到以后Command Handler先解析RETURN_TO_CHARGE然后进入Robot Control Arbiter继续判断currentMode ? controlOwner ? currentTask ? robotState ? navigationState ?假设发现currentMode LOCAL那么Robot Arbiter → REJECT返回reason LOCAL_CONTROL_ACTIVE这是完全正常的。十三、所以Cloud ALLOW Robot REJECT 并不矛盾因为两边回答的问题不同。Cloud这个远程请求 从全局业务角度 允许发送Robot但从机器人此刻真实状态来看 现在不能执行所以Cloud ALLOW Robot REJECT完全可能。甚至是一个成熟系统必须允许出现的情况。十四、那 Linux ALLOW 以后是不是就一定执行仍然不一定。因为下面还有MCU以及真实硬件。假设 Linux 判断当前 REMOTE 没有任务冲突 Navigation 正常 允许回充于是Robot Arbiter → ALLOW然后 Navigation 开始控制底盘linearVelocity 0.5m/s但就在此刻底盘检测到急停按下怎么办当然还是不能动。十五、第三级MCU Safety Interlock这里我更愿意叫Safety Interlock而不是继续全部叫Control Arbiter因为 MCU 做的已经不是业务控制权仲裁。而是实时物理安全保护。它可能检查Emergency Stop Bumper Cliff Sensor Motor Overcurrent Driver Fault Watchdog Communication Lost Temperature Hardware Limit如果任何一个条件触发BLOCK即使 Linux 发MOVE_FORWARDMCU 仍然拒绝执行甚至直接切断电机输出十六、为什么 Safety 不能只放 Linux因为 Linux 本身也可能卡死 线程阻塞 进程崩溃 通信异常 系统负载过高如果安全保护完全依赖Linux那么 Linux 出问题时安全能力也跟着失效。所以一些关键保护需要继续下沉到MCU Safety Controller 甚至纯硬件电路例如物理急停可以设计成急停按钮 ↓ Safety Circuit / MCU ↓ Motor Driver直接阻止电机输出。它不应该要求Android ↓ TCP Linux ↓ CAN MCU完整链路正常以后才能停车。十七、所以 STOP_TASK 和 Emergency Stop 属于不同层例如STOP_TASK属于业务控制。可能经过Command Center ↓ Control Arbiter ↓ Task Manager ↓ Navigation ↓ 平滑停止它会考虑任务状态 业务结果 云端同步而EMERGENCY STOP关注的是先让危险动作停下来它甚至可以绕开Task Manager直接作用到Chassis / Motor因此STOP_TASK ≠ EMERGENCY_STOP一个是业务停止。一个是安全停止。十八、现在再看割草机器人割草机器人也存在控制仲裁。只是它和服务机器人控制入口分布不同。割草机器人更常见的是手机 App ↓ Cloud ↓ Mower远程业务入口首先汇聚到Cloud所以 Cloud 可以承担很大一部分Global Control Arbiter例如用户权限 设备归属 远程控制权 计划任务冲突 手动任务和自动任务冲突 多客户端操作然后Cloud ↓ MQTT Mower十九、割草机器人本地为什么仍然需要判断例如 Cloud 下发START_MOWING云端认为用户权限 ✓ 设备在线 ✓ 当前没有任务冲突 ✓但是割草机器人此刻发现RTK / 定位不可用 电池过低 刀盘故障 机器人倾倒 急停按下 驱动故障那么机器人仍然必须REJECT例如reason POSITIONING_NOT_READY或者reason LOW_BATTERY所以割草机器人也是Cloud Global Arbiter ↓ Robot Local Check ↓ Safety ↓ Execution只是云端仲裁承担的比例更大。二十、服务机器人和割草机器人真正的差异在哪放在一起就很清楚。割草机器人App A ─┐ │ App B ─┼→ Cloud │ Global Arbiter 计划任务┘ ↓ MQTT ↓ Robot Local / Safety ↓ Chassis它的特点大多数外部业务控制首先汇聚 Cloud。服务机器人手机 App ↓ Cloud ───────────┐ │ 机身 Android ──────┼→ Linux │ Local Arbiter AUTO Task ─────────┤ │ Maintenance ───────┘ ↓ MCU Safety它的特点是存在机身 Android → TCP → Linux 这条绕过 Cloud 的本地控制链路。所以Linux Local Arbiter在服务机器人里会更加重要。二十一、这也解释了为什么服务机器人的控制体系更复杂割草机器人大量控制入口可以先Cloud统一。而服务机器人同时存在LOCAL REMOTE AUTO MAINTENANCE并且很多入口直接发生在机器人本体。所以 Linux 必须统一处理谁现在拥有控制权 哪一种 Mode 哪一个 Source 哪一种 Command 能不能抢占当前任务因此服务机器人会更明显地出现Robot Control Arbiter这个独立架构角色。二十二、这里还需要区分“普通底盘”和“智能底盘”我们前面一直说Linux Arbiter但实际项目中有时候大家会说控制仲裁在底盘。这句话是不是错不一定。如果所谓的智能底盘内部已经包含Linux ROS / ROS2 Navigation 底盘服务 MCU那么完全可以理解成Android ↓ TCP 智能底盘 Linux 【Control Arbiter】 ↓ 底盘 MCU所以工程上说控制权仲裁在底盘没有问题。但是如果所谓底盘只是STM32 Motor Driver Encoder Wheel那么更准确应该是Linux 主控 【业务 Control Arbiter】 ↓ 底盘 MCU 【Safety Interlock】普通 MCU 一般不应该负责LOCAL 和 REMOTE 谁优先 手机用户有没有远程控制权限 AUTO Task 能不能被 App 抢占这些属于上层业务逻辑。二十三、Cloud Arbiter 和 Command Center 也不是一回事前面的补充篇我们讲过Command Center它负责CommandId Pending Timeout Retry Result Command Lifecycle而Control Arbiter负责这条 Command 有没有资格继续向下执行所以 Cloud 里可能同时有Cloud ├── Command Center │ ↓ │ 管 Command 生命周期 │ └── Control Arbiter ↓ 管远程业务控制权两者可能属于同一个服务实现。也可能以后拆成不同模块。但逻辑职责要分开。二十四、Robot 端也是一样机器人 LinuxMQTT / TCP ↓ Command Handler ↓ Control Arbiter ↓ Task / Navigation / DeviceCommand Handler 负责解析 校验 去重 幂等Control Arbiter 负责当前是否允许执行Task / Navigation 负责真正完成机器人能力所以一个完整链路可以变成Command Center ↓ Communication ↓ Command Handler ↓ Control Arbiter ↓ Capability ↓ Hardware Adapter ↓ MCU Safety ↓ Hardware这时候前几篇内容就全部串起来了。二十五、三级系统各自掌握什么“事实”这是理解多级仲裁最好用的方法。Cloud掌握全局业务事实。例如用户是谁 设备属于谁 远程控制者是谁 任务历史 账号权限 远程 LeaseRobot / Linux掌握当前机器人执行事实。例如当前 ControlMode 当前 Task 当前 Navigation 当前 Local 控制者 是否 Maintenance 设备当前真实运行状态MCU / Safety掌握当前物理事实。例如急停有没有按下 电机有没有过流 碰撞有没有触发 驱动器是否故障 硬件是否允许输出所以可以记成Cloud 全局业务事实 ↓ Robot 本地执行事实 ↓ MCU 物理安全事实谁最接近事实谁负责这一层最终判断。二十六、这也是为什么状态不能只相信 Cloud假设 Cloud 显示Robot IDLE并不代表机器人此刻一定还是IDLE因为状态同步存在网络延迟 MQTT 延迟 数据库更新延迟 消息顺序Robot 本地状态永远更加接近当前真实执行情况。同样Linux 认为Motor READY也不代表下一毫秒电机一定能运行。MCU 可能刚刚检测OVER_CURRENT所以机器人控制必须接受越接近硬件状态越实时。二十七、最终执行原则越往下越有否决权这个模型还可以总结出一个非常重要的设计原则Cloud 可以允许 Robot 可以否决 MCU 还可以继续否决也就是Cloud ALLOW ↓ Robot ALLOW ↓ MCU ALLOW ↓ Execute任何一层REJECT最终都不能执行。例如Cloud ALLOW ↓ Linux ALLOW ↓ MCU REJECT 急停触发最终机器人不移动不能因为 Cloud 已经允许就强制绕过下面的安全系统。所以上层拥有调度权下层拥有基于真实状态的否决权。这个原则非常重要。二十八、但下层不能反过来越权做上层业务决策同样需要注意另外一面。MCU 有权因为Emergency Stop拒绝运动。但是 MCU 不应该自己判断User A 比 User B 权限高Robot Linux 可以判断当前 LOCAL 所以拒绝 REMOTE但它通常不需要维护整个用户会员体系 账号权限 组织结构所以好的分层不是大家什么都判断一遍。而是每一层只判断自己最了解的事实。二十九、把一个远程回充完整走一遍用户RETURN_TO_CHARGE第一层手机 App ↓ CloudCloud Arbiter用户权限 ✓ 设备归属 ✓ 远程控制权 ✓ 业务任务冲突 ✓ ↓ ALLOWCommand Center创建 commandId 1001然后MQTT ↓ RobotRobot Command Handler解析 去重 校验进入 Robot Control ArbiterLOCAL 是否正在控制 否 MAINTENANCE 否 当前任务允许中断 是 当前 RobotState 允许回充 是 ↓ ALLOW进入Navigation产生底盘控制setVelocity(...)MCU SafetyEmergencyStop 否 Bumper 否 DriverFault 否 Watchdog 正常 ↓ ALLOW最后Motor Execute这才是一条完整的机器人控制链路。三十、如果中途被拒绝怎么办假设 CloudALLOW但是 RobotREJECT reason LOCAL_CONTROL_ACTIVE机器人应该把结果上报commandId 1001 status REJECTED reason LOCAL_CONTROL_ACTIVECloud Command Center 更新1001 REJECTED手机 App 最终显示机器人当前正在本地控制 暂时无法远程回充这时候用户看到的是业务拒绝。而不是请求失败或者网络异常这就是前面 Command / Result 设计继续发挥作用的地方。三十一、多级仲裁其实和前面所有文章都连起来了回头看第二季前面几篇TCP 长连接解决Android 和 Linux 怎么长期通信粘包半包解决TCP 字节流怎么还原消息Command / Ack / Retry 解决指令怎么可靠执行Command Center 解决谁管理指令生命周期Android / Linux / MCU 分层解决能力应该属于谁多控制入口解决Command 可能从哪里来而这一篇的多级仲裁解决这么多 Command 到底哪些有资格继续向下执行整个体系开始完整起来。三十二、最终可以得到一张机器人控制架构图手机 App / 管理后台 ↓ ┌───────────────┐ │ Cloud │ │ │ │ Control │ │ Arbiter │ │ │ │ Command │ │ Center │ └───────┬───────┘ │ MQTT ↓ ┌─────────────────┐ │ Robot / Linux │ │ │ TCP ───→│ Command Handler │ ↑ │ │ │ │ Control Arbiter │ │ │ │ │ │ Task / Nav │ │ └────────┬────────┘ │ │ │ CAN / Serial │ ↓ │ ┌─────────────────┐ │ │ MCU / Safety │ │ │ │ │ │ E-Stop │ │ │ Bumper │ │ │ Overcurrent │ │ │ Watchdog │ │ └────────┬────────┘ │ ↓ │ Hardware │ 机身 Android从上到下分别回答Cloud 业务上能不能下发 ↓ Linux 机器人现在能不能执行 ↓ MCU 物理上能不能安全执行三十三、总结机器人里的Control Arbiter并不一定只有一个。对于复杂机器人系统很自然会形成Cloud Global Control Arbiter ↓ Robot / Linux Control Arbiter ↓ MCU Safety Interlock三层检查。Cloud 负责全局业务控制。主要判断用户权限 设备归属 远程控制权 多客户端冲突 任务冲突 Remote LeaseRobot / Linux 负责本地执行控制。主要判断LOCAL / REMOTE / AUTO / MAINTENANCE 当前 Task 当前 RobotState Local Android 控制权 Navigation / Chassis 状态 Command 是否允许抢占MCU / Safety 负责实时物理安全。主要判断急停 碰撞 防跌落 驱动器故障 过流 Watchdog 失联保护最终判断所以Cloud ALLOW ≠ Robot 必须执行而是Cloud 业务允许 ↓ Robot 本地允许 ↓ MCU 安全允许 ↓ Execute越靠近机器人和硬件越掌握最新的真实状态。因此上层负责调度下层保留基于真实状态和安全条件的否决权。如果是割草机器人App ↓ Cloud Global Arbiter ↓ Mower Local / Safety ↓ Hardware由于远程业务入口主要经过 Cloud云端承担的全局控制仲裁会更多。如果是服务机器人手机 → Cloud ───┐ │ 机身 Android ───┼→ Linux Control Arbiter │ AUTO Task ──────┤ Maintenance ────┘ ↓ MCU Safety由于存在机身 Android ↓ TCP Linux这条本地直连控制链路Linux 主控就必须成为机器人本地控制状态的最终事实源。到这里我们可以把前面几个核心概念彻底区分开Command Center 解决 指令生命周期怎么管理 Control Arbiter 解决 这条指令有没有资格执行 Capability Owner 解决 这个机器人能力到底属于谁 Safety Interlock 解决 物理上是否允许安全执行这四个角色组合起来才逐渐形成一套真正完整的机器人可靠控制架构。下一篇回到正式主线第 8 篇《云柜机器人本质上是在服务机器人底座上增加了哪些能力》