Integración de enjambre de drones en sistemas de control de campos solares

Proyecto Fin de Carrera Ingeniería de Telecomunicación Formato de Publicación de la Escuela Técnica Superior de Ingeniería Autor: F. Javier Payán Somet Tutor: Juan José Murillo Fuentes Dep. Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2013 Trabajo Fin de Máster Máster en Ingeniería Industrial Integración de enjambre de drones en sistemas de control de campos solares Autor: Jenifer Delgado Rich Tutor: José María Maestre Torreblanca Tutor externo: Ramón Andrés García Rodríguez Dpto. Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 Trabajo Fin de Máster Máster en Ingeniería Industrial Integración de enjambre de drones en sistemas de control de campos solares Autor: Jenifer Delgado Rich Tutor: José María Maestre Torreblanca Tutor externo: Ramón Andrés García Rodríguez Dpto. Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 Trabajo Fin de Máster: Integración de enjambre de drones en sistemas de control de campos solares Autor: Jenifer Delgado Rich Tutor: José María Maestre Torreblanca Tutor externo: Ramón Andrés García Rodríguez El tribunal nombrado para juzgar el trabajo arriba indicado, compuesto por los siguientes profesores: Presidente: Vocal/es: Secretario: acuerdan otorgarle la calificación de: El Secretario del Tribunal Fecha: Agradecimientos Me gustaría utilizar estas líneas para agradecer a todas aquellas personas que me han ayudado a lo largo de este máster. A los innumerables compañeros y amigos que me han ayudado con las asignaturas del máster. A Ramón y a Pepe, mis tutores, por confiar en mí y darme la oportunidad de realizar este bonito proyecto y, sobre todo, por la ayuda ofrecida. A mis padres, por su cariño y ánimo, puesto que sin ellos quedaba dudosa la finalización de este máster. A Vicente, por su continuo apoyo y la paciencia infinita que ha demostrado en las épocas más duras de estudio. A todos ellos, muchas gracias. Jenifer Delgado Rich Estudiante Máster Ingeniería Indutrial Sevilla, 2021 I Resumen En este trabajo se integra un enjambre de drones en un sistema de control con el objetivo de mejorar los procesos de integración de la energía solar en los sistemas que suministran energía. Se ha definido un sistema escalable y abierto, de tal forma que si se quiere integrar otro tipo de vehículo, el esfuerzo es mínimo. III XÍndice 3.2.3 Nodo de tierra 37 3.2.4 Interfaz gráfica 38 3.3 Funcionamiento 38 4 Conclusiones y trabajo futuro 47 4.1 Conclusiones 47 4.2 Trabajo futuro 47 Índice de Figuras 49 Bibliografía 51 Índice de Códigos 53 Glosario 55 1. Introducción Cualquiera que deje de aprender es viejo, ya sea a los veinte u ochenta. Cualquier persona que sigue aprendiendo se mantiene joven. HENRY FORD 1.1. Relevancia de los Unmanned Aerial Vehicles (UAVs) El primer uso de vehículos aéreos no tripulados se remonta al ataque con globos incendiarios sobre Venecia por parte del ejército austríaco en julio de 1849 como muestra la Figura 1.1. En dicho ataque, las aeronaves se movían a merced del viento, llegando algunas incluso a impactar en el mismo punto de dónde partieron. En posteriores conflictos bélicos, con la I Guerra Mundial, se haría un uso más efectivo de la idea del ejército austriaco, utilizando las primera aeronaves no tripuladas controladas por radio desde tierra para dotar de cierta inteligencia y dirigir estas aeronaves contra los zepelines del ejército alemán. Figura 1.1 Ataque de las tropas austríacas con globos incendiarios1 Poco después, el desarrollo de estas aeronaves evolucionó gracias a la implementación de los sistemas de control por radio diseñados por Archibald Montgomery Low, produciéndose el 21 de marzo de 1917 el primer vuelo de un monoplano bajo control. Durante el periodo de entre guerras, se continuó desarrollando esta 1Obtenida en https://theflyingdroneblog.wordpress.com/2017/06/18/drones-a-brief-history/ 1 2Capítulo 1. Introducción tecnología, que difería poco de lo que hoy podría considerarse un misil de crucero. En 1931, los británicos desarrollaron el monoplano radiocontrolado Fairey Queen, que se puede observar en la Figura 1.2, usado por primera vez como un objetivo militar móvil. Figura 1.2 Aeronave Fairey Queen2 El éxito de este prototipo llevó a la producción masiva de objetivos aereos radiocontrolados, entre ellos el popular "DH.82B Queen Bee". Se dice que el nombre Queen Bee es el origen del termino popularmente conocido como drone (que en español significa zángano, pero que se ha adapatado finalmente al español como dron). Gracias a los avances en 1929 del cientifico hungaro Kálmán Tihanyi sobre los sistemas de visión, hicieron que embarcar esta tecnología sobre las plataformas aéreas no tripuladas implicasen un uso no destructivo del vehículo. Durante la II Guerra Mundial, Reginald Denny, un ex-miembro de la Royal British Flying Corps, crearía en EEUU la Radioplane Company, primera empresa en fabricar aviones de radio control para entrenar a los artilleros de la defensa antiaérea. Tras múltiples demostraciones, Denny y sus socios, consiguieron ganar un contrato con el ejército americano y fabricar 15000 drones de práctica para el ejército durante dicha guerra. En la Figura 1.3, se puede ver el modelo OQ-2 que fue el primer modelo en fabricarse de manera masiva. Figura 1.3 Radioplano OQ23 2Obtenida en https://commons.wikimedia.org/wiki/File:HMS_Furious-18.jpg 3Obtenida en https://en.wikipedia.org/wiki/History_of_unmanned_aerial_vehicles 1.1 Relevancia de los UAVs 3 Hasta 1946 la evolución de los drones continúa como objetivo balístico y en paralelo con el desarrollo de misiles guiados sofisticándose conforme evolucionan las tecnologías en el campo de las comunicaciones y en el campo de la propulsión. En ese mismo año, se reutilizan prototipos de UAVs para hacer estudios de radioactividad sobre los hongos de detonaciones nucleares. Este sirve como disparador de las primeras misiones de reconocimiento. El uso de los drones como plataforma de reconociemiento seguiría su desarrollo a lo largo de la época de los 50, teniendo su apogeo durante los 60 y 70 en misiones de reconocimiento en el norte de Vietnam, en la China comunista y en Corea del Norte. El uso de UAVs en misiones espías, fue incentivado por la mala prensa que tenía en la guerra de Vietnam, la captura de pilotos americanos por parte del Viet Cong. Tras Vietnam, el uso de robot aereos quedó demostrado. Al mismo tiempo, se habían dado los primeros pasos hacia su uso activo en combate marítimo y terrestre, aunque el uso en combate no se desarrollaría propiamente dicho hasta 1980. Al inicio de esa década, la visión que se tenía de los UAVs es que no eran fiables y resultaban caros. No obstante, la guerra de Israel contra Siria dio un giro respecto a esta perspectiva, debido al enorme número de bajas que causaron los UAVs sobre la aviación siria sin apenas pérdidas para el ejército de Israel. Este último, utilizó los drones como señuelos e inhibidores electrónicos y sistemas de vigilancia durante esta guerra. Esto, marcó el inicio de una nueva era en la que los UAVs se utilizan para la interceptación de señales de inteligencia, la recopilación de información y la guerra electrónica, siendo fundamentales para la guerra contra el terrorismo y en misiones de espionaje [1]. Conforme el desarrollo de las tecnologías de UAVs ha sido probado en diferentes conflictos bélicos con buenos resultados, ha habido una transferencia natural hacia el uso a nivel nacional por parte de los estados en tareas como el control de fronteras, el soporte ante desastres naturales o la vigilancia del tráfico. La popularización de su uso para prácticas no militares, ha sido propiciado conforme ha mejorado el costebeneficio de estas soluciones y ha hecho crecer su interés entre compañías privadas que buscan extender sus capacidades en el ámbito civil. Es innumerable la variedad de aplicaciones que existen en sectores como la energía (supervisión de líneas eléctricas), la agricultura (fumigación de campos) o en el sector de las comunicaciones (soporte audiovisual). Hoy en día los UAVs presentan una gran variedad de configuraciones, que llevan asociadas distintos beneficios y desventajas que son ponderadas a la hora de aplicarse en unos sectores u otros. Por ello, a continuación se muestra una clasificación según el tipo de ala. 1.1.1. Clasificación de UAVs Según la tarea que se quiera realizar, será necesario utilizar una morfología de la plataforma aérea. En función de el alcance, la altitud, la autonomia y el peso máximo al despegue que se necesite para la aplicación en concreto, se puede elegir entre dos configuraciones de ala: ala rotatoria y ala fija. Ala rotatoria Los drones de ala rotatoria son también conocidos como multirrotores. Dentro de las ventajas con las que cuentan estas arquitecturas son la capacidad de despegar y aterrizar de forma vertical además de poder mantenerse en una misma posición, con lo que ofrecen mucha versatilidad. En contraposición, suelen tener menos autonomía [2]. Los más comunes son, según el número de motores: • Cuatro motores: son el tipo de dron más extendido y por tanto el más económico. Tiene dos configuraciones, en equis (X) o en cruz (+). Figura 1.4 Quadcóptero4 4Capítulo 1. Introducción • Seis motores: los dos motores adicionales respecto a la arquitectura anterior, proporcionan más potencia y más estabilidad. Figura 1.5 Hexacóptero5 • Ocho motores: estas plataformas son las que más estabilidad tienen, pero al tener que incluir más peso, cada vez la estructura se va haciendo más grande. Figura 1.6 Octacóptero6 Ala fija Esta tipología es la más parecida a los aviones comerciales. Gracias a la aeródinamica que tiene su estructura y al perfil alar, estas plataformas pueden volar más tiempo. Y, gracias a la velocidad que consiguen, pueden recorrer grandes superficies por lo que se suelen utilizar para labores de agricultura o para mapeos de terrenos [ 3 ]. En cambio, tienen la desventaja de que no pueden despegar de forma autónoma (necesitan un sistema mecánico o que lo lance el operador) y que necesitan cierto espacio para aterrizar. 4Obtenida en https://www.dji.com/es/spark 5 Obtenida en https://www.amazon.es/SJAPEX-Hexacopter-Cuadricoptero-Retenci<%C3%B3n-Rotaci%C3%B3n/dp/B07YKN93Z8 6Obtenida en https://www.dji.com/es/matrice600 1.1 Relevancia de los UAVs 5 Figura 1.7 Dron de ala fija 1.1.2. Enjambre de UAVs A día de hoy, los drones individuales como producto están bastante desarrollados. De hecho se pueden encontrar gran variedad de productos en el mercado que, sin necesidad de licencia, pueden adquirirse y realizar muchas de las tareas comentadas con anterioridad, como fotogrametría. En cambio, la investigación y desarrollo con sistemas de multiples drones no está todavía muy desarrollado. El uso de múltiples vehículos aéreos no tripulados puede aportar varias ventajas respecto al uso individual; aproximar una tarea con un enfoque de drones colaborativo mejora la eficiencia de los tiempos sobre todo en tareas que requieren la monitorización de superficies muy extensas o la toma de medidas de forma simultánea. En el tema económico, una ventaja puede ser que el coste global de adquisición y mantenimiento de varios vehículos aéreos no tripulados pequeños sea menor que el coste global de un solo vehículo aéreo no tripulado grande necesario para la misma tarea. Además, el uso de enjambres proporciona tolerancia a los fallos, ya que un sólo dron puede ser eliminado con un impacto limitado para el conjunto del sistema. Los enjambres también pueden proporcionar escalabilidad, es decir, añadir o eliminar drones de un enjambre, para adaptarse mejor a las condiciones cambiantes o simplemente para reemplazar uno o más UAVs que experimenten problemas o agotamiento de la batería [4]. Uno de los aspectos más relevantes de los enjambres de drones es la arquitectura de comunicaciones, que define la manera en la que se comunican los elementos del sistema. 1.1.2.1. Arquitecturas de comunicación en los enjambres La definición de la arquitectura de comunicaciones de un enjambre de drones depende inicialmente de la potencia que tenga el radioenlace de tierra. Para un conjunto de aeronaves que están realizando una misión a una distancia prudencial, la arquitectura más adecuada es la centralizada puesto que es una arquitectura bastante simple y estable. En cambio, a medida que el objetivo del sistema empieza a cubrir áreas más amplias y alejadas de la estación de tierra, se opta por descentralizar las comunicaciones para reducir la dependencia del grupo de dicha estación. En contraposición, aumenta la complejidad de la solución [5]. •Arquitectura centralizada En este tipo de arquitectura, todos los vehículos están conectados al enlace de tierra como se observa en la Figura 1.8. Como se ha comentado antes, es un sistema más sencillo pero se crea un gran dependencia de la estación de tierra, puesto que si ese nodo se cae se paraliza toda la red de comunicaciones. 6Capítulo 1. Introducción Figura 1.8 Arquitectura de comunicaciones centralizada •Arquitectura descentralizada Con la arquitectura descentralizada, se elimina la dependencia con el radioenlance de tierra haciendo que la comunicación sea interactiva en tiempo real y eliminando, además, las restricciones de rango. En contraposición, su estructura y organización se vuelven más complejas. En la Figura 1.9 se observa dos formas de arquitectura descentralizada, con uno o varios conjuntos de drones. Figura 1.9 Arquitectura descentralizada con uno o varios grupos 1.2. Motivación proyecto OCONTSOLAR El sector de la energía, ha sido uno de los sectores en los que más aplicación comercial ha tenido el uso de drones debido a que las plantas de generación de energía suelen hacer un uso masivo de infraestructuras que son difíciles y costosas de monitorizar bajo metodos tradicionales. Es por ello, que sin importar el tipo de energía que se produzca o transporte, el uso de drones ha tenido una mayor penetración que en otros sectores. Algunos ejemplos de campos de la industria energética donde el uso de drones ha sido un exito son: • Inspección de parques eólicos Gracias al uso de los drones, se pueden comprobar en tan sólo unos minutos, a diferencia de las horas que tardarían unos operadores, las posibles incidencias que tengas las palas de los aerogenerados como se observa en la Figura 1.10. Con ello se consigue aumentar la vida útil de las instalaciones y aumentar su eficiencia a un precio menor. 1.2 Motivación proyecto OCONTSOLAR 7 Figura 1.10 Detección de fallas en las palas de aerogenerados con drones7 • Inspecciones de redes eléctricas La inspección de líneas eléctricas se realiza, antiguamente, a pie y en los últimos años con helicópteros. Con el uso de los drones como en la Figura 1.11, se ha conseguido reducir el coste de los operadores de inspección o el coste del combustible de los helicópteros, haciendo que las inspecciones sean más rápidas y menos peligrosas para dichos operadores. Figura 1.11 Inspección redes de alta y media tensión con drones8 • Inspecciones de refinerías o plataformas petrolíferas En este caso, las aplicaciones pueden, además de detectar posibles fallos en la estructura, analizar el aire alrededor de la estructura y detectar gases contaminantes. Para ello, una posible forma es realizar una termografía de la planta como refleja la Figura 1.12. Con ello se consigue además de abaratar costes, mejorar los procesos de inspección preventiva. 7Obtenida en https://elpais.com/retina/2018/03/14/tendencias/1521045717_028069.html 8Obtenida en https://www.rpalabs.es/curso-inspeccion-redes/ 8Capítulo 1. Introducción Figura 1.12 Termografía realizada por un dron de una refinería9 El objetivo del proyecto en el cuál este trabajo está enmarcado, llamado OCONTSOLAR, es el desarrollo de nuevos métodos de control para utilizar sensores montados en drones, formando un enjambre, en plantas de energía solar, con el fin de optimizar su funcionamiento utilizando estimaciones y predicciones de irradiación espacial. 1.3. Presentación de la solución La solución propuesta por este trabajo es el desarrollo e implementación de un sistema que incluye un enjambre de drones y un puesto de operador en tierra. Embarcados en los vehículos, irán los sensores de medición de la irradiancia y tomarán medidas que serán enviadas al enlace de tierra. Dichas medidas, serán integradas en algoritmos de control predictivos de modelos que conseguirán un funcionamiento más seguro y eficiente de las plantas. La idea es que el algoritmo de control (que para este trabajo se considerará una caja negra y cuyos datos se simularán), hace una petición de medición de la irrandiancia en varios puntos, que están predeterminados, y el sistema se organiza de tal manera que envía los drones a medir en dichos puntos. En el caso de haber menos drones que puntos a medir, el sistema se encarga de que el primero de los drones que quede libre después de la medición correspondiente, se dirija hacia el siguiente punto a medir. Para el desarrollo de este sistema se ha elegido, al azar, una planta solar de Almería. Dicha planta, que se puede observar en la Figura 1.13, en ningún caso tiene porqué corresponder con la planta dónde se realizarán las pruebas en el futuro próximo. En este punto, se va a hacer un inciso, explicando que el campo solar elegido es de tipo concentración. El uso de este sistema en este tipo de campos podría estar justificado en tareas de inspección. Para la integración del enjambre en el sistema de control, como es la finalidad del proyecto OCONTSOLAR, las plantas más adecuadas son aquellas de tipo cilindro parabólico como en la Figura 1.14. Ya que el trabajo se ha realizado con la planta de la Figura 1.13 y el tipo de planta no afecta al sistema desarrollado, la descripción del mismo será sobre ella, pero era necesario realizar esta puntualización. 9Obtenida en https://enterprise-insights.dji.com/es/experiencias/drone-mejora-resultados-inspecciones-de-refinerias 1.3 Presentación de la solución 9 Figura 1.13 Planta solar Figura 1.14 Planta solar de tipo cilindro parabólico10 La planta solar se ha dividido en dos zonas. Una zona de despegue y aterrizaje de los drones, y la zona de mediciones, donde estarán dichos robots autónomos cuando el sistema requiera de alguna medida (Figura 1.15). Esta última zona estará dividida en una serie de puntos que estarán predeterminados, los cuales han sido previamente estudiados por la idoneidad de su localización en cuánto a la medición que deseamos obtener del campo solar. 10Obtenida en https://solar-energia.net/energia-solar-termica/colector-solar-termico/colector-solar-concentracion 16 Capítulo 2. Descripción detallada del sistema respuesta se componen de mensajes de ROS. En la Figura 2.6 podemos ver éstos modos de comunicación que tienen los nodos. (a) Publicador - suscriptor (b) Servidor - cliente Figura 2.6 Modos de comunicación de los nodos Una de las características más importantes a la hora de ejecutar los nodos en ROS es la existencia de un nodo maestro llamado roscore. Su función es la de ayudar a los nodos a comunicarse entre ellos. 2.1.2.1. mavros Para la comunicación entre el protocolo MAVLink que usa el proyecto ArduPilot y la arquitectura de ROS existe un paquete llamado, mavros. Este paquete contiene una serie de tópicos y servicios, donde se pueden recibir los datos de telemetría del vehículo al que esté conectado y enviar comandos para la ejecución de las misiones. Se puede decir que es un traductor entre el formato de mensajes MAVLink visto en la Subsubsección 2.1.1.1 y los mensajes de ROS. 2.1.3. Protocol buffers El Protobuf (Protocol buffers) es un mecanismo para serializar datos estructurados desarrollado por Google. Es como eXtensible Markup Language (XML) pero tiene una serie de ventajas al ser más simple, ocupar menos espacio de memoria y este protocolo genera clases de acceso a datos para facilitar el uso en programación. Otra ventaja que tiene el uso de este protocolo es la variedad de lenguajes en los que se puede implementar. Los mensajes de este protocolo se definen en un fichero de extensión .proto que puede tener o la versión 2 (proto2) o la 3 (proto3). A continuación se muestra un ejemplo de un fichero .proto en la versión 3: Código 2.1 Ejemplo de fichero .proto "proto3"; message SearchRequest { string query = 1; int32 page_number = 2; int32 result_per_page = 3; } A los campos se les puede poner un norma delante llamada repeated y permite repetir ese campo cualquier número de veces. El orden de los valores repetidos es preservado. En la Tabla 2.1 podemos ver la correspondencia entre los valores del fichero .proto y los tipos de C++. Cuando se compila el fichero para el lenguaje C++, se generan dos archivos, una cabecera (.h) y un fichero fuente (.cc) con una clase para cada tipo de mensaje descrito en el fichero. 2.2 Arquitectura aire 17 Tabla 2.1 Correspondencia entre los tipos .proto y los tipos de C++ Tipo .proto Tipo C++ double double float float int32 int32 int64 int64 uint32 uint32 uint64 uint64 sint32 int32 sint64 int64 fixed32 uint32 fixed64 uint64 sfixed32 int32 sfixed64 int64 bool bool string string bytes string 2.2. Arquitectura aire En este apartado se va a describir los procesos que se ejecutan en el ordenador abordo de los vehículos. Como se a explicado anteriormente, la idea es lanzar un conjunto de vehículos por tanto, el sistema que se lanza en el aire es genérico y depende de un identificador que se le asigne a dicho vehículo. 2.2.1. Estructura En la Figura 2.7, se muestran los nodos que conforman el sistema en aire y su conexión. Figura 2.7 Arquitectura aire Entre ellos podemos encontrar: • Nodo de comunicación: este nodo es a través del cual se realiza la comunicación con el sistema. • Nodo administrador : conecta el nodo de comunicaciones con el resto de los nodos del sistema y se encarga de monitorizar el estado del vehículo. 18 Capítulo 2. Descripción detallada del sistema • Nodo de comandado: realiza el comandado de la misión a través de un protocolo. • Nodo de mavros: comunicación con el autopiloto del vehículo. • Nodo de medición : se utiliza este nodo para simular una medición de la irradiancia para poder simular completamente la misión del vehículo. 2.2.2. Comunicaciones Este paquete tiene dos funciones principales: utilizar el controlador del dispositivo (device driver) según se le indique y serializar/deserializar los mensajes definidos en protobuf y convertirlos a mensajes de ROS. Los mensajes que se utilizan en este sistema son: • vehicle_status : este mensaje describe el estado del vehículo y sus parámetros son: el identificador del vehículo, su posición GPS global con latitud, longitud y altitud respecto al terreno, la orientación, el porcentaje de batería y el modo, que puede ser MODE_WAITING (esperando a misión), MODE_ONROUTE (dirigiéndose al punto de medición) y MODE_MEASURING (midiendo). • vehicle_mission : misión comandada al vehículo, con el identificador del vehículo al cual la misión va dirigida, la latitud, longitud y altitud de la misión y el tipo, que puede ser: TYPE_MEASURE (misión medición), TYPE_LAND (misión aterriza) y TYPE_WAIT (espera a misión nueva). • measure : este mensaje contiene el identificador del vehículo que ha hecho la medición y el valor de la medida tomada. El fichero ocontsolar.proto (Código 2.2) describe los mensajes anteriores y define un mensaje llamado mMessage que contiene uno de esos mensajes. Este mensaje se utiliza con la opción oneof para averiguar el mensaje que me ha llegado, puesto que independientemente de la forma de comunicación utilizada, un mensaje llega en forma de vector de Bytes y es necesario saber de alguna forma cuál de los mensajes es, para poder deserializarlo correctamente. Código 2.2 Contenido ocontsolar.proto syntax = "proto3"; package OCONTSOLAR; message mMessage { header MessageHeader =1; oneof u{ vehicle_status vehicleStatus = 2; vehicle_mission vehicleMission = 3; measure measureData = 4; } } message header { uint32 MessageType = 1; } message vehicle_status { uint32 vehicleId = 1; double latitude = 2; double longitude = 3; double altitude = 4; double yaw = 5; double batteryPerc = 6; enum vehicleMode { MODE_WAITING = 0; MODE_ONROUTE = 1; MODE_MEASURING = 2; 2.2 Arquitectura aire 19 } vehicleMode mode = 7; } message vehicle_mission { uint32 vehicleId = 1; enum missionType { TYPE_MEASURE = 0; TYPE_LAND = 1; TYPE_WAIT = 2; } missionType type = 2; repeated double latitude = 3; repeated double longitude = 4; repeated double altitude = 5; } message measure { uint32 vehicleId = 1; double measure_data = 2; } Respecto al tipo de interfaz que se utiliza para la comunicación, se han usado sockets no orientados a conexión, UDP. La finalidad de este proyecto será el uso de módulos de Radio Frecuencia (RF) para la comunicación pero para facilitar la simulación se ha implementado con lo comentado. Por otro lado, otra de las características de este proyecto es la capacidad de comunicación punto-multipunto que tendrá cada vehículo formando así una malla de comunicación donde todos los vehículos se pueden conectar con todos los demás y con tierra. Para poder simular esta malla y que funcionase en local, es decir, lanzar N vehículos y un sistema de tierra en un mismo ordenador, se probó a enviar a una dirección local broadcast pero se encontró el problema de que al enviar a esa dirección (127.0.0.255), cuando uno de los nodos leía un mensaje, dicho mensaje no llegaba a los demás vehículos por lo que se optó por crear un nodo con un socket en una dirección Internet Protocol (IP) local y puerto fijo. La función de este nodo es guardar las direcciones de las cuales le llegan mensajes y reenviar el mensaje a todas las direcciones que tenga guardadas distintas a la dirección que le envía el mensaje. En el diagrama de flujo de la Figura 2.9 se describe el funcionamiento de este nodo. A continuación se presenta en la Figura 2.8 un ejemplo donde se ve el funcionamiento del nodo anterior. En este caso tenemos dos vehículos y el nodo de tierra. Éste último tiene asignado la dirección (127.0.0.200). Cuando el vehículo 2 envía un mensaje, el simulador de malla se encarga de reenviar ese mensaje tanto al vehículo 1 como al nodo de tierra. Figura 2.8 Ejemplo simulador malla 20 Capítulo 2. Descripción detallada del sistema Figura 2.9 Diagrama de flujo - Simulador malla Nos encontramos ahora con el siguiente problema; la división del canal para evitar la colisión de los paquetes en el envío. Esta división se ha hecho en tiempo (Time-division multiple access (TDMA)) y de forma fija, es decir se ha supuesto que como máximo habrá cinco nodos en el sistema. Como siempre ha de estar presente el nodo de tierra, el sistema queda capado a un máximo de cuatro vehículos. Para tener una idea de cómo van las comunicaciones, se ha decidido usar un periodo de 200 ms, que implica que un vehículo ha de enviar al menos 5 paquetes por segundo. Por tanto, de cada ciclo, queda un espacio de tiempo de 40 ms para cada nodo del sistema para poder enviar. El orden de envío se decide por el orden de los identificadores, quedando el nodo de tierra en última posición para el envío y la sincronización se realiza por reloj. Al inicio de cada segundo comienza un ciclo y cada 200 ms empieza otro como se puede apreciar en la Figura 2.10. 2.2 Arquitectura aire 21 Figura 2.10 División del canal en tiempo Con lo explicado, en la Figura 2.11 tenemos el diagrama de flujo principal del nodo de comunicaciones. Al inicio se calcula el slot al que pertenece el vehículo (o el nodo de tierra) y a partir de ahí se hace un bucle en el que se espera a que sea el tiempo que le toca a dicho vehículo a enviar y entonces, se lee lo que haya en el buffer y se envía aquellos mensajes que haya que enviar. Por último, se vuelve a calcular el nuevo tiempo de envío y se vuelve a esperar. Figura 2.11 Diagrama de flujo del nodo de comunicaciones 22 Capítulo 2. Descripción detallada del sistema 2.2.3. Controlador (administrador) del sistema en aire La función principal del controlador del sistema en aire (manager) es la de conformar el mensaje VehicleS- tatus.msg (Código 2.3). Los datos de telemetría los obtiene del nodo mavros y el modo en el que está el vehículo lo monitoriza según cómo ha ido el comandado de una misión. Código 2.3 VehicleStatus.msg #Mode types uint8 MODE_WAITING = 0 uint8 MODE_ONROUTE = 1 uint8 MODE_MEASURING = 2 std_msgs/Header header uint8 vehicle_id float32 gps_latitude float32 gps_longitude float32 rel_altitude float32 yaw float32 battery_perc uint8 mode 2.2.4. Comandado de misiones El nodo de comandado de misiones define un servicio llamado CommandMission.srv (Código 2.4) que tiene dos campos en la petición que son el estado actual del vehículo y la misión que debe de hacer. Como respuesta el servicio envía un booleano en caso de que la misión haya sido aceptada y el vector de waypoints enviados al autopiloto. Código 2.4 CommandMission.srv ocontsolar_msgs/VehicleStatus vehicle_status ocontsolar_msgs/VehicleMission vehicle_mission --- bool accepted mavros_msgs/Waypoint[] waypoints El mensaje VehicleMission.msg (Código 2.5) contiene el identificador del vehículo al cuál se le envía la misión, las coordenadas GPS (latitud, longitud) del punto de la misión, la altura sobre el terreno y el tipo de misión a realizar. Como se ha explicado anteriormente, hay tres tipos de misión: medir, aterrizar y esperar nueva misión. Código 2.5 VehicleMission.msg uint8 TYPE_MEASURE = 0 uint8 TYPE_LAND = 1 uint8 TYPE_WAIT = 2 std_msgs/Header header uint8 vehicle_id uint8 type float32[] gps_latitude float32[] gps_longitude float32[] rel_altitude En la Figura 2.12 se observa el diagrama de flujo del nodo de comunicaciones donde se puede observar que para cada tipo de misión se ha definido un protocolo diferente de actuación. 2.2 Arquitectura aire 23 Figura 2.12 Diagrama de flujo del nodo de misiones El protocolo de esperar es muy sencillo; simplemente se le hace una petición al autopiloto de cambio de modo de vuelo a LOITER (mantener localización, guiñada y altitud actuales). El protocolo de medir y de aterrizar son prácticamente iguales excepto un par de detalles. El último waypoint de la misión medir se comanda un loiter indefinido y en el protocolo de aterrizar se comanda un waypoint de aterrizaje. La otra diferencia es que al principio del protocolo de medición, siempre se envía un waypoint de despegue; esto permite que si estamos aterrizados despeguemos y en caso de estar ya volando, el autopiloto ignorará ese waypoint sin causar ningún fallo. En la Figura 2.13 podemos ver el diagrama de flujo del protocolo de misión de medición. Para solventar un posible problema de colisión entre los drones, los waypoints se han definido a distinta altura y en el proceso de envío de la misión al autopiloto, primero se comanda un waypoint en el mismo sitio donde está el vehículo (por esa razón viene en la petición el estado actual del vehículo) a la altura dónde se va realizar la misión. 24 Capítulo 2. Descripción detallada del sistema Figura 2.13 Diagrama de flujo - Envio mision 2.3. Arquitectura tierra A continuación se describen los procesos usados desde el sistema en tierra. 2.3.1. Estructura En la Figura 2.14 se muestra la arquitectura de tierra, la cual consta de dos nodos: el nodo de comunicación explicado dentro de la arquitectura de aire y un proceso que contiene la interfaz gráfica del sistema. 2.3 Arquitectura tierra 25 Figura 2.14 Arquitectura tierra 2.3.2. Interfaz g´ rafica La interfaz gráfica ha sido programada con las librerías de Qt en C++ y Qt Meta Language (QML), que es un lenguaje basado en JavaScript. El programa se compone principalmente de tres capas, una capa principal de donde salen dos, una capa de comunicaciones y una capa de datos como se observa en la Figura 2.15. Figura 2.15 Capas de la interfaz gráfica 2.3.2.1. Capa de comunicaciones Como se ha comentado en este documento, el proyecto se basa en la arquitectura ROS y para recibir la información del sistema la interfaz se ha de conectar a los tópicos del nodo de comunicación. Para ello la propia interfaz tiene que crear un nodo de ROS. Los nodos de ROS se han de crear cuando haya un roscore lanzado; para ello la capa de comunicaciones tiene un hilo de comprobación de la existencia o no del roscore, y en caso de existencia crear el nodo. En caso de desaparición esta capa desconecta el nodo creado. Todo esto queda reflejado en el diagrama de flujo de la Figura 2.16. 3. Simulaciones La mayoría de las personas gastan más tiempo y energía en rondar los problemas que en tratar de resolverlos. HENRY FORD Pa ra poder comprobar el funcionamiento del sistema sin tener que lanzar a mano cada uno de los procesos de los vehículos y de tierra, se ha creado una herramienta que realiza esta función. En este capítulo se va a explicar cómo se utiliza dicha herramienta y qué procesos lanza. 3.1. Herramienta simulación La herramienta simulación ha sido programada con las librerías de Qt y C++. La parte gráfica ha sido diseñada con el UI Design de Qt. Este programa comienza con una imagen del proyecto que se desvanece para dar paso a la ventada de parámetros. Esta imagen es la que se observa en la Figura 3.1. Figura 3.1 Interfaz de la herramienta de simulación En la Figura 3.2 aparecen los parámetros seleccionables por el usuario que son el número de vehículos que se quieren lanzar y si se quiere o no ejecutar la interfaz de tierra. Esto último se deja seleccionable por si se está depurando el sistema en aire y se quieren ver sólamente los nodos de los vehículos sin tener la interfaz gráfica abierta. 33 34 Capítulo 3. Simulaciones Figura 3.2 Parámetros de la herramienta simulación La primera vez que se lanza esta aplicación se abre directamente la ventana de configuración, la cuál se puede abrir en cualquier momento clickeando en Configuration... -> Open.... Esta ventana de configuración contiene las rutas que son necesarias definir para que la aplicación pueda lanzar los procesos. Figura 3.3 Ventana de configuración de las rutas Las rutas que hay que definir son: • Default data folder: esta carpeta es donde se van a guardar los datos que genera el SITL de cada avión. Por defecto la aplicación crea una carpeta SwarmSimulatorData en HOME. Dentro de esta carpeta se crearán tantas carpetas como vehículos se lancen con el nombre UAVx, donde x será el identificador del vehículo. • Ardupilot folder: aquí se indica la ruta a la carpeta ardupilot necesaria para el lanzamiento de los SITL. • ROS workspace: en esta tercera ruta se le indica al usuario que especifíque la ruta al devel del workspace donde tenga el código de ROS. • GCS Qt Path: cuando se compila la interfaz gráfica, se crea un directorio build de ese proyecto. Esa es la carpeta que hay que poner en esta ruta. Una vez que se han establecido estas cuatro rutas, se pulsa en Save que cierra dicha ventana. Como se ha comentado antes, para ejecutar la aplicación basta con elegir el número de vehículos y si queremos o no la parte de tierra. Cuando ésta se lanza, se crea un cuadro resumen con los directorios seleccionados, el número de vehículos y true/false si se ha elegido lanzar GCS, como se observa en la Figura 3.4. Además, se va indicando cuánto tiempo falta para empezar la simulación. 3.2 Procesos 35 Figura 3.4 Cuadro resumen de la simulación En cualquier momento el usuario puede decidir acabar con la simulación y lo único que ha de hacer es pulsar en Stop Simulation. Esto matará los hilos de los procesos e indicará al usuario que ha terminado la simulación. En la Figura 3.5 se puede ver el cuadro resumen de la simulación tras pulsar el botón de parar. Figura 3.5 Fin de la simulación 3.2. Procesos Según los parámetros seleccionados en la ventana principal se crearán una serie de hilos que contendrán los procesos necesarios para el funcionamiento del sistema. Por cada vehículo se lanza un simulador (SITL) y un fichero launch de ROS con todos los nodos explicados en el capítulo anterior. Para la parte de tierra se ejecuta un nodo de comunicaciones y la interfaz gráfica. En la Figura 3.6 se observan los procesos lanzados en una simulación de un sólo vehículo. Cada proceso se lanza en una terminal y se cambia el título de cada terminal para poder diferenciar unas de otras. Se lanza además un roscore aparte para evitar que si muere algún proceso y éste contenía el core de ROS, no se caiga todo el sistema. 36 Capítulo 3. Simulaciones Figura 3.6 Procesos 3.2.1. Simulador vehículo Para lanzar el simulador del vehículo necesitamos, como hemos dicho antes, la ruta al directorio de ardupilot. El simulador utiliza una posición GPS para iniciar el vehículo en dicha posición. Esa información está guardada en un fichero llamado locations.txt. Código 3.1 Comando del simulador del vehículo 1 export PATH=$PATH:/home/jenny-ros/Libraries/ardupilot/Tools/autotest && sim_vehicle.py -I 1 -v ArduCopter -L OCONTSOLAR1 En el Código 3.1 se puede observar que cuando se lanza el simulador hay una opción, -I, que lleva un número detrás. Ese número es el identificador del vehículo y está relacionado con el puerto que crea el SITL a través del cuál se tendrá que conectar otro socket para enviar o recibir información en la IP local (127.0.0.1). El puerto que se crea según el parámetro anterior es: puerto =14550+10·id. 3.2.2. Nodo vehículo Para lanzar todos los nodos de aire en un sólo fichero se ha creado un launch llamado ocontsolar_vehicle.launch . Este fichero, cuyo contenido podemos observar en el Código 3.2, tiene un parámetro de entrada que es el identificador del vehículo. Con ese parámetro se calcula el puerto al que irá conectado mavros para comunicarse con el simulador de ese vehículo. Código 3.2 Contenido ocontsolar_vehicle.launch <launch> <arg name="vehicle_id" default="1"/> <arg name="port" value="$(eval 14550 + 10 * arg(’vehicle_id’))"/> <param name="mavros_port" value="$(arg port)"/> <group ns="UAV$(arg vehicle_id)" > <arg name="fcu_url" default="udp://127.0.0.1:$(arg port)@" /> <arg name="gcs_url" default="" /> <arg name="tgt_system" default="1" /> <arg name="tgt_component" default="1" /> <arg name="system_id" default="255" /> <arg name="log_output" default="log" /> <arg name="fcu_protocol" default="v2.0" /> <arg name="respawn_mavros" default="false" /> 3.2 Procesos 37 <include file="$(find mavros)/launch/node.launch"> <arg name="pluginlists_yaml" value="$(find mavros)/launch/ px4_pluginlists.yaml" /> <arg name="config_yaml" value="$(find mavros)/launch/px4_config. yaml" /> <arg name="fcu_url" value="$(arg fcu_url)" /> <arg name="gcs_url" value="$(arg gcs_url)" /> <arg name="tgt_system" value="$(arg tgt_system)" /> <arg name="tgt_component" value="$(arg tgt_component)" /> <arg name="log_output" value="$(arg log_output)" /> <arg name="fcu_protocol" value="$(arg fcu_protocol)" /> <arg name="respawn_mavros" default="$(arg respawn_mavros)" /> </include> <node pkg="manager" type="manager_node" name="manager" output="screen" > <param name="vehicle_id" value="$(arg vehicle_id)" type="int" /> </node> <node pkg="measure" type="measure_node" name="measure" output="screen"/> <node pkg="comms" type="comms_node" name="comms" output="screen"> <param name="vehicle_id" value="$(arg vehicle_id)" type="int" /> </node> <node pkg="command" type="command_node" name="command" output="screen"> <param name="vehicle_id" value="$(arg vehicle_id)" type="int" /> </node> </group> </launch> Para lanzar por tanto el nodo del vehículo, se ejecuta el Código 3.3 con el vehicle_id al que corresponda. Código 3.3 Comando del proceso del vehículo 1 source /opt/ros/kinetic/setup.bash && source /home/jenny-ros/ocontsolar_ws/devel/setup.bash && roslaunch ocontsolar_common ocontsolar_vehicle.launch vehicle_id:=1 3.2.3. Nodo de tierra En el Código 3.4 se muestra la parte de tierra cuyo fichero es ocontsolar_ground.launch . Además de lanzarse el nodo de comunicaciones de tierra, se lanza también el simulador de malla explicado en el punto 2.2.2 de este documento. Código 3.4 Contenido ocontsolar_ground.launch <launch> <arg name="vehicle_id" /> <node pkg="comms" type="comms_node" name="comms" output="screen"> <param name="vehicle_id" value="$(arg vehicle_id)" type="int" /> </node> <node pkg="comms" type="multipoint_faker" name="multipoint_faker" output="log" /> 38 Capítulo 3. Simulaciones </launch> Este fichero necesita un parámetro de entrada que será el identificador de tierra, que en este sistema está definido como el 200 como se ve en el Código 3.5. Código 3.5 Comando del proceso de los nodos de tierra source /opt/ros/kinetic/setup.bash && source /home/jenny-ros/ocontsolar_ws/devel/setup.bash && roslaunch ocontsolar_common ocontsolar_ground.launch vehicle_id:=200 3.2.4. Interfaz gráfica Para lanzar la interfaz gráfica se cambia de directorio en la terminal que va a lanzar el proceso al build del proyecto y se ejecuta el ejecutable creado, que se llama OcontSolarApp. 3.3. Funcionamiento En la Figura 3.7 se muestra una simulación con cuatro vehículos. Las posiciones iniciales que toman estos vehículos, definidas en el fichero locations.txt, son aleatorias. Figura 3.7 Simulación cuatro vehículos Como todavía no se ha indicado los puntos donde se quieren recibir las mediciones, los vehículos se encuentran en el estado WAITING. El siguiente paso es enviar la petición de medida de los puntos que viene de un algoritmo que predice el movimiento de las nubes. Este dato se tiene que simular también. Para ello se publica un mensaje en el tópico mission, que es del tipo std_msgs/UInt64MultiArray. Los campos que contiene este mensaje se pueden ver en la Figura 3.8, donde el que se va a utilizar es data que va a contener los identificadores de los puntos a medir. [6] 3.3 Funcionamiento 39 Figura 3.8 Campos del mensaje std_msgs/UInt64MultiArray Exiten dos posibilidades; la primera es publicarlo en una terminal y la segunda, abrir un programa llamado rqt y utilizar el plugin de Message Publisher. Para esta simulación se ha optado por utilizar el segundo método. Figura 3.9 Envío de los waypoints a medir En la Figura 3.9 se ha incluido el tópico comentado antes y se ha rellenado con tres puntos, el 1, 2 y el 3. Para publicar el mensaje, basta con hacer click derecho sobre el nombre y Publich Selected Once. Esto publica un mensaje que lo recibe la interfaz y en caso de no estar realizando ya una misión, comienza la misión. Se puede observar cómo en la Figura 3.10 los vehículos 1, 2 y 3 han sido seleccionados para ir a los puntos a medir y han cambiado su estado a ONROUTE. 40 Capítulo 3. Simulaciones Figura 3.10 Vehículos seleccionados para medir en estado ONROUTE Con objecto de evitar posibles colisiones los vehículos realizan trayectorias a distintas alturas, tomando primero la altura deseada y posteriormente dirigiéndose al punto correspondiente. En la Figura 3.11, el vehículo 1 realiza la misión a una altura de unos 50 metros sobre el terreno mientras que los vehículos 2 y 3 a 40 y a 60 metros respectivamente. Figura 3.11 Rutas a distintas alturas En el momento en el que un vehículo alcanza el punto de medición, mantiene la posición y comienza a tomar medidas. En ese momento pasa al estado MEASURING como podemos ver en el vehículo 1 de la Figura 3.12. 3.3 Funcionamiento 41 Figura 3.12 Vehículo 1 tomando mediciones Cuando el vehículo termina la medición, pasa a estado WAITING a la espera de recibir una nueva misión. Mientras que los demás vehículos no hayan terminado de hacer las mediciones, la estación de tierra no va a comenzar la misión de aterrizaje con el objetivo de tener a un vehículo de "repuesto" por si ocurriese alguna emergencia en los vehículos que están tomando medidas. En la Figura 3.13 se observa que el vehículo 1 se ha quedado en su posición y con estado WAITING aún incluso cuando los vehículos 2 y 3 no han empezado la medición. Figura 3.13 Vehículo 1 esperando a nueva misión Al llegar a sus respectivos puntos, los vehículos 2 y 3 comienzan a tomar medidas como se ve en la Figura 3.14. 48 Capítulo 4. Conclusiones y trabajo futuro 3. Decidir el equipo que se va a utilizar en la parte de tierra teniendo en cuenta los requisitos del software desarrollado. 4. Modificar los datos de la localización puesto que como se comentó en el Capítulo 1 la que se utiliza en este proyecto ha sido elegida al azar. 5. Probar el sistema con un vehículo y corregir errores. 6. Probar el sistema con un enjambre de drones y volver a corregir errores. Como método para evitar colisiones, actualmente lo que se ha definido ha sido el enviar a los vehículos a distinta altura pero esto hace que el sistema sea más lento. Una posible mejora es utilizar la información que llega de los otros nodos para que se eviten entre ellos de una manera dinámica. Asimismo, si se empezase a usar la información que se obtiene de los otros vehículos, se podría implementar una capa de decisión dentro del sistema de aire dónde los vehículos se pusieran de acuerdo entre ellos para determinar cuál de ellos va a medir a qué punto según criterios de distancia, batería, etc. Es decir, dotar a los vehículos de cierta inteligencia. Índice de Figuras 1.1 Ataque de las tropas austríacas con globos incendiarios 1 1.2 Aeronave Fairey Queen 2 1.3 Radioplano OQ2 2 1.4 Quadcóptero 3 1.5 Hexacóptero 4 1.6 Octacóptero 4 1.7 Dron de ala fija 5 1.8 Arquitectura de comunicaciones centralizada 6 1.9 Arquitectura descentralizada con uno o varios grupos 6 1.10 Detección de fallas en las palas de aerogenerados con drones 7 1.11 Inspección redes de alta y media tensión con drones 7 1.12 Termografía realizada por un dron de una refinería 8 1.13 Planta solar 9 1.14 Planta solar de tipo cilindro parabólico 9 1.15 Zonas de la planta solar 10 1.16 Ejemplo del sistema definido 10 2.1 Logo de ArduPilot 13 2.2 Quadrotor - (CW - clockwise | CCW - counterclockwise) 14 2.3 Formato de los mensajes MAVLink 14 2.4 Arquitectura SITL 15 2.5 Logo Robot Operating System (ROS) 15 2.6 Modos de comunicación de los nodos 16 2.7 Arquitectura aire 17 2.8 Ejemplo simulador malla 19 2.9 Diagrama de flujo - Simulador malla 20 2.10 División del canal en tiempo 21 2.11 Diagrama de flujo del nodo de comunicaciones 21 2.12 Diagrama de flujo del nodo de misiones 23 2.13 Diagrama de flujo - Envio mision 24 2.14 Arquitectura tierra 25 2.15 Capas de la interfaz gráfica 25 2.16 Hilo de comunicaciones 26 2.17 Base de datos - Waypoints a medir 27 2.18 Mapa con plugin Mapbox GL 27 2.19 Estado del vehículo en interfaz gráfica 28 2.20 Detalle estado del vehículo 28 2.21 Función recepción estado del vehículo 29 2.22 Detalle estado del vehículo 30 3.1 Interfaz de la herramienta de simulación 33 49 50 Índice de Figuras 3.2 Parámetros de la herramienta simulación 34 3.3 Ventana de configuración de las rutas 34 3.4 Cuadro resumen de la simulación 35 3.5 Fin de la simulación 35 3.6 Procesos 36 3.7 Simulación cuatro vehículos 38 3.8 Campos del mensaje std_msgs/UInt64MultiArray 39 3.9 Envío de los waypoints a medir 39 3.10 Vehículos seleccionados para medir en estado ONROUTE 40 3.11 Rutas a distintas alturas 40 3.12 Vehículo 1 tomando mediciones 41 3.13 Vehículo 1 esperando a nueva misión 41 3.14 Vehículos 2 y 3 tomando mediciones en sus respectivos puntos a medir 42 3.15 Misión terminada - Vehículos a la espera de nueva misión 42 3.16 Vuelta al punto de despegue a diferente altura 43 3.17 Número de puntos a medir superior al número de vehículos disponibles 43 3.18 Vehículo 1 comandado a nueva misón 44 3.19 Nueva misión de medición para los vehículos 2 y 3 44 3.20 Vuelta a casa tras misión realizada 45 Bibliografía [1] Wikipedia. History of unmanned aerial vehicles. https://en.wikipedia.org/wiki/History_of_unmanned_ aerial_vehicles, Abril 2021. Accessed on 2021-04-15. [2] ADSL Zone. Todos los tipos de drones según el uso, diseño o control. https://www.adslzone.net/ reportajes/drones/tipos-drones/, Febrero 2021. Accessed on 2021-04-09. [3] droneymas. Tipos de drone en el mercado. https://www.droneymas.com/tipos-de-drone/. Accessed on 2021-04-09. [4] Manlio Bacco, Stefano Chessa, Marco Benedetto, Davide Fabbri, Michele Girolami, Alberto Gotta, Davide Moroni, Maria Pascali, and Vincenzo Pellegrini. Uavs and uav swarms for civilian applications: Communications and image processing in the sciadro project. 3 2018. [5] Xi Chen, Jun Tang, and Songyang Lao. Review of unmanned aerial vehicle swarm communication architectures and routing protocols. Applied Sciences, 10:3661, 05 2020. [6] ROS. std_msgs/uint64multiarray message, Feb 2020. [7] EE Times. Nasa drone’s sensors help battle california wildfires. https://www.eetimes.com/nasa-drones- sensors-help-battle-california-wildfires/, Julio 2015. Accessed on 2021-03-30. 51 Índice de Códigos 2.1 Ejemplo de fichero .proto 16 2.2 Contenido ocontsolar.proto 18 2.3 VehicleStatus.msg 22 2.4 CommandMission.srv 22 2.5 VehicleMission.msg 22 3.1 Comando del simulador del vehículo 1 36 3.2 Contenido ocontsolar_vehicle.launch 36 3.3 Comando del proceso del vehículo 1 37 3.4 Contenido ocontsolar_ground.launch 37 3.5 Comando del proceso de los nodos de tierra 38 53 Glosario FDM Flight Dynamics Model. 13 GPL General Public License. 11 GPS Global Positioning System. 12, 16, 21, 26 IP Internet Protocol. 17 LOS Line-Of-Sight. 45 QML Qt Meta Language. 24 RF Radio Frecuencia. 17 ROS Robot Operating System. IX, 13, 14, 16, 47 SITL Software In The Loop. 13 TCP Transmission Control Protocol. 13 TDMA Time-division multiple access. 19 UAVs Unmanned Aerial Vehicles. VII, IX, 1, 3, 5 UDP User Datagram Protocol. 13, 17 XML eXtensible Markup Language. 14 55