2. 实时性基础
在讨论AI机器人的推理延迟、控制周期和动作同步之前，我们必须先建立对“实时性”这一核心概念的准确认知。许多工程师容易将“实时”等同于“快”，这是一个根本性的误解。实时性的本质并非速度，而是确定性——即系统必须在规定的时间窗口内完成指定的任务，无论系统负载如何变化。对于机器人系统而言，实时性直接决定了其安全边界、控制品质和任务执行的可信度。本章将从实时系统的定义出发，厘清硬实时与软实时的本质区别，并深入剖析机器人系统在不同层级上的实时性需求，为后续章节的延迟优化和周期设计奠定理论基础。
2.1 实时系统的定义与核心特征
实时系统（Real-Time System）是指系统的正确性不仅依赖于计算结果的逻辑正确性，还依赖于结果产生的时间。用形式化语言描述：一个实时任务 T 具有释放时间 r、执行时间 c 和截止期限 d，系统必须保证在 d 之前完成执行并输出结果。如果结果在截止期限之后才产生，即使逻辑完全正确，也被视为系统失效。
实时系统有三个核心特征需要深入理解：
- 时间约束性：每个任务都有明确的截止期限（Deadline），这是区别于普通计算系统的最根本特征。普通系统追求“尽快完成”，实时系统追求“在指定时间完成”。
- 可预测性：系统必须能够对任务的最坏执行时间（WCET, Worst-Case Execution Time）做出估计，并基于此进行调度分析。无法预测的系统无法证明其实时性。
- 确定性：在给定输入和系统状态下，任务的执行时间和调度行为应当是确定且可重复的。缓存未命中、内存分配延迟、垃圾回收等不确定性因素都是实时系统的大敌。
在机器人系统中，实时性并非一个单一属性，而是贯穿从传感器采集到执行器驱动的完整链路。一个典型的实时链路包括：传感器数据采样 → 数据预处理 → 状态估计 → 控制计算 → 指令输出 → 执行器响应。这条链路上任何一个环节的时序抖动都会向下游传播，最终表现为机器人动作的抖动或延迟。
2.2 硬实时与软实时的本质区别
根据错过截止期限的后果严重程度，实时系统被划分为硬实时（Hard Real-Time）和软实时（Soft Real-Time）两类。这种划分并非学术分类游戏，而是直接决定了系统架构设计、调度策略选择和资源预留方式。
| 对比维度 | 硬实时（Hard RT） | 软实时（Soft RT） |
|---|---|---|
| 错过截止期限的后果 | 灾难性：设备损坏、人员伤亡、任务失败 | 降级性：输出质量下降、用户体验变差 |
| 时间保证方式 | 必须通过数学分析证明最坏情况满足 | 统计性保证（如99.9%的请求在期限内完成） |
| 典型调度策略 | 速率单调调度（RMS）、最早截止期限优先（EDF） | 优先级抢占、时间片轮转、多级反馈队列 |
| 系统设计倾向 | 静态资源预留、禁止动态内存分配、关中断 | 允许动态资源管理、可接受偶发超时 |
| 机器人应用场景 | 伺服控制环、安全急停、力/力矩控制 | 视觉SLAM、路径规划、语音交互、AI推理 |
| 验证方法 | WCET分析 + 调度可行性分析 + 形式化验证 | 压力测试 + 延迟分布统计 + QoS监控 |
需要特别指出的是，硬实时与软实时之间并非对立，而是存在一个连续谱系。在实际机器人系统中，往往采用混合实时架构：核心安全关键任务运行在硬实时分区中，而AI推理、复杂感知等计算密集型任务运行在软实时分区中。这种架构既保证了安全性，又兼顾了计算灵活性。
2.3 机器人实时性需求的分层分析
机器人系统是一个典型的异构实时系统，不同功能模块对实时性的要求差异巨大。为了准确分析需求，我们将机器人系统划分为四个层级，每个层级都有不同的时间尺度、计算特征和实时性要求。
L1 关节/伺服层（1kHz - 10kHz）
这是最底层的电流环和速度环控制，直接驱动电机。以典型的六轴工业机器人为例，电流环的典型周期为100μs（10kHz），速度环为1ms（1kHz）。这一层对实时性的要求最为严苛：任何超过控制周期的延迟都可能导致电流过冲、电机振动甚至驱动器损坏。该层通常运行在专用DSP/FPGA或MCU上，采用硬实时调度，中断响应时间必须控制在微秒级。
L2 运动控制层（100Hz - 1kHz）
负责位置环、力控、轨迹插补等任务。以协作机器人为例，位置环周期通常为1-4ms，力控周期为1ms。这一层需要与伺服层进行严格的数据同步，通常运行在实时操作系统（如RT-Linux、VxWorks）上，采用固定优先级抢占式调度。该层对抖动（Jitter）非常敏感，因为位置指令的时序抖动会直接转化为末端执行器的轨迹误差。
L3 感知/规划层（10Hz - 50Hz）
包括SLAM建图、路径规划、障碍物检测等。这一层通常运行在通用操作系统（如Ubuntu + ROS）上，属于软实时范畴。以移动机器人的SLAM为例，激光雷达的扫描频率通常为10Hz，路径规划需要在100ms内完成。虽然偶尔的超时不会造成灾难性后果，但会降低导航的平滑性和避障的可靠性。
L4 AI推理层（1Hz - 30Hz）
包括深度学习视觉识别、大语言模型推理、语义理解等。这一层是典型的软实时+计算密集型任务。以视觉抓取为例，目标检测的推理时间通常在20-100ms之间，而整个视觉伺服环路的周期要求可能在50-200ms。AI推理的延迟具有高度不确定性，受输入数据、模型复杂度、GPU负载等多重因素影响，这给实时性保障带来了巨大挑战。
2.4 机器人实时性需求分析的方法论
在实际项目开发中，实时性需求分析需要遵循一套系统化的流程，而不是凭经验拍脑袋。以下是一个经过验证的四步分析法：
- 任务清单梳理：列出机器人系统中所有时间关键型任务，包括任务名称、触发方式（周期/事件）、数据流向、计算资源需求。
- 时间参数标定：为每个任务确定三个关键参数——周期（Period）、截止期限（Deadline）、最坏执行时间（WCET）。WCET需要通过代码分析、基准测试和静态分析工具综合确定。
- 调度可行性分析：使用利用率测试（Utilization Test）或响应时间分析（Response Time Analysis）验证任务集在目标调度策略下是否可调度。对于硬实时任务，必须保证在最坏情况下的响应时间小于截止期限。
- 端到端延迟预算：从传感器采样到执行器响应的完整链路，建立端到端的延迟预算表，明确每个环节的延迟上限和抖动容限。
案例拆解：移动机械臂的实时性需求分析
我们以一个移动机械臂平台为例，该平台需要在移动底盘上完成动态抓取任务。系统包含以下关键任务：
- 关节伺服控制（6轴 × 1kHz，硬实时，WCET=0.3ms）
- 底盘运动控制（500Hz，硬实时，WCET=0.5ms）
- 力/力矩传感器采集（1kHz，硬实时，WCET=0.1ms）
- 视觉目标检测（10Hz，软实时，WCET=80ms，P99=150ms）
- 运动规划（20Hz，软实时，WCET=25ms）
- SLAM定位（10Hz，软实时，WCET=30ms）
在初始设计中，工程师将所有任务都放在一台高性能x86工控机上运行，使用Ubuntu + PREEMPT_RT内核。实测发现，当视觉检测任务运行时，关节伺服控制的抖动从原来的0.05ms恶化到0.8ms，导致机械臂在高速运动时出现明显振动。
通过响应时间分析发现，问题根源在于视觉检测任务触发了大量的内存分配和GPU调用，导致内核的调度延迟显著增加。解决方案是采用异构架构：将关节伺服和力控任务部署到专用的MCU（如STM32H7）上，通过EtherCAT总线与工控机通信；工控机只负责视觉、规划和SLAM等软实时任务。同时，在工控机上使用CPU隔离（isolcpus）和线程优先级设置，将视觉任务绑定到专用CPU核心，避免与运动规划任务争抢资源。
改造后的系统性能对比如下：
| 指标 | 改造前（单机） | 改造后（异构） |
|---|---|---|
| 伺服控制最大抖动 | 0.8ms | 0.06ms |
| 视觉推理P99延迟 | 150ms | 120ms |
| 端到端抓取周期 | 250ms（不稳定） | 180ms（稳定） |
| 系统CPU平均负载 | 85% | 60% |
这个案例的复盘经验是：实时性需求分析必须在系统架构设计阶段就介入，而不是等到系统集成后再去“打补丁”。异构架构虽然增加了硬件成本，但换来了确定性的提升和系统整体性能的改善。
2.5 常见误区与设计原则总结
在机器人实时性需求分析中，以下误区需要特别警惕：
- 误区一：实时性 = 高性能硬件。增加CPU主频或GPU算力并不能解决实时性问题，反而可能引入更多的不确定性（如缓存一致性、PCIe总线竞争）。实时性的核心在于调度策略和资源隔离。
- 误区二：所有任务都做成硬实时。过度设计会导致系统利用率低下，且硬实时调度算法（如EDF）在过载情况下的行为难以预测。正确的做法是区分关键等级，采用混合调度策略。
- 误区三：忽略中断延迟。在Linux等通用操作系统中，中断处理（尤其是网络中断和GPU中断）可能造成毫秒级的调度延迟。对于硬实时任务，需要将中断绑定到非关键CPU核心，或使用中断线程化技术。
- 误区四：只关注平均延迟。机器人控制系统的稳定性取决于最坏情况延迟（Worst-Case Latency），而非平均延迟。在设计时必须考虑延迟分布的长尾效应。