Diseño de un prototipo para la identificación de drones mediante el sistema AIS

Escuela de Ingeniería de Telecomunicación y Electrónica Trabajo Fin de Máster Diseño de un prototipo para la identificación de drones mediante el sistema AIS Titulación: Máster Universitario en Ingeniería de Telecomunicación Autor: D. Nicolás Molina Padrón Tutores: Dr. Francisco José Cabrera Almeida Dr. Víctor Alexis Araña Pulido Fecha: Febrero de 2017 Escuela de Ingeniería de Telecomunicación y Electrónica Trabajo Fin de Máster Diseño de un prototipo para la identificación de drones mediante el sistema AIS Hoja de Firmas Firma de los tutores Fdo.: Dr. Francisco José Cabrera Almeida Fdo.: Dr. Víctor Alexis Araña Pulido Firma del alumno Fdo.: D. Nicolás Molina Padrón Fecha: Febrero de 2017 Escuela de Ingeniería de Telecomunicación y Electrónica Trabajo Fin de Máster Diseño de un prototipo para la identificación de drones mediante el sistema AIS Hoja de Evaluación Calificación: Presidente Secretario Vocal Fdo.: Fdo.: Fdo.: Fecha: Febrero de 2017 We are what we pretend to be, so we must be careful about what we pretend to be. Kurt Vonnegut Agradecimientos A mis padres y mi hermano, por apoyarme durante el transcurso de toda la carrera, soportar mis nervios y malas caras constantes y aún así, seguir alegrándose cuando traigo buenas noticias. Al resto de mi familia, que directa o indirectamente siempre me han animado a alcanzar mis metas, y a mis amigos y amigas, que me permitían desconectar un poco de los estudios cuando venían los picos de estrés. A mis compañeros de clase, que sin duda fueron el apoyo que necesité para resistir durante los momentos de mayor tensión en el máster. También a los compañeros del IDeTIC, Jaime y Baltasar, que me ayudaron en la última etapa de este trabajo con muchas ganas y paciencia. A mis tutores Francis y Víctor, por toda la ayuda y las oportunidades que han puesto a mi disposición un año más, y por las que siempre les estaré agradecido. ix Índice de figuras 1.1. Ejemplo de placa no estandarizada para la identificación de drones . . . 4 1.2. Monitorización de buques en Las Palmas de Gran Canaria, España . . 5 1.3. Diagrama de bloques del prototipo .................... 7 1.4. Comunicaciones desde la estación AIS BMT-IDeTIC . ......... 8 2.1. Estructuras aerodinámicas de los UAVs.................. 11 2.2. Clasificación de drones tipo multicóptero ................. 12 2.3. Ángulos de navegación en un UAV .................... 13 2.4. Partes de la estructura de soporte de un dron .............. 15 2.5. Conexiones en una unidad ESC de un dron ................ 15 2.6. Batería LiPo Zippy 5000 20C ....................... 16 2.7. Unidad de control de vuelo ArduPilot ................... 17 2.8. Unidad de telemetría de 3D Robotics para drones . . . ......... 18 2.9. Interfaz de Mission Planner ........................ 19 2.10. Interfaz de APM Planner .......................... 19 xvii xviii ÍNDICE DE FIGURAS 2.11. Elementos en una comunicación UAV-estación terrena con MAVLink . 20 2.12. Formato de una trama MAVLink ..................... 21 3.1. Proceso de comunicación compartida entre estaciones AIS ....... 27 3.2. Arquitectura OSI del sistema AIS ..................... 30 3.3. Esquema de codificación y modulación en AIS .............. 30 3.4. Campos de una trama AIS ......................... 31 3.5. Tipos de esquema de acceso al medio en AIS en función del ámbito de aplicación .................................. 31 3.6. Estructura básica de un mensaje AIS ................... 33 3.7. Líneas de comunicación NMEA0183 genéricas para talker ylistener .. 36 4.1. Diagrama de bloques del prototipo .................... 41 4.2. Dimensiones y conectores del módulo Cobalt ............... 42 4.3. Pines del conector Hirose DF13-40P-1.25V del módulo Cobalt ..... 43 4.4. Indicadores LED en el módulo Cobalt SRT-Marine ........... 44 4.5. Conectores para las antenas de VHF y GPS del módulo Cobalt ..... 46 4.6. Placa BeagleBone Black .......................... 48 4.7. Diagrama de bloques del procesador de la placa BeagleBone Black . . . 49 4.8. Conectores y botones de la placa BeagleBone Black ........... 50 4.9. Pinout de la placa BeagleBone Black ................... 51 ÍNDICE DE FIGURAS xix 4.10. Conexión, edición y ejecución de un script en Python para BeagleBone Black ..................................... 53 4.11. Configuración de rc.local para el lanzamiento automático de scripts .53 4.12. Modelo de antena de VHF con banda magnética seleccionado ...... 54 4.13. Modelo de antena de VHF Motorola PMAD4095A ............ 55 4.14. Medidas adicionales del COE sobre las antenas de VHF utilizadas . . . 56 4.15. Modelo de antena de GPS Trimble 66800-52-SP ............. 57 5.1. Diagrama de bloques del prototipo inicial ................. 60 5.2. Diagrama de bloques del prototipo final .................. 60 5.3. Conexión y configuración del módulo Cobalt con el software proAIS2 . 62 5.4. Conexiones entre los módulos del prototipo inicial ............ 63 5.5. Montaje físico del prototipo inicial .................... 63 5.6. Integración física del prototipo en un dron experimental ......... 64 5.7. Etapas del algoritmo para la creación y envío de un mensaje AIS tipo HDT..................................... 66 6.1. Instalación general del sistema de pruebas para el prototipo ...... 72 6.2. Disposición de instalación de la arqueta de comunicaciones del IDeTIC 73 6.3. Conexiones en la estación receptora AIS BMT-IDeTIC dentro de la arqueta de comunicaciones del IDeTIC ................... 74 6.4. Flujo de ejecución de los scripts implementados ............. 76 xx ÍNDICE DE FIGURAS 6.5. Identificación del prototipo sobre la plataforma web de MarineTraffic . 83 6.6. Identificación del prototipo sobre el software OpenCPN......... 83 C.1. Vista de configuración en proAIS2 ..................... 122 C.2. Vista de monitorización de señal GNSS en proAIS2 ........... 123 C.3. Vista de monitorización de embarcaciones en proAIS2 .......... 123 C.4. Vista de verificación de estado en proAIS2 ................ 124 C.5. Vista de comandos recibidos y transmitidos en proAIS2 ......... 125 Índice de tablas 2.1. Características técnicas del módulo de telemetría de 3D Robotics . . . 18 2.2. Descripción de los campos del mensaje MAVLINK_MSG_ID_ATTITUDE .. 22 3.1. Periodo de actualización de mensajes AIS en función de la velocidad . . 34 3.2. Clasificación de los tipos de mensajes AIS ................ 35 4.1. Limitaciones para las antenas de VHF y GPS en el módulo Cobalt . . . 46 4.2. Parámetros de la antena de VHF con base magnética para el módulo Cobalt.................................... 54 4.3. Parámetros de la antena de VHF Motorola PMAD4095A para el módulo Cobalt.................................... 55 4.4. Parámetros de la antena de GPS Trimble 66800-52-SP para el módulo Cobalt.................................... 56 6.1. Tramas NMEA contenidas en los mensajes AIS transmitidos por el prototipo .................................... 78 6.2. Muestra de mensajes AIS dinámicos decodificados y con formato tabular 79 6.3. Mensaje AIS tipo 18 del prototipo con campos de datos desglosados . . 80 xxi xxii ÍNDICE DE TABLAS 6.4. Mensaje AIS tipo 24 del prototipo con campos de datos desglosados . . 80 6.5. Mensajes AIS obtenidos desde la API de MarineTraffic ......... 81 P.1. Costes de materiales fungibles hardware .................. 96 P.2. Costes de materiales no fungibles software ................ 97 P.3. Otros costes materiales ........................... 98 P.4. Costes asociados al inmovilizado material ................. 99 P.5. Trabajo tarifado por tiempo empleado .................. 101 P.6. Costes totales del Trabajo Fin de Máster . . ............... 101 Resumen El número de aplicaciones que involucran el uso de los drones o UAVs (Unmanned Aerial Vehicle) se ha incrementado notablemente en los últimos años, obligando a las autoridades gubernamentales de muchos países, entre ellas España, a establecer regulaciones estrictas en materia de estas aeronaves. Estas normativas restringen el uso de los drones en las ciudades, así como en zonas de confluencia aérea comercial, con el objetivo de garantizar la seguridad de los ciudadanos y evitar un mal uso de estas nuevas tecnologías. En este sentido, la normativa española cuenta con algunos problemas no resueltos en lo que respecta a la identificación de estas aeronaves. La normativa vigente indica que todo UAV debe estar identificado con un número de serie y otros datos que permitan reconocer al propietario de esta aeronave, pero no existe una solución estándar a este problema. Tradicionalmente, la solución más común consiste en incorporar una placa de identificación en el fuselaje de la aeronave, aunque no resulta una solución óptima cuando el UAV está realizando una operación de vuelo. Por ello, existe la necesidad de encontrar un sistema inalámbrico que permita la identificación remota de estos dispositivos. Una posible solución a este problema radica en el sistema AIS (Automatic Identification System), un sistema de comunicaciones marítimas por radiofrecuencia que se emplea para la identificación de buques y conocer sus parámetros más significativos, como son la velocidad o el rumbo. Cada embarcación que integra este sistema es capaz de identificarse de forma unívoca con un código denominado MMSI (Maritime Mobile Service Identity), y luego transmitir y recibir datos sobre el resto de embarcaciones. xxiii xxiv ÍNDICE DE TABLAS De esta manera, es posible evitar colisiones y además, conocer el estado del tráfico marítimo en todo momento. Para ello, el IDeTIC (Instituto para el Desarrollo Tecnológico y la Innovación en Comunicaciones) propone en este trabajo el aprovechamiento del sistema AIS para la identificación de drones mediante la integración de un prototipo embarcado en un dron experimental, permitiendo identificar a la aeronave y transmitir sus parámetros más significativos de forma autónoma. Esta solución, que presenta numerosas ventajas en términos de alcance y costes económicos, permite sustituir el método tradicional para la identificación de drones adoptado en la actualidad, solventando los principales problemas que derivan de esta solución. Tras la implementación y verificación del prototipo, las pruebas llevadas a cabo muestran resultados satisfactorios que permiten concluir la viabilidad del prototipo y las virtudes que supone la adopción de este sistema a nivel comercial. Por ello, más allá de los resultados expuestos en este trabajo, se plantean futuras mejoras de este prototipo para lograr una mayor repercusión social que motive la sustitución definitiva del método de identificación tradicional de UAVs. Palabras clave: AIS (Automatic Identification System), Dron, MMSI (Maritime Mobile Service Identity), Prototipo, UAV (Unmanned Aerial Vehicle). Abstract The number of applications which involve the use of drones or UAVs (Unmanned Aerial Vehicle) has increased significantly in the last years, and this fact has coerced the governments of many countries, for instance Spain, into establishing strict regulations for these aircrafts. These regulations restrict the use of drones in the cities, as well as air confluence areas, and so guarantee the citizens’ security and avoid the wrong use of this technology. In this sense, the Spanish regulation has some problems which have not been solved yet with regards to the UAVs identification. The current regulation shows that every UAV must be identified with a serial number and other data which allow to know the owners of these aircrafts, but there is not a standardised solution for this problem. Traditionally, the common solution consists of a identification plate embedded in the drone’s fuselage, but this is not the optimal solution when the UAV is flying. For this reason, there exists a need to find a wireless system to allow the remote identification of these devices. A possible solution to this problem is AIS (Automatic Identification System), a marine radiocommunication system which is used for vessels identification and to know the most meaningful parameters, such as speed or course. Each vessel which integrates this system can be able to identify itself uniquely by means of a code named MMSI (Maritime Mobile Service Identity), and then transmit and receive data about the other vessels. In this way, it is possible to avoid collisions and moreover, to know the state of marine traffic at all times. xxv Capítulo 1 Introducción 1.1. Antecedentes En los últimos años, el creciente interés que ha despertado el uso de los vehículos aéreos no tripulados o UAV (Unmanned Aerial Vehicle) ha supuesto un impacto crucial en numerosos ámbitos de la sociedad. Esta tecnología, que inicialmente estaba únicamente a disposición de las autoridades militares [1], es utilizado hoy día para múltiples propósitos relacionados con el ámbito empresarial o el ocio, ya que facilitan ciertas labores de automatización de procesos o para operaciones vigilancia en las ciudades, entre otras aplicaciones [2]. Sin embargo, la inmersión de los UAVs o drones en la sociedad actual puede derivar en un uso inapropiado de los mismos. Desde hace algunos años, subyace una preocupación sobre el uso de esta tecnología para apoyar operaciones terroristas o de vigilancia no autorizada sobre la población [3]. En este sentido, los gobiernos de numerosos países han establecido leyes que garantizan la privacidad de los ciudadanos mediante la restricción de uso de estos dispositivos. En el caso de España, los drones son regulados en virtud del Real Decreto-Ley 8/2014 [4] y el Artículo 50 de Ley 18/2014 [5], que establecen el marco jurídico aplicable a este tipo de aeronaves para garantizar la seguridad aérea y permitir, a su vez, el auge de estas tecnologías en beneficio de la ciudadanía. De esta manera, se establecen los términos que debe cumplir el propietario de un UAV, la zona de operación, el peso máximo e incluso, la identificación de la aeronave. 3 41.1. Antecedentes La vigente normativa española en materia de UAVs establece que toda aeronave civil pilotada de forma remota debe incorporar algún elemento que permita identificarla, así como el número de serie y la empresa operadora de la aeronave como contacto. Sin embargo, la legislación no ha alcanzado una estandarización del método empleado por los usuarios de drones para identificar sus dispositivos, y de forma tradicional se ha utilizado una placa metálica solapada al fuselaje del dron, donde se incluyen los datos obligatorios que fija la normativa (figura 1.1). Fabricante: Modelo: Número de serie: Empresa operadora: Datos de contacto: Figura 1.1: Ejemplo de placa no estandarizada para la identificación de drones Sin embargo, este método resulta ineficiente cuando el dron se encuentra sobrevolando una zona no autorizada o que induce un riesgo sobre la seguridad, como puede ocurrir en las áreas próximas a los aeropuertos, que en el peor de los casos obliga a las autoridades a abatirlo. En este sentido, el método tradicional resulta tedioso, además de una solución primitiva en comparación con los sistemas inalámbricos. La estricta regulación en materia de drones no ha mermado el interés por esta nueva tecnología, sino que ha propiciado que un gran número de investigadores evalúen el uso de los UAVs como apoyo sobre sus proyectos, tanto en el sector empresarial como académico. Entre los centros españoles que estudian la tecnología UAV se encuentra el IDeTIC (Instituto para el Desarrollo Tecnológico e Innovación en Comunicaciones), que desde 2011 ha centrado parte de su actividad en el desarrollo de proyectos nacionales y europeos donde los drones basados en la tecnología de 3D Robotics [6] son el componente crucial. En virtud de estos proyectos, el IDeTIC ha planteado numerosas aplicaciones que implican el uso de drones, desde tecnología RF para drones ligeros [7] hasta sistemas aéreos para el seguimiento de líneas de fuego [8], y sobre estas aplicaciones se han propuesto diversas ofertas de Trabajos Fin de Título [9] [10] [11] [12] que han permitido consolidar los conocimientos adquiridos acerca de la tecnología UAV. 1. Introducción 5 Es por ello que el IDeTIC, atendiendo a la ausencia de estandarizaciones para el método de identificación de drones, plantea en este Trabajo de Fin de Máster una alternativa al método tradicional utilizado para este propósito. Para ello, se combina la línea de trabajo de los UAVs con una línea incipiente que aborda el IDeTIC desde 2014, que es el sistema AIS. El sistema AIS (Automatic Identification System) es un estándar para las comunicaciones marítimas ubicado en la banda de VHF marina [13], que permite obtener los parámetros característicos de los buques que lo integran, como son la velocidad o la posición, entre otros (figura 1.2). Este sistema es de uso obligatorio desde 2003, cuando la IMO (International Maritime Organization), en relación al Convenio SOLAS (Safety of Life at Sea), establece que cualquier embarcación que supere un tonelaje bruto superior a 500 toneladas, 300 toneladas y que realice travesías internacionales o destinadas al transporte de pasajeros, debe incluir un transpondedor AIS abordo para monitorizar su actividad y así evitar posibles colisiones o desastres en alta mar [14]. Figura 1.2: Monitorización de buques en Las Palmas de Gran Canaria, España Cuando una embarcación quiere incorporarse en el sistema AIS necesita obtener un identificador único denominado MMSI (Maritime Mobile Service Identity). Se trata de un código de 9 dígitos provisto por la autoridad marítima correspondiente del país de origen de la embarcación, que en el caso de España corresponde a la Dirección General de la Marina Mercante, que asigna un MMSI a una embarcación tras el pago de las tasas correspondientes que fija el Ministerio de Fomento [15]. 61.2. Objetivos Desde 2013, el IDeTIC (Instituto para el Desarrollo Tecnológico e Innovación en Comunicaciones) mantiene un convenio marco con WoW Group, empresa matriz de la compañía MarineTraffic, líder en la monitorización de buques a través del sistema AIS. Gracias a este convenio, el IDeTIC posee una estación de monitorización AIS denominada BMT-IDeTIC instalada en el Campus de Tafira (Gran Canaria, España), que tiene acceso a la red de MarineTraffic y sirve como nodo para la monitorización de buques que navegan cerca de las costas de la isla de Gran Canaria. En base al convenio con MarineTraffic, el IDeTIC ha comenzado a evaluar las posibilidades que ofrece el sistema AIS [16], y en combinación con la amplia experiencia que ha adquirido este instituto de investigación en materia de drones, se plantea el desarrollo de este proyecto. Con ello, se pretende desarrollar un sistema embarcado en drones basado en el sistema AIS, que permita al dron identificarse incluso cuando se encuentre en el aire, de forma que sea una alternativa al método tradicional que se emplea en virtud de la normativa española. Además, los primeros planteamientos de este proyecto han sido acogidos favorablemente a través del concurso de ideas de la Primera Convocatoria de Premios Talento y Compromiso CajaSiete 2015, donde se obtuvo el primer premio [17]. 1.2. Objetivos El principal objetivo de este Trabajo Fin de Máster consiste en desarrollar un prototipo basado en el sistema AIS que, al ser integrado sobre un dron experimental, permita que el dispositivo pueda enviar su propia identificación al resto de estaciones AIS, además de otros parámetros del dron, como puede ser el rumbo. Para ello, el prototipo es capaz de generar comandos NMEA particulares con datos del dron, obtenidos a través de la información paramétrica que envía la aeronave a través del protocolo MAVLink. En la figura 1.3 se presenta el diagrama de bloques del prototipo, donde se muestra una visión general de los principales módulos que integran el prototipo y su relación con el dron experimental. 1. Introducción 7 PILOTO AUTOMÁTICO DEL UAV MICROCONTROLADOR TRANSCEPTOR AIS CLASE B ANTENA VHF ANTENA GPS Figura 1.3: Diagrama de bloques del prototipo Cuando el prototipo envía sus datos, la estación receptora AIS BMT-IDeTIC, instalada en el Campus de Tafira, recoge estos datos y los empaqueta para posteriormente enviarlos por la red. De esta manera, los datos de red se envían a un socket del servidor de MarineTraffic, asignado previamente al IDeTIC por esta entidad. Una vez los datos son almacenados en el servidor de MarineTraffic, son procesados y filtrados para obtener únicamente aquellos valores que son de interés comercial, y a través de una API (Application Programming Interface) propia de MarineTraffic pueden llegar a los usuarios de MarineTraffic. En el caso del IDeTIC, se hace uso de un servidor Linux donde se almacenan estos datos con ayuda de un grupos de scripts. De esta manera, es posible acceder a estos datos mediante una conexión SSH (Secure Shell) al servidor Linux del IDeTIC, presentándose los datos en la terminal de comandos de UNIX, aunque la opción más rápida consiste en conectarse al servidor SFTP (SSH File Transfer Protocol) propio del IDeTIC y acceder a los ficheros donde están alojados los datos enviados por la API de MarineTraffic. Además, durante la elaboración de este Trabajo Fin de Máster se ha instalado una placa Raspberry Pi en la arqueta de comunicaciones en la que se ubica la estación AIS BMT-IDeTIC, que al conectarse al puerto serie del receptor AIS permite acceder a los datos que realmente recibe el receptor, y no aquellos que MarineTraffic muestra en su API. De este modo, es posible activar y configurar la Raspberry Pi a través de una conexión remota vía Telnet y posteriormente, extraer los datos sin tratamiento que recibe la estación AIS BMT-IDeTIC y almacenarlos en ficheros sobre el servidor Linux del IDeTIC, entre los que se encuentra la información emitida por el prototipo diseñado (figura 1.4). 81.3. Estructura de la memoria Receptor AIS BMT-IDeTIC Servidor de MarineTraffic Internet Procesado y tratamiento de los datos AIS recibidos Socket para BMT-IDeTIC Socket para otras estaciones Conexión Ethernet Ordenador personal Conexión SFTP Conexión SSH Petición de acceso Descarga de datos API MarineTraffic Raspberry Pi 3 Servidor Linux del IDeTIC USB Telnet Ethernet Figura 1.4: Comunicaciones desde la estación AIS BMT-IDeTIC Por último, el prototipo desarrollado se embarca en un dron experimental para estudiar su viabilidad de integración sobre estas aeronaves, haciendo uso de la instalación previamente comentada para la realización de las pruebas necesarias para alcanzar los objetivos de este Trabajo Fin de Máster. 1.3. Estructura de la memoria La memoria de este Trabajo Fin de Máster se organiza en función de siete capítulos, cuya temática se describe de forma breve en los siguientes puntos: Capítulo 1: se detallan los motivos y antecedentes que justifican el desarrollo de este trabajo, así como los objetivos planteados y la organización temática de la memoria. Capítulo 2: se introducen los conceptos fundamentales sobre los vehículos aéreos no tripulados, que son utilizados durante el resto de la memoria. Capítulo 3: se introducen los conceptos fundamentales sobre el sistema AIS, que son utilizados durante el resto de la memoria. 1. Introducción 9 Capítulo 4: se presenta el diagrama de bloques del prototipo, junto a los módulos que lo componen y la descripción técnica asociada a estos dispositivos. Capítulo 5: se explica la interconexión entre los módulos del prototipo y la programación de su firmware de control. Capítulo 6: se describen las pruebas llevadas a cabo para verificar el funcionamiento del prototipo, además de la infraestructura necesaria para apoyar las medidas llevadas a cabo. Capítulo 7: se detallan los resultados obtenidos y las conclusiones alcanzadas en virtud de los objetivos planteados, además de darse una visión global sobre las posibles líneas futuras que pueden originarse a partir de este prototipo. Además, se incluye la bibliografía empleada y el presupuesto que conlleva la ejecución de este Trabajo Fin de Máster. Del mismo modo, se incluyen como anexos toda aquella información relevante que no se detalla durante la redacción de los capítulos de esta memoria. 1.4. Vinculaciones del proyecto Se hace constar en este documento que parte del contenido y/o resultados que se presenten en este Trabajo Fin de Máster están sujetos a cláusulas de confidencialidad con la empresa MarineTraffic, lo que se declara a los efectos oportunos en virtud del vigente Reglamento de Trabajos Fin de Título de la Escuela de Ingeniería de Telecomunicación y Electrónica de la Universidad de Las Palmas de Gran Canaria. Capítulo 2 Sistemas UAV 2.1. Introducción Se conoce como UAV (Unmanned Aerial Vehicle) o dron a una aeronave que puede realizar diferentes tareas en vuelo sin necesidad de ser manejada por un piloto humano [18]. De esta manera, el usuario puede modificar el movimiento del dron a través de un protocolo de comunicación compartido entre el dron y una estación terrena de control. Además, estos vehículos aéreos suelen clasificarse en función de su estructura aerodinámica en tipo avión, con una estructura de aeronave de ala fija y orientados principalmente hacia usos militares, y tipo multicóptero, con una estructura de aeronave de ala rotatoria y utilizados en ámbitos muy diversos, como indica la figura 2.1. (a) UAV tipo avión (b) UAV tipo multicóptero Figura 2.1: Estructuras aerodinámicas de los UAVs 11 18 2.3. Descripción de la estación terrena Figura 2.8: Unidad de telemetría de 3D Robotics para drones Tabla 2.1: Características técnicas del módulo de telemetría de 3D Robotics Parámetro Valor Frecuencia 433 MHz Alimentación en transmisión 3.7 – 6 V, 100 mA Alimentación en recepción 3.7 – 6 V, 25 mA Velocidad de transmisión por radio 57.6 Mbps Velocidad de transmisión por cable 115.2 Mbps 2.3. Descripción de la estación terrena La estación terrena consta de un software que permite la configuración, control y monitorización del dron por medio de un protocolo de comunicaciones, que en el caso de los multicópteros suele ser MAVLink. En este sentido, en el mercado hay distintas opciones para implementar una estación terrena software, siendo las más habituales Mission Planner yAPM Planner. La estación terrena Mission Planner es la plataforma más utilizada con el controlador de vuelo ArduPilot. Se trata de una plataforma basada en software libre, únicamente disponible para Windows, que permite realizar operaciones en el dron tanto en el momento del vuelo como previamente (si es necesario modificar determinados parámetros para corregir su vuelo) o tras el aterrizaje (lo que permite revisar los pa- 2. Sistemas UAV 19 rámetros de vuelo y así corregir los posibles fallos que se produzcan). De esta manera, está habilitada para diferentes funcionalidades, entre las que destacan las siguientes: Introducir waypoint de Google Earth u otras plataformas similares. Configurar los ajustes del ArduPilot y cargar el firmware, en la versión que se desee. Seleccionar los comandos de misión mediante desplegables. Descargar los archivos de vuelo para su posterior análisis. Simular el vuelo del dron por medio de una interfaz gráfica ejecutada desde un ordenador personal. Por otro lado, la estación terrena APM Planner es una plataforma de software libre y disponible tanto para Windows como UNIX, con funcionalidades muy similares a las de Mission Planner y sin modificar en gran medida su interfaz, tal y como puede compararse en las figuras 2.9 y 2.10. Figura 2.9: Interfaz de Mission Planner Figura 2.10: Interfaz de APM Planner 2.4. Protocolo MAVLink El protocolo MAVLink (Micro Air Vehicle Link) es una biblioteca de mensajes que se utiliza para establecer un canal de comunicación entre un UAV y una estación base [22], tal y como se refleja en la figura 2.11. 20 2.4. Protocolo MAVLink Estación terrena Unidad UAV Unidad de telemetría de la estación terrena Unidad de telemetría de la unidad UAV Software de control de vuelo ArduPilot Figura 2.11: Elementos en una comunicación UAV-estación terrena con MAVLink Este protocolo puede utilizar determinadas funciones en un dispositivo integrado en un UAV y que va a recibir o enviar datos a la aeronave. De esta forma, permite importar cabeceras de ficheros sobre los scripts propios que ejecuta el dispositivo integrado en el dron, y de esta manera, extraer la información de la aeronave en todo momento. Estos ficheros están escritos en el lenguaje C, pero a través de una herramienta software llamada wrapper puede compatibilizar la programación en C con otros lenguajes de programación, como puede ser Python o Ruby. Por tanto, MAVLink es capaz de enviar tramas de datos a través del puerto serie hacia la estación terrena o hacia el UAV, permitiendo al usuario crear mensajes personalizados a los que se les asocia un código con una o más funciones. 2.4.1. Tipos de datos y tramas MAVLink Los tipos de datos con los que trabaja el protocolo MAVLink son caracteres (char), variables sin signo de 8 bits (uint8_t,int8_t), 16 bits (uint16_t,int16_t), 32 bits (uint32_t,int32_t)y64bits(uint64_t,int64_t), y números en coma flotante de 32 bits (float) y 64 bits (double), además de un tipo de variable sin signo de 8 bits propio de MAVLink que se rellena automáticamente, sin posibilidad de ser editado (uint8_t_MAVLink_version). A partir de estos tipos, el protocolo MAVLink puede intercambiar tramas o paquetes con una longitud comprendida entre 8 y 263 bytes, donde cada campo lo compone un byte dispuesto en una cadena de bytes que marca, a grandes rasgos, las cabeceras de la trama, el payload yelchecksum, tal y como se indica en la figura 2.12. 2. Sistemas UAV 21 SXT LEN SEQ SYS COMP MSG Payload CKA CKB Trama MAVLink (8 - 263 bytes) Figura 2.12: Formato de una trama MAVLink A continuación, se especifica el significado de cada uno de los campos que aparecen en la figura 2.12 y que presenta una trama MAVLink : STX, indica el comienzo de una nueva trama, pudiendo tomar los valores en hexadecimal 0xFE y0x55, dependiendo de la versión de MAVLink. LEN, indica el tamaño del payload, y puede tomar valores entre 0 y 255. SEQ, indica la secuencia de la trama y permite saber si se ha perdido algún paquete, tomando valores entre 0 y 255. SYS, es el identificador del sistema, es decir, del UAV o de la estación terrena, dependiendo cuál de los dos sistemas envía la trama. Puede tomar valores comprendidos entre 1 y 255. COMP, es el identificador del componente, es decir, de las unidades embarcadas en el dron o conectadas con la estación terrena. Puede tomar valores comprendidos entre 0 y 255. MSG, indica el número del identificador del mensaje, marcando el significado del payload y cómo debe ser decodificado. Puede tomar valores comprendidos entre 0 y 255. Payload, señala la información que se desea transmitir en el paquete MAVLink, y puede tomar valores comprendidos entre 0 y 255. CKA yCKB son los valores del checksum asociado a la trama MAVLink para su verificación de envío. 22 2.4. Protocolo MAVLink 2.4.2. Mensajes MAVLink La biblioteca de MAVLink integra un total de 108 mensajes específicos para UAV que permiten extraer determinados parámetros del dron [23], como puede ser su posición, la velocidad en cada una de las direcciones marcadas en un sistema de ejes cartesianos o sus ángulos de navegación. Sin embargo, en virtud de los objetivos de este Trabajo Fin de Máster, en este apartado solamente se evalúa un tipo de mensaje que permite extraer la información de los ángulos de navegación del UAV, denominado MAVLINK_MSG_ID_ATTITUDE. El mensaje MAVLINK_MSG_ID_ATTITUDE tiene el identificador 30 en la biblioteca MAVLink. Este mensaje permite extraer los valores de los ángulos de navegación del UAV expresados en radianes, así como la velocidad angular en radianes por segundo, tal y como se indica en la tabla 2.2. Tabla 2.2: Descripción de los campos del mensaje MAVLINK_MSG_ID_ATTITUDE Campo Tipo Descripción time_boo_ms uint32_t Tiempo en milisegundos desde que arranca el boot del sistema. roll float Valor angular del roll, expresado en radianes y con valores comprendidos entre +πy−π. pitch float Valor angular del pitch, expresado en radianes y con valores comprendidos entre +πy−π. yaw float Valor angular del yaw, expresado en radianes y con valores comprendidos entre +πy−π. rollspeed float Velocidad angular sobre el roll, expresada en radianes por segundo. pitchspeed float Velocidad angular sobre el pitch, expresado en radianes por segundo. yawspeed float Velocidad angular sobre el yaw, expresado en radianes por segundo. Cuando se necesita obtener los valores de los ángulos de navegación o la velocidad angular asociada, una opción muy extendida consiste en importar la biblioteca desarrollada por Lorenz Meier en C++, accesible desde GitHub [24], que permite llamar a las funciones que monitorizan los parámetros del dron y extraerlos. De este modo, las funciones que extraen los ángulos de navegación del UAV son las siguientes: 2. Sistemas UAV 23 Función getYaw(). Extrae el valor del yaw del UAV y lo retorna como un valor de tipo float. Función getPitch(). Extrae el valor del pitch del UAV y lo retorna como un valor de tipo float. Función getRoll(). Extrae el valor del roll del UAV y lo retorna como un valor de tipo float. Cabe señalar que el usuario puede modificar estas funciones para que la variable angular obtenida no esté expresada en radianes, sino en grados, realizando una simple conversión angular antes de devolver la variable. Capítulo 3 Sistema AIS 3.1. Introducción A raíz de la catástrofe naval del Titanic en 1912, la mejora de la seguridad de las travesías marítimas pasó a convertirse en un objetivo global donde se sumaron prácticamente todas las naciones de la Tierra. Como respuesta a este desastre, en 1914 se crea el Convenio SOLAS (Safety Of Life At Sea) para establecer aquellas normas y recomendaciones que, bajo consenso internacional, garantizaran la seguridad de los seres humanos al embarcarse en una travesía marítima [25]. De esta manera, en 1948 la ONU crea un organismo para regular la normativa internacional consensuada en el Convenio SOLAS, al que se le llama IMO (International Maritime Organization). El objetivo de este organismo es incorporar enmiendas y revisiones sobre los puntos establecidos en el Convenio SOLAS, además de promover tecnologías que favorezcan la seguridad marítima. En este sentido, el sistema AIS (Automatic Identification System) toma partida como un sistema valioso para monitorizar las embarcaciones en todo momento y así evitar posibles colisiones o accidentes de diversa índole en el mar [26]. Sin embargo, no fue hasta 1991 cuando se publica el primer documento acerca de las especificaciones técnicas del sistema AIS [27]. Este estándar, actualmente regulado por las autoridades marítimas de cada país, es propuesto por la ITU (International Telecommunication Union) a través de la recomendación ITU-R M.1371, que actualmente se encuentra en su quinta versión desde 2014 [28]. El sistema AIS se concibe 25 26 3.1. Introducción como un estándar internacional y de libre acceso, incorporado por un gran número de embarcaciones en la actualidad y desde 2002, obligatorio para los siguientes tipos de embarcaciones [29]: Cualquier embarcación con un tonelaje bruto superior a 500 toneladas. Embarcaciones con un tonelaje bruto de más de 300 toneladas y que realicen travesías internacionales. Cualquier buque destinado al transporte de pasajeros, independientemente de su tonelaje bruto. Dado que el propio estándar del sistema alude a una clasificación entre los dispositivos AIS clase A, de mayores prestaciones y costes elevados, y AIS clase B, con prestaciones y precios más moderados, son los equipos AIS clase A los que deben ser integrados de forma obligatoria en las embarcaciones que cumplan al menos uno de los requisitos anteriores. Sin embargo, hay embarcaciones no sujetas a esta normativa, como son los buques militares y aquellas embarcaciones que prestan un servicio no comercial a un Estado, que no están obligadas a identificarse en el sistema, pero sí pueden integrarlo si se considera oportuno. En definitiva, AIS es un sistema de radiocomunicación punto a punto en la banda de VHF, que cuenta con un esquema TDMA propio y que permite la identificación y monitorización de aquellas embarcaciones que disponen de un transpondedor de este sistema a bordo. Dicho de otra manera, permite a una embarcación con un transpondedor AIS conocer numerosos parámetros sobre el resto de embarcaciones que integran este sistema y se encuentran en su zona de cobertura, como pueden ser la posición, velocidad, rumbo o incluso, los puertos de origen y destino (figura 3.1) [30]. Con ello, cada embarcación está identificada de manera unívoca a través de un código de 9 dígitos decimales denominado MMSI (Maritime Mobile Service Identity), que es asignado por la autoridad marítima competente de cada país. En el caso de España, el organismo que asigna un MMSI a un equipo AIS mediante una solicitud previa es la Dirección General de la Marina Mercante. 3. Sistema AIS 27 Satélite GPS Embarcaciones con AIS clase A y AIS clase B Estación satelital AIS Satélite AIS Estación de control y vigilancia para tráfico marino Figura 3.1: Proceso de comunicación compartida entre estaciones AIS 3.1.1. Ventajas y desventajas El sistema AIS se reconoce como uno de los sistemas de comunicaciones marítimas de mayor relevancia debido a una serie de ventajas frente a otros sistemas con propósitos similares [31]. Algunas de las ventajas más importantes que presenta este sistema son las siguientes: Presenta una gran robustez frente a las adversidades meteorológicas (niebla, lluvia o calima, entre otros), el estado del oleaje y los elementos orográficos que circundan a la estación. El alcance máximo de un único transpondedor AIS puede llegar hasta 100 millas náuticas, aumentando considerablemente si existen nodos intermedios, además de existir cobertura satelital mediante satélites como ORBCOMM yexactEarth. Es un sistema autogestionado, de manera que cada estación controla el envío y la recepción de los mensajes, desvinculando su operatividad de las estaciones base. 34 3.2. Descripción del sistema Cabe señalar que la información transmitida influye en el periodo de envío de los mensajes junto a la clase de AIS del equipo. Cuando una embarcación está atracada en un puerto o no realiza ningún desplazamiento, la velocidad es nula y por tanto, los datos estáticos se envían cada 6 minutos, independientemente de la clase de AIS del equipo. Por el contrario, cuando una embarcación se desplaza durante una travesía o realiza alguna maniobra en el mar, sus datos dinámicos se actualizan en función de la velocidad de la embarcación, tal y como se presenta en la tabla 3.1. Tabla 3.1: Periodo de actualización de mensajes AIS en función de la velocidad Velocidad Periodo de actualización AIS clase A Inferiora3nudosparabuquesanclados o amarrados 3 minutos Superior a 3 nudos para buques anclados amarrados 10 segundos Entre 0 y 14 nudos 10 segundos Entre 0 y 14 nudos con cambio de rumbo 3 segundos Entre 14 y 23 nudos 6 segundos Entre 14 y 23 nudos con cambio de rumbo 2 segundos Superior a 23 nudos 2 segundos Superior a 23 nudos con cambio de rumbo 2 segundos AIS clase B Inferior a 2 nudos 3 minutos Superior a 2 nudos 30 segundos Comentarios 1nudo =0,514 m/s A excepción de AIS clase A y clase B, los otros tipos de AIS no dependen de la velocidad para fijar la tasa de actualización de mensajes. De este modo, el periodo de actualización de los equipos AIS SAR y las estaciones base AIS es de 10 segundos, mientras que el de AIS AtoN es de 3 minutos. 3.2.4. Tipos de mensajes AIS En la tabla 3.2 se presentan los tipos de mensajes AIS recogidos en la normativa y clasificados en función del identificador del tipo de mensaje que presentan. Este sistema cuenta con 63 mensajes en total, pero la normativa vigente solamente especifica los 27 primeros, indicando que del mensaje 28 al 63 se reservan para usos futuros. 3. Sistema AIS 35 Tabla 3.2: Clasificación de los tipos de mensajes AIS MSG ID Descripción de la información 1, 2, 3 Informe de posición de equipos AIS clase A 4 Informe de posición de estaciones base AIS 5 Datos estáticos y de viaje de equipos AIS clase A 6, 7, 8 Información de reconocimiento, binaria y broadcast 9 Posición de equipos SAR 10, 11 Información del tiempo UTC 12, 13, 14 Información binaria y de reconocimiento segura 15 Cambio al modo interrogación 16 Cambio al modo asignado 17 Información broadcast de la red GNSS 18, 19 Informe de posición normal y extendido de equipos AIS clase B 20 Reserva de slots para estaciones base AIS 21 Informe de posición de equipos AtoN 22, 23 Cambio a otros modos de las estaciones base AIS 24 Datos estáticos de equipos AIS clase A 25, 26 Información binaria no programada 27 Informe de posición para equipos AIS de largo alcance 3.3. Estándar NMEA0183 Desde el tercer cuarto del siglo XX, el creciente número de equipos de radiocomunicación a bordo de las embarcaciones comenzó a ser un problema para quienes tenían que lidiar con equipos de diferentes fabricantes o integrar nuevos equipos al sistema sin sustituir los antiguos. El número de cables que intervenían en la conexión de estos sistemas, además de las dificultades de configuración de algunos equipos, obligó a la asociación NMEA (National Marine Electronics Association), dedicada a la negociación de estándares para los productos electrónicos marítimos entre los distintos fabricantes, a establecer un protocolo que facilitara la operación de los usuarios con los sistemas a bordo de las embarcaciones. De este modo, en 1980 se propuso una primera versión de un estándar que permitía comunicar entre sí los equipos a bordo, independientemente del modelo del equipo, al que se llamó NMEA0180. Esta primera versión fue modificada dos años después con el estándar NMEA0182, hasta que finalmente, en 1983 se propuso el protocolo NMEA0183, convirtiéndose en el estándar de referencia para toda la electrónica naval. 36 3.3. Estándar NMEA0183 En la actualidad, este estándar es acogido por numerosos sistemas de comunicaciones navales, desde GPS hasta radares, entre los que destaca el sistema AIS. Sin embargo, aunque NMEA0183 sigue vigente en la actualidad, en los últimos años ha sido sustituido por la nueva versión NMEA2000 [35], aunque el proceso de sustitución no está tomando un ritmo muy acelerado, por lo que NMEA0183 sigue siendo la versión más utilizada. 3.3.1. Introducción El estándar NMEA0183 es el principal protocolo que siguen los equipos electrónicos navales para comunicarse entre sí. Se trata de un código de señales habilitado para transmitir y recibir datos de los equipos que se alojan en la embarcación. De esta manera, cuando un dispositivo opera bajo el estándar NMEA0183, interpreta el formato de los mensajes de este protocolo e identifica al equipo y la información que recibe. En lo que respecta a sus características físicas, este estándar opera a una tasa de símbolo de 4800 baudios a través de un bus serie, siguiendo un protocolo con un bit de start yunbitdestop, sin incluir ningún bit de paridad. Para la última versión de NMEA0183, los niveles de señal oscilan entre los +5y0V,aunquesisecrea una red de equipos conectados bajo este mismo protocolo donde algunos de ellos son equipos obsoletos, se puede incrementar la tensión hasta ±15 V. Generalmente, el estándar NMEA0183 diferencia para cada equipo un único talker y al menos un listener.Eltalker representa a las líneas de comunicación relativas a la transmisión, mientras que el listener se asocia a las líneas de comunicación en recepción, tal y como se presenta en la figura 3.7. Canal A, TX Canal B, TX Canal A, RX Canal B, RX Figura 3.7: Líneas de comunicación NMEA0183 genéricas para talker ylistener Cabe señalar que a pesar de ser un protocolo estandarizado, los fabricantes de equipos de radioelectrónica naval no han llegado a ningún consenso en lo que respecta 3. Sistema AIS 37 al código de colores de los cables del equipo. En este sentido, la norma general es que dado dos canales A y B, los canales de recepción toman colores blanco y marrón, mientras que los de transmisión son de color amarillo y verde, respectivamente. Sin embargo, hay una gran cantidad de equipos que no se guían por esta norma, de manera que lo recomendable es consultar siempre el manual de usuario del equipo. 3.3.2. Formato y tipos de mensajes De forma general, un mensaje NMEA presenta una estructura basada en un código ASCII de 6 bits donde se indica el tipo de dispositivo que transmite el mensaje, la información que se da a conocer al resto de los equipos con los que se comunica y la verificación del mensaje transmitido mediante el cálculo de un checksum, tal y como se indica a continuación: $yyXXX,ZZZZ...ZZ,Z*xx <0D><0A> !yyXXX,ZZZZ...ZZ,Z*xx <0D><0A> De esta manera, la interpretación de los distintos campos que conforman las posibles estructuras de mensajes NMEA presentadas anteriormente queda detallada en los siguientes puntos: $y!son los posibles delimitadores iniciales del mensaje. yy son 2 dígitos que indican el tipo de dispositivo que envía el mensaje. XXX son 3 dígitos que marcan el tipo de dato que contiene el mensaje. ZZZZ...ZZ son el contenido del mensaje, que dependen del tipo de mensaje y la información que se está transmitiendo en cada momento. xx son 2 dígitos hexadecimales de checksum, que se obtienen a partir del cálculo de la OR-exclusiva sobre los dígitos anteriores del mensaje, incluyendo las comas, salvo los delimitadores iniciales del mensaje. <0D><0A> son los dígitos hexadecimales de carriage return yline feed, respectivamente, y marcan la finalización del mensaje. 38 3.3. Estándar NMEA0183 En relación a este Trabajo Fin de Máster, los principales dígitos para la identificación de dispositivos son AI (referencian a dispositivos AIS), GP (referencian a la red GPS) y HE (referencian a dispositivos autónomos que envían comandos NMEA a otros dispositivos). 3.3.3. Ejemplos de mensajes NMEA Con el objetivo de incidir en la semántica de los comandos NMEA, a continuación se presenta un ejemplo de un mensaje NMEA transmitido por una estación AIS: !AIVDM,1,1,,B,13EmhtPP1:NqMAd@6Eoncww:0@FD,0*56 En el inicio del mensaje, el identificador !AIVDM indica que se trata de un mensaje transmitido por un equipo AIS (AI) en la banda de VHF por un equipo distinto al que lo transmite (VDM). Si fuera el propio equipo AIS el que transmite y recibe el mensaje, aparecería AIVDO. Con la sentencia consecutiva, 1,1„B, se sabe que el mensaje se recibe por el canal AIS-1 y es de tipo 1, correspondiente a los informes de posición, y que el equipo es de tipo AIS clase B. Respecto al contenido del mensaje, 13EmhtPP1:NqMAd@6Eoncww:0@FD, saber que es de tipo 1 posibilita la identificación de los valores que se reciben en función del formato del mensaje. Este contenido está codificado con 6 bits, de manera que se debe trasladar a un formato de 8 bits y asignar los valores binarios recibidos en función de los campos indicados por el estándar ITU-R M.1371-5. De este modo, los principales campos de interés de este mensaje son los siguientes: ID del mensaje:1 MMSI: 224227570 SOG (Speed Over Ground): 7.4 nudos Longitud: 15.4102567 grados Latitud: 28.1351983 grados 3. Sistema AIS 39 COG (Course Over Ground): 171.1 grados Por último, se indica el checksum del mensaje (0*56), que se calcula a partir de una OR-exclusiva iterada sobre cada uno de los valores que existen entre el preámbulo !y la última coma previa al checksum. Por tanto, se puede concluir que al tratarse de un informe de posición, es necesario obtener el identificador MMSI de la embarcación, las coordenadas donde se ubica y su velocidad y rumbo. Se puede realizar un ejercicio similar con los mensajes NMEA relativos a la red GPS, que al no estar codificados con 6 bits como los mensajes AIS, resulta más intuitiva su interpretación. Para ello, se supone el siguiente mensaje de ejemplo: $GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47 El identificador GPGGA al inicio del mensaje indica que se trata de información GPS (GP) para mejorar la precisión de la medida (GGA). Seguidamente, los datos que contiene el mensaje se interpretan de forma sencilla con los campos indicados a continuación: Tiempo UTC del sistema: 12:35:19 Latitud: 48d 07.038’ N Longitud: 01d 131.000’ E Longitud: 15.4102567 grados Indicador de calidad de precisión: 1 (GPS en modo estándar SPS) Número de satélites en cobertura:8 HDOP: 0.9 Altitud: 545.4 metros Altura geodésica para el modelo WGS84: 46.9 metros Al igual que con el resto de comandos NMEA, el último parámetro (*47) indica el checksum calculado a partir de los datos anteriores. Fundamentalmente, todos los 40 3.3. Estándar NMEA0183 datos introducidos en este mensaje muestran no sólo la ubicación de un punto sobre la Tierra, sino que también aportan información relevante para la mejora de la precisión de la información del GPS. Por último, otro ejemplo que destaca por su sencillez son los mensajes para dispositivos autónomos que se comunican a través del protocolo NMEA. Un ejemplo de estos mensajes es el siguiente: $HEHDT,214.5,T*2D En este ejemplo, el identificador $HEHDT indica que se trata de un dispositivo autónomo (HE) que indica su orientación angular en el plano (HDT). Por tanto, solamente es necesario indicar el ángulo de orientación, que es 214.5 grados, y finalizar el mensaje con el checksum calculado a partir de la información previa del mensaje. Capítulo 4 Desarrollo del prototipo 4.1. Diagrama de bloques El diagrama de bloques de la figura 4.1 expresa el prototipo que se desarrolla en este Trabajo Fin de Máster, que está formado por un microcontrolador BeagleBone Black y un transpondedor AIS clase B basado en el módulo Cobalt de SRT-Marine, además de las antenas de VHF marino y GPS. Transceptor AIS clase B SRT Marine Cobalt Microcontrolador BeagleBone Black Controlador de vuelo del drone ArduPilot Antena GPS Antena VHF Comandos MAVLink Comandos NMEA0183 Figura 4.1: Diagrama de bloques del prototipo En este diagrama, el dron comunica sus propios datos con formato MAVLink al microcontrolador BeagleBone Black mediante el módulo ArduPilot, vía puerto serie. De esta manera, los datos son recogidos por el microcontrolador y, mediante el firmware implementado en el microcontrolador, únicamente procesa los datos relativos a la orientación del dron. Con estos datos, el firmware construye un mensaje con formato NMEA y lo envía cada segundo por el puerto serie que va conectado al transceptor AIS clase B Cobalt, que finalmente envía estos mensajes a través de la antena VHF. 41 42 4.2. Transceptor AIS clase B Cabe destacar que el módulo Cobalt también emite de forma automática otros tipos de mensajes AIS relativos a la posición, velocidad y rumbo del dron, que los construye internamente a partir de la información que recibe de la antena GPS. 4.2. Transceptor AIS clase B 4.2.1. Introducción El módulo Cobalt de SRT-Marine [36] es un transpondedor AIS clase B completamente integrado en un dispositivo compacto, que permite transmitir mensajes AIS tipo 13, 18, 19 y 24, además de recibir la mayoría de tipos de mensajes AIS que describe el estándar ITU-M.1371-5 y decodificar los mensajes GPS. Se trata de un dispositivo de bajo consumo de potencia, tamaño reducido, y su flexibilidad lo establece como un candidato ideal para su adaptación y configuración en numerosas soluciones con el sistema AIS, que van desde su integración en transpondedores AIS comerciales hasta aeronaves y satélites. Este módulo dispone de un conector board-to-board Hirose DF13A-40DP-1.25V(91) en la parte superior de su estructura, que consta de 40 pines relacionados con la configuración y el control del mismo. A su vez, incluye dos conectores de RF Hirose U.FLR-SMT-1 en los que se conectan las antenas de VHF marítimo y GPS (figura 4.2). 70 mm 55 mm 13.8 mm Conector para antena GPS Conector para antena VHF Diodos LED para indicación de status Conector para interfaz serie y de alimentación Figura 4.2: Dimensiones y conectores del módulo Cobalt El conector Hirose DF13A-40DP-1.25V(91) permite al usuario acceder a las conexiones externas del módulo Cobalt, clasificadas de la siguiente forma (figura 4.3): 4. Desarrollo del prototipo 43 Conexiones de alimentación: relativas a las tensiones y corrientes externas que necesita el dispositivo para operar correctamente, además de un pin configurable que permite su activación. Conexiones de interfaces serie: incluye los puertos que emplea el estándar AIS (NMEA0183 y NMEA2000), además de los puertos USB, SPI y USER_IO. Conexiones de interfaces RF: referidas a los conectores para las antenas de VHF y GPS. 40 39 38 37 36 35 34 33 32 31 30 28 26 24 22 20 18 16 14 12 10 8642 1 3 5 7 9 11 13 15 17 19 21 23 2527 29 Interfaz de alimentación Toma de tierra Interfaz USER_IO Interfaz SPI Interfaz USB Interfaz NMEA0183 Interfaz NMEA2000 Sin conexión VIN(+) USER_IO_8 VIN(+) VIN(-) VIN(-) USER_IO_6 USER_IO_4 USER_IO_0 USER_IO_1 USER_IO_2 GND NMEA0183_TX1_A NMEA0183_TX1_B nAIS_OFF NMEA0183_RX1_A NMEA0183_TX2_A NMEA0183_TX2_B NMEA0183_RX2_A N2K_NET_C N2K_NET_C 3V3_EXT USER_IO_3 SPI_MISO GND USB_VBUS NC NMEA0183_RX1_B NMEA0183_RX2_B N2K_NET_L N2K_NET_H USER_IO_9 USER_IO_7 USER_IO_5 SPI_MOSI SPI_SCK SPI_SDIO_CS USB_DP USB_DM USB_GND GND Figura 4.3: Pines del conector Hirose DF13-40P-1.25V del módulo Cobalt 4.2.2. Conexiones de alimentación El módulo Cobalt se alimenta con tensiones continuas nominales de entrada comprendidas entre 9.6 V y 31.2 V. Para ello, este módulo dispone de 5 pines de alimentación en el conector Hirose DF13-40P-1.25V(91), además de los pines de referencia 50 4.3. Microcontrolador 4.3.4. Interfaces de comunicación y alimentación La placa BeagleBone Black cuenta con una serie de interfaces de comunicación que permiten la interconexión de la misma con otros dispositivos, o bien para su propia alimentación, tal y como se indica en la figura 4.8. Conector DC externa Conector Ethernet Debugger Conector micro-HDMI Tarjeta micro-SD Conector mini-USB Botón RESET Botón POWER Botón SWITCH Conectores de expansión Conector USB Figura 4.8: Conectores y botones de la placa BeagleBone Black De este modo, las interfaces externas y de alimentación de las que dispone esta placa son las siguientes: Conector de alimentación externa. Permite alimentar a la placa con 5 V y una corriente menor que 2 A, lo que resulta necesario a veces si se incorporan módulos o si se utilizan muchos puertos de entrada y salida, obligando a la placa a exceder los 500 mA del conector USB. Conector Ethernet. Mediante un conector RJ45 se provee a la placa de conexión a Internet, actuando como puerto Ethernet 10/100 o de alta velocidad sobre la red cableada. Conector micro-HDMI. Permite conectar a la placa una pantalla HDMI, soportando resoluciones de hasta 1920x1080 píxeles a 24 Hz. 4. Desarrollo del prototipo 51 Conectores mini-USB y USB. Por un lado, con estos conectores es posible alimentar a la placa sin necesidad del conector de alimentación externa, pero también es posible conectarse al sistema operativo de la BeagleBone Black mediante un puerto Ethernet virtual por SSH e intercambiar los datos que procesa. Además de los conectores mencionados anteriormente, la placa contiene dos ristras de conectores de expansión que proveen a la BeagleBone Black de 90 pines asociados a las interfaces ADC, PWM, GPIO, I2C y UART, además de los pines relativos a la alimentación y referencia a tierra (figura 4.9). Estos conectores permiten enlazar otros módulos y circuitos a la placa en función de la aplicación a desarrollar. P8 P9 Figura 4.9: Pinout de la placa BeagleBone Black La placa BeagleBone Black también cuenta con una serie de diodos LED integrados para indicar el estado de la placa y tres botones accesibles al usuario con las siguientes funcionalidades: RESET, para reiniciar el sistema operativo de la placa. POWER, que al presionarse permite a la placa tanto activarse como ponerse en modo suspensión, así como restaurar el estado del procesador. BOOT, que permite cambiar el modo de arranque de la placa, ya sea mediante la memoria FLASH integrada o desde la tarjeta microSD incorporada. 52 4.3. Microcontrolador 4.3.5. Configuración del dispositivo Para comenzar a programar una BeagleBone Black, el primer paso consiste en realizar una conexión SSH a través de la terminal de comandos hacia la dirección por defecto [email protected], que no incluye ninguna contraseña. También es posible asignar una dirección IP dentro de la subred donde se ubica la placa BeagleBone Black para realizar su configuración y programación sin necesidad de utilizar la dirección asignada por defecto. Una vez realizado este paso, es posible programar aquellos ficheros que se deseen ejecutar sobre la BeagleBone Black a través de tres posibles métodos: Mediante la programación de scripts en Python e importando sobre los mismos la biblioteca Adafruit_BBIO, haciendo uso del editor de textos nano que incorpora la distribución de Linux que integra la placa. A través de BoneScript, usando un lenguaje basado en JavaScript y el entorno de programación en la Nube Cloud9. Por medio de la programación de ficheros en C, accediendo al directorio de ficheros de Linux y usando el editor de textos nano. La primera de las tres opciones anteriores goza de mayor popularidad, dado que el lenguaje Python resulta sencillo para los usuarios con cualquier nivel de experiencia, además que la biblioteca que ofrece Adafruit satisface un gran número de funcionalidades de la placa. Para ello, basta con introducir el comando nano para abrir el editor de texto propio del sistema e incluir con un import la biblioteca de Adafruit al inicio del código. Una vez el script esté programado, se almacena asignándole un nombre seguido de la extensión .py y se ejecuta, mediante el comando python, seguido del nombre asignado a este script. En la figura 4.10 se presentan los pasos de conexión con la BeagleBone Black, así como la edición y ejecución de un fichero Python. 4. Desarrollo del prototipo 53 Conexión con la BeagleBone Black Apertura del editor de texto y ejecución del script programado en Python Figura 4.10: Conexión, edición y ejecución de un script en Python para BeagleBone Black Cuando se desea integrar la BeagleBone Black para controlar un sistema autónomo, suele ser conveniente modificar el fichero rc.local para que el script que se desea ejecutar una vez se inicie el programa, ubicado en home, sea lanzado tras el encendido de la placa. Para ello, se añaden las líneas señaladas en la figura 4.11 para forzar el arranque del script cuando se activa el sistema. Figura 4.11: Configuración de rc.local para el lanzamiento automático de scripts 54 4.4. Antena VHF 4.4. Antena VHF Con respecto a la selección de una antena de VHF marítimo apropiada para el prototipo desarrollado, se diferencia entre el modelo escogido para las pruebas iniciales, que incluye una base magnética de soporte, y la antena embarcada en el dron. De este modo, la antena de VHF marítimo escogida para las pruebas iniciales del prototipo presenta las características señaladas en la tabla 4.2, usando para su conexión con el módulo Cobalt un cable Hirose U.FL a SMA hembra, tal y como se presenta en el diagrama de la figura 4.12. Tabla 4.2: Parámetros de la antena de VHF con base magnética para el módulo Cobalt Parámetro Valor Impedancia 50 Ω Banda de frecuencia 156 – 174 MHz Frecuencia central 162 MHz Ganancia 1.5 dBi COE 1.2:1 Conector SMA macho Altura 400 mm Peso 60 g 400 mm Base magnética con diámetro de 25 mm SMA macho Conector U.FL a SMA para la conexión con el módulo Cobalt Figura 4.12: Modelo de antena de VHF con banda magnética seleccionado 4. Desarrollo del prototipo 55 Sin embargo, la selección de una antena de para AIS adecuada para ser embarcada en un dron, en lo que respecta al peso y las dimensiones, no es una tarea evidente. En la actualidad, se han realizado estudios para determinar si es viable utilizar la tecnología microstrip para implementar antenas de VHF propias para el sistema AIS [39], pero a nivel comercial no existen productos con estas características. Por ello, la antena escogida para este prototipo es el modelo Motorola PMAD4095A, que también se emplea para walkie-talkies en la banda de VHF marítimo (figura 4.13), y sus dimensiones, peso y características radio son aceptables, tal y como se indica en la tabla 4.3. Tabla 4.3: Parámetros de la antena de VHF Motorola PMAD4095A para el módulo Cobalt Parámetro Valor Impedancia 50 Ω Banda de frecuencia 160 – 174 MHz Frecuencia central 162 MHz Ganancia 2dB i COE 2:1 Conector SMA macho Altura 11 cm Peso 20 g 11 cm Conector SMA hembra Transición SMA-SMA macho para conectar la antena al cable Hirose U.FL-SMA Figura 4.13: Modelo de antena de VHF Motorola PMAD4095A Con el fin de caracterizar ambas antenas de una forma más precisa, en la figura 4.14 se presentan sus medidas de COE para la frecuencia de 162 MHz, realizadas a través de un analizador de redes. Para esta frecuencia, el COE se mantiene para la antena de VHF con base magnética, pero mejora considerablemente para la antena de VHF 56 4.5. Antena GPS portable con un COE de 1.4:1. (a) Medida de COE para antena de VHF con base magnética (b) Medida de COE para antena de VHF portable Figura 4.14: Medidas adicionales del COE sobre las antenas de VHF utilizadas 4.5. Antena GPS La antena de GPS escogida para este prototipo es el modelo Trimble 66800-52-SP, que presenta las características señaladas en la tabla 4.4. Esta antena se conecta con el módulo Cobalt a través de un cable Hirose U.FL a SMA hembra, tal y como se indica en la figura 4.15. Tabla 4.4: Parámetros de la antena de GPS Trimble 66800-52-SP para el módulo Cobalt Parámetro Valor Impedancia 50 Ω Frecuencia central 1575.42 MHz ±3MHz Polarización Circular COE 1.2:1 Conector SMA macho Dimensiones 37.4 mm ×34 mm ×12.9 mm Peso 25 g 4. Desarrollo del prototipo 57 Conector U.FL a SMA para la conexión con el módulo Cobalt SMA macho Antena GPS Látigo de 1 metro Figura 4.15: Modelo de antena de GPS Trimble 66800-52-SP Capítulo 5 Integración del prototipo 5.1. Interconexionado hardware Con el objetivo de conectar todos los módulos que deben incorporarse al prototipo, es necesario realizar dos etapas de integración. Previamente, es necesario realizar una integración básica de los módulos para verificar su correcto funcionamiento y estudiar las conexiones necesarias para habilitar las actividades que ejerce el prototipo. Finalmente, se realiza la integración de este prototipo en un dron experimental a partir de la sustitución de ciertos elementos inviables debido a su peso y tamaño, y posteriormente su ensamblado en la aeronave. La etapa previa a la integración y configuración del prototipo en un dron experimental exige que el elemento fundamental de este prototipo, que es el transpondedor AIS clase B basado en el módulo Cobalt, sea configurado de forma independiente con los datos estáticos (nombre, MMSI, tipo de vehículo...) solicitados previamente por la Dirección General de la Marina Mercante. De esta manera, el módulo Cobalt es capaz de transmitir sus datos al resto de estaciones AIS e identificarse en el sistema. En la figura 5.1 se representa el diagrama de bloques del montaje de integración inicial del prototipo desarrollado. 59 66 5.2. Firmware de control Captura de datos angulares del dron en MAVLink Creación de mensaje AIS tipo HDT sin checksum Cálculo del checksum de mensaje AIS tipo HDT Creación de mensaje AIS tipo HDT con checksum Envío del mensaje AIS tipo HDT por la UART Figura 5.7: Etapas del algoritmo para la creación y envío de un mensaje AIS tipo HDT En los siguientes puntos se explica cada una de estas fases y su implementación en Python. El código completo de este script se encuentra en el anexo D.1. 5.2.1. Captura de valores angulares La biblioteca MAVLink, al ser instalada en el controlador de vuelo del dron, permite acceder a toda la información paramétrica de la aeronave. Con ello, la lectura de los parámetros relativos a los ángulos de navegación de un dron se recogen en un fichero en C++ llamado attitude_module, que integra las funciones para capturar y devolver los valores de yaw,pitch yroll del dron, entre otros parámetros. Cuando este fichero se ejecuta, genera un fichero llamado attitude_execute donde se almacenan los valores actualizados de los ángulos de navegación del dron. Por tanto, en el script de Python donde se desarrolla el firmware de control del prototipo, se hace una llamada a este fichero con la función call, que habilita el uso de la función getYaw para la obtención de los valores actualizados del yaw del dron. 5. Integración del prototipo 67 1import os 2call(./attitude_execute , shell = true) 3yaw = get_yaw() 5.2.2. Creación de mensaje HDT Para la formación del mensaje HDT, se declara una variable llamada data como string que incluye la cabecera $HEHDT, junto al valor del yaw del dron capturado con la función getYaw() importada previamente y el parámetro true,T, que se ubica antes del cálculo del checksum. 1yaw = getYaw() 2data = "$HEHDT ," + yaw + ",T*" A partir de la formación de este mensaje, es posible obtener su checksum calculando de forma iterada la OR-exclusiva entre los caracteres consecutivos que se ubican en el campo de datos. Para ello, el código asociado a este cálculo determina, a partir de los delimitadores $ y !, el inicio del mensaje, mientras que el final se indica a partir del delimitador *. De esta manera, a partir de los datos ubicados entre ambos delimitadores, se calcula con un bucle la OR-exclusiva entre caracteres consecutivos del contenido del mensaje, y finalmente, se obtiene el checksum asociado. Por último, se vuelve a formar un string con el mensaje con checksum, que se almacena en la variable message. 1# inicializacion de inicio y fin de mensaje 2end = data.find(’*’) 3start = 0 4if data[0] in (’$’,’!’): 5start = 1 6if -1 != end: 68 5.2. Firmware de control 7data = data[start:end] 8else: 9data = data[start:] 10 11 # calculo de checksum 12 sum = 0 13 for kin data: 14 sum = sum ^ ord(k) 15 sumHex = "%x" % sum 16 if len(sumHex) == 1: 17 sumHex = ’0’ + sumHex 18 checksum = sumHex.upper() 19 message = data + "*" +str(checksum) 5.2.3. Envío de mensaje HDT por UART Una vez creado el mensaje HDT con el contenido del yaw yelchecksum asociado, se habilita el puerto serie UART1 de la BeagleBone Black para realizar la transmisión del mensaje hasta el módulo Cobalt. Para ello, es necesario importar desde la biblioteca Adafruit_BBIO las funciones relativas a la UART del dispositivo, y seguidamente habilitar la UART1 mediante la función setup. 1import Adafruit_BBIO.UART as UART 2 3# codigo del programa 4 5UART.setup("UART1") 5. Integración del prototipo 69 Seguidamente, se habilita el puerto ttyO1 de la placa y se le asocia una velocidad de 9600 baudios, de manera que es posible abrir y cerrar el puerto a partir de las funciones open yclose, respectivamente. 1ser = serial.Serial(port = ’/dev/ttyO1’, baudrate = 9600) 2ser.close() 3ser.open() Por último, se establece una condición que indica que si el puerto declarado está abierto, se escriba sobre éste el contenido del mensaje NMEA generado anteriormente. Para ello, es necesario declarar la condición mediante el uso de la función isOpen,que devuelve un valor verdadero siempre que el puerto asociado no haya sido cerrado, y finalmente escribir el mensaje HDT a través de la función write. 1if ser.isOpen(): 2ser.write(message) Capítulo 6 Verificación y pruebas del sistema 6.1. Introducción Tras la integración del prototipo en el dron experimental, se realizan diversas pruebas para verificar si el funcionamiento del prototipo diseñado presenta un comportamiento satisfactorio que permita su viabilidad de integración en un UAV. Para ello, es necesario realizar una instalación previa que permita verificar el envío de los mensajes AIS generados por el prototipo de una forma sencilla, y que además posibilite la recuperación de estos mensajes para su posterior análisis. A continuación, se describen brevemente las pruebas fundamentales que se llevan a cabo para la verificación del prototipo, además de la descripción de la instalación puesta a punto para la realización de las pruebas. Con ello, las pruebas realizadas en este punto se clasifican en dos grupos: Verificación de los mensajes transmitidos por el prototipo mediante la consulta de los ficheros almacenados, donde se analiza tanto la trama NMEA correspondiente al MMSI del prototipo, que es recibida en la estación AIS BMT-IDeTIC, como los datos extraídos tras solicitarlos a la API de MarineTraffic. Verificación gráfica de los mensajes transmitidos por el prototipo a partir de la aplicación OpenCPN y la plataforma web de MarineTraffic para la visualización de estaciones AIS. 71 72 6.2. Descripción de la instalación 6.2. Descripción de la instalación La instalación necesaria para realizar las pruebas de comunicación con el prototipo diseñado consta de dos elementos fundamentales, que son los siguientes: Arqueta de comunicaciones, donde se instala la estación receptora AIS BMTIDeTIC cedida por MarineTraffic, y que posteriormente envía sus datos como paquetes de red a través de una Raspberry Pi a la que se accede mediante una conexión Telnet. Servidor Linux, donde se alojan los scripts ejecutados para el almacenamiento y tratamiento de los datos recibidos por la estación receptor AIS BMT-IDeTIC. En la figura 6.1 se presenta el diagrama de bloques general de la instalación, con todos los elementos mencionados anteriormente, además del prototipo desarrollado. Otros equipos Receptor AIS BMT-IDeTIC Raspberry Pi Regleta Switch Scripts propios Conexión API MarineTraffic Conexión remota Ordenador personal Prototipo Fuente de alimentación Toma eléctrica Toma Ethernet Antena VHF Antena VHF Antena GPS Estación de pruebas AIS del Pabellón B (EITE, Campus de Tafira) Estación receptora AIS BMT-IDeTIC (Edif. Polivalente II, Campus de Tafira) Servidor Linux IDeTIC (Edif. Polivalente II, Campus de Tafira) Servidor MarineTraffic Conexiones serie Conexiones de red Alimentación Leyenda Figura 6.1: Instalación general del sistema de pruebas para el prototipo 6. Verificación y pruebas del sistema 73 6.2.1. Arqueta de comunicaciones del IDeTIC La instalación de la arqueta de comunicaciones del IDeTIC se ubica en la azotea del Edificio Polivalente II del Parque Científico y Tecnológico, en el Campus de Tafira (Las Palmas de Gran Canaria, España). En esta arqueta se incluyen diversos sistemas de comunicación utilizados por el IDeTIC, entre los que se encuentra la estación receptora AIS BMT-IDeTIC (figura 6.2), basada en un receptor AIS Comar SLR-300N. Receptor AIS Comar SLR-300N Raspberry Pi 3 Equipo switch Otros equipos de comunicación Regleta de alimentación Figura 6.2: Disposición de instalación de la arqueta de comunicaciones del IDeTIC A través de una conexión Ethernet, esta estación receptora envía sus datos a una dirección y un puerto del servidor de MarineTraffic, y por medio de una API los usuarios pueden acceder a la información AIS capturada por este dispositivo. Sin embargo, la orientación comercial de esta API cercena numerosos datos AIS que no son de interés comercial, y únicamente cuenta con aquellos mensajes que resultan significativos para un estudio estadístico del tráfico marítimo cercano a la estación o la recolección de datos para su posterior visualización gráfica en la plataforma web de MarineTraffic. Por ello, debido a la necesidad de acceder a todos los datos que recibe y decodifica la estación BMT-IDeTIC, se opta por incluir una placa Raspberry Pi 3 que, mediante una conexión serie con el receptor AIS, es capaz de capturar los datos AIS recibidos y ejecutar un daemon de Linux llamado ser2net, que convierte estos datos serie en 74 6.2. Descripción de la instalación paquetes de red. De esta manera, habilitando una conexión Telnet con la Raspberry Pi sobre una dirección IP y un puerto dados, es posible acceder a los datos desde la terminal de comandos de cualquier sistema operativo (figura 6.3). BMT-IDeTIC Raspberry Pi 3 Switch 12 V 5 V 12 V USB Ethernet Ethernet 230 V Figura 6.3: Conexiones en la estación receptora AIS BMT-IDeTIC dentro de la arqueta de comunicaciones del IDeTIC 6.2.2. Servidor Linux del IDeTIC Con el fin de almacenar los datos recibidos por la estación AIS BMT-IDeTIC, el IDeTIC cuenta con un servidor Linux instalado en el Edificio Polivalente II del Campus de Tafira, al que se puede acceder remotamente a través de una conexión SSH o SFTP, y que aloja los contenidos de los proyectos que se llevan a cabo en este centro. En este servidor se pueden ejercer dos vías de funcionamiento para la obtención y visualización de los datos recogidos por la estación AIS BMT-IDeTIC, que son los siguientes: A través de scripts propios en Bash, se puede realizar una llamada a la API de MarineTraffic para visualizar y almacenar los datos recogidos por la estación AIS BMT-IDeTIC. Mediante la implementación de scripts propios en Python, se pueden extraer y decodificar los mensajes AIS que salen del puerto serie de la estación AIS BMTIDeTIC y enviarlos a través de la utilidad ser2net como paquetes de red. Por un lado, los ficheros en Bash permiten obtener los valores de la API de MarineTraffic y almacenarlos en diferentes formatos, entre los que destacan los formatos CSV (Comma-separated values)yXML(eXtensible Markup Language). De esta manera, es posible volcar el registro de todos los mensajes AIS obtenidos por la estación AIS 6. Verificación y pruebas del sistema 75 BMT-IDeTIC sobre un fichero Excel o un servidor web, facilitando así su posterior consulta y tratamiento para diferentes aplicaciones. Por otro lado, el número masivo de mensajes recibidos por la estación AIS BMTIDeTIC provoca que la detección de aquellos mensajes propios del prototipo desarrollado resulte tediosa. Por ello, se justifica el desarrollo de los scripts en Python para poder recoger los mensajes AIS decodificados por el equipo de la estación AIS BMTIDeTIC a través de su puerto serie. Estos scripts permiten almacenar los mensajes AIS en bruto y evitar el cercenamiento que realiza MarineTraffic al filtrar únicamente aquellos campos que son de interés comercial. Los dos scripts en Python principales para este propósito son los siguientes: ais_bmtidetic.py, una biblioteca de libre acceso [40] que permite decodificar los mensajes AIS en formato NMEA que se introducen en su entrada. Originalmente, este script incluye una sección de código que permite dar distintos formatos a las tramas AIS, de manera que se elimina y se vuelca en un nuevo script denominado ais.py, al que se llama cuando se desee mostrar los datos AIS recibidos de forma desglosada u otras funcionalidades programadas en el mismo. servertel2.py, un código propio, incluido en el anexo D.2, que abre una conexión Telnet sobre una dirección y un puerto dados en donde la Raspberry Pi vuelca sucesivamente los datos recogidos vía puerto serie por la estación AIS BMT-IDeTIC. De este modo, filtra a través de una condición únicamente aquellos mensajes AIS que contengan un MMSI que coincida con el del prototipo, y finalmente los almacena en dos ficheros de texto junto con la fecha y hora de almacenamiento, que son los siguientes: -bmtidetic_file_parsed: se almacenan los mensajes AIS codificados con NMEA que son transmitidos por el prototipo desarrollado. -bmtidetic_file_raw: a partir de los mensajes AIS del prototipo, hace una llamada a una de las funciones del script ais_bmtidetic.py y vuelca el contenido decodificado de la trama AIS, presentado de forma tabulada. En la figura 6.4 se representa el flujo de ejecución de todos los scripts que se ejecutan para la realización de las pruebas presentadas a continuación. 82 6.3. Verificación y pruebas del prototipo integrado la instalación implementada para realizar las pruebas de verificación anteriores como a través de la API de MarineTraffic. En este último caso, cabe considerar que los datos decodificados están limitados en contenido, apareciendo únicamente aquellos campos más relevantes a nivel comercial. 6.3.3. Verificación mediante herramientas software de visualización de tráfico marítimo Otra forma de comprobar el funcionamiento del prototipo es a través de herramientas software destinadas a la monitorización de embarcaciones sobre mapas en tiempo real. En este sentido, las utilidades más conocidas son la plataforma web de MarineTraffic, de acceso gratuito salvo cuando se requiere una conexión satelital, y la aplicación gratuita OpenCPN, que permite el seguimiento de embarcaciones en tiempo real de forma similar a como opera la plataforma de MarineTraffic. Además, para cada una de estas utilidades existen apps para las plataformas Android e iOS, que permiten consultar el tráfico marino de una región o realizar el seguimiento de una determinada embarcación desde un dispositivo móvil. Esto supone una ventaja fundamental en términos de portabilidad frente a los ordenadores personales, en los que tradicionalmente se ejecutan estas utilidades software. Por tanto, conociendo el MMSI asignado al prototipo desarrollado, con identificador 111224515, y que el dron se ubica en el Campus de Tafira, en Gran Canaria, es posible trasladarse sobre esta región en la visualización de mapas de estas utilidades y consultar, entre las estaciones AIS que aparecen, cuál se corresponde con el prototipo desarrollado, que toma el nombre de IDETIC DRONE AIS. En la figura 6.5 se representa la identificación del prototipo sobre la aplicación web de MarineTraffic, donde se puede observar el identificador MMSI asignado y otros parámetros relevantes, como su velocidad y curso. 6. Verificación y pruebas del sistema 83 Figura 6.5: Identificación del prototipo sobre la plataforma web de MarineTraffic Por otro lado, a través del software OpenCPN es posible habilitar una conexión Telnet sobre la dirección y puerto asignados para la recepción de datos de la estación AIS BMT-IDeTIC, y posibilitar la visualización sobre una carta de navegación de la información transmitida por el prototipo (figura 6.6). Al igual que la plataforma de MarineTraffic, se presentan los valores más relevantes que transmite el prototipo, incluyendo además el campo HDT que indica el yaw de la aeronave. Figura 6.6: Identificación del prototipo sobre el software OpenCPN Capítulo 7 Conclusiones 7.1. Resultados y revisión de objetivos Tras la realización de las pruebas de verificación del prototipo, se puede concluir que los elementos que conforman el sistema son viables en función los objetivos planteados en este Trabajo Fin de Máster. De este modo, se ha logrado establecer un prototipo con capacidad para ser embarcado en un dron y transmitir su identificación a partir de sus datos estáticos y dinámicos, además de un parámetro adicional relativo a uno de los ángulos de navegación del dron mediante la creación de un mensaje AIS propio. Con ello, el módulo Cobalt cumple con las expectativas volcadas sobre el diseño preliminar del prototipo, de tal forma que en relación a los objetivos planteados en este trabajo, y también sobre futuras mejoras del prototipo, es un elemento hardware que se ajusta a las necesidades del prototipo. Del mismo modo, la placa BeagleBone Black ofrece suficiente potencia de procesamiento como para manejar la captura de datos del dron y el posterior envío de mensajes AIS propios, demostrando capacidad para adaptarse a la comunicación con el controlador de vuelo del dron a través del protocolo MAVLink. Por otro lado, algunos elementos integrados en el dron pueden ser sustituidos por otros más adecuados para futuras aplicaciones orientadas a la realización de pruebas de vuelo. En este sentido, la necesidad de incorporar dos baterías para hacer funcionar 85 86 7.2. Líneas futuras el prototipo afecta directamente al peso del dron, y por tanto, a su periodo de autonomía. Por este motivo, queda latente la necesidad de replantear el sistema para utilizar una única batería que abastezca tanto a la unidad transceptora AIS como al resto de elementos integrados en la aeronave. En este sentido, se requiere previamente una calibración precisa para integrar el prototipo en el dron, de forma que la reorganización de los módulos no afecten a la sustentación de la aeronave en ningún momento. En virtud de los objetivos planteados en este Trabajo Fin de Máster, las pruebas de verificación del prototipo han mostrado resultados favorables que han permitido identificar aquellos elementos sujetos a modificaciones, posibilitando su escalabilidad en pruebas futuras, principalmente en la fase de vuelo, y orientar su uso hacia un marco comercial con la colaboración de MarineTraffic. 7.2. Líneas futuras Tras la realización de este Trabajo Fin de Máster, se plantea la posibilidad de abrir otras líneas de trabajo a partir de los resultados obtenidos y el análisis de las virtudes y defectos detectados durante la realización de las pruebas de verificación del prototipo. Entre las posibilidades planteadas, destacan las siguientes: Realización de pruebas de vuelo con el prototipo embarcado en un dron experimental, analizando la ubicación del prototipo previamente para la correcta calibración de la aeronave. Estudio de la cobertura satelital del prototipo desarrollado para verificar si la señal puede ser recogida por la red de satélites AIS, sin necesidad de elementos hardware adicionales. Estudio de otros tipos de mensajes AIS, así como la implementación de mensajes propios adicionales que permitan la transmisión de otros parámetros relevantes del dron, como puede ser la altura a la que se encuentra durante el vuelo. Bibliografía [1] M. J. Boyle, “The costs and consequences of drone warfare,” International Affairs, vol. 89, no. 1, pp. 1–29, 2013. [2] Ó. Díaz Cantos, “Drones y su aplicación en materia de seguridad y salud en el trabajo,” 2015. [3] G. J. Knezo, “Possible impacts of major counter terrorism security actions on research, development, and higher education,” DTIC Document, 2002. [4] P. N.-C. Contreras, “Modalidades de contratación y empleo joven: novedades del Real Recreto-Ley 8/2014, de 4 de julio, de aprobación de medidas urgentes para el crecimiento, la competitividad y la eficiencia),” Actualidad laboral, no. 10, p. 1, 2014. [5] B. Ley, “18/2014,” Sección 6a, Artículo, vol. 50. [6] F. Bi and R. Mac, “Drone maker 3D Robotics raises $50 million in latest round. Forbes,” 2015. [7] R. TEC2014-60283-C3-2-R, “Frontal de RF direccional y de doble banda para drones ligeros multicópteros,” MINECO, Enero, 2015. [8] F. B. Ref. Sivu2015, “Sistema de visión umbral térmico georreferenciado. Aplicación al seguimiento de líneas de fuego en incendios forestales,” Ministerio de Agricultura, Alimentación y Medioambiente, Enero, 2015. [9] J. Batista, “Caracterización y evaluación de un UAV multirrotor para la obtención y georreferenciación de imágenes: estudio de viabilidad y demostrador,” Proyecto Fin de Carrera, Universidad de Las Palmas de Gran Canaria, Julio, 2014. 87 88 BIBLIOGRAFÍA [10] A. Trujillo, “Sistema de sujeción a líneas de alta tensión mediante UAV multirrotor: prueba experimental del sistema de guiado autónomo,” Trabajo Fin de Grado, Universidad de Las Palmas de Gran Canaria, Julio, 2014. [11] P. Mena, “Guiado de UAV multirrotor asistido por imagen: aplicación a un sistema de recarga distribuido,” Proyecto Fin de Carrera, Universidad de Las Palmas de Gran Canaria, Julio, 2015. [12] J. A. Godoy, “Planificación de ruta de vuelo de un UAV en tiempo real,” Trabajo Fin de Grado, Universidad de Las Palmas de Gran Canaria, Julio, 2015. [13] K. Hasegawa, K. Hata, K. Niwa, and J. Fukuto, “Transmission evaluation of Shipborne Automatic Identification System (AIS) in congested waterways,” in ITS Telecommunications, 2008. ITST 2008. 8th International Conference on, pp. 18– 23, IEEE, 2008. [14] B. J. Tetreault, “Use of the Automatic Identification System (AIS) for Maritime Domain Awareness (MDA),” in Proceedings of OCEANS 2005 MTS/IEEE, pp. 1590–1594, IEEE, 2005. [15] “Solicitud MMSI.” http://www.fomento.gob.es/MFOM/LANG_CASTELLANO/ DIRECCIONES_GENERALES/MARINA_MERCANTE/RADIOCOMUNICACIONES/MMSI/. Accessed: 2016-09-11. [16] F. Cabrera, N. Molina, M. Tichavska, and V. Arana, “Automatic Identification System modular receiver for academic purposes,” Radio Science, vol. 51, no. 7, pp. 1038–1047, 2016. 2015RS005895. [17] “Control de Operaciones de Dron a través del Sistema AIS. Premio Talento y Compromiso Cajasiete 2015.” https://www.researchgate.net/publication/ 289522517_Control_de_Operaciones_de_Dron_a_traves_del_Sistema_AIS_ Premio_Talento_y_Compromiso_Cajasiete_2015. Accessed: 2016-09-11. [18] A. Cavoukian, Privacy and drones: Unmanned Aerial Vehicles. Information and Privacy Commissioner of Ontario, Canada Ontario, Canada, 2012. BIBLIOGRAFÍA 89 [19] S. Franchini and Ó. L. García, Introducción a la ingeniería aeroespacial. Escuela Técnica Superior de Ingenieros Aeronáuticos, Universidad Politécnica de Madrid, 2008. [20] S. W. Space 1999 Telecom, “Convenio con WSN para la mejora de la autonomía de los UAVs,” BOULGPC, Junio, 2016. [21] B. Carrasco, J. Alberto, et al., “Integración de un UAV (vehículo aéreo no tripulado) en la plataforma robótica ARGOS,” 2015. [22] G. Crespo Quirós et al., “Sistema de enlace robusto para la teleoperación de un UAV (vehículo aéreo no tripulado) en la plataforma robótica ARGOS,” 2015. [23] L. Meier, J. Camacho, B. Godbolt, J. Goppert, L. Heng, M. Lizarraga, et al., “MAVLink: micro-air vehicle communication protocol,” Online]. Tillgänglig: http://qgroundcontrol. org/mavlink/start.[Hämtad 2014-05-22], 2013. [24] “MAVLink Protocol. GitHub repository with libraries..” https://github.com/ mavlink. Accessed: 2016-01-08. [25] K. Li and J. Wonham, “Maritime legislation: new areas for safety of life at sea,” Maritime Policy & Management, vol. 28, no. 3, pp. 225–234, 2001. [26] A. Harati-Mokhtari, A. Wall, P. Brooks, and J. Wang, “Automatic Identification System (AIS): data reliability and human error implications,” Journal of navigation, vol. 60, no. 03, pp. 373–389, 2007. [27] A. Norris, “AIS Implementation: success or failure?,” Journal of Navigation, vol. 60, no. 01, pp. 1–10, 2007. [28] Recommendation, “M.1371-5,” Technical characteristics for an automatic identification system using time-division multiple access in the VHF maritime mobile, vol. ITU-R, 2014. [29] K. Jaskólski, “Availability and integrity model of Automatic Identification System (AIS) information,” 2014. 90 BIBLIOGRAFÍA [30] P. R. Lei, T. H. Tsai, and W. C. Peng, “Discovering Maritime Traffic Route from AIS network,” in 2016 18th Asia-Pacific Network Operations and Management Symposium (APNOMS), pp. 1–6, Oct 2016. [31] N. R. C. U. C. for Evaluating Shipboard Display of Automated Identification Systems, Shipboard Automatic Identification System Displays: Meeting the Needs of Mariners. No. 273, Transportation Research Board, 2003. [32] “CML Microcircuits, Product Selector Catalogue, 2016.” http://www.cmlmicro. com/assets/CML_Product_Catalogue_September_2016.pdf. Accessed: 2016-1221. [33] N. Molina, “Diseño e implementación de un prototipo hardware para un banco de pruebas del estándar AIS,” Trabajo Fin de Grado, Universidad de Las Palmas de Gran Canaria, Julio, 2015. [34] G. Giuliano, “Shipboard Automatic Identification System Displays,” Transportation Research Board, Washington DC, p. 4, 2003. [35] K.-Y. Kim, D.-H. Park, J.-B. Shim, and Y.-H. Yu, “A study of marine network NMEA2000 for e-navigation,” Journal of the Korean Society of Marine Engineering, vol. 34, no. 1, pp. 133–140, 2010. [36] M. Robins, D. Reid, M. Clarke, and N. Emery, “SRT Marine Technology: Cobalt Integration Guide,” SRT Marine Technology Ltd, vol. LD3700, 2014. [37] “BeagleBone Black System: Reference Manual.” https://cdn-shop.adafruit. com/datasheets/BBB_SRM.pdf. Accessed: 2017-01-05. [38] M. Richardson, Getting Started with BeagleBone: Linux-powered Electronic Projects with Python and JavaScript. Maker Media, Inc., 2013. [39] T. Dousset, C. Renard, H. Diez, J. Sarrazin, and A. C. Lepage, “Compact patch antenna for Automatic Identification System (AIS),” in 2012 15 International Symposium on Antenna Technology and Applied Electromagnetics, pp. 1–5, June 2012. BIBLIOGRAFÍA 91 [40] “Christian Gagneraud library for AIS messages decode with python. GitHub repository with libraries..” https://github.com/ukyg9e5r6k7gubiekd6/gpsd/blob/ master/devtools/ais.py. Accessed: 2016-01-22. [41] BOULPGC, “Tabla de Contrataciones de Investigadores con cargo a Proyectos de Investigación aprobada el 21 de julio de 2012,” Año III, vol. 8. [42] “Reglamento de Radiocomunicaciones. Resoluciones y Recomendaciones, Edición de 2012.” http://www.itu.int/en/history/ HistoryDigitalCollectionDocLibrary/regulations/1.41.48.es.303.pdf. Accessed: 2016-12-25. [43] L. del Estado Español, “Real Decreto Legislativo 2/2011, de 5 de septiembre, por el que se aprueba el Texto Refundido de la Ley de Puertos del Estado y de la Marina Mercante,” Boletín Oficial del Estado, vol. 253, p. 20, 2011. [44] “Ley 14/2000 de 29 de diciembre. Medidas fiscales, administrativas y del orden social..” http://www.minhafp.gob.es/Documentacion/Publico/ NormativaDoctrina/Tributaria/IRPF/LEY%2014.00.pdf. Accessed: 2016-1225. [45] F. Cabrera, N. Molina, M. Tichavska, and V. Araña, “Design of a low cost prototype of Automatic Identification System (AIS) receiver,” in 2015 1st URSI Atlantic Radio Science Conference (URSI AT-RASC), pp. 1–1, May 2015. 98 P.3. Amortización del inmovilizado material Coste total 19,66 e Por tanto, el coste total de los materiales software fungibles empleados en este Trabajo Fin de Máster asciende a diecinueve con sesenta y seis euros. P.2.3. Otros conceptos de gastos materiales En la tabla P.3 se presentan los costes asociados a aquellos materiales que se adquieren, pero no se enmarcan en la categoría de hardware ni de software. Tabla P.3: Otros costes materiales Concepto Coste evaluado o estimado Material de oficina (folios, tinta de impresora) 80 e Asignación de MMSI para estación AIS 51,22 e Coste total 131,22 e Por tanto, el coste total de los materiales no enmarcados en las categorías hardware osoftware empleados en este Trabajo Fin de Máster asciende a ciento treinta y uno con veintidós euros. P.3. Amortización del inmovilizado material El inmovilizado material hace referencia a aquellos elementos que son utilizados durante la elaboración de este Trabajo Fin de Máster, pero pueden ser reutilizados para otros propósitos más adelante. De esta manera, los elementos que se engloban en esta categoría son utilizados durante el periodo de tiempo estipulado para el desarrollo del Trabajo Fin de Máster, que se conoce como tiempo de vida del producto, y con el tiempo reducen su valor adquisitivo inicial una cierta cantidad, que es lo que se conoce 99 como valor residual. Además, se debe ponderar el tiempo de ejecución del Trabajo de Fin de Máster, con una duración aproximada de 6 meses, sobre los valores obtenidos. De esta manera, para conocer el valor de amortización de los elementos enmarcados en esta categoría se les debe aplicar la ecuación P.1, Amortización =Va−Vr T·Tu=Va−k·Va T·Tu=Va·(1 −k) T·Tu(P.1) donde Vaes el valor adquisitivo inicial del producto, Vrel valor residual del producto (que se calcula considerando un porcentaje de desuso k=0,6sobre el valor adquisitivo inicial), Tes el tiempo de vida del producto y Tuel tiempo de uso del mismo, siendo este último un valor ponderado de 0,33 sobre todos los productos incluidos, debido a que se estima una duración de 4 meses para la realización del Trabajo Fin de Máster. En la tabla P.4 se indican aquellos materiales utilizados durante la elaboración de este Trabajo Fin de Máster y que se enmarcan en la categoría de inmovilizado material. Tabla P.4: Costes asociados al inmovilizado material Concepto Unidades Valor de adquisición Valor residual Vida útil Total Portátil MacBook Pro Retina 13.3” i5 512 GB 1 1.449 e869,4 e5años 38,25 e Fuente de alimentación PROMAX FAC662B 1 556,9 e334,14 e8años 9,19 e Estación de soldadura JBC 1 395 e237 e8años 6,52 e Antena VHF marino Shakespeare Marine 5202 2 105,40 e63,24 e10 años 2,78 e 100 P.4. Trabajo tarifado por tiempo empleado Cargador de baterías iMAX B6 LiPro Balance Charger 1 32,84 e19,7 e1año 4,33 e Ordenador Acer i5 512 GB con sistema operativo Linux 1 865 e519 e5años 22,84 e Receptor AIS Comar SLR 300N cedido por MarineTraffic 1 0 e0e8años 0e Analizador de redes HP 8753D 1 2.943 e1.765,8 e10 años 38,85 e Coste total 122,76 e Por tanto, el coste asociado al inmovilizado material empleado en este Trabajo Fin de Máster asciende a ciento veintidós con setenta y seis euros. P.4. Trabajo tarifado por tiempo empleado Para calcular el salario que debe percibir el autor de este Trabajo Fin de Máster, se toma como referencia la Tabla de Contrataciones de Investigadores con cargo a Proyectos de Investigación de la Universidad de Las Palmas de Gran Canaria, aprobada el 21 de julio de 2010 y publicada posteriormente en el BOULPG [41]. Se asume que el autor se enmarca en la clasificación de investigador en proyecto a tiempo parcial, con una titulación de ingeniero, de modo que su salario mensual es de 1.192,99 e. Dado que un Trabajo Fin de Máster tiene una duración límite de 300 horas, en la tabla P.5 se muestra el sueldo total que debe ganar el autor de este trabajo en función del número de horas dedicadas y el sueldo establecido por la institución mencionada. 101 Tabla P.5: Trabajo tarifado por tiempo empleado Categoría Sueldo mensual Número de horas trabajadas Sueldo por hora trabajada Sueldo final Ingeniero 1.192,99 e300 6,78 e2.033,51 e Por tanto, el salario que percibe el autor de este Trabajo Fin de Máster suma un total de dos mil treinta y tres con cincuenta y un euros. P.5. Aplicación de impuestos y coste total Dado que este Trabajo Fin de Máster se realiza en una institución integrada en la Comunidad Autónoma de Canarias, sobre los costes totales se debe aplicar el Impuesto General Indirecto Canario (I.G.I.C.), que se establece en un 7 % sobre los costes asociados, tal y como se indica en la tabla P.6. Tabla P.6: Costes totales del Trabajo Fin de Máster Concepto Coste Costes de materiales 3.467,88 e Amortización del inmovilizado material 122,76 e Trabajo tarifado por tiempo empleado 2.033,51 e Costes totales (sin I.G.I.C.) 5.624,15 e Costes totales (con I.G.I.C.) 6.017,84 e 102 P.5. Aplicación de impuestos y coste total El coste de este Trabajo Fin de Máster titulado Diseño de un prototipo para la identificación de drones mediante el sistema AIS, considerando la aplicación del I.G.I.C. sobre el coste final, asciende a un total de seis mil diecisiete con ochenta y cuatro euros. Fdo.: D. Nicolás Molina Padrón 6 de febrero de 2017 Las Palmas de Gran Canaria Parte III Anexos 103 Anexo A Procedimiento de asignación de un identificador MMSI La regulación determinada por la ITU en el Reglamento de Radiocomunicaciones de 1979 [42] y las autoridades competentes en materia de radiocomunicación de cada país obligan a que cualquier equipo AIS sea provisto de un identificador MMSI. En España, la asignación de este identificador lo lleva a cabo la Dirección General de la Marina Mercante, tanto para estaciones terrestres como dispositivos de ayuda a la navegación, entre los que se encuentra el sistema AIS, tal y como indican el Real Decreto Legislativo 2/2011 de 5 de septiembre [43] y la Ley 14/2000 de 29 de diciembre [44]. De esta manera, cualquier usuario en España que disponga de un transpondedor AIS, independientemente de la clase que sea o del ámbito de la aplicación a la que se destine, debe realizar una petición de asignación de MMSI a la Dirección General de la Marina Mercante por medio del siguiente procedimiento administrativo: 1. A través del acceso a la web del Ministerio de Fomento, el usuario debe rellenar un formulario con sus datos personales y/o de la institución solicitante, así como las características técnicas del equipo AIS que desea habilitar para transmitir (nombre de la estación, tipo de embarcación...). 2. Una vez el usuario completa el formulario, lo envía por medio de un correo electrónico a la dirección indicada en la página web, donde se evalúa la petición 105 106 realizada para posteriormente asignar el MMSI que mejor corresponda al equipo en función de su ámbito de aplicación. 3. Tras ser aceptada la solicitud, el usuario debe abonar las tasas correspondientes que indica el procedimiento administrativo de la web. Una vez abonadas las tasas, se envía por correo electrónico el número de MMSI que ha sido asignado y que puede ser usado desde ese momento. 4. Después de unas semanas, la Dirección General de la Marina Mercante también envía una carta con el impreso de solicitud y aceptación del MMSI sellado y firmado por el administrador correspondiente. A continuación, se muestra el documento de aceptación de la solicitud de MMSI que se ha tenido que realizar en este Trabajo Fin de Máster. Algunos de los campos señalados en el documento adjunto han sido omitidos por los autores de este trabajo por razones de privacidad. MINISTERIO DE FOMENTO ubdirección General de Seguridad. Contaminación e Inspección Marítima FCO. JOSÉ CABRERA ALMEIDA 35011 LAS PALMAS G.C. (LAS PALMAS) E RElARl1\ De F 'I \1)0 DE I FRAE TRl CI llltJ\S, fltAN POR rE V VI\ ILNDA OIRECCJÓ '(ihNI RAI IJJ L/\MARI AMl:R \1\11 Madrid, 16 de Noviembre de 2016 ASUNTO: ASIGNACIÓN DE MMSI Se informa de la asignación de Número de Identificación del Servicio Móvil Marítimo a la siguiente estación: Tipo de Estación: OTROS SERVICIOS -UNIDADES AÉREAS Nombre de la Estación: IDETIC DRONE AIS MMSI Asignado: 111224515 Esta asignación caduca el 30-12-2018, fecha en la que el MMSI deberá ser desprogramado del equipo y su baja comunicada al Área de Radiocomunicaciones Marítimas de la DGMM. Jefe del Area de Radiocomunicaciones Marítimas ••• MADRID Rlg -N"Doc:201611041741 FReg; N"Exp:201611020296 Dett: 996/000 D.G.M.M IHIHIIIIIHIIHll!fflHHUIIDIUIUlllil RUIZ DE Al.ARCO, 1 2�071 MADRID FAX 91 )9191 ,6 a conversion to AM modulated signal. Since the information is located in the envelope of the AM signal, an envelope detector enables demodulation of the modulated signal. The last stage uses a low-pass cutoff frequency of 7 kHz and is used to improve the selectivity of the demodulator filter. Finally, a receiver buffer to store data received during a certain period of time in order to adapt transmission rates to different types of protocols is added. The output data are obtained via the RXD pin at a speed which depends on the filing of the buffer. 3.2. Baseband GMSK Demodulation The DV-MEGA board is a shield for Arduino, designed to perform GMSK modulation and demodulation tasks baseband to speed 9.6 kbit/s. This board (Figure 4) consists of a CMX589A GMSK modem with external sync stages, also with filtered transmit and receive gain and PTT controller. 3.2.1. Modem GMSK CMX589A The CMX589A chip is encapsulated 24-pin designed by the company CML Microcircuits described as a GMSK baseband modem. This chip supports full-duplex and half-duplex communication modes and allows transmission rates between 4 kbit/s and 200 kbit/s. BT (Bandwidth per symbol period) has a configurable pin factor to select the values 0.3 and 0.5. This chip transmits and receives bit serial data with corresponding sync pin to be connected to the microcontroller for data transfer. Rx input levels can be set with external components around an on-chip Rx Input Amplifier. 3.2.2. Clock System CMX589A GMSK modem employs a synchronization circuit based on a crystal 9.8304 MHz. This crystal fixed clock signal 9.8304 MHz to set a bit rate of 9.6 kbit/s. For this, the value N= 1024 is set through ClkDivA and ClkDivB lines so that the value of the bit rate is RB¼fXTAL=N¼9:6 kbit=s (2) However, since the DV-MEGA board has a crystal oscillator of 4.9608 MHz, the desoldering and soldering of this crystal oscillator was necessary. A more detailed explanation of the process and the new oscillator is found in IDeTIC-AIS Github Repository (2016, https://www.github.com/IDeTIC-AIS/RX-AIS). 3.2.3. Rx Level Adjust System Two filters are placed on pin RxOut of CMX589A chip. The first of these filters is responsible for setting the bit rate output of the device, while the second low-pass filtering performs on the data and includes, via a potentiometer, the gain control to the modem output. In a first step, the passive RC filter low-pass first-order consists of the resistance R=47kΩand capacitor C= 470 pF determines the BT factor equal to 0.5, according to the selected bit rate, and eliminates Figure 4. DV-MEGA GMSK shield. Radio Science 10.1002/2015RS005895 CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1042 high-frequency noise. The second filter is an active low-pass filter based on an operational amplifier in inverting configuration. The gain of this filter is given by the ratio between the resistive values and thus depending on the output of the GMSK modem can adjust the signal level. The solution adopted is to put a fixed and a variable resistance so that we have a gain value between 7 dB and 10 dB. 3.2.4. Push to Talk The circuits Push to Talk (PTT) are integrated into systems for activating and deactivating RF subsystems transmitting and receiving in half-duplex mode. In this design, the activation signal is generated by the Arduino microcontroller. 3.3. Arduino Microcontroller Arduino is an open programmable hardware platform. It is based on a microcontroller and a development environment, including specific programming language Processing based, with a syntax similar to C ++. Arduino UNO R3 model integrates an ATmega328P microcontroller 32 KB of Flash memory, 2 KB of SRAM, and 1 KB of EEPROM. It has 14-pin digital input and output and 6 analog input pins that connect to other devices (shield) as the DV-MEGA board. It also has a serial port where programs are loaded and performs serial communications. After creating a setup() function, which initializes and sets the initial values, the interrupt service routine ISR() is responsible to decode AIS frames. This interrupt is enabled via clock lines DV-MEGA board. This routine reads the bits via pin RXD and identifies the start and stop flags to the store the data in the frame, as shown in Figure 5. Once stored, data are converted to NMEA format and through the routine loop() data are sent to the Front-End Unit via the serial port. 3.4. Front-End Unit The Front-End Unit has been implemented through the use of free and open software available that meets the requirements of our hardware. OpenCPN (OpenCPN web, 2016, http://www.opencpn.org) is a free software with GNU license that displays maps of any area through the use of OpenSeaMap (OpenSeaMaps web, 2016, http://www.openseamap.org) and allows an easy integration with our AISreceiving system by using serial port connection. OpenCPN decodes the data using NMEA [ISO/IEC 13239, 2002], visualizing it on the map and allowing the decode of 22 different types of messages. It also allows the implementation of the network layer allowing to send the NMEA sentences by using a TCP or UDP port. 4. Results As mentioned within the structure description of the paper, this section describes results of a preliminary performance test from the proposed modular receiver and an AIS commercially available receiver. This is to verify its correct operation. First, each module has been revised independently to ensure proper operation. Second, a test set has been performed in the laboratory to check the system operation. Finally, a proper operation has been verified with a live stream of AIS signals. The RX1 Radiometrix was verified through a comparison of a baseband signal generated by a function generator with the demodulated signal RX1 device. The GMSK demodulator was verified by mounting two DV-MEGA. The first generates a random GMSK signal and demodulates the second one. In Figure 6, the Figure 5. Simplified setup(),loop(), and ISR(). Radio Science 10.1002/2015RS005895 CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1043 different signals are shown. First, D0 clock signal is generated by the module. The D1 random sequence is transmitted from Arduino. D3 and D2 are the GMSK modulated and demodulated. It is noted that a match exists between the two signals having a propagation delay of 0.15 ms between D1 and D2. Figure 7 shows the prototype receiver finally implemented. This receiver has been tested using an AIS test system organized by a modular receiver equipment and other similar transmitter, where both devices are separated by a distance of 1 m. AIS frames sent in this test have been compared with the received frames. The 2250 time slots were used to verify that all had been correctly received. Once the modular receiver has been verified with real AIS frames, the developed prototype had been connected to a VHF maritime mobile band antenna located on the rooftop of the ULPGC Science and Technology Park (28.08°N/15.46°W). In Figure 8, the assembly is shown in the laboratory, by using the digital oscilloscope to display the received frames. Once stored, frames and changing the time base on the oscilloscope are shown in Figure 9 as the bitrate is 9.6 kbit/s. This signal passed through the Arduino microcontroller that performed the tasks of NRZ inverted decoding and data Figure 6. Random binary sequence in the DV-MEGA modem. Figure 7. A developed hardware receiver prototype. Radio Science 10.1002/2015RS005895 CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1044 extraction RxVector later to make the CRC checksum. The last step has been the conversion to the NMEA 0183 format and its transmission to the computer’s serial port. Table 1 shows an example of this message format and the most relevant parameters of the manual decoding (using ITU-R Rec.M.1371-5 [2014]) where the message ID (1) indicates the Position Report. Figure 10 shows the graphical representation of OpenCPN through a map of the Canary Islands where the number of vessels collected in real time is observed. Vessel information can be obtained by clicking on the icon of each. By clicking on the coordinates that have previously been manually decoded, it is found that there is a vessel in the same coordinates and time sharing the same MMSI number. This verifies that manual decoding has been performed satisfactorily. Furthermore, these results were revised again through the MarineTraffic network and data sent by the BMT-IDeTIC AIS terrestrial node. By using the OpenCPN software, AIS messages have been received from a coverage distance of up to 100 NM and a frequency of up to 300 messages per minute. The latter is below the maximum standard (2250). To use this software simultaneously by multiple users, OpenCPN has been configured as a server program using UDP Figure 8. Assembly of an AIS real test system. Figure 9. Demodulated AIS received signal. Radio Science 10.1002/2015RS005895 CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1045 port 3245 in a laboratory of 10 computers. Each computer can collect server information, allowing to perform measurements such as distance and routes. Finally, a comparative table with other receivers is shown in Table 2. This table reflects the prototype developed with the Comar SLR300N receiver (Comar System web, 2016, http://www.comarsystems.com/slr_300n.html) located in the same place and used as a node called BMT-IDeTIC in the MarineTraffic Network [Tichavska et al., 2015], DaisyAIS receiver (Tindie web, 2016, https://www.tindie.com/products/astuder/daisy-ais-receiver/), and RTL-SDR receiver (RTL-SDR web, 2016, http://www.rtl-sdr.com/rtl-sdr-tutorial-cheap-ais-ship-tracking/). It should be noted that all receivers get NMEA0183 messages at a rate of 38.4 kbit/s. Test results reflect that the receiver sensitivity developed has better features than others but has nevertheless been implemented in a single channel. The prototype as the Daisy-AIS and the RTL-SDR has not implemented the network layer, thus allowing an external program performing it. Finally, the cost of the developed prototype has been 125 €where the major cost has been covered by the DV-MEGA GMSK device. This price may be of course reduced if many units are purchased. The Front-End Unit has not been included since a unit dedicated to the AIS is not necessary. In a comparison with the other receivers it is noticeable that the prototype is cheaper than the SLR300N but more expensive than the Daisy-AIS and RTL-SDR. 5. Conclusions Within this paper, we propose and describe the implementation of an AIS terrestrial modular receiver, to be used for academic purposes. Also, we compare its performance with AIS general purpose receiving devices. The proposed modular design proves its use for education and student learning in areas such as electronic engineering, telecommunications, and maritime studies. The performance of the prototype also proves to be useful for the live reception of AIS frames at a not too expensive cost. Table 1. NMEA 0183 Frame and the Most Relevant Parameters Using a Manual Decoding NMEA 0183 frame !AIVDM,1,1,,A,13aN2dPOilNtC1L@@lf0g@`l0H=o,0*78 Parameter Value Message ID 1 MMSI 244810418 Speed over ground (SOG) 11.6 knots Longitude 14.789895° Latitude 28.421427° Course over ground (COG) 18.9° True heading 20° Figure 10. Data decoded and displayed on a map of the Canary Islands in the software OpenCPN. Radio Science 10.1002/2015RS005895 CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1046 Moreover and within this work, the process and firmware code to be used with a single hardware receiver has also been described and included as an open source, the latter to simultaneously visualize and map decoded AIS vessel traffic details within a network of computers and thus facilitate AIS-based research and the dissemination of regional vessel traffic-based knowledge. At last, results of this work motivate and support the implementation of a more accessible AIS-receiving node toward the potential advance of applied and theoretical research within the areas of innovative system architectures for the future internet of things, transport intelligent systems, Geographical Information Systems, hardware sensors, low-power computing, vessel and route efficiency, port optimization, among others. Indeed, AIS-data access, related research, and the advance of knowledge and science may allow unprecedented opportunities to a better understanding and the improvement of the blue territory and shipping, among others, throughout descriptive and predictive analytics applied to a more efficient, transparent, and green operations at sea and in ports. Also, it may facilitate the design, development, and implementation of computing systems and actionable intelligence services that further support maritime policy and management [Shelmerdine, 2016; Tichavska and Tovar, 2015a, 2015b]. References Eriksen, T., G. Hoye, B. Narheim, and G. Jenslokken (2006), Maritime traffic monitoring using a space-based AIS receiver, Acta Astronaut.,58, 537–549. ISO/IEC 13239 (2002), Information technology—Telecommunications and information exchange between systems—High-level data link control (HDLC) procedures, ISO. ITU-R Rec. M.1371-5 (2014), Technical characteristics for a universal shipborne Automatic Identification System using time division multiple access in the VHF maritime mobile band, ITU-R. ITU-R Rep. M.2123 (2007), Long range detection of Automatic Identification System (AIS) messages under various tropospheric propagation conditions, ITU-R Lanier, F. (2012), Practical sailor review feature loaded high-end VHFs, ICOM. Shelmerdine, R. L. (2016), Teasing out the detail: How our understanding of Marine AIS data can better inform industries, developments, and planning, Mar. Policy,54,17–25. Safety of Life at Sea (1974), , edited by International Maritime Organization, International Convention on the Safety of the Life at Sea. Tichavska, M., and B. Tovar (2015a), Port-city exhaust emission model: An application to cruise and ferry operations in Las Palmas Port, Transp. Res. A Policy Pract.,78, 347–360. Tichavska, M., and B. Tovar (2015b), Environmental cost and eco-efficiency from vessel emissions in Las Palmas Port, Transp. Res. E,83, 126–140. Tichavska M., F. Cabrera, B. Tovar, and V. Araña (2015), Use of the Automatic Identification System in academic research, EUROCAST 2015, LNCS 9520, pp. 33–40. Table 2. Comparative of Receiver Developed and Commercial Receivers (Comrad SMR300N, Daisy-AIS, and RTL-SDR) a Receiver Prototype SLR300N Daisy-AIS RTL-SDR Sensitivity 119 dBm 112 dBm 105 dBm 116.5 dBm No. of channels 1 2 2 1 Output format NMEA0183 NMEA0183 NMEA0183 NMEA0183 BaudRate 38.4 kbit/s 38.4 kbit/s 38.4 kbit/s 38.4 kbit/s Ethernet port No Yes No No Cost 125 €304 €76 €20 € a RTL-SDR sensitivity is an estimated value (IDeTIC-AIS Github Repository, 2016, https://www.github.com/IDeTIC-AIS/ RX-AIS). Radio Science 10.1002/2015RS005895 CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1047 Acknowledgments We would like to extend our acknowledgements to MarineTraffic and its team for actively contributing to every question raised and for supporting the verification of our results with the MarineTraffic BMT-IDeTIC AIS terrestrial node and also to Juan Domingo Santana Urbín (ULPGC) for his enormous contribution during the development phase of the AIS receiver prototype. At last, the authors would like to thank the reviewers for the valuable comments and suggestions that have enabled the quality improvement of this paper. The source code of the firmware, PCB layout, and two technical notes may be accessed for future academic and research projects at https://www.github.com/IDeTIC-AIS. 120 Anexo C Vistas del software proAIS2 El software proAIS2 se utiliza para configurar y monitorizar la información recibida y transmitida por los módulos AIS de la compañía SRT-Marine, entre los que se encuentra el transceptor AIS clase B Cobalt. Para ello, el usuario tiene a su disposición cinco vistas con las que interaccionar con el módulo, y son las siguientes: Configuración del módulo (Configuration). Monitorización de señal GNSS (GNSS Status). Monitorización de embarcaciones (Other Vessels). Verificación de estado del dispositivo (Diagnostics). Terminal de comandos recibidos y transmitidos (Serial Data). En la figura C.1 se presenta un ejemplo de la vista de configuración del módulo Cobalt. Además de los campos para indicar los puertos a los que se conecta el dispositivo (AIS Virtual COM) y el botón de escritura de la configuración (Write configuration), cuenta con los siguientes campos principales: Vessel Details, que permite al usuario introducir los datos estáticos del dispositivo, como son el nombre de la embarcación, el identificador MMSI, el código de llamada digital selectiva y el tipo de embarcación sobre la que se embarca el 121 122 módulo. Además, es posible configurar de forma gráfica la posición de la antena de GPS en la embarcación. Configure Baud Rate, que permite configurar la velocidad de transmisión a la salida de los canales NMEA1 y NMEA2 del módulo. Figura C.1: Vista de configuración en proAIS2 Por otro lado, en la figura C.2 se presenta un ejemplo de la vista de monitorización de la señal GNSS, que dado que el módulo Cobalt utiliza habitualmente una antena de GPS para extraer su ubicación y procesar a partir de esta información los comandos NMEA, se puede concebir como una monitorización de la red GPS sobre el dispositivo Cobalt. En esta vista, el usuario puede reconocer de forma gráfica los niveles de señal de la relación portadora-ruido de la red GPS, así como conocer otros parámetros de importancia en la cobertura GNSS como son el tiempo UTC (Universal Time Coordinated), la latitud y longitud donde se ubica el dispositivo, los parámetros COG (Course Over Ground)ySOG(Speed Over Ground) y el número de satélites utilizados para establecer la ubicación del módulo sobre la superficie terrestre. Tal y como aparece en la figura C.3, la vista de monitorización de embarcaciones permite al usuario observar todas aquellas embarcaciones que disponen de un equipo AIS y emiten sus datos en la misma zona de cobertura donde se ubica el módulo Cobalt. De esta manera, la interfaz de esta vista muestra el nombre comercial de C. Vistas del software proAIS2 123 Figura C.2: Vista de monitorización de señal GNSS en proAIS2 la embarcación junto a otros datos de mayor relevancia, como son la clase de AIS del equipo, la velocidad y el rumbo de la embarcación, la ubicación en función de la latitud y longitud, y otros parámetros relacionados con la señal AIS y el alcance. Figura C.3: Vista de monitorización de embarcaciones en proAIS2 En la figura C.4 se muestra un ejemplo de la vista de verificación del estado del módulo Cobalt, que permite conocer si se han realizado las conexiones con las interfaces del módulo y si transmite y recibe correctamente los mensajes AIS. Para ello, esta vista presenta los siguientes campos: