{"id":11878,"date":"2026-06-10T23:26:34","date_gmt":"2026-06-10T21:26:34","guid":{"rendered":"https:\/\/bitacora.eniac2000.com\/?p=11878"},"modified":"2026-06-10T23:26:37","modified_gmt":"2026-06-10T21:26:37","slug":"fotogrametria-asistida-con-ia-pruebas-de-campo-cuando-el-firmware-no-hace-lo-que-promete","status":"publish","type":"post","link":"https:\/\/bitacora.eniac2000.com\/?p=11878","title":{"rendered":"Fotogrametr\u00eda asistida con IA: Pruebas de campo. Cuando el firmware no hace lo que promete"},"content":{"rendered":"
Esta entrada es la parte 13 de 13 de la serie Fotogrametr\u00eda asistida por IA<\/a><\/div>\n
\"\"
Reconstrucci\u00f3n fotogram\u00e9trica en 3D de una zona residencial. Jardines y h\u00f3rreos<\/figcaption><\/figure>\n\n\n\n

La Fase 9<\/a> dej\u00f3 el sistema completo sobre el papel: planificaci\u00f3n, vuelo aut\u00f3nomo, detecci\u00f3n de objetos a dos niveles y procesamiento fotogram\u00e9trico en el servidor. Pero entre un sistema completo sobre el papel y uno en el que conf\u00edas cuando el dron est\u00e1 a 40 metros de altura hay una distancia considerable, y este art\u00edculo va exactamente de recorrerla. Lo que viene a continuaci\u00f3n es la cr\u00f3nica de una serie de pruebas que incluyen vuelos de producci\u00f3n, una revisi\u00f3n de c\u00f3digo que destap\u00f3 un problema serio de seguridad, el dise\u00f1o de un sistema de recuperaci\u00f3n ante fallos, y dos sesiones de pruebas de campo con catorce vuelos que demostraron algo que ya sospechaba: el firmware<\/em> de DJI tiene opiniones propias, y no siempre coinciden con la documentaci\u00f3n.<\/p>\n\n\n\n

Los primeros vuelos de producci\u00f3n: el gimbal<\/em> que ignoraba las fachadas<\/h2>\n\n\n\n
\"\"
El problema de las fachadas transparentes<\/figcaption><\/figure>\n\n\n\n

A principios de junio hice las dos primeras misiones reales con intenci\u00f3n de producir resultados, y no de simplemente probar la aplicaci\u00f3n: fotogrametr\u00eda de dos viviendas y sus respectivas parcelas en la zona de Pontevedra. La primera dej\u00f3 una lecci\u00f3n inmediata: para las misiones de modelo 3D, la aplicaci\u00f3n calculaba un \u00e1ngulo de gimbal de -73,5 grados \u2014 casi cenital. El resultado en OpenDroneMap fue revelador: los edificios sal\u00edan planos, como mont\u00edculos sin fachadas. La c\u00e1mara nunca llegaba a verlas. La correcci\u00f3n fue hacer el \u00e1ngulo dependiente de la altitud, interpolando entre -50 grados a baja altura (fachadas cercanas, hace falta mucha inclinaci\u00f3n) y -65 a gran altura (cobertura amplia sin desperdiciar imagen en el horizonte).<\/p>\n\n\n\n

\"\"
Una mejora evidente en la representaci\u00f3n de las fachadas<\/figcaption><\/figure>\n\n\n\n

Con el gimbal<\/em> corregido, la siguiente misi\u00f3n fue otra historia: 186 waypoints a 20 metros, 173 fotos, y un resultado de ODM que no esperaba tan pronto \u2014 el 100% de las im\u00e1genes reconstruidas, una nube densa de 25,9 millones de puntos, GSD de 0,8 cm\/p\u00edxel y un error 3D relativo de 8 cent\u00edmetros. Los tejados se distinguen teja a teja.<\/p>\n\n\n\n

\"\"
Un buen nivel de detalle del tejado<\/figcaption><\/figure>\n\n\n\n

Los vuelos reales tambi\u00e9n sirvieron para calibrar la estimaci\u00f3n de bater\u00eda, que ven\u00eda siendo optimista. La especificaci\u00f3n del Mini 3 Pro promete 34 minutos de vuelo (un consumo te\u00f3rico del 2,94% por minuto), pero la realidad, medida en tres vuelos, fue un 4% por minuto clavado. El factor de correcci\u00f3n de la f\u00f3rmula que calcula la cantidad de bater\u00eda necesaria por misi\u00f3n pas\u00f3 de 1,15 a 1,45, y desde entonces la estimaci\u00f3n acierta.<\/p>\n\n\n\n

Una revisi\u00f3n de c\u00f3digo con ojos nuevos<\/h2>\n\n\n\n

Con el sistema ya volando misiones reales, le ped\u00ed a Claude una revisi\u00f3n completa del c\u00f3digo y la documentaci\u00f3n: calidad, bugs, mejoras y deuda pendiente, usando para ello el reci\u00e9n estrenado modelo de IA Claude Fable (del que hablaremos m\u00e1s adelante). El veredicto general fue amable (la arquitectura aguanta bien), pero la lista de hallazgos inclu\u00eda uno que me quit\u00f3 la tranquilidad de golpe.<\/p>\n\n\n\n

\"\"
Problem\u00e1ticas encontradas. Generado con IA<\/figcaption><\/figure>\n\n\n\n

El Mini 3 Pro no soporta misiones onboard<\/em>, as\u00ed que toda la navegaci\u00f3n va por Virtual Stick: la app env\u00eda comandos de velocidad veinte veces por segundo, simulando los controles del mando. El detalle cr\u00edtico es que, mientras Virtual Stick est\u00e1 activo, la autoridad de control la tiene la app y los sticks f\u00edsicos del mando no responden<\/strong>. \u00bfY qu\u00e9 pasaba si la misi\u00f3n lanzaba una excepci\u00f3n en pleno vuelo, como un timeout<\/em> de GPS, por ejemplo? Pues que el c\u00f3digo capturaba el error, pintaba \u00abERROR\u00bb en la pantalla\u2026 y nada m\u00e1s. El dron se quedaba flotando con el control autom\u00e1tico activo, los sticks bloqueados, y sin que la app hiciera absolutamente nada por recuperarlo.<\/p>\n\n\n\n

Hab\u00eda m\u00e1s: los bucles de navegaci\u00f3n no ten\u00edan vigilancia de progreso (si el viento superaba la velocidad de crucero, la app insistir\u00eda contra el viento para siempre), el monitor de bater\u00eda arrancaba tarde, una tabla de la base de datos crec\u00eda sin purgarse jam\u00e1s, y ni un solo test en todo el proyecto. Pero el agujero de la recuperaci\u00f3n era el que importaba.<\/p>\n\n\n\n

Dise\u00f1ando la recuperaci\u00f3n: el matiz que lo cambia todo<\/h2>\n\n\n\n

Mi primera intuici\u00f3n fue implementar que, si algo falla, el dron ha de quedar en modo sobrevuelo con el Virtual Stick activo para que yo pueda hacer maniobras de emergencia con el mando. Claude me corrigi\u00f3 el modelo mental, y menos mal: es exactamente al rev\u00e9s. Virtual Stick activo significa mandos bloqueados. Si quieres devolverle el control al piloto, lo que hay que hacer es desactivar<\/em> Virtual Stick. De esa conversaci\u00f3n sali\u00f3 el dise\u00f1o definitivo:<\/p>\n\n\n\n