2. 机器人控制计算需求分析
机器人控制计算平台的设计，不能从“选哪颗 CPU”开始，而要从“机器人到底需要平台做什么”开始。同一块计算板卡，放在六轴机械臂、AGV 移动机器人或协作机器人上，需求优先级可能完全不同：机械臂最在意伺服周期的抖动，移动机器人最在意功耗与续航，协作机器人则把功能安全放在首位。本节把机器人对计算平台的需求拆成六个维度——实时性、确定性、算力、功耗、功能安全、典型形态差异，并给出可量化的分析方法。
一、实时性与确定性：两个必须分开的指标
实时性（Real-time）指系统能在规定时间内完成响应，确定性（Determinism）指这个响应时间的抖动足够小、可预测。二者常被混为一谈，但工程上必须分开看。
以典型的 1 kHz 伺服控制环为例：控制周期 T = 1 ms。假设控制算法（正逆运动学、PID、前馈）单次计算耗时 200 μs，通信与 IO 耗时 100 μs，则单周期占用约 300 μs，CPU 占用率 30%。这满足“实时”——只要每毫秒都能算完。但如果某次因缓存未命中、中断抢占或内存争用，耗时突然涨到 900 μs，虽然仍小于 1 ms，却已逼近极限；若下一次再叠加，就会错过周期，导致关节抖动甚至报警。因此真正要控制的是最坏情况执行时间（WCET）和抖动（Jitter），而不是平均耗时。
工程上通常要求：控制环抖动小于周期的 5%~10%。对 1 ms 周期，抖动应控制在 50~100 μs 以内。达成手段包括：控制环绑定独立 CPU 核心（CPU Isolation）、关闭该核的 C-State 与频率调节、使用 PREEMPT_RT 或实时 OS、把 EtherCAT 主站与运动规划放在不同核、避免在实时核上做动态内存分配。
cyclictest 在目标平台上跑 1 小时以上，观察 Max Latency。若 Max Latency < 50 μs，可支撑 1 kHz 硬实时；若在 100~200 μs，适合 500 Hz 以下控制环；若超过 500 μs，则只能做非实时任务。二、算力需求：分层估算，而非拍脑袋
机器人算力需求可分为三层：伺服控制层（1 kHz 级，算力需求小但实时性要求高）、运动规划层（100 Hz~1 kHz，涉及轨迹插补、碰撞检测）、感知与决策层（10~30 Hz，涉及视觉、点云、SLAM、AI 推理）。
以协作机器人视觉抓取为例，可做如下示例估算（属合理假设，非实测）：
| 任务 | 频率 | 单次算力 | 合计 |
|---|---|---|---|
| 伺服控制（6 轴） | 1 kHz | 0.3 ms × 1 核 | 约 0.3 核 |
| 轨迹规划与碰撞检测 | 100 Hz | 2 ms | 约 0.2 核 |
| 2D 视觉检测 | 30 Hz | 15 ms | 约 0.45 核 |
| 6D 位姿估计（轻量 CNN） | 15 Hz | 40 ms | 约 0.6 核 |
| 抓取规划 | 5 Hz | 80 ms | 约 0.4 核 |
合计约 2 核通用算力，加上操作系统与通信开销，建议预留 30% 余量，即 3 核左右。若引入深度学习分割或点云配准，则需 GPU/NPU 加速，此时应关注 TOPS 与内存带宽，而非 CPU 主频。
三、功耗与散热：移动场景的硬约束
移动机器人和协作机器人常由电池供电，功耗直接决定续航。以 48 V/20 Ah 电池（约 960 Wh）为例，若计算平台整机功耗 60 W，仅计算部分续航约 16 小时；若功耗 150 W，则降至 6.4 小时。因此移动平台倾向选择低 TDP 的嵌入式 SoC（如 15~35 W 级），并采用无风扇或被动散热设计。
功耗分析要区分峰值功耗与平均功耗：AI 推理瞬间可能拉高到 2~3 倍 TDP，若电源与散热按平均值设计，会出现降频甚至宕机。工程上应给出功耗包络（Power Envelope），并配置足够的电源裕量与热设计功耗（TDP）余量。
四、功能安全：从 SIL 到架构冗余
功能安全关注“系统失效时是否安全”。协作机器人需满足 ISO 10218 与 ISO/TS 15066，通常要求安全功能达到 PL d（ISO 13849）或 SIL 2（IEC 61508）。这意味着计算平台不能只靠一颗 CPU：
- 安全相关信号（急停、安全门、力矩超限）应走独立安全通道，如安全 PLC 或安全 IO 模块；
- 主控 CPU 与安全监控单元之间做交叉校验（Cross-check），任一方异常即触发安全停止；
- 关键状态（使能、模式、速度限值）需冗余存储与周期自检；
- 看门狗、ECC 内存、锁步核（Lockstep）是常见硬件手段。
需要强调：功能安全不是“加一个安全模块”就完成，而是从需求、架构、实现到验证的全链路活动。计算平台选型时必须确认其是否支持所需的安全等级与认证证据。
五、典型机器人形态的差异化要求
把上述维度落到三种典型形态上，可以得到一张需求对比图（见下方 SVG）。机械臂以实时性与确定性为第一优先级，算力集中在运动控制；移动机器人以功耗、续航与感知算力为核心；协作机器人则在实时性、安全性与算力之间取平衡，且安全权重最高。
六、需求分析的可执行方法
把上述维度落成一份可执行的需求分析，建议按以下顺序推进：
- 确定控制周期与抖动上限：由机械结构、减速比、负载惯量决定。例如 6 轴机械臂末端要求 0.1 mm 跟踪精度，通常需 1 kHz 控制环、抖动 < 50 μs。
- 列出任务清单并估算算力：按“任务—频率—单次耗时—核数”表格逐项累加，预留 30% 余量。
- 确定功耗预算：由电池容量与目标续航反推允许功耗，再分配计算、驱动、传感的功耗份额。
- 确定安全等级与架构：明确所需 PL/SIL 等级，决定是否引入安全 PLC、锁步核或冗余通道。
- 按形态调整权重：机械臂加重实时性，移动机器人加重功耗与感知算力，协作机器人加重安全。
- 验证：在目标平台上用 cyclictest 测抖动、用功耗仪测包络、用故障注入测安全响应，形成需求—验证闭环。
综上，机器人控制计算需求分析的本质，是把“机器人要做什么”翻译成“平台必须保证什么”。实时性与确定性决定控制品质，算力决定功能上限，功耗决定形态边界，功能安全决定人机协作的底线，而典型形态则决定这些维度的权重排序。只有先完成这份分析，后续的平台选型、操作系统配置与软件架构才有依据。