实时系统与工程集成：让算法按时、持续、可恢复地工作

实时的核心是截止时间

“运行得快”描述平均速度，“实时”描述时间约束。硬实时任务错过一次截止时间就可能不可接受，例如电机保护与安全制动；软实时任务偶尔超时会降低质量，例如视频显示；固实时任务超时后的结果失去价值，例如基于旧传感帧的控制命令。

周期为 \(T\)、最坏执行时间为 \(C\)、端到端响应时间为 \(R\)，基本要求是

\[R\le D,\]

\(D\) 是截止时间。响应时间不仅包含算法计算，还包含传感采样、驱动、排队、线程调度、通信、执行器更新。平均 1 ms、偶尔 50 ms 的任务，对 10 ms 控制周期仍不合格。评估应看最坏值、分位数和长时间尾部；平均数只描述其中一个侧面。

抖动是周期或延迟的波动。控制器按固定 \(\Delta t\) 离散设计，实际周期波动会改变等效增益和数值积分。时间戳应来自明确时钟；单调时钟适合测间隔，UTC/系统时钟适合跨设备关联但可能校时跳变。多机系统可使用 PTP 等协议同步，仍需测实际偏差。

调度、优先级与资源竞争

实时线程应有明确周期、优先级和 CPU 资源。高优先任务等待低优先任务持有的锁，会发生优先级反转；带优先级继承的互斥机制可以缓解。页面缺失、动态内存分配、日志 I/O、磁盘写入和网络调用都可能引入不可预测延迟，因此高频控制路径通常预分配内存、锁定内存页、避免阻塞系统调用。

把实时线程优先级全部调高会让系统管理和网络线程饥饿。优先级应按截止时间和依赖关系设计，并验证 CPU 过载时的行为。可调度性分析提供理论边界，压力测试观察真实平台上的缓存、驱动与中断影响。

多线程共享数据可用双缓冲、无锁单生产者/单消费者队列或短临界区。无锁并不自动更安全，内存顺序和生命周期错误难排查；对低频任务，清晰的互斥锁可能更可靠。原则是让实时路径等待时间可界定，并保持数据所有权明确。

图 1　端到端截止时间由所有模块和排队共同消耗。

从传感器到执行器的端到端预算

若视觉闭环要求 100 ms 内响应，可以先分配预算：曝光与驱动 20 ms、传输 10 ms、推理 35 ms、融合与规划 15 ms、控制与总线 5 ms，剩余 15 ms 留给抖动和余量。各模块“各自很快”仍可能因排队超过整体截止时间，因此要为数据标记采集时刻，在最终消费点测 age。

流水线吞吐量与单帧延迟不同。相机每 33 ms 来一帧，推理每帧 50 ms，若串行处理，队列会无限增长；增加并发能提高吞吐，却可能让 GPU 竞争增加单帧延迟。实时机器人常采用只保留最新帧、限制并发或降低采样率，确保动作依据新鲜证据。

实时 Linux、ROS 2 与硬件总线

PREEMPT_RT 可降低 Linux 内核调度延迟，但仍需配置 CPU 亲和性、中断、内存、频率调节和驱动。ROS 2 的实时工作还涉及执行器调度、DDS 实现、消息分配和 QoS。实时节点不应在控制回调中分配不受界定的内存、写同步日志或等待 Service。

ros2_control 将控制器与硬件接口组织在统一框架中。Controller Manager 按更新率读取状态、运行控制器、写命令。硬件 read() 或 write() 若阻塞，会拖慢所有控制器；设备驱动应设置超时、诊断并设计断连后的安全命令。

EtherCAT、CAN/CAN FD、工业以太网和串口各有带宽、同步、拓扑和故障特性。总线周期必须容纳所有设备帧和重试余量。控制器输出力矩到电机真正生效之间还可能经过驱动器内部环路与滤波，这些动态要纳入系统辨识和稳定性分析。

故障容错与安全状态

故障可以来自传感器冻结、越界、通信丢包、执行器过温、电池欠压、估计发散、规划无解和软件崩溃。检测不仅看“有没有消息”，还看消息是否变化、时间戳是否新鲜、数值是否物理合理、多个传感器是否一致。

