Proyecto · Objetivos
Diseñar una herramienta SAR profesional desde cero
El objetivo general es diseñar y construir, desde cero, un UAV autónomo de Búsqueda y Rescate (SAR, del inglés Search And Rescue) como Trabajo de Fin de Grado de Ingeniería de Tecnologías de Telecomunicación — consolidando varias de las principales disciplinas de la carrera en un único sistema funcional.
La motivación real
Más que un requisito para titularme
El título del proyecto lo resume en una frase: un dron que facilite la búsqueda y rescate de personas. Pero detrás de ese objetivo hay una decisión bastante más personal.
Quería un TFG que no se limitara a cumplir un expediente, sino que combinara una de mis pasiones —la aeronáutica y los aviones— con la oportunidad de profundizar en la mayor parte de las disciplinas que he cursado en la carrera. Ahí es donde entran los drones: un concepto que permite tocar muchísimas áreas distintas a la vez, y en el que además hay mucho margen para innovar.
Por eso, aunque el objetivo se resuma en una frase, detrás hay un intento consciente de consolidar el conocimiento de casi toda la carrera —electrónica, comunicaciones, IoT, bases de datos, programación, inteligencia artificial, sistemas, normativa, gestión de proyectos y sostenibilidad— en un único sistema real, no en asignaturas sueltas.
Dicho de forma concreta: mi objetivo ha sido poder cubrir, dentro de un mismo proyecto, cada una de las áreas principales de la carrera, para consolidar así una visión integradora de todo lo visto durante estos cuatro años.
Un ejemplo de cómo encaja todo: los sensores ambientales
A primera vista puede parecer que estos sensores están metidos con calzador: ¿qué pinta un sensor de gases o de temperatura en un dron pensado para encontrar personas? Nada más lejos de la realidad. Por un lado, sirven para comprobar si la zona donde se encuentra la víctima es habitable —posibles emanaciones de gases, humo de un incendio incipiente, o condiciones extremas de frío o calor que puedan ponerla en riesgo—. Por otro, y no menos importante: son el motivo por el que el IoT y los brokers de mensajería (Mosquitto) tienen un papel tan central en el sistema. Necesitaba una forma innovadora de cubrir esa parte del proyecto, un área que me interesaba especialmente, y estos sensores encajaban a la perfección — no como un añadido a la telemetría de vuelo, sino como parte real del objetivo de la misión. En el fondo, el motivo para introducir el IoT no fue solo esa utilidad concreta: fue también una forma más de cumplir el objetivo de fondo de este proyecto — cubrir, dentro de un mismo sistema, todas las áreas vistas a lo largo de la carrera.
Por qué un dron
La aeronáutica es una pasión personal — y los drones concentran casi todas las disciplinas de la carrera en un único sistema real.
Electrónica y integración de circuitos
La electrónica, los sensores y la integración de componentes son un ámbito que quería dominar de verdad, no solo de forma teórica.
Comunicaciones avanzadas
Las comunicaciones —RF, 4G y su seguridad— son el núcleo que mantiene conectado y resiliente todo el sistema.
En concreto, estas son las áreas que he querido cubrir en el proyecto:
Electrónica
Todo el material electrónico necesario para construir el dron: motores, servos, componentes eléctricos, la Raspberry Pi, sensores y baterías.
Comunicaciones
Un núcleo amplio de tecnologías — LTE/4G, WiFi y distintos enlaces de radio — y también seguridad en las comunicaciones: cifrado, redes privadas y redundancia.
IoT & cloud
Una de mis áreas favoritas: brokers como Mosquitto y el uso de la nube para recopilar y almacenar toda la información que genera el dron.
Bases de datos
Entre SQL, NoSQL y series temporales, se ha escogido InfluxDB por ser la más apropiada para la gestión de datos IoT del proyecto, junto con SQLite para el tratamiento de datos en local.
Programación
Python como lenguaje principal para interactuar con el dron: control de vuelo, scripts de misión y comunicación entre los distintos servicios del sistema.
Inteligencia artificial
Durante la carrera trabajé con modelos de lenguaje (LLMs) en varias asignaturas. Dada la importancia actual de la IA, quería incluirla también en el proyecto de alguna forma — por eso Guardian Eye incorpora un sistema de redes neuronales basado en YOLO para la detección de personas.
Sistemas
Linux como base del sistema embarcado, aplicando directamente los conceptos de sistemas operativos vistos en la carrera.
Normativa
Una visión tan importante en telecomunicaciones como poco vistosa: seguida de forma estricta, incluida la obtención de las licencias de vuelo y de operador necesarias.
Gestión de proyectos
Planificación, hitos y validación por etapas — la parte menos visible de un TFG, pero tan real como el propio hardware.
Sostenibilidad (ODS)
Los Objetivos de Desarrollo Sostenible como marco de referencia para pensar el impacto social del proyecto, más allá de la ingeniería pura.
Programación Web
No considero esta web parte de los entregables del TFG en sí, pero quise aprovechar la optativa de Programación Web que cursé en la carrera para darle visibilidad al proyecto — el TFG no tiene por qué limitarse al ámbito de un requisito académico.
“El título dice ‘un dron que facilite la búsqueda y rescate de personas’. La realidad es que ha sido la excusa perfecta para consolidar cuatro años de carrera en un sistema real.”
Un sistema, no piezas sueltas
Nada se desarrolla de forma aislada
Un TFG dividido en piezas independientes —una placa, un script, un servidor y una memoria— no demuestra lo mismo que un único sistema donde esas piezas dependen unas de otras para funcionar. Ahí está, precisamente, la diferencia de este TFG: integrar todas las áreas de la carrera entre sí, en lugar de tratarlas como bloques monolíticos o islas aisladas — cada disciplina solo tiene sentido en Guardian Eye si las demás también funcionan.
Cómo se organiza el desarrollo de estas piezas para que encajen entre sí, y cómo se valida cada una antes de confiar en ella, se explica en detalle en la página de Metodología.
El stack real
Las disciplinas, en herramientas concretas
Cada bloque académico se traduce en tecnologías reales, no en teoría de asignatura: esto es lo que efectivamente corre a bordo y en la nube.
MAVLink
AWS