Ignoran la pausa y entran en zonas prohibidas: un estudio halla con agentes de IA 105 fallos desconocidos en autopilotos de drones PX4 y ArduPilot en simulador

Un sistema de agentes de IA ha encontrado 105 fallos lógicos desconocidos en PX4 y ArduPilot, dos autopilotos de drones de código abierto. El dato sale de un artículo subido a arXiv el 14 de octubre. No consta que haya pasado una revisión por pares.

Lo firman investigadores de la Universidad de Ciencia y Tecnología de Huazhong, en China, y de la Universidad de Illinois en Urbana-Champaign. Su herramienta se llama Impossible Mission Finder y trabajó en simulador.

De 428 sospechas a 105 fallos

Ziyi Liang, Zichuan Li, Bin Yuan, Deqing Zou y Luyi Xing arrancaron con 428 hipótesis. De ellas, 235 cayeron enseguida porque necesitaban cámaras, soportes o cabrestantes físicos.

Con las 193 restantes llegaron los ensayos. En el simulador, el propio sistema tiró 46. Dos expertos revisaron a mano otras 147, leyeron cada registro y eliminaron 40 más.

Tras fundir dos parejas de duplicados, salen las 105. La web del proyecto atribuye 63 a ArduPilot y 42 a PX4, descrito en su documentación como un autopiloto abierto para drones y vehículos autónomos.

Tres agentes y un simulador

A diferencia de un cuelgue, un fallo lógico deja el software en marcha. El programa decide mal, y los detectores clásicos de bloqueos no lo ven.

Los dos proyectos suman más de seis millones de líneas. Por eso el equipo preparó fragmentos que siguen cada orden de MAVLink, el protocolo que conecta el dron con su estación de control.

Con ese material, un agente basado en GPT-5.4 plantea la sospecha y otro escribe la prueba. Un tercero, con GPT-OSS-120B, lee el registro del vuelo simulado.

En un ensayo previo con cuatro modelos, cada uno con tres intentos, el contexto resultó decisivo. GPT-5.4 detectó un error de PX4 en sus tres intentos con el fragmento preparado, mientras que con los archivos completos ningún modelo lo encontró. También con IA se destaparon hace poco dos fallos críticos en PHP.

Cuando pausar no detiene el vuelo

Según los autores, uno de los casos afecta a PX4 durante una misión. Tras la orden de pausa, una parte del sistema anota el cambio, pero el navegador conserva el objetivo anterior. En su prueba en simulador, el aparato siguió hacia el siguiente punto.

Mientras tanto, la estación de control indica el modo de espera, como si todo fuera bien. «El cambio de modo por sí solo no daría al operador ningún indicio de que la pausa ha fallado», escriben los autores.

Los autores describen otros fallos de estados internos que no coinciden entre módulos, sin que el operador reciba un aviso claro.

Zonas prohibidas que dejan pasar

PX4 revisa la misión contra las zonas vetadas al cargarla. Según el artículo, no siempre repite el control si después se añade una zona nueva, y en simulador el dron puede entrar en ella.

Con el regreso automático al punto de partida pasa algo parecido: en un escenario de prueba, ese modo, según los investigadores, «puede guiar al dron directamente hacia un espacio aéreo restringido».

Según el artículo, entre dos zonas vetadas muy próximas la maniobra de recuperación puede dejar al aparato atrapado, y quizá haga falta que el operador tome el mando.

57 errores al validar órdenes

Más de la mitad de los hallazgos, según los autores, son órdenes que los programas aceptan sin comprobar bien sus valores, tanto en PX4 como en ArduPilot.

Hay otros 29 errores por estados internos que no coinciden y 11 incumplimientos de MAVLink. Las 8 salvaguardas que no se aplican completan la lista.

Según su web, ArduPilot funciona en más de un millón de vehículos, cifra del propio proyecto. Otros modelos ya compiten en pruebas de detección de fallos, y los drones autónomos ya inspeccionan galerías de agua en Madrid.

Vuelos reales, pendientes de probar

Según el artículo, los ensayos se hicieron en simulación. El artículo tampoco calcula la frecuencia de estos fallos en operaciones corrientes. Deja fuera, además, sensores, controladores de bajo nivel y suplantación de GPS.

Los autores admiten la dependencia de los modelos, aunque defienden que «la prueba final sigue saliendo de ensayos ejecutables y del comportamiento observado». En una prueba con 50 registros, su analizador cazó 19 de 25 anomalías y dio tres falsas alarmas.

A los operadores les interesa sobre todo una pregunta que sigue abierta. El texto no dice si PX4 y ArduPilot han corregido estos errores ni si recibieron aviso previo.

El estudio se ha publicado como preimpresión en arXiv.

Crédito de la imagen: Liang, Li, Yuan, Zou y Xing (proyecto Impossible Mission Finder).