Prueba de aceptación de ruta de política de Xiaomi-Robotics-1: llevar checkpoints VLA a un despliegue seguro

Un checkpoint robótico puede verse sólido en un benchmark y aun así no estar listo para una celda de trabajo calibrada. La verdadera prueba de aceptación de ruta de política de Xiaomi-Robotics-1 empieza en los momentos incómodos: la cámara se desplaza, un objeto cae fuera de la pose esperada, el reinicio falla, la latencia de inferencia se dispara o un operador necesita que el sistema se detenga antes de que un pequeño error se convierta en un incidente de seguridad.

Esa es la perspectiva correcta para Xiaomi-Robotics-1. El proyecto oficial lo describe como un modelo fundacional robótico de visión-lenguaje-acción entrenado con más de 100,000 horas de trayectorias de manipulación UMI del mundo real, seguido de post-entrenamiento con más de 10,000 horas de datos de múltiples encarnaciones. El repositorio, la página del proyecto, el informe de arXiv, la colección de Hugging Face, el código de despliegue y las carpetas de evaluación de benchmarks lo hacen más útil que una versión solo de demostración. También amplían la superficie de evaluación.

La pregunta útil no es si este checkpoint equivale a autonomía robótica. Es si este checkpoint puede convertirse en una ruta candidata: una ruta de política acotada que se pueda reproducir, fijar, ejecutar en sombra, desplegar como canary, desactivar y revertir. Un benchmark pregunta si un modelo puede completar tareas bajo una configuración definida. Una prueba de aceptación de ruta pregunta si un equipo puede reproducir el artefacto, mapearlo a su encarnación robótica, medir el bucle completo de percepción-política-acción y mantener intacta la autoridad humana cuando el comportamiento se vuelve extraño.

Este ángulo difiere del trabajo de robótica de video en el edge, donde la principal superficie de decisión es el rendimiento de sensores, los códecs y los pipelines de video en dispositivo. Para un contexto más amplio sobre infraestructura robótica, consulta la pieza relacionada de Optijara sobre JetPack 7.2.1 y robótica de video en el edge. Xiaomi-Robotics-1 plantea una pregunta separada: ¿puede un checkpoint abierto de política VLA convertirse en una ruta contenida de política robótica después de controles de calibración, temporización, seguridad y recuperación? Para patrones adyacentes de evaluación de políticas robóticas abiertas, compáralo con la prueba de aceptación de cuerpo completo de LingBot-VLA 2.0 de Optijara.

Por qué Xiaomi-Robotics-1 necesita un control de despliegue, no otro resumen de benchmarks

El README oficial dice que Xiaomi-Robotics-1 combina un VLM preentrenado, Qwen3-VL, con un Diffusion-Transformer mediante un diseño Mixture-of-Transformers. Reporta más de 100,000 horas de trayectorias UMI libres de encarnación en más de 1,700 escenarios, y luego post-entrenamiento con datos de múltiples encarnaciones, incluidos datos propios de robots reales, datos robóticos abiertos filtrados y datos UMI anotados manualmente. La colección de Hugging Face enumera checkpoints publicados, incluidos Xiaomi-Robotics-1-5B y checkpoints específicos de benchmark para RoboCasa, RoboCasa365 y VLABench.

Esos artefactos merecen atención. No son prueba de despliegue. El README reporta puntuaciones de benchmark en RoboCasa, RoboCasa365, VLABench y RoboDojo, incluido 57.4 por ciento en RoboCasa365 frente a 46.6 por ciento para la segunda mejor entrada de la tabla. Trata esos números como afirmaciones de benchmark reportadas por el proyecto hasta que un equipo las reproduzca con código fijado, pesos fijados, versiones de simulador coincidentes y configuraciones de evaluación coincidentes.

El problema de despliegue es más desordenado que completar tareas en un benchmark. Una ruta robótica tiene que sobrevivir a deriva de calibración, frames obsoletos, oclusión parcial, desplazamientos de objetos, errores de reinicio, límites de red, errores del adaptador de acciones e intervención humana. Si la política se ejecuta mediante una división cliente-servidor, como describen las guías de evaluación de RoboCasa y VLABench, la prueba de aceptación también tiene que medir idas y vueltas de socket, sobrecarga de serialización, inferencia del modelo, despacho de acciones, respuesta de actuadores y jitter en bucles repetidos. La misma disciplina de preparación se aplica también fuera de la robótica, como se muestra en la prueba de aceptación AEO de preparación de agentes de Cloudflare de Optijara.

El mapa de artefactos: lo que los equipos deben fijar antes de que cualquier robot se mueva

Antes de que un robot se mueva, el equipo necesita un mapa de artefactos que pueda reconstruirse más adelante. Fija el commit del repositorio público, la revisión exacta del checkpoint de Hugging Face, hashes de archivo para los artefactos del modelo, la licencia de código Apache-2.0, los términos de la model card, el lockfile de dependencias, la pila CUDA y PyTorch, las versiones de transformers, las versiones de simulador, las configuraciones de benchmark, los scripts de despliegue y cualquier firmware de robot o compilación de controlador usada en pruebas de hardware.

