Sistema de navegación de robot aéreo y visualización en la estación en tierra

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 Grado Grado en Ingeniería Electrónica, Robótica y Mecatrónica Sistema de navegación de robot aéreo y visualización en la estación en tierra Autor: Joaquín Borrego Villa Tutor: Aníbal Ollero Baturone Dpto. Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 Trabajo Fin de Grado Grado en Ingeniería Electrónica, Robótica y Mecatrónica Sistema de navegación de robot aéreo y visualización en la estación en tierra Autor: Joaquín Borrego Villa Tutor: Aníbal Ollero Baturone Catedrático de Universidad Dpto. Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 Trabajo Fin de Grado: Sistema de navegación de robot aéreo y visualización en la estación en tierra Autor: Joaquín Borrego Villa Tutor: Aníbal Ollero Baturone 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 agradecer en primer lugar a todos los compañeros que han pasado durante estos años de universidad, por su atención, su ayuda y sobre todo, los buenos momentos que hemos pasado. Sin ellos esto no hubiera sido posible. También me gustaría dar las gracias a mi familia por la oportunidad que me dieron al poder estudiar esta carrera, ellos me enseñaron el esfuerzo y sacrificio que hay que dedicarle a cualquier cosa en la vida. A FADA-CATEC por la oportunidad que me brindaron para desarrollar este trabajo con ellos y sobre todo a Marco, por la amabilidad y la paciencia que tuvo para guiarme cuando le pedí ayuda. Joaquín Borrego Villa Sevilla, 2021 I Índice Abreviado Índice Abreviado III Notación VII 1 Introducción 1 1.1 Motivación 1 1.2 Objetivos del proyecto 4 2 Descripción Software 7 2.1 ¿Por qué ROS? 7 2.2 RViz 9 2.3 Qt 10 2.4 CMake 12 3 Desarrollo Software 15 3.1 Preámbulo 15 3.2 Arquitectura Software 17 3.3 Modelo de datos 18 3.4 Core 18 3.5 Comunicaciones 19 3.6 Visualizador 3D 25 3.7 Interfaz gráfica 33 4 Experimentos con UAV real 47 5 Conclusiones y posibles líneas futuras 51 Índice de Figuras 53 Índice de Tablas 55 Índice de Códigos 57 Bibliografía 59 III 2Capítulo 1. Introducción •Fotogrametría: Se encarga de obtener planos y mapas tridimensionales en grandes extensiones de terreno utilizando algoritmos de fotografía aérea. La aplicación principal es la cartografía. Figura 1.2 Mapa de un vecindario construido a partir de fotogrametría. Fuente: jonhassall.com. •Detección de incendios: En los últimos años parques de bomberos han requerido de la formación de especialistas para el uso de drones en reconocimiento de focos de calor. Un UAV es capaz de recorrer en poco tiempo una extensa área de terreno y gracias a las cámaras térmicas reconocer focos de calor. Figura 1.3 Monitorización y medición de focos de calor con UAVs. Fuente: CATEC. •Recuento en inventario en almacenes: Debido al desarrollo de empresas de venta on-line que requieren del almacenamiento de grandes cantidades de productos, es necesario llevar a cabo el recuento de estos productos de una manera sencilla y rápida. Para llevar a cabo 1.1 Motivación 3 este cometido se pueden utilizar UAVs, que equipados con lectores de códigos de barras, son capaces de hacer un recuento de los productos que hay en un almacén. Como en el último ejemplo expuesto, existen situaciones en las que el uso de sensores como el GPS no están disponibles para llevar a cabo la localización de la aeronave. Es necesario por tanto lograr navegar por el entorno de manera autónoma (control + localización) mediante sensores visuales como cámaras, aunque en los últimos años ha aparecido una nueva tecnología conocida como LiDAR que ayuda a esta tarea. Esta tecnología se basa en la emisión de un láser con distintas longitudes de onda que es reflejado en el terreno y reconocido de nuevo por este dispositivo. Además permite representar algo parecido a un mapa pero usando nubes de puntos y así elaborar modelos digitales del terreno en alta resolución. Figura 1.4 LIDAR Ouster OS0. Fuente: ouster.com. El LiDAR es también útil para la cartografía de lineas eléctricas, vías ferroviarias, tuberías o incluso zonas de inundación. El auge que han tenido el uso de los UAV en todas estas aplicaciones, ha hecho que se desarrollen en torno a ellos herramientas capaces de facilitar su uso, ya que de esta manera este tipo de tecnología podría estar al alcance de más personas y ampliar así el mercado de los vehículos aéreos. En este contexto nacen las estaciones de control en tierra o como se conocen por sus siglas en ingles GCS (Ground Control Station), esta estación constituye un conjunto de sistemas encargados de controlar el UAV. Estos sistemas pueden estar compuestos por : interfaces humano-máquinas, telemetría, captura de vídeo a bordo del UAV, y alarmas durante el vuelo. En primera instancia se usaban exclusivamente en ámbitos armamentísticos y esta GCS básicamente era una habitación en la que varios operarios recibían todos estos datos del UAV y los usaban para controlar la aeronave. 4Capítulo 1. Introducción Figura 1.5 Interior de la GCS Bayrkatar TB2. Fuente: wikipedia.org. Poco a poco se fueron desarrollando GCSs que eran portables y que estaban fuera del mundo armamentístico, de esta manera se podían desplegar en cualquier momento y lugar los medios necesarios para llevar a cabo el vuelo de un UAV. Figura 1.6 Worthington Sharpe Wing GCS. Fuente: worthingtonsharpe. En los últimos años han ido apareciendo GCSs específicas para la realización de tares de mantenimiento e inspección de manera autónoma. Este proyecto pretende desarrollar una GCS para un UAV DJI Matrice 600, que sea fácil e intuitiva de usar y de esta manera permitir que un operario pueda controlar el vuelo de un UAV. 1.2 Objetivos del proyecto Para poder llevar a cabo cualquier tipo de proyecto hay que definir cuáles son los objetivos que se quieren conseguir con la realización de este. A continuación se enumeran : 1.2 Objetivos del proyecto 5 1. Llevar a cabo un estudio sobre cuáles son los datos críticos que se deben recibir del UAV para su correcta visualización. Esto se denomina telemetría y permite la medición remota de magnitudes físicas y el posterior envío de la información hacia el operador del sistema1. 2. Definir las interfaces de comunicación con la aeronave, es decir, cómo van a interactuar la GCS con el UAV. 3. Implementación de la interfaz: a) Realizar un diseño de el aspecto de la GCS y cómo van a estar distribuidos los diferentes widgets en ella. b) Definir las acciones necesarias que la GCS debe poder enviar al UAV usando elementos interactivos. 4. Validación de la interfaz mediante simulaciones y pruebas de vuelo real. 1Fuente: wikipedia.org 2 Descripción Software En este capítulo se va a describir cuáles son los distintos componentes software que se han utilizado para el desarrollo de este proyecto, cúales son las opciones que nos ofrece cada uno de ellos y cómo se han de modificar para conseguir los objetivos que se han planteado en la Sección 1.2 para el correcto funcionamiento de este sistema. El trabajo de un ingeniero no solo consiste en ser ser capaz de desarrollar aquellas herramientas que crea necesarias para llevar a cabo un objetivo concreto, si no que también tiene que ser capaz de utilizar otras herramientas que le faciliten y agilicen la tarea, siendo capaz de modificarlas para obtener los resultados esperados. Los apartados que se desarrollarán a continuación corresponden a aquellas herramientas que han facilitado la realización de esta tarea y que han aportado un conocimiento necesario para la funcionalidad del sistema. Tras un estudio de las diferentes herramientas disponibles para conseguir la funcionalidad necesaria, se ha decidido utilizar Robot Operating System[ 2 ] (ROS) como medio de comunicación con el UAV, Ros Visualizer[ 3 ] (RViz) como modelo de visualización del entorno y Qt[ 4 ] como framework para el desarrollo de la interfaz gráfica. 2.1 ¿Por qué ROS? ROS es un framework usado para el desarrollo de software para robots que provee la funcionalidad de un sistema operativo en un clúster heterogéneo 1 . Se desarrolló originalmente en 2007 por el Laboratorio de Inteligencia Artificial de Stanford para dar soporte a su proyecto STAIR[ 5 ]. Hoy en día es un proyecto en el que colaboran unas 20 instituciones bajo términos de licencia BSD, es decir que existe una libertad de uso tanto comercial como de investigación. Figura 2.1 Logotipo de ROS. Fuente: es.wikipedia.org . ROS ha sido diseñada y pensada para su uso en código abierto por lo que ofrece un conjunto de paquetes que han sido aportados gracias a la contribución de usuarios y que están organizados 1es.wikipedia.org 7 8Capítulo 2. Descripción Software en conjuntos de pilas o stacks que implementan diferentes funcionalidades. Algunas de estas funcionalidades son : •Abstracción del hardware. •Paso de mensajes entre procesos. •Identificación de objetos. •Seguimiento de objetos. •Segmentación y reconocimiento. 2.1.1 Conceptos básicos sobre ROS Es necesario conocer la terminología 2 propia de ROS debido a que en capítulos siguientes se van a utilizar estos términos y hay que dejar claro su significado para la comprensión de este documento. •Nodos : Los nodos son procesos que llevan a cabo una función concreta y que se ejecutan individualmente unos de otros y son gestionados por un nodo principal concocido como ROS MASTER. Para comunicarse entre nodos se envían mensajes a través de unos canales de información que se conocen como tópicos. •Mensajes: Son estructuras de datos compuestos por diferentes tipos de datos como enteros, flotantes o estructuras. Código 2.1 Ejemplo de mensaje sensor_msgs/Temperature.msg. # Single temperature reading. Header header # timestamp is the time the temperature was measured # frame_id is the location of the temperature reading float64 temperature # Measurement of the Temperature in Degrees Celsius float64 variance # 0 is interpreted as variance unknown •Tópicos: Son los canales de información por los que se transmiten los mensajes. Los nodos pueden publicar/suscribirse a un tópico determinado para conseguir un tipo de dato. Varios nodos pueden publicar/suscribirse a un mismo tópico. •Servicios: Los servicios son otro método de información pero en este caso se utiliza la arquitectura cliente/servidor y se utiliza un tipo de mensaje con dos partes: la primera para la solicitud del dato y la segunda para la respuesta. •Bags: Los bags son un formato para grabar y reproducir los mensajes de ROS. Este formato es el perfecto para llevar a cabo la simulación de un vuelo de un UAV y de esa manera reproducir los datos emitidos por este. 2Fuente: es.wikipedia.org 2.2 RViz 9 2.2 RViz RViz es una herramienta de visualización 3D para aplicaciones de ROS.Permite la visualización de diferentes modelos de robots, de datos capturados por sensores del robot, de imágenes de cámaras, lasers y un largo etcétera que hace de esta herramienta la perfecta para trabajar con robots móviles en entornos con condiciones desconocidas y/o adversas3. Figura 2.2 Logotipo de RViz. Fuente: github.com . RViz ofrece diversas formas y estilos de representación de datos, para ello se utilizan los displays que son objetos que se renderizan en el visualizador 3D y ofrece una lista de opciones de representación. 2.2.1 Displays En este apartado se mostrarán algunos ejemplos de displays que la librería de RViz ofrece, de esta manera se comprenderá la utilidad que tiene el uso de este framework para el desarrollo de este trabajo. Tabla 2.1 Ejemplos de displays. Fuente: wiki.ros.org/rviz/DisplayTypes . Nombre Descripción Imagen Axes Representa un conjunto de ejes Grid Representa una malla de líneas centrada en el origen Point Representa un punto 3Fuente: wiki.ros.org/rviz 10 Capítulo 2. Descripción Software Robot Model Representa un modelo de robot definido por un archivo URDF4 Point Cloud Nube de puntos de mensaje tipo : sensor_msgs/PointCloud2 Se observa que existen muchas opciones a la hora de representar datos en RViz, esto será muy útil a la hora de la correcta comprensión del entorno para el usuario. 2.2.2 Tipos de Cámara Además RViz ofrece diversos tipos de cámara para la visualización del entorno, cada una de ellas con una lista de opciones configurable. Estos tipos de cámara se describen en la Tabla 2.2 Tabla 2.2 Tipos de cámaras. Fuente: wiki.ros.org/rviz/UserGuide . Nombre Descripción Orbital Camera Esta cámara rota entorno a un punto focal, a la vez que siempre está observándolo. First Person Camera Rota como si estuviera en primera persona Top-Down Orthographic Se mueve a lo largo del eje Z. Camera XY Orbit Camera Igual que Orbital Camera pero el punto focal está restringido al plano XY Third Person Follower Mantiene un ángulo constante con el frame fijado Con todo esto comentado acerca de RViz se puede conocer el gran potencial que tiene esta herramienta para alcanzar los objetivos que tiene este proyecto en cuanto a la visualización 3D y 2D se refiere. 2.3 Qt Qt es un framework multiplataforma orientado a objetos ampliamante usado para desarrollar programas que utilicen interfaz gráfica de usuario, asi como para la línea de comandos5. Qt es desarrollada como un software libre y de código abierto donde participa tanto la comunidad como desarrolladores de Nokia, Digia y otras empresas 6 . Esta herramienta no es un lenguaje de programación por sí mismo, si no que es un framework escrito en C++. 4Este tipo de formato describe los elementos de un robot y las distintas relaciones entre ellos. 5Fuente: qt.io 6Fuente: es.wikipedia.org 2.3 Qt 11 . Figura 2.3 La interfaz de Spotify está diseñada con Qt. Fuente: community.spotify.com . Además este framework también proporciona su propia herramienta de desarrollo (IDE) conocida como Qt Creator y es soportada por Linux, Android, Windows, OS X y demás sistemas operativos. Considerando que esta librería está basada en C ++ es de esperar que Qt esté orientada a objetos y que sea fácilmente extensible y modular. Aunque no es necesario el uso de este IDE tiene algunas ventajas sobre otros IDE, que no son propios de Qt: •Catálogo de ayuda en línea. •Resaltado de sintaxis. •Autocompletado de código. •Control de versiones integrado. . Figura 2.4 Apariencia Qt Creator. Fuente: doc.qt.io . 18 Capítulo 3. Desarrollo Software de datos queda desacoplado de los módulos superiores gracias al core. 3.3 Modelo de datos Este módulo es el responsable de almacenar toda la información manejada por la GCS. Se utiliza el objeto de transferencia de datos (DTO) cómo objeto básico para mover la información entre los diferentes módulos de nuestra GCS. Cada DTO tiene una serie de atributos que pueden ser enviados o recibidos por cada módulo de la GCS en una sola invocación, de esta forma encapsulamos diferentes tipos de datos en uno solo. Los DTOs que componen nuestro modelo de datos se muestran en la Figura 3.2. Figura 3.2 DTOs que componen el modelo de datos. Cada uno de estos DTOs tiene un significado y una serie de atributos que se explicarán en la Tabla 3.3 Tabla 3.3 DTOs que componen el modelo de datos . DTO Explicación ApplicationStatusDTO Representa alguno de los estados de la aplicación mencionados en la Tabla 3.2 CommsStatusDTO Representa si la aplicación está conectada al UAV o no CurrentWaypointDTO Representa el identificador de waypoint de la ruta cargada al que el UAV está yendo FlightStatusDTO Representa alguno de los estados de vuelo del UAV mencionados en la Tabla 3.1 EditionModeDTO La aplicación está en modo edición de misiones o en modo vuelo RouteOptionsDTO Contiene información sobre qué rutas deben estar visibles o no MeasureDTO Contiene, o no, los puntos de medida de distancia del visualizador MissionDTO Contiene toda la información necesaria de la misión como: la ruta cargada, las distintas rutas locales, el nombre de la misión, el punto de despegue/aterrizaje ... MissionStatusDTO Representa el estado de la misión (no hay misión cargada, tiene cambios o está guardada) 3.4 Core Como su propio nombre indica, el core es el núcleo en la estructura de la GCS, es el encargado de llevar a cabo las modificaciones en el modelo de datos que los demás módulos le solicitan usando las diferentes acciones disponibles y se encarga también de notificar a los diferentes módulos que lo necesitan la modificación de estos datos para que actúen en consecuencia. 3.5 Comunicaciones 19 Para poder llevar a cabo estas modificaciones se utilizan unas acciones que se han predefinido en este módulo, estas acciones pueden llevar o no asociado un DTO que indique de qué manera la acción modifica al datamodel. Además para cada acción puede existir una capa de business que englobe alguna funcionalidad que se use en varias acciones. Existe una lista de las diferentes acciones que se pueden realizar, cada una de estas acciones tiene una clase propia de asociada de C++ que se crea a través del manager. Se ha decidido que la mejor manera de detallar estas acciones, sea exponiendo en cada módulo las acciones que solicita al core con su DTO asociado, así como explicar para cada módulo cuales son las modificaciones del modelo de datos de las que debe estar al tanto. 3.5 Comunicaciones El módulo de comunicaciones (Comms) es el encargado de comunicarse con el UAV, para poder recibir datos de la aeronave y también para mandarle comandos de vuelo a tiempo real, la relación señal-slot se muestra en la Figura 3.3, se observa que es el módulo de comunicaciones el que se conecta con el core solicitando a este cambios en el modelo de datos a través del envío de acciones con ayuda de la señal sendDTOToCore, en ningún caso el core se comunicará con las comunicaciones ya que no tiene que avisar a este de que el modelo de datos ha cambiado. Como se comentó anteriormente se ha elegido ROS como modelo de comunicaciones con el UAV, el módulo Comms se encarga de gestionar los distintos subscriptores a los diferentes tópicos que el UAV nos ofrece así como los diferentes servicios que esta aeronave ofrece. Estos servicios y tópicos están definidos por el paquete que ofrece la propia compañía DJI para sus UAV (DJI Onboard SDK ROS 4.1.0) [8] así como los que se definen en un paquete de ROS que se ha creado en específico para este proyecto que se conoce como trajectory_planner. Algunos de los tópicos y servicios de este paquete se muestran en la Tabla 3.4. Figura 3.3 Comunicación comss-core. Tabla 3.4 Ejemplos de tópicos y servicios que ofrece DJI OSDK ROS. Nodos Nombre Tópicos Nombre Servicios telemetry_node dji_osdk_ros/attitude dji_osdk_ros/battery_state dji_osdk_ros/imu mission_node dji_osdk_ros/mission_waypoint_upload dji_osdk_ros/mission_waypoint_action dji_osdk_ros/mission_waypoint_setSpeed flight_control_node set_go_home_altitude get_go_home_altitude 3.5.1 Trajectory planner Es el paquete de ROS que sirve como máquina de estados entre los diferentes estados de vuelo del UAV y en el que se definen los tópicos, servicios y transformadas que se usarán tanto para el control de la misión de la aeronave como para la visualización del estado de vuelo y de todos los 20 Capítulo 3. Desarrollo Software sensores que el UAV proporciona. Cada uno de los servicios y tópicos tienen asociado su propio tipo de mensaje que en alguno de los casos se ha tenido que crear específicamente para esta tarea. Servicios Se presentan en las Tabla 3.5, Tabla 3.6, Tabla 3.7, Tabla 3.8, Tabla 3.9, Tabla 3.10, Tabla 3.11, Tabla 3.12, Tabla 3.13 y Tabla 3.14 la descripción de los diferentes servicios disponibles para la comunicación con el UAV. Tabla 3.5 Servicio Set Flight Plan. Url /trajectory_planner/set_flight_plan Tipo /trajectory_planner/SetFlightPlan Campos geometry_msgs/Pose[] waypoints — bool sucess string message Comentarios Establece la misión Tabla 3.6 Servicio Get Flight Plan. Url /trajectory_planner/get_flight_plan Tipo /trajectory_planner/GetFlightPlan Campos — geometry_msgs/Pose[] waypoints string message Comentarios Obtiene la misión actual En caso de que no haya ninguna, responde lista vacía con mensaje de error Tabla 3.7 Servicio Set Mode. Url /trajectory_planner/set_mode Tipo /trajectory_planner/SetMode Campos uint8 mode — bool sucess string message Comentarios uint8 AUTO = 0 uint8 ASSIST = 1 3.5 Comunicaciones 21 Tabla 3.8 Servicio Despegue. Url /trajectory_planner/takeoff Tipo /trajectory_planner/Takeoff Campos float64 height — bool success string message Comentarios Servicio de despegue Si la altura es menor a 1.5, devuelve error. Si el UAV no está armado, devuelve error Tabla 3.9 Servicio Aterrizaje. Url /trajectory_planner/land Tipo std_srvs/Trigger Campos — bool success string message Comentarios Servicio de aterrizaje Tabla 3.10 Servicio ir a waypoint. Url /trajectory_planner/go_to_waypoint Tipo /trajectory_planner/GoToWaypoint Campos uint8 mode uint16 wp_index — bool success string message Comentarios uint8 STOP = 0 uint8 CONTINUE = 1 El modo debe de ser cualquiera de los dos de arriba. Este mismo servicio se usa para comenzar la misión, usando el modo CONTINUE 22 Capítulo 3. Desarrollo Software Tabla 3.11 Servicio pausar misión. Url /trajectory_planner/stop_mission Tipo std_srvs/Trigger Campos — bool success string message Comentarios Pausa la misión Tabla 3.12 Servicio cancelar misión. Url /trajectory_planner/cancel_mission Tipo std_srvs/Trigger Campos — bool success string message Comentarios Borra la lista de waypoints y pausa la misión Tabla 3.13 Servicio configurar Home. Url /trajectory_planner/set_home_tf Tipo /trajectory_planner/SetTransform Campos geometry_msgs/Vector3 translation geometry_msgs/Quaternion rotation — bool success string message Comentarios Configura el home (Posición inicial del UAV) Tabla 3.14 Servicio obtener Home. Url /trajectory_planner/get_home_tf Tipo /trajectory_planner/GetTransform Campos — geometry_msgs/Vector3 translation geometry_msgs/Quaternion rotation bool success string message Comentarios Configura el home (Posición inicial del UAV) Tópicos Se presentan en Tabla 3.15, Tabla 3.16 y Tabla 3.17 los diferentes tópicos propios del paquete trajectory_planner para comunicarse con el UAV. 3.5 Comunicaciones 23 Tabla 3.15 Tópico Estado de vuelo del UAV. Url /trajectory_planner/status Tipo std_msgs/Uint8 Comentarios Número del estado en el que se encuentra el UAV UNITITIALIZED = 0, MANUAL = 1, STOP = 2, ARMED = 3 , TAKEOFF = 4, HOVERING = 5, GOTOWP = 6, LANDING = 7, ASSISTED = 8, PRELANDING = 9, Se publica continuamente a 50Hz Tabla 3.16 Tópico Waypoint Actual al que está yendo el UAV. Url /trajectory_planner/current_wp_index Tipo std_msgs/Uint16 Comentarios Index del waypoint actual. Se publica continuamente a 50Hz Tabla 3.17 Posición actual del UAV. Url /odometry/baselink Tipo geometry_msgs/PoseStamped Comentarios Posición actual del UAV. Se publica continuamente a 400Hz OJO: Su frame_id es odom_r Árbol de transformadas El árbol de transformadas define las transformaciones necesarias entre los diferentes ejes de coordenadas asociados a los elementos móviles del UAV. Este árbol es necesario sobre todo para el control a bordo del dron pero también para la correcta representación de los datos, ya que la información que podemos obtener a partir de los canales de comunicación que se comentaron anteriormente está referenciada a diferentes ejes coordenados. En la Figura 3.4 se muestra el árbol de transformadas para este proyecto. •/map -> /odom_r : Desde el origen del mapa (0,0,0) al punto de despegue(home). •/odom_r -> /odom: Transformada estática. Rotación de 180 º en el eje X para darle la vuelta al sistema ya que el LIDAR está al revés. •/odom -> /os_lidar: Posición del UAV con respecto al punto de despegue. Calculada por el algoritmo de SLAM. •Resto de las transformaciones son estáticas relacionadas con el montaje hardware. 24 Capítulo 3. Desarrollo Software Figura 3.4 Árbol de transformadas. 3.5.2 Acciones propias que solicita al core En este módulo, las acciones que se solicitan tienen que ver con la actualización de los datos recibidos por los canales de información que nos facilita ROS, p. ej., si el módulo de comunicaciones recibe el tópico que me está informando del estado de vuelo de la aeronave (trajectory_planner/status), deberá solicitar al core la actualización de este dato mediante una acción. En la Tabla 3.18 se detallan las acciones que solicitan la modificación del modelo de datos que usa el módulo comunicaciones. 3.6 Visualizador 3D 25 Tabla 3.18 Acciones emitidas por las comunicaciones. Tipo de Acción DTO Asociado Explicación UPDATE_COMMS_STATUS CommsStatusDTO Actualiza el estado de las comunicaciones (conectada o desconectada ) UPDATE_POINT_CLOUD PointCloudDTO Actualiza la nube de puntos UPDATE_POSE PoseDTO Actualiza la posición actual del UAV UPDATE_COMPRESSED_ CompressedImageDTO Actualiza la imagen capturada IMAGE por la cámara del UAV UPDATE_FLIGHT_STATUS FlightStatusDTO Actualiza el estado de vuelo del UAV UPDATE_BATTERY_ BatteryParametersDTO Actualiza el estado de PARAMETERS la batería del UAV UPDATE_CURRENT_WP CurrentWaypointDTO Actualiza el waypoint actual del UAV UPDATE_LOADED_ROUTE_ — Actualiza la ruta actual como FROM_CURRENT_ROUTE ruta cargada UPDATE_LOADED_ROUTE RouteDTO Actualiza la ruta cargada UPDATE_LOADED_HOME HomeDTO Actualiza el home cargado UPDATE_MSG_CONSOLE MsgConsoleDTO Solicita la publicación de un mensaje en la consola 3.6 Visualizador 3D Se ha decidido que el visualizador 3D o map como se conoce en la Figura 3.1 se base en RViz, ya que es compatible con ROS, y nos ofrece una diversa variedad de tipos de formas para mostrar en él, como ya se comentó en la Tabla 2.1. La comunicación interna map->core se muestra en la Figura 3.5, análogo al comportamiento visto anteriormente, sin embargo en este caso es totalmente necesario que el visualizador conozca los cambios producidos en el modelo de datos ya sea por su propia solicitud o por el de otros módulos. Para llevar a cabo esta funcionalidad se conecta la señal sendDTOToPlugin del core a el slot manageCoreDTO del visualizador, de esta manera el core notificará al visualizador de cualquier modificación del modelo de datos cuando se produzca y el visualizador trabajará con un modelo de datos actualizado Figura 3.6. Figura 3.5 Comunicación map->core. 26 Capítulo 3. Desarrollo Software Figura 3.6 Comunicación core->map. Para el correcto funcionamiento de este visualizador hay que tener en cuenta una serie de clases que lo manejan: •rviz::VisualizationManager : Es el que contiene los diferentes objetos renderizables, así como el escenario y la herramienta que se encarga de el manejo de la cámara de la visualización (ViewManager) [9]. •rviz::RenderPanel : Es el escenario en si mismo, el encargado de renderizar los diferentes objetos que están en la escena para su correcta visualización [10]. •rviz::ViewManager : Es el que se encarga del manejo de la cámara de la visualización, RViz ofrece diferentes tipos de cámara como se comentó en la Tabla 2.2, de esta manera utilizando algunos de estos tipos de cámara se puede visualizar el escenario en 2D o 3D o incluso hacer que la cámara mantenga la vista en tercera persona a un frame en concreto para poder “seguir ” al UAV. •Displays : Conjunto de objetos renderizables. Figura 3.7 Aspecto inicial visualizador 3D. 3.6.1 Representación En primera instancia el desarrollo del visualizador se centró en la correcta representación de tanto los datos ofrecidos por el UAV como los datos necesarios para la creación de la misión: •Representar punto de despegue/aterrizaje (home). (Véase Figura 3.8) •Representar imagen de la planta del entorno. (Véase Figura 3.8) •Representar marcadores (waypoints). •Representar trayectoria del UAV. 3.6 Visualizador 3D 27 •Representar nube de puntos obtenida por el LIDAR. (Véase Figura 3.9) •Representar modélo 3D del UAV. •Representar línea que una waypoints de una misma ruta. Figura 3.8 Representación punto de aterrizaje e imagen de la planta del entorno. Figura 3.9 Nube de puntos obtenida por el LIDAR. Para que el UAV conozca los puntos objetivo a los que debe ir, es necesario cargar una ruta, es decir una lista de waypoints utilizando el servicio setFlightPlan. Se debe llevar por tanto un control de cuál de las diferentes rutas que se pueden tener en el visualizador es la cargada, para ello se hace distinción uniendo los waypoints con líneas verdes, y las rutas no cargadas (locales) con líneas amarillas, esto se muestra en Figura 3.10. 34 Capítulo 3. Desarrollo Software Figura 3.16 Comunicación core->GUI. Figura 3.17 Comunicación GUI->core. A continuación se va a describir los distintos elementos que componen el prototipo de la interfaz de usuario diseñado y las interacciones que se pueden realizar sobre ellos. Existe un conjunto de componentes que están siempre visibles para el usuario, como la barra de menús, la barra de herramientas y los diferentes widgets que aparecen en la Figura 3.25 (excepto el editor de waypoints que solo es visible en modo edición). Aunque es la GUI quién envía las señales al core provenientes de los diferentes widgets o herramientas y quién recibe las modificaciones del modelo de datos actualizando los widgets y herramientas necesarias, todo esto usando el mecanismo señales-slots, se va a comentar en el apartado de cada widget y herramienta cuáles son las acciones asociadas a cada uno de ellos y cuáles son las modificaciones del modelo de datos de las que debe estar al tanto para hacer mas comprensible la lectura de este documento. 3.7.1 Barra de menús En la parte superior-izquierda de la interfaz de usuario se encuentra el acceso a los diferentes menús de la aplicación. Se puede acceder a cada menú pulsando sobre él. Figura 3.18 Barra de menús. El ménu File nos ofrece ciertas opciones que se muestran en la Figura 3.19. Figura 3.19 Menú File. 3.7 Interfaz gráfica 35 Estas opciones nos permiten: •New Mission: Crear una nueva misión añadiéndole un nombre. •Open Mission: Cargar una misión de un archivo guardado con anterioridad. •2D View: Cambia el visualizador a modo 2D. •3D View: Cambia el visualizador a modo 3D. •Save Mission: Guardar los cambios realizados en la misión actual. •Save Mission As: Guardar la misión actual creando un nuevo fichero. •Close Mission: Cerrar la misión actual. •Quit: Cierra la aplicación. El menú Options se muestra en la Figura 3.20 y nos permite : Figura 3.20 Menú Options. •Comms Options: Muestra un diálogo que permite modificar los tópicos a los que se suscriben las comunicaciones. (Véase Figura 3.21) •Waypoints Options: Muestra un diálogo en el que se puede modificar la altura por defecto de los waypoints que se creen.(Véase Figura 3.22) •Floor Image Options: Muestra un diálogo que permite cambiar la ruta de la imagen que se muestra en el plano XY del visualizador 3D. (Véase Figura 3.23) Figura 3.21 Diálogo de opciones de las comunicaciones. 36 Capítulo 3. Desarrollo Software Figura 3.22 Diálogo modificación de altura por defecto de waypoints. Figura 3.23 Diálogo de modificación de ruta de la imagen del plano XY. Acciones de las que es responsable Esta barra de menús es responsable de la emisión de las siguientes acciones : Tabla 3.25 Acciones responsable por la barra de menús. Acción DTO Asociado Explicación NEW_MISSION BasicMissionDTO Crea una nueva misión OPEN_MISSION BasicMissionDTO Carga una misión previamente guardada SAVE_MISSION BasicMissionDTO Guarda en un archivo la misión actual SAVE_AS_MISSION BasicMissionDTO Guarda la misión actual en un nuevo fichero CLOSE_MISSION BasicMissionDTO Cierra la misión actual Cambios en el modelo de datos a los que es susceptible Tabla 3.26 Cambios del modelo de datos sensibles para la barra de menús. DTO que cambia Explicación CommsStatusDTO Sólo se puede cerrar la misión si las comunicaciones están desconectadas MissionDTO No se puede guardar la misión si no hay home guardado 3.7.2 Barra de herramientas Debajo de la barra de menús se encuentra las diferentes herramientas de la aplicación. Estas herramientas están divididas en secciones formadas por un conjunto de botones. En la Figura 3.24 se muestra las distintas herramientas incluidas en esta GCS. 3.7 Interfaz gráfica 37 Figura 3.24 Barra de herramientas. •Edition Mode : Pulsando sobre este botón la aplicación pasa a modo edición de misiones en el que puede modificar los waypoints que pertenecen a rutas locales y sale del modo de vuelo. •Center UAV : Pulsando sobre este botón la aplicación pasa a modo seguimiento del UAV en el que el visualizador centra la cámara en la aeronave. Sólo esta disponible cuando la aplicación está conectada a la aeronave. •2D View : Pulsando sobre este botón la aplicación pasa a modo 2D en el que el visualizador centra la cámara en el plano XY. •3D View : Pulsando sobre este botón la aplicación pasa a modo 3D en el que la cámara que usa el visualizador es Orbital Camera. •Create Route : Seleccionando esta herramienta, se pueden añadir nuevas rutas locales a la misión actual. Esta herramienta está solo disponible cuando la aplicación tiene cargada una misión y está en modo edición de misiones. •Edit Route : Seleccionando esta herramienta, se pueden editar las rutas existentes en la misión actual. Esta herramienta está solo disponible cuando la aplicación está en modo edición de misiones y existe alguna ruta en la misión actual. •Edit Home : Seleccionando esta herramienta, se puede editar el punto de despegue/aterrizaje actual. •Measure : Seleccionando esta herramienta, se puede medir la distancia entre dos puntos del mapa. •Connect : Seleccionando esta herramienta, la aplicación se conecta a la aeronave. Esta herramienta está solo disponible cuando existe una misión cargada. •Disconnect : Seleccionando esta herramienta, la aplicación se desconecta de la aeronave. Esta herramienta está solo disponible cuando la aplicación está conectada al UAV. •Options : Seleccionando esta herramienta, aparece el diálogo de las opciones de comunicaciones. •Image : Seleccionando esta herramienta, aparece en el visualizador la imagen en el plano XY. •Show Point Cloud : Seleccionando esta herramienta, se muestra la nube de puntos obtenida por el LIDAR. Solo está disponible cuando la GCS está conectada a la aeronave. •Show Local Routes : Seleccionando esta herramienta, se muestran todas las rutas locales que hay en la misión actual. Se habilita cuando existe una misión cargada en la GCS. •Show Loaded Route : Seleccionando esta herramienta, se muestra la ruta cargada en la aeronave. Se habilita cuando la GCS está conectada a el UAV. Acciones de las que es responsable Esta barra de herramientas es responsable de la emisión de las siguientes acciones : 38 Capítulo 3. Desarrollo Software Tabla 3.27 Acciones responsable por la barra de herramientas. Acción DTO Asociado Explicación CHANGE_APPLICATION_ ApplicationStatusDTO Modifica el estado de la aplicación STATUS ROS_CONNECT – Solicita la conexión con el UAV ROS_DISCONNECT – Solicita la desconexión ccon el UAV SHOW_POINT_CLOUD BasicBoolDTO Muestra o no la nube de puntos SHOW_FLOOR_IMAGE BasicBoolDTO Muestra o no la imagen CHANGE_ROUTE_ RouteOptionsDTO Modifica la visualización de las OPTIONS rutas locales y cargada Cambios en el modelo de datos a los que es susceptible Tabla 3.28 Cambios del modelo de datos sensibles para la barra de herramientas. DTO que cambia Explicación CommsStatusDTO Sólo se puede cerrar la misión si las comunicaciones están desconectadas MissionDTO No se pueden añadir waypoints si no hay una misión cargada EditionModeDTO Actualiza el modo edición/vuelo ApplicationStatusDTO Los botones deben conocer en que modo esta la GCS para activarse/desactivarse adecuadamente Además la GUI está compuesta por diferentes widgets, que se encargan tanto de la representación de datos, como del envío de acciones sobre el UAV. Los diferentes widgets están conectados con la GUI mediante el mecanismo de señales y slots para que tanto la GUI pueda solicitar al core acciones provenientes de los widgets, como estos representar de manera adecuada la diferente información proveniente del modelo de datos. En la Figura 3.25 se muestran los diferentes widgets que pertenecen a la GUI. Figura 3.25 Diferentes widgets de la GUI. 3.7.3 Alarms Este widget se usa como un visualizador rápido de los aspectos fundamentales durante el vuelo, como son el estado de las comunicaciones, el estado de la batería y el estado del UAV . •COMMS: La alarma estará en rojo si las comunicaciones están desconectadas, en verde si están conectadas y en gris si no ha recibido nada. 3.7 Interfaz gráfica 39 •INTERNAL STATUS: Existe un tópico que nos ofrece el UAV que comprueba que todos los demás tópicos funcionan correctamente. Si este tópico está correcto la alarma estará en verde, si no lo está la alarma aparecerá en rojo y si no ha recibido nada aparecerá en gris. •BATTERY: La alarma aparecerá en verde si la la batería del UAV es de más del 30%, en amarillo si está entre el 20% y el 30%, en rojo si es menor del 20% y en gris si no ha recibido el estado de la batería. Figura 3.26 Aspecto inicial de las alarmas. Figura 3.27 Aspecto de las alarmas durante el vuelo. Acciones de las que es responsable Este widget es solo de visualización por lo que no emite ninguna señal. Cambios en el modelo de datos a los que es susceptible Tabla 3.29 Cambios del modelo de datos sensibles para las alarmas. DTO que cambia Explicación CommsStatusDTO Actualizar el estado de las comunicaciones BatteryParametersDTO Actualizar el estado de la batería TopicsStatusDTO Actualizar el estado de los tópicos 3.7.4 Camera Display Este widget se encarga de representar las imágenes tomadas por una cámara montada en el UAV para que el operario tenga en todo momento una visual de la aeronave. La imagen es transmitida a través de un tópico y recogida por las comunicaciones que mandan al core una acción de actualizar la imagen. Esta modificación del modelo de datos es notificada a la GUI que a su vez notifica a este widget y representa la imagen. Figura 3.28 Estado inicial y durante el vuelo de la cámara. 40 Capítulo 3. Desarrollo Software Acciones de las que es responsable Este widget es solo de visualización por lo que no emite ninguna señal. Cambios en el modelo de datos a los que es susceptible Tabla 3.30 Cambios del modelo de datos sensibles para la cámara. DTO que cambia Explicación CompressedImageDTO Actualizar la imagen de la cámara embarcada 3.7.5 Console Display Este widget se usa para llevar un registro que muestre al usuario los sucesos más importantes en la GCS. Existen tres tipos de mensaje: información, aviso y error. Cada uno es representado por un color diferente de letra: blanco, amarillo y rojo. Figura 3.29 Aspecto inicial de la console. Figura 3.30 Aspecto de la consola durante el vuelo. Acciones de las que es responsable Este widget es solo de visualización por lo que no emite ninguna señal. Cambios en el modelo de datos a los que es susceptible Tabla 3.31 Cambios del modelo de datos sensibles para la consola. DTO que cambia Explicación MsgConsoleDTO Actualizar mensaje de la consola 3.7 Interfaz gráfica 41 3.7.6 Flight Control Este widget está compuesto de una serie de botones que permiten enviar comandos de vuelo durante la ejecución de la misión. Estos botones estarán activados cuando la GCS está conectada con el UAV, y cada uno de ellos podrá utilizarse dependediendo del estado de vuelo de la aeronave, p.ej. el botón de aterrizar solo estará disponible cuando el estado de vuelo del UAV es “HOVERING” que quiere decir que el UAV esta estático en una altura determinada. Figura 3.31 Estado inicial y durante el vuelo del widget de control de vuelo . Acciones de las que es responsable Este widget emite acciones que tienen que ver con el envío de comandos al UAV. Acciones DTO Asociado Explicación SEND_LAND – Aterriza al UAV SEND_TAKE_OFF BasicFloatDTO Despega al UAV a una altura determinada SEND_START_MISSION – Empieza la Misión SEND_CANCEL_MISSION – Cancela la Misión SEND_STOP_MISSION – Pausa la Misión SEND_ROUTE – Carga la ruta en el UAV RECEIVE_ROUTE – Actualiza la ruta cargada que hay en el UAV GO_TO_WAYPOINT TargetWaypointDTO Manda al UAV a un waypoint determinado CHANGE_FLIGHT_STATUS BasicBoolDTO Cambia el modo de vuelo entre asistido o automático SEND_HOME_TF – Actualiza el home en el UAV RECEIVE_HOME_TF – Recibe el home del UAV Tabla 3.32 Comandos que envía Flight Control al UAV. Cambios en el modelo de datos a los que es susceptible 42 Capítulo 3. Desarrollo Software Tabla 3.33 Cambios del modelo de datos sensibles para el Flight Control. DTO que cambia Explicación CommsStatusDTO Este widget se activa sólo cuando la GCS está conectada. FlightStatusDTO Los botones se activarán dependiendo del estado de vuelo 3.7.7 Telemetry Tree Este widget es el encargado de monitorizar la telemetría que nos ofrece el UAV, compuesta por los datos de posición y orientación de la aeronave, el nivel de batería de esta, el estado de vuelo y el waypoint al que se está dirigiendo en cada momento. Figura 3.32 Telemetry Tree Widget inicialmente y durante el vuelo . Acciones de las que es responsable Este widget es sólo de visualización por lo que no emite acciones. Cambios en el modelo de datos a los que es susceptible Tabla 3.34 Cambios del modelo de datos sensibles para el Telemetry Tree Widget. DTO que cambia Explicación CommsStatusDTO Este widget se activa sólo cuando la GCS está conectada. PoseDTO Actualiza los datos de posición del UAV BatteryParametersDTO Actualiza el nivel de batería del UAV FlightStatusDTO Actualiza el estado de vuelo del UAV CurrentWaypointDTO Actualiza el waypoint actual 3.7 Interfaz gráfica 43 3.7.8 Primary Flight Display La función fundamental de este widget es representar visualmente y de manera animada la telemetría del UAV para que de un vistazo rápido el operario tenga la suficiente información de si la aeronave está llevando a cabo un vuelo adecuado o de si por el contrario hay algún aspecto que no está funcionando correctamente. Los datos del UAV que se representan en este widget son : •Estado de vuelo. •Altitud. •Estado de la batería. •Orientación: Roll ypitch en el centro del display,yaw en la parte inferior. •Waypoint al que se dirige si el estado de vuelo es "GOTOWP”. •Distancia al próximo waypoint. Figura 3.33 Estado inicial y durante el vuelo del Primary Flight Display. Acciones de las que es responsable Este widget es sólo de visualización por lo que no emite acciones. Cambios en el modelo de datos a los que es susceptible Tabla 3.35 Cambios del modelo de datos sensibles para el Primary Flight Display Widget. DTO que cambia Explicación CommsStatusDTO Este widget se activa sólo cuando la GCS está conectada. PoseDTO Actualiza los datos de posición del UAV BatteryParametersDTO Actualiza el nivel de batería del UAV FlightStatusDTO Actualiza el estado de vuelo del UAV CurrentWaypointDTO Actualiza el waypoint actual 3.7.9 Vehicle Control Este widget consiste en un joystick que envía referencias de velocidad en los ejes X e Y cuando la aeronave se encuentra en modo asistido. Además de botones que envía referencias en velocidad en 50 Capítulo 4. Experimentos con UAV real Figura 4.5 Aspecto de la GCS durante un vuelo real. 5 Conclusiones y posibles líneas futuras An tes de nada, es necesario destacar que el llevar a cabo la implementación de este proyecto ha provocado la necesidad de aprendizaje de tecnologías de las que previamente no se tenía conocimiento como son C ++ , Qt, Python y ROS. Por lo que el desarrollo de este TFG ha permitido adquirir conocimientos muy útiles y sobre todo transversales. Con respecto a la GCS en sí, se ha conseguido que sea intuitiva y que cumpla los aspectos que se introdujeron al principio de este documento. Sin embargo, estaría interesante añadir mejoras que por falta de tiempo no se han llevado a cabo, pero que se han tenido en cuenta a la hora de la realización de este trabajo. Algunas de estas mejoras tienen que ver con la eficiencia del código, existen mecanismos integrados en versiones posteriores de C ++ que harían que la GCS fuera más eficiente. Además estaría bien hacer un análisis del tiempo que tarda la GCS en recibir los datos que el UAV le envía y cuánto tarda este en recibir las comandas de la GCS. Otra de las líneas futuras podría ser el diseño de simulaciones que llevadas a cabo en bucle validen el correcto funcionamiento de la GCS en todos los aspectos. Esto permitiría validar las funcionalidades desarrolladas sin depender directamente de la realización de pruebas de vuelo reales, dadas las limitaciones normalmente asociadas a la experimentación con aeronaves no tripuladas en cuanto a disponibilidad de espacios apropiados, y el mantenimiento de las propias aeronaves. 51 Índice de Figuras 1.1 AeroX UAV llevando a cabo una inspección por contacto en un puente. Fuente: CATEC 1 1.2 Mapa de un vecindario construido a partir de fotogrametría. Fuente: jonhassall.com 2 1.3 Monitorización y medición de focos de calor con UAVs. Fuente: CATEC 2 1.4 LIDAR Ouster OS0. Fuente: ouster.com 3 1.5 Interior de la GCS Bayrkatar TB2. Fuente: wikipedia.org 4 1.6 Worthington Sharpe Wing GCS. Fuente: worthingtonsharpe 4 2.1 Logotipo de ROS. Fuente: es.wikipedia.org 7 2.2 Logotipo de RViz. Fuente: github.com 9 2.3 La interfaz de Spotify está diseñada con Qt. Fuente: community.spotify.com 11 2.4 Apariencia Qt Creator. Fuente: doc.qt.io 11 2.5 Logo de CMake. Fuente: cmake.org 12 3.1 Estructura Software GCS 17 3.2 DTOs que componen el modelo de datos 18 3.3 Comunicación comss-core 19 3.4 Árbol de transformadas 24 3.5 Comunicación map->core 25 3.6 Comunicación core->map 26 3.7 Aspecto inicial visualizador 3D 26 3.8 Representación punto de aterrizaje e imagen de la planta del entorno 27 3.9 Nube de puntos obtenida por el LIDAR 27 3.10 Ruta cargada y ruta local 28 3.11 Posición actual del cursor 29 3.12 Menú de home 29 3.13 Medida de distancia entre dos puntos 29 3.14 Menú de acciones sobre waypoints 30 3.15 Aspecto inicial de la GCS 33 3.16 Comunicación core->GUI 34 3.17 Comunicación GUI->core 34 3.18 Barra de menús 34 3.19 Menú File 34 3.20 Menú Options 35 3.21 Diálogo de opciones de las comunicaciones 35 53 54 Índice de Figuras 3.22 Diálogo modificación de altura por defecto de waypoints 36 3.23 Diálogo de modificación de ruta de la imagen del plano XY 36 3.24 Barra de herramientas 37 3.25 Diferentes widgets de la GUI 38 3.26 Aspecto inicial de las alarmas 39 3.27 Aspecto de las alarmas durante el vuelo 39 3.28 Estado inicial y durante el vuelo de la cámara 39 3.29 Aspecto inicial de la console 40 3.30 Aspecto de la consola durante el vuelo 40 3.31 Estado inicial y durante el vuelo del widget de control de vuelo 41 3.32 Telemetry Tree Widget inicialmente y durante el vuelo 42 3.33 Estado inicial y durante el vuelo del Primary Flight Display 43 3.34 Estado inicial y cuando el UAV está en modo asistido del Vehicle Control Widget 44 3.35 Estado del Waypoint Editor cuando hay varias rutas locales 45 4.1 UAV utilizado para las pruebas de validación 47 4.2 Testbed de la compañía FADA-CATEC 48 4.3 Entorno durante las pruebas de validación, se observa el UAV al fondo y la GCS en primer plano 48 4.4 Pruebas de Validación realizadas para la GCS 49 4.5 Aspecto de la GCS durante un vuelo real 50 Índice de Tablas 2.1 Ejemplos de displays. Fuente: wiki.ros.org/rviz/DisplayTypes 9 2.2 Tipos de cámaras. Fuente: wiki.ros.org/rviz/UserGuide 10 3.1 Estados de vuelo de la aeronave 16 3.2 Estados de la aplicación 17 3.3 DTOs que componen el modelo de datos 18 3.4 Ejemplos de tópicos y servicios que ofrece DJI OSDK ROS 19 3.5 Servicio Set Flight Plan 20 3.6 Servicio Get Flight Plan 20 3.7 Servicio Set Mode 20 3.8 Servicio Despegue 21 3.9 Servicio Aterrizaje 21 3.10 Servicio ir a waypoint 21 3.11 Servicio pausar misión 22 3.12 Servicio cancelar misión 22 3.13 Servicio configurar Home 22 3.14 Servicio obtener Home 22 3.15 Tópico Estado de vuelo del UAV 23 3.16 Tópico Waypoint Actual al que está yendo el UAV 23 3.17 Posición actual del UAV 23 3.18 Acciones emitidas por las comunicaciones 25 3.19 Funcionalidades según eventos del cursor 29 3.20 Menú de acciones sobre waypoint 30 3.21 Tipos de cámara según modo GCS 31 3.22 Controles según tipo de cámara 31 3.23 Acciones emitidas por el visualizador 32 3.24 Cambios del modelo de datos sensibles para el visualizador 32 3.25 Acciones responsable por la barra de menús 36 3.26 Cambios del modelo de datos sensibles para la barra de menús 36 3.27 Acciones responsable por la barra de herramientas 38 3.28 Cambios del modelo de datos sensibles para la barra de herramientas 38 3.29 Cambios del modelo de datos sensibles para las alarmas 39 3.30 Cambios del modelo de datos sensibles para la cámara 40 3.31 Cambios del modelo de datos sensibles para la consola 40 3.32 Comandos que envía Flight Control al UAV 41 3.33 Cambios del modelo de datos sensibles para el Flight Control 42 55 56 Índice de Tablas 3.34 Cambios del modelo de datos sensibles para el Telemetry Tree Widget 42 3.35 Cambios del modelo de datos sensibles para el Primary Flight Display Widget 43 3.36 Acciones emitidas por el Vehicle Control Widget 44 3.37 Cambios del modelo de datos sensibles para el Primary Flight Display Widget 44 3.38 Acciones emitidas por el Waypoint Editor Widget 45 3.39 Cambios del modelo de datos sensibles para el Waypoints Editor Widget 45 Índice de Códigos 2.1 Ejemplo de mensaje sensor_msgs/Temperature.msg 8 57 Bibliografía [1] “REGISTRO DE COMUNICACIONES PREVIAS DE OPERADORES DE RPA’s,” https: //www.seguridadaerea.gob.es/sites/default/files/listado_operadores.pdf. [Online]. Available: https://www.seguridadaerea.gob.es/sites/default/files/listado_operadores.pdf [2] “ROS.org | Powering the world’s robots,” https://www.ros.org/. [Online]. Available: https://www.ros.org/ [3] W. W. Dave Hershberger, David Gossow, Josh Faust, “rviz - ROS Wiki,” http://wiki.ros.org/rviz. [Online]. Available: http://wiki.ros.org/rviz [4] “Qt | Cross-platform software development for embedded desktop,” https://www.qt.io/. [Online]. Available: https://www.qt.io/ [5] Andrew Ng, “STAIR,” http://stair.stanford.edu/index.php. [Online]. Available: http: //stair.stanford.edu/index.php [6] “QObject Class | Qt Core 5.15.2,” https://doc.qt.io/qt-5/qobject.html, may 2017. [Online]. Available: https://doc.qt.io/qt-5/qobject.html [7] “Signals and Slots | Qt Core 5.15.2,” https://doc.qt.io/qt-5/signalsandslots.html, may 2017. [Online]. Available: https://doc.qt.io/qt-5/signalsandslots.html [8] Botao Hu, “dji-sdk/Onboard-SDK-ROS: Official ROS packages for DJI onboard SDK.” https://github.com/dji-sdk/Onboard-SDK-ROS, jan 2021. [Online]. Available: https://github. com/dji-sdk/Onboard-SDK-ROS [9] J. F. Dave Hershberger, David Gossow, “rviz: rviz::VisualizationManager Class Reference,” http://docs.ros.org/en/jade/api/rviz/html/c++/classrviz_1_1VisualizationManager.html, 2017. [Online]. Available: http://docs.ros.org/en/jade/api/rviz/html/c++/classrviz_1_ 1VisualizationManager.html [10] D. G. Dave Hershberger, “rviz: rviz::RenderPanel Class Reference,” http://docs.ros.org/ en/indigo/api/rviz/html/c++/classrviz_1_1RenderPanel.html, jun 19. [Online]. Available: http://docs.ros.org/en/indigo/api/rviz/html/c++/classrviz_1_1RenderPanel.html [11] J. F. Dave Hershberger, David Gossow, “rviz: rviz::ViewManager Class Reference,” http: //docs.ros.org/en/jade/api/rviz/html/c++/classrviz_1_1ViewManager.html, 2017. [Online]. Available: http://docs.ros.org/en/jade/api/rviz/html/c++/classrviz_1_1ViewManager.html [12] “New Applications of Drone Technology | Ohio University,” https://onlinemasters. ohio.edu/blog/new-applications-of-drone-technology/, 2021. [Online]. Available: https: //onlinemasters.ohio.edu/blog/new-applications-of-drone-technology/ 59