2. 基础概念

在无人车低延迟控制系统中,三个时间维度的概念构成了整个软件与硬件协同工作的骨架:推理周期(Inference Period)、控制周期(Control Period)与动作同步(Action Synchronization)。它们分别对应感知决策的“思考节奏”、底层执行的“行动节奏”以及两者之间的“握手协议”。理解这三者的定义、区别与联系,是设计任何实时无人车控制系统的第一道门槛。若将无人车比作一位赛车手,推理周期是大脑思考下一步动作的频率,控制周期是手脚执行指令的频率,而动作同步则确保大脑的指令不会在手脚已经完成上一个动作后才姗姗来迟。

感知与决策域 执行与控制域 同步与调度域 推理周期 T_inf = 50~100ms 神经网络/规划算法 输入:传感器融合数据 输出:轨迹/速度/转向角 控制周期 T_ctrl = 1~10ms PID/MPC/前馈控制 输入:目标状态+反馈 输出:电机/转向指令 动作同步 时间戳对齐+缓冲 延迟补偿/插值 匹配推理输出与控制输入 保证动作时序一致性 目标 状态 指令 反馈 时间同步协议 动作执行确认 t0 t0 + T_inf t0 + T_inf + T_ctrl

上图展示了三个核心概念在无人车系统中所处的域、典型时间尺度以及它们之间的数据流向。可以看到,推理周期位于感知与决策域,控制周期位于执行与控制域,而动作同步则作为两者之间的桥梁,负责协调时序与数据一致性。下面我们将逐一深入剖析。

2.1 推理周期:大脑的思考节奏

推理周期(T_inf)定义为无人车从采集到传感器原始数据(如激光雷达点云、摄像头图像)到完成环境感知、路径规划并输出一条可执行轨迹或一组目标状态(目标速度、目标转向角)所需的固定时间间隔。在典型的L4级自动驾驶系统中,这个周期通常设定在50ms至100ms之间,对应10Hz至20Hz的推理频率。

推理周期的长短直接决定了系统对动态环境的“反应速度”。例如,当一辆车以72km/h(20m/s)行驶时,100ms的推理周期意味着车辆在两次“思考”之间已经前进了2米。因此,推理周期并非越短越好,它受到算法复杂度、GPU/NPU算力、传感器数据量等多重约束。工程上,推理周期通常由以下公式估算:

T_inf = T_sensor_acquisition + T_preprocessing + T_inference + T_planning + T_margin

其中,T_sensor_acquisition是传感器数据汇聚时间,T_preprocessing包括去畸变、坐标变换等,T_inference是神经网络前向传播时间,T_planning是轨迹规划与优化时间,T_margin是预留的抖动余量(通常为总时间的10%~20%)。

工程经验:推理周期的设定应遵循“够用就好”原则。过短的推理周期会迫使算法降低模型复杂度,反而可能因感知精度下降导致规划质量恶化。建议通过离线数据集回放,绘制“推理周期 vs 规划轨迹误差”曲线,选择误差曲线拐点对应的周期值。

2.2 控制周期:手脚的执行节奏

控制周期(T_ctrl)是底层控制器(如ESP车身稳定系统、转向电机控制器、驱动电机控制器)更新一次执行指令的时间间隔。它通常由车辆的线控底盘接口决定,常见值为1ms、2ms、5ms或10ms。控制周期越短,对执行机构的机械磨损和通信带宽要求越高,但控制精度和稳定性也越好。

控制周期的核心约束来自三个方面:

  • 执行器带宽:转向电机和驱动电机的响应带宽通常为20Hz~50Hz,过快的控制指令更新并不会带来更快的物理响应,反而可能激发机械谐振。
  • 通信链路延迟:从控制器到执行器之间的CAN/CAN-FD/Ethernet通信存在固定延迟和抖动,控制周期必须大于通信延迟的2~3倍以保证指令有序到达。
  • 控制算法计算量:模型预测控制(MPC)等高级算法在1ms内完成求解需要高性能MCU或FPGA,而PID控制在1ms内则绰绰有余。

在工程实践中,控制周期通常由底盘供应商的接口协议固定,例如某主流线控底盘要求控制指令以1000Hz(1ms周期)通过CAN发送,而另一款商用底盘仅支持100Hz(10ms周期)。因此,控制周期的选择往往不是软件工程师的自由变量,而是硬件约束下的“给定值”。

2.3 动作同步:让思考与行动对齐

动作同步是指将推理周期产生的目标状态(通常是离散的、低频的)与控制周期所需的输入状态(连续的、高频的)在时间轴上对齐的过程。由于推理周期(如100ms)通常是控制周期(如10ms)的整数倍或非整数倍,两者之间存在天然的相位差和频率差,动作同步机制需要解决以下三个核心问题:

  1. 时间戳对齐:推理输出的轨迹点必须带有精确的时间戳,控制模块需要根据当前时刻与目标时间戳的差值,判断该轨迹点是否仍然有效。
  2. 插值与外推:当控制模块需要以10ms的频率输出指令,而推理模块每100ms才更新一次目标时,控制器需要在两个推理目标之间进行线性插值或样条插值,以生成平滑的中间目标。
  3. 延迟补偿:从推理完成到控制指令真正作用于执行器,存在系统延迟(包括推理时间、通信时间、控制计算时间)。动作同步模块需要预测“当前时刻执行器应该处于什么状态”,而不是简单使用“推理完成时的目标状态”。

