随着人形机器人、工业机器人、移动机器人和具身智能系统不断向复杂化发展机器人控制系统已经不再是一个简单的“传感器采集数据→控制器计算→电机执行”的单一闭环。现在一台机器人可能同时运行 ROS 2、ros2_control、EtherCAT、视觉识别、深度学习模型、SLAM、路径规划、语音交互、网络通信、日志系统以及大量后台服务。CPU 上同时存在几十甚至上百个线程并不奇怪。对于普通计算任务来说这种高度共享资源的架构能够充分利用硬件性能但对于机器人控制来说一个越来越现实的问题也随之出现如果 AI 推理突然卡住了怎么办如果视觉节点发生异常怎么办如果某个 ROS 2 Node 死循环了怎么办如果控制线程没有按时执行怎么办如果网络通信中断了怎么办更重要的是机器人发现异常以后能不能在规定的时间内进入安全状态这其实已经不是简单的“实时性”问题而是进一步进入了安全隔离问题。实时性解决的是“任务能不能按时完成”而安全性关注的是“系统出现异常以后能不能把风险控制在可接受范围内”。二者相关但并不是同一个概念。对于 ROS 2 机器人系统而言CPU 核心隔离、线程隔离、内存隔离、进程隔离解决的是不同类型的问题而安全隔离则需要进一步考虑故障检测、超时监测、看门狗、安全状态机以及执行机构的安全控制。换句话说实时系统解决的是“按时做正确的事”安全系统还需要解决“如果没按时做接下来怎么办”。这也是为什么当 ROS 2 从实验室机器人逐渐走向工业机器人、人形机器人和复杂具身智能系统时系统架构必须从“功能能不能运行”进一步走向“异常情况下系统还能不能被控制”。一、实时隔离和安全隔离不是一回事机器人为什么必须考虑“故障之后怎么办”理解安全隔离之前首先需要区分一个非常容易混淆的概念实时性 ≠ 安全性。假设一台机械臂有一个 1 kHz 的关节控制循环。1 kHz 意味着周期 1 / 1000Hz 1ms也就是说控制系统理论上每 1 ms 完成一次读取状态 ↓ 读取传感器/编码器 ↓ 控制算法计算 ↓ 生成控制指令 ↓ 发送给执行机构如果控制线程平均每 1 ms 执行一次但是偶尔突然用了 8 ms那么从实时系统角度看这已经出现了严重的 deadline miss。但是安全系统还会继续追问出现这次 8 ms 延迟以后系统做了什么如果控制任务没有及时执行控制任务 ↓ 应该在1ms内执行 ↓ 没有执行 ↓ 谁发现 ↓ 多久发现 ↓ 发现之后做什么 ↓ 如何让机器人进入安全状态这才是安全隔离真正关注的问题。例如一个机器人手臂正在高速运动。正常情况下传感器 ↓ ROS 2 ↓ 控制器 ↓ EtherCAT ↓ 伺服驱动器 ↓ 电机假设中间某个控制节点发生死循环控制节点 ↓ CPU占用100% ↓ 控制周期停止 ↓ 控制指令不再更新如果系统没有任何监测机制那么“实时控制线程停止运行”只是一个软件故障。但对于机器人来说这个软件故障可能最终演变成物理风险。因此一个更完整的机器人控制架构应该是┌───────────────┐ │ AI / Vision │ │ SLAM / Nav │ │ Planning │ └───────┬───────┘ │ ▼ ┌───────────────┐ │ ROS 2应用层 │ └───────┬───────┘ │ ▼ ┌───────────────┐ │ 控制任务 │ │ 1kHz Control │ └───────┬───────┘ │ ▼ ┌───────────────┐ │ 执行机构 │ └───────────────┘ ↑ │ ┌──────┴──────┐ │ Safety │ │ Monitor │ │ Watchdog │ └─────────────┘这里多出来的 Safety Monitor就是安全监控任务。它不一定负责正常情况下的机器人运动控制但需要持续判断控制任务是否还活着控制周期是否超时心跳是否正常关键传感器数据是否更新通信是否正常是否出现异常状态是否触发保护条件所以可以把两者简单理解为类型主要关注实时控制控制任务能否按时执行实时隔离其他任务是否影响控制任务故障检测能否及时发现异常安全隔离故障是否会传播到关键控制链路安全控制出现故障后如何进入安全状态这意味着一个真正面向复杂机器人的实时系统并不能只讨论“CPU够不够快”。真正需要讨论的是任务有没有时间边界、资源有没有边界、故障有没有边界。二、为什么AI、视觉和控制任务不能共用一个“故障域”从看门狗到安全状态机现在来看一个非常典型的机器人系统。假设机器人有 8 个 CPU 核心CPU 0 ─ AI CPU 1 ─ AI CPU 2 ─ Vision CPU 3 ─ SLAM CPU 4 ─ Planning CPU 5 ─ ROS 2 Communication CPU 6 ─ 1kHz Control CPU 7 ─ Safety Monitor这种设计的目的并不仅仅是提高性能。更重要的是建立一种故障边界。例如AI模型 ↓ GPU占用异常 ↓ AI线程长时间运行理想情况下AI异常 ↓ AI资源被限制 ↓ 控制CPU不受影响 ↓ 1kHz控制继续运行 ↓ Safety Monitor继续运行而不是AI异常 ↓ CPU资源争抢 ↓ 控制线程延迟 ↓ 控制周期超时 ↓ 没有监控 ↓ 机器人状态不可预测所以在复杂机器人中“隔离”并不是单纯为了跑得快而是为了让系统中的故障尽量不要跨越边界传播。这就是所谓的故障域Fault Domain。可以把机器人软件系统简单分成几个区域┌──────────────────────────────────────┐ │ 非实时计算域 │ │ AI / Vision / SLAM / UI / Logging │ └──────────────────────────────────────┘ ↓ 数据 ┌──────────────────────────────────────┐ │ 实时控制域 │ │ ros2_control / Control Loop │ │ 1kHz / 500Hz / State Estimation │ └──────────────────────────────────────┘ ↓ 控制 ┌──────────────────────────────────────┐ │ 安全监控域 │ │ Watchdog / Timeout / Safety State │ └──────────────────────────────────────┘ ↓ ┌──────────────────────────────────────┐ │ 执行机构 │ │ Servo / Motor / Brake / Drive │ └──────────────────────────────────────┘其中一个非常重要的设计原则是安全路径不要过度依赖普通业务路径。例如机器人视觉系统发现前方有人。一种架构可能是Camera ↓ AI Detection ↓ ROS 2 Node ↓ Planner ↓ Controller ↓ Motor这个链条非常长。任何一个环节出现异常都可能影响最终动作。如果把它作为唯一安全机制那么系统就会形成很长的故障传播链。另一种架构则会把安全机制单独设计正常运动链 Camera ↓ AI ↓ ROS 2 ↓ Planner ↓ Controller ↓ Motor 安全监控链 Watchdog / Safety Sensor ↓ Safety Logic ↓ Safe State ↓ Drive / Brake这样当正常业务链出现故障时安全链仍然可以工作。当然具体机器人产品是否采用独立安全控制器、安全 PLC、安全 MCU 或其他架构需要结合产品安全目标、硬件架构以及相关标准进行设计。不能简单理解为“增加一个 ROS 2 Node 就等于完成安全设计”。三、Watchdog为什么如此重要因为“发现控制线程死了”本身也是实时问题在机器人系统中看门狗Watchdog是非常典型的一种故障监控机制。它的基本思想非常简单控制任务 │ │ 周期性发送心跳 ▼ Watchdog │ ├── 正常 → 继续运行 │ └── 超时 → 触发故障处理例如Control Loop 1ms 2ms 3ms 4ms 5ms ...每一个周期都可以产生某种“活跃信号”。如果正常情况下Control → Heartbeat → Watchdog而某一次Control ↓ CPU被阻塞 ↓ Lock等待 ↓ 线程异常 ↓ 没有HeartbeatWatchdog就可以检测到异常。但是这里有一个很重要的问题Watchdog自己是不是实时的如果 Watchdog 和控制线程一样也被 AI、视觉、日志等任务严重干扰那么Control死了 ↓ Watchdog也没运行 ↓ 没人发现安全机制就失去了意义。因此安全监控任务本身也需要考虑CPU调度优先级CPU核心隔离IRQ干扰内存使用锁竞争通信延迟自身故障超时机制这再次说明实时性并不是某一个线程的属性而是整条关键任务链的系统属性。更进一步如果安全监控本身具有更高的安全等级要求那么通常还需要考虑独立硬件、独立电源域、独立控制器或其他架构措施而不能仅靠软件线程优先级解决所有问题。四、Deadline Miss意味着什么机器人不能只统计“平均延迟”前面多篇文章一直强调一个问题实时系统不能只看平均值。假设一个 1 kHz 控制线程运行了 100 万次。结果平均周期1.001 ms 最大周期8.7 ms如果只看平均值似乎系统表现不错。但是对于实时控制来说真正重要的问题可能是最大周期为什么是8.7ms因为期望 1ms 1ms 1ms 1ms 1ms实际1ms 1ms 1ms 8.7ms ← Deadline Miss 1ms这一次异常就可能比前面几百万次正常执行更重要。因此在实时机器人系统中需要关注Average Latency ↓ Worst-case Latency ↓ Jitter ↓ Deadline Miss ↓ Fault Detection ↓ Safe Response这也是实时控制和普通应用开发思路非常不同的地方。进一步可以建立这样的机制控制周期 ↓ 是否按时完成 │ ├── 是 → 正常运行 │ └── 否 ↓ 记录异常 ↓ 连续超时 │ ├── 否 → 恢复/观察 │ └── 是 ↓ 进入故障状态 ↓ 安全处理注意这里不能简单规定“某一次 deadline miss 就一定立刻急停”。实际策略需要根据机器人类型、控制系统设计和安全目标决定。例如有些系统可能一次异常 ↓ 记录连续异常连续超时 ↓ 降级严重异常通信失效 / 控制器失效 / 传感器异常 ↓ 安全状态所以deadline miss不是简单的性能统计数字它也可以成为故障管理体系中的输入信号。这也是实时系统设计从“性能优化”走向“系统安全”的一个重要转折点。五、从ROS 2到实时Linux机器人真正需要的是一条有边界的控制链路把前面几篇文章串起来就可以发现ROS 2机器人实时控制实际上已经形成了一条完整的技术链ROS 2 │ ┌──────────┼──────────┐ ↓ ↓ ↓ Node Topic Action │ ↓ DDS / QoS │ ↓ Executor │ ↓ Callback │ ↓ Control Thread │ ↓ Linux Scheduler │ ↓ CPU / Core │ ↓ Memory / IRQ / Driver │ ↓ EtherCAT / CAN / PCIe │ ↓ Servo / Motor而在这条链路旁边还应该存在Safety Monitor │ ┌───────────┼───────────┐ ↓ ↓ ↓ Watchdog Timeout Heartbeat │ │ │ └───────────┼───────────┘ ↓ Fault Handling ↓ Safe State这时候就可以理解为什么机器人实时控制不能简单归结为“ROS 2用了实时Executor所以实时了。”也不能归结为“Linux用了SCHED_FIFO所以实时了。”更不能归结为“CPU核心隔离以后就安全了。”真正的系统设计应该是ROS 2 ↓ Executor ↓ 实时控制线程 ↓ 调度策略 ↓ CPU核心隔离 ↓ IRQ隔离 ↓ 内存与资源控制 ↓ 硬件通信 ↓ 执行机构与此同时控制任务 ↓ Heartbeat ↓ Watchdog ↓ Deadline / Timeout ↓ Fault Detection ↓ Safety State这两条链路共同构成一个更加完整的机器人控制架构。这也意味着实时操作系统承担的是底层确定性运行环境而不是替代ROS 2也不是自动完成机器人安全设计。对于实时性要求更高的机器人控制系统可以考虑采用具有更强确定性和资源隔离能力的实时Linux环境为 ROS 2、ros2_control 以及底层硬件控制任务提供更加可控的运行基础。例如在国产化实时控制场景中望获rtLinux可以作为这类实时Linux基础环境的一种技术选择将实时调度、CPU核心隔离、资源隔离等能力与机器人上层软件结合起来。其典型思路并不是ROS 2 望获rtLinux 自动获得安全而是ROS 2 ↓ 机器人应用 ↓ 实时控制架构 ↓ 资源隔离 ↓ 实时Linux运行环境 ↓ 硬件控制在此基础上再建立故障监测 ↓ Watchdog ↓ Timeout ↓ 安全状态这样的完整机制。最终可以形成一种更加清晰的分层层级主要解决的问题ROS 2节点、通信、机器人软件组织DDS / QoS数据通信与通信行为ExecutorCallback如何组织和执行Linux Scheduler线程如何获得CPU实时Linux提供更加可控的实时运行环境CPU/IRQ/内存隔离降低资源干扰ros2_control机器人控制器与硬件接口EtherCAT/CAN等控制数据传输Watchdog检测任务是否正常Safety Logic处理异常状态Drive / Brake最终执行安全动作所以机器人实时控制真正需要的并不是某一个“实时开关”。而是一套从任务 → 调度 → 资源 → 通信 → 硬件 → 故障检测 → 安全状态逐层建立边界的系统架构。当 AI、视觉、SLAM、ROS 2、ros2_control 和高速运动控制全部运行在同一台设备上时系统设计的核心问题已经从“如何让机器人跑起来”逐渐变成如何让关键控制任务始终拥有确定的运行条件同时让非关键任务的故障不会轻易传播到控制链路。这也是机器人操作系统走向工业化、复杂化之后必须面对的问题。而下一步还可以继续往机器人最底层的实时通信链路深入。因为即使我们已经解决了ROS 2 ↓ Executor ↓ 实时线程 ↓ CPU隔离 ↓ Watchdog机器人依然存在一个非常关键的问题控制指令究竟是怎么从 ros2_control 传到电机驱动器的尤其是在工业机器人和高性能运动控制系统中EtherCAT、CAN、PCIe以及网卡中断都会进入这条链路。