一个大公司的面试
一个大公司 规控岗 (PNC) 一面
📌 基本信息
- 公司: 一个大公司
- 岗位: 规划控制 (PNC) 工程师
- 形式: 纯聊项目,无 Coding。
📝 项目经历深挖 (CX835 城市领航)
面试官首先让我详细介绍在恒润一年半的 CX835 项目经验。
- 核心职责: 负责横向规划模块,重点攻克参考线生成及相关功能。
- 核心方案架构:
- 输入: 定位、感知、建图、腾讯 HA 轻地图 (提供宏观导航)。
- 规划逻辑: 采用横纵向解耦方案。
- 流程:
- 基于车道规划静态参考线。
- 以该参考线为坐标系。
- 对动态障碍物(车辆、行人)进行绕行处理,输出横向轨迹。
- 在该横向轨迹上完成纵向决策与规划。
🔧 技术细节 (一): 参考线生成
这是面试的绝对核心,聊得非常细。
1. 标准工况 (平行车道)
- 流程:
- 建图模块提供车道中心线(作为参考线粗解)。
- 经 SQP 优化器处理。
- 以左右路沿为边界约束。
- 最终优化输出平滑的 B 样条曲线作为静态轨迹。
- 换道: 同时生成
current(当前)、left(左侧)、right(右侧) 三条属性的参考线。换道时,切换目标参考线,当下游横向规划使自车位置l收敛到 0 时,即完成换道。
2. 特殊工况 (匝道、分流、路口)
- 核心方案: 采用三段式参考线拼接方式。
- 三段式构成:
- 第一段 (历史): 自车已驶过的历史参考线 (硬约束,位置固定)。
- 第二段 (远端): 远端目标点 (时距根据车道紊乱程度可调)。
- 第三段 (连接): 贝塞尔曲线,用于平滑连接历史参考线与远端参考线。
- 优化补充: 拼接后的长点链仍需经优化器平滑。额外增加了曲率、heading 与历史帧一致的约束,以避免参考线近端大幅变化,导致控车画龙或猛打方向。
3. 不同场景的“远端目标点”来源
- 高速/匝道 (曲率大): 感知距离有限,采用高清地图 (HD Map) 中心线作为目标点引导。
- 城区一分二 (感知可覆盖): 车速低,无需长距离规划。筛选候选车道区域,为每条远端车道生成参考线。无导航时选最平滑直线;有导航时按对应方向选择。
- 过路口 (远端感知缺失):
- 利用 HA 轻地图提供的路口退出点局部坐标。
- 设计了三个状态机轮转切换 (平行车道 → HA 引导 → 感知引导 → 平行车道),解决感知缺失问题。
🔧 技术细节 (二): 参考线修正 (V1-V3 迭代)
重点讨论了如何解决轻地图的偏差 (0.5-1m 宽度偏差, 5-10m 横向位置偏差)。
- V1 (路沿修正):
- 逻辑: 用感知到的路沿信息,与轻地图车道边界匹配,修正偏出路外的大幅偏差。
- 局限: 对路内偏差修正效果差;若地图道线与路沿间有非机动车道,会导致匹配偏差。
- V2 (道线修正):
- 逻辑: 结合轻地图车道属性与已感知道线信息,预配准并调整车道宽度。
- 操作: 若轻地图给出异常宽度 (如三车道误判为 9 米超宽车道),则完全摒弃地图信息,基于感知重新拟定车道宽度。
- V3 (对向停止线修正):
- 场景: 适用于急右转、道线与路沿感知较晚的场景,避免侵入对向车道。
- 规则: 仅在轻地图车道侵入对向停止线时进行 “推送修正” (不主动 “拉拽”)。优先以停止线附近的黄线、路沿、栅栏等作为边界。
🔧 技术细节 (三): 车道决策
- 常规车道决策:
- 过滤重复与对向车道,以黄线/栅栏为左边界、路沿为右边界,确定当前车道
index。 - 根据轻地图转向信息,判断目标车道
index,发起换道意图。
- 过滤重复与对向车道,以黄线/栅栏为左边界、路沿为右边界,确定当前车道
- 选道功能 (一分二场景):
- 适用于近距离需切换车道的场景。
- 根据感知道线筛选候选区域,直接将参考线连接至目标车道,无需常规换道流程。
- 强制换道方案 (跨多车道):
- 方案一 (参考线直连): 并行生成两条参考线(当前直行、直接连接目标)。下游检查碰撞风险,风险高则直行错过路口(或报接管)。缺点是轨迹固定,非最优。
- 方案二 (大规模采样): 从当前位置到目标位置进行大规模轨迹采样 (含速度与横向位置地推),剪枝剔除不安全轨迹,从剩余轨迹中选择评价最优的执行。
- 兜底: 若所有采样均有风险,触发 Fallback 机制返回原车道。
⚙️ 疑难问题处理与迭代流程
1. 抖动与猛打问题
- 猛打定义: 0.5 秒内方向盘转角达 60-100 度;或轨迹横向加速度过大。
- 画龙定义: 车辆缓慢左右摆动,偏离预期直线。
- 优化: 规划侧保证近端轨迹稳定,控制侧设置方向盘转速硬限制。采样轨迹时对原始轨迹设置 cost 防抖,新轨迹无明显优势时沿用历史轨迹。
- 现存痛点: 规控侧与控制侧无明确责任划分阈值,存在问题扯皮,目前主要由规划侧主导优化。
2. 问题闭环处理流程 (JIRA 问题)
- 客户提出 JIRA 问题,每日表格跟踪。
- 大负责人分配给具体责任人。
- 责任人 1 日内完成分析、出方案。
- 修改代码后,通过数据回灌验证效果。
- 测试团队小范围验证,提交至
daily build。 - 合入稳定版 (release) 后,提请客户复测,通过后关闭问题。
💬 未来技术方向与岗位沟通
1. 个人技术诉求 (我的提问)
- 核心诉求: 希望采用时空联合 (XYT)、基于学习的前沿技术栈,优化当前横纵向解耦方案的局限性。
- 个人认知: 时空联合优点是能在三维空间获更优解;缺点是计算性能消耗大。
2. MMT 技术路线 (面试官解答)
- 并行发展: 时空联合规划 与 端到端学习 并行推进。端到端模型输出轨迹后,下游仍需平滑处理与安全兜底,不会完全替代传统优化。
- 决策逻辑: 决策环节已实现纯模型驱动。
- 端到端方案: 模型从图像输入,直接输出包含横纵向信息的轨迹与决策。下游仅在存在碰撞风险时调整决策,保障安全性。
3. 团队与岗位信息
- 团队规模: 规控相关团队整体达数百人,面试对应团队约 30 人。
- 岗位定位: 规划特色岗 (后续是否侧重模型或下游规划,需再定)。
- 应用场景: 主要面向园区 AVP 车型,速度限制在 25KM/H 以下,场景为非结构化道路 (园区通行与停车场)。
🎙️ 豆包面试总结
- 考察形式: 纯粹的项目深挖,全程高强度对技术细节。
- 考察重点: 参考线生成、特殊工况处理、问题迭代闭环、对方案局限性的思考。
- 个人感受: 整体状态较紧张,但基本都答上来了。
1 | |