3. Construcción y validación del entorno de simulación

3.1 Arquitectura de simulación: Unreal Engine 5.5 y Cosys-AirSim

El desarrollo y la validación de este trabajo se realizan, tal como preveía el plan de trabajo aprobado (plan_tesis/plan-tesis.md), sobre AirSim, un simulador basado en Unreal Engine que ofrece física y renderizado de alta fidelidad (Shah et al., 2017). La implementación no usa la distribución original de AirSim de Microsoft, sino Cosys-AirSim (específicamente el build para Windows de la versión Cosys-AirSim v3.3 for Unreal v5.5, un fork mantenido por el Cosys-Lab (Laboratorio de Co-Diseño para Sistemas Ciber-Físicos de la Universidad de Amberes, Bélgica), porque el proyecto original de Microsoft está abandonado. El plugin se compila e integra sobre proyectos de Unreal Engine 5.5 (específicamente la versión 5.5.4-40574608+++UE5+Release-5.5), que sirven como banco de pruebas y validación experimental.

Cosys-AirSim, a diferencia del AirSim clásico de Microsoft —enfocado principalmente en cámaras RGB y visión por computadora—, agrega sensores adicionales basados en GPU y CPU (LiDAR, sonar, radar), documentados en el paper oficial de la plataforma (Jansen et al., 2023). Este trabajo no usa esos sensores adicionales: la percepción descrita en el capítulo 6 depende exclusivamente de la cámara RGB monocular y de la telemetría de actitud, consistente con la restricción de hardware de bajo costo que motiva todo el proyecto (§1.2). La elección de Cosys-AirSim sobre el AirSim original responde a la actividad de mantenimiento del fork más que a una necesidad de esos sensores adicionales: el proyecto de Microsoft no recibe actualizaciones activas.

Particularidades de la API y telemetría de actitud. A diferencia del paquete clásico airsim, el binding cosysairsim no expone la función auxiliar to_eularian_angles para la extracción directa de ángulos de actitud; sin ella, un fallback ingenuo reporta pitch y roll en \(0.0^\circ\) de forma permanente. Para no introducir dependencias externas, el cliente de simulación (AirSimClient._quaternion_to_euler) implementa la conversión matemática directa de cuaterniones a ángulos de Euler en convención aeroespacial NED (North-East-Down), de modo que las variaciones de inclinación del cuadricóptero alimenten con fidelidad continua la telemetría del lazo táctico y el contexto del modelo deliberativo.

Casos de uso de AirSim y Cosys-AirSim en la literatura

La elección de AirSim como plataforma no es un caso aislado: es el simulador de referencia de una línea de trabajo amplia que abarca múltiples tipos de vehículo, dominios de aplicación y paradigmas de aprendizaje, lo cual sitúa a este trabajo dentro de un ecosistema de investigación activo en lugar de una herramienta de nicho.

AirSim más allá de los cuadricópteros. Aunque este trabajo usa exclusivamente el modelo de multirotor, AirSim fue diseñado desde su publicación original como una plataforma multivehículo: el mismo motor de física e interfaz de API sirve tanto para drones como para automóviles autónomos, con un wrapper oficial de ROS (airsim_ros_pkgs) que expone odometría NED, imágenes de cámara y datos de LiDAR/IMU como tópicos estándar para integrarse con pilas de navegación basadas en ROS/ROS2. Una revisión reciente de simuladores de código abierto para conducción autónoma (Li et al., 2023) ubica a AirSim junto a CARLA y LGSVL como una de las plataformas de referencia del campo, con la particularidad —relevante para este trabajo— de estar construido sobre Unreal Engine en lugar de un motor gráfico propio, lo que permite reutilizar directamente el mismo pipeline de escalabilidad gráfica y activos de entorno descripto en §3.3 para ambos tipos de vehículo.

En el dominio aéreo específicamente, AirSim ha sido la base de dos líneas de investigación directamente pertinentes a este trabajo. La primera es la competencia Game of Drones de NeurIPS 2019 (Madaan et al., 2020), organizada junto con Stanford y la Universidad de Zúrich sobre el framework AirSim Drone Racing Lab: benchmarking de percepción, planificación de trayectoria y control de multirotores compitiendo cabeza a cabeza en circuitos de carreras simulados, con el objetivo explícito de reducir la barrera de entrada de la comunidad de machine learning a la investigación en autonomía de drones —el mismo objetivo de accesibilidad que motiva la elección de un simulador gratuito y de código abierto en este trabajo—. La segunda línea es más cercana aún al problema central de esta tesis: Xue y Gonsalves (2021) entrenan un agente de aprendizaje por refuerzo profundo (soft actor-critic) para evasión de obstáculos usando exclusivamente mapas de profundidad como entrada, en un entorno construido íntegramente sobre AirSim, logrando generalización a entornos reconfigurados sin reentrenamiento. El paralelismo metodológico es directo —evasión de obstáculos a bordo de un UAV, en AirSim, a partir de un único canal de percepción visual— aunque la elección de arquitectura difiera en un punto central: donde Xue y Gonsalves aprenden una política mediante aprendizaje por refuerzo sobre profundidad, este trabajo compara una política aprendida implícitamente por un modelo de lenguaje pre-entrenado contra una heurística explícita, ambas sobre flujo óptico monocular, y usa la profundidad solo estimada desde el RGB, nunca el sensor de profundidad del simulador (cap. 6). AirSim también se ha usado para escenarios de más alto nivel de sistema: Turco et al. (2024) construyen un gemelo digital de co-simulación entre MATLAB y AirSim para movilidad aérea avanzada (Advanced Air Mobility), y sus mediciones de consumo de VRAM del propio AirSim sobre Unreal Engine son, de hecho, la fuente del presupuesto de memoria de video que condiciona la elección del modelo de lenguaje de este trabajo (cap. 8, §8.1).

Cosys-AirSim y la extensión a nuevos dominios de vehículo. La motivación declarada del fork de Cosys-Lab no es solamente mantenimiento activo (§3.1): es también la incorporación de modalidades de sensor y tipos de vehículo ausentes en el AirSim original, documentada en su propio artículo de referencia (Jansen et al., 2023) — un sensor LiDAR acelerado por GPU con mayor densidad de puntos, un sensor genérico de tipo echo que modela tanto sonar como radar mediante trazado de rayos, y un modo de simulación de dirección por deslizamiento (skid-steering) con vehículos terrestres de referencia (ClearPath Husky, Pioneer P3DX) ya implementados como tipos de vehículo. Ninguna de estas extensiones se usa en este trabajo, que se restringe deliberadamente a cámara RGB monocular y telemetría de actitud (§3.1) — pero su existencia es la evidencia de que Cosys-AirSim es una plataforma activamente extendida por la comunidad, no un fork estático. La extensión más reciente y más ilustrativa de esa actividad es ASVSim (Lesy et al., 2026): un framework construido directamente sobre Cosys-AirSim que añade dinámica de embarcaciones y sensores marítimos (radar, cámara) para investigación en vehículos de superficie autónomos en canales navegables y puertos —una prueba directa de que la arquitectura de Cosys-AirSim generaliza a un dominio de vehículo completamente distinto (naval en lugar de aéreo o terrestre) sin reescribir el núcleo de simulación—, publicado por el mismo grupo de investigación (Cosys-Lab, Universidad de Amberes) que mantiene el fork adoptado por este proyecto.

Este panorama sitúa la elección metodológica de este trabajo con precisión: de una plataforma que soporta multirotores, automóviles, vehículos con dirección por deslizamiento y embarcaciones, con sensores que van desde cámara RGB hasta LiDAR, sonar y radar, este trabajo usa deliberadamente el subconjunto más restringido posible —un multirotor con una única cámara RGB monocular y sin sensores de profundidad activos—, consistente con la restricción de hardware de bajo costo que motiva el proyecto (§1.2) y con el objetivo de aislar qué tan lejos puede llegar la navegación autónoma con la configuración sensorial más económica que la plataforma permite simular.

3.2 Desvío respecto del plan aprobado: de la fotogrametría de Buenos Aires a activos urbanos genéricos

El plan de trabajo aprobado describía un pipeline de digitalización de entornos urbanos específico: extraer fotogramas de videos públicos de drones en Buenos Aires (YouTube), filtrarlos para asegurar diversidad visual, anotar obstáculos y zonas de aterrizaje con LabelImg/LabelMe, y reconstruir modelos 3D hiperrealistas con RealityCapture (fotogrametría) a partir de esos videos y de OpenStreetMap, optimizados en Blender para reducir su complejidad computacional antes de importarlos a AirSim (plan_tesis/plan-tesis.md, §"Metodología"). El objetivo declarado era un entorno virtual 3D personalizado de Buenos Aires, con las particularidades geométricas de su infraestructura densa.

La implementación efectivamente construida sustituyó ese pipeline de fotogrametría por activos urbanos y suburbanos ya disponibles para Unreal Engine (marketplace de Fab/Epic Games y paquetes de terceros), configurados con el plugin de Cosys-AirSim en lugar de reconstruidos a partir de video real de Buenos Aires (disponibles en el repositorio compartido de Google Drive: https://drive.google.com/drive/folders/1roLmbGFNsHXZyT3NaNzNYMuaBQ8CulX7).

Entornos principales estructurados por Tiers de evaluación

Para responder con rigor al protocolo experimental de la tesis (capítulo 10), los entornos de simulación se organizan en una jerarquía formal de tres niveles de complejidad (Tiers):

1. Tier 0 — Base / Control (MiniSim): Entorno abierto basado en el proyecto base de Unreal Engine https://dev.epicgames.com/documentation/unreal-engine/unreal-engine-templates-reference?application_version=5.5: un plano liso con textura de tablero, sin relieve ni objetos (la imagen crater.png que muestra WebDCS es solo un fondo y no corresponde al mundo). Diseñado para pruebas de calibración cinemática, sintonización de controladores de posición y determinación de la cota inferior de latencia del sistema sin interferencia de obstáculos.

2. Tier 1 — Intermedio / Morfología orgánica y vegetación (TownSim): Entorno semiurbano (mapa cenital townsim_ortho.png, construido con capturas del propio simulador: 4 px/m, origen NED en el centro, norte arriba; cap. 4 §4.3.2), basado en el entorno Downtown West Modular Pack https://www.fab.com/listings/0faf8b5d-7a5f-4fee-a297-7a8efaba8896 de PurePolygons. Presenta calles de ancho variable, fachadas intermedias, mobiliario y arboledas densas. Constituye el banco de pruebas de los escenarios de recorrido perimetral (townsim_clear), de travesía del corredor arbolado (townsim_ini) y de bloqueo frontal masivo (townsim_calib_cruce_frontal).

3. Tier 2 — Complejo / Cañones urbanos de gran densidad (CitySim): Proyecto de Unreal Engine 5.5 con tejido edilicio masivo (mapa cenital citysim_ortho.png, construido con capturas del propio simulador: 2 px/m, origen NED en el centro, norte arriba; cap. 4 §4.3.2), rascacielos, pasos restringidos y disposición en cuadrícula ortogonal, basado en el entorno Sample City https://www.fab.com/listings/4898e707-7855-404b-af0e-a505ee690e68 de Epic Games. El escenario de control es citysim_clear.json: perímetro de una manzana con 4 waypoints (~420 m) y altitud creciente en rampa (−10, −30 y −50 m) antes de volver a −10 m. Los escenarios con corredores angostos (citysim_pilot.json) constituyen el escenario de dificultad máxima del tier.

3.3 Configuración de rendimiento, escalabilidad gráfica e higiene de captura

La documentación técnica de Cosys-Lab sostiene que priorizar la tasa de actualización de la física por sobre la fidelidad gráfica es una práctica recomendada cuando el objetivo principal no es la fotografía cinemática de la escena. Siguiendo esas directrices y considerando que la misma estación de cómputo aloja en simultáneo el renderizado 3D y la inferencia del modelo de lenguaje local (§8.1), se establecieron los siguientes compromisos de arquitectura:

• Desactivar el ahorro de CPU en segundo plano del editor de Unreal Engine (Use Less CPU when in Background), evitando caídas drásticas en el refresco de la física cuando la ventana del simulador pierde el foco.
• Ajustar ClockSpeed en settings.json para sincronizar el tiempo de simulación y garantizar que el lazo físico se calcule sin pérdidas temporales cuando la carga gráfica fluctúa.
• Preferir binarios empaquetados (standalone) sobre la ejecución directa desde el editor, reduciendo la sobrecarga de memoria VRAM asociada a la interfaz de desarrollo.
• El modo NoDisplay no pudo utilizarse, dado que la captura de imágenes RGB monocular es estrictamente indispensable para la percepción del dron (capítulo 6).

Escalabilidad gráfica en Unreal Engine 5.5

Para equilibrar la carga de GPU entre Unreal Engine y el servidor SLM/VLM local, se definió un perfil de escalabilidad mínima (Minimal Scalability Config) que fija sombras, postprocesamiento e iluminación global en niveles bajos (Low/Medium), reservando la VRAM necesaria para los pesos del modelo multimodal.

Sin embargo, en Unreal Engine 5.5 la reducción automática de efectos suele degradar la resolución de los render targets de captura de escena. Para evitar que la cámara frontal pierda nitidez o altere el cálculo de flujo óptico, se forzó el nivel de detalle en el archivo Config/DefaultScalability.ini del proyecto Unreal:

[EffectsQuality@0]
r.DetailMode=2
[EffectsQuality@1]
r.DetailMode=2
[EffectsQuality@2]
r.DetailMode=2
[EffectsQuality@3]
r.DetailMode=2
[EffectsQuality@Cine]
r.DetailMode=2

También desde el editor de Unreal Engine se puede configurar la escalabilidad de la siguiente manera:

Con esta configuración Scalability de Unreal Engine se asegura a la hora de ejecutar la simulación: - Captura de video desde AirSim (con Effects=Epic) - Sombras en las texturas necesarias para capturar los gradientes usados para el cálculo del TTC con el flujo visual (con Shadows=Epic).

(Para la especificación completa del archivo settings.json anotado, el perfil de escalabilidad y el protocolo de reproducibilidad del entorno de simulación, véase el Anexo 6).

Higiene y consistencia de la captura monocular

El cliente de simulación aplica dos medidas de higiene sobre el canal visual:

1. Orden de canales de color (RGB vs. BGR): El buffer crudo devuelto por simGetImages(ImageType.Scene) en Cosys-AirSim viene en formato RGB, mientras que OpenCV y las rutinas de compresión asumen la convención BGR; sin conversión, las capturas enviadas al VLM y guardadas en auditoría muestran rojo y azul invertidos. AirSimClient.capture() convierte el orden de canales, de modo que el modelo razona sobre los colores naturales de la escena (pavimento, vegetación y cielo).
2. Supresión de marcadores de depuración persistentes: Primitivas geométricas dibujadas en el mundo virtual por scripts de planificación (mediante simPlotLineStrip y simPlotPoints de plot_mission_route.py) permanecen activas en el nivel, la cámara a bordo las captura y el VLM las interpreta como obstáculos físicos. Por eso cada sesión de conexión empieza con una rutina de higiene obligatoria (AirSimClient.clear_debug_markers(), que invoca simFlushPersistentMarkers()).

3.4 Validación frente a telemetría de vuelos reales

La dinámica de vuelo simulada —no la geometría de la escena urbana, cuya fidelidad fotográfica es el desvío documentado en §3.2— se validó de forma independiente contra telemetría de drones reales, con el objetivo explícito de que la comparación experimental entre brazos (capítulo 10) se apoyara en vuelos simulados cuya cinemática fuera comparable a la de un cuadricóptero real y no solo físicamente plausible en abstracto.

Fuente de datos reales. Se descargó un conjunto de datos de telemetría real de drones cuadricópteros comerciales (DJI) desde el repositorio público de Zenodo (https://zenodo.org/records/15912415).

Protocolo de calibración. Sobre esa telemetría real se identificaron dos trayectorias de vuelo distintas —un patrón rectangular simple (Drone 1) y un patrón de cruz combinado con rectángulo (Drone 2)— y se reprodujeron en simulación con moveOnPath/move de la API de AirSim, ajustando la simulación a la misma altura y la misma velocidad que los vuelos reales correspondientes. La trayectoria completa se envía como un único comando moveOnPath, y no como una secuencia de tramos independientes, para que el perfil de aceleración simulado se parezca al de un vuelo real continuo; la telemetría de cada vuelo simulado se registra en un CSV individual.

Metodología estadística. El análisis se implementó en notebooks de Jupyter del repositorio complementario del proyecto (consolidate_telemetry.ipynb y telemetry_analysis_*.ipynb, georgsmeinung/lm-drone), con estadística descriptiva y pruebas de significancia —en particular la prueba de Levene para diferencia de varianzas— aplicadas al cambio de velocidad en los tres ejes, para determinar si la distribución de la telemetría simulada difiere de forma significativa de la real.

Resultado. El análisis documenta tres hallazgos consistentes:

1. La varianza de actitud difiere de forma significativa (prueba de Levene, p ≪ 0,05): en simulación, el dron ejecuta inclinaciones de roll/pitch extremas durante los giros rápidos para alcanzar instantáneamente el punto de trayectoria siguiente. Los drones reales, en cambio, están limitados electrónicamente por su controlador PID de estabilización (típicamente a ±30°), y muestran una varianza mucho menor y acotada durante las mismas maniobras.
2. La segregación por trayectoria es significativa y consistente. El Drone 1 (patrón rectangular, giros menos frecuentes) concentra la aceleración en las esquinas; el Drone 2 (patrón de cruz y rectángulo continuo) presenta una dinámica transicional más exigente y oscilaciones de roll/ pitch más ruidosas, tanto en el vuelo real como en el simulado.
3. El vuelo simulado en tramos rectos es idealizado. Durante las fases rectas, la telemetría simulada muestra varianza de actitud cercana a cero, sin fuerzas externas de viento ni ruido de sensores; el dron real, en cambio, mantiene una variabilidad permanente de ±2°–3° en roll y pitch incluso en tramos rectos estables, producto del viento real y de las correcciones continuas del piloto automático.

Alcance de esta validación. Confirma que la dinámica de vuelo simulada —cómo se mueve el dron dado un comando— es más ágil y menos amortiguada que la de un dron real equivalente, con una brecha de idealización conocida y cuantificada (varianza de actitud, ausencia de viento simulado). No valida, en cambio, la fidelidad fotográfica de la escena urbana frente a Buenos Aires real: esa es una validación distinta, no realizada, y coincide con el desvío documentado en §3.2. Un ejercicio de validación relacionado pero diferente —si el suavizado por histéresis y media móvil exponencial de WaypointTracker (capítulo 5, §5.15) acerca de forma medible la telemetría simulada a la real— da un resultado ambiguo (std(Δvx) prácticamente igual con y sin suavizado) y se informa como tal, no como una mejora confirmada.