一个典型的动作同步实现采用“双缓冲+时间戳”机制:推理模块将最新轨迹写入共享内存的“前台缓冲区”,并附带时间戳;控制模块在每个控制周期读取“后台缓冲区”的数据,根据当前时间戳进行插值计算。当推理模块完成新一次推理后,原子性地交换前后台缓冲区指针,确保控制模块永远不会读到“半更新”的数据。

2.4 三者的区别与联系:一张表看懂

维度 推理周期(T_inf) 控制周期(T_ctrl) 动作同步
所属层级 感知与决策层 执行与控制层 跨层协调层
典型时长 50ms ~ 200ms 1ms ~ 20ms 无固定周期,随事件触发
核心目标 理解环境、生成全局/局部轨迹 精确跟踪目标状态、抑制扰动 保证数据时序一致性、最小化延迟
主要硬件 GPU/NPU/FPGA、高性能CPU MCU、实时CPU、执行器ECU 共享内存、硬件时钟、同步总线
失败后果 感知滞后、规划轨迹过时 控制抖动、车辆偏离车道 指令错位、执行器收到过期目标
设计自由度 高(可调算法复杂度) 低(受底盘接口限制) 中(可设计缓冲策略)

从表中可以看出,推理周期关注“想得对不对”,控制周期关注“做得准不准”,而动作同步关注“配合得顺不顺”。三者相互制约:推理周期过长会加重同步模块的插值压力;控制周期过短会放大同步模块的抖动;同步策略不当则会让高性能的推理和控制算法都发挥不出应有的效果。

2.5 实战场景:一个典型的城市道路跟车案例

为了更直观地理解三者的协同关系,我们拆解一个城市快速路跟车场景。假设车辆以80km/h巡航,前方200米处有一辆慢车,系统需要自动减速并保持安全距离。

初始参数设定:

  • 推理周期:80ms(12.5Hz),采用ResNet-50+轨迹优化器
  • 控制周期:5ms(200Hz),底盘CAN接口支持
  • 系统总延迟:推理80ms + CAN通信2ms + 控制计算1ms = 83ms

运行过程:

  1. t=0ms:传感器采集完成,推理模块开始处理。
  2. t=80ms:推理完成,输出目标轨迹点序列:未来0.5秒内每50ms一个目标速度(如从22m/s线性降至18m/s)。轨迹点附带时间戳:t=80ms, 130ms, 180ms...
  3. t=80ms~85ms:动作同步模块将轨迹写入共享缓冲区,并触发同步信号。
  4. t=85ms:控制模块读取缓冲区,发现当前时刻(85ms)介于两个轨迹点(80ms和130ms)之间,于是进行线性插值,计算出85ms时刻的目标速度为21.6m/s。
  5. t=85ms~90ms:控制模块执行PID计算,输出转向和驱动指令,通过CAN发送至底盘。
  6. t=90ms:底盘执行器响应,车辆实际加速度开始变化。

关键问题:如果动作同步模块没有进行延迟补偿,控制器会直接使用80ms时刻的目标速度(22m/s)作为当前目标,导致车辆在80ms~130ms期间以过高的速度行驶,实际减速比预期晚了50ms。在紧急制动场景下,这50ms意味着1米以上的制动距离差异。

案例复盘:通过引入“预测性同步”策略——即根据系统总延迟(83ms)提前外推目标状态——可以将有效延迟从83ms降低至约30ms。具体做法是:在插值计算时,不是查询“当前时刻”的目标,而是查询“当前时刻+预估延迟”的目标。该策略在本案例中使跟车距离误差从±1.2m缩小至±0.3m,显著提升了舒适性和安全性。

2.6 常见误区与设计建议

在实际工程中,工程师常陷入以下误区,需要特别警惕:

误区一:盲目追求更短的推理周期。推理周期从100ms缩短至50ms,如果算法精度因此下降(例如使用更小的神经网络),可能导致目标轨迹频繁跳变,反而增加控制模块的负担。正确做法是保持推理周期不变,优化同步插值算法。
误区二:忽略控制周期的抖动。控制周期标称5ms,但实际可能因中断优先级、总线竞争而出现±1ms的抖动。动作同步模块必须容忍这种抖动,否则会频繁触发“数据过期”告警。建议在同步模块中设置“有效时间窗口”(如±2ms),窗口内的数据均视为有效。
误区三:将推理时间戳与控制执行时间戳混用。推理模块使用系统时钟(如Linux的CLOCK_MONOTONIC),控制模块使用MCU内部定时器,两者未做时钟同步,导致时间戳偏差达数十毫秒。必须使用PTP(IEEE 1588)或简单的周期性对时机制统一时间基准。

设计建议:在系统架构初期,应首先确定控制周期(由底盘决定),然后反推推理周期的上限(通常为控制周期的10~20倍),最后设计动作同步策略。同时,建议在仿真环境中注入不同的延迟和抖动,验证同步模块的鲁棒性。一个实用的经验法则是:动作同步模块的额外开销(包括插值计算、缓冲管理、时间戳处理)不应超过控制周期的10%,否则同步本身将成为新的延迟源。