Gemini Robotics 2.5 ayudó a Apollo 2 a clasificar piezas de Mercedes con un 96% de éxito

En una zona de montaje hay que sacar un soporte de un montón de piezas mezcladas y colocarlo en el compartimento correcto de una bandeja. Para una persona es una tarea rutinaria. Para un robot, cada cambio de orientación de la pieza modifica las condiciones de agarre. Esa es precisamente la operación que DeepMind probó con Apollo 2 en fábricas de Mercedes-Benz: la empresa comunica un 96% de ejecuciones satisfactorias. Los desarrolladores de automatización tienen aquí algo que estudiar, y los responsables de producto, cuentas que hacer antes de poner en marcha su propia prueba piloto.

Cómo una instrucción se convierte en movimiento

Gemini Robotics 2.5 pertenece a la familia de modelos VLA, que relacionan imágenes, instrucciones en lenguaje natural y acciones físicas. Un ejemplo sencillo: el robot recibe la tarea de ordenar piezas, observa el contenido de una caja a través de las cámaras y controla la pinza en función de la escena que tiene delante. En la página del modelo, Google ofrece inscribirse en una lista de espera para obtener acceso anticipado.

En la prueba en fábrica se repartieron las funciones. Gemini Robotics ER supervisaba el avance del trabajo, mientras Robotics 2.5 controlaba los brazos de Apollo 2. El robot trasladaba soportes metálicos desde cajas con piezas a granel a contenedores, preparando las piezas en el orden de montaje. Las pruebas se realizaron en Kecskemet y Sindelfingen. DeepMind las describe expresamente como una prueba de concepto. Los detalles están publicados en el anuncio de la empresa.

Para un ingeniero, esta división resulta útil al analizar fallos. Si una pieza incorrecta acaba en la bandeja, hay que averiguar dónde se produjo el error: si el sistema interpretó mal el siguiente paso, eligió el objeto equivocado o no logró sujetarlo. Son problemas distintos, y un registro con una única entrada de «operación fallida» aporta poco a la depuración.

En un prototipo propio conviene guardar de forma vinculada la tarea, la imagen anterior al agarre, la acción seleccionada y el resultado de la comprobación. Así se pueden identificar los errores recurrentes y decidir qué modificar: la ubicación de la cámara, la pinza, el suministro de piezas o la lógica de la tarea. Esta es una recomendación práctica para diseñar el sistema, no una descripción de la implementación publicada por Google.

Qué significa el resultado del 96%

Supongamos que su operación también alcanza un 96% de éxito. Por cada cien intentos quedan aproximadamente cuatro fallidos. Pero una misma tasa de error puede suponer cargas muy distintas para la producción. En un caso, el robot simplemente repite el agarre. En otro, deja caer una pieza, prepara un conjunto incorrecto o exige detener la zona de trabajo.

Por eso, la cifra por sí sola no permite determinar si la inversión será rentable. El equipo necesita conocer el tiempo del ciclo completo, la frecuencia con la que se solicita al operario, el tiempo de recuperación y las consecuencias de un error no detectado. Es especialmente útil contabilizar por separado los intentos completados sin ayuda humana: de lo contrario, las correcciones manuales pueden quedar ocultas en un promedio atractivo.

La evaluación debe realizarse con las piezas y las condiciones de la futura zona de trabajo. Por ejemplo, conviene incluir desde el principio una caja casi vacía, piezas superpuestas y un soporte en una posición difícil. La lista debe reflejar las causas reales de las paradas. De otro modo, la prueba piloto solo confirmará que el robot funciona bien en una escena preparada para él.

Por dónde empezar una prueba piloto propia

El primer paso es elegir una operación repetitiva con un criterio de éxito claro. Para la preparación de conjuntos de piezas, podría ser colocar la pieza correcta en el compartimento correcto dentro del tiempo permitido. Antes de las pruebas, hay que definir quién valida el resultado y qué sucede en caso de duda: repetir el intento, omitirlo o solicitar ayuda humana.

Después conviene comparar varias formas de realizar esa operación, incluida la posibilidad de cambiar el suministro de piezas. A veces, una bandeja adecuada o un utillaje sencillo ofrecen un resultado económico más favorable que complicar el control. Tiene sentido evaluar el modelo dentro del sistema de trabajo completo, junto con los equipos, el control de calidad y el mantenimiento.

El anuncio de DeepMind ofrece un motivo concreto para realizar este experimento. La decisión de compra debe basarse en mediciones de la propia zona de trabajo. Si el robot mantiene el ritmo necesario, los errores se detectan y la recuperación tiene un coste aceptable, habrá una base concreta para hablar de implantación. Hasta entonces, el 96% sigue siendo el resultado de una prueba piloto ajena: una referencia útil para poner a prueba su hipótesis.