ACTUALIDAD EN IA Y TECNOLOGÍA
Inicio / Artículos / Robótica
Robótica · Google DeepMind / Apptronik

Google conecta vídeo, simulación y el humanoide Apollo en una demostración con Gemini Argon

Google mostró el 13 de octubre de 2026 un flujo de robótica con Gemini 4 Argon que conecta vídeo, simulación y ejecución en Apollo. El modelo ayuda a reconstruir la tarea y preparar movimientos antes de trasladarlos al humanoide.

Google DeepMind / Apptronik: imagen del material de presentación
Imagen del vídeo de Google DeepMind / Apptronik.

Ver a una persona lanzar un objeto no proporciona de inmediato las órdenes que necesita otro cuerpo para repetir el gesto. Hay que reconstruir la escena, identificar el objetivo y adaptar la acción a una mecánica distinta. Google mostró el 13 de octubre de 2026 un flujo con Gemini 4 Argon que recorre ese camino hasta el humanoide Apollo. [1]

El caso principal utiliza cornhole, un juego en el que se lanza hacia un objetivo. Google comunica siete aciertos consecutivos. La cifra corresponde a la demostración que presenta la compañía; no ofrece por sí sola una tasa de éxito general ni una comparación independiente con otros sistemas. [1]

Lo que un vídeo permite reconstruir

Google describe un ensayo en el que Argon observa a una persona jugando a cornhole, interpreta el espacio y genera código de simulación. La secuencia termina trasladando movimientos al humanoide Apollo de Apptronik. La empresa comunica siete aciertos consecutivos en una prueba real. [1]

La explicación exige conservar los pasos intermedios. No estamos ante un robot que recibe un vídeo y adquiere instantáneamente cualquier habilidad. Reconstruir el escenario, representar la física y adaptar movimientos al cuerpo disponible son partes distintas de la tarea. Eliminarlas del relato convertiría un flujo de investigación en una promesa excesiva.

Un vídeo ofrece imágenes desde una cámara, no una descripción física completa. Para construir un entorno de práctica hay que estimar dónde están los objetos, cómo se mueven y qué contactos importan. La perspectiva puede ocultar tamaños o distancias; un material visualmente parecido puede tener otra fricción.

El objetivo de la reconstrucción no es solo parecerse a la escena. Si se va a estudiar un lanzamiento, la trayectoria y la interacción con el destino deben responder al cálculo. Una imagen convincente que permite atravesar superficies sería útil como animación, pero no como prueba del comportamiento de un robot.

La persona y el robot tienen proporciones y articulaciones diferentes. Copiar coordenadas sin adaptarlas puede exigir una postura imposible o desestabilizar el cuerpo. La transferencia debe expresar la intención de la acción dentro de los movimientos disponibles en la plataforma.

Para lanzar un objeto no basta con mover la mano. Hay que coordinar aceleración, orientación, liberación y equilibrio. Una simulación ayuda a explorar esa coordinación, pero la ejecución real incorpora sensores, retrasos y contacto. Cada etapa reduce una parte de la incertidumbre y conserva otras.

Practicar antes de mover el robot

La documentación distingue control, reconstrucción de escenas y comprensión física. Incluye gemelos digitales a partir de cámaras de robot, vídeo humano y bocetos, además de comprobaciones de contacto. [2] Son ejemplos diferentes y no una lista de capacidades ya demostradas por Apollo en el mismo ensayo.

La distinción evita sumar demostraciones como si pertenecieran a un único robot. Un experimento de mesa con dos brazos puede explicar una técnica sin acreditar locomoción. Un cuadrúpedo puede mantener equilibrio al accionar un pedal sin que ese resultado indique cómo lo hará un humanoide al lanzar. El cuerpo y la tarea forman parte de la evidencia.

Un ciclo cerrado usa el resultado de una acción para decidir la siguiente. En simulación puede comparar la trayectoria esperada con la obtenida y ajustar un parámetro. En hardware necesita además observar lo ocurrido y distinguir error de percepción, de planificación o de ejecución.

Ese diagnóstico importa porque dos fallos parecidos pueden tener causas distintas. Si un objeto cae corto, puede faltar velocidad, haberse liberado tarde o haberse estimado mal la distancia. Corregir siempre la misma variable puede empeorar el problema. La aportación de una herramienta de razonamiento se evalúa también por cómo identifica esa diferencia.

La documentación técnica de Google sitúa Argon en varios flujos de control y reconstrucción de entornos. Utiliza ejemplos con MuJoCo y describe ajustes de objetos, trayectorias y contacto para acercar la representación virtual a la escena real. [2]

Un simulador permite probar movimientos sin ejecutar cada intento en hardware. Su utilidad depende de que las variables que importan estén representadas: una trayectoria visualmente parecida puede fallar si el peso o el contacto difieren. El proceso debe cerrar el círculo con pruebas físicas para saber qué se ha transferido de verdad.

El alcance de la demostración

Google comunica siete aciertos consecutivos. La pieza publicada contiene cortes y no permite observar esa racha como una secuencia ininterrumpida. La cifra corresponde al resultado comunicado por la empresa. [1]

La distancia, el número total de intentos y las variaciones del entorno condicionan la interpretación. Una racha en unas condiciones concretas no determina el porcentaje de éxito en otra tarea o con otro objeto.

El blog técnico incluye también un caso con Spot y un cubo de basura de pedal. Es otra demostración, con otro cuerpo y otra tarea; ayuda a entender el enfoque, pero no sirve para atribuir a Apollo todas sus capacidades. [2]

Al comparar proyectos conviene fijar una unidad clara: plataforma física, tarea, entorno y forma de control. Hablar solamente del modelo de IA deja fuera las herramientas y condiciones que hacen posible el experimento. La transferencia entre robots no se puede dar por hecha por compartir un nombre de software.

El flujo reduce parte del trabajo manual que conecta una observación con un entorno de práctica. La reconstrucción permite ensayar movimientos antes de ejecutar cada intento físicamente.

El resultado sigue dependiendo del escenario, de la fidelidad de la simulación y de la preparación del hardware. La demostración no acredita aprendizaje instantáneo de cualquier habilidad ni autonomía doméstica general.

El anuncio general ofrece Argon por API en AI Studio y la plataforma de Gemini, y en productos con planes determinados. [1] Acceder al modelo no entrega por sí solo el robot, el entorno del experimento ni todos los componentes que hicieron posible la demostración.

Para repetir un caso de robótica hacen falta condiciones físicas y software compatibles, además de procedimientos del laboratorio. El interés de la noticia es mostrar trabajo que conecta esas capas. Su alcance no es prometer que cualquier usuario con una cuenta pueda enseñar cualquier habilidad a cualquier robot a partir de un vídeo.

Modelo de razonamiento, simulador, controlador y robot físico cumplen funciones diferentes. La disponibilidad de uno de ellos no significa que el conjunto se entregue como una solución lista para cualquier máquina. El interés del trabajo reside en cómo se enlazan esas capas para una tarea identificable, con condiciones que todavía importan al trasladarla a otro entorno.

Fuentes y documentación

  1. Google: anuncio de Gemini 4 Argon ↗
  2. Google Developers: Argon para robótica ↗
  3. Apptronik: Apollo ↗
  4. Vídeo del caso con Apollo ↗

El vídeo original de Google DeepMind / Apptronik

Original de Google DeepMind / Apptronik

Original de Google DeepMind / Apptronik. El reproductor conecta con YouTube al pulsar. Abrir en YouTube ↗