{"id":11708,"date":"2026-04-01T23:56:14","date_gmt":"2026-04-01T21:56:14","guid":{"rendered":"https:\/\/bitacora.eniac2000.com\/?p=11708"},"modified":"2026-04-01T23:56:16","modified_gmt":"2026-04-01T21:56:16","slug":"aplicacion-android-para-fotogrametria-con-ia-fase-3-correccion-de-heading-visualizacion-en-vuelo-y-ajustes-de-ux","status":"publish","type":"post","link":"https:\/\/bitacora.eniac2000.com\/?p=11708","title":{"rendered":"Aplicaci\u00f3n Android para fotogrametr\u00eda con IA. Fase 3: Correcci\u00f3n de heading, visualizaci\u00f3n en vuelo y ajustes de UX"},"content":{"rendered":"
Esta entrada es la parte 4 de 6 de la serie Fotogrametr\u00eda asistida por IA<\/a><\/div>\n

En el art\u00edculo anterior<\/a> de esta serie expliqu\u00e9 c\u00f3mo se construy\u00f3 el motor de navegaci\u00f3n aut\u00f3noma con Virtual Stick<\/em> y los bugs m\u00e1s relevantes que aparecieron durante las primeras pruebas de vuelo real. Al terminar esa fase, la app era capaz de volar una misi\u00f3n de principio a fin y tomar fotos en los waypoints correctos. Pero hab\u00eda un problema que s\u00f3lo se hac\u00eda evidente cuando ves volar al dron: volaba de lado<\/strong>.<\/p>\n\n\n\n

La c\u00e1mara no apuntaba en la direcci\u00f3n de avance durante las pasadas de vuelo, sino que el dron navegaba en diagonal, orientado de manera cuasi<\/em> aleatoria. Para fotogrametr\u00eda esto es un problema serio: las fotos salen mal encuadradas, los solapamientos entre im\u00e1genes no se corresponden con los calculados y el resultado del procesado se resiente. Esta Fase 3 fue, en buena medida, la fase de hacer que el dron volara bien, no s\u00f3lo que volara.<\/p>\n\n\n\n

\"Aplicaci\u00f3n
Aplicaci\u00f3n mostrando el vuelo en tiempo real<\/figcaption><\/figure>\n\n\n\n

El problema del heading: por qu\u00e9 el dron volaba de lado<\/h2>\n\n\n\n

En la implementaci\u00f3n original del motor de navegaci\u00f3n, el yaw<\/em> del dron \u2014es decir, hacia d\u00f3nde apunta\u2014 se controlaba usando el bearing<\/em> instant\u00e1neo hacia el siguiente waypoint. En teor\u00eda suena razonable: apunta hacia donde vas. En la pr\u00e1ctica, el bearing instant\u00e1neo oscila mucho cerca de los waypoints<\/em>, cambia durante las transiciones entre pasadas y no tiene en cuenta que lo que necesita la fotogrametr\u00eda es que la c\u00e1mara est\u00e9 alineada con la direcci\u00f3n de la pasada, no con la direcci\u00f3n puntual de movimiento.<\/p>\n\n\n\n

\"Ortofotograf\u00eda
Ortofotograf\u00eda de uno de los primeros vuelos. Se aprecia que la pista deportiva no est\u00e1 completa debido al fallo de orientaci\u00f3n del dron<\/figcaption><\/figure>\n\n\n\n

La soluci\u00f3n fue a\u00f1adir un campo headingDeg<\/code> a cada waypoint<\/em>, calculado en el motor fotogram\u00e9trico como el bearing<\/em> entre el primer y el \u00faltimo waypoint<\/em> de cada l\u00ednea de vuelo. As\u00ed, todos los waypoints<\/em> de una misma pasada comparten un heading<\/em> fijo, que es la direcci\u00f3n real de esa l\u00ednea. La c\u00e1mara siempre apunta a lo largo de la pasada, independientemente de peque\u00f1as correcciones de trayectoria.<\/p>\n\n\n\n

El problema ven\u00eda en las transiciones entre l\u00edneas<\/strong>: cuando el dron terminaba una pasada y se desplazaba lateralmente a la siguiente, usar el heading<\/em> de l\u00ednea durante ese movimiento no tiene sentido. Para detectar estas transiciones se comparaba el bearing<\/em> instant\u00e1neo de movimiento con el heading de la l\u00ednea destino: si la diferencia superaba los 45\u00b0, se consideraba una transici\u00f3n y el dron apunta hacia donde se mov\u00eda; si estaba dentro de los 45\u00b0, manten\u00eda el heading<\/em> de l\u00ednea.<\/p>\n\n\n\n

val angleDiff = abs(((bearing - wp.headingDeg + 540) % 360) - 180)\nval yaw = if (angleDiff > 45.0) bearing else wp.headingDeg<\/code><\/pre>\n\n\n\n
Pero detectar la transici\u00f3n no es suficiente. Cuando el dron llega al primer waypoint<\/em> de una nueva pasada tras un movimiento lateral, puede estar todav\u00eda orientado en la direcci\u00f3n de la transici\u00f3n. Si se dispara la foto en ese momento, sale girada. Se a\u00f1adi\u00f3 por tanto una fase de rotaci\u00f3n pre-foto<\/strong>: si la diferencia entre la orientaci\u00f3n actual y el heading de l\u00ednea supera los 20\u00b0, el dron hace hover<\/em> y rota hasta alinearse antes de disparar. El tiempo de rotaci\u00f3n es proporcional al \u00e1ngulo a corregir, con un m\u00ednimo de 1,5 segundos y un m\u00e1ximo de 3.<\/p>\n\n\n\n
El bug cr\u00edtico: DJI rechaza silenciosamente los \u00e1ngulos fuera de rango<\/h2>\n\n\n\n
Corregido el heading<\/em>, los vuelos de prueba mejoraron notablemente, pero segu\u00eda habiendo un comportamiento extra\u00f1o en las l\u00edneas orientadas hacia el oeste. El dron llegaba al primer waypoint<\/em> de esas pasadas orientado en la direcci\u00f3n correcta, pero al llegar a los siguientes, la rotaci\u00f3n no se completaba. Los logs lo mostraban con claridad:<\/p>\n\n\n\n
WP8 ROTANDO: yaw actual=~180\u00b0 \u2192 l\u00ednea=270.0\u00b0 (\u039490\u00b0)\nWP9 ROTANDO: yaw actual=~180\u00b0 \u2192 l\u00ednea=270.0\u00b0 (\u039490\u00b0)  \u2190 no rot\u00f3<\/code><\/pre>\n\n\n\n
El dron intentaba rotar a 270\u00b0 (oeste) pero se quedaba clavado en 180\u00b0. Despu\u00e9s de descartar otras causas, el diagn\u00f3stico fue el siguiente: el modo YawControlMode.ANGLE<\/code> del DJI MSDK v5 acepta valores \u00fanicamente en el rango [-180\u00b0, 180\u00b0]<\/strong>. Un valor de 270\u00b0 no produce un error \u2014el SDK lo recorta silenciosamente al l\u00edmite\u2014 y el dron se queda apuntando a 180\u00b0 sin que nada indique que algo ha fallado.<\/p>\n\n\n\n
La soluci\u00f3n es normalizar el yaw<\/em> antes de enviarlo al SDK, convirtiendo cualquier \u00e1ngulo al rango [-180\u00b0, 180\u00b0]:<\/p>\n\n\n\n
var normalizedYaw = yawAngle % 360\nif (normalizedYaw > 180) normalizedYaw -= 360\nif (normalizedYaw < -180) normalizedYaw += 360<\/code><\/pre>\n\n\n\n
Con esta normalizaci\u00f3n, 270\u00b0 se convierte en -90\u00b0, que es exactamente lo mismo (oeste) expresado en el rango que el SDK espera. Un detalle peque\u00f1o con un impacto grande: sin \u00e9l, la mitad de las l\u00edneas de vuelo con orientaci\u00f3n oeste, noroeste o suroeste se recorr\u00edan con el dron mirando en la direcci\u00f3n incorrecta.<\/p>\n\n\n\n
Un crash inesperado: listas vac\u00edas a gran altitud<\/h2>\n\n\n\n
Mientras se ajustaba el heading, apareci\u00f3 otro bug<\/em> desagradable: al editar una misi\u00f3n existente y subir la altura por encima de unos 79 metros, la app se cerraba con un NoSuchElementException: List is empty<\/code> en el motor fotogram\u00e9trico.<\/p>\n\n\n\n
La causa tiene una l\u00f3gica clara una vez que se entiende: a mayor altura, mayor es la superficie captada por cada foto y mayor la separaci\u00f3n entre waypoints<\/em>. Llegado a cierto punto, algunas l\u00edneas de vuelo quedan tan cortas (en relaci\u00f3n a la zona de vuelo) que no caben waypoints<\/em> dentro del pol\u00edgono. El generador de rejilla devuelve listas vac\u00edas para esas l\u00edneas, y el c\u00f3digo que calculaba el heading<\/em> intentaba acceder al primer y \u00faltimo elemento de una lista vac\u00eda.<\/p>\n\n\n\n
La soluci\u00f3n fue doble: filtrar las l\u00edneas sin waypoints<\/em> antes de devolverlas, y a\u00f1adir salvaguardas isNotEmpty()<\/code> antes de cualquier acceso a la rejilla. Un bug<\/em> de esos que solo aparece en los extremos del rango de par\u00e1metros, pero que en campo puede surgir perfectamente si alguien decide subir la altura para cubrir un \u00e1rea grande con menos bater\u00eda.<\/p>\n\n\n\n
Visualizaci\u00f3n en tiempo real: saber exactamente qu\u00e9 est\u00e1 haciendo el dron<\/h2>\n\n\n\n
Con el vuelo ya correcto, el siguiente objetivo fue mejorar la informaci\u00f3n disponible en pantalla durante la ejecuci\u00f3n. El mini-mapa original mostraba el plan de vuelo y la posici\u00f3n del dron, pero no permit\u00eda saber si la trayectoria real se correspond\u00eda con la planificada ni d\u00f3nde se hab\u00edan tomado las fotos.<\/p>\n\n\n\n
Se a\u00f1adieron dos StateFlow<\/code> en el motor de ejecuci\u00f3n que se actualizan durante el vuelo:<\/p>\n\n\n\n