El código del servidor de despliegue carga un AutoModel con trust_remote_code, flash attention, bfloat16, CUDA y devuelve tensores de acción serializados con pickle. El README de evaluación de RoboCasa especifica RoboCasa v0.2, Python 3.10, transformers 4.57.1 y una división cliente-servidor en dos entornos conda. El README de evaluación de VLABench especifica su propio entorno, versiones fijadas de MuJoCo y dm_control, y una forma de acción sin procesar de [10, 60], con las primeras 7 dimensiones ejecutables para delta de posición, delta de rotación Euler y control de pinza.

El contrato de entrada/salida necesita su propio inventario. Registra nombres de cámaras, resolución de imagen, preprocesamiento, formato de instrucciones, campos de propiocepción si se usan, task_id o clave de robot, forma del tensor de acción, escalado de acciones, semántica de la pinza, frecuencia de acciones, comportamiento de batching, protocolo de endpoint y la capa de adaptador específica del robot. Si un campo queda implícito, el equipo no está evaluando una ruta. Está apostando. Para equipos que formalizan controles más amplios de lanzamiento de modelos, la prueba de aceptación de despliegue de Motif 3 de Optijara ofrece un paralelo útil para separar afirmaciones del modelo de evidencia de ruta.

El marco R-PATH de Optijara para aceptación de rutas de políticas robóticas

R-PATH es un marco práctico de aceptación para pasar de un checkpoint de investigación a una ruta contenida de política robótica. Sus pasos son Reproducir, Fijar, Alinear, Probar y Mantener.

R: Reproducir la ruta publicada

Empieza en simulación, no en hardware. Reproduce la ruta documentada de RoboCasa, RoboCasa365 o VLABench que coincida con el checkpoint que planeas inspeccionar. Los documentos de evaluación de Xiaomi-Robotics-1 usan una configuración cliente-servidor en la que el servidor carga el modelo y sirve acciones por un socket, mientras el cliente ejecuta el simulador, crea entradas con AutoProcessor y decodifica acciones. Ese límite es donde aparecen muchos problemas de despliegue.

P: Fijar la política y la plataforma

Una vez que exista una ejecución base, congela todo lo mutable. Fija código, checkpoint, dependencias, comportamiento del procesador, assets del simulador, definiciones de tareas, scripts de lanzamiento, variables de entorno y configuración de hardware. Agrega checksums para archivos del modelo y archivos del adaptador de ruta. Guarda los comandos de lanzamiento junto a los metadatos de ejecución.

A: Alinear cámaras, acciones y encarnación

El preentrenamiento libre de encarnación es prometedor porque puede aprender patrones amplios de manipulación antes de la alineación específica del robot. No elimina la necesidad de mapeo específico del robot. Alinea intrínsecos y extrínsecos de cámara, convenciones de frames, iluminación, recorte de imagen, escala de objetos, límites del espacio de trabajo, pose base, cinemática del brazo, escalado de acciones, semántica de apertura y cierre de la pinza, posiciones de reinicio y definiciones de tareas.

T: Probar temporización de bucle cerrado y recuperación

Mide el bucle completo, no solo la inferencia del modelo. El bucle incluye captura de cámara, preprocesamiento, transferencia de red si se usa, inferencia del modelo, serialización de acciones, conversión del adaptador de acciones, despacho del controlador, respuesta del actuador, actualización de observaciones y evaluación del control de seguridad. Registra distribuciones de latencia y jitter, no solo promedios. Luego prueba oclusiones, frames retrasados, observaciones obsoletas, instrucciones ambiguas, objetos desplazados, agarres fallidos, rutas bloqueadas, fallos de reinicio y eventos de parada de emergencia.

H: Mantener autoridad humana y rollback

Ninguna ruta VLA debe superar en prioridad al mecanismo de parada. La autoridad humana de parada, los límites físicos del espacio de trabajo, el fallback de parada segura, el fallback a controlador base, el modo sombra, el modo canary y las reglas de rollback deben existir antes de la expansión.

Matriz de decisión de ruta: cuándo Xiaomi-Robotics-1 está listo, no está listo o solo está listo para sandbox

Esta matriz es intencionalmente conservadora. Aprobar un benchmark puede justificar continuar la evaluación. No debería autorizar por sí solo la actuación en una celda de trabajo de producción. Xiaomi-Robotics-1 puede ser el candidato adecuado para una evaluación amplia de manipulación, pero un controlador programado más estrecho, una política de aprendizaje por imitación, un flujo asistido por teleoperación o una pila robótica específica de proveedor puede ser mejor para una tarea restringida con requisitos estrictos de repetibilidad. Eso es ingeniería ordinaria: usa el modelo donde importa la adaptabilidad y usa control más simple donde importa más la repetibilidad.

Checklist de implementación: del checkpoint a la ruta robótica calibrada

Empieza con predicciones en sombra, donde la política observa pero no actúa. Compara las acciones propuestas con envolventes seguras esperadas. Luego pasa a tareas canary contenidas con supervisión humana, límites físicos y un fallback base. Si un canary falla por calibración, latencia, reinicio o comportamiento fuera de distribución, revierte la ruta en lugar de editar el entorno hasta que el fallo desaparezca.

En qué se equivocan los equipos al evaluar políticas robóticas VLA abiertas

El primer error es confundir cobertura de benchmark con cobertura operativa. RoboCasa, RoboCasa365 y VLABench son valiosos porque proporcionan entornos estructurados para evaluación. La página del proyecto RoboCasa365 lo describe como un conjunto que abarca 365 tareas y más de 2,500 entornos de cocina, con más de 600 horas de datos de demostración humana y más de 1,600 horas de demostraciones generadas sintéticamente. Ningún benchmark puede demostrar que una celda de trabajo objetivo, distribución de objetos, configuración de iluminación, rutina de reinicio y límite de seguridad estén cubiertos.

El segundo error es omitir el mapeo de encarnación. El entrenamiento libre de encarnación o de múltiples encarnaciones puede ayudar al modelo a aprender patrones de manipulación transferibles. No garantiza que la pose de tu cámara, pinza, escala de acciones, frame de coordenadas o temporización del controlador coincida con las suposiciones de la política.

El tercer error es medir éxito mientras se ignora la recuperación. Una ruta que completa una tarea en condiciones limpias pero se comporta mal después de un agarre fallido no está lista para expansión. El comportamiento de recuperación, la gestión de casi incidentes, la detección fuera de distribución, la parada segura y la política de reinicio a menudo importan más que clips de éxito aislados.

El cuarto error es tratar la latencia como un promedio. Una ruta de política puede tener una media aceptable y aun así fallar por jitter, observaciones obsoletas o retrasos intermitentes del servidor. Observa las colas, no solo el centro de la distribución.

Plan de medición: evidencia que recopilar antes de aprobar la ruta

Un paquete de aprobación de ruta debería responder una pregunta incómoda: ¿podría otro equipo inspeccionar la misma ejecución y entender exactamente qué pasó? Captura commit de origen, hash de checkpoint, configuración, entorno, encarnación robótica, ID de calibración de cámara, tarea, seed si aplica, instrucción, pila de runtime, hora de inicio y fin, operador y modo de ruta. Luego captura resultado de tarea, razón de intervención, casi incidente, colisión, activador fuera de distribución, resultado de reinicio, activación de fallback, evento de rollback, distribución de latencia, jitter, observaciones perdidas, observaciones obsoletas y modo de fallo observado.

El costo por hora de tarea aceptada es útil si se trata como métrica interna, no como promesa universal. Puede combinar tiempo de hardware, supervisión del operador, sobrecarga de reinicio, costo de cómputo, mantenimiento, ejecuciones rechazadas y tiempo de tarea exitosa aceptada. El punto es comparar rutas sin ocultar el trabajo de reinicio y el costo de supervisión.

{
  "route_status": "shadow",
  "policy": "Xiaomi-Robotics-1 candidate route",
  "required_pins": ["repo_commit", "checkpoint_hash", "dependency_lock", "calibration_id"],
  "accepted_tasks": ["team_defined_after_canary"],
  "excluded_tasks": ["uncalibrated_or_high_risk_tasks"],
  "safety_gates": ["independent_human_stop", "workspace_limit", "fallback", "rollback"],
  "rollback_condition": "timing, recovery, OOD, collision, or reset behavior outside acceptance band",
  "unresolved_caveats": ["sim_to_real_gap", "benchmark_leakage", "calibration_drift", "model_weight_terms"]
}

Salvedades, límites y el siguiente paso práctico

Vale la pena evaluar Xiaomi-Robotics-1 porque incluye código público, rutas de despliegue, enlaces de checkpoints, guías de benchmark, una página de proyecto y un informe técnico. Eso hace posible una reproducción seria. No elimina las partes difíciles del despliegue robótico.

Las principales salvedades son el costo de implementación, las brechas entre simulador y mundo real, fuga de benchmark o solapamiento de datasets, varianza de modelo y proveedor, privacidad de datos de cámara, deriva de calibración, términos de assets de terceros, límites de certificación de seguridad y trade-offs operativos. No despliegues si los artefactos no se pueden fijar, la evaluación no se puede reproducir, las encarnaciones soportadas no coinciden con el robot, la temporización es inestable, la parada de seguridad no es independiente, la recuperación es pobre, la política de reinicio no está clara o el rollback depende de actos manuales extraordinarios.

El siguiente paso práctico es tratar Xiaomi-Robotics-1 como una ruta candidata detrás de R-PATH, no como un despliegue automático. Reproduce primero, fija los artefactos, alinea la encarnación, prueba temporización y recuperación de bucle cerrado, y mantén visible la autoridad humana mediante controles canary y rollback. Si tu equipo evalúa políticas robóticas u otras rutas de automatización de IA, Optijara puede ayudar a diseñar controles de aceptación, telemetría, rigs de evaluación y planes de rollout que conecten artefactos de investigación con evidencia operativa.