Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Escuela de Ingeniería de
Telecomunicación y Electrónica
Trabajo Fin de Máster
Diseño de un prototipo para la identificación dedrones mediante el sistema AIS
Titulación: Máster Universitario en Ingeniería deTelecomunicaciónAutor: D. Nicolás Molina PadrónTutores: Dr. Francisco José Cabrera Almeida
Dr. Víctor Alexis Araña PulidoFecha: 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 dedrones mediante el sistema AIS
Hoja de Firmas
Firma de los tutores
Fdo.: Dr. Francisco JoséCabrera Almeida
Fdo.: Dr. Víctor AlexisArañ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 dedrones 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 general
I Memoria 1
1. Introducción 3
1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Vinculaciones del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Sistemas UAV 11
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Descripción de la aeronave . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Descripción de la estación terrena . . . . . . . . . . . . . . . . . . . . . 18
2.4. Protocolo MAVLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1. Tipos de datos y tramas MAVLink . . . . . . . . . . . . . . . . 20
2.4.2. Mensajes MAVLink . . . . . . . . . . . . . . . . . . . . . . . . . 22
xi
xii ÍNDICE GENERAL
3. Sistema AIS 25
3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1. Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2. Dispositivos comerciales . . . . . . . . . . . . . . . . . . . . . . 28
3.2. Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1. Características radio y de enlace . . . . . . . . . . . . . . . . . . 30
3.2.2. Esquema de acceso al medio . . . . . . . . . . . . . . . . . . . . 31
3.2.3. Estructura de mensajes AIS . . . . . . . . . . . . . . . . . . . . 32
3.2.4. Tipos de mensajes AIS . . . . . . . . . . . . . . . . . . . . . . . 34
3.3. Estándar NMEA0183 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2. Formato y tipos de mensajes . . . . . . . . . . . . . . . . . . . . 37
3.3.3. Ejemplos de mensajes NMEA . . . . . . . . . . . . . . . . . . . 38
4. Desarrollo del prototipo 41
4.1. Diagrama de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2. Transceptor AIS clase B . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2. Conexiones de alimentación . . . . . . . . . . . . . . . . . . . . 43
4.2.3. Conexiones de interfaces serie . . . . . . . . . . . . . . . . . . . 44
ÍNDICE GENERAL xiii
4.2.4. Conexiones de RF . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.5. Configuración del dispositivo . . . . . . . . . . . . . . . . . . . . 46
4.3. Microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.2. Microprocesador . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.3. Unidad de memoria . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.4. Interfaces de comunicación y alimentación . . . . . . . . . . . . 50
4.3.5. Configuración del dispositivo . . . . . . . . . . . . . . . . . . . . 52
4.4. Antena VHF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5. Antena GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5. Integración del prototipo 59
5.1. Interconexionado hardware . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1. Configuración del transpondedor AIS clase B . . . . . . . . . . . 61
5.1.2. Montaje del prototipo inicial . . . . . . . . . . . . . . . . . . . . 62
5.1.3. Integración del prototipo en un dron experimental . . . . . . . . 64
5.2. Firmware de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.1. Captura de valores angulares . . . . . . . . . . . . . . . . . . . . 66
5.2.2. Creación de mensaje HDT . . . . . . . . . . . . . . . . . . . . . 67
5.2.3. Envío de mensaje HDT por UART . . . . . . . . . . . . . . . . 68
xiv ÍNDICE GENERAL
6. Verificación y pruebas del sistema 71
6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2. Descripción de la instalación . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2.1. Arqueta de comunicaciones del IDeTIC . . . . . . . . . . . . . . 73
6.2.2. Servidor Linux del IDeTIC . . . . . . . . . . . . . . . . . . . . . 74
6.3. Verificación y pruebas del prototipo integrado . . . . . . . . . . . . . . 76
6.3.1. Verificación de mensajes AIS transmitidos y recibidos . . . . . . 77
6.3.2. Comparativa de resultados obtenidos a través de la API de Ma-
rineTraffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.3.3. Verificación mediante herramientas software de visualización de
tráfico marítimo . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7. Conclusiones 85
7.1. Resultados y revisión de objetivos . . . . . . . . . . . . . . . . . . . . . 85
7.2. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
II Presupuesto 93
Presupuesto 95
P.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
P.2. Costes de materiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
P.2.1. Materiales hardware . . . . . . . . . . . . . . . . . . . . . . . . 96
ÍNDICE GENERAL xv
P.2.2. Materiales software . . . . . . . . . . . . . . . . . . . . . . . . . 97
P.2.3. Otros conceptos de gastos materiales . . . . . . . . . . . . . . . 98
P.3. Amortización del inmovilizado material . . . . . . . . . . . . . . . . . . 98
P.4. Trabajo tarifado por tiempo empleado . . . . . . . . . . . . . . . . . . 100
P.5. Aplicación de impuestos y coste total . . . . . . . . . . . . . . . . . . . 101
III Anexos 103
A. Procedimiento de asignación de un identificador MMSI 105
B. Divulgación de resultados 109
C. Vistas del software proAIS2 121
D. Lista de códigos implementados 127
D.1. Generación y envío de mensajes HDT propios del prototipo . . . . . . . 127
D.2. Almacenamiento y filtrado de mensajes AIS recibidos del prototipo . . 129
Í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 y listener . . 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 ar-
queta 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 pro-
totipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Identi-
fication 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
xxvi ÍNDICE DE TABLAS
For that purpose, IDeTIC (Instituto para el Desarrollo Tecnológico y la Innovación
en Comunicaciones) proposes in this research project an exploitation of AIS system to
identify UAVs by means of an embedded prototype in an experimental drone, which
enables to identify itself and transmit the most important parameters autonomously.
This solution, that has a lot of advantages in terms of range and price, allows to
substitute the traditional method for drones identification that is used nowadays, and
solves the main problems which entangles the previous solution.
After the implementation and verification of the prototype, the tests carried out
show successful results which allow to conclude that this prototype is suitable and
show the potential benefits of adopting this system for commercial applications. For
these reasons, beyond the results which have been obtained in this work, some future
improvements for this prototype have raised to achieve a higher impact and so, propel
the definitively substitution of the tradicional method for UAV identification.
Keywords: AIS (Automatic Identification System), Drone, MMSI (Maritime Mobile
Service Identity), Prototype, UAV (Unmanned Aerial Vehicle).
Acrónimos
Siglas Descripción
ADC Analog-to-Digital Conversion
AIS Automatic Identification System
API Application Programming Interface
AtoN Aids-to-Navigation
COE Coeficiente de Onda Estacionaria
COG Course Over Ground
CSTDMA Carrier-Sense Time Division Multiple Access
CSV Comma-Separated Values
DDR3 Double Data Rate type three Synchronous Dynamic
Random-Access Memory
eMMC Embedded Multi-Media-Card
ESC Electronic Speed Control
FATDMA Fixed-Access Time Division Multiple Access
FM Frequency Modulation
GMSK Gaussian Minimum-Shift Keying
GNSS Global Navigation Satellite System
GPIO General Purpose Input/Output
GPS Global Positioning System
HDMI High-Definition Multimedia Interface
HDOP Horizontal Dilution of Precision
HDT Heading True
I2C Inter-Integrated Circuit
xxvii
xxviii ÍNDICE DE TABLAS
IDeTIC Instituto para el Desarrollo Tecnológico y la Innovación en
Comunicaciones
IMO International Maritime Organization
IMU Inertial Measurement Unit
IP Internet Protocol
ITDMA Incremental Time Division Multiple Access
ITU International Telecommunication Union
LiPo Lithium Polymer
MISO Master Input Slave Output
MMSI Maritime Mobile Service Identity
MOSI Master Output Slave Input
NMEA National Marine Electronics Association
NRZI Non-Return to Zero Inverted
OSI Open System Interconnection
PWM Pulse-Width Modulation
RATDMA Random Access Time Division Multiple Access
RF Radio Frequency
RISC Reduced Instruction Set Computer
SAR Search and Rescue
SART Search and Rescue Transponder
SFTP SSH File Transfer Protocol
SPI Serial Peripheral Interface
SPS Standard Positioning Service
SOG Speed Over Ground
SOLAS Safety of Life at Sea
SOTDMA Self-Organized Time Division Multiple Access
SRAM Static Random Access Memory
SSH Secure Shell
TDMA Time Division Multiple Access
UART Universal Asynchronous Receiver-Transmitter
UAV Unmanned Aerial Vehicle
USB Universal Serial Bus
ÍNDICE DE TABLAS xxix
UTC Universal Time Coordinated
VHF Very High Frequency
WGS84 World Geodetic System 84
Parte I
Memoria
1
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 única-
mente 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 preocupa-
ció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 res-
tricció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 esta-
blecen 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
4 1.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 sobrevo-
lando 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 nue-
va 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 nacio-
nales 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 aplica-
ciones 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 comuni-
caciones 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 supe-
rior 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].
6 1.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 proto-
tipo 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, ade-
má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ÁTICODEL UAV MICROCONTROLADOR TRANSCEPTOR AIS
CLASE B ANTENAVHF
ANTENAGPS
Figura 1.3: Diagrama de bloques del prototipo
Cuando el prototipo envía sus datos, la estación receptora AIS BMT-IDeTIC, ins-
talada 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 servi-
dor 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, aun-
que 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).
8 1.3. Estructura de la memoria
Receptor AISBMT-IDeTIC
Servidor deMarineTrafficInternet
Procesado y tratamientode los datos AIS recibidos
Socket paraBMT-IDeTIC
Socket paraotras estacionesConexión
Ethernet
Ordenadorpersonal
ConexiónSFTP
ConexiónSSH
Peticiónde acceso
Descargade datos
APIMarineTraffic
Raspberry Pi 3
Servidor Linuxdel 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 es-
tudiar 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 funcio-
namiento 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 ejecu-
ció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 Teleco-
municació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
12 2.1. Introducción
En lo que respecta a los drones tipo multicóptero, es importante señalar que existe
otra clasificación en función del número de elementos rotatorios que presente. En la
figura 2.2 se presentan algunos de estos dispositivos, clasificados a razón de su número
de rotores como simples o dobles.
Tricóptero simple Cuadricóptero simple Hexacóptero simple
Octacóptero simple Tricóptero dedoble rotor
Cuadricóptero dedoble rotor
Figura 2.2: Clasificación de drones tipo multicóptero
Al igual que ocurre con cualquier aeronave, un dron está sujeto a tres movimientos
angulares en el espacio, denominados ángulos de navegación, y son yaw, pitch y roll
[19], tal y como se presenta en la figura 2.3, y cumplen las siguientes características:
Yaw. También llamado guiñada, es el movimiento angular sobre el eje vertical
perpendicular a la aeronave, y permite conocer el rumbo de la misma.
Pitch. También llamado cabeceo, es el movimiento angular sobre el rumbo de la
aeronave, que puede marcar su inclinación por delante o por detrás, indicando si
se encuentra en ascenso o descenso.
Roll. También llamado alabeo, es el movimiento angular sobre el rumbo de la
aeronave, que marca la inclinación a izquierda o derecha de las alas o los rotores, y
permite a la aeronave sortear obstáculos o estabilizar su vuelo frente a condiciones
ambientales adversas.
2. Sistemas UAV 13
Yaw
Pitch
Roll
Figura 2.3: Ángulos de navegación en un UAV
En la actualidad, los drones tipo multicóptero gozan de autonomía suficiente para
desempeñar las tareas que un usuario les planifique. En este sentido, la automatización
de los UAVs es el factor primordial que persiguen las empresas de base tecnológica que
emplean esta tecnología, lo que trasciende en un gran número de aplicaciones, tanto
civiles como militares, donde el uso de estos dispositivos comienza a ser indispensa-
ble para determinadas tareas. Sin embargo, el principal problema que presenta esta
tecnología radica en la eficiencia y duración de las baterías, y sobre este aspecto, el
IDeTIC mantiene un convenio con la compañía WSN para evaluar nuevos métodos que
favorezcan la autonomía energética de estos dispositivos [20].
En lo que respecta al ámbito comercial, la compañía 3D Robotics se sitúa en los
primeros ranking de ventas de la tecnología UAV, principalmente en la gama de drones
multicópteros. Esta compañía opera desde 2007 y es pionera en la democratización
de los drones, dado que entre su línea de productos destacan los equipos de montaje
por piezas de drones, que no solamente permiten al usuario adquirir destreza en el
montaje de drones, sino que ofrece total libertad para modificar los diseños iniciales
hasta conseguir la unidad de vuelo que el usuario desee. Además, 3D Robotics mantiene
unos precios considerables en su gama de productos, ya que no solamente pretende
que estos drones sean utilizados en entornos empresariales o académicos, sino incluso
como entretenimiento, ofertando también piezas de recambio y módulos adicionales
compatibles con sus modelos.
14 2.2. Descripción de la aeronave
2.2. Descripción de la aeronave
Los drones están diseñados para cumplir tareas similares a las que haría una aerona-
ve de pequeño tamaño, facilitando su control y despliegue. Por ello, puede desgranarse
en cinco elementos fundamentales sobre una misma estructura física, que son:
Estructura de soporte.
Unidades de propulsión y sustentación.
Unidad de alimentación.
Controlador de vuelo.
Módulo de comunicaciones vía radio.
A continuación, se explica cada uno de estos elementos del dron desde la óptica de
la tecnología desarrollada por 3D Robotics, dado que no solamente es la que mayor
extensión de uso presenta hoy día, sino que además el grupo de investigación en materia
de UAVs del IDeTIC utiliza los productos de este fabricante para desarrollar diversas
aplicaciones embarcadas en drones multicópteros.
Estructura de soporte
Cada dron está conformado por una estructura metálica o de fibra de carbono que
le permite sostener el resto de elementos necesarios para su funcionamiento. De este
modo, la estructura de soporte está formada por tres partes fundamentales (figura 2.4):
Brazos. Permiten soportar la unidad de propulsión y sustentación del dron, o lo
que es lo mismo, sus rotores y hélices.
Patas. Se encargan de mantener la estabilidad del dron en tierra cuando se
produzca el aterrizaje o al inicio del vuelo.
Bandeja central. Permiten alojar la unidad de control del dron, así como el
módulo de comunicaciones, de alimentación y la carga de pago que transporta
este dispositivo.
2. Sistemas UAV 15
Brazos Bandeja central
Patas
Figura 2.4: Partes de la estructura de soporte de un dron
Unidades de propulsión y sustentación
Los drones vuelan gracias al movimiento de los rotores que se alojan en los brazos
de su estructura de soporte. Cada uno de estos elementos de propulsión y sustenta-
ción están constituidos por un motor y las hélices, activos a partir de la unidad de
alimentación de la aeronave y que se controlan por medio de una unidad denominada
ESC (Electronic Speed Control), que entrega al motor las revoluciones necesarias para
iniciar, mantener o finalizar la etapa de vuelo del dispositivo de manera adaptable, tal
y como se representa en el esquema de la figura 2.5.
Rotor
ESC Batería LiPo
ArduPilot
Figura 2.5: Conexiones en una unidad ESC de un dron
16 2.2. Descripción de la aeronave
Unidad de alimentación
Normalmente, la alimentación de un multicóptero está basada en baterías tipo
LiPo (Lithium Polymer), como es el caso de las baterías Zippy 5000 20C (figura 2.6),
constituidas por tres celdas que entregan un voltaje de 11.1 V mediante una conexión
con el módulo ArduPilot por el puerto Power port, con una capacidad de 5000 mAh.
Figura 2.6: Batería LiPo Zippy 5000 20C
Estas baterías tienen la ventaja de ser lo suficientemente ligeras como para no
incurrir en un peso excesivo sobre el dron, además de tener una gran capacidad de
almacenamiento de carga. A pesar de ello, su coste en el mercado suele ser superior al
de otros modelos también utilizados en estos drones, y tanto el tiempo de autonomía
como el de vida de estas baterías suele ser inferior al de otros modelos comerciales [21].
Controlador de vuelo
El controlador de vuelo de un dron es la unidad que permite automatizar las fun-
ciones de guiado de la aeronave sin necesitar la intervención de seres humanos, es decir,
que mediante un sistema electrónico con acceso a las funciones electromecánicas del
dron, es posible automatizar o controlar su movimiento y las tareas que se le quieran
planificar.
Para ello, la solución comercial más extendida en la actualidad se basa en la pla-
taforma ArduPilot (figura 2.7). Se trata de un dispositivo basado en la plataforma de
microcontroladores Arduino MEGA 2560 que, a través de un firmware open source
denominado Arducopter toma el control de la unidad inercial o IMU (Inertial Mea-
surement Unit) del dron a través del protocolo de comunicación que comparte con la
estación terrena.
2. Sistemas UAV 17
Figura 2.7: Unidad de control de vuelo ArduPilot
En este sentido, el controlador de vuelo controla la estabilización y navegación
autónoma del dron haciendo uso de una unidad GPS integrada en la aeronave. Con
ello, la plataforma ArduPilot presenta un gran número de ventajas que la establecen
como una de las principales opciones que toman los usuarios de drones para incorporar
la unidad de control de vuelo en sus dispositivos, y son las siguientes:
Sencillez en la instalación y configuración del firmware.
Permite realizar misiones basadas en waypoints, sin necesidad de la intervención
humana.
Soporta hasta 8 canales de radiocontrol, 4 puertos serie y 2 vías de telemetría
sobre un mismo módulo compacto.
Compatibilidad con estaciones terrenas gratuitas.
Configuración de despegue y aterrizaje autónomos.
Módulo de comunicaciones vía radio
Con el objetivo de comunicar datos de monitorización del dron a la estación terrena,
es necesario incorporar una unidad de telemetría que transmita y reciba comandos
según el protocolo de comunicación fijado entre el dron y la estación terrena. Uno de
los modelos comerciales de unidad de telemetría más utilizados en materia de drones
son los proporcionados por 3D Robotics (figura 2.8), que cumplen las características
recogidas en la tabla 2.1.
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 ValorFrecuencia 433 MHzAlimentación en transmisión 3.7 – 6 V, 100 mAAlimentación en recepción 3.7 – 6 V, 25 mAVelocidad de transmisión por radio 57.6 MbpsVelocidad 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 y APM Planner.
La estación terrena Mission Planner es la plataforma más utilizada con el con-
trolador de vuelo ArduPilot. Se trata de una plataforma basada en software libre,
únicamente disponible para Windows, que permite realizar operaciones en el dron tan-
to 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 dela estación terrena
Unidad de telemetría dela unidad UAV
Software de controlde 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) y 64 bits (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 y el checksum, 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 he-
xadecimal 0xFE y 0x55, 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 terre-
na, 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 y CKB 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 po-
sició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_tTiempo en milisegundos desde que arranca el bootdel sistema.
roll floatValor angular del roll, expresado en radianes y convalores comprendidos entre +π y −π.
pitch floatValor angular del pitch, expresado en radianes ycon valores comprendidos entre +π y −π.
yaw floatValor angular del yaw, expresado en radianes y convalores comprendidos entre +π y −π.
rollspeed floatVelocidad angular sobre el roll, expresada en ra-dianes por segundo.
pitchspeed floatVelocidad angular sobre el pitch, expresado en ra-dianes por segundo.
yawspeed floatVelocidad angular sobre el yaw, expresado en ra-dianes 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 desa-
rrollada 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 actual-
mente 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 dis-
positivos 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 transpon-
dedor 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ígi-
tos 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 conAIS clase A y AIS clase B
Estación satelital AIS
Satélite AIS
Estación de controly 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, llu-
via 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 y exactEarth.
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.
28 3.1. Introducción
La estandarización del sistema es internacional.
En comparación con otros sistemas de comunicaciones marítimas, el coste de los
equipos y su mantenimiento es relativamente bajo.
No obstante, AIS es un sistema proclive a ser utilizado para respaldar operaciones
de piratería, terrorismo y pesca ilegal, ya que muchas embarcaciones están exentas de
identificarse en el sistema de forma obligatoria. En este sentido, las funcionalidades y
garantías que ofrecen otras tecnologías, como puede ser el radar, superan claramente
al sistema AIS en términos de seguridad y privacidad.
3.1.2. Dispositivos comerciales
La demanda latente en lo que concierne a la tecnología electrónica como elementos
de apoyo en las travesías marítimas, tanto para embarcaciones comerciales como de
recreo, favorece la existencia de un gran número de compañías dedicadas a la venta
y distribución de equipos AIS. Además, numerosas empresas hacen uso de la tecnolo-
gía AIS para ofrecer servicios de monitorización y seguimiento de embarcaciones, que
resultan útiles en numerosas disciplinas.
En la actualidad, la compañía puntera en tecnología AIS es Sofware Radio Techno-
logy, conocida como SRT-Marine, una empresa británica fundada en 1987 que cuenta
con una larga experiencia en AIS y otras tecnologías hardware y software para sistemas
de radiocomunicación. Los productos desarrollados por esta empresa copan cerca del
90 % de la tecnología AIS utilizada en la actualidad, y entre los servicios que ofrece
destacan los siguientes:
Diseño de equipos hardware personalizados, a petición del cliente.
Módulos AIS funcionales para ser integrados en cualquier entorno.
Soluciones software relacionadas con el mantenimiento y la configuración de equi-
pos AIS.
3. Sistema AIS 29
Por otro lado, CML Microcircuits ofrece una gama de productos similar a la de
SRT-Marine. Esta compañía oferta distintas líneas de productos para aplicaciones de
radiofrecuencia [32], donde destaca una línea particular para comunicaciones marítimas.
En esta línea se ofertan diferentes modelos de chips y equipos de evaluación para
transpondedores y receptores AIS y SAR, pensados para su integración en aplicaciones
electrónicas particulares.
El resto de compañías dedicadas a la venta y distribución de equipos AIS están
orientadas hacia la integración de receptores y transpondedores en embarcaciones. De-
bido a su volumen de ventas, son notables las compañías Comar Systems, Digital Yatch,
Milltech Marine y Em-Trak para la adquisición de transpondedores y receptores AIS
de instalación inmediata, así como otros elementos imprescindibles como pueden ser
antenas VHF y splitters. Sin embargo, hay que considerar que la mayor parte de es-
tas compañías basan sus diseños en la tecnología desarrollada por SRT-Marine, y que
incluso adaptan el software propio esta compañía para sus productos.
Finalmente, las principales empresas dedicadas a ofrecer servicios a partir de la
información recogida por el sistema AIS son MarineTraffic y exacEarth. Ambas com-
pañías se dedican a la venta de estadísticas e históricos de datos sobre el tráfico ma-
rítimo. En el caso de MarineTraffic, ofrece un servicio gratuito de monitorización de
embarcaciones en la web a partir de la información recogida por su red de receptores
AIS en todo el mundo, disponible también para Android e iOS. De esta forma, cual-
quier usuario puede acceder a la web de MarineTraffic y consultar el estado del tráfico
marítimo en todo momento y en numerosos lugares del planeta, salvo en algunas zonas
donde la cobertura es satelital y por tanto, de pago.
3.2. Descripción del sistema
Las características técnicas del sistema AIS están descritas en la recomendación
ITU-R M.1371-5 en función de su arquitectura OSI (Open System Interconnection),
aunque únicamente están descritos los niveles desde la capa física hasta la capa de
transporte, dejando los niveles superiores relativos a la presentación y tratamiento de
los datos a elección del usuario (figura 3.2).
30 3.2. Descripción del sistema
Nivel Físico
Nivel de Enlace
Nivel de Red
Nivel de Transporte
Subcapa MAC Subcapa DLS Subcapa LME
Nivel de Sesión, Presentacióny Aplicación
Parámetros radio y esquemas de modulacióny codificación
Sincronismo y formato de tramas, esquemade acceso al medio
Formato de mensajes AIS y mecanismosde envío y recepción por la red
No existe ninguna estandarización sobreestos niveles OSI en AIS
Figura 3.2: Arquitectura OSI del sistema AIS
3.2.1. Características radio y de enlace
El sistema AIS opera en la banda de VHF marina sobre dos frecuencias llamadas
AIS-1 (161.975 MHz) y AIS-2 (162.025 MHz), con una canalización de 25 KHz. Además,
presenta una codificación de línea NRZI Non-Return to Zero Inverted) a 9600 bps, de
forma que tras la codificación, los bits generados se modulan con una modulación
específica denominada FM-GMSK (Frequency Modulation - Gaussian Minimum Shift
Keying), que pondera la forma de onda de los bits con una envolvente gaussiana,
seguido de una modulación analógica en frecuencia (figura 3.3).
Modulación GMSK
Modulación FM
Modulación FM-GMSK
CodificaciónNRZI
Figura 3.3: Esquema de codificación y modulación en AIS
Por otro lado, el formato de tramas del sistema AIS lo forman seis campos relativos
al preámbulo o secuencia de inicio, los flags o cabeceras de inicio y fin, el campo de
datos de la trama, un código de redundancia cíclica de 16 bits y un campo adicional
que se relaciona con el sincronismo de la trama, tal y como aparece en la figura 3.4.
3. Sistema AIS 31
Preámbulo
Cabecerainicial
Datos CRC
Cabecerafinal
Buffer temporal
0x55 0x55 0x55 0x7E 168 bits 16 bits 0x7E 24 bits
Figura 3.4: Campos de una trama AIS
3.2.2. Esquema de acceso al medio
En lo que respecta al esquema de acceso al medio, AIS emplea un esquema de acceso
tipo TDMA que depende de la clase de AIS del equipo y el ámbito de aplicación. De
esta manera, los dos esquemas fundamentales en AIS son SOTDMA (Self-Organized
Time Division Multiple Access), empleado por los equipos AIS clase A, y CSTDMA
(Carrier Sense Time Division Multiple Access), propio de los equipos AIS clase B. Tam-
bién existen otros esquemas como RATDMA (Random Access Time Division Multiple
Access), FATDMA (Fixed Access Time Division Multiple Access) o ITDMA (Incre-
mental Time Division Multiple Access), que se usan para respaldar a los dos esquemas
de acceso principales o para aplicaciones específicas de AIS, como son AtoN (Aids-to-
Navigation), SAR (Search and Rescue) o SART (Search and Rescue Transponder) [33],
tal y como se refleja en la figura 3.5.
SAR SART AtoN AIS clase A AIS clase B Estación base AIS
No está definidoen el estándar
SOTDMAmodificado
FATDMARATDMA
SOTDMARATDMAITDMA
CSTDMA FATDMARATDMA
Figura 3.5: Tipos de esquema de acceso al medio en AIS en función del ámbito deaplicación
En cualquier caso, ambos esquemas principales operan de tal forma que los equipos,
sincronizados sobre un tiempo común UTC (Universal Time Coordinated) que extraen
de la red GNSS, compiten por el acceso a un slot de tiempo de 26.67 ms, y en caso de
estar ocupados, se autogestionan para no colisionar con los equipos que ya han accedido
al slot y así poder acceder a aquellos que se encuentren libres.
32 3.2. Descripción del sistema
En este sentido, el esquema de acceso SOTDMA presenta tres modos de operación
fundamentales que se describen a continuación [34]:
Modo autónomo y continuo. Los equipos AIS clase A están continuamente
emitiendo y recibiendo mensajes AIS, a menos que ocurra un fallo en el equipo,
se desconecte o cambie el modo de operación.
Modo asignado. La autoridad competente de cada país programa este modo en
función del área donde se realice una travesía marítima.
Modo interrogación. Una estación AIS solicita a otra una respuesta sobre algún
parámetro o sencillamente, sobre el estado de la misma.
Con este esquema, las estaciones monitorizan durante un minuto el estado del canal
y cómo otras estaciones acceden a los slots. Una vez conocidos los slots libres, la estación
accede a uno de ellos y se presenta al resto de equipos AIS que operan en una misma
región de cobertura. En el momento en el que expire el tiempo de acceso al primer slot,
la estación busca otro slot libre y accede a él, y así sucesivamente de forma organizada
sin interferir en la operación del resto de equipos.
Por el contrario, el esquema de acceso CSTDMA monitoriza el nivel de ruido de
fondo de los canales AIS y así establecer un umbral que le permita discernir entre ruido
(no hay actividad en el slot) y señal (el slot está ocupado). Aunque los equipos que
operan con CSTDMA son totalmente compatibles con los que emplean SOTDMA, la
prioridad de acceso la tienen los equipos con SOTDMA, dado que son AIS clase A y
por tanto, su uso es obligatorio y resulta prioritaria su conexión frente a equipos AIS
clase B que están exentos del cumplimiento obligatorio de incorporación del sistema
AIS en la embarcación.
3.2.3. Estructura de mensajes AIS
El campo de datos de una trama AIS contiene un mensaje conformado por un
identificador (MSG ID), un código MMSI, la información contenida y el estado de la
comunicación, tal y como se representa en la figura 3.6.
3. Sistema AIS 33
MSG ID MMSI Información del mensajeEstado de comunicación
Campo de datos de la trama AIS
Figura 3.6: Estructura básica de un mensaje AIS
El identificador de mensaje consta de 6 bits e indica el tipo de mensaje AIS que
se envía o recibe en una trama, existiendo un total de 27 mensajes AIS para diferen-
tes propósitos, mientras que el identificador MMSI consta de 30 bits representados
mediante 9 dígitos decimales, siendo un identificador único para cada equipo AIS y es
asignado a cada equipo por la autoridad reguladora del país donde opera. Por otro lado,
el estado de comunicación provee al sistema de la información necesaria para conocer
el estado de los slots durante su acceso al medio e indicar el estado de sincronismo del
sistema por medio del sistema GPS.
Por último, la información del mensaje depende del tipo de mensaje AIS, y se
relaciona intrínsecamente con la naturaleza de la información que se comunica. En este
sentido, la preponderancia de la información compartida por el sistema AIS se clasifica
en los siguientes tipos:
Información estática, que no varía en ningún momento y sirve para identificar
de forma unívoca a cada equipo, como puede ser el MMSI o las dimensiones de
la embarcación.
Información dinámica, que se actualiza constantemente y señala aquellos pa-
rámetros variables del sistema, como puede ser la posición o la velocidad.
Información de travesía, que permiten al usuario introducir manualmente
información relevante para la travesía marítima, principalmente como apoyo para
otros sistemas de comunicación a bordo.
Otra información, destacando los mensajes de texto cortos que se emplean para
garantizar la seguridad en el mar o informar de una situación de alerta, con un
propósito similar a la llamada digital selectiva.
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ónAIS clase AInferior a 3 nudos para buques anclados o amarra-dos 3 minutos
Superior a 3 nudos para buques anclados amarra-dos 10 segundos
Entre 0 y 14 nudos 10 segundosEntre 0 y 14 nudos con cambio de rumbo 3 segundosEntre 14 y 23 nudos 6 segundosEntre 14 y 23 nudos con cambio de rumbo 2 segundosSuperior a 23 nudos 2 segundosSuperior a 23 nudos con cambio de rumbo 2 segundosAIS clase BInferior a 2 nudos 3 minutosSuperior a 2 nudos 30 segundosComentarios 1 nudo = 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ón1, 2, 3 Informe de posición de equipos AIS clase A4 Informe de posición de estaciones base AIS5 Datos estáticos y de viaje de equipos AIS clase A6, 7, 8 Información de reconocimiento, binaria y broadcast9 Posición de equipos SAR10, 11 Información del tiempo UTC12, 13, 14 Información binaria y de reconocimiento segura15 Cambio al modo interrogación16 Cambio al modo asignado17 Información broadcast de la red GNSS18, 19 Informe de posición normal y extendido de equipos AIS clase B20 Reserva de slots para estaciones base AIS21 Informe de posición de equipos AtoN22, 23 Cambio a otros modos de las estaciones base AIS24 Datos estáticos de equipos AIS clase A25, 26 Información binaria no programada27 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 radiocomu-
nicació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 es-
tos 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 ne-
gociació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 y un bit de stop, sin incluir ningún bit de paridad. Para la última versión de
NMEA0183, los niveles de señal oscilan entre los +5 y 0 V, aunque si se crea 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. El talker 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 y listener
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 posi-
bles 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 y line feed, respecti-
vamente, 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 identifi-
cació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 disposi-
tivos 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 BSRT Marine Cobalt
MicrocontroladorBeagleBone Black
Controlador de vuelo del droneArduPilot
Antena GPS
Antena VHF
ComandosMAVLink
ComandosNMEA0183
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 firm-
ware 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 completa-
mente 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 confi-
guración y el control del mismo. A su vez, incluye dos conectores de RF Hirose U.FL-
R-SMT-1 en los que se conectan las antenas de VHF marítimo y GPS (figura 4.2).
70 mm55 mm
13.8 mmConector paraantena GPS
Conector paraantena VHF
Diodos LED paraindicación de status
Conector para interfazserie 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 cone-
xiones 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 8 6 4 2
1357911131517192123252729
Interfaz de alimentación
Toma de tierra
Interfaz USER_IO
Interfaz SPI
Interfaz USB
Interfaz NMEA0183
Interfaz NMEA2000
Sin conexión
VIN
(+)
USE
R_IO
_8
VIN
(+)
VIN
(-)
VIN
(-)
USE
R_IO
_6
USE
R_IO
_4
USE
R_IO
_0
USE
R_IO
_1
USE
R_IO
_2
GN
D
NM
EA01
83_T
X1_A
NM
EA01
83_T
X1_B
nAIS
_OFF
NM
EA01
83_R
X1_A
NM
EA01
83_T
X2_A
NM
EA01
83_T
X2_B
NM
EA01
83_R
X2_A
N2K
_NET
_C
N2K
_NET
_C
3V3_
EXT
USE
R_IO
_3
SPI_
MIS
O
GN
D
USB
_VBU
S
NC
NM
EA01
83_R
X1_B
NM
EA01
83_R
X2_B
N2K
_NET
_L
N2K
_NET
_H
USE
R_IO
_9
USE
R_IO
_7
USE
R_IO
_5
SPI_
MO
SI
SPI_
SCK
SPI_
SDIO
_CS
USB
_DP
USB
_DM
USB
_GN
D
GN
D
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 com-
prendidas entre 9.6 V y 31.2 V. Para ello, este módulo dispone de 5 pines de alimen-
tación en el conector Hirose DF13-40P-1.25V(91), además de los pines de referencia
44 4.2. Transceptor AIS clase B
a tierra y un circuito de protección contra polaridades inversas. Cabe señalar que el
módulo Cobalt tiene un consumo de potencia en el momento de la transmisión de en-
tre 1 W y 5 W. Esta característica permite que el módulo Cobalt se mantenga en un
modo de bajo consumo cuando únicamente recibe datos, y solamente cuando envía un
mensaje AIS genera un pico de potencia y vuelve a su estado de bajo consumo.
4.2.3. Conexiones de interfaces serie
Las conexiones de la interfaz serie del módulo Cobalt se ubican en el conector
Hirose DF13-40P-1.25V(91), con un total de 30 pines referidos a las distintas interfaces
provistas en este dispositivo. Además, se integran 4 diodos LED de distinto color que
se activan en función de los estados marcados por estas interfaces, tal y como aparece
en la figura 4.4.
StatusFaultTx timeoutPower / OK
Pin 40 Pin 2
Pin 1Pin 39
Figura 4.4: Indicadores LED en el módulo Cobalt SRT-Marine
Las interfaces serie del módulo Cobalt a las que tiene acceso el usuario mediante el
conector Hirose DF13A-40DP-1.25V(91) son las siguientes:
Interfaz USB. Esta interfaz consta de 4 pines, dos de ellos referidos a los datos
de entrada y salida (D+ y D−, respectivamente) y otros para las conexiones de
alimentación (VCC = +5 V) y tierra (GND). Mediante esta interfaz, y con ayuda
4. Desarrollo del prototipo 45
del software propio del dispositivo, es posible configurar los datos estáticos del
módulo Cobalt y monitorizar su actividad si se conecta a un ordenador.
Interfaz SPI. Esta interfaz cuenta con 4 pines referidos a las cuatro señales
básicas del protocolo SPI, que son MOSI (Master Output Slave Input), MISO
(Master Input Slave Output), señal de sincronismo y señal de enable. De esta
manera, es posible conectarse a una memoria SD integrada en el módulo Cobalt,
que opera en modo SPI, y extraer los datos almacenados en el transpondedor y/o
realizar ampliaciones futuras del sistema.
Interfaz NMEA0183. Esta interfaz consta 2 canales bidireccionales asociados a
8 pines, que a su vez se relacionan con la recepción y transmisión de mensajes AIS
bajo el protocolo NMEA0183. De estos pines, 4 de ellos están relacionados con
la recepción y los otros 4 con la transmisión, y se presentan en parejas dado que
actúan como entradas y salidas diferenciales. Se trata de una interfaz necesaria
para conectar el módulo Cobalt a otros instrumentos de navegación marítima.
Interfaz NMEA2000. Esta interfaz consta de 4 pines relacionados con la trans-
misión y recepción de mensajes AIS bajo el protocolo NMEA2000, donde dos de
ellos se relacionan con los datos transmitidos y recibidos, y los otros dos para la
alimentación y tierra.
Interfaz USER_IO. Esta interfaz está formada por 10 pines relacionados con
el estado del dispositivo, que se marca mediante 4 diodos LED integrados en el
dispositivo, y con el control de escritura y lectura de la memoria SD en modo
SPI. Es por ello que esta inferfaz se asocia a las futuras expansiones que se deseen
hacer con el módulo Cobalt.
4.2.4. Conexiones de RF
El módulo Cobalt dispone de dos conectores Hirose U.FL-R-SMT-1 para conectar
las antenas de GPS y VHF (figura 4.5), existiendo además ciertas limitaciones sobre los
parámetros característicos de las antenas de VHF y GPS que se conectan al módulo,
recogidas en la tabla 4.1.
46 4.2. Transceptor AIS clase B
Conector para antena GPS
Conector para antena VHF
Figura 4.5: Conectores para las antenas de VHF y GPS del módulo Cobalt
Tabla 4.1: Limitaciones para las antenas de VHF y GPS en el módulo Cobalt
Parámetro Conector VHF Conector GPSImpedancia 50 Ω 50 ΩFrecuencia 156 – 162 MHz 1.575 GHzGanancia 3 dBi > 20 dBCOE 2:1
4.2.5. Configuración del dispositivo
El módulo Cobalt se configura a través de un software específico desarrollado por
SRT-Marine llamado proAIS2, que se puede adquirir de forma gratuita para las pla-
taformas Windows y UNIX. Este software permite tanto la configuración de los datos
estáticos del dispositivo como la monitorización del estado del mismo y los mensajes
AIS recibidos y transmitidos, además de servir como interfaz para enviar comandos
NMEA al módulo Cobalt.
El software proAIS2 presenta cinco vistas con las que el usuario puede interactuar,
explicadas más extensamente en el anexo C, y son las siguientes:
Configuration. Permite la conexión del módulo Cobalt y la configuración de los
datos estáticos del dispositivo (nombre y tipo de la embarcación, MMSI, código
de llamada selectiva, ubicación de las antenas...). También permite configurar la
tasa binaria de salida del dispositivo.
GNSS Status. Permite la monitorización y representación gráfica de los niveles
de la relación portadora-ruido de los satélites de GPS, así como determinar el
4. Desarrollo del prototipo 47
número de satélites que el módulo Cobalt está recibiendo en todo momento y sus
parámetros asociados.
Other Vessels. Permite la recepción y monitorización del resto de embarcaciones
que integran un transpondedor AIS y se encuentran en la zona de cobertura del
módulo Cobalt, mostrando toda la información relevante de cada embarcación
(nombre, clase de transpondedor, posición, velocidad...).
Diagnostic. Permite la revisión de los parámetros característicos del módulo
(estado de las conexiones y características propias del software) e incluso, el
número de mensajes recibidos y transmitidos por los dos canales del dispositivo.
Serial Data. Permite la monitorización y el almacenamiento de los mensajes
AIS recibidos y transmitidos, así como habilitar el envío de comandos NMEA
por parte del usuario.
4.3. Microcontrolador
4.3.1. Introducción
La placa BeagleBone Black [37] es un sistema empotrado de desarrollo basado en
un procesador ARM Cortex A8 que ejecuta un sistema operativo Linux, actualmente
en su versión Debian 8.6 Jessie (figura 4.6). Esta placa está dotada de una gran po-
tencia y capacidad de ejecución para diversas actividades en tiempo real sobre un gran
número de aplicaciones. Además, cuenta con un gran número de entradas y salidas que
le permite conectarse con diferentes dispositivos e interfaces, destacando su reducido
consumo de potencia y el bajo coste de las mismas, siendo un competidor inmediato de
otras plataformas destinadas a propósitos similares, como son Raspberry Pi o Arduino.
Los elementos principales de la BeagleBone Black, al igual que ocurre con otras
plataformas de microcontroladores, se pueden esquematizar en tres grupos bien dife-
renciados, que son los siguientes:
48 4.3. Microcontrolador
Figura 4.6: Placa BeagleBone Black
Microprocesador.
Unidad de memoria.
Interfaces externas y de alimentación.
La programación de estas placas resulta sencilla, ya que permite la ejecución de
scripts en el lenguaje Python [38], que destaca por su sencillez de sintaxis, aunque
también es posible programarlas en otros lenguajes como C y C++. No obstante, la
extensión de uso de la BeagleBone Black es inferior a la de la Raspberry Pi, de manera
que no hay comunidades tan amplias para compartir las novedades y problemas que
pueden aparecer durante la configuración de estas placas.
4.3.2. Microprocesador
El microprocesador integrado en la BeagleBone Black es el modelo Texas Instru-
ments Sitara XAM3359AZCZ100, un procesador Cortex-A8 de 32 bits con arquitectura
RISC que cuenta con una frecuencia de reloj de 1 GHz y 512 MB de memoria DDR3L.
En lo que se refiere a las interfaces de entrada y salida de este microprocesador, cabe
señalar aquellas interfaces a las que el usuario tiene acceso en la placa BeagleBone
Black. En la figura 4.7 se presenta una descripción de estas interfaces, destacando la
inclusión de hasta 6 puertos UART, 2 puertos SPI, 3 canales PWM y 3 puertos I2C,
que suelen ser las interfaces de mayor interés para el usuario.
4. Desarrollo del prototipo 49
UART
SPI
I2C
CAN
6
Interfaces serie Interfaces del sistema
McASP
2
3
2
2
Watchdog Timer
RTC EDMA
eCAP3 eQEP3
eHRPWM3
Timer8
JTAG/ETB
ADC 12 bits8
MMC/SD/SDIO3
GPIO
USB 2.0 OTG / PHY2
Puerto EMAC2
Interfaces paralelo
ARM Cortex-A8 Gráficas, display y otras interfaces del microprocesador
Interfaces principales
Procesador Otras interfaces
Buses de interconexión L4 y L5
SDRAM DDR3
Flash 16 bit NAND/NOR
Memoria del sistema
Figura 4.7: Diagrama de bloques del procesador de la placa BeagleBone Black
4.3.3. Unidad de memoria
La unidad de memoria de la BeagleBone Black se compone de una memoria SRAM
y una memoria flash integradas en el placa, siendo esta última ampliable mediante una
memoria micro-SD. Con ello, a continuación se muestran las principales características
técnicas que presentan estos dos tipos de memorias:
Memoria SRAM. Se basa en tecnología DDR3 y tiene una capacidad de 512
MB, repartida en 16 módulos a 800 MHz.
Memoria flash. Se basa en tecnología flash eMMC y tiene una capacidad de
2 o 4 GB, donde se ejecuta el sistema operativo, además de poder ser ampliada
mediante una tarjeta micro-SD.
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
Tarjetamicro-SD
Conector mini-USB
BotónRESET
BotónPOWER
BotónSWITCH
Conectoresde 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 cone-
xió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, so-
portando 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 tam-
bié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 funcionali-
dades 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óndel script programado en Python
Figura 4.10: Conexión, edición y ejecución de un script en Python para BeagleBoneBlack
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 ValorImpedancia 50 ΩBanda de frecuencia 156 – 174 MHzFrecuencia central 162 MHzGanancia 1.5 dBi
COE 1.2:1Conector SMA machoAltura 400 mmPeso 60 g
400 mm
Base magnéticacon diámetro de25 mm
SMA macho
Conector U.FL a SMApara la conexión conel 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 esco-
gida 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óduloCobalt
Parámetro ValorImpedancia 50 ΩBanda de frecuencia 160 – 174 MHzFrecuencia central 162 MHzGanancia 2 dBi
COE 2:1Conector SMA machoAltura 11 cmPeso 20 g
11 cm
Conector SMAhembra
Transición SMA-SMA machopara conectar la antena alcable 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 basemagné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 ValorImpedancia 50 ΩFrecuencia central 1575.42 MHz ± 3 MHzPolarización CircularCOE 1.2:1Conector SMA machoDimensiones 37.4 mm × 34 mm × 12.9 mmPeso 25 g
4. Desarrollo del prototipo 57
Conector U.FL a SMApara la conexión conel módulo Cobalt
SMA machoAntena 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. Final-
mente, 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 experi-
mental 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
60 5.1. Interconexionado hardware
Transpondedor AIS clase BSRT-Marine Cobalt
MicrocontroladorBeagleBone Black
Antena VHF marítimocon soporte magnético
Antena GPScon soporte magnético
Fuente de alimentaciónPROMAX FAC-662B
Figura 5.1: Diagrama de bloques del prototipo inicial
Por otro lado, algunos elementos utilizados en la integración inicial se sustituyen,
como ocurre con la fuente de alimentación, por otros módulos integrables en un dron,
mientras que las conexiones entre el microcontrolador y el transpondedor AIS se man-
tienen inalterables. De esta manera, se atiende principalmente a la manera de embarcar
estos componentes en la aeronave y con ello, integrar el prototipo final con el que se
realiza la verificación final.
En la figura 5.2 se representa el diagrama de bloques del montaje de integración
final del prototipo desarrollado y embarcado en un dron.
Transpondedor AIS clase BSRT-Marine Cobalt
MicrocontroladorBeagleBone Black
Antena VHF marítimoportable
Antena GPScon soporte magnético
Batería para UAVZippy 5000 20C
Figura 5.2: Diagrama de bloques del prototipo final
5. Integración del prototipo 61
5.1.1. Configuración del transpondedor AIS clase B
Previamente a la interconexión entre el transceptor AIS clase B Cobalt y la placa
BeagleBone Black, es necesario configurar los datos estáticos del módulo Cobalt por
medio de la habilitación de un nombre y un MMSI, asignados por la Dirección General
de la Marina Mercante. El procedimiento llevado a cabo para esta solicitud se detalla
en el anexo A de esta memoria, por lo que a continuación solamente se indican cuáles
son los datos asignados al módulo Cobalt que integra el prototipo desarrollado.
En términos de este Trabajo Fin de Máster, el módulo Cobalt se enmarca en el tipo
de embarcación número 99, que se destina a estaciones habilitadas para usos distintos a
los que habitualmente se destinan estos dispositivos. Con ello, Dirección General de la
Marina Mercante asigna un el MMSI de número 111224515 a la estación con nombre
IDETIC DRONE AIS. En el momento que se conozcan estos datos, es posible configurar
el módulo Cobalt a través del software proAIS2.
Para ello, se conecta a través de USB el módulo Cobalt con un ordenador personal
que ejecute el software proAIS2. Cabe señalar que para la conexión por USB entre el
módulo Cobalt y el ordenador personal, es necesario construir un cable propio, soldado
y recubierto con un tubo termoretráctil, a partir de un conector USB tipo A macho y
cuatro cables con pines adaptables al conector Hirose DF13 que se encuentra integrado
en el módulo Cobalt.
Una vez el software proAIS2 detecta el puerto del dispositivo (AIS Virtual COM), se
habilita la conexión y se accede a la vista de configuración. Luego, se rellenan los campos
referentes al MMSI, el nombre y el tipo de la embarcación con los datos asignados por
la Dirección General de la Marina Mercante. Finalmente, estos datos se vuelcan sobre el
módulo Cobalt, sin posibilidad de revertir la configuración, y apareciendo un mensaje
de alerta que indica que el número de MMSI asignado debe ser válido de cara al marco
legislativo del país. Una vez se aceptan las condiciones de configuración, el módulo ya
se encuentra operativo para iniciar la transmisión de mensajes AIS con ayuda de las
antenas de VHF marino y GPS. Este proceso de configuración se representa a través
de un esquema en la figura 5.3.
62 5.1. Interconexionado hardware
Ordenadorpersonal
MóduloCobalt
Antena deVHF marino
Antena deGPS
Figura 5.3: Conexión y configuración del módulo Cobalt con el software proAIS2
5.1.2. Montaje del prototipo inicial
Los dos módulos fundamentales que forman parte del prototipo que se plantea en
este Trabajo Fin de Máster son el microcontrolador, a través de la placa BeagleBone
Black, y el transpondedor AIS clase B, basado en el módulo Cobalt de SRT-Marine,
que se conectan a través de una interfaz serie USB. Además, el módulo Cobalt precisa
una alimentación de al menos 12.6 V para la transmisión de los datos, de modo que
inicialmente se debe conectar sus pines relativos a la alimentación a una fuente de
alimentación externa.
En lo que respecta a la conexión USB, la BeagleBone Black utiliza sus pines para
la UART1 para enviar y recibir, en caso de ser necesario, los comandos NMEA que
es capaz de interpretar el módulo Cobalt, tal y como se representa en el esquema
de la figura 5.5, y se conectan además las antenas de VHF con base magnética y
de GPS a los conectores SMA hembra señalados. Finalmente, se ejecuta el firmware
implementado en la BeagleBone Black para transmitir los datos generados al módulo
Cobalt y seguidamente, por la antena de VHF.
5. Integración del prototipo 63
Transceptor AIS clase BSRT-Marine Cobalt
MicrocontroladorBeagleBone Black
UART1_TX
UART1_TX
12.6 V 0 V
VCC (5 V)
GND
Conector para antena de GPS
Conector para antena de VHF
Figura 5.4: Conexiones entre los módulos del prototipo inicial
En la figura 5.5 se presenta el montaje físico del prototipo inicial que se implementa
durante la fase de interconexión del prototipo.
Módulo Cobalt
Antena GPS Antena VHFOrdenador personal
Fuente de alimentación
Figura 5.5: Montaje físico del prototipo inicial
64 5.1. Interconexionado hardware
5.1.3. Integración del prototipo en un dron experimental
Para la integración hardware del prototipo en un dron experimental, basado en el
tricóptero DIY Y6 de 3D Robotics, es necesaria la sustitución de ciertos elementos
habilitados para su integración en esta aeronave. Además de la inclusión de nuevos
elementos como son el controlador de vuelo ArduPilot y la batería LiPo para la ali-
mentación del UAV, los elementos que requieren ser sustituidos para la integración del
prototipo sobre el dron experimental son los siguientes:
La antena VHF con base magnética se sustituye por una antena VHF portable,
modelo Motorola PMAD4095A, debido a su pequeño tamaño y bajo peso, además
de la conservación de las características radio respecto a la antena VHF inicial.
Por razones de peso y dimensiones, fuente de alimentación pasa a ser una ba-
tería LiPo, modelo TATTU 1300mAh 25C, que entrega una tensión de 12.6 V,
suficiente para habilitar la transmisión de mensajes por parte del módulo Cobalt.
De esta manera, en la figura 5.5 se presenta el montaje físico realizado sobre el dron
con los elementos previamente integrados en el prototipo inicial y los nuevos elementos
para la transmisión en VHF y la alimentación de la aeronave.
Antena GPS
Antena VHF
Módulo Cobalt
Batería LiPo
ArduPilot
BeagleBone Black
Power-Bank
Figura 5.6: Integración física del prototipo en un dron experimental
5. Integración del prototipo 65
Cabe señalar que con el objetivo de alimentar a la placa BeagleBone Black, es nece-
sario incluir un dispositivo Power-Bank conectado al puerto mini-USB de la placa. Este
dispositivo, fundamentalmente utilizado para la alimentación de dispositivos móviles en
situaciones donde no es posible recargarlos a través de la toma eléctrica convencional,
entrega una tensión de 5 V, suficiente para alimentar a la BeagleBone Black y permitir
la ejecución del firmware implementado en la misma.
5.2. Firmware de control
La creación de mensajes AIS propios con formato NMEA es una de las funcionalida-
des que incluye el prototipo diseñado, y permite el envío de parámetros específicos del
dron dentro del campo de datos del mensaje seleccionado para este propósito. Por ello,
el firmware de control que se programa en la BeagleBone Black permite crear un tipo
de mensaje HDT (Heading True), empleado para obtener la orientación de dispositivos
externos al equipo AIS a partir de la información paramétrica recogida del dron.
Tras una configuración previa del dron, el proceso para desarrollar este firmware
de control comienza con la captura de los valores de yaw que entrega el dron en todo
momento. Estos valores se actualizan a medida que el dron varíe su rumbo, y se integran
en el formato de mensaje HDT creado previamente sobre un script en Python. De este
modo, cuando se completa el campo de datos del mensaje, se calcula el checksum
asociado y se vuelca sobre el mensaje final, que se envía a través de una UART de la
placa BeagleBone Black hasta el módulo Cobalt. Con ello se consigue enviar, a través
del módulo Cobalt, un mensaje propio que contiene un parámetro característico del
dron, como es el yaw, siendo escalable para otros posibles parámetros que quieran
enviarse con este prototipo.
El hecho de elegir el yaw para el desarrollo de mensajes NMEA propios se debe
a que el valor que se envía coincide con el del COG (Course Over Ground), que se
transmite automáticamente desde el dispositivo Cobalt en los mensajes AIS tipo 18, lo
que permite constatar la viabilidad de creación de mensajes propios. En la figura 5.7
se presentan las fases que conforman el algoritmo que se implementa en un script de
Python sobre la BeagbleBone Black.
66 5.2. Firmware de control
Captura de datos angularesdel dron en MAVLink
Creación de mensaje AIStipo HDT sin checksum
Cálculo del checksum demensaje AIS tipo HDT
Creación de mensaje AIStipo HDT con checksum
Envío del mensaje AIStipo 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 y roll 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
1 import os
2 call (./ attitude_execute , shell = true)
3 yaw = 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.
1 yaw = getYaw ()
2 data = "$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 de-
limitador *. 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
2 end = data.find(’*’)
3 start = 0
4 if data [0] in (’$’,’!’):
5 start = 1
6 if -1 != end:
68 5.2. Firmware de control
7 data = data[start:end]
8 else:
9 data = data[start :]
10
11 # calculo de checksum
12 sum = 0
13 for k in 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 y el checksum 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 biblio-
teca Adafruit_BBIO las funciones relativas a la UART del dispositivo, y seguidamente
habilitar la UART1 mediante la función setup.
1 import Adafruit_BBIO.UART as UART
2
3 # codigo del programa
4
5 UART.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 y close, respectivamente.
1 ser = serial.Serial(port = ’/dev/ttyO1’, baudrate = 9600)
2 ser.close ()
3 ser.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.
1 if ser.isOpen ():
2 ser.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 prue-
bas para verificar si el funcionamiento del prototipo diseñado presenta un comporta-
miento 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 mensa-
jes 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 BMT-
IDeTIC 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 AISBMT-IDeTIC
Raspberry Pi
RegletaSwitch
Scripts propios
Conexión API MarineTraffic
Conexión remota
Ordenadorpersonal
Prototipo
Fuente dealimentación
Toma eléctrica
Toma Ethernet
AntenaVHF
AntenaVHF
AntenaGPS
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 equiposde comunicación
Regleta dealimentació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 arquetade 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 BMT-
IDeTIC 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 Marine-
Traffic y almacenarlos en diferentes formatos, entre los que destacan los formatos CSV
(Comma-separated values) y XML (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 BMT-
IDeTIC provoca que la detección de aquellos mensajes propios del prototipo desarro-
llado 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 BMT-
IDeTIC 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 co-
nexió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 aque-
llos 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.
76 6.3. Verificación y pruebas del prototipo integrado
Importar
servertel2.py bmtidetic_file_raw.txt
bmtidetic_file_parsed.txt
ais_bmtidetic.py
ais.py
Ejecutar yalmacenaren fichero
Introducirficheros
Mensajes conotros formatos
Conexión Telnet(dirección, puerto)
Datos AIS en CSV
API de MarineTraffic Ficheros Bash
propios del IDeTIC
Datos recibidos de la estación AIS
BMT-IDeTIC
Tratamiento de los datos AIS
Conexiónserie conser2net
Figura 6.4: Flujo de ejecución de los scripts implementados
6.3. Verificación y pruebas del prototipo integrado
Para la realización de las pruebas de transmisión y recepción de los mensajes AIS
relativos al prototipo desarrollado, es necesaria la ejecución de los ficheros comenta-
dos en el apartado anterior. De esta manera, se obtiene durante un cierto periodo de
tiempo los mensajes AIS transmitidos por el prototipo y posteriormente, recibidos por
la estación AIS BMT-IDeTIC y almacenados en el servidor Linux del IDeTIC sobre
ficheros de texto. Aquellos mensajes que se corresponden únicamente con el prototipo
se filtran a partir de su MMSI, representándose junto a los campos asociados a los
mensajes y en formato de tramas con formato NMEA.
6. Verificación y pruebas del sistema 77
Además, aprovechando la utilidad que aporta la API de MarineTraffic, se realiza una
comparativa entre los valores almacenados en ficheros CSV a través de esta API y los
que se obtienen tras la ejecución de los scripts comentados anteriormente. Finalmente,
se comprueba a través de dos herramientas software de visualización de estaciones AIS
que el prototipo transmite los datos recogidos y es identificable, de forma gráfica, a
través de este tipo de aplicaciones.
6.3.1. Verificación de mensajes AIS transmitidos y recibidos
En los ficheros de texto bmtidetic_file_parsed y bmtidetic_file_raw se alma-
cenan todos los mensajes AIS del prototipo, filtrados a partir del MMSI asignado y
enviados durante un periodo de 24 horas. Inicialmente, los parámetros a los que se
atiende para las pruebas son los siguientes:
MMSI, formado por 9 dígitos que identifican a la estación AIS.
STATUS, indica el tipo de embarcación que contiene a la estación AIS.
TIMESTAMP, indica la fecha y hora de llegada de cada mensaje AIS.
LAT, indica la latitud en formato decimal.
LON, indica la longitud en formato decimal.
SPEED, indica la velocidad a la que se desplaza la estación AIS.
COG, indica el rumbo de la estación AIS.
HDT, indica el rumbo de la estación AIS señalada por el dispositivo GPS con el
que se comunica el piloto automático del dron a través de comandos MAVLink.
El parámetro TIMESTAMP permite monitorizar los tiempos de llegada y almacena-
miento de los mensajes durante el periodo de pruebas. Debido a que durante el periodo
indicado se recibe un total de 240 mensajes AIS tipo 24 (estáticos) y 480 mensajes AIS
tipo 18 (dinámicos), es necesario tomar una muestra de 10 mensajes significativos en
tiempos consecutivos dos a dos.
78 6.3. Verificación y pruebas del prototipo integrado
En la tabla 6.1 se representan 10 tramas AIS del prototipo, recibidas durante el
periodo de pruebas y almacenadas en el fichero bmtidetic_file_raw, donde se pueden
distinguir tanto mensajes AIS estáticos como dinámicos.
Tabla 6.1: Tramas NMEA contenidas en los mensajes AIS transmitidos por el prototipo
Mensajes AIS en formato NMEA!AIVDM,1,1„A,B1b4Vhh00?fD8D40wssJWwl5oP06,0*4D 17:30:42, 02/02/17!AIVDM,1,1„A,B1b4Vhh00?fD8>40wrWJWwlUoP06,0*72 17:33:43, 02/02/17!AIVDM,1,1„A,H1b4VhmSC=D5j0Q0000000000000,0*3D 21:36:40, 02/02/17!AIVDM,1,1„B,H1b4VhmSC=D5j0Q0000000000000,0*3E 21:42:41, 02/02/17!AIVDM,1,1„A,B1b4Vhh00?fD8U40wsoJWwl5oP06,0*40 02:00:40, 03/02/17!AIVDM,1,1„B,B1b4Vhh00?fD8LT0wr3JWwl5oP06,0*67 02:03:41, 03/02/17!AIVDM,1,1„A,B1b4Vhh00?fD8QT0wsWJWwl5oP06,0*1C 10:27:41, 03/02/17!AIVDM,1,1„B,B1b4Vhh00OfD8J40wqGJWwl5oP06,0*06 10:30:06, 03/02/17!AIVDM,1,1„B,B1b4Vhh00?fD8G40wsJKWwS5oP06,0*4A 17:24:42, 03/02/17!AIVDM,1,1„A,B1b4Vhh00OfD8L40wtrKWwSUoP06,0*6D 17:27:41, 03/02/17
Atentiendo al TIMESTAMP, se observa que en los periodos consecutivos dos a dos, la
duración de llegada entre mensajes AIS es de 3 minutos. Estos mensajes se corresponden
con los tipo 18, como se comprueba seguidamente a través de la decodificación de
la trama, que son los que indican la información dinámica del prototipo (velocidad,
rumbo, ubicación...). Por otro lado, los mensajes consecutivos con una duración entre
ellos de 6 minutos, indicados con color rojo en la tabla 6.2, se corresponden con los
mensajes estáticos, que únicamente envían información relativa al MMSI o el nombre
de la estación AIS, entre otros.
Seguidamente, se analizan los mensajes AIS dinámicos recogidos en la tabla 6.1
pero decodificados y representados en formato tabular. De este modo, se representan
en la tabla 6.2n los mensajes almacenados en el fichero bmtidetic_file_parse, donde
se pueden apreciar los datos dinámicos decodificados y representados en función de los
campos indicados al inicio de este punto de la memoria.
6. Verificación y pruebas del sistema 79
Tabla 6.2: Muestra de mensajes AIS dinámicos decodificados y con formato tabular
MMSI LAT LONG SPEED COG HDT STATUS TIMESTAMP111224515 28.07 -15.4538 0 341.9 341.6 99 17:30:42, 02/02/17111224515 28.07 -15.4538 0 341.9 341.5 99 17:36:43, 02/02/17111224515 28.07 -15.4538 0 341.9 341.5 99 02:00:40, 03/02/17111224515 28.07 -15.4538 0 341.9 341.6 99 02:03:41, 03/02/17111224515 28.07 -15.4538 0 341.9 341.6 99 10:27:41, 03/02/17111224515 28.07 -15.4538 0 248.9 248.3 99 10:30:06, 03/02/17111224515 28.07 -15.4538 0 248.9 248.3 99 17:24:42, 03/02/17111224515 28.07 -15.4538 0 248.9 248.2 99 17:27:41, 03/02/17
Atendiendo al parámetro TIMESTAMP de esta tabla, se observa que los parámetros
dinámicos se mantienen constantes durante aproximadamente 16 horas. Sin embargo,
aproximadamente a las 10:30 horas, se hace mover el dron apuntando a otra dirección,
por lo que los valores angulares del parámetro COG varían significativamente. Al no
haber desplazamiento del dron, la velocidad (SPEED) se mantiene nula y por tanto, el
periodo de envío de los mensajes estáticos se mantiene en 3 minutos, tal y como indica
el estándar. Lo mismo ocurre con la ubicación del dron, dada a través de la latitud y
longitud (LAT y LON), que al no variar la ubicación de la aeronave, siempre marcan el
mismo valor.
Además, se comprueba que el campo HDT es prácticamente idéntico al de COG, con
diferencias menores de 1o que se deben a las desviaciones en los datos GPS del dron, ya
que al realizar estas pruebas dentro de un recinto cerrado, la precisión de las medidas se
reduce. Por otra parte, en lo que respecta a los parámetros estáticos, el parámetro MMSI
indica el identificador propio del prototipo (111224515), mientras que con STATUS se
indica que el prototipo se encuentra a bordo de una estación AIS de tipo 99, clasificada
como otros tipos de embarcaciones. Por tanto, los valores configurados en el módulo
Cobalt coinciden con los indicados en la tabla 6.2.
Finalmente, con el objetivo de visualizar otros formato de tramas AIS, se ha-
ce una llamada al script ais.py para cambiar el formato de presentación a partir
de la información almacenada en los ficheros de texto bmtidetic_file_parsed y
bmtidetic_file_raw. En las tablas 6.3 y 6.4 se presenta un ejemplo de mensaje AIS
tipo 18 y tipo 24, respectivamente, sobre los que se les aplica el formato desglosado
que se ejecuta desde el script ais.py.
80 6.3. Verificación y pruebas del prototipo integrado
Tabla 6.3: Mensaje AIS tipo 18 del prototipo con campos de datos desglosados
Parámetro ValorMessage Type 18Repeat Indicator 0MMSI 111224515Regional reserved 0Speed Over Ground 0.0Position Accuracy 1Longitude -15.4537666667Latitude 28.0711133333Course Over Ground 248.9True Heading 248.3Time Stamp 7Regional reserved 0CS Unit 1Display flag 0DSC flag 1Band flag 1Message 22 flag 1Assigned 0RAIM flag 1Radio status 917510
Tabla 6.4: Mensaje AIS tipo 24 del prototipo con campos de datos desglosados
Parámetro ValorMessage Type 24Repeat Indicator 0MMSI 111224515Part Number 1Ship Type 99Vendor ID SMTE2Call SignDimension to Bow 0Dimension to Stern 0Dimension to Port 0Dimension to Starboard 0
6. Verificación y pruebas del sistema 81
6.3.2. Comparativa de resultados obtenidos a través de la API
de MarineTraffic
En virtud de los resultados obtenidos en las pruebas anteriores, es posible hacer una
comparación entre estos resultados y los que automáticamente se obtienen a través de
la API de MarineTraffic. En este sentido, con la API se generan ficheros CSV de los
datos recibidos por todas las estaciones AIS circundantes, pero se realiza el mismo
filtrado en función del MMSI del prototipo que se aplica en las pruebas anteriores. De
esta manera, se almacenan los mensajes recibidos durante un periodo de 24 horas en
la misma fecha y hora en que se comienzan a realizar las pruebas iniciales.
Con ello, se extraen estos mensajes AIS almacenados en el servidor Linux del IDe-
TIC como ficheros CSV durante el periodo indicado. Seguidamente, se toma una mues-
tra de 10 mensajes que coincida con los mensajes tomados en la muestra de la tabla
6.2, en virtud de los tiempos de almacenamiento del mensaje sobre el fichero, tal y
como se refleja en la tabla 6.5.
Tabla 6.5: Mensajes AIS obtenidos desde la API de MarineTraffic
MMSI LAT LON SPEED COG STATUS TIMESTAMP111224515 28.0711 -15.4538 0 341.9 99 2016-12-02T17:30:06111224515 28.0711 -15.4538 0 341.9 99 2016-12-02T17:36:4111224515 28.0711 -15.4538 0 341.9 99 2016-12-03T02:00:06111224515 28.0711 -15.4538 0 341.9 99 2016-12-03T02:03:06111224515 28.0711 -15.4538 0 341.9 99 2016-12-03T10:27:06111224515 28.0711 -15.4538 0 248.9 99 2016-12-03T10:30:42111224515 28.0711 -15.4538 0 248.9 99 2016-12-03T17:24:05111224515 28.0711 -15.4538 0 248.9 99 2016-12-03T17:27:41
Por tanto, si se comparan los valores de las tablas 6.2 y 6.5, exceptuando el pará-
metro HDT que no entrega la API de MarineTraffic, se observa que salvo los tiempos de
recepción de los mensajes, el resto de parámetros coinciden. Esto se debe a que el servi-
dor de MarineTraffic toma su propio tiempo del sistema cuando recibe un mensaje AIS
y lo procesa para su posterior envío, por lo que los tiempos marcados en los mensajes
pueden diferenciarse hasta un máximo de 2 minutos con respecto a los recibidos origi-
nalmente a través de la estación AIS BMT-IDeTIC. Sin embargo, esta prueba permite
constatar que los mensajes del prototipo se reciben correctamente, ya sea a través de
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 visuali-
zación de tráfico marítimo
Otra forma de comprobar el funcionamiento del prototipo es a través de herramien-
tas 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 MarineTraf-
fic, 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 An-
droid e iOS, que permiten consultar el tráfico marino de una región o realizar el segui-
miento 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 estacio-
nes 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 autono-
mí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 ca-
libració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 ex-
perimental, 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. Apli-
cació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 Ship-
borne 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 Mariti-
me 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 tripu-
lado) 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 naviga-
tion, 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 identi-
fication 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 Sys-
tems, 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-12-
21.
[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,” Transporta-
tion 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 Enginee-
ring, 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 Pro-
jects 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 repo-
sitory 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 Recomen-
daciones, 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-12-
25.
[45] F. Cabrera, N. Molina, M. Tichavska, and V. Araña, “Design of a low cost prototy-
pe of Automatic Identification System (AIS) receiver,” in 2015 1st URSI Atlantic
Radio Science Conference (URSI AT-RASC), pp. 1–1, May 2015.
Parte II
Presupuesto
93
Presupuesto
P.1. Introducción
En este capítulo se desarrolla el presupuesto de este Trabajo Fin de Máster, que
permite valorar los costes que han supuestos los materiales y herramientas utilizados
durante su elaboración, además del coste del trabajo realizado. Para ello, los puntos
tratados en este capítulo en relación al cálculo del coste total que supone este trabajo
son los siguientes:
Costes de los materiales.
Amortización del inmovilizado material.
Trabajo tarifado por tiempo empleado.
Aplicación de impuestos y coste total.
P.2. Costes de materiales
Normalmente, costes de materiales de un proyecto se pueden diferenciar entre
costes de materiales fungibles, referidos a todos aquellos elementos adquiridos y que
están expuestos a un deterioro con el uso durante la elaboración del proyecto, y costes
de materiales no fungibles, que se asume que no están expuestos a deterioro durante
el periodo de ejecución del proyecto. Para este Trabajo Fin de Máster, la ausencia de
materiales no fungibles implica que únicamente se atienda al coste de los materiales
fungibles, dada la temática del mismo, y se clasifican en dos categorías:
95
96 P.2. Costes de materiales
Materiales hardware, que hacen referencia a componentes hardware que son
utilizados para la elaboración de este trabajo, sin incluir los equipos de medida
que, al ser amortizables, no se incluyen en esta categoría.
Materiales software, que hacen referencia a las licencias de los programas que
se emplean en este trabajo, asumiendo un tiempo de uso de un año, motivo por
el que no se incluye en la categoría de elementos amortizables.
Además de esta clasificación, se añaden a los costes materiales la categoría de otros
conceptos de gastos, donde se evalúan aquellos elementos adquiridos que no pueden
englobarse formalmente en ninguna de las dos categorías anteriores, aunque se imputan
igualmente en los costes materiales finales del Trabajo Fin de Máster.
P.2.1. Materiales hardware
En la tabla P.1 se presentan los costes totales, en función del número de unidades
necesarias, de los materiales hardware utilizados en este Trabajo Fin de Máster.
Tabla P.1: Costes de materiales fungibles hardware
Concepto UnidadesCoste
unitario
Coste to-
tal
Carrete de estaño para soldadura (250
g)1 21,26 e 21,26 e
Bote de pasta para soldadura 2,52 e 1 2,52 e
Kit de tubos de plástico termoretrácti-
les10,12 e 1 10,12 e
Transceptor AIS clase B Cobalt 1 250 e 250 e
Microcontrolador BeagleBone Black 1 59,33 e 59,33 e
Conector Hirose DF13-40P-1.25V(91) 10 6,23 e 60,23 e
Cable Hirose DF13 40 1,19 e 47,60 e
Cable USB macho-macho tipo A 2 2,35 e 4,70 e
Pares de cable BNC rojo y negro 1 3,20 e 6,4 e
97
Antena VHF con base magnética 1 12,30 e 12,30 e
Antena VHF portable 1 7,34 e 7,34 e
Antena GPS con base magnética 1 15,85 e 15,85 e
Kit de accesorios y repuestos para dro-
nes 3D Robotics1 1.000 e 1.000 e
Kit de dron DIY Y6 3D Robotics 1 1.300 e 1.300 e
Receptor AIS COMAR SLR-300N 1 459,71 e 459,71 e
Raspberry Pi 3 1 46,50 e 46,50 e
Carcasa protectora para Raspberry Pi 1 7,59 e 7,59 e
Cable Ethernet RJ45 (1 m) 2 1,49 e 2,98 e
Cargador ETA-U90EBE 2A 5V 1 9,90 e 9,90 e
Cargador Power-Bank 2100 mAh 5V 1 14,90 e 14,90 e
Coste total 3.341,3 e
Por tanto, el coste total de los materiales hardware fungibles empleados en este
Trabajo Fin de Máster asciende a tres mil trescientos cuarenta y uno con treinta euros.
P.2.2. Materiales software
En la tabla P.2 se presentan los costes de licencia de cada uno de los programas
utilizados durante la elaboración de este Trabajo Fin de Máster.
Tabla P.2: Costes de materiales no fungibles software
Concepto Coste de licencia
Aplicación proAIS2 0 e
Aplicación OpenCPN 0 e
Editor Python 2.7 0 e
Editor LATEX Texmaker 0 e
Editor Adobe Illustrator 2016 académico 19,66 e
Editor Keynotes para presentaciones 0 e
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 ad-
quieren, 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 impreso-
ra)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
o software 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 Va es el valor adquisitivo inicial del producto, Vr el valor residual del producto
(que se calcula considerando un porcentaje de desuso k = 0, 6 sobre el valor adquisitivo
inicial), T es el tiempo de vida del producto y Tu el 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 UnidadesValor de
adquisición
Valor re-
sidual
Vida
útilTotal
Portátil MacBook Pro
Retina 13.3” i5 512
GB
1 1.449 e 869,4 e 5 años 38,25 e
Fuente de alimenta-
ción PROMAX FAC-
662B
1 556,9 e 334,14 e 8 años 9,19 e
Estación de soldadura
JBC1 395 e 237 e 8 años 6,52 e
Antena VHF marino
Shakespeare Marine
5202
2 105,40 e 63,24 e 10 años 2,78 e
100 P.4. Trabajo tarifado por tiempo empleado
Cargador de baterías
iMAX B6 LiPro Ba-
lance Charger
1 32,84 e 19,7 e 1 año 4,33 e
Ordenador Acer i5 512
GB con sistema opera-
tivo Linux
1 865 e 519 e 5 años 22,84 e
Receptor AIS Comar
SLR 300N cedido por
MarineTraffic
1 0 e 0 e 8 años 0 e
Analizador de redes
HP 8753D1 2.943 e 1.765,8 e 10 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íaSueldo
mensual
Número de ho-
ras trabajadas
Sueldo por ho-
ra trabajada
Sueldo
final
Ingeniero 1.192,99 e 300 6,78 e 2.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 Impues-
to 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 elec-
tró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
108
Anexo B
Divulgación de resultados
Durante la realización del Trabajo Fin de Grado que precede a este Trabajo Fin de
Máster, titulado Diseño e implementación de un prototipo hardware para un banco de
pruebas del estándar AIS, se presentó una propuesta y un póster en el Congreso URSI
AT-RASC en mayo de 2015, celebrado en Maspalomas, Gran Canaria (España) [45].
Tras la presentación de esta propuesta, los autores (Francisco José Cabrera Almei-
da, Milûse Tychavska, Víctor Alexis Araña Pulido y Nicolás Molina Padrón) evaluaron
la posibilidad de publicar los resultados obtenidos en los meses posteriores al congre-
so, y en julio de 2016 presentaron el artículo Automatic Identification System modular
receiver for academic purposes en la revista AGU Publication Radio Science, que está
indexada en JCR (Journal Citation Reports) con un factor de impacto 1.273 y situada
en el segundo cuartil dentro del Área de Telecomunicación. En este artículo se seña-
lan los principales hitos alcanzados durante la elaboración del Trabajo Fin de Grado
mencionado, centrando el estudio en el diseño del receptor AIS modular, y no del trans-
misor, de forma que pudiese resultar de interés para fines académicos, principalmente
en lo que concierne al nivel físico de este estándar y en la búsqueda de obtener un re-
ceptor AIS sencillo que no diste demasiado de los modelos comerciales. A continuación,
se adjunta el artículo publicado.
109
Automatic Identification System modular receiverfor academic purposesF. Cabrera1, N. Molina1, M. Tichavska2, and V. Araña1
1IDeTIC, Departamento de Señales y Comunicaciones, Universidad de Las Palmas de Gran Canaria (ULPGC), Las Palmas,Spain, 2Exmile Solutions Limited (MarineTraffic), London, UK
Abstract The Automatic Identification System (AIS) standard is encompassed within the Global MaritimeDistress and Safety System (GMDSS), in force since 1999. The GMDSS is a set of procedures, equipment, andcommunication protocols designed with the aim of increasing the safety of sea crossings, facilitatingnavigation, and the rescue of vessels in danger. The use of this system not only is increasingly attractive tosecurity issues but also potentially creates intelligence products throughout the added-value informationthat this network can transmit from ships on real time (identification, position, course, speed, dimensions,flag, among others). Within the marine electronics market, commercial receivers implement this standardand allow users to access vessel-broadcasted information if in the range of coverage. In addition to satelliteservices, users may request actionable information from private or public AIS terrestrial networks wherereal-time feed or historical data can be accessed from its nodes. This paper describes the configuration of anAIS receiver based on a modular design. This modular design facilitates the evaluation of specific modulesand also a better understanding of the standard and the possibility of changing hardware modules toimprove the performance of the prototype. Thus, the aim of this paper is to describe the system’sspecifications, its main hardware components, and to present educational didactics on the setup and use of amodular and terrestrial AIS receiver. The latter is for academic purposes and in undergraduate studies such aselectrical engineering, telecommunications, and maritime studies.
1. Introduction
The Automatic Identification System (AIS) broadcasts high-speed, automatic, and granular information fromthe activity of vessels at sea. It is a very high frequency (VHF) radio broadcasting system that enables AIS-equipped vessels and shore-based stations to send and receive static (vessel-identifying details), dynamic(vessel position, speed, navigational status, among others), and voyage (destination port and the estimatedtime of arrival of the vessel) information.
An AIS transponder, as a shipboard device, automatically transmits vessel information allowing ships andshore stations to easily receive these details and track, identify, or exchange vessel traffic details. At the sametime, vessels fitted with AIS transponders can be tracked by AIS receivers located along the coast lines or,when out of range of terrestrial networks, throughout a growing number of satellites (and lately nanosatel-lites) fitted with AIS receivers.
The communication standard of the AIS was conceived by the International Telecommunication Unionand adopted by the International Maritime Organization. The latter through the Safety of Life at SeaConvention [Safety of Life at Sea, 1974] and its requirement for AIS transponders is to be fitted aboard inter-national voyaging ships with gross tonnage (GT) of 300 or more and all passenger ships regardless of size.Communication devices that integrate the transmission and receiving capabilities of the AIS are commerciallyavailable [Lanier, 2012; MarineTraffic web, 2016, http://shop.marinetraffic.com/ais-receivers.html]. Theseenable the access to vessel information (speed, heading, course, vessel dimensions, and other particulars)when vessels are within coverage range. However, the acquisition of AIS-receiving devices or custom distri-bution channels from AIS-receiving networks commonly implies a substantial cost, and it is not always acces-sible for nonfunded and academic purposes. Based on the above described need and objective, the presentpaper has been structured as follows.
Section 2 discusses the description of the system in accordance with the Open Systems Interconnection (OSI)model (physical, link, and network layer) and the relevant specifications that all devices must have [ITU-R Rec.M.1371-5, 2014]. Section 3 presents our modular receiver design, implemented in compliance with the AIS
CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1038
PUBLICATIONSRadio Science
RESEARCH ARTICLE10.1002/2015RS005895
Special Section:URSI AT-RASC (Atlantic RadioScience Conference)
Key Points:• Automatic Radio System foridentifying and locating vessels
• Modular receiver for use throughdevices of general purpose
• Explore AIS-related didactics inundergraduate studies
Correspondence to:F. Cabrera,[email protected]
Citation:Cabrera, F., N. Molina, M. Tichavska,and V. Araña (2016), AutomaticIdentification System modular receiverfor academic purposes, Radio Sci., 51,1038–1047, doi:10.1002/2015RS005895.
Received 1 DEC 2015Accepted 1 JUL 2016Accepted article online 5 JUL 2016Published online 18 JUL 2016
©2016. American Geophysical Union.All Rights Reserved.
specifications. For this, general purpose and commercially available devices such as an FM demodulator RX1of Radiometrix, a GMSK demodulator baseband, CMX589A CML Microcircuits integrated into a DV-MEGAplate, and an Arduino UNO R3 microcontroller (for the storage of information received) have been used.Also, a Front-End unit has been set up on a computer with open source software in order to decode theAIS frame. Section 4 presents device results of a preliminary performance test from the proposed modularreceiver and an AIS commercially available receiver. This is to verify its correct operation. Finally, insection 5, the conclusions of this work are shown.
2. System Description
The AIS is an open system that allows nonencrypted and broadcasted information to be received by anydevice that meets the system specifications. This system operates in the VHF maritime band, and it is capableof handling well over 2250 reports per minute. Each AIS device (vessel transponder and coastal or satellitereceiver) monitors the vessel speed and determines the interval when the messages are being sent out. Asthe speed of the transponder increases, the frequency of messages increases and vice versa when the velo-city decreases. AIS static data are automatically transmitted every 2 to 10 s depending on the vessel’s speedwhile underway and every 6min while anchored. On the other hand, static- and voyage-related informationis manually introduced by the vessel’s crew and transmitted every 6min regardless of the vessel’s movementspeed or status [ITU-R Rec. M.1371-5, 2014]. The principles of operation of the AIS are based on the Self TimeDivision Multiple Access (SOTDMA) protocol. This protocol is responsible for the organization of the packetand the information generated by the transponders and its order in time. These data packets contain twotypes of data: static-/voyage-related information (International Maritime Organization number, call sign,name, destination, and Estimated Time of Arrival) and dynamic details (MaritimeMobile Service Identity num-ber (MMSI), rate of turn, position coordinates, course over ground, and heading), among others. This systemcan be described throughout the OSI model. The first three layers of this model are defined in the standard,leaving the other layers for the user to make its own implementation. It should be noted that the receptionsubsystem of transponders installed in vessels and receivers located in the coast comprise the same charac-teristics described in the OSI model.
2.1. Physical Layer
The AIS transmission uses non-return-to-zero (NRZ) digital data encoded with a rate of 9.6 kbit/s using aGMSK modulation baseband and band pass subsequently modulated by FM. The frequency bands usedare two (AIS-1: 161.975MHz and AIS-2: 162.025MHz) using a 25 kHz channel [ITU-R Rep. M.2123, 2007].
2.2. Link Layer
The link-level details support the management of bit patterns, as well as the error detection and correctionthat are carried out before sending packets over the network. Therefore, it is the layer that assures the relia-bility of bitstream. This layer is divided into three sublayers: the Medium Access Control (MAC), the Data LinkService (DLS) sublayer, and the Link Management Entity (LME).2.2.1. MAC SublayerThe MAC sublayer ensures a correct data transfer. For this reason, it is necessary to include references to com-mon time between AIS receiving stations within the network. Thus, all AIS stations should be synchronizedunder a common time reference called universal time coordinated (UTC) which is given by the GlobalPosition System (GPS) of the transmitting network of vessels.2.2.2. DLS SublayerThe DLS sublayer is responsible for providing a format in AIS frames. Each AIS frame consists of 32 bytes fol-lowing the High-level Data Link Control standard, and this is organized as follows. First, the Preamble (3 bytes:0x55 0x55 0x55) is transmitted, next the Start Flag (1 byte: 0x7E) and subsequently the data field (21 bytes),the cyclic redundancy check (CRC) (2 bytes) field to control errors in AIS frames, and finally, Stop Flag (1 byte:0x7E). In addition, a 24 bit temporary buffer supplementing the frame and used for tasks bit stuffing, distancedelay, repeater delay, and jitter effects is included.2.2.3. LME SublayerThe LME sublayer implements the scheme of TDMA. Thus, each AIS receiving station has an assigned timeinterval (slot) to share the channel with other stations and the transfer of data. This implies that the receiving
Radio Science 10.1002/2015RS005895
CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1039
stations are synchronized. This timing is determined by the reference time UTC (obtained in the MAC),common to all AIS receiving stations integrated into a region of coverage.
Within the AIS standard, each slot has a duration of 26.67ms. If each frame has a time duration of AIS of 60 s,the total number of slots in a frame AIS is
N ¼ 60 � Δtslot ¼ 60 � 26:67≃2250 slots (1)
In Figure 1, a TDMA scheme for both AIS channels available is observed, verifying the duration for each slot of26.67ms. The AIS standard incorporates different media TDMA access schemes, but the main one is theSOTDMA scheme [Eriksen et al., 2006].2.2.4. Network SublayerIn this layer the sending and receiving of data packets is performed. The network layer performs the task ofsending frames, commonly through a Transmission Control Protocol (TCP)/Internet Protocol networkthrough of TCP or User Datagram Protocol (UDP) ports. The AIS allows users to implement the upper layerswith the only requirement of being compatible with the network level.
3. Modular Receiver Description
Once the AIS characteristics and components have been discussed in the previous section, the modulardesign of a receiver will be described (DV-MEGA web, 2016, http://www.dvmega.auria.nl/GMSK_shield.html).The modular design of the receiver presented in this section is of interest in academic environments thatallow to evaluate each device independently. The elements that characterize this receiver are as follows: amaritime VHF antenna, a FM receiver RX1 Radiometrix, a GMSK modem DV-MEGA, and a microcontrollerArduino UNO R3. In Figure 2, the connections between each module can be observed. Furthermore, the lastblock reflects a personal computer with a Front-End Program to process the data and send the data over thenetwork. A compact receiver design is achieved by choosing the sizes of all modules equal to the size of theArduino UNO. For this reason, both the DV-MEGA board and the breakout board Radiometrix RX1 meet theserequirements. The connections between the modules are made via USB and Mini DIN-6 connectors. A GPS isonly required in AIS transponders. In this case a GPS is not required due to the exclusive frame-receivingpurposes of its use.
3.1. Radiometrix Demodulator
The Radiometrix RX1-161.975-10 chip is a FM demodulator device that enables the connection to the VHFfrequency 161.975MHz and delivers the demodulated output (baseband) with a sensitivity of �119 dBm.
Figure 1. AIS TDMA scheme.
Radio Science 10.1002/2015RS005895
CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1040
The input impedance of Radiometrix RX1 is of 50Ω connected to a VHF antenna with Voltage Standing WaveRatio less than 1.3. This device has nine-pin input and output of encapsulation, which are the RF In, RXD, GND,Vcc, RSSI, and Enable pin. The RX1 Radiometrix chip is designed with a dual conversion superheterodynetopology FI (Radiometrix web, 2016, http://www.radiometrix.com/files/additional/tx1rx1.pdf) (Figure 3).Signals from the device input pass through the RF stage where a preamp followed by a band-pass filteringis performed. Once filtering is performed in RF, the signal passes through a mixer through another inputconnected to a crystal oscillator frequency to 161.975MHz, allowing the RF signal conversion to performthe first IF stage (FI1). Then, this signal passes through a band-pass fitter and is amplified. Finally, the inter-mediate frequency FI2 is obtained through a second mixer thereby improving the selectivity.
Once the double-conversion FI is performed, the signal passes through a frequency discriminator whichconverts frequency variations into amplitude variations linearly so that the FM modulated signal performs
Figure 3. Radiometrix RX1.
Figure 2. AIS receiver prototype block diagram.
Radio Science 10.1002/2015RS005895
CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1041
a conversion to AM modulated signal. Since the information is located in the envelope of the AM signal, anenvelope detector enables demodulation of the modulated signal. The last stage uses a low-pass cutofffrequency of 7 kHz and is used to improve the selectivity of the demodulator filter. Finally, a receiver bufferto store data received during a certain period of time in order to adapt transmission rates to different typesof protocols is added. The output data are obtained via the RXD pin at a speed which depends on the filing ofthe buffer.
3.2. Baseband GMSK Demodulation
The DV-MEGA board is a shield for Arduino, designed to perform GMSK modulation and demodulation tasksbaseband to speed 9.6 kbit/s. This board (Figure 4) consists of a CMX589A GMSK modem with external syncstages, also with filtered transmit and receive gain and PTT controller.3.2.1. Modem GMSK CMX589AThe CMX589A chip is encapsulated 24-pin designed by the company CML Microcircuits described as a GMSKbaseband modem. This chip supports full-duplex and half-duplex communication modes and allows trans-mission rates between 4 kbit/s and 200 kbit/s. BT (Bandwidth per symbol period) has a configurable pin factorto select the values 0.3 and 0.5. This chip transmits and receives bit serial data with corresponding sync pin tobe connected to the microcontroller for data transfer. Rx input levels can be set with external componentsaround an on-chip Rx Input Amplifier.3.2.2. Clock SystemCMX589A GMSK modem employs a synchronization circuit based on a crystal 9.8304MHz. This crystal fixedclock signal 9.8304MHz to set a bit rate of 9.6 kbit/s. For this, the value N= 1024 is set through ClkDivA andClkDivB lines so that the value of the bit rate is
RB ¼ f XTAL=N ¼ 9:6 kbit=s (2)
However, since the DV-MEGA board has a crystal oscillator of 4.9608MHz, the desoldering and soldering ofthis crystal oscillator was necessary. A more detailed explanation of the process and the new oscillator isfound in IDeTIC-AIS Github Repository (2016, https://www.github.com/IDeTIC-AIS/RX-AIS).3.2.3. Rx Level Adjust SystemTwo filters are placed on pin RxOut of CMX589A chip. The first of these filters is responsible for setting the bitrate output of the device, while the second low-pass filtering performs on the data and includes, via a poten-tiometer, the gain control to the modem output.
In a first step, the passive RC filter low-pass first-order consists of the resistance R=47 kΩ and capacitorC=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 isan active low-pass filter based on anoperational amplifier in inverting config-uration. The gain of this filter is given bythe ratio between the resistive valuesand thus depending on the output ofthe GMSK modem can adjust the signallevel. The solution adopted is to put afixed and a variable resistance so thatwe have a gain value between 7 dBand 10 dB.3.2.4. Push to TalkThe circuits Push to Talk (PTT) are inte-grated into systems for activating anddeactivating RF subsystems transmittingand receiving in half-duplex mode. Inthis design, the activation signal is gen-erated by the Arduino microcontroller.
3.3. Arduino Microcontroller
Arduino is an open programmable hard-ware platform. It is based on a microcon-
troller and a development environment, including specific programming language Processing based, with asyntax similar to C ++. Arduino UNO R3 model integrates an ATmega328P microcontroller 32 KB of Flashmemory, 2 KB of SRAM, and 1 KB of EEPROM. It has 14-pin digital input and output and 6 analog input pinsthat connect to other devices (shield) as the DV-MEGA board. It also has a serial port where programs areloaded 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 routinereads the bits via pin RXD and identifies the start and stop flags to the store the data in the frame, as shownin Figure 5. Once stored, data are converted to NMEA format and through the routine loop() data are sent tothe 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 thatmeets the requirements of our hardware. OpenCPN (OpenCPN web, 2016, http://www.opencpn.org) isa 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 AIS-receiving system by using serial port connection. OpenCPN decodes the data using NMEA [ISO/IEC13239, 2002], visualizing it on the map and allowing the decode of 22 different types of messages. It alsoallows the implementation of the network layer allowing to send the NMEA sentences by using a TCP orUDP port.
4. Results
As mentioned within the structure description of the paper, this section describes results of a preliminaryperformance test from the proposed modular receiver and an AIS commercially available receiver. This isto verify its correct operation.
First, each module has been revised independently to ensure proper operation. Second, a test set has beenperformed in the laboratory to check the system operation. Finally, a proper operation has been verified witha live stream of AIS signals.
The RX1 Radiometrix was verified through a comparison of a baseband signal generated by a functiongenerator with the demodulated signal RX1 device. The GMSK demodulator was verified by mounting twoDV-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 istransmitted from Arduino. D3 and D2 are the GMSK modulated and demodulated. It is noted that a matchexists between the two signals having a propagation delay of 0.15ms between D1 and D2.
Figure 7 shows the prototype receiverfinally implemented. This receiver hasbeen tested using an AIS test systemorganized by a modular receiver equip-ment and other similar transmitter,where both devices are separated bya distance of 1m. AIS frames sent in thistest have been compared with thereceived frames. The 2250 time slotswere used to verify that all had beencorrectly received.
Once the modular receiver has been ver-ified with real AIS frames, the developedprototype had been connected to a VHFmaritime mobile band antenna locatedon the rooftop of the ULPGC Scienceand Technology Park (28.08°N/15.46°W).In Figure 8, the assembly is shown inthe laboratory, by using the digital oscil-loscope to display the received frames.Once stored, frames and changing thetime base on the oscilloscope are shownin Figure 9 as the bitrate is 9.6 kbit/s.This signal passed through the Arduinomicrocontroller that performed the tasksof 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 0183format and its transmission to the computer’s serial port. Table 1 shows an example of this message formatand the most relevant parameters of the manual decoding (using ITU-R Rec. M.1371-5 [2014]) where themessage ID (1) indicates the Position Report.
Figure 10 shows the graphical representation of OpenCPN through a map of the Canary Islands where thenumber of vessels collected in real time is observed. Vessel information can be obtained by clicking on theicon of each. By clicking on the coordinates that have previously been manually decoded, it is found thatthere is a vessel in the same coordinates and time sharing the same MMSI number. This verifies that manualdecoding has been performed satisfactorily. Furthermore, these results were revised again through theMarineTraffic 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 NMand a frequency of up to 300 messages per minute. The latter is below the maximum standard (2250). To usethis software simultaneously bymultiple 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 compu-ters. Each computer can collect serverinformation, allowing to perform mea-surements such as distance and routes.
Finally, a comparative table with otherreceivers is shown in Table 2. This tablereflects the prototype developed withthe Comar SLR300N receiver (ComarSystem web, 2016, http://www.comar-systems.com/slr_300n.html) located inthe same place and used as a nodecalled BMT-IDeTIC in the MarineTrafficNetwork [Tichavska et al., 2015], Daisy-
AIS receiver (Tindie web, 2016, https://www.tindie.com/products/astuder/daisy-ais-receiver/), and RTL-SDRreceiver (RTL-SDR web, 2016, http://www.rtl-sdr.com/rtl-sdr-tutorial-cheap-ais-ship-tracking/). It should benoted that all receivers get NMEA0183 messages at a rate of 38.4 kbit/s. Test results reflect that the receiversensitivity developed has better features than others but has nevertheless been implemented in a singlechannel. The prototype as the Daisy-AIS and the RTL-SDR has not implemented the network layer, thus allow-ing an external program performing it. Finally, the cost of the developed prototype has been 125 €where themajor cost has been covered by the DV-MEGA GMSK device. This price may be of course reduced if manyunits are purchased. The Front-End Unit has not been included since a unit dedicated to the AIS is not neces-sary. In a comparison with the other receivers it is noticeable that the prototype is cheaper than the SLR300Nbut 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 beused 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 electronicengineering, telecommunications, and maritime studies. The performance of the prototype also proves tobe 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 aManual Decoding
NMEA 0183 frame
!AIVDM,1,1,,A,13aN2dPOilNtC1L@@lf0g@`l0H=o,0*78
Parameter Value
Message ID 1MMSI 244810418Speed over ground (SOG) 11.6 knotsLongitude �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 hasalso been described and included as an open source, the latter to simultaneously visualize and map decodedAIS vessel traffic details within a network of computers and thus facilitate AIS-based research and the disse-mination of regional vessel traffic-based knowledge.
At last, results of this work motivate and support the implementation of a more accessible AIS-receiving nodetoward the potential advance of applied and theoretical research within the areas of innovative system archi-tectures 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 unprece-dented 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 implementationof computing systems and actionable intelligence services that further support maritime policy and manage-ment [Shelmerdine, 2016; Tichavska and Tovar, 2015a, 2015b].
ReferencesEriksen, 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-RLanier, 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 dBmNo. of channels 1 2 2 1Output format NMEA0183 NMEA0183 NMEA0183 NMEA0183BaudRate 38.4 kbit/s 38.4 kbit/s 38.4 kbit/s 38.4 kbit/sEthernet port No Yes No NoCost 125 € 304 € 76 € 20 €
aRTL-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
AcknowledgmentsWe would like to extend our acknowl-edgements to MarineTraffic and itsteam for actively contributing to everyquestion raised and for supporting theverification of our results with theMarineTraffic BMT-IDeTIC AIS terrestrialnode and also to Juan DomingoSantana Urbín (ULPGC) for hisenormous contribution during thedevelopment phase of the AIS receiverprototype. At last, the authors wouldlike to thank the reviewers for thevaluable comments and suggestionsthat have enabled the qualityimprovement of this paper. The sourcecode of the firmware, PCB layout, andtwo technical notes may be accessed forfuture academic and research projectsat 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 recibi-
da 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ódu-
lo 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 dispo-
sitivo, 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 Coordi-
nated), la latitud y longitud donde se ubica el dispositivo, los parámetros COG (Course
Over Ground) y SOG (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:
124
Checklist, que indica si la conexión con las antenas de VHF y GPS y la alimen-
tación del módulo se ha realizado correctamente, así como si el dispositivo tiene
un MMSI válido y acceso a la red GPS, y ha recibido mensajes de otros equipos
AIS.
Internal Data, que muestra las versiones del software y del módulo, además de
monitorizar el COE y la tensión que se le suministra al dispositivo.
Status, que no es más que una visualización gráfica del estado de los diodos
LED integrados en el módulo, por lo que su funcionalidad es la misma que la que
indican estos componentes.
Statistics, que cuentan el número de mensajes AIS recibidos y transmitidos
por los dos canales habilitados en el módulo.
Mesages, que muestra los posibles errores que se han producido durante la trans-
misión de los mensajes AIS y marcan las alarmas que el usuario haya configurado
previamente en el dispositivo para ciertos tipos de mensajes.
Figura C.4: Vista de verificación de estado en proAIS2
Por último, en la figura C.5 se muestra un ejemplo de la terminal de mensajes
integrada en este software y que permite al usuario conocer la lista de mensajes AIS
que han sido recibidos y transmitidos con el módulo Cobalt. Esta terminal, además de
C. Vistas del software proAIS2 125
monitorizar todos los mensajes AIS que han sido procesados por el módulo, permite al
usuario ejecutar dos acciones fundamentales:
Log To File, que una vez que el usuario inicie esta acción, los mensajes mos-
trados en la terminal de mensajes se almacenan en un fichero de texto hasta
que nuevamente, el usuario indique que quiere parar el almacenamiento de los
mismos.
Enter Commands, que permite al usuario introducir comandos NMEA que, en
caso de ser correctos en su formato, son enviados por el módulo. Esta acción
resulta de gran utilidad cuando se desea comprobar que el dispositivo es capaz
de enviar ciertos tipos de mensajes al resto de equipos AIS.
Figura C.5: Vista de comandos recibidos y transmitidos en proAIS2
126
Anexo D
Lista de códigos implementados
D.1. Generación y envío de mensajes HDT propios
del prototipo
1 #!/usr/bin/env python
2
3 # bibliotecas y ficheros importados
4 import attitude_module
5 import Adafruit_BBIO.UART as UART
6 import serial
7 import time
8
9 # datos de entrada y formato de mensaje
10 yaw = getYaw ()
11 data = "$HEHDT ," + yaw + ",T"
12
13 # inicializacion de inicio y fin de mensaje
14 end = data.find(’*’)
15 start = 0
16 if data [0] in (’$’,’!’):
17 start = 1
127
128 D.1. Generación y envío de mensajes HDT propios del prototipo
18 if -1 != end:
19 data = data[start:end]
20 else:
21 data = data[start:]
22
23 # calculo de checksum
24 sum = 0
25 for k in data:
26 sum = sum ^ ord(k)
27 sumHex = " %x" % sum
28 if len(sumHex) == 1:
29 sumHex = ’0’ + sumHex
30 checksum = sumHex.upper ()
31 message = data + "*" + str(checksum)
32
33 # envio por UART
34 UART.setup("UART1")
35 ser = serial.Serial(’/dev/ttyO1’, baudrate = 9600)
36 ser.close ()
37 ser.open()
38
39 # comprobacion y envio recurrente
40 while ser.isOpen:
41 ser.write(message)
42 ser.close ()
Código D.1: Generación y envío de mensajes HDT propios del prototipo
D. Lista de códigos implementados 129
D.2. Almacenamiento y filtrado de mensajes AIS re-
cibidos del prototipo
1 #!/usr/bin/env python
2
3 # bibliotecas y ficheros importados
4 import telnetlib
5 import time
6 import sys
7 import ais_bmtidetic
8
9 # habilitacion de direccion y puerto para conexion Telnet
10 address = ’10.13.30.35 ’
11 port = ’2000’
12 # definicion de ficheros de texto para almacenamiento
13 outfileraw = ’bmtidetic_file_raw.txt’
14 outfileparsed = ’bmtidetic_file_parsed.txt’
15 # valor de filtrado para MMSI del prototipo
16 MMSI = "B1b4Vhh00"
17
18 # se habilita una conexion Telnet con la direccion y el
19 # puerto asignados previamente
20 tn = telnetlib.Telnet(address , port)
21 # se abren los ficheros de texto para almacenamiento
22 # definidos previamente
23 fraw = open(outfileraw , ’a’)
24 fparsed = open(outfileparsed , ’a’)
25
26 # en todo momento se realiza la lectura de los datos
27 # recibidos por Telnet , y si se corresponden con el
28 # MMSI del prototipo , se almacenan en los ficheros de
29 # texto definidos previamente
130D.2. Almacenamiento y filtrado de mensajes AIS recibidos del prototipo
30 while 1:
31 data = tn.read_until("\n")
32 long = len(data)
33 if data.find(MMSI) == 14:
34 for (raw , parsed) in ais_bmtidetic.parse_ais_messages(
data , True , False , 0):
35 timedata1 = time.strftime(" %H: %M: %S")
36 timedata2 = time.strftime(" %d/ %m/ %y")
37 print "Mensaje de IDETIC DRONE AIS recibido"
38 # se escribe la trama AIS con formato NMEA del
39 # prototipo sobre el fichero
40 # ’bmtidetic_file_raw.txt’
41 fraw.write(raw)
42 # se escribe la trama AIS decodificada a partir de
43 # la funcion importada ’parse_ais_messages ’, junto
44 # con la fecha y hora del sistema , sobre el
45 # fichero ’bmtidetic_file_parsed.txt’
46 fparsed.write(parsed + ", " + timedata1 + ", " +
timedata2 + ’\n’)
47 fraw.flush ()
48 fparsed.flush ()
Código D.2: Almacenamiento y filtrado de mensajes AIS recibidos del prototipo