自动驾驶架构：人为接口与隐式特征的博弈

在自动驾驶架构的演进过程中，人们通过人为定义接口和隐式表达特征的方式来实现不同阶段的规划。

下面用通俗的例子，说明"人为定义接口"和"隐式表达特征"的区别，以及它们在自动驾驶感知-规划链路里是怎么被用的。

一、什么是"人为定义接口"（Human-defined Interface）

• 核心思想：用人能读懂、带明确语义的结构化数据，把感知输出"规范化"后交给规划器。字段、单位、坐标系、置信度等都被明确约定。
• 形态：固定的数据结构/消息格式（比如 Protobuf/ROS msg/IDL），包含对象清单、地图元素、车道拓扑、交通灯状态等可解释字段。

典型例子

1. 目标列表（Object List / Tracks）

   感知模块输出"世界里有哪些东西"

   • 每个目标包含：
     • 类型：vehicle/pedestrian/cyclist/cone...
     • 3D框：x, y, z, 长宽高, 朝向
     • 运动学：速度、加速度、转向率
     • 置信度与协方差：state_cov 6x6
     • ID与时间戳：track_id, stamp
   • Planner使用方式：
     • 基于运动学与规则进行避让、跟车、变道决策
     • 基于不确定性做风险评估和碰撞概率计算

   伪消息示例（片段）

   • header.stamp: 123456.78
   • ego_pose: {...}
   • objects:
     • id: 42, type: vehicle
       bbox_3d: {x: 12.3, y: -3.1, yaw: 1.57, lwh: 4.5,1.9,1.6}
       velocity: {vx: -0.2, vy: 0.0}
       confidence: 0.92
       covariance: [...6x6...]

2. 车道与地图（HD Map/车道图/拓扑）

   • 车道中心线、左右界、多段样条
   • 限速、优先级、可变道标记、车道连通图
   • 停止线、斑马线、路口几何
   • Planner使用方式：轨迹生成的几何参考、合法性约束（不得跨实线）、优先级让行等

3. 交通灯与路权

   • 信号灯ID、颜色、剩余时长
   • 停止线关联关系
   • Planner使用：红灯前停车、绿灯放行、黄灯减速策略

4. 可占用栅格/语义分割（可解释但仍是接口）

   • BEV占用网格：每格是否可通行/是否有动态物体
   • 语义BEV：road/sidewalk/crosswalk/禁止区域
   • Planner使用：道路边界、可通行区域成本

特征

• 明确边界：字段和语义由工程师定义，跨模块/团队可以稳定协作
• 易于调试/安全合规：能做规则校验、逻辑审计、可追责
• 代价：信息"瓶颈"。感知输出被压缩为少量人定义的标签，可能丢失细节（比如行人姿态、路缘微小几何、阴影/反射等未被建模的线索）

二、什么是"隐式表达特征"（Implicit Features）

• 核心思想：不把世界编码成"人能读懂的对象/规则"，而是把深度网络学到的高维连续特征（通常是张量或token）直接传给规划网络。语义不由人定义，而由训练目标隐式学习。
• 形态：BEV特征图、稀疏查询token、时空特征金字塔、代价体（cost volume）、占用流等的"潜在表示"。

典型例子

1. BEV特征图直连规划

   • 感知编码器输出：F ∈ R[C×H×W]（例如 C=256, H=W=200）
   • 内容：融合了多相机/激光的时空线索，但没有"这是车/这是人"的显式标签
   • Planner（如 PlanningFormer）通过跨注意力在F上做查询，直接回归未来自车轨迹或控制量
   • 训练：用轨迹监督（L2/安全约束/碰撞率等）端到端调优编码器与规划器

2. Token化场景表示

   • 将场景压缩为若干latent tokens（如N个场景token+自车token）
   • Planner与这些token交互，预测轨迹/动作分布
   • Token不显式对应"车道线/车辆/灯"，但蕴含这些信息

3. 占用流/运动场（Occupancy Flow / Scene Flow）

   • 网络输出随时间变化的占用概率和速度场，连续密集但非对象化
   • Planner用它评估"某路径上未来时刻被占用的概率"，进行碰撞规避
   • 这比"目标列表"更细腻，但语义是学习到的，不是标准对象定义

4. 代价体或隐式成本地图

   • 直接学习"走哪里代价低"，不需要先显式分割成道路/路缘
   • Planner从代价体里做最优路径搜索或通过解码器回归轨迹

特征

• 表达力强：保留细节与上下文，减少信息瓶颈
• 端到端优化：感知和规划共享目标，可能更鲁棒
• 代价：可解释性差、调试难；跨团队/跨平台复用困难；安全审计与功能安全认证门槛更高

三、同一场景的对比示例

场景：十字路口，前方有一辆横穿车辆，右侧有行人，左转待转车道，红灯即将转绿。

• 人为定义接口链路

  • 感知输出：
    • 对象列表：车辆A {x,y,yaw,v}, 行人B {x,y,v}...
    • 地图/拓扑：左转车道中心线、停止线、优先级
    • 信号灯：lane_group_12 = red, time_to_green=1.2 s
  • 规划输入：
    • "左转车道可用但需等待绿灯；行人B在斑马线上；车辆A横穿速度2 m/s"
  • 规划决策：
    • 红灯前减速停车；绿灯后判断A与B的时隙冲突，满足安全间隙再起步并左转

• 隐式表达特征链路

  • 感知输出：
    • BEV特征F（包含相机/激光融合的时空上下文），可能再叠加占用流
  • 规划器：
    • 对F做注意力，直接回归未来3--5秒的控制轨迹，使得碰撞概率低、离散化成本低、轨迹平顺
    • 其内部"知道"红灯、斑马线、车辆运动，但没有显式字段；这些信息是通过训练从数据中学会的
  • 结果：
    • 轨迹在红灯时靠近停止线停止，绿灯后在安全时隙通过路口

四、边界情况与混合形态

• BEV语义分割或占用网格：虽然是稠密栅格，但每个通道"道路/人行道/障碍物"有清晰语义，仍可视作"人为定义接口"（可解释）。
• 学习到的占用流或代价体：若通道语义不是人定义而是通过损失函数隐式学得，更偏"隐式特征"。
• 模块化端到端：常见做法是用显式接口约束安全（如交通规则、最低距离），同时旁路传递隐式特征给AI规划器，兼顾可解释性与性能。

五、选择与权衡

• 选择人为定义接口，当你需要：
  • 清晰的安全边界与功能安全认证
  • 多团队协作、系统集成、可维护性
  • 易调试、易做回放与逻辑回归测试
• 选择隐式表达特征，当你需要：
  • 最小信息瓶颈与更强的端到端性能上限
  • 融合复杂上下文、长尾细节
  • 用大数据与大模型提升泛化

一句话总结

• 人为定义接口：把世界"翻译成人能读懂的字段"，如"这有辆车、这里是车道、灯是红的"，规划器基于这些显式语义做决策。
• 隐式表达特征：不翻译，直接把"看懂世界"的高维潜在特征交给规划器，规划器从这些特征中自己学会怎么开。