En un banco de pruebas reciente, un pequeño cuadrúpedo giró limpiamente hacia la derecha. El giro simétrico hacia la izquierda arrastró y perdió contacto con el piso. Las patas habían aterrizado en regiones distintas del servo y cargaron el cuerpo de forma diferente, así que el mismo comando produjo dos resultados. El código era simétrico; la mecánica de contacto no.

La analogía con Llama funciona hasta que el modelo tiene que mover hardware. El paper original de Llama le dio a los equipos de software un punto de partida reutilizable. Un equipo que no pagó la corrida de entrenamiento podía adaptar el modelo, encogerlo y servirlo por una ruta de software familiar. Los pesos eran útiles porque otros equipos ya tenían las herramientas para convertirlos en software corriendo.

Los modelos de robots se mueven de forma parecida, pero una política robótica no viaja sola. Un stack de control local convierte la salida de la política en movimiento sobre el robot instalado, vía su controlador y dentro del envelope de seguridad de la celda. El acceso a modelos va a expandir lo que los robots intentan. La ventaja vendrá de transformar ese comportamiento en trabajo soportado sobre sistemas instalados, con un registro de fallas que un técnico pueda usar meses después.

¿Por qué las políticas robóticas son cada vez más fáciles de descargar?

El proyecto Open X-Embodiment de Google DeepMind consolidó datos de robots de distintas instituciones y cuerpos, y sus resultados RT-X mostraron que entrenar a través de embodiments mejora la transferencia en algunos escenarios, en lugar de obligar a cada sistema a aprender solamente de su propio dataset acotado.

Los lanzamientos más recientes de DeepMind dividen el trabajo entre capas del stack. Gemini Robotics 1.5 es un modelo vision-language-action que toma información visual e instrucciones y las traduce en comandos de motor. Gemini Robotics-ER 1.6 se ubica más arriba en el stack, manejando razonamiento espacial y planeación de tareas, con soporte para chequeos de progreso y tool calls.

NVIDIA empujó la distribución en la misma dirección, con los releases de GR00T y los modelos Isaac entrando a canales para desarrolladores como LeRobot de Hugging Face. Desde el ángulo de distribución, la historia Llama encaja con la idea de que las políticas robóticas capaces se están volviendo más fáciles de obtener para desarrolladores.

Contra el conteo de Crunchbase de cerca de USD 14.000 millones en venture funding de robótica durante 2025, las rondas individuales se apilan rápido. Skild AI levantó USD 1.400 millones para un modelo robótico omni-bodied, mientras que Physical Intelligence estaría negociando otros USD 1.000 millones a una valuación sobre USD 11.000 millones. Advanced Machine Intelligence, de Yann LeCun, levantó USD 1.030 millones alrededor de un enfoque distinto al world modeling, y Wayve cerró una Serie D de USD 1.200 millones para conducción autónoma. Esas rondas asumen que la inteligencia robótica se vuelve reutilizable antes de que la industria pruebe que el camino de release funciona a través de sistemas.

OpenVLA es un modelo vision-language-action de 7B parámetros entrenado sobre 970.000 episodios de manipulación robótica de Open X-Embodiment. Physical Intelligence trabaja la cara de acciones con FAST, que convierte chunks de acción robótica en tokens. Su repositorio openpi muestra el trabajo que queda una vez que hay modelo disponible. Un equipo corre inferencia, hace tuning sobre sus propios datos de robot y valida el resultado sobre la máquina objetivo. Incluso ese camino tiene una factura de hardware: el repo lista más de 8 GB de memoria GPU para inferencia, 22,5 GB para fine-tuning con LoRA y 70 GB para fine-tuning completo.

¿Dónde se rompe realmente la transferencia?

Una celda robótica puede pasar la aceptación y correr limpiamente durante la mayoría de los ciclos. El problema más duro vive en los misses restantes, donde pequeños cambios físicos crean una tarea distinta a la que la política vio durante el tuning.

En sitios de cliente, la transferencia entre embodiments suele romperse por cambios ordinarios. La geometría de la cámara y la compliance del end-effector cambian después del sign-off, los datums de fixture se desplazan con el proceso del cliente, y la contaminación se acumula durante semanas de turnos antes de que el comportamiento de recovery se vuelva poco confiable. La site drift es justamente el desajuste entre el robot que pasó aceptación y el robot operando dentro del proceso del cliente.

La domain randomization entrena sobre muchas variaciones simuladas, pero el piso real introduce nuevas todos los días. Un comando puede preservar la misma intención de alto nivel y producir un resultado distinto cuando el contacto se mueve por otra trayectoria de carga. Un lado de un mecanismo puede empujar al frame de forma diferente, así que un movimiento que funciona en una dirección puede generar drag, balanceo o pérdida de contacto en la otra. Cuando eso pasa, suavizar el comando no va a arreglar un fallo cuya raíz real es el timing.

Los modelos embodiment-aware reducen una fuente del problema al representar el hardware del robot mediante cinemática, atributos de articulación, prompts o tokens. Una política que considera límites de joint y dinámica de actuadores arranca desde una mejor descripción del sistema. Algunas incógnitas se convierten en parámetros medidos, pero esa medición empieza a envejecer apenas el robot entra en producción. La fricción cambia, las herramientas se desgastan y las cargas varían según el proceso. Los movimientos de recovery también pueden crear estados que la calibración original no contempló. Mejores modelos de hardware hacen el rollout más diagnosticable, no más genérico.

