我们提出一种混合架构，结合了快速本地规划器与慢速视觉语言模型（VLM）。规划器以高频率生成动态可行的候选轨迹，而VLM则以1–2秒延迟异步提供语义判断。关键挑战在于弥合这种时间错配：过时的VLM建议如何改善实时轨迹选择？
视觉轨迹选择
我们将候选轨迹以编号、彩色标注的形式渲染到当前摄像头图像上，并使用现成的VLM来选择索引。
视觉叠加。 我们利用已知的相机外参和内参，将机器人本体坐标系中的每个候选轨迹投影到摄像头图像上。每条轨迹以彩色折线渲染，终点处标注其索引。目标方向可选用箭头标记。这种视觉表示让VLM直接在像素空间中推理：它可以看到每条轨迹相对于人行道边界、行人和障碍物的走向。
免训练部署。 我们使用现成的VLM（Gemini、GPT-5、Qwen）而不进行任何微调。视觉提示界面将轨迹选择转化为一个通用VLM可以零样本解决的视觉推理任务。这消除了对VLA训练数据、领域适配或专用模型架构的需求。
实验
评估包含三个部分：（1）基于真实世界导航日志的离线轨迹选择；（2）在VLM延迟下，使用受控的损坏规划器进行闭环仿真，以隔离延迟和融合策略的影响；（3）在真实校园人行道上的部署，考虑实际的蜂窝网络延迟。
考虑VLM延迟的闭环仿真
我们研究了在闭环条件下，VLM在1–3秒延迟下是否仍然有用，以及融合策略是否保留了直接执行过时VLM轨迹所无法带来的优势。
结论
我们提出了一种对延迟鲁棒的VLM增强导航方法，尽管VLM推理延迟为1–2秒，仍能实现连续的机器人控制。我们的关键洞察是：快速规划器和慢速VLM提供了互补的能力，可以融合而非强行整合到单一系统中。现成的VLM在语义挑战场景中擅长轨迹选择（ADE降低30%），而学习型规划器在常规场景中仍有竞争力——这促使采用融合方法而非纯VLM控制。分数融合和概率融合使得在延迟下实现连续控制成为可能。实际部署中，概率融合与VLM流式传输相比纯规划器和朴素VLM执行显著减少了人工干预。
我们的方法继承了规划器的候选集；如果没有好的候选轨迹，VLM也无能为力。我们发现VLM选择并非普遍优于规划器：在常规场景中，规划器的学习评分通常足够，而VLM查询消耗计算资源却无益处。我们的闭环仿真器还将VLM建模为延迟的预言机，无法体现真实世界的场景漂移。下一步工作包括自适应查询（仅在规划器不确定时调用VLM）、研究VLM与规划器在轨迹选择之外的交互，以及在更真实的仿真器中测试整个系统。
接口概述
我们的VLM负责轨迹选择而非底层控制：每一步，快速本地规划器提出一组离散的短时域候选轨迹（4秒时域），VLM返回（i）要执行的候选轨迹索引，或（ii）当所有轨迹都不安全时发出停止决策。这约束了VLM输出必须符合动态可行的运动，并允许安全回退。
本地规划器：基于锚点的候选生成
我们采用S2E作为本地规划器。与基于扩散的导航模型（如NoMaD）不同，S2E使用锚点引导的分布匹配来生成结构化的候选轨迹集。
锚点集。 该模型定义了64个锚点，通过对训练数据中轨迹终点进行k-means聚类得到。每个锚点代表一个原型行为模式（例如直行、左转、减速、急转）。这些锚点在训练后固定，并用作交叉注意力解码器的查询。
架构与输出。 给定当前RGB观测（过去4帧）和目标坐标，EfficientNet编码器和Transformer编码器生成场景上下文嵌入。Transformer解码器从64个锚点查询对这些上下文嵌入进行交叉注意力，生成每个锚点的特征。三个轻量级预测头将每个锚点特征解码为：
- 分数（softmax归一化），表示模型认为该锚点是当前最佳行为模式的置信度；
- 回归轨迹：由20个航点组成的序列（相对于锚点的归一化偏移），形成机器人坐标系中4秒、20个航点的折线；
- 速度缩放因子，将归一化轨迹转换为公制坐标。
结果是64个候选轨迹，每个都有对应的规划器分数。在我们的流程中，我们按分数选择前k个候选（默认8个）呈现给VLM。
候选可视化（叠加设计）
渲染内容。 我们在前摄像头图像上渲染叠加层，包括：
- 彩色折线表示的候选轨迹（或可选地显示为足迹走廊）；
- 每个候选终点的小圆点；
- 每个终点附近的整数索引标签（标签文本是权威ID）；
- 可选的目标提示（品红色GOAL标记和/或“悬挂”箭头）。
投影与几何。 候选轨迹定义在机器人本体坐标系的地平面上，通过轻量级鱼眼投影映射到摄像头图像。叠加层的图例提醒VLM，靠近图像边缘的鱼眼畸变是正常的。
标签与线条的区分。 为了减少轨迹重叠时的索引混淆，每个标签以与其轨迹颜色相同的背景色绘制；如果标签需要移动以保持可读性，则使用细引导线连接标签和终点圆点。
提示设计
关注点分离。 系统提示强制执行安全优先策略并定义输出格式。用户提示提供每一步的状态：目标（如果有）、候选数量以及显示候选的表格，包括几何信息（以及可选的规划器置信度，我们通常隐藏以避免锚定效应）。
短时域语义。 提示明确指出候选轨迹仅覆盖4秒，并且目标可能位于屏幕外且远远超出时域；因此正确的行为是选择一个局部安全且能取得进展的候选，而不是一步“到达目标”。
输出验证与鲁棒解析
为了确保执行和评估的鲁棒性，我们验证VLM输出并标准化常见的格式偏差。解析器按顺序处理以下情况：
- 代码块剥离： 提取在Markdown代码块中（例如三重反引号json块）的JSON后进行解析。
- JSON对象提取： 解析第一个
{...}块；接受action字段的值select_trajectory、select、stop和halt。 - 裸整数回退： 如果响应是单个整数（没有JSON），则视为轨迹索引。
- 索引验证： 如果返回的索引不在显示的标签集合中，解析器尝试基于排名的映射（将整数解释为候选表格中基于0的行索引）。如果映射也失败，则输出视为无效。
如果解析完全失败或映射后索引超出范围，我们将该步骤视为无效，并在部署中回退到安全行为（规划器argmax或停止）。
策略与延迟处理
我们评估了三类策略：（i）直接执行过时的VLM轨迹（VLM Hold和VLM Stream）；（ii）将过时的VLM轨迹匹配到最近的当前候选（VLM Match）；（iii）融合策略，在仍然选择当前候选的同时将规划器选择偏向过时的VLM意图（分数融合/概率融合）。
请求调度与流水线。 我们区分顺序请求策略（收到上一个响应后才提交下一个查询；单个在途请求）和流式请求策略（以固定频率提交；多个流水线在途请求）。这种区分将延迟的影响与吞吐量限制分离开来。
系统架构
真实世界系统采用双速率架构：快速机载本地规划器连续提出短时域、动态可行的候选轨迹，而较慢的VLM异步查询提供高层意图（轨迹选择形式）。关键之处在于，控制和规划从不阻塞等待VLM响应。相反，系统（i）在递推时域循环中执行规划器，并（ii）使用论文中描述的延迟处理策略（直接执行、匹配或融合）合并最新的可用VLM意图。
异步执行与时间对齐。 每个VLM请求都标记有单调递增的请求ID和用于叠加的摄像头帧的时间戳。当响应到达时，策略使用（a）请求ID和（b）当前候选集将其与当前规划周期对齐，应用以下方式之一：（i）保持式执行（在可行时直接执行过时意图），（ii）匹配（将过时意图映射到最近的当前候选），或（iii）融合（在仍选择最新候选的同时将当前规划器选择偏向过时的VLM意图）。如果没有有效的VLM输出，系统回退到安全默认值（纯规划器配合保守停止）。
VLM查询、延迟处理与安全机制
查询调度。 VLM使用叠加图像加文本提示异步查询。我们支持两种调度模式：
- 顺序模式（用于vlm_hold和vlm_hold_match）：任何时候只有一个在途请求；只有在收到并处理前一个响应后才提交下一个请求。这最大化了每个响应的新鲜度，但限制了吞吐量。
- 流式模式（用于vlm_stream、score_fusion_stream、prob_fusion_stream）：无论先前响应是否到达，请求以固定频率（默认1 Hz）提交，允许多个在途请求。当响应返回时（可能由于网络延迟变化而乱序），系统按查询时间戳采用最新的建议。
输出验证。 所有VLM输出都经过解析和验证。无效输出（非整数索引、超出范围索引或不可解析格式）被丢弃并视为缺失。
人在回路安全。 所有真实世界运行都包括经过培训的安全操作员，具备即时干预能力（远程操作或紧急停止）。任何干预立即取消当前VLM意图，并将控制权返回安全模式；由此产生的接管事件被记录并用于计算论文中报告的安全指标。速度限制始终强制执行，机器人仅在行人环境中运行，且始终可以安全停止。
评估协议与指标
环境与路线。 评估在户外行人路线（例如人行道和校园路径）上进行，包含自然障碍物，如行人、路缘、路面边界（草地/花坛）以及交叉口/岔路。每条路线每种方法在相似条件下执行多次；所有传感器流、规划器候选、所选索引和操作员干预均带有时间戳记录。
运行与完成。 运行从固定起始位置开始，持续到机器人到达路线终点（在较小容差内）。在我们的实验协议中，无论发生多少次接管，每次试验都完成：当发生接管时，安全操作员手动将机器人引导至安全位置，然后将控制权返回自主策略。运行从该点继续。这确保了所有指标（接管率、轨迹平滑度、完成时间）在各方法间具有可比性。
常见问题
系统如何在不阻塞机器人控制的情况下处理VLM延迟？ 机器人使用双速率架构：快速本地规划器在递推时域循环中连续运行，VLM建议通过融合策略异步合并，从不阻塞等待VLM响应。
作者评估了哪些融合策略来结合过时的VLM建议与最新的规划器输出？ 他们评估了分数融合和概率融合，这两种方法在仍然选择最新候选轨迹的同时，将当前规划器的轨迹选择偏向过时的VLM意图。
VLM在轨迹选择方面是否总是优于学习型规划器？ 不，VLM在语义挑战场景中表现优异，但学习型规划器在常规场景中通常具有竞争力，这促使采用融合方法而非纯VLM控制。
如何验证VLM输出并使其对格式错误具有鲁棒性？ 解析器处理代码块剥离、JSON提取、裸整数回退和带排名映射的索引验证，如果解析完全失败则回退到安全行为。