图 2　越接近物理风险的闭环，越应靠近硬件并减少依赖。

系统应为故障定义状态与动作：继续、降级、保持、受控停止、紧急停止或断电。带负载机械臂突然断电可能让物体掉落，受控制动更安全；电机驱动失控时软件停止命令可能无效，需要独立硬件切断。安全状态取决于机械结构、制动器、重力与周围人员。

看门狗监测心跳和周期，但“线程还活着”不能证明输出正确。可加入命令—反馈合理性、状态估计创新、控制饱和时间和任务进展监控。故障注入测试应主动模拟断网、冻结时间戳、传感器偏置、CPU 过载和设备重启，验证系统真的进入预期状态。

架构边界与部署

高频安全闭环应靠近硬件，较慢的感知、规划和业务编排可以运行在通用计算平台或远程服务。云端适合训练、日志分析和非实时调度，不应承担当网络中断时仍必须完成的制动动作。容器便于依赖管理，但 CPU、GPU、设备和实时权限要显式配置。

软件发布需要固定操作系统、ROS 发行版、中间件、驱动、模型和参数版本。参数文件与标定文件都应可追溯；升级前后用同一数据集与硬件回归。启动编排要按依赖顺序拉起节点，健康检查通过后才允许执行器使能。关闭也要有顺序：先停止任务和运动，再安全释放硬件。

验证：从单元测试到现场证据

几何与算法函数适合单元测试；节点接口做集成测试；录制数据回放检验感知与估计回归；仿真覆盖碰撞和少见场景；硬件在环验证总线与时序；最终仍需在真实环境验证材料、光照、摩擦、人流和磨损。

每项需求都应对应可测指标。例如“及时避障”需要写成指定速度、障碍尺寸、感知条件下的最大停止距离和成功率；“控制稳定”需要负载范围、扰动和跟踪误差；“长期可靠”需要连续运行时间、温度范围、故障恢复与日志完备性。

仿真通过不能证明真实系统通过。仿真擅长大规模探索和可重复故障，现实验证负责模型外因素。发现仿真—现实差距后，要把新失效模式加入模型与回归集，形成迭代闭环。

图 3　故障处理包含多种有条件的状态转移，统一 stop 命令无法覆盖全部风险。

工程例子：控制周期平均 1 ms，机器人仍偶发抽动

日志显示平均周期 1 ms，看似满足 1 kHz；进一步记录最大值发现，后台日志压缩每隔几分钟占用 CPU，控制线程偶尔延迟 30 ms。位置目标在延迟后一次跳过多个采样点，产生大力矩。

修复包括把压缩移出控制 CPU，设置线程优先级与亲和性，预分配日志缓冲，控制器按真实时间步或对过期目标限幅，并监控截止时间违约。验证要运行足够久，叠加网络、磁盘和 GPU 压力，统计最大值与高分位。只优化平均性能会遗漏最危险的尾部事件。

深入阅读

## 本卷结语：把算法放回机器人整体

读完这一卷，最重要的能力是沿闭环追问。目标是否可验证？传感器在什么时间和坐标系下提供了什么证据？状态估计是否表达不确定性？规划是否满足几何、动力学和任务约束？控制命令是否在执行器能力内？动作完成后是否有终态回读？故障发生时，系统进入哪一个安全状态？

经典机器人学提供了一套可解释的骨架：坐标变换连接空间，运动学连接关节与任务，动力学连接力与运动，概率估计连接测量与状态，规划连接目标与可行路径，控制连接期望与物理执行，软件与实时工程保证整条链能按时协作。学习模型可以替换或增强其中某些模块，也可以端到端地产生动作；只要机器人进入真实世界，上述坐标、时延、接触、约束和安全问题仍会存在。

因此，评价一个机器人系统时，不要只问某个模型或算法“准确率多高”。还要问它在整条闭环中的输入证据、输出语义、时间预算、失败边界和恢复责任。能把这些问题讲清楚，才真正开始理解机器人。