Proponemos una arquitectura híbrida que combina un planificador local rápido y un Modelo de Lenguaje y Visión (VLM) lento. El planificador genera trayectorias candidatas dinámicamente factibles a alta frecuencia y el VLM proporciona juicio semántico de forma asíncrona con una latencia de 1–2 s. El desafío clave es salvar este desajuste temporal: ¿cómo puede el consejo obsoleto del VLM mejorar la selección de trayectorias en tiempo real?
Selección Visual de Trayectorias
Renderizamos las trayectorias candidatas sobre la imagen actual de la cámara como anotaciones numeradas y coloreadas, y dejamos que un VLM estándar elija un índice.
Superposición Visual. Proyectamos cada trayectoria candidata en el marco del cuerpo del robot sobre la imagen de la cámara utilizando los parámetros extrínsecos e intrínsecos conocidos de la cámara. Cada trayectoria se renderiza como una polilínea coloreada con su índice etiquetado en el punto final. La dirección del objetivo se marca opcionalmente con una flecha. Esta representación visual permite que el VLM razone directamente en el espacio de píxeles: puede ver hacia dónde lleva cada trayectoria en relación con los bordes de las aceras, peatones y obstáculos.
Despliegue sin Entrenamiento. Usamos VLMs estándar (Gemini, GPT-5, Qwen) sin ningún ajuste fino. La interfaz de prompting visual transforma la selección de trayectorias en una tarea de razonamiento visual que los VLMs de propósito general pueden resolver con cero ejemplos. Esto elimina la necesidad de datos de entrenamiento de VLA, adaptación de dominio o arquitecturas de modelos especializadas.
Experimentos
La evaluación tiene tres componentes: (1) selección de trayectorias offline en registros de navegación del mundo real; (2) simulación en lazo cerrado bajo latencia VLM con un planificador corrupto controlado, aislando el efecto de la latencia y la política de fusión; (3) un despliegue en el mundo real en aceras universitarias bajo latencia celular realista.
Simulación en Lazo Cerrado Bajo Latencia VLM
Estudiamos si los VLMs siguen siendo útiles bajo 1–3 s de latencia en lazo cerrado, y si la fusión preserva el margen de mejora que la ejecución directa de trayectorias VLM obsoletas no logra.
Conclusión
Hemos presentado un enfoque resiliente a la latencia para la navegación aumentada con VLM que permite el control continuo del robot a pesar de demoras de inferencia de 1–2 s del VLM. Nuestra idea clave es que un planificador rápido y un VLM lento proporcionan capacidades complementarias que pueden fusionarse en lugar de forzarse en un solo sistema. Los VLMs estándar destacan en la selección de trayectorias en escenarios semánticamente desafiantes (reducción del ADE en un 30%), mientras que los planificadores aprendidos siguen siendo competitivos en situaciones rutinarias, lo que motiva un enfoque de fusión en lugar de control exclusivo del VLM. La Fusión de Puntuación y Probabilidad permite el control continuo bajo latencia. El despliegue en el mundo real con Fusión de Probabilidad y Transmisión VLM reduce sustancialmente las intervenciones humanas en comparación con el planificador solo y la ejecución ingenua del VLM.
Nuestro enfoque hereda el conjunto de candidatos del planificador; si no existe un buen candidato, el VLM no puede ayudar. Encontramos que la selección del VLM no supera universalmente al planificador: en escenarios rutinarios, la puntuación aprendida del planificador a menudo es suficiente, y las consultas al VLM consumen recursos computacionales sin beneficio. Nuestro simulador de lazo cerrado también modela el VLM como un oráculo retardado, que no puede mostrar deriva de escena del mundo real. Los próximos pasos incluyen consultas adaptativas que invocan al VLM solo cuando el planificador está inseguro, estudiar la interacción entre el VLM y el planificador más allá de la selección de trayectorias, y probar todo el sistema en simuladores más realistas.
Resumen de la Interfaz
Nuestro VLM realiza selección de trayectorias en lugar de control de bajo nivel: en cada paso, un planificador local rápido propone un conjunto discreto de trayectorias candidatas de horizonte corto (horizonte de 4 s), y el VLM devuelve (i) el índice de un candidato a ejecutar a continuación o (ii) una decisión de detenerse cuando ninguno parece seguro. Esto limita las salidas del VLM a movimientos dinámicamente factibles y permite fallos de seguridad.
Planificador Local: Generación de Candidatos Basada en Anclas
Adoptamos S2E como nuestro planificador local. A diferencia de los modelos de navegación basados en difusión (por ejemplo, NoMaD), S2E utiliza coincidencia de distribución guiada por anclas para producir un conjunto estructurado de trayectorias candidatas.
Conjunto de anclas. El modelo define 64 puntos de ancla obtenidos mediante agrupamiento k-means sobre los puntos finales de las trayectorias en los datos de entrenamiento. Cada ancla representa un modo de comportamiento prototípico (por ejemplo, seguir recto, girar a la izquierda, reducir la velocidad, giro brusco). Estas anclas se fijan después del entrenamiento y sirven como consultas en un decodificador de atención cruzada.
Arquitectura y salidas. Dada la observación RGB actual (últimos 4 fotogramas) y una coordenada objetivo, un codificador EfficientNet y un codificador Transformer producen incrustaciones de contexto de escena. Luego, un decodificador Transformer aplica atención cruzada desde las 64 consultas de ancla a estas incrustaciones de contexto, produciendo características por ancla. Tres cabezas ligeras decodifican cada característica de ancla en:
- una puntuación (normalizada con softmax), que representa la confianza del modelo en que el ancla es el mejor modo de comportamiento para la situación actual;
- una trayectoria de regresión: una secuencia de 20 puntos de ruta (desplazamientos normalizados desde el ancla), formando una polilínea de 4 s y 20 puntos de ruta en el marco del robot;
- una escala de velocidad, que convierte la trayectoria normalizada en coordenadas métricas.
El resultado son 64 trayectorias candidatas, cada una con una puntuación del planificador asociada. En nuestro pipeline, seleccionamos los k mejores candidatos por puntuación (por defecto 8) para presentarlos al VLM.
Visualización de Candidatos (Diseño de Superposición)
Qué se renderiza. Renderizamos una superposición en la imagen de la cámara frontal con:
- trayectorias candidatas como polilíneas coloreadas (u opcionalmente como corredores de huella barrida);
- un pequeño punto en cada punto final del candidato;
- una etiqueta de índice entero cerca de cada punto final (el texto de la etiqueta es el ID autorizado);
- una señal opcional del objetivo (marcador GOAL magenta y/o una flecha "colgante").
Proyección y geometría. Los candidatos se definen en el marco del cuerpo del robot en el plano del suelo y se proyectan en la imagen de la cámara utilizando una proyección ojo de pez ligera. La leyenda de la superposición recuerda al VLM que la distorsión ojo de pez es normal cerca de los bordes de la imagen.
Desambiguación etiqueta-línea. Para reducir la confusión de índices cuando las trayectorias se superponen, cada etiqueta se dibuja con un color de fondo que coincide con el color de su trayectoria; si una etiqueta debe moverse para mejorar la legibilidad, una línea delgada de conexión une la etiqueta al punto final.
Diseño del Prompt
Separación de responsabilidades. El prompt del sistema impone una política de seguridad primero y define el formato de salida. El prompt de usuario proporciona el estado paso a paso: el objetivo (si lo hay), el número de candidatos y una tabla para los candidatos mostrados que incluye geometría (y opcionalmente la confianza del planificador, que a menudo ocultamos para evitar anclaje).
Semántica de horizonte corto. El prompt establece explícitamente que los candidatos cubren solo 4 s y que el objetivo puede estar fuera de la pantalla y mucho más allá del horizonte; por lo tanto, el comportamiento correcto es elegir un candidato localmente seguro que progrese, no "alcanzar el objetivo" en un solo paso.
Validación de Salida y Análisis Robusto
Para hacer la ejecución y evaluación robustas, validamos las salidas del VLM y normalizamos las desviaciones de formato comunes. El analizador maneja los siguientes casos en orden:
- Eliminación de bloques de código: El JSON envuelto en bloques de código Markdown (por ejemplo, bloques de triple comilla invertida json) se extrae antes del análisis.
- Extracción de objeto JSON: se analiza el primer bloque
{...}; se aceptan los valores de camposelect_trajectory,select,stopyhalt. - Valor entero simple: si la respuesta es un solo entero (sin JSON), se trata como un índice de trayectoria.
- Validación de índice: si el índice devuelto no está en el conjunto de etiquetas mostradas, el analizador intenta un mapeo basado en rango (interpretando el entero como un índice de fila basado en 0 en la tabla de candidatos). Si el mapeo también falla, la salida se trata como inválida.
Si el análisis falla por completo o el índice está fuera de rango después del mapeo, tratamos el paso como inválido y recurrimos a un comportamiento seguro (argmax del planificador o detención) en el despliegue.
Políticas y Manejo de Latencia
Evaluamos tres familias de políticas: (i) ejecución directa de trayectorias VLM obsoletas (VLM Hold y VLM Stream); (ii) coincidencia de la trayectoria VLM obsoleta con el candidato actual más cercano (VLM Match); y (iii) políticas de fusión que sesgan la selección del planificador hacia la intención VLM obsoleta mientras aún eligen entre candidatos actuales (Fusión de Puntuación / Fusión de Probabilidad).
Programación de solicitudes y segmentación. Distinguimos políticas de solicitud secuencial (enviar la siguiente consulta solo después de recibir la respuesta anterior; una sola solicitud en curso) de políticas de solicitud en transmisión (enviar a una cadencia fija; múltiples solicitudes en curso segmentadas). Esta separación aísla el efecto de la latencia de las limitaciones de rendimiento.
Arquitectura del Sistema
El sistema del mundo real sigue una arquitectura de dos velocidades: un planificador local rápido a bordo propone continuamente trayectorias candidatas de horizonte corto y dinámicamente factibles, mientras que un VLM más lento se consulta de forma asíncrona para proporcionar intención de alto nivel en forma de selección de trayectorias. Crucialmente, el control y la planificación nunca bloquean la respuesta del VLM. En su lugar, el sistema (i) ejecuta el planificador en un bucle de horizonte recedente y (ii) incorpora la intención VLM más reciente disponible utilizando las políticas de manejo de latencia descritas en el artículo principal (ejecución directa, coincidencia o fusión).
Ejecución asíncrona y alineación temporal. Cada solicitud VLM se etiqueta con un ID de solicitud monótonamente creciente y una marca de tiempo correspondiente al fotograma de la cámara utilizado para la superposición. Cuando llega la respuesta, la política la alinea con el tick de planificación actual utilizando (a) el ID de solicitud y (b) el conjunto de candidatos actual, aplicando: (i) ejecución de tipo hold (ejecutar la intención obsoleta directamente cuando sea factible), (ii) match (mapear la intención obsoleta al candidato actual más cercano), o (iii) fusión (sesgar la selección del planificador actual hacia la intención VLM obsoleta mientras aún se selecciona entre candidatos actualizados). Si no hay una salida VLM válida disponible, el sistema recurre a un valor predeterminado seguro (solo planificador con detención conservadora).
Consulta VLM, Manejo de Obsolescencia y Mecanismos de Seguridad
Programación de consultas. El VLM se consulta de forma asíncrona utilizando la imagen de superposición más el prompt de texto. Soportamos dos modos de programación:
- Secuencial (usado por vlm_hold y vlm_hold_match): una sola solicitud está en curso en cualquier momento; la siguiente solicitud se envía solo después de que se recibe y procesa la respuesta anterior. Esto maximiza la frescura por respuesta pero limita el rendimiento.
- Transmisión (usado por vlm_stream, score_fusion_stream, prob_fusion_stream): las solicitudes se envían a una cadencia fija (por defecto 1 Hz) independientemente de si han llegado respuestas anteriores, permitiendo múltiples solicitudes en curso. Cuando las respuestas regresan (potencialmente desordenadas debido a la latencia de red variable), el sistema adopta el consejo más reciente según la marca de tiempo de la consulta.
Validación de salida. Todas las salidas del VLM se analizan y validan. Las salidas inválidas (índice no entero, índice fuera de rango o formato no analizable) se descartan y se tratan como faltantes.
Seguridad con supervisión humana. Todas las ejecuciones del mundo real incluyen un operador de seguridad capacitado con capacidad de anulación inmediata (teleoperación o parada de emergencia). Cualquier intervención cancela inmediatamente la intención VLM actual y devuelve el control a un modo seguro; el evento de toma de control resultante se registra y se utiliza para calcular las métricas de seguridad reportadas en el artículo principal. Los límites de velocidad siempre se aplican, y el robot se opera solo en entornos peatonales donde una parada segura es factible en todo momento.
Protocolo de Evaluación y Métricas
Entornos y rutas. La evaluación se realiza en rutas peatonales al aire libre (por ejemplo, aceras y caminos universitarios) que contienen obstáculos naturales como peatones, bordillos, límites de superficie (césped/macetas) e intersecciones/bifurcaciones. Cada ruta se ejecuta múltiples veces por método en condiciones similares; todas las transmisiones de sensores, candidatos del planificador, índices elegidos e intervenciones del operador se registran con marcas de tiempo.
Ejecuciones y finalización. Una ejecución comienza en una pose inicial fija y continúa hasta que el robot alcanza el punto final de la ruta (dentro de una pequeña tolerancia). En nuestro protocolo experimental, cada prueba se completa independientemente del número de tomas de control: cuando ocurre una toma de control, el operador de seguridad guía manualmente el robot de vuelta a una pose segura y devuelve el control a la política autónoma. La ejecución continúa desde ese punto. Esto asegura que todas las métricas (tasa de tomas de control, suavidad de la trayectoria, tiempo de finalización) sean comparables entre métodos.
Preguntas Frecuentes
¿Cómo maneja el sistema la latencia del VLM sin bloquear el control del robot? El robot utiliza una arquitectura de dos velocidades donde un planificador local rápido se ejecuta continuamente en un bucle de horizonte recedente, y el consejo del VLM se incorpora de forma asíncrona utilizando políticas de fusión que nunca bloquean la respuesta del VLM.
¿Qué políticas de fusión evaluaron los autores para combinar el consejo VLM obsoleto con la salida fresca del planificador? Evaluaron la Fusión de Puntuación y la Fusión de Probabilidad, que sesgan la selección de trayectorias del planificador actual hacia la intención VLM obsoleta mientras aún eligen entre trayectorias candidatas actualizadas.
¿El VLM siempre supera al planificador aprendido en la selección de trayectorias? No, el VLM destaca en escenarios semánticamente desafiantes, pero el planificador aprendido a menudo es competitivo en situaciones rutinarias, lo que motiva el enfoque de fusión en lugar del control exclusivo del VLM.
¿Cómo se validan las salidas del VLM y se hacen robustas a errores de formato? El analizador maneja la eliminación de bloques de código, extracción de JSON, valor entero simple y validación de índice con mapeo basado en rango, recurriendo a un comportamiento seguro si el análisis falla por completo.