{"id":11828,"date":"2026-05-10T21:54:41","date_gmt":"2026-05-10T19:54:41","guid":{"rendered":"https:\/\/bitacora.eniac2000.com\/?p=11828"},"modified":"2026-05-10T21:54:45","modified_gmt":"2026-05-10T19:54:45","slug":"aplicacion-android-para-fotogrametria-con-ia-fase-9-deteccion-inteligente-de-objetos-a-dos-niveles-dispositivo-y-servidor","status":"publish","type":"post","link":"https:\/\/bitacora.eniac2000.com\/?p=11828","title":{"rendered":"Aplicaci\u00f3n Android para fotogrametr\u00eda con IA. Fase 9: Detecci\u00f3n inteligente de objetos a dos niveles, dispositivo y servidor"},"content":{"rendered":"
Esta entrada es la parte 12 de 12 de la serie Fotogrametr\u00eda asistida por IA<\/a><\/div>\n

La Fase 8<\/a> dej\u00f3 cerrado el panel de condiciones de vuelo: meteorolog\u00eda de AEMET, \u00edndice geomagn\u00e9tico Kp de la NOAA y monitorizaci\u00f3n GPS en tiempo real. Con toda esa informaci\u00f3n, el piloto sabe si es buen momento para volar. Pero una vez en el aire, \u00bfqu\u00e9 ve el dron? Hasta ahora, la \u00fanica respuesta llegaba con retraso: el m\u00f3dulo de auditor\u00eda del servidor procesaba el stream<\/em> RTMP con un YOLOv8n gen\u00e9rico y, francamente, los resultados dejaban bastante que desear: en un vuelo de validaci\u00f3n del proceso de cuatro minutos se realizaron 105 detecciones, la mayor\u00eda falsos positivos. La Fase 9 nace para resolver exactamente eso: darle ojos inteligentes al sistema, tanto en el aire como en tierra.<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n de lo desarrollado en Fase 9. Generada por IA<\/figcaption><\/figure>\n\n\n\n

La idea inicial: Roboflow<\/h2>\n\n\n\n

Mi primera intuici\u00f3n fue hacer uso de Roboflow. Pod\u00eda desplegar un MCP integrado en Claude Code para tener este entorno habilitado en el flujo de desarrollo asistido por IA, y la plataforma promete un pipeline completo: anotaci\u00f3n, entrenamiento y despliegue. Pero creo que es conveniente dar un peque\u00f1o paso atr\u00e1s, y explicar lo que es un MCP.<\/p>\n\n\n\n

Un MCP, o Model Context Protocol, es un modelo de integraci\u00f3n que permite que un agente de inteligencia artificial, como Claude Code, se conecte con herramientas externas para interactuar directamente con ellas, dentro de su propio flujo de trabajo, sin necesitar interacciones manuales entre distintos sistemas por parte del usuario, lo que incrementa de manera dram\u00e1tica las capacidades del agente de IA, ya que no s\u00f3lo puede pedir<\/em> al usuario que haga tal o cual tarea en el sistema externo, sino que puede usarlo directamente, e incluso evaluar el resultado de esa interacci\u00f3n. Sencillamente soberbio. Sus principales ventajas son las siguientes:<\/p>\n\n\n\n

    \n
  • Interoperabilidad Total<\/strong>: Las integraciones eran silos cerrados para pasar a ser esquemas interoperables. Un servidor MCP escrito para una base de datos de Postgres funciona igual de bien en Claude Desktop<\/strong>, en Claude Code<\/strong> o en cualquier otro IDE que adopte el est\u00e1ndar. No hay que reinventar la rueda.<\/li>\n\n\n\n
  • Contexto en Tiempo Real<\/strong>: En lugar de copiar y pegar logs o fragmentos de c\u00f3digo, el MCP permite que la IA \u00abpregunte\u00bb a la fuente de verdad en el momento exacto. Si el estado de un servidor cambia, Claude lo sabe porque tiene un canal directo de comunicaci\u00f3n.<\/li>\n\n\n\n
  • Seguridad y Control Local<\/strong>: <\/li>\n\n\n\n
  • A diferencia de otras soluciones que requieren subir todos tus datos a la nube para que la IA los procese, los servidores MCP<\/strong> pueden ejecutarse localmente en tu m\u00e1quina. T\u00fa decides qu\u00e9 archivos o qu\u00e9 datos espec\u00edficos permites que el modelo consulte, manteniendo la privacidad de la informaci\u00f3n sensible.<\/li>\n<\/ul>\n\n\n\n
    \"\"
    Uso de servidores MCP para extender las capacidades d Claude Code. Generada por IA<\/figcaption><\/figure>\n\n\n\n

    Volviendo a la mesa de dibujo, como dec\u00eda, le ped\u00ed a Claude que evaluara la propuesta y, adicionalmente, inclu\u00ed en el proceso de evaluaci\u00f3n de la misma una validaci\u00f3n del dise\u00f1o preliminar contra ChatGPT, que precisamente tengo configurado como m\u00f3dulo de consulta desde Claude Code a trav\u00e9s de su propio MCP. La raz\u00f3n de esto es poderlo utilizar como un \u00abasesor externo\u00bb a Claude Code. Y en este caso, le ped\u00ed que hiciera la funci\u00f3n de abogado del diablo.<\/em><\/p>\n\n\n\n

    El veredicto fue demoledor. Con el plan gratuito de Roboflow, la exportaci\u00f3n a TFLite est\u00e1 bloqueada, los datos deben ser p\u00fablicos, y las limitaciones de inferencia lo hacen inviable para un proyecto que aspira a funcionar en una combinaci\u00f3n de procesamiento offline<\/em> y en el propio dispositivo Android. ChatGPT, en su rol de adversario de razonamiento, identific\u00f3 adem\u00e1s que el acoplamiento a una plataforma comercial no ten\u00eda sentido para un proyecto personal sin \u00e1nimo de lucro inmediato. Punto para el abogado del diablo.<\/p>\n\n\n\n

    La alternativa: Ultralytics a coste cero<\/h2>\n\n\n\n

    El plan B fue hacer uso, directamente, de Ultralytics. Las razones para ello eran de peso. En primer lugar, la licencia AGPL-3.0 lo hacen perfectamente v\u00e1lida para uso personal. En segundo lugar, el poder emplear YOLOv8n como arquitectura, en su configuraci\u00f3n nano, de 6 MB, funciona perfectamente en CPU frente a GPU. Tercero, hace posible utilizar VisDrone como dataset<\/em> de entrenamiento (se trata de 10.000 im\u00e1genes a\u00e9reas capturadas con drones DJI, lo que es exactamente mi dominio). Cuarto, la posibilidad de hacer entrenamiento gratuito en Google Colab o Kaggle con GPU T4. Y por \u00faltimo, la posibilidad de realizar exportaci\u00f3n a todos los formatos que necesitaba: PyTorch para el servidor, TFLite INT8 para Android. Y todo ello a coste cero. Una aproximaci\u00f3n muy completa para resolver el escenario que ten\u00eda encima de la mesa.<\/p>\n\n\n\n

    \"\"
    El plan B en toda su gloria. Generada por IA<\/figcaption><\/figure>\n\n\n\n

    Aun as\u00ed, antes de decidir, le ped\u00ed a Claude que usara el MCP de NotebookLM para hacer una investigaci\u00f3n profunda sobre la viabilidad de usar Ultralytics en mi hardware<\/em> (recordemos, un servidor HPE ProLiant DL360p Gen8 con Xeon E5 y 96 GB de RAM, pero sin GPU). La conclusi\u00f3n fue clara: para realizar inferencia en CPU sobre im\u00e1genes est\u00e1ticas de alta resoluci\u00f3n, el rendimiento era m\u00e1s que suficiente aplicando SAHI (Slicing Aided Hyper Inference) para dividir cada foto en mosaicos de 640×640. Ya s\u00f3lo era cuesti\u00f3n de ponerse a ello, para lo que estructur\u00e9 el proceso en cuatro pasos bien diferenciados.<\/p>\n\n\n\n

    Primer paso. Entrenamiento del modelo<\/h2>\n\n\n\n

    La primera tarea fue entrenar un YOLOv8n especializado en vista a\u00e9rea. El servidor ODM ya ten\u00eda un script<\/em> de entrenamiento (train_visdrone.py<\/code>) preparado desde la Fase 5, pero hab\u00eda fallado al intentar ejecutarlo en CPU. Tras varios intentos fallidos hab\u00eda acabado generando un core dump<\/em> de 500 MB que confirmaba que entrenar en el Xeon no era viable.<\/p>\n\n\n\n

    Instal\u00e9 el MCP oficial de Google Colab (googlecolab\/colab-mcp<\/code>) en el Mac Mini para controlar el notebook<\/em> directamente desde Claude Code. La idea era elegante: crear celdas, ejecutarlas, leer resultados, todo sin salir del terminal. La realidad fue menos elegante.<\/p>\n\n\n\n

    Google Colab<\/strong> (o Colaboratory) es una plataforma gratuita basada en la nube que permite escribir y ejecutar c\u00f3digo de Python<\/strong> directamente desde tu navegador, sin necesidad de realizar configuraciones previas en tu ordenador. Funciona bajo un sistema de \u00abnotebooks\u00bb (cuadernos interactivos) inspirados en Jupyter, donde puedes combinar texto enriquecido, ecuaciones matem\u00e1ticas y c\u00f3digo ejecutable, todo almacenado de forma autom\u00e1tica en tu cuenta de Google Drive<\/strong>.<\/p>\n\n\n\n

    Lo que realmente lo distingue es el acceso gratuito a recursos de computaci\u00f3n de alto rendimiento, espec\u00edficamente GPUs y TPUs<\/strong>. Esto lo convierte en la herramienta muy valiosa para estudiantes, investigadores y desarrolladores de Inteligencia Artificial<\/strong> y Ciencia de Datos, ya que permite entrenar modelos complejos o procesar grandes vol\u00famenes de informaci\u00f3n de manera r\u00e1pida y colaborativa, tal como si estuvieras trabajando en un documento compartido de Google Docs. Sobre el papel era perfecto para esta fase de entrenamiento del modelo.<\/p>\n\n\n\n

    El primer intento lleg\u00f3 hasta la epoch<\/em> 36 de 100 antes de que un MCP timeout <\/em>cortara la conexi\u00f3n. Los checkpoints<\/em> no se hab\u00edan guardado porque el directorio de salida no estaba bien configurado. Al reintentar, el kernel de Colab se hab\u00eda reiniciado, perdiendo las dependencias instaladas y el dataset descargado. Vuelta a empezar.<\/p>\n\n\n\n

    El segundo intento a\u00f1ad\u00eda save_period=5<\/code> para guardar checkpoints<\/em> cada 5 epochs<\/em>. Lleg\u00f3 hasta la epoch<\/em> 79 de 100 cuando Colab cort\u00f3 la sesi\u00f3n por l\u00edmite de uso de GPU gratuita. Y como los checkpoints<\/em> estaban en almacenamiento ef\u00edmero de Colab… se perdieron otra vez. Adem\u00e1s, el MCP de Colab ten\u00eda un problema fundamental: update_cell<\/code> reportaba \u00e9xito pero run_code_cell<\/code> ejecutaba el contenido anterior de la celda. Las actualizaciones no sincronizaban con el runtime. Entre unas cosas y otras, fueron 6 horas de tiempo perdido.<\/p>\n\n\n\n

    El salto a Kaggle<\/h3>\n\n\n\n

    Ya hab\u00eda identificado Kaggle como plataforma alternativa, y que aportaba las siguientes caracter\u00edsticas: 30 horas semanales de GPU (m\u00e1s generoso que Colab), sesiones de hasta 12 horas, y \/kaggle\/working\/<\/code> que persiste autom\u00e1ticamente tras finalizar la sesi\u00f3n. No hay MCP, pero a estas alturas eso era casi una ventaja, as\u00ed que prepar\u00e9 un script completo en 6 celdas que el usuario ejecuta directamente en el navegador.<\/p>\n\n\n\n

    El primer obst\u00e1culo en Kaggle fue la existencia de un bug<\/em> de la versi\u00f3n preinstalada de PyTorch (THPDtypeType.tp_dict == nullptr<\/code>) que dio la cara al intentar ejecutar la primera de las celdas. Se resolvi\u00f3 instalando Ultralytics antes de importar torch, que trae su propia versi\u00f3n compatible. A partir de ah\u00ed, todo fue fluido: el entrenamiento complet\u00f3 80 epochs en 2 horas y 7 minutos a 5.6 iteraciones por segundo.<\/p>\n\n\n\n

    Los resultados finales del entrenamiento fueron los siguientes:<\/p>\n\n\n\n

    Clase<\/th>mAP@0.5<\/th><\/tr><\/thead>
    car<\/td>0.681<\/td><\/tr>
    bus<\/td>0.321<\/td><\/tr>
    van<\/td>0.254<\/td><\/tr>
    pedestrian<\/td>0.249<\/td><\/tr>
    motor<\/td>0.249<\/td><\/tr>
    Global<\/strong><\/td>0.236<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    El mAP global queda ligeramente por debajo del umbral de 0.25 que nos hab\u00edamos marcado, pero las clases relevantes para fotogrametr\u00eda (coches, veh\u00edculos, peatones) tienen valores m\u00e1s que aceptables. Las clases que bajan la media \u2014 bicycle (0.029) y awning-tricycle (0.063) \u2014 son objetos muy peque\u00f1os y poco frecuentes que no son prioritarios para nuestro caso de uso.<\/p>\n\n\n\n

    Despliegue y comparativa con el modelo gen\u00e9rico<\/h3>\n\n\n\n

    Con los modelos exportados (PyTorch de 5.9 MB y TFLite INT8 de 11.6 MB), el despliegue en el servidor fue directo: copiar el .pt<\/code> a \/odm-data\/models\/<\/code>, actualizar la variable YOLO_MODEL<\/code> en el docker-compose, y reiniciar el ai-processor.<\/p>\n\n\n\n

    La prueba de fuego fue volver a analizar el v\u00eddeo del vuelo real del 11 de abril con el nuevo modelo. El resultado fue contundente:<\/p>\n\n\n\n

    Modelo<\/th>Detecciones<\/th>Observaci\u00f3n<\/th><\/tr><\/thead>
    YOLOv8n gen\u00e9rico<\/td>105<\/td>Mayor\u00eda falsos positivos<\/td><\/tr>
    YOLOv8n VisDrone<\/td>9<\/td>5 peatones, 2 camiones, 2 autobuses<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    De las 9 detecciones, la validaci\u00f3n visual en el visor Leaflet confirm\u00f3 que las 5 detecciones de peat\u00f3n eran correctas (era yo, al inicio del vuelo), aunque aparec\u00edan duplicadas por detecci\u00f3n en frames consecutivos. Un cami\u00f3n era un falso positivo, y dos detecciones de baja confianza (bus\/peat\u00f3n al 41%) correspond\u00edan en realidad a un \u00e1rbol. Con tan s\u00f3lo subir el umbral de confianza de 0.35 a 0.50, los falsos positivos desaparecieron y quedaron solo las detecciones v\u00e1lidas. Nada mal para una primera iteraci\u00f3n, aunque a\u00fan espero mejorar mucho el proceso.<\/p>\n\n\n\n

    Segundo paso. Detecci\u00f3n en tiempo real en el m\u00f3vil<\/h2>\n\n\n\n

    La segunda capa de detecci\u00f3n se realiza en el dispositivo de captura: consiste en el mismo modelo YOLOv8n, pero cuantizado a TFLite INT8 y ejecut\u00e1ndose directamente en el tel\u00e9fono durante el vuelo. Se trata de una duramente informativa: no controla el dron, s\u00f3lo muestra al operador lo que el modelo ve.<\/p>\n\n\n\n

    La implementaci\u00f3n requiri\u00f3 cuatro ficheros nuevos y tres modificados. El ObjectDetector<\/code> carga el modelo desde assets<\/em>, ejecuta inferencia y aplica NMS (Non-Maximum Suppression). El DetectionOverlay<\/code> dibuja bounding boxes<\/em> de colores sobre el v\u00eddeo FPV con etiquetas de clase y confianza. Un bot\u00f3n de ojo en la esquina permite activar o desactivar la detecci\u00f3n, y un badge<\/em> muestra el n\u00famero de objetos detectados y los FPS de inferencia.<\/p>\n\n\n\n

    \"\"
    Implementaci\u00f3n de la captura en tiempo real. Generada por IA<\/figcaption><\/figure>\n\n\n\n

    El primer intento de integraci\u00f3n provoc\u00f3 un fallo en la aplicaci\u00f3n al entrar en la pantalla de vuelo. El culpable: el GPU Delegate de TensorFlow Lite lanzaba un NoClassDefFoundError<\/code> en el Moto G73, que es un Error<\/code> de la JVM, no una Exception<\/code>. Mi recolector de eventos no lo pillaba. Qued\u00f3 corregido con catch (e: Throwable)<\/code>, con lo que detector cae elegantemente a CPU.<\/p>\n\n\n\n

    El segundo problema fue m\u00e1s sutil: las cajas de detecci\u00f3n aparec\u00edan en la esquina superior izquierda, diminutas y lejos del objeto. El modelo TFLite INT8 devuelve coordenadas ya normalizadas (rango 0-1), pero mi c\u00f3digo las divid\u00eda otra vez por el tama\u00f1o de entrada (416), aplast\u00e1ndolas a valores microsc\u00f3picos. Una vez eliminada la doble normalizaci\u00f3n, las cajas se posicionaron correctamente sobre los objetos detectados.<\/p>\n\n\n\n

    La validaci\u00f3n final: con la aplicaci\u00f3n instalada en el Moto G73 y el dron conectado, activ\u00e9 la detecci\u00f3n y me puse delante de la c\u00e1mara. El overlay mostr\u00f3 \u00abpedestrian 61%\u00bb con una caja correctamente posicionada alrededor de mi cara, a 3-4 FPS en CPU. No es espectacular, pero es suficiente para alertar al operador de la presencia de personas u objetos durante el vuelo.<\/p>\n\n\n\n

    Tercer paso. An\u00e1lisis batch de fotos en el servidor<\/h2>\n\n\n\n

    La tercera pieza del puzzle es un contenedor separado, photo-analyzer<\/code>, que analiza las fotos de alta resoluci\u00f3n (12-48 MP) descargadas del dron despu\u00e9s del vuelo. A diferencia del stream<\/em> RTMP a 720p que procesa el ai-processor en tiempo real, aqu\u00ed se trabaja con las fotos completas que se usan para la ortofotograf\u00eda.<\/p>\n\n\n\n

    La clave t\u00e9cnica es SAHI: cada foto se divide en mosaicos de 640×640 con un 25% de solapamiento, se ejecuta la inferencia sobre cada mosaico, y despu\u00e9s se reensamblan las detecciones eliminando duplicados en las zonas de solapamiento. Esto permite detectar objetos peque\u00f1os que se perder\u00edan al redimensionar una foto de 48 MP a 640×640 directamente.<\/p>\n\n\n\n

    \"Visor
    Visor de hallazgos con las capas de detecci\u00f3n<\/figcaption><\/figure>\n\n\n\n

    El photo-analyzer expone una API FastAPI en el puerto 8003, y audit-api act\u00faa como proxy con un endpoint POST \/audit\/flights\/{id}\/analyze-photos<\/code> que encola el trabajo. Las detecciones se almacenan en una nueva tabla PostGIS (photo_detections<\/code>) con geometr\u00eda georreferenciada extra\u00edda del EXIF GPS de cada foto, y se exponen como GeoJSON en una capa separada del visor Leaflet.<\/p>\n\n\n\n

    Cuarto paso. Preparaci\u00f3n para fine-tuning continuo<\/h2>\n\n\n\n

    El modelo VisDrone es un buen punto de partida, pero su dominio consiste en escenas urbanas densas. Si alg\u00fan d\u00eda necesito detectar objetos espec\u00edficos de mi caso de uso (tejados da\u00f1ados, paneles solares, infraestructuras agr\u00edcolas) necesitar\u00e9 ajuste fino con datos propios. Esta wave<\/em> prepara la infraestructura de versionado de modelos: una tabla en PostGIS que registra cada versi\u00f3n con su SHA256, fecha de entrenamiento, dataset, n\u00famero de epochs y mAP de validaci\u00f3n.<\/p>\n\n\n\n

    El flujo iterativo queda documentado: volar, revisar detecciones, anotar 200-500 fotos en Roboflow (aqu\u00ed s\u00ed es \u00fatil como herramienta de anotaci\u00f3n gratuita) o CVAT, fine-tune en Kaggle partiendo del modelo VisDrone como transfer learning<\/em>, validar, exportar a ambos formatos, desplegar y comparar. Todo el pipeline<\/em> a coste cero.<\/p>\n\n\n\n

    El papel de los asistentes IA en la toma de decisiones<\/h2>\n\n\n\n

    Un aspecto que merece menci\u00f3n aparte es c\u00f3mo he usado la orquestaci\u00f3n de m\u00faltiples asistentes IA para tomar decisiones informadas, precisamente gracias a la integraci\u00f3n que explicaba al inicio mediante MCPs. Claude Code sigue siendo el agente principal de desarrollo, pero en esta fase se ha apoyado en agentes de IA adicionales, mediante sendos MCPs espec\u00edficos:<\/p>\n\n\n\n