Ciencia

El simulador, no el robot: el fallo oculto que infla las notas de la IA robótica

¿Y si parte de los suspensos que le ponemos a un robot en un examen virtual no fueran culpa suya, sino del propio examinador?

·

¿Y si parte de los suspensos que le ponemos a un robot en un examen virtual no fueran culpa suya, sino del propio examinador? ¿Y si parte de los suspensos que le ponemos a un robot en un examen virtual no fueran culpa suya, sino del propio examinador? Un equipo de la Universidad de Tsinghua ha encontrado que en varias pruebas de referencia para robots, el motor físico que simula el mundo comete un error de bulto: declara que dos piezas de un objeto están incrustadas cuando en realidad están separadas por uno o dos centímetros, y entonces las expulsa a toda velocidad.

En un caso documentado, una lata de 10 gramos colocada dentro de una cesta sale despedida a 22 metros por segundo en un solo paso de simulación de 4 milisegundos, sin que ningún brazo robótico la toque. La causa es una sola constante en el algoritmo de detección de colisiones de PhysX 5.3.1, que descarta triángulos demasiado pequeños y deja de calcular bien la distancia entre piezas cuando estas miden centímetros. Al corregir ese valor, los episodios con este artefacto pasaron de 12 a 0 por cada 100, y la tasa de éxito de un modelo en cinco tareas subió del 89% al 98%.

Esto importa porque las puntuaciones de los benchmarks son el termómetro con el que se decide qué IA robótica funciona, y ahora sabemos que parte del ruido no viene del robot sino de la física mal calculada. Es como si un examen de tiro al blanco te suspendiera porque la diana se mueve sola. Los autores proponen una herramienta, SimuGuard, que audita cada paso sin alterar la evaluación y permite repetir el episodio bit a bit para verificar el fallo.

Cautela: es un preprint, la medición en el motor reparado cubre solo dos modelos y cinco tareas, y la diferencia de éxito en las semillas compartidas no es estadísticamente significativa por sí sola. Nota: Preprint no revisado por pares. El arreglo se probó cambiando una constante dentro de PhysX 5.3.1, no ejecutando RoboTwin sobre una versión posterior completa. La medición en el motor reparado abarca dos políticas y cinco tareas con 20 semillas cada una, y la mejora de éxito en las 83 semillas compartidas no alcanza significación por sí sola (p=0,11), aunque la desaparición de los artefactos sí es clara. La causa del fallo en RoboDojo no se localizó y los benchmarks sobre MuJoCo se auditaron a menor escala. Paper: When the Simulator Fails, Not the Policy: Auditing Contact Artifacts in Simulated Robot Benchmarks Enlace: https://arxiv.org/abs/2610.41857 PDF: https://arxiv.org/pdf/2610.41857v1

Con información de SECIHTI · Fuente oficial