En una línea real, el primer chequeo suele ser mundano. El equipo compara el último ciclo bueno con el ciclo fallado antes de culpar a la política. El cambio aparece en la pose, en el consumo de corriente o en el datum de fixture alrededor de la tarea. El modelo puede estar produciendo exactamente lo que producía durante las pruebas de aceptación, mientras la tarea local se movió lejos de los datos que lo entrenaron.

Los datos útiles llegan después del error

Los datos robóticos cargan una mochila distinta a los datos de lenguaje. Bessemer Venture Partners estimó que el total global de datos de manipulación robótica está en torno a las 300.000 horas, contra cerca de 1.000 millones de horas de video de internet y 300 billones de tokens de texto. Los modelos de lenguaje pudieron tirar de internet. Los robots tienen que construir la mayor parte de su corpus a partir de máquinas desplegadas.

NVIDIA está tratando de ensanchar ese corpus desde otro lado. La compañía dice que GR00T N1.7 fue preentrenado sobre más de 20.000 horas de video egocéntrico humano en lugar de teleoperación robótica, apostando a que las imágenes en primera persona cargan priors útiles de manipulación.

Una parte igualmente importante del dataset es el contexto de falla, que incluye el estado del controlador, la acción de recovery y la causa física. Una cámara puede mostrar que el robot falló, pero puede no explicar por qué el gripper perdió la pieza o por qué se disparó el paro de seguridad. También puede pasar por alto cuál fue el movimiento de recovery que volvió a poner la celda en marcha. Los logs fallan de otra forma cuando se separan del evento físico. Un log puede mostrar progreso contra una métrica estrecha de control mientras el robot está visiblemente arrastrándose en la tarea. Puede acumular el número que el software quiere, mientras produce un comportamiento que sería inaceptable para un cliente. Los logs solo ganan su lugar cuando el equipo puede emparejarlos con lo que pasó en la celda.

La teleoperación y la simulación pueden generar datos antes de que un sistema llegue al piso, pero el mejor registro viene de robots instrumentados corriendo procesos de cliente con suficiente contexto para diagnosticar fallas después. Una empresa que convierte el historial de fallas en movimientos de recovery más seguros aprende más de cada instalación que una que guarda videos limpios de éxito. El técnico tiene que separar una falla de política de una herramienta resbalada, un fixture desplazado o un camino de recovery que empeoró el ciclo siguiente.

Futuros simulados, contacto real

Los world models están pensados para probar decisiones antes de poner hardware en riesgo. Marble de World Labs construye mundos 3D a partir de prompts o entradas visuales y los exporta a formatos para simulación y design review. En conducción autónoma, GAIA-3 de Wayve sigue un camino similar como modelo del mundo de 15.000 millones de parámetros, pensado para evaluación offline realista y controlable de IA de manejo autónomo.

Los World Action Models acercan el world modeling al control. DreamZero define la arquitectura como un modelo que predice estados del mundo futuros y acciones a partir de video. NVIDIA previó GR00T N2 sobre esa investigación, afirmando que tiene éxito en tareas nuevas dentro de entornos nuevos más del doble de veces que los modelos VLA líderes, y que queda primero en los benchmarks MolmoSpaces y RoboArena. NVIDIA dice que N2 llegará más adelante este año.

La acción generada tiene que pasar por el controlador antes de convertirse en movimiento. La conducción está acotada por la geometría del camino y la dinámica del vehículo. La manipulación introduce contacto directo, y el contacto introduce modos de falla que son más difíciles de capturar limpiamente en simulación. El cierre de fuerza puede estar mal, los sellos se desgastan y la calibración puede driftear lo suficientemente lento como para que la línea siga corriendo hasta que deje de repetir.

La simulación se vuelve más útil cuando la fricción, la respuesta del actuador, el centro de masa y los límites de tasa son medidos y no asumidos. Incluso así, el equipo mantiene el simulador calibrado contra el hardware y vigila el punto en el que el sistema real driftea más allá del modelo. Un simulador medido reduce el espacio de búsqueda antes de que alguien toque hardware, pero no sustituye el chequeo contra el sistema ejecutando tareas reales.

El controlador es donde se valida la promesa

La salida del modelo llega al mundo a través del controlador. Agility Robotics describió un whole-body control model para Digit. El modelo es un LSTM pequeño, con menos de 1 millón de parámetros, entrenado en NVIDIA Isaac Sim durante décadas de tiempo simulado a lo largo de varios días.

Muchas políticas VLA operan a la cadencia de acciones por tarea o chunks de acción. Un loop industrial típico de servo cierra cerca de 1 kHz. Una salida de modelo se vuelve útil solo cuando el controlador la traduce en movimiento ejecutable dentro de los límites del robot. La arquitectura de movimiento puede decidir el resultado antes incluso de que el controlador rechace un comando. Un path construido a partir de poses limpias puede arrastrar pausas o un mal timing de contacto. En movimientos cíclicos, la fase continua puede importar más para el resultado que el pulido de pose, y un movimiento de recovery que en el espacio de comando parece conservador puede llegar tarde al punto de contacto.

Incluso un paso conservador de post-procesado puede abrir una nueva falla al cambiar el timing de contacto o retrasar un recovery a una parte peor de la dinámica local del robot. Filtrar puede hacer que el comando se vea más limpio mientras coloca el pie o la herramienta tarde, parecido al giro simétrico del cuadrúpedo que se veía simétrico en código y arrastraba en contacto. Para sistemas industriales, la capa de seguridad también define lo que la capa aprendida puede hacer cuando el modelo está incierto o el estado de máquina cambió.