Fotogrametría asistida por IA
Una de las temáticas más recurrentes en mi página es el uso de drones. Soy un aficionado al piloto de UAS desde hace ya años, y tengo la titulación de piloto de drones en categorías A1/A3. Es algo que hago por afición, pero que me tomo en serio. Ya casi desde el principio me interesó algo más que el simple hecho de volarlos para tomar vídeos e imágenes (prueba de ellos es mi canal de YouTube), y pronto la fotogrametría fue algo que despertó mi interés. En su momento fue algo sobre lo que ya escribí algunos artículos, pero en lo que tampoco pude avanzar demasiado, sobre todo por las limitaciones que tenía en lo relativo a la aplicación de captura de imágenes, y el entorno de procesado.
Pero ese interés era algo que seguía estando ahí. Así que, cuando hace algunos meses, empecé a interesarme por el desarrollo de aplicaciones asistido por IA, la fotogrametría fue algo que pronto escaló puestos en mi lista de iniciativas a desarrollar. El problema principal es que los pasos iniciales que di no eran muy compatibles con las necesidades de este proyecto: el desarrollo de aplicaciones en el que estaba trabajando -con tan buenos resultados en otros ámbitos- no estaba bien alineado con lo que se requería para esto. Y es que las aplicaciones apoyadas por IA que estaba desarrollando eran aplicaciones web, básicamente.
Este punto era bloqueante ya que, si bien existe un SDK documentado por DJI para el manejo de sus drones que permite el desarrollo de aplicaciones ajenas a las oficiales para interactuar con diversos modelos, el uso de este SDK requería el desarrollo de aplicaciones nativas para Android, algo que quedaba fuera del alcance de los motores de IA en los que me estaba basando. Aun así, empleé bastante tiempo en llegar a una solución mixta, con el desarrollo de una aplicación web apoyada en componentes nativos de Android, pero con resultados bastante pobres. Especialmente porque no tengo los conocimientos adecuados para el desarrollo de aplicaciones nativas en Kotlin o usando Android Suite.
Pero hace algunas semanas empecé a trabajar en una línea distinta, que me ha abierto las puertas a poder retomar este proyecto: el uso de Anthropic y Claude Code como elemento de desarrollo asistido por IA. El desarrollo con Claude Code es algo diferencial con respecto a otros entornos que estaba utilizando. Aunque sigues teniendo que estar muy encima para controlar lo que desarrolla la IA, das instrucciones muy claras de lo que estás buscando, y tener las capacidades adecuadas para validar que el resultado desarrollado se ajusta a las especificaciones que has definido, el salto es abismal. Sobre todo por el hecho de que también tiene capacidad para realizar despliegue y configuración de elementos de infraestructura. Y esto es algo que, en mi faceta de integrador de sistemas, es clave.
El caso es que, cuando confirmé que con Claude Code podía hacer desarrollo nativo de aplicaciones para Android, el desarrollar una aplicación que fuera capaz de definir las misiones en las que realizar vuelos para escanear el área sobre el que realizar la fotogrametría, tomar las imágenes conforme a las necesidades del vuelo se situaba en mis capacidades de desarrollo. Y así lo hice.
A diferencia de otras ocasiones anteriores en las que he utilizado Claude Code, en esta ocasión no desplegué un agent team, sino que realicé una aproximación de desarrollo con un único asistente de IA, ya que el objeto no era sólo desarrollar la aplicación, sino utilizarlo como guía de aprendizaje para el desarrollo de aplicaciones para Android. Y el caso es que esta aproximación funcionó estupendamente.
En primer lugar Claude realizó un análisis de en qué podía apoyar como asisntente de IA, y cuáles eran las principales dificultades del proyecto, que comparto por su interés:
En qué puede apoyar Claude Code
- Generar el scaffolding inicial del proyecto en Android Studio
- Explicar y escribir código Java/Kotlin paso a paso mientras aprendes
- Interpretar la documentación del DJI Mobile SDK (que es extensa y a veces confusa)
- Depurar errores de compilación y de conexión con el dron
- Sugerir arquitectura de la app (permisos, ciclo de vida, manejo de estados)
Los retos reales del proyecto
1. El DJI Mobile SDK tiene sus propias complejidades:
- Requiere registro de app y una App Key de DJI Developer
- El SDK v5 (el más reciente) cambió bastante respecto al v4
- La conexión física requiere testear en dispositivo real (no emulador)
2. Android desde cero implica aprender:
- Kotlin o Java como lenguaje
- Ciclo de vida de Activities/Fragments
- Manejo de permisos en tiempo de ejecución (GPS, cámara, Bluetooth, USB)
- Gradle y gestión de dependencias
3. El Mini 3 Pro tiene limitaciones en el SDK:
- No todas las funciones avanzadas están disponibles para todos los modelos
- Necesitarás el RC-N1 o el RC 2 conectado al teléfono vía USB o Wi-Fi
Las piezas clave del proyecto
🔴 El desafío central: el algoritmo de rejilla
El corazón de una app de fotogrametría es el planificador de líneas de vuelo. Dado un polígono en el mapa, tienes que calcular:
- Líneas paralelas separadas según el overlap lateral deseado (ej. 75%)
- Waypoints en cada línea con separación basada en overlap frontal y altura de vuelo
- GSD (Ground Sampling Distance) calculado según sensor del Mini 3 Pro y altura
- Orientación óptima del patrón según el polígono
Claude Code puede generar este algoritmo, pero necesitarás entender la geometría para validarlo.
🟠 El reto del DJI SDK v5
El Mini 3 Pro usa el SDK v5 de DJI, que es bastante diferente al v4. Puntos críticos:
- Las misiones de waypoints usan
WaypointMissionManagercon archivos KMZ - El trigger de cámara puede hacerse por tiempo o por distancia recorrida (mejor para fotogrametría)
- Requiere activación con App Key y el dron físico para pruebas reales
Un primer análisis muy acertado, pero que no se quedó ahí. Fue capaz de componer un plan de acción para desarrollar la aplicación, y asistirme para ponerlo en práctica. Plan que empezaba por desplegar Android Studio en el Mac Mini M4, y validar la instalación del entorno. Por suerte, ya había empezado a hacer en el pasado intentos en este sentido, y ya tenía el entorno desplegado. A partir de ahí, podíamos empezar. Propuso realizar un despliegue estructurado en fases.
Fase 1 – Aplicación mínima
- Mapa interactivo con tiles de OpenStreetMap vía MapLibre GL
- Dibujo de polígonos para definir el área de interés
- Configuración de parámetros de vuelo: altura, overlap frontal/lateral, velocidad, orientación de pasadas
- Selector 2D/3D: rejilla simple (ortomosaico) o doble rejilla cross-hatch (modelo 3D)
- Cálculo automático de GSD, grilla de waypoints, número de fotos, duración estimada y batería necesaria
- Preview visual de las líneas de vuelo sobre el mapa (actualización en tiempo real)
- Persistencia local: guardar, cargar y eliminar misiones con Room/SQLite
Fase 2 — Ejecución con el dron
- Integración con DJI Mobile SDK v5
- Conexión y estado del dron en tiempo real
- Upload de misión y ejecución automática
- Trigger de cámara por distancia
- Telemetría en vivo y vista FPV
- RTH automático ante baja batería
- Capas de mapa adicionales: ortofotos SIGPAC y mapas del Catastro de España (WMS/WMTS)
Fase 3 — Integración cloud
- Upload de imágenes a WebODM vía API REST
- Configuración del servidor WebODM
- Seguimiento del procesamiento
- Notificación de modelo listo
Mejoras futuras planificadas
Un plan bastante completo. Pero… ¿era realista? Bueno, creo que una imagen vale más que mil palabras:
En próximos artículos seguiremos hablando del proceso de desarrollo seguido, las dificultades encontradas, y cómo las resolví. Pero como adelanto dejo el resultado del procesado fotogramétrico de esta misión, en forma de representación 3D:
