Simulación Instrumentos De Vuelo
Proyecto seytrma2526g06 · URJC · Edward Andrei · Manuel Alos · Anass Chikou
¿Qué hemos construido?
En este proyecto de sistemas empotrados hemos desarrollado dos instrumentos reales de cabina de avión funcionando sobre hardware de bajo coste. El resultado es un sistema interactivo que replica fielmente la información que un piloto tendría frente a él en la cabina.
El sistema implementa dos modos de visualización:
- Horizonte Artificial (ADI): muestra el cabeceo (pitch) y el alabeo (roll) del avión en tiempo real, con una escalera de pitch rotada y una escala de alabeo.
- Medidor de Fuerzas G (G-Meter): barra de nivel con escala cromática que indica la fuerza G total y el pico máximo registrado en la sesión.
Además, el sistema incluye una alarma sonora mediante zumbador pasivo que se activa cuando el pitch o el roll superan los ±40°, y una pantalla táctil que permite alternar entre ambos modos con un simple toque.
Componentes del proyecto
| Componente | Función | Precio |
| Arduino UNO | Microcontrolador principal | – |
| MPU-6050 | Acelerómetro y giroscopio | 10€ |
| ILI9341 | Pantalla táctil | 18€ |
| Zumbador pasivo | Alarma sonora | 1,50€ |
| Batería 9V | Alimentación portátil | – |
Coste total aproximado: 30 €
Cómo funciona el sistema
El sistema sigue un ciclo de estados bien definido:
- Arranque: calibra el giroscopio tomando 200 muestras durante aproximadamente 600 ms para eliminar el ruido de offset.
- Modo Horizonte: dibuja el ADI con pitch, roll y la escala de alabeo cada frame.
- Toque táctil: con un antirrebote de 500 ms, alterna entre el modo ADI y el G-Meter.
- Modo G-Meter: muestra la barra de nivel, los valores de los tres ejes, el G total y el pico máximo.
- Alarma: si |pitch| ≥ 40° o |roll| ≥ 40°, el zumbador se activa automáticamente.
Modo Horizonte Artificial (ADI)
El ADI calcula la actitud del avión a partir de los datos del acelerómetro usando trigonometría:
- Pitch: arctan( ay / √(ax² + az²) )
- Roll: arctan( -ax / az )
La pantalla se divide en cielo (azul) y tierra (marrón). El bucle de renderizado recorre las 320 columnas de la pantalla calculando para cada una la altura de la línea del horizonte según la pendiente del roll y el desplazamiento del pitch. Para cada columna se pintan dos líneas verticales: la porción de cielo y la de tierra.
Optimización triángulos
La estrategia del refresco por triángulos es un método de optimización que intenta ahorrar tiempo actualizando únicamente los píxeles que cambian de color cuando el avión se mueve. En lugar de redibujar todos los píxeles de la pantalla, el algoritmo compara la posición del horizonte anterior con el nuevo y solo sobrescribe esa área específica, convirtiendo el cielo en tierra o viceversa según sea necesario.
Esta solución no es viable porque genera artefactos y errores visuales en la pantalla. Desconocemos si la causa es el ruido del sensor, la falta de precisión del Arduino o fallos en el código, por lo que mantenemos el redibujado completo por columnas para garantizar una imagen estable.
Optimización SPI
Sin optimizar, el pin CS (Chip Select) cambia de estado con cada píxel individual, lo que provocaba que la pantalla tardara varios segundos en refrescar, lo que hacía el sistema muy lento y no era tan útil para usarlo en tiempo real porque tardaba mucho en actualizar la información.
La solución fue envolver todo el bucle de 320 columnas dentro de una única transacción SPI usando startWrite() y endWrite(). Con esto, el CS se mantiene activo durante toda la operación y el refresco pasa a ser prácticamente instantáneo. Esta fue la optimización con mayor impacto en el rendimiento de todo el proyecto.
Modo G-Meter
El G-Meter calcula la magnitud total de la fuerza G combinando los tres ejes del acelerómetro:
G total = √( ax² + ay² + az² )
En reposo el valor es aproximadamente 1 g (la gravedad terrestre). La pantalla muestra una barra de nivel cuyo color cambia según la zona:
- 0 – 2 g → Verde: operación normal
- 2 – 3 g → Amarillo: zona de precaución
- 3 – 4 g → Rojo: zona de peligro
Junto a la barra se muestran los valores numéricos de cada eje (X, Y, Z), el G total y el pico máximo alcanzado durante la sesión.
Conexiones al Arduino
El MPU-6050 se comunica por I²C, mientras que la pantalla ILI9341 usa SPI para la transferencia de píxeles.
| I²C | |
| SDA | A4 |
| SCL | A5 |
| VCC | 5V |
| GND | GND |
| SPI | |
| CS | D10 |
| DC | D9 |
| RST | D8 |
| MOSI | D11 |
| SCK | D13 |
| MISO | D12 |
| CS Táctil | D4 |
Problema de voltaje
El controlador ILI9341 opera a 3.3 V mientras que el Arduino UNO envía señales de 5 V. Para resolver esta incompatibilidad instalamos divisores de voltaje mediante resistencias en todos los pines de datos, protegiendo así el controlador de la pantalla.
Proceso de montaje
El proyecto pasó por varias fases de montaje. Empezamos con una protoboard para validar todas las conexiones, y fuimos refinando el cableado del MPU-6050 una vez confirmado el funcionamiento. La carcasa final se construyó en cartón y se pintó de negro, simulando el aspecto de un bombardero real (B2 Spirit).
Conclusiones
Con menos de 30 € en componentes y una placa Arduino, es posible replicar el comportamiento de dos instrumentos reales de cabina con un buen resultado. Lo que aprendimos al hacer el proyecto fue:
- La optimización del rendimiento vino de la mejora de SPI, no del algoritmo de dibujado.
- Los divisores de voltaje son imprescindibles cuando se utilizan 5 V y 3.3 V con la pantalla que hemos configurado.
- El uso de la pantalla táctil como único control de usuario simplifica el hardware.
Proyecto realizado para la asignatura de Sistemas Empotrados · ETSII · URJC Grupo seytrma2526g06 · Edward Andrei · Manuel Alos · Anass Chikou
