diogo andré dias salgueirorepositorium.sdum.uminho.pt/bitstream/1822/46721/1/tese... ·...
TRANSCRIPT
Diogo André Dias Salgueiro
Sistema de monitorizaçãopara veículos aéreos não tripulados
Diog
o An
dré
Dias
Sal
gueir
o
junho de 2015UMin
ho |
201
5Si
stem
a de
mon
itori
zaçã
opa
ra v
eícu
los
aére
os n
ão tr
ipul
ados
Universidade do MinhoEscola de Engenharia
junho de 2015
Dissertação de MestradoCiclo de Estudos Integrados Conducentes ao Grau deMestre em Engenharia Eletrónica Industrial e Computadores
Trabalho efectuado sob a orientação doProfessor Doutor Paulo Cardoso
Diogo André Dias Salgueiro
Sistema de monitorizaçãopara veículos aéreos não tripulados
Universidade do MinhoEscola de Engenharia
iii
Agradecimentos
Sendo este trabalho o culminar de mais uma etapa do meu percurso académico, não posso
deixar de agradecer a todos que, direta ou indiretamente contribuíram para que a sua realização
fosse possível.
Gostaria de agradecer, em primeiro lugar aos meus pais, por todas a oportunidades que me
proporcionaram em termos académicos e pessoais de forma a que eu atingisse esta meta. Seja
em termos financeiros ou morais estiveram sempre disponíveis para me ouvir, aconselhar e
apoiar nas decisões tomadas e caminhos seguidos.
Agradecer ao Professor Doutor Paulo Cardoso pelo apoio dado enquanto orientador, pelo
tempo dispendido em reuniões, pela paciência para infindáveis trocas de emails e por toda a
sua ajuda e total disponibilidade em todos os momentos deste projeto.
Agradecer ao Professor Sérgio Lopes pela grande ajuda prestada enquanto diretor de curso
no sentido da realização desta dissertação.
Agradecer à Catarina por ser uma constante fonte de motivação, por nunca ter deixado de
me apoiar e estar presente em todas as alturas, nunca deixando de me incentivar a fazer mais
e melhor.
Agradecer aos meus colegas de trabalho da Critical Software, em especial ao meu tutor
Alexandre Esper e ao meu orientador Ricardo Batista pelos conselhos e trocas de ideias
durante toda a realização deste trabalho.
Agradecer aos meus amigos por todo o companheirismo ao longo desta dissertação.
Um agradecimento final também à Universidade do Minho por todas as condições
oferecidas durante todo o curso.
iv
v
Resumo
O crescimento da chamada Economia do Mar gera, inevitavelmente um aumento da
circulação das pessoas e bens, com impacto nas atividades relacionadas com a salvaguarda da
vida humana no mar, regulação e fiscalização das atividades marítimas e, garantia de
sustentabilidade e bom estado ambiental dos oceanos. Todas estas atividades levam a uma
necessidade cada vez maior de um adequado conhecimento situacional marítimo.
Esta dissertação está incluída no âmbito do projeto SEAGULL Ref 34063, co-financiado
pelo POFC (Programa Operacional Fatores de Competitividade), o qual tem como objetivo o
desenvolvimento de sistemas de bordo inteligentes de maneira que quando associados a
veículos aéreos não tripulados (VANT) já existentes (providenciados pela Força Aérea
Portuguesa), possam contribuir de forma muito significativa para a geração do já referido
conhecimento situacional marítimo. Estes sistemas irão suportar funcionalidades como a
deteção, identificação e seguimento de alvos (e.g. embarcações, manchas de poluentes,
náufragos, destroços, etc.), reconhecimento de padrões de comportamento e planeamento, e
ainda missões colaborativas de diversos veículos autónomos para as quais se torna imperativo
um sistema de sense and avoid.
Estes VANT, já existentes, estarão equipados com um piloto automático Piccolo fabricado
pela Cloud Cap Technology, sendo este o responsável pelo controlo dos atuadores que afetam
as manobras da aeronave e também por toda a comunicação de e para terra, conseguindo ainda
fornecer dados de telemetria do avião (altitude, velocidade, etc.).
Os módulos de deteção e identificação de objetos, target tracking e sense and avoid serão
tratados como componentes COTS (commercial off-the-shelf), pelo que o âmbito desta
dissertação é a implementação de módulos de suporte a estes subsistemas tais como:
Autopilot Comms e Autopilot Driver – Permitem a comunicação entre todos os
módulos do sistema e o Piccolo Autopilot.
Comms Relay – Assegura a fragmentação de mensagens em pacotes de dimensão
reduzida, implementando um protocolo de garantia de entrega dos mesmo. É também
responsável pela agregação dos pacotes na extremidade oposta.
Control Supervisor – Módulo que implementa uma gestão de prioridades entre o target
tracking e o sense and avoid sendo responsável pela ativação/desativação destes dois
sistemas. Pode reportar mensagens de erro em caso de falha do Seagull Manager.
vi
Seagull Manager – Módulo responsável por compor todas as mensagens com destino
a terra, tal como descodificar todos os comandos recebidos e comunicar os mesmos ao
sistema de bordo.
Frame grabbers e sensores – Vários módulos responsáveis pela operação dos sensores
e câmaras e pela comunicação de informação dos mesmos ao sistema.
Convém ainda ressalvar que um dos grandes objetivos deste sistema assenta na
comunicação e reporte de eventos para terra e o cumprimento de comandos enviados pelas
estações de terra. Assim sendo, esta dissertação detalha também uma estação de terra capaz
de monitorizar o sistema a bordo e apresentar, ao operador, dados visuais para uma melhor
avaliação da missão em curso.
vii
Abstract
The growth of the so-called Sea economy generates, inevitably, increased traffic of people
and goods with an impact on activities related to the safety of life at sea, regulation and
surveillance of maritime activities and ensuring sustainability and good environmental status
of the oceans. All these activities rely heavily on an appropriate maritime situational
awareness.
This dissertation is included in the SEAGULL project Ref 34063, co-funded by POFC
(Competitiveness Factors Operational Program), which aims to the development of intelligent
vehicle systems that associated with existing unmanned aerial vehicles (UAV) can contribute
very significantly to the generation of this maritime situational awareness. These systems will
address aspects such as detecting, identifying and tracking targets (e.g. vessels, polutant stains,
shipwrecks, debris, etc.), planning and behavioral patterns recognition and aspects related to
collaborative missions with several autonomous vehicles for which it becomes mandatory a
Sense and Avoid system.
These UAV will be equipped with an autopilot Piccolo manufactured by Cloud Cap
Technology, which is responsible for the control of actuators that affect the maneuvers of the
aircraft and also for all communication to and from earth, while providing aircraft telemetry
data (altitude, speed, etc.).
The object detection and identification, target tracking and sense and avoid systems will
be treated as COTS (commercial off-the-shelf) components so the scope of this thesis is the
implementation of support modules to these subsystems such as:
Autopilot Autopilot and Comms Driver - Enables communication between all system
modules and the Piccolo Autopilot.
Comms Relay – Ensures the fragmentation of messages in small size packets,
implementing a delivery security protocol thereof. It is also responsible for aggregating
the packets at the opposite end.
Control Supervisor – Module that implements priority management between the target
tracking and the sense and avoid, being responsible for the activation / deactivation of
these two systems. May report error messages in case of Seagull Manager failure.
Seagull Manager – Module responsible for composing all messages destined for land
as decode all incoming commands and communicate them to the onboard system.
viii
Frame grabbers e sensores – Several modules responsible for the operation of sensors
and cameras and communication of information thereof to the system.
It should also be pointed out that one of the major objectives of this system is based on
communication and reporting of events to land and compliance with commands sent by ground
stations. Therefore, this work also details a ground station capable of monitoring the system
on board and present visual data to the operator for a better assessment of the current mission.
ix
Acrónimos
A Tabela 1 apresenta a lista de acrónimos usados neste documento.
Tabela 1: Tabela de acrónimos
Acrónimo Descrição
AIS Automatic identification System
AP Autopilot
BD Base de Dados
BLOS Beyond Line of Sight
C4I Command, Control, Communications and Inteligence
CCD Charge-coupled device
COMINT Communications Intelligence
COSPAS – SARSAT Cosmicheskaya Poiska Avariynyh Sudov ou Space System for Search of Distressed Vessel - Search and Rescue Satellite Aided Tracking
COTS Commercial off-the-shelf
CS Control Supervisor
CSM Conhecimento Situacional Marítimo
DARPA Defense Advanced Research Projects Agency
DSC Digital Selective Calling
DSP Digital Signal Processor
EASA European Aviation Safety Agency
EDA European Defense Agency (Agência europeia da defesa)
ELINT Electronic Intelligence
ELT Emergency Locator Transmitter
EO Eletro-ópticas
EPIRB Emergency Position-Indicating Radio Beacon
EUROCAE Organização Europeia para Equipamento da Aviação Civil
ESM Electronic Support Measures
ETC2 Estação de terra de comando e controlo
ETP Estação de terra de payload
FAP Força Aérea Portuguesa
FEUP Faculdade de Engenharia da Universidade do Porto
FNC Future Naval Capabilities
GS Ground Control Station
x
Acrónimo Descrição
GMDSS Global Maritime Distress Safety System
GMES Global Monitoring for Environment and Security
GPGPU General Purpose Graphics Processing Unit
GPU Graphics Processing Unit
GPRS General Packet Radio Services
GPS Global Positioning System
HALE High Altitude Long Endurance
HIL Hardware In the Loop
HF High Frequency
HPC High-performance computing
HPEC High Performance Embedded Computing
IMINT Imagery Intelligence
IMO International Maritime Organization
IR Infravermelhos
ISR Intelligence, Surveillance, Reconnaissance
IT Integration Test
KPI Key Performance Indicator
LIDAR Light Detection And Ranging
LMRS Sistema de Reconhecimento de minas de longa-distância
LOS Line of Sight
LRIT Long Range Identification and Tracking
MIDCAS Midair Collision Avoidance System
MF Medium Frequency
MMSI Maritime Mobile Service Identity
MRA Mission Review and Analysis
MRCC Maritime Rescue Co-ordination Centre
MTOW Maximum Take-Off Weight
NATO North Atlantic Treaty Organization
nm Nanómetros
NAVTEX Navigational Telex
ONR Office of Naval Research
xi
Acrónimo Descrição
PLB Personal Locator Beacon
REMUS Sistema de Monitorização Ambiental Remoto
RMS Sistema de Minehunting remoto
ROI Region of Interest
RPC Remote Procedure Call
SAM Sensitive Area Monitoring
SAR Search and Rescue
SATCOM Satellite Communications
SEC2 Sistema Embarcado de Comando e Controlo
SEP Sistema Embarcado de Payload
SOLAS Safety of Life at Sea
SOTDMA Self Organized Time Division Multiple Access
SRT Search and Rescue Transponder
SW Software
S2SN Slave to Sensor Navigation
S&A Sense and Avoid
TCAS Traffic Collision Avoidance Systems
TCS Test Case Specification
TDMA Time Division Multiple Access
TT Target Tracking
TUAV Tactical Unmanned Aerial Vehicle
UAS Unmanned Aerial System
UAV Unmanned Aerial Vehicle
UHF Ultra High Frequency
UK CAA United Kingdom Civil Aviation Authority
VANT Veículo Aéreo Não Tripulado
VHF Very High Frequency
VMS Vessel Monitoring System
VSNT Veículo Subaquático Não Tripulado
VTNT Veículo Terreste Não Tripulado
xii
xiii
Índice
AGRADECIMENTOS ........................................................................................................... III
RESUMO ................................................................................................................................. V
ABSTRACT .......................................................................................................................... VII
ACRÓNIMOS ....................................................................................................................... IX
CAPÍTULO 1 ............................................................................................................................ 1
INTRODUÇÃO ........................................................................................................................ 1
ENQUADRAMENTO ....................................................................................................... 1
OBJETIVOS ...................................................................................................................... 3
1.2.1. PROPOSTA DE SISTEMA ............................................................................................ 4
1.2.2. VALOR ACRESCENTADO .......................................................................................... 6
ESTRUTURA DA DISSERTAÇÃO ................................................................................. 7
CAPÍTULO 2 ............................................................................................................................ 9
ESTADO DA ARTE ................................................................................................................ 9
2.1. ASPETOS OPERACIONAIS ............................................................................................ 9
2.1.1. SISTEMAS DE REPORTE AUTOMÁTICO DE POSICIONAMENTO DE NAVIOS
.................................................................................................................................................. 9
2.1.2. SISTEMAS DE EMISSÃO DE ALERTAS DE SOCORRO ....................................... 11
VEÍCULOS AÉREOS NÃO TRIPULADOS (VANT) ................................................... 13
2.2.1. INTEGRAÇÃO ............................................................................................................ 16
2.2.1.1. REGULAMENTAÇÃO ............................................................................................. 17
2.2.1.1.1. REQUISITOS DE SEGURANÇA ......................................................................... 17
2.2.1.1.2. A REGULAMENTAÇÃO EUROPEIA ................................................................. 18
2.2.1.2. EVOLUÇÃO DE CAPACIDADES .......................................................................... 19
2.2.1.2.1. AUTONOMIA ........................................................................................................ 20
2.2.1.2.2. PERCEPÇÃO (REMOTE SENSING) ................................................................... 22
2.2.1.2.3. MONITORIZAÇÃO E DIAGNÓSTICO ............................................................... 23
2.2.1.3. INTEGRAÇÃO COM SISTEMAS EXTERNOS ..................................................... 24
VANT PAYLOAD ............................................................................................................ 25
ESTAÇÃO DE COMANDO E CONTROLO ................................................................. 28
ESTAÇÃO DE PAYLOAD .............................................................................................. 30
COMUNICAÇÕES ......................................................................................................... 32
2.6.1. COMUNICAÇÕES LOCAIS ....................................................................................... 32
xiv
2.6.2. COMUNICAÇÕES EM LINHA DE VISTA ............................................................... 33
2.6.3. COMUNICAÇÕES PARA ALÉM DE LINHA DE VISTA........................................ 34
CAPÍTULO 3 .......................................................................................................................... 37
ANÁLISE DO SISTEMA ...................................................................................................... 37
REQUISITOS .................................................................................................................. 37
ARQUITETURA DO SISTEMA .................................................................................... 38
3.2.1. ARQUITETURA ABERTA ......................................................................................... 38
3.2.2. BAIXO NÍVEL DE ACOPLAMENTO ENTRE FUNÇÕES ...................................... 40
3.2.3. DECOMPOSIÇÃO DO SISTEMA .............................................................................. 41
3.2.3.1. VISTA FÍSICA .......................................................................................................... 41
3.2.3.2. ARQUITETURA A BORDO .................................................................................... 42
3.2.3.3. EQUIPAMENTOS DE TERRA ................................................................................ 45
3.2.4. VISÃO GERAL DO SOFTWARE ................................................................................ 45
3.2.4.1. MIDDLEWARE ROS ................................................................................................. 47
3.2.4.2. MAVLINK ................................................................................................................. 48
HARDWARE .................................................................................................................... 49
3.3.1. PICCOLO ..................................................................................................................... 49
3.3.2. PLATAFORMAS COMPUTACIONAIS .................................................................... 50
3.3.2.1. PLATAFORMA COMPUTACIONAL SEC2 .......................................................... 51
3.3.2.2. PLATAFORMA COMPUTACIONAL SEP ............................................................. 52
3.3.3. SENSORES .................................................................................................................. 52
3.3.3.1. ESPETRO VISÍVEL .................................................................................................. 53
3.3.3.2. INFRAVERMELHOS ............................................................................................... 53
3.3.3.2.1. CÂMARA JAI ........................................................................................................ 53
3.3.3.2.2. CÂMARA GOBI .................................................................................................... 55
3.3.3.3. CÂMARA HIPERESPETRAL .................................................................................. 56
3.3.3.4. SENSOR AIS ............................................................................................................. 57
3.3.3.5. ADS-B RECEIVER ................................................................................................... 58
CAPITULO 4 .......................................................................................................................... 61
DESIGN DETALHADO DO SISTEMA ................................................................................ 61
4.1. DECOMPOSIÇÃO DO SISTEMA EMBARCADO DE COMANDO E CONTROLO 61
4.1.1. MÓDULOS DE COMUNICAÇÃO ............................................................................. 62
4.1.1.1. AUTOPILOT DRIVER ............................................................................................. 63
4.1.1.1.1. FLUXO DE MENSAGENS DE TELEMETRIA DO AP ...................................... 64
xv
4.1.1.1.2. FLUXO DE MENSAGENS DE COMANDO PARA O AP .................................. 64
4.1.1.2. AUTOPILOT COMMS ............................................................................................. 65
4.1.1.2.1. FLUXO DE MENSAGENS VIA PAYLOADSTREAM DO AP ............................. 66
4.1.1.3. ADSB DRIVER ......................................................................................................... 67
4.1.1.4. COMMS RELAY ...................................................................................................... 68
4.1.1.4.1. PROTOCOLO TERRA-VANT .............................................................................. 69
4.1.1.4.1.1. FILAS E ESTRUTURAS DE CONTROLO ....................................................... 71
4.1.1.4.1.2. ENVIO DE MENSAGENS ................................................................................. 72
4.1.1.4.1.3. RECEÇÃO DE MENSAGENS ........................................................................... 75
4.1.2. MÓDULOS DE NAVEGAÇÃO .................................................................................. 76
4.1.2.1. CONTROL SUPERVISOR ......................................................................................... 76
4.1.2.2. TARGET TRACKER .................................................................................................. 78
4.1.2.3. SENSE & AVOID ..................................................................................................... 79
4.2. DECOMPOSIÇÃO DO SISTEMA EMBARCADO DE PAYLOAD ............................ 82
4.2.1. SEAGULL MANAGER .................................................................................................. 82
4.2.1.1. PLANO DE MISSÃO ................................................................................................ 84
4.2.1.2. ORDEM PARA INICIAR/TERMINAR SEGUIMENTO ........................................ 85
4.2.1.3. PEDIDO DE FOTOGRAFIA DE ALVO .................................................................. 87
4.2.1.4. NOTIFICAÇÃO DE DETEÇÃO .............................................................................. 88
4.2.1.5. ENVIO DE ATUALIZAÇÃO DO PANORAMA MARÍTIMO ............................... 90
4.2.1.6. TELEMETRIA DE PAYLOAD ................................................................................ 90
4.2.2. MÓDULOS DE AQUISIÇÃO DE SENSORES .......................................................... 91
4.2.2.1. RECETOR AIS .......................................................................................................... 91
4.2.2.2. SENSORES DE IMAGEM ....................................................................................... 92
4.2.3. MÓDULO DE DETEÇÃO ........................................................................................... 93
4.2.4. ATUADORES .............................................................................................................. 94
4.3. HEALTH MONITORING E ERROR HANDLING ........................................................... 95
4.3.1. HEARTBEAT ................................................................................................................ 95
4.3.2. ERROR HANDLING ..................................................................................................... 95
4.3.2.1. KEEP ALIVE ERROR HANDLING ........................................................................... 95
4.3.2.2. PAYLOAD ERROR HANDLING ............................................................................... 96
4.3.3. ROSLAUNCH ............................................................................................................... 96
4.4. DECOMPOSIÇÃO DA ESTAÇÃO DE TERRA DE PAYLOAD ................................. 97
4.4.1. CORE ............................................................................................................................ 98
xvi
4.4.1.1. COMMUNICATIONS .............................................................................................. 99
4.4.1.1.1. ETP-ROS INTERFACE ....................................................................................... 100
4.4.1.1.2. SISOM INTERFACE ........................................................................................... 105
4.4.1.2. DATATYPES .......................................................................................................... 105
4.4.1.3. PAYLOAD .............................................................................................................. 106
4.4.1.4. PAYLOAD MONITORING .................................................................................... 106
4.4.1.4.1. CONFIGURAÇÃO ............................................................................................... 106
4.4.1.4.2. MONITORING ..................................................................................................... 108
4.4.1.5. SUPPORT ................................................................................................................ 110
4.4.2. GUI ............................................................................................................................. 111
4.4.2.1. ACTIONS ................................................................................................................ 112
4.4.2.2. ADVISORS ............................................................................................................. 113
4.4.2.3. PERSPECTIVES ..................................................................................................... 113
4.4.2.4. VIEWS ..................................................................................................................... 113
4.4.3. DATA ......................................................................................................................... 114
CAPÍTULO 5 ........................................................................................................................ 117
IMPLEMENTAÇÃO, RESULTADOS E TESTES. ............................................................ 117
5.1. IMPLEMENTAÇÃO ..................................................................................................... 117
5.1.1. ESTRUTURA DE UM MÓDULO ROS .................................................................... 117
5.1.2. SCRIPT DE ARRANQUE AUTOMÁTICO DO SISTEMA..................................... 120
5.1.3. ESTRUTURA DE UM FICHEIRO ROSLAUNCH .................................................... 122
5.2. RESULTADOS ............................................................................................................. 123
5.3. METODOLOGIA DE TESTES .................................................................................... 126
5.3.1. NECESSIDADES DE AMBIENTE ........................................................................... 127
5.3.1.1. AMBIENTE HARDWARE-IN-THE-LOOP (HIL) ................................................ 127
CAPÍTULO 6 ........................................................................................................................ 129
CONCLUSÃO ...................................................................................................................... 129
TRABALHO FUTURO ........................................................................................................ 130
BIBLIOGRAFIA .................................................................................................................. 133
ANEXOS .............................................................................................................................. 137
ANEXO A - REQUISITOS .................................................................................................. 137
ANEXO B – INTERFACES A BORDO .............................................................................. 147
ANEXO C – INTERFACES TERRA-AR ............................................................................ 181
ANEXO D – CASOS DE TESTE E MATRIZ DE RASTREABILIDADE ........................ 201
xvii
Índice de Figuras
Figura 1: Sistema conceptual .................................................................................................... 5 Figura 2: Classificação de VANT. (Fonte: Adaptado de NATO UAS Classification Guide
September 2009 JCGUAV meeting e (CAP 722, 2010)) ....................................................... 14 Figura 3: Alcance máximo em linha de vista consoante a altitude de operação do VANT
(Austin R. , 2010) ................................................................................................................... 33 Figura 4: Vista física do sistema ............................................................................................. 41 Figura 5: Visão da pilha de software/hardware dos sistemas embarcados ............................. 42 Figura 6: Visão geral do software ........................................................................................... 46
Figura 7: Ficheiro XML MAVLink ........................................................................................ 48 Figura 8: Piccolo autopilot ...................................................................................................... 49 Figura 9: Piccolo e Piccolo Ground Station ............................................................................ 49
Figura 10: Plataforma computacional do SEC2 ..................................................................... 51 Figura 11: Plataforma computacional do SEP ........................................................................ 52
Figura 12: Sensor de espectro visível - TASE 150 ................................................................. 53 Figura 13: Câmara JAI ............................................................................................................ 54
Figura 14: Câmara Gobi ......................................................................................................... 55 Figura 15: Câmara hiperespetral ............................................................................................. 56 Figura 16: Sensor AIS ............................................................................................................. 58
Figura 17: ADS-B receiver GNS 5890 ................................................................................... 59 Figura 18: Diagrama de componentes do sistema .................................................................. 61
Figura 19: Diagrama de componentes do SEC2 ..................................................................... 62 Figura 20: Fluxo de mensagens de telemetria do AP ............................................................. 64
Figura 21: Envio de comandos para o AP .............................................................................. 65 Figura 22: Mensagens via PayloadStream .............................................................................. 66
Figura 23: Conversão de dados do sensor ADS-B ................................................................. 67 Figura 24: Tópicos envolvidos na comunicação entre extremidades ..................................... 69 Figura 25: Diagrama de envio de mensagem (Comms Relay Callback) ................................ 72
Figura 26: Diagrama de envio de mensagem (Comms Relay Loop) ...................................... 73 Figura 27: Diagrama de envio de mensagem (Comms Relay Watchdog de envio) ............... 74
Figura 28: Diagrama de receção de mensagens do CommsRelay .......................................... 75 Figura 29: Diagrama de monitorização da fila de receção ..................................................... 76 Figura 30: Visão das trocas de mensagens no SEC2 e SEP relacionadas com Navegação .... 77
Figura 31: Serviços ................................................................................................................. 78 Figura 32: Vista do sistema de seguimento de alvos .............................................................. 79
Figura 33: Diagramas de blocos para o módulo Sense&Avoid .............................................. 80 Figura 34: Diagrama de atividade do módulo Sense&Avoid ................................................. 80
Figura 35: Diagrama de componentes do SEP ....................................................................... 82 Figura 36: Visão geral das trocas de mensagens entre os módulos relacionados com o
Seagull Manager ..................................................................................................................... 83 Figura 37: Diagrama de atividade do plano de missão ........................................................... 84 Figura 38: Diagrama de atividade de ordem para (não) seguir alvo ....................................... 85
Figura 39: Interações entre componentes no seguimento de um alvo .................................... 86 Figura 40: Diagrama de atividade de pedido de uma fotografia de alvo ................................ 87
Figura 41: Diagrama de atividade de notificação de deteção de um objeto ........................... 88
xviii
Figura 42: Diagrama de sequência de deteção de um objeto .................................................. 89 Figura 43: Composição do vetor Data .................................................................................... 90 Figura 44: Diagrama de atividade do módulo AIS ................................................................. 91 Figura 45: Conversão de imagens em formato OpenCV para mensagens ROS
(RaduBogdanRusu, 2010) ....................................................................................................... 92 Figura 46: Diagrama de atividade de captura de uma imagem ............................................... 93 Figura 47: Ilustração das funcionalidades da TASE ............................................................... 94 Figura 48: Diagrama de componentes da ETP ....................................................................... 97
Figura 49: Componentes de software da ETP ........................................................................ 98 Figura 50: Modelo de classes Core ......................................................................................... 99 Figura 51: Diagrama de classes Communications .................................................................. 99 Figura 52: ETP-ROS Interface ............................................................................................. 100 Figura 53: Classe Datatypes ................................................................................................. 105
Figura 54: Diagrama de classes Payload .............................................................................. 106
Figura 55: Definição de missão ............................................................................................ 107
Figura 56: Lista de missões .................................................................................................. 107 Figura 57: Envio de execução de missão .............................................................................. 108 Figura 58: Monitorização de missão em execução ............................................................... 109 Figura 59: Monitorização de erros e eventos de payload ..................................................... 109
Figura 60: Vista de mapa – Monitorização ........................................................................... 110 Figura 61: Diagrama de classes Support ............................................................................... 110 Figura 62: Modelo de classes GUI ....................................................................................... 112
Figura 63: Exemplo de ação da GUI .................................................................................... 112 Figura 64: Perspetiva única e vistas da GUI ......................................................................... 114
Figura 65: Modelo de classes Data ....................................................................................... 115 Figura 66: Função main de um módulo ................................................................................ 117 Figura 67: Ficheiro fonte de um módulo (Implementação de métodos)............................... 119
Figura 68: Ficheiro de cabeçalho .......................................................................................... 120
Figura 69: Init script ............................................................................................................. 121 Figura 70: Ficheiro Roslaunch .............................................................................................. 122 Figura 71: Preparação para voo ............................................................................................ 123
Figura 72:Hardware VANT - Vista superior ........................................................................ 124 Figura 73: Motor e gerador do VANT .................................................................................. 125
Figura 74: Hardware VANT - Vista inferior ........................................................................ 125 Figura 75: Etapas de um teste formal ................................................................................... 126 Figura 76: Diagrama de ligações entre os diversos componentes do sistema de testes com
HIL ........................................................................................................................................ 127
Índice de Tabelas
Tabela 1: Tabela de acrónimos ................................................................................................ ix Tabela 2: Parâmetros do Protocolo terra-VANT .................................................................... 70 Tabela 3: Estrutura da mensagem ReliableMessage ............................................................... 70 Tabela 4: Estrutura de controlo de cada fragmento (Chunk) .................................................. 71 Tabela 5: Definição de missão ................................................................................................ 85 Tabela 6: Telemetria de payload ............................................................................................. 90
xix
Tabela 7: Requisitos do sistema ............................................................................................ 137 Tabela 8: Requisitos de hardware ......................................................................................... 140 Tabela 9: Requisitos de software .......................................................................................... 141 Tabela 10: Interfaces SEP (P – Publica, S – Subscreve) ...................................................... 147 Tabela 11: Serviços do SEP .................................................................................................. 149 Tabela 12: Definição da mensagem PositionReport ............................................................. 149 Tabela 13: Definição da mensagem StaticVoyage ............................................................... 150 Tabela 14: Definição da mensagem Image ........................................................................... 151
Tabela 15: Definição de estrutura visibleObjects ................................................................. 152 Tabela 16: Definição da mensagem DetectionList ............................................................... 153 Tabela 17: Definição da mensagem DetectionImage ........................................................... 153 Tabela 18: Definição da mensagem RequestImage .............................................................. 154 Tabela 19: Definição da mensagem DetectionConfig .......................................................... 155
Tabela 20: Definição da mensagem TargetLocation ............................................................ 155
Tabela 21: Definição da mensagem SeagullHeartbeat ......................................................... 156
Tabela 22: Definição da mensagem SeagullError ................................................................ 157 Tabela 23: Definição da mensagem DetectionDebug ........................................................... 157 Tabela 24: Definição da mensagem TASEAngles ............................................................... 158 Tabela 25: Definição da mensagem TASECameraCommand .............................................. 159
Tabela 26: Definição da mensagem TASECameraZoom ..................................................... 160 Tabela 27: Definição da mensagem TASECommand .......................................................... 160 Tabela 28: Definição da mensagem TASERates .................................................................. 161
Tabela 29: Definição da mensagem TASERawData ............................................................ 162 Tabela 30: Definição da mensagem TASEZero ................................................................... 163
Tabela 31: Definição da mensagem TASETelemetry .......................................................... 163 Tabela 32: Tópicos do SEC2 (P – Publica, S – Subscreve) .................................................. 164 Tabela 33: Serviços do SEC2 ............................................................................................... 167
Tabela 34: Definição da mensagem SeagullPayload ............................................................ 167
Tabela 35: Definição da mensagem CommsParameters ....................................................... 168 Tabela 36: Definição da mensagem AutopilotPayload ......................................................... 168 Tabela 37: Definição da mensagem AutopilotTelemetry ..................................................... 169
Tabela 38: Definição da mensagem AutopilotWarning ....................................................... 170 Tabela 39: Definição da mensagem AutopilotUserAction ................................................... 171
Tabela 40: Definição da mensagem AutopilotMissionLimits .............................................. 171 Tabela 41: Definição da mensagem CsStatus ....................................................................... 172 Tabela 42: Definição da mensagem BoolResponse .............................................................. 173
Tabela 43: Definição da mensagem ActionRequest ............................................................. 174 Tabela 44: Definição da mensagem ADSBOutput ............................................................... 174
Tabela 45: Definição da mensagem AutopilotCommand ..................................................... 175 Tabela 46: Definição da mensagem FilteredAutopilotCommand ........................................ 175 Tabela 47: Definição da mensagem AutopilotGimbalPayload ............................................. 176
Tabela 48: Definição da mensagem AutopilotADCSamples ............................................... 176 Tabela 49: Definição da mensagem AutopilotStatus ............................................................ 177 Tabela 50: Definição da mensagem AutopilotZeroLength ................................................... 179 Tabela 51: Mensagem MissionDefinition ............................................................................. 181
Tabela 52: Mensagem RequestImage ................................................................................... 181 Tabela 53: Mensagem FollowTarget .................................................................................... 182 Tabela 54: Mensagem DMDebug ......................................................................................... 183 Tabela 55: Mensagem PayloadTelemetry ............................................................................. 183
xx
Tabela 56: Mensagem PayloadEvent .................................................................................... 184 Tabela 57: Mensagem ImageData ........................................................................................ 185 Tabela 58: Mensagem PayloadError ..................................................................................... 187 Tabela 59: Mensagem ObjectList ......................................................................................... 188 Tabela 60: Mensagem Object ............................................................................................... 188 Tabela 61: Mensagem TargetObject ..................................................................................... 189 Tabela 62: Mensagem Heartbeat .......................................................................................... 190 Tabela 63: Resumo de Comunicações ETP .......................................................................... 191
Tabela 64: Definição de estrutura SeagullHeader ................................................................ 192 Tabela 65: Mensagem AutopilotTelemetry .......................................................................... 192 Tabela 66: Mensagem SeagullPayload ................................................................................. 194 Tabela 67: Mensagem AutopilotPayload .............................................................................. 194 Tabela 68: Mensagem AutopilotWaypoint ........................................................................... 195
Tabela 69: Mensagem AutopilotRequestWaypoints ............................................................ 197
Tabela 70: Mensagem AutopilotWPList .............................................................................. 197
Tabela 71: Mensagem AutopilotStatus ................................................................................. 198 Tabela 72: Mensagem AutopilotTrack ................................................................................. 198 Tabela 73: TCS-SW-IT-0010 ............................................................................................... 201 Tabela 74: TCS-SW-IT-0020 ............................................................................................... 201
Tabela 75: TCS-SW-IT-0030 ............................................................................................... 202 Tabela 76: TCS-SW-IT-0040 ............................................................................................... 203 Tabela 77: TCS-SW-IT-0050 ............................................................................................... 205
Tabela 78: TCS-SW-IT-0060 ............................................................................................... 205 Tabela 79: TCS-SW-IT-0070 ............................................................................................... 206
Tabela 80: TCS-SW-IT-0080 ............................................................................................... 207 Tabela 81: TCS-SW-IT-0090 ............................................................................................... 207 Tabela 82: TCS-SW-IT-0100 ............................................................................................... 208
Tabela 83: TCS-SW-IT-0110 ............................................................................................... 208
Tabela 84: TCS-SW-IT-0120 ............................................................................................... 209 Tabela 85: TCS-SW-IT-0130 ............................................................................................... 209 Tabela 86: TCS-SW-IT-0140 ............................................................................................... 210
Tabela 87: TCS-SW-IT-0150 ............................................................................................... 210 Tabela 88: TCS-SW-IT-0160 ............................................................................................... 211
Tabela 89: TCS-SW-IT-0170 ............................................................................................... 212 Tabela 90: TCS-SW-IT-0180 ............................................................................................... 212 Tabela 91: TCS-SW-IT-0190 ............................................................................................... 216
Tabela 92: Relatório de resultados de teste .......................................................................... 217 Tabela 93: Matriz de rastreabilidade .................................................................................... 219
1
Capítulo 1
Introdução
A comunidade marítima internacional vem assistindo, ao longo da última década, ao
aparecimento de novas tecnologias associadas a sistemas de reporte automático de
posicionamento de navios e à evolução de sistemas tecnológicos utilizados para emissão de
alertas de socorro. Importa referir também que a partir do marco da história que foram os
ataques terroristas do 11 de Setembro de 2001, a comunidade marítima internacional foi
compelida a refletir sobre o desenvolvimentos de soluções inovadoras que pudessem
diretamente contribuir para a proteção dos navios, na medida em que 90 por cento das trocas
comerciais, a nível mundial, são feitas por via marítima, representando um peso significativo
na economia global (International Maritime Organization, 2013a). A evolução e regulação
destes sistemas têm sido acompanhadas pela agência das Nações Unidas responsável pelos
assuntos de segurança, proteção e poluição marinha - a Organização Marítima Internacional
(International Maritime Organization, IMO).
Todo este crescimento da chamada Economia do Mar gera, inevitavelmente um aumento
da circulação das pessoas e bens, com impacto nas atividades relacionadas com a salvaguarda
da vida humana no mar. Esta pressão irá sentir-se também ao nível da necessidade de garantia
de uma adequada regulação e fiscalização das atividades no mar, bem como ao nível da
garantia da sustentabilidade e do bom estado ambiental dos oceanos. Todas estas atividades
dependem fortemente de um adequado conhecimento situacional marítimo.
Enquadramento
Esta dissertação enquadra-se na área de fiscalização marítima, monitorização ambiental e
salvaguarda da vida humana no mar.
A perceção do panorama marítimo é, hoje em dia, baseada tipicamente em radares
costeiros, sistemas de posicionamento de embarcações, sistemas de alerta, deteção remota e
em sensores instalados em meios de sub-superfície, superfície e aéreos tripulados. No entanto,
existe ainda um enorme défice no que diz respeito à capacidade de observação, em particular
2
em zonas mais afastadas da costa, sendo fundamental incrementar a cobertura, resolução
temporal e resolução espacial dos mecanismos de observação. Por outro lado, o empenho de
meios tripulados implica custos elevados, quer na aquisição dos mesmos quer na sua operação.
Neste cenário a utilização de veículos autónomos não tripulados, em particular os aéreos,
aparece como uma alternativa muito promissora, até mesmo incontornável.
Para nos dar alguma perceção da importância que os veículos aéreos não tripulados
(VANT) estão a assumir, estes veículos, outrora considerados uma obra de ficção científica,
são utilizados por uma das maiores forças militares do mundo que é o exército dos Estados
Unidos da América, numa enorme variedade de atividades, tais como vigilância em tempo
real, missões de salvamento em situações críticas de combate e assistência na detenção de
suspeitos de terrorismo. Além disso, veículos aéreos não tripulados estão agora a ser utilizados
para executar operações tipicamente reservadas a aviões tripulados, tais como ataques aéreos
com mísseis a alvos de alto perfil (Lieutenant General Walter E. Buchanan III, Mar. 17, 2004).
No total, é estimado que os EUA tenham mais de 7000 VANT em operação. Outros países
estão nesta “corrida” – cerca de cinquenta países compraram ou construíram veículos aéreos
não tripulados, de acordo com peritos na área da defesa (Shane, October 8, 2011). Estimativas
apontam para que a industria dos VANT, abrangendo um vasto leque desde o ramo militar,
vigilância e sector comercial, atinja um investimento total de 94 mil milhões de dólares nos
próximos 10 anos (Duhigg, April 15, 2007) e (Shane, October 8, 2011). Graças à sua
resistência, custo e flexibilidade, os VANT estão claramente a marcar a diferença nas
operações de defesa e reconhecimento (Duhigg, April 15, 2007). A recomendação do
pentágono para a redução na produção de aviões tripulados F-22 e F-35, a par do aumento na
aquisição de veículos aéreos não tripulados é apenas um dos sinais deste desenvolvimento
(Auslin, February 24, 2011). Adicionalmente a marinha americana pretende expandir
dramaticamente o número de veículos não tripulados para a realização não só de missões
aéreas mas também de missões subaquáticas tais como encontrar minas, detetar navios
inimigos e providenciar defesa para portos – missões atualmente conduzidas por veículos
tripulados. Assim podemos ver que a aposta em veículos não tripulados não se limita a meios
aéreos, estando em rápida expansão.
3
Objetivos
Esta dissertação está incluída no âmbito de um projeto chamado SEAGULL, o qual tem
como objetivo o desenvolvimento de soluções eficientes para abordar os desafios da gestão de
conhecimento situacional marítimo, indispensável em operações marítimas relacionadas com
salvaguarda da vida humana, segurança e ambiente, fazendo uso de tecnologia existente em
termos de veículos aéreos não tripulados. Um dos contributos será o desenvolvimento de
sistemas de bordo inteligentes que possam ser acoplados a este tipo de veículos facultando,
assim, um acréscimo de conhecimento situacional marítimo, o que permite um maior suporte
a todas as atividades do mar. Estes sistemas inteligentes deverão dotar os VANT de
capacidades tais como:
Deteção, identificação e seguimento de alvos (e.g. embarcações, manchas de
poluentes, náufragos, destroços, etc.);
Reconhecimento de padrões de comportamento e planeamento;
Missões colaborativas com outros veículos autónomos;
Tendo em conta as propriedades anteriormente referidas, mais especificamente a
capacidade de execução de missões colaborativas entre veículos, é perceptível a necessidade
de um sistema de sense and avoid para que estas missões possam ser levadas a cabo sem o
risco de colisão entre os veículos envolvidos.
Considerando o acima descrito, é facilmente perceptível que existem três módulos que
resultam dos objetivos do projeto SEAGULL, sendo eles o módulo de deteção, target tracking
e sense and avoid. Assim sendo, os objetivos desta dissertação são:
Garantir a comunicação bidirecional entre o VANT e a terra;
Implementar módulo para garantia de entrega e fragmentação/agregação de mensagens
em pacotes;
Implementar módulo de controlo de prioridade sobre os módulos de target tracking e
sense and avoid;
Implementar estação de terra de payload;
A garantia de comunicação será providenciada através da implementação de novos
módulos que permitam, em primeiro lugar, o direcionamento de toda a informação dos
sistemas de bordo para o AP do VANT, o qual garante a comunicação com a estação de terra.
Devido à baixa largura de banda fornecida pelo protocolo de comunicação do autopilot existe
também a necessidade de um módulo que proceda à fragmentação/agregação de mensagens
4
enviadas de e para o AP, assegurando ao mesmo tempo a garantia de entrega (acknowledge)
de todas as mensagens trocadas pois o Piccolo não fornece este tipo de funcionalidade. Toda
esta comunicação será bidirecional pelo que a implementação será a mesma a bordo e na
estação de terra.
Focando-nos mais concretamente nos sistemas de sense and avoid e target tracking é do
intuito desta dissertação a implementação de um módulo para controlo e supervisão do TT e
S&A. Estes dois módulos permitem o seguimento automático de alvos e a execução de
manobras de evasão de colisões pelo que ambos necessitam de manobrar a aeronave de acordo
com o algoritmo implementado. Este tipo de navegação autónoma exige a criação de políticas
de segurança que possam a qualquer momento devolver o controlo do VANT ao operador e
garantam o correto controlo de prioridades entre o sistema de sense and avoid e o sistema de
target tracking pois evitar uma colisão será sempre mais importante do que continuar a seguir
um alvo.
A comunicação e reporte de eventos para terra e o cumprimento, por parte do sistema de
bordo, de comandos enviados pelas estações de terra são também um dos grandes objetivos
deste sistema. Deste modo, será do âmbito desta dissertação a implementação de uma estação
de terra capaz de monitorizar os sistemas a bordo e facultar ao operador dados visuais que
permitam uma melhor avaliação da missão em curso. Esta estação de terra será também
importante na obtenção de resultados práticos da implementação feita a bordo visto que será
possível visualizar, através de uma interface gráfica, dados provenientes do VANT
confirmando o correcto funcionamento do sistema.
1.2.1. Proposta de sistema
Tendo em conta os objetivos do projeto SEAGULL, no qual se insere esta dissertação, será
do âmbito da mesma apresentar um sistema de suporte aos módulos de deteção e identificação
de objetos, target tracking e Sense and Avoid de forma que estes possam comunicar e permutar
entre si (e.g. em caso de perigo de colisão o sistema de Sense and Avoid deve ter prioridade
sobre o sistema de seguimento de alvos). Neste sentido a Figura 1 dá-nos uma primeira
amostra do sistema conceptual que será desenvolvido.
5
Figura 1: Sistema conceptual
Tal como pode ser visto, além dos componentes de deteção, sense and avoid e target
tracking, existem componentes que permitem o controlo da informação e estados de ativação
dos primeiros. Os módulos encontram-se agrupados em dois grandes grupos, SEP – Sistema
embarcado de payload e SEC2 – Sistema embarcado de comando e controlo, que serão
explicados mais pormenorizadamente no capítulo 4 e têm as seguintes funções:
Comms Relay – Módulo responsável pela fragmentação dos dados em pacotes antes
de seguirem para o Autopilot e respetiva reconstrução dos mesmos quando chegam
vindos do Autopilot. É também este módulo que implementa a capacidade de envio de
mensagens com garantia de entrega.
Control Supervisor – Este módulo receberá pedidos do Seagull Manager para ativação
do sistema de seguimento de alvos (quando o sistema TT é ativo diz-se que o VANT
está a operar em modo slave to sensor navigation – S2SN) e pedidos do sense and
avoid (S&A) para poder executar manobras de evasão. Tanto o TT como o S&A
enviarão comandos de voo que serão filtrados pelo Control Supervisor antes de serem
6
passados ao sistema de Autopilot. Será este módulo que atribuirá prioridades de
navegação para que manobras de evasão de colisões sejam sempre mais prioritárias
que manobras de seguimento de alvos.
Seagull Manager – Todas as mensagens em terra e a bordo, antes de serem enviadas
para a outra extremidade, são encapsuladas em formato MAVlink (Micro Air Vehicle
Communication Protocol), uma biblioteca header-only bastante leve utilizada para o
empacotamento de estruturas C em canais série. Este componente fará a
(des)codificação, utilizando este protocolo, de todas as mensagens trocadas entre o
VANT e a terra. Mensagens empacotadas seguirão para o Comms Relay enquanto a
informação das mensagens recebidas e desempacotadas será reencaminhada para os
módulos aos quais se destina. Resumidamente funcionará como um gestor de dados a
bordo, controlando o fluxo da informação, principalmente no SEP.
Tal como as plataformas computacionais SEP e SEC2, todos estes componentes serão
descritos com mais detalhe no capítulo 4.
1.2.2. Valor acrescentado
Com a execução do projeto SEAGULL objetiva-se um aumento das capacidades existentes
em VANT atuais, nos seguintes campos:
Deteção e evasão de colisões;
Seguimento automático de alvos definidos por terra como sendo de interesse;
Utilização de câmaras hiperespectrais;
Automatização dos processos de gestão de payload (sendo payload o equipamento
necessário para a realizar uma dada missão);
Esta dissertação, inserida no contexto do projeto SEAGULL, interage com os três
primeiros pontos mencionados na medida em que providencia a capacidade de gestão dos
processos necessários à execução dos mesmos e permite a execução do quarto ponto criando
um sistema autónomo em termos de gestão de payload e sensores permitindo a definição de
uma missão e mesmo a redefinição durante o voo, mantendo o operador atualizado em relação
ao panorama marítimo.
7
Estrutura da dissertação
O primeiro capítulo é composto pela introdução ao estado do panorama marítimo atual,
sendo também feito o enquadramento desta dissertação e explicado o valor acrescentado que
vêm trazer os veículos aéreos não tripulados no contexto de vigilância, fiscalização e
salvaguarda da vida humana no mar. São também mencionados os objetivos desta dissertação.
O segundo capítulo é composto pelo estado da arte. Nesta fase são apresentados os
resultados dos estudos relativamente aos aspetos operacionais, incluindo sistemas de reporte
automático de posicionamento de navios e sistemas tecnológicos utilizados para emissão de
alertas de socorro. São também apresentados dados relativamente ao tipo de VANT e a sua
classificação segundo os parâmetros da Força Aérea Portuguesa (FAP), dados sobre os vários
componentes de payload a bordo do VANT, dados sobre a estação de terra de comando e
controlo (ETC2) e dados sobre a estação de terra de payload (ETP). Será ainda discutido neste
capítulo a capacidade de comunicações do VANT e as propriedades do mesmo no contexto de
regulamentação, integração de novas capacidades e integração com sistemas externos.
O terceiro capítulo será dedicado à especificação dos requisitos, arquitetura, e hardware
utilizado neste projeto. São detalhadas as capacidades esperadas do sistema sendo
complementadas por informação em anexo. Nesta fase serão também apresentadas a visão
geral da arquitetura e a sua decomposição em termos da vista física do sistema e visão geral
do software. Componentes de terra e outros que não são totalmente do âmbito desta dissertação
serão abordados em pouco detalhe, apenas com o intuito de fornecerem uma melhor
contextualização. Este procedimento será transversal a todos os outros capítulos para que seja
possível manter o foco nos aspetos principais inerentes a esta dissertação mas mantendo uma
visão geral do sistema como um todo (em terra e a bordo).
No quarto capítulo é apresentado o design detalhado de todo o sistema de bordo e da
estação de terra de payload. Relativamente ao sistema de bordo, está dividido em duas
unidades de processamento e neste capítulo são especificados os módulos pertencentes a cada
uma delas e a sua função. São ainda explicitados os mecanismos de gestão de erros e
monitorização do estado de funcionamento do sistema a bordo. A estação de terra de payload
é um dos objetivos desta dissertação pelo que será detalhada neste capítulo onde são
demonstradas algumas das suas capacidades mais importantes no contexto de definição de
missão, reporting, requerimento de imagens, etc. Todos os interfaces de comunicação entre
unidades de processamento e entre os subsistemas são também aqui referenciados.
8
No quinto capítulo são expostos a implementação, os seus resultados e os testes. Tendo
em conta todo o detalhe do capítulo anterior serão apenas abordados alguns tópicos
importantes para a implementação e resultados da mesma. São também apresentados os testes
nesta secção, mais propriamente a metodologia adotada e as necessidades de ambiente para a
realização dos mesmos, sendo a sua especificação e resultados especificados nos anexos num
formato de testes orientados a requisitos.
O sexto capítulo é composto pela conclusão do trabalho efetuado bem como
melhoramentos que possam ser implementados no futuro em relação a este trabalho.
Por fim, o sétimo capítulo é constituido pela bibliografia utilizada nesta dissertação
seguindo-se uma secção para os anexos.
9
Capítulo 2
Estado da Arte
Após uma introdução ao projeto e aos seus objetivos, iremos agora focar-nos no estado da
arte, não só dos VANT mas também dos componentes que os constituem, que com eles
interagem, o meios pelos quais efetuam essa interação e a integração destes veículos no espaço
aéreo e em novas áreas de atividade.
2.1. Aspetos Operacionais
2.1.1. Sistemas de reporte automático de posicionamento
de navios
O Long Range Identification and Tracking (LRIT) tem como principal objetivo
disponibilizar informação, a nível global, relativa à identificação e ao seguimento automáticos
de navios (International Maritime Organization, 2013b). O LRIT é aplicável a todos os navios
com mais de 300 toneladas, navios de passageiros e plataformas offshore, sendo obrigatório
para navios que naveguem em áreas afastadas de costa, por norma para além das 40 milhas
náuticas, desde que o Estado de bandeira do navio tenha ratificado a convenção SOLAS
(Safety of Life at Sea). O sistema, tal como está concebido, estabelece que cada Estado costeiro
deve garantir que os seus navios devem, no mínimo, reportar quatro posições por dia (i.e. um
reporte a cada 6 horas). No entanto, a frequência de reporte pode ser alterada até um intervalo
máximo de 15 minutos. A título de exemplo, foi estabelecida internacionalmente uma área
especial, a Sensitive Area Monitoring (SAM) na região do Golfo de Áden, onde as forças
navais NATO e da União Europeia dispõem das posições dos navios a uma taxa de atualização
de 15 minutos, de forma a poderem acompanhar a navegação mercante naquela região do
globo. As mensagens LRIT são recebidas através de telecomunicações satélite, utilizando os
links de satélite Iridium e Inmarsat (Inmarsat C e Inmarsat D+). A informação LRIT,
transmitida por cada navio, corresponde aos números de identificação IMO e Maritime Mobile
Service Identity (MMSI), data, hora e posição geográfica.
O sistema LRIT pressupõe que cada navio só transmite a sua informação para o centro de
controlo de informação LRIT nacional que por sua vez, através de mecanismos regionais e
10
internacionais previamente definidos pela IMO, pode partilhar com outros centros. Esta
arquitetura de funcionamento torna o LRIT um sistema fechado, somente acessível aos centros
de controlo de informação do Estado de bandeira, do Estado costeiro onde navega o navio em
questão e, dos centros de coordenação de busca e salvamento marítimo, os Maritime Rescue
Co-ordination Centre (MRCC).
Outro tipo de sistema existente para detecção de navios por satélite, é o Vessel Monitoring
System (VMS), que utiliza o link Inmarsat (C), podendo utilizar também o link Iridium. O tipo
de informação fornecida por este equipamento, é em tudo semelhante à informação
disponibilizada pelo LRIT, no entanto, estes equipamentos são por norma utilizados a bordo
de embarcações de pesca para efeitos da monitorização contínua da atividade da pesca. Por
razões de proteção desta atividade comercial, a monitorização de todas as embarcações
nacionais e de bandeira comunitária, que naveguem dentro da zona económica exclusiva, é
assegurada por centros de controlo e vigilância da pesca. Por este facto, o acesso à informação
VMS ao público em geral está vedado, podendo somente aceder a esta informação as
organizações com responsabilidades na coordenação de ações de busca e salvamento marítimo
e os departamentos do Estado com responsabilidades em matéria de fiscalização da pesca.
Dada a arquitetura (de deteção satélite) complexa, em que estão edificados quer o sistema
LRIT, quer o sistema VMS, não é expectável que veículos aéreos não tripulados (VANT)
possam ter a capacidade de deteção do sinal deste tipo de equipamento de reporte automático
de posicionamento.
Por último, e apesar de ser um sistema cuja arquitetura de funcionamento é mais
conhecida, importa sumariamente descrever o Automatic identification System (AIS)
(International Maritime Organization, 2013c), criado com o propósito de contribuir para o
incremento da segurança da navegação. Este sistema de reporte de posicionamento fornece de
forma automatizada, a outros navios e a estações costeiras, informação própria do navio,
relativa às características (dimensões) e identificação (e.g. nome, numero IMO, MMSI), dados
de viagem (último porto praticado e próximo porto previsto), rumo e velocidade. A utilização
do AIS passou a ser obrigatória a partir de 31 de Dezembro de 2004 a bordo de todos os navios
a partir das 300 toneladas, ou a partir de 500 toneladas mas que não pratiquem viagens
internacionais, e para qualquer navio de passageiros. No entanto, verifica-se um incremento
da utilização destes equipamentos a bordo de pequenas embarcações de recreio (e.g. veleiros,
iates) e de pesca, neste último caso em resultado de diretivas comunitárias que obrigam este
tipo de embarcações a utilizarem um equipamento AIS para além do VMS.
11
Os equipamentos AIS são por norma equipamentos de relativas pequenas dimensões, de
baixo custo e que por isso são facilmente adquiridos no mercado pelo público em geral,
podendo sem dificuldade ser instalados a bordo de um navio ou embarcação, ou em terra. Os
dados AIS de navios podem inclusive ser encontrados em sítios na Internet, que partilham sem
custos adicionais e para qualquer utilizador, aquela informação. No entanto, esta facilidade de
aquisição e manuseamento dos equipamentos AIS, permite que os seus dados possam
facilmente ser adulterados por qualquer indivíduo, contrariando os princípios subjacentes à
segurança da navegação, fim primário para que foi desenvolvido.
Assim, um recetor AIS é um tipo de equipamento que, se for incluído num payload de um
VANT, poderá servir como um importante sensor de recolha e cruzamento de informação AIS
de navios em zonas afastadas de costa, onde o alcance normal das antenas AIS montadas em
terra não atingem, atento no entanto aos constrangimentos expostos no parágrafo anterior.
2.1.2. Sistemas de emissão de alertas de socorro
Antes de descrever os sistemas tecnológicos utilizados para emissão de alertas de socorro,
importa referir sumariamente o que é o Sistema Mundial de Socorro e Segurança Marítima,
vulgarmente conhecido pelo seu acrónimo GMDSS, Global Maritime Distress Safety System
(Monteiro, 2009). O GMDSS é um sistema global rádio, estabelecido a partir de 1993 com o
objetivo de melhorar a segurança marítima e, em particular, otimizar as operações de busca e
salvamento marítimo (United Kingdom Hydrographic Office, 2012/2013).
Em termos genéricos, o GMDSS estabelece a arquitetura de comunicações baseado numa
combinação de serviços de comunicações proporcionados por satélites e por estações
terrestres, fazendo utilização simultânea de sistemas automáticos (e.g. as balizas Emergency
Position-Indicating Radio Beacon (EPIRB), em situações de emergência, tem capacidade para
enviar automaticamente mensagens de socorro, sem qualquer intervenção do operador). O
GMDSS aplica-se aos navios com mais de 300 toneladas, a todos os navios de passageiros que
efetuem viagens internacionais e a navios de passageiros com mais de 100 toneladas que
efetuem apenas viagens domésticas. O GMDSS integra no sistema alguns subsistemas, como
sejam:
• O sistema Cosmicheskaya Poiska Avariynyh Sudov ou Space System for Search of
Distressed Vessel - Search and Rescue Satellite Aided Tracking (COSPAS-SARSAT);
12
• As balizas Emergency Position-Indicating Radio Beacon (EPIRB), as Emergency
Locator Transmitter (ELT) e as Personal Locator Beacon (PLB);
• As balizas Search and Rescue Transponder (SART);
• O serviço NAVTEX;
• O serviço INMARSAT de comunicações por satélite;
• A chamada Digital Selective Calling (DSC)
• A SafetyNet.
As EPIRB são balizas montadas no exterior dos navios e podem ser ativadas manual ou
automaticamente, transmitindo um sinal de socorro que é detetado pelos satélites do sistema
COSPAS-SARSAT e retransmitido aos centros de coordenação de busca e salvamento
marítimo de todo o mundo, de forma a desencadear uma ação de busca e salvamento (Search
and Rescue, SAR). O princípio de funcionamento das ELT e PLB é idêntico ao das EPIRB,
no entanto as ELT são utilizadas em aeronaves e as PLB são utilizadas por pessoas para
sinalizar uma emergência (e.g. escaladas). O sinal de socorro deste tipo de equipamentos é
transmitido na frequência de 406 Mhz, com cobertura global contínua, e emprega tecnologia
que permite exatidão de cerca de 5 km, sem integração com um recetor GPS. No caso de
integrar um GPS pode ser obtida uma exatidão na posição até 100 metros.
As SART são balizas destinadas a ser transportadas nas balsas salva-vidas e a responder
às emissões radar de outros navios, fazendo aparecer no display dos navios, a menos de 10
milhas, um sinal constituído por vários pontos no azimute da balsa, facilitando a sua
localização. À medida que o navio se aproxima da balsa salva-vidas, os pontos produzidos
pela baliza SART tomam a forma de pequenos arcos, e quando o navio está a menos de 1
milha, o seu display mostra várias circunferências concêntricas, cortadas por uma linha no
azimute da balsa equipada com SART
O NAVTEX é um sistema de radiodifusão automática da informação de segurança
marítima, que permite receber, a bordo dos navios, os avisos à navegação costeiros, a
informação SAR e os avisos meteorológicos numa rádio-teleimpressora ou em sistemas
digitais.
O INMARSAT é um serviço comercial de comunicações por satélite que utiliza satélites
geoestacionários, que asseguram a cobertura de toda a faixa do globo terrestre compreendida
entre aproximadamente 75º N e 75º S.
O DSC é um mecanismo de chamada automática, destinado a iniciar comunicações navio-
navio, terra-navio e navio-terra. O DSC pode ser usado em equipamentos das várias gamas de
13
frequências (nomeadamente VHF (Very High Frequency), MF (Medium Frequency) e HF
(High Frequency)), dispensando os operadores de rádio. A utilização do DSC permite
chamadas seletivas dentro de uma rede, acesso automático a todos os navios e estações
costeiras e transmissão digital de mensagens pré-formatadas (por exemplo: mensagens de
socorro), entre outras facilidades mais específicas e avançadas.
A SafetyNet é um serviço de transmissão de informação de segurança marítima e
meteorológica, a partir dos satélites INMARSAT. Os satélites transmitem informação
semelhante à do serviço NAVTEX, ou seja avisos à navegação, avisos de temporal, avisos
diversos sobre o funcionamento dos sistemas de radionavegação, relatos de gelo da Ice Patrol,
etc.
Embora se anteveja que os VANT não integrem equipamentos do sistema GMDSS,
poderão desempenhar um papel decisivo em operações de busca e salvamento, porquanto são
capazes de ser empenhados na execução de planos de busca na vizinhança da posição onde foi
reportado um alerta de socorro através dos sistemas GMDSS anteriormente descritos. Em
termos de boas práticas, são os centros de coordenação de busca e salvamento marítimo as
entidades que centralizam a receção e análise deste tipo de alertas, cuja posição deverão a
posteriori passar para a estação de controlo responsável por operar o VANT.
É assim esperado que, em termos de conceito de operação dos VANT, possam ser
empregues em complementaridade com as aeronaves de asa fixa ou helicópteros de busca e
salvamento marítimo, segundo o racional de serem meios versáteis e pouco onerosos quando
comparados com os custos inerentes à operação de aeronaves tradicionais.
Veículos Aéreos Não Tripulados (VANT)
Apesar do amplo leque de classificações existentes relativamente a Veículos Aéreos Não
Tripulados (VANT) importa apresentar aquela que é utilizada pela Força Aérea Portuguesa
(FAP). Deste modo, a FAP, optou por uma classificação que tomasse em conta dois aspetos.
Primeiro, a adoção da classificação, quanto ao emprego militar de UAS (Unmanned Aerial
Systems), proposta pela NATO, designada por classificação por classes, a qual se baseia,
principalmente, na massa máxima à descolagem (Maximum Take-Off Weight - MTOW) do
VANT, bem como na altitude a que o mesmo visa operar. Em segundo lugar a classificação
por grupos proposta pela United Kingdom Civil Aviation Authority (UK CAA) (CAP 722,
14
2010) relativamente à qual está subjacente, não só a massa máxima à descolagem, mas também
a regulamentação a que o VANT deverá estar sujeito de modo a poder integrar espaço aéreo
não segregado.
Desta forma, e tendo em conta os dois aspetos anteriores, a tabela representada na Figura
2 ilustra a classificação a ser adotada no âmbito deste projeto.
A Força Aérea Portuguesa tem efetivamente vindo a apostar na Classe I, nomeadamente
nas subcategorias Mini e Small. Este tipo de plataforma, apesar das restrições em alcance e
autonomia, quando comparada com outras de maiores dimensões, e operação essencialmente
em line of sight (LOS), tem grande aplicabilidade numa vasta gama de missões, quer militares,
quer civis. Isto deve-se principalmente à sua portabilidade, menor custo, operação mais
simples e capacidade de transportar um conjunto de sensores bastante versátil, como câmaras
eletro-ópticas e de infravermelhos (EO/IR), com transmissão em tempo real. Prova disto é o
grande desenvolvimento a nível mundial de VANT desta classe e a sua aplicação com sucesso
nas mais variadas missões, apesar de essencialmente militares. Dois exemplos de VANT desta
categoria, que se destacam não só pelo elevado número de horas voadas, mas também pela
experiência adquirida quanto ao seu emprego em teatros operacionais, são o Scan Eagle
(Mortimer, 2011) e o Shadow RQ-7 (Military Factory, 2014):
- Scan Eagle: trata-se de um VANT da Classe I Mini com MTOW de 20 kg, envergadura
de cerca de 3 m, desenvolvido e construído pela Boeing e grupo Insitu para missões de
inteligência, vigilância e reconhecimento (ISR), incluindo para isso um payload base
contemplando uma câmara EO/IR. Esta plataforma tem ainda uma estrutura em materiais
Figura 2: Classificação de VANT. (Fonte: Adaptado de NATO UAS Classification Guide September 2009 JCGUAV
meeting e (CAP 722, 2010))
15
compósitos e é propulsionado por um motor alternativo, conseguindo uma autonomia de voo
superior a 15 horas, não necessitando de pista para operar. No que respeita a utilizações
operacionais, destacam-se a participação na guerra do Iraque, ao serviço dos US Marine
Corps, e missões no Golfo Pérsico para a segurança de plataformas petrolíferas (ScanEagle
Unmanned Aerial Vehicle, 2013).
- Shadow RQ-7A: trata-se de um VANT maior – tem 4 m de envergadura e MTOW de 149
kg (Classe I Small). Foi desenvolvido pela AAI Corporation para missões de apoio a forças
terrestres, como vigilância, reconhecimento, aquisição de alvos e avaliação de danos de
batalha, e tem sido utilizado pelo exército dos Estados Unidos, Marine Corps, exército
Australiano e exército Sueco. Este VANT de descolagem por catapulta, é construído
integralmente em materiais compósitos e propulsionado por um motor de combustão interna
rotativo, conseguindo uma autonomia de voo entre 4 a 5 horas e meia. O payload primário
consiste em sensores EO/IR, mas é ajustável ao tipo de missão. Em 2004 sofreu uma evolução
que acabou por trazê-lo para a Classe II (MTOW de 170 kg) – Shadow RQ-7B (Shadow 200
RQ-7 Tactical Unmanned Aircraft System, 2013).
O tipo de missões que tem atraído a FAP (vigilância e reconhecimento), bem como outras
entidades envolvidas nesta área para o uso de VANT como demonstradores de conceitos de
operação e de tecnologia, focam-se essencialmente na utilização de veículos de Classe I
Mini/Small, daí que a aposta tenha sido, pelo menos por agora e a curto prazo, nesta classe
específica. Exemplos disso são os dois tipos de VANT atualmente a serem operados com
maior frequência na FAP: a série Alfa e Extended, ambos produzidos pela própria FAP.
A série Alfa caracteriza-se por uma envergadura de 2,4 m, MTOW de 16 kg, velocidade
de cruzeiro a rondar os 40 nós e autonomia de voo máxima de 4 horas. Os seus sistemas de
base para operar consistem numa câmara eletro-óptica, fixa ou articulada, piloto automático
Piccolo da Cloud Cap Technology e computador de bordo PC104. O espaço e peso livres são
destinados ao payload específico de cada missão.
Face à necessidade de se ter uma plataforma com maior autonomia de voo e capacidade
de payload surge a série Extended como evolução da série anterior. Por tal, trata-se de uma
plataforma com design semelhante ao da série Alfa, apresentando contudo uma fuselagem
mais alongada e uma asa aerodinamicamente mais eficiente. As alterações introduzidas nesta
plataforma permitiram ter uma aeronave com características melhoradas: MTOW de 26 kg,
velocidade de cruzeiro de 52 nós e autonomia de voo máxima superior a 14 horas.
16
O controlo das plataformas é feito através de uma estação de terra, que comunica com o
piloto automático. As comunicações LOS são garantidas até 40 km em terra, não sendo
limitativas, até porque a transferência de controlo entre estações de terra permite estender este
limite. No entanto, as plataformas estão preparadas para fazer comunicações beyond line of
sight (BLOS) recorrendo-se a satélites.
2.2.1. Integração
No que diz respeito ao estado da arte dos VANT, quando consideramos o tema integração,
haverá 3 dimensões diferentes desse conceito que importa considerar:
A integração do VANT enquanto veículo que tem de coexistir no mesmo espaço com
outros veículos aéreos diferentes, surgindo a necessidade de considerar a
regulamentação e a conformidade.
A evolução da arquitetura interna dos VANT de forma a disponibilizar mais e melhores
serviços para cumprimento de missões cada vez mais ricas.
A integração destes novos veículos com diversas atividades enriquecendo-as com a
sua versatilidade e capacidades particulares.
Conforme descrito por Valavanis (Valavanis, 2007), grandes projetos de I&D,
patrocinados principalmente pelo setor militar, contribuíram no passado para o
desenvolvimento e implantação de VANT, VSNT (Veículos subaquáticos não tripulados) e
VTNT (veículos terrestres não tripulados), com novos projetos e tecnologias nesta área. Este
tipo de tecnologias continuam hoje a surgir a um ritmo crescente com forte contributo da
sociedade civil, para aplicações civis e comerciais. Continua no entanto a ser necessário o
aparecimento tanto de novos conceitos como de novas tecnologias, sendo que estes são
necessários para uma utilização mais generalizada destes ativos críticos, não só para fins
militares, como também para fins civis e comerciais com diversas aplicações em espera, tais
como a segurança interna, operações de salvamento, deteção de incêndios florestais, entrega
de mercadorias, para citar apenas algumas. Os desenvolvimentos nas áreas de novas
plataformas, sistemas multi-VANT, maior autonomia, confiabilidade, controlo a partir do
solo, sensores e acessibilidade são considerados fatores decisivos aguardando tecnologias-
chave.
17
2.2.1.1. Regulamentação
Em relação ao primeiro tipo de integração falamos essencialmente de regulamentação.
Atualmente existem projetos em execução cujo principal objetivo é testar a forma como
diferentes parceiros podem cooperar e trocar informações, juntamente com know-how, de
forma a alcançarem o mesmo objetivo: o de vigilância marítima para a segurança de pessoas
e propriedade.
O objetivo global de integração de sistemas de vigilância a nível da UE é o de melhorar a
eficácia das autoridades responsáveis pelas atividades marítimas, disponibilizando cada vez
mais ferramentas e cada vez mais informação, ambas necessárias para o desempenho das
diversas missões. Consequentemente esperam-se operações mais eficientes, com custos
operacionais mais reduzidos.
Em relação à problemática das questões jurídicas sobre a utilização de veículos autónomos,
podemos concluir que a legislação ainda está numa fase inicial e os VANT irão portanto
desafiar os limites do direito marítimo existente.
2.2.1.1.1. Requisitos de segurança
Há inúmeros requisitos de segurança que têm de ser cumpridos, em termos de normas de
aeronavegabilidade e operacionais, antes que um VANT possa ser autorizado a operar.
Enquanto os voos de VANT além dos limites de controlo visual são atualmente restritos ao
espaço aéreo segregado, o objetivo final é o desenvolvimento de um quadro regulamentar que
permita a plena integração de atividades VANT com aeronaves tripuladas em operações
conjuntas no espaço aéreo. Enquanto nova tecnologia, não há atualmente muitos precedentes
para acomodar VANT no quadro existente das normas que regem os voos no espaço aéreo
não-segregado europeu. Para que isso aconteça com sucesso, uma grande quantidade de
ajustamentos serão necessários.
Uma série de medidas legislativas e regulamentares precisa ser projetada, de comum
acordo, depois elaborada e implementada. Estas regras, devem por sua vez ser fundadas sobre
certas tecnologias essenciais, sendo a mais notável a sense and avoid, o que eliminaria a
possibilidade de uma colisão no ar entre as aeronaves, tripuladas ou não, a voar em espaço
aéreo não-segregado. Isto significa que o controlador de tráfego aéreo não terá de manter uma
vigilância constante a fim de garantir uma separação segura entre uma aeronave não-tripulada
18
e outros utilizadores do espaço aéreo. Para tal, a EDA (Agência Europeia de Defesa) está a
apoiar o programa MIDCAS (Midair Collision Avoidance System).
O objetivo para o qual os legisladores e a indústria se estão a esforçar é para que os VANT
possam ser capazes de operar com um nível de segurança equivalente ao dos aviões tripulados.
Enquanto isso não acontece os VANT são obrigados a voar quer em espaço aéreo reservado
ou, em caso de necessidade de acesso ao espaço aéreo controlado, geralmente têm que obter
uma "isenção" da sua autoridade de aviação local. De momento, as regras variam de um país
para outro. Recentemente, a EDA afirmou que "VANT devem ser rotineiramente capazes de
voar em espaço aéreo controlado Europeu em 2015". No entanto é pouco provável que o
espaço aéreo se abra para os VANT num único 'Big Bang'. A realidade é que uma abordagem
faseada vai realmente ver certos tipos de VANT certificados para voar em certos tipos de
espaço aéreo. O desenvolvimento de um marco regulatório está a ser coordenado pela
EUROCAE – Organização Europeia para Equipamento da Aviação Civil – para a
EUROCONTROL cujo trabalho especializado WG-73 está a colaborar com uma série de
outros participantes internacionais da indústria e as Forças Armadas bem como órgãos
governamentais e académicos relevantes.
Outro grande obstáculo a curto prazo está relacionado com a atribuição de frequências de
rádio. Atualmente, não existem áreas específicas do espectro de RF alocadas exclusivamente
para operações de VANT. Tal como acontece com isenções do espaço aéreo, o acesso a áreas
adequadas do espectro de frequência é concedida, de acordo com a disponibilidade, pela
autoridade local, sendo a atribuição de fatias adequada do espectro esperada para breve.
2.2.1.1.2. A regulamentação europeia
O regulamento CE 216/2008 da Agência Europeia para a Segurança da Aviação (EASA)
prevê a aplicação de normas que tratam de certificação de aeronavegabilidade. Nem o
Regulamento EASA nem as regras de execução se aplicam a aeronaves envolvidas em
operações militares, aduaneiras, policiais ou serviços semelhantes (aeronaves do Estado).
Certas categorias de aeronaves civis estão isentas da necessidade de cumprir o regulamento
da AESA e suas regras de execução. Estas categorias isentas são enumeradas no anexo II do
Regulamento EASA. As categorias de isenção, que são de relevância para o nosso caso são:
19
Aeronaves especificamente concebidas ou modificadas para fins de investigação,
experimentais ou científicos, e, provavelmente, a ser produzido em número muito
limitado (Anexo II 216/2008 alínea b);
Aeronaves que tenham estado ao serviço das forças militares (Anexo II 216/2008
alínea d);
Aeronaves não tripuladas cuja massa operacional seja menor do que 150 kg (Anexo II
216/2008 alínea i).
Qualquer outra aeronave está sujeita ao Regulamento EASA e normas de execução (por
exemplo, uma aeronave não tripulada superior a 150 kg que não é nem experimental nem
utilizado para fins estaduais) e será obrigada a ter um certificado de aeronavegabilidade
EASA.
Uma aeronave que não é obrigada a cumprir o regulamento da EASA, ou porque é uma
aeronave de Estado ou porque está dentro de uma das categorias de isenção, permanece sujeita
à regulamentação nacional medida em certificação de aeronavegabilidade e de
aeronavegabilidade permanente em causa.
Requisitos de equipamentos, regras de funcionamento, licenciamento de pessoal,
regulação de aeródromo e regulação dos serviços de tráfego aéreo ainda não são tratadas por
regulamentos europeus e por isso é tudo uma questão de regulamentação nacional para todas
as categorias de aeronaves.
Apesar da importância deste assunto, esta dissertação tem objetivos científico-
tecnológicos de criação de capacidades que não têm intervenção nesta área, sendo no entanto
naturalmente necessário manter atenção às iniciativas regulamentares de forma a garantir
tecnologia alinhada com o futuro enquadramento.
2.2.1.2. Evolução de capacidades
Não há dúvidas de que os VANT vão ser uma forte tendência no futuro próximo e de
ruptura positiva. Um recente estudo da FAA aposta que na próxima década os VANT serão
responsáveis pela geração de valor significativo na economia, cerca de 90 mil milhões de
dólares.
De acordo com um estudo recente as seguintes áreas serão particularmente endereçadas
pelos VANT:
20
Inteligência Militar
Reconhecimento;
Vigilância;
Ataque;
Apoio 1ªlinha de combate;
Operações de informação;
Segurança
Patrulhamento;
Segurança de fronteiras;
Segurança de perímetro;
Segurança e patrulhamento marítimo;
Ambiente, resposta a emergências e infraestrutura
Vigilância (inteligência, plataformas petrolíferas);
Seguimento e monitorização de tempestades;
Busca e salvamento;
Gestão de emergências (incêndios, derrames marítimos);
Damage assessment (desastres naturais, guerras).
De forma a obter esse nível de importância social, os VANT vão ter de se integrar melhor
com as capacidades existentes que são relevantes para as diversas áreas funcionais. A
integração de coesão e inteligência interna e externa será por isso desenvolvida nos próximos
anos.
2.2.1.2.1. Autonomia
Autonomia é normalmente definida como a capacidade de tomar decisões sem intervenção
humana. O observador atento pode associar isso com o desenvolvimento no campo da
inteligência artificial que se tornou popular na década de 1980 e 1990, tais como expert
systems, redes neuronais, aprendizagem de máquina, processamento de linguagem natural e
visão. No entanto, o modo de desenvolvimento tecnológico no domínio da autonomia tem
seguido principalmente uma abordagem bottom-up e os recentes avanços têm sido em grande
parte impulsionados pelos profissionais da área da ciência de controlo, não das ciências da
computação. Da mesma forma, a autonomia tem sido e provavelmente continuará a ser
21
considerada uma extensão do campo do controlo. No futuro próximo, no entanto, os dois
campos deverão trabalhar colaborativamente num grau muito superior, e os profissionais e
investigadores de ambas as disciplinas irão trabalhar em conjunto para um mais rápido
desenvolvimento tecnológico na área. (The UAV, s.d.)
Alguns dos primeiros VANT são também conhecidos por drones porque eles não são mais
sofisticados do que um avião controlado por rádio diretamente comandado por um piloto
humano (às vezes chamado de operador) em todos os momentos. Versões mais sofisticadas
podem ter embutido sistemas de orientação de controlo e executar tarefas de baixo nível, tais
como a velocidade e a estabilização da trajetória de voo e funções de navegação prescritas, tal
como o waypoint seguinte. Apesar desta perspetiva, os primeiros VANT têm um grau de
autonomia limitado. Na verdade, o campo da autonomia no veículo aéreo é um
desenvolvimento recente, cujos avanços foram em grande parte impulsionados pelas
organizações militares que pretendem desenvolver tecnologia para o combate. Em
comparação com o nível do equipamento de controlo de voo de VANT, o mercado da
tecnologia de autonomia é bastante imaturo e pouco desenvolvido pelo que continua a ser o
maior desafio para futuros desenvolvimentos. O valor total e a taxa de expansão do futuro
mercado VANT podem ser fortemente impulsionados pelos avanços a serem feitos no campo
da autonomia. (The UAV, s.d.)
Embora as tecnologias de autonomia que são descritas de seguida já sejam utilizadas
(principalmente em veículos tripulados), a sua utilização conjunta em VANT será de grande
importância para o desenvolvimento futuro de aeronaves não tripuladas com maior capacidade
de decisão:
• Fusão de dados de sensores: combinando informações de diferentes sensores para uso a
bordo do veículo;
• Comunicações: comunicação e coordenação entre os vários agentes na presença de
informação incompleta e imprecisa;
• Planeamento de voo e trajetória: determinação do caminho ideal para o veículo,
considerando objetivos e constrangimentos, considerando obstáculos, etc;
• Geração de trajetória: determinação de manobra de controlo ótimo para seguir um
determinado caminho ou para ir de um local para outro;
• Alocação de tarefas e programação: determinação da distribuição ótima de tarefas entre
um grupo de agentes, com restrições de tempo e equipamentos;
22
• Táticas cooperativas: formulação de uma sequência ideal e distribuição espacial das
atividades entre os agentes, a fim de maximizar a hipótese de sucesso em qualquer cenário de
missão.
• Tecnologias S&A: pré-determinar os caminhos e permitir aos VANT a deteção de
colisões evitando obstáculos imprevistos no ar. (The UAV, s.d.)
Com o contributo de todas as tecnologias referidas será possível obter VANT que
consigam definir as suas ações baseando-se nos dados providenciados por sensores, reduzindo
assim a interação entre a aeronave e o operador que pode dessa forma concentrar-se em
objetivos primários de missão e analisar possível informação pré-processada proveniente do
VANT. Note-se que a redução de interação entre o operador e o VANT tem também a
vantagem de reduzir o tráfego no canal de comunicação e minimiza a susceptibilidade do
veículo à perda temporária do link de comunicação com a estação de terra do operador (Protti
& Barzan, 2007).
2.2.1.2.2. Percepção (remote sensing)
Hoje em dia os sistemas de deteção e de perceção com nível operacional são
essencialmente utilizados para navegação e prevenção dos riscos no terreno. A maior parte
dos sistemas aviónicos são baseados em GPS e sistemas de navegação inercial, embora haja
outros tipos que também usam registos de velocidade de doppler ou outros sensores de
velocidade de correção para auxiliar o sistema inercial de navegação. O sensoriamento terreno
utilizando sonar em veículos autónomos submarinos e, dotar veículos terrestres não tripulados
de comportamentos como, por exemplo, seguir ao lado de uma parede também são usados.
Outros sistemas, tais como mísseis de cruzeiro usam tecnologia com capacidade de
identificação de terreno e de identificação de cena que podem ter aplicação para algumas
missões de VANT.
Tecnologias de deteção de obstáculos também têm sido um foco de investigação ao longo
da última década, usando uma variedade de sensores incluindo câmaras eletro-ópticas (stereo
e mono), câmaras de infravermelho, radares de banda ultralarga, sonares e LIDAR (Light
Detection And Ranging). A Defense Advanced Research Projects Agency (DARPA) usa
LIDAR e câmaras stereo para construir um mapa tridimensional imediato do veículo, usado
para planear caminhos locais que se movem em direção a um objetivo, evitando os obstáculos.
23
O Programa Marítimo de demonstração de reconhecimento da ONR usa mapas de batimetria
e sonar forward-looking para executar desvio de obstáculos.
Sistemas autónomos que detetam, classificam e identificam alvos ou ameaças são
limitados principalmente ao domínio submarino, apesar das aeronaves tripuladas também
incluírem tecnologias para apoiar o piloto que podem ser utilizada para VANT. A criação de
mapas de situação panorâmica também é rara hoje em dia, exceto em veículos submarinos
usados para mapear a localização de minas submarinas, o que foi feito em meados de 1990 no
DARPA Minehunting automático e Programa de Tecnologias Cartográficas e é uma parte do
Sistema de Monitorização Ambiental Remoto (REMUS), Sistema de Minehunting remoto
(RMS), e Sistema de Reconhecimento de minas de longa-distância (LMRS). O Programa
Marítimo de demonstração reconhecimento ONR (parte das operações autónomas de
capacidade naval futuro (FNC)) usa um conjunto de sensores para criar o panorama da
situação, incluindo comunicações de inteligência (COMINT), inteligência eletrónica (ELINT)
e vídeo para detetar, mapear e evitar ameaças de superfície. (Committee on Autonomous
Vehicles in Support of Naval Operations, 2001)
2.2.1.2.3. Monitorização e diagnóstico
Sistemas de monitorização e diagnóstico são usados para detetar e isolar falhas dentro de
subsistemas VANT. A monitorização e sistemas de diagnóstico em uso hoje baseiam-se
principalmente em equipamento built-in que deteta o mau funcionamento dos subsistemas e
outros equipamentos. Esta informação é geralmente usada para diagnóstico e suporte de
manutenção, mas também pode ser usada para apoiar a reconfiguração do sistema autónomo
ou o replaneamento da missão, particularmente em VANT. A reconfiguração do sistema e
replaneamento missão podem exigir sistemas redundantes a bordo.
A redundância analítica que faz uso de modelos matemáticos de subsistemas de hardware
para fornecer estimativas das medições do sensor esperados ou respostas a deteção e
isolamento de falhas é usada em sistemas tripulados, mas ainda é raramente usada em veículos
autónomos. (Committee on Autonomous Vehicles in Support of Naval Operations, 2001)
24
2.2.1.3. Integração com sistemas externos
Atualmente a perceção do panorama marítimo é tipicamente baseada em diversos sistemas
incluindo sistemas de deteção de embarcações baseados em radar, em sistemas cooperativos
de relato do posicionamento de embarcações, sistemas de alerta, sistemas meteorológicos e
oceanográficos, deteção remota e sensores instalados em meios de sub-superfície, superfície
e aéreos tripulados. Um exemplo de uma iniciativa no âmbito da construção de um panorama
marítimo integrado através da fusão de todas estas fontes de dados é o projeto BlueEye, no
qual a Critical Software é promotora. Projeto este que visa ultrapassar os desafios relacionados
com a eficácia e eficiência em missões de busca e salvamento, patrulhamento marítimo e
proteção ambiental, do qual resultou a plataforma Oversee (Critical Software S.A., 2011). Esta
plataforma oferece um panorama marítimo integrado composto por um mapa sobreposto com
informação adquirida de múltiplas fontes, tais como:
Sistemas de informação de tráfego marítimo – Informação sobre navios a partir de
bases de dados existentes;
Serviços meteorológicos – Velocidade e direção do vento, temperatura do ar,
nebulosidade, precipitação, etc;
Serviços oceonagráficos – Altura e direção das ondas, temperatura da superfície do
mar, correntes e marés, etc;
Cartografia – portos e cais, áreas de jurisdição, batimetria, etc;
A capacidade no que diz respeito a recolha de informação para geração de Conhecimento
Situacional Marítimo (CSM) é crucial para um conjunto de atividades no âmbito da
salvaguarda da vida humana no mar, segurança marítima e a proteção ambiental, entre outras.
Só através do CSM são possíveis a geração de mapas de risco, a antecipação de incidentes,
geração de alarmes, a busca de objetos no mar, condução de operações marítimas, ou obtenção
de prova do ilícito, evitando-se ou atuando em caso de acidentes, incidentes de poluição,
ilícitos ou até desastres naturais, salvaguardando-se assim vidas humanas, protegendo-se o
ambiente marinho e o ambiente costeiro e evitando-se impactos a nível económico (e.g.
turismo), social e politico.
25
VANT Payload
Tal como já foi referido os VANT têm capacidade de payload o que permite acoplamento
de alguns sensores tais como:
Câmaras de luz visível
Os sensores de luz visível são sensores passivos, ou seja, que captam radiação
eletromagnética com um comprimento de onda entre os 400 aos 700 nm. Esta gama de
comprimentos de onda é exatamente a mesma gama captada pelos olhos humanos, portanto, a
informação obtida por estes sensores é de fácil interpretação para os humanos. Com a vasta
utilização deste tipo de sensores, têm existido avanços ao nível da miniaturização e uma
diminuição do seu custo. Estes factos associados à elevada resolução e à economia energética
tornam estes sensores apetecíveis para aplicações remotas ou autónomas.
Como no passado as aplicações autónomas ou remotas não dispunham de muita
capacidade para analisar a informação recolhida, a estratégia mais seguida era a transmissão
de todos os dados para um operador humano ou para outro sistema com mais capacidade
computacional. Contudo, esta abordagem tem algumas desvantagens. Em primeiro lugar,
coloca bastante pressão no segmento de telecomunicações, ao exigir uma elevada taxa de
transmissão de dados. Em segundo lugar, em tarefas repetitivas, enfadonhas e fatigantes, um
operador humano pode apresentar uma quebra de desempenho. Um exemplo típico deste tipo
de situações são as tarefas de vigilância marítima ou de busca e salvamento, em que milhares
de quilómetros quadrados têm que ser examinados com detalhe; desta forma, têm sido
desenvolvidos algoritmos de visão computacional que procuram aumentar a capacidade de
análise das imagens, diminuindo a informação a transmitir e complementando os operadores
humanos.
No caso da vigilância marítima, existem muitas aplicações ao nível do solo que seguem
algumas abordagens bastante restritivas para simplificar o problema de análise das imagens
recolhidas (Fefilatyev & Goldgof, 2008), (Gupta, Aha, Hartley, & Moore, 2009) e (Kruger &
Orlov, 2010). Algumas das abordagens consistem na deteção da linha do horizonte e posterior
deteção de arestas ou na diferença do fundo de imagens sucessivas.
Ao realizar deteção de objetos de interesse a partir de plataformas aéreas, existem vários
constrangimentos que condicionam a metodologia adotada, nomeadamente, o tamanho dos
objetos na imagem (que tipicamente é mais reduzido), o movimento relativo presente na
26
imagem (devido a translações e rotações), a variabilidade do ângulo de observação dos objetos
e a capacidade computacional limitada.
Em (Breckon & Barnes, 2009) e em (Ramakrishnan, Prabhavathy, & Devishree, 2012) é
reportada a utilização dos chamados classificadores de Haar em cascata para identificação de
veículos com uma forma conhecida a priori. Outra técnica que é utilizada quando existe
informação acerca de forma do objeto a detetar é a de Histogram of Oriented Gradients. Esta
técnica é utilizada em (Oreifej, Mehran, & Shah, 2010) e em (Ramakrishnan, Prabhavathy, &
Devishree, 2012) para detetar veículos terrestres, uma vez que têm dimensões e formas com
uma variabilidade reduzida. No caso de deteção de objetos em ambiente marítimo, existe uma
grande diversidade de dimensões, formas, cores e texturas. Os objetos a detetar podem variar
de náufragos a navios de grandes dimensões.
Em (Westall, Ford, O’Shea, & Hrabar, 2008) e (Westall, Shea, Ford, & Hrabar, 2009) é
apresentado um método para detetar náufragos. Nestes trabalhos, os autores assumem que
apenas a cabeça do náufrago vai ser visível e vai ocupar aproximadamente três pixéis. A
pequena dimensão implica sérios desafios a uma deteção fiável e consequentemente, os
autores apresentam duas camadas para efetuar uma deteção. Uma primeira fase em que
utilizam operações morfológicas e uma segunda fase, onde vão acompanhando as deteções ao
longo do tempo com recurso a hidden markov models.
De modo a ultrapassar as dificuldades referidas, foi introduzida uma metodologia de
deteção diferente. Esta metodologia baseia-se no conceito de saliência da imagem e de entre
estes algoritmos destacam-se o modelo de saliência de Itti-Koch (Itti, Koch, & Niebur, 1998),
o modelo dynamic visual attention (Hou & Zhang, Dynamic Visual Attention: Searching for
Coding Length Increments, 2008) ou algoritmos como por exemplo graph-based visual
saliency (Harel, Koch, & Perona, 2007), attention based on information maximization e
saliency using natural image statistic. Em (Sokalski, Breckon, & Cowling, 2007) é mesmo
utilizada uma técnica baseada no trabalho de Itti e Koch para proceder à deteção de objetos
salientes presentes em imagens com um fundo relativamente uniforme. É de destacar que esta
aplicação destina-se a veículos aéreos não tripulados e é aplicável em missões de vigilância
marítima e terrestre.
Uma abordagem promissora é a apresentada em (Hou, Harel, & Koch, Image Signature:
Highlighting Sparse Salient Regions, 2011), em que é calculada a assinatura da imagem com
o recurso à Transformada do Cosseno Discreta. Neste trabalho são apresentadas taxas de
27
deteção iguais ou superiores a outros algoritmos de saliência e tempos de computação bastante
inferiores.
Uma camara de luz visível será explorada como payload com vista ao reconhecimento de
alvos.
Câmaras de infravermelhos
As câmaras de infravermelhos (IR) têm sido fortemente utilizadas a bordo de VANT,
muitas vezes para ultrapassar as limitações dos sensores de luz visível. Como os sensores de
luz visível captam radiação que é refletida pelo objetos observados, a imagem resultante
depende fortemente das condições de iluminação. Já os sensores de infravermelhos captam
radiação que não só é refletida, como também é transmitida pelos próprios objetos que são
observados, dependendo da sua temperatura e de sua emissividade.
Apesar da gama dos infravermelhos estar compreendida entre os comprimentos de onda
de 700 nm aos 1000 μm, para aplicações de vigilância, normalmente destacam-se dois
intervalos, 3-5 μm e 7-15 μm, uma vez que são os mínimos para a absorção de radiação por
parte da água presente na atmosfera (Austin R. , 2010).
Como este tipo de tecnologia não é tão dependente das condições de iluminação como as
camaras de luz visível, é especialmente útil para as aplicações em que se quer realizar uma
vigilância persistente. Para transformar as imagens de infravermelhos captadas em informação
útil, têm sido aplicadas técnicas de processamento de imagem, semelhantes às utilizadas para
imagens de luz visível. Nestas técnicas incluem-se algoritmos de melhoria de imagem (Dulski,
Piatkowski, Trzaskawka, & Kastek, 2012), algoritmos de deteção automática (Srivastava &
Limbu, 2007) e (Toet, 2002) e algoritmos para classificação dos objetos detetados (Teutsch &
Kruger, 2010). Existem ainda algoritmos que utilizam as imagens de infravermelhos de uma
forma complementar a outros sistemas (Samama, 2010).
Uma camara de infravermelhos será igualmente explorada como payload para o
reconhecimento de alvos, nomeadamente de náufragos.
Rádios AIS
Estes dispositivos permitirão ao VANT detetar, localizar e identificar os navios que
possuam AIS ativo. Os dispositivos deverão ter boa capacidade de integração nos VANT,
28
nomeadamente em termos de peso, consumo energético e fácil incorporação no espaço de
payload.
A especificação (ITU , 2010) define todo o conjunto de características técnicas que os
equipamentos AIS devem contemplar.
As especificações são apresentadas para aplicação em meio naval, num esquema de acesso
ao meio físico através de TDMA (Time Division Multiple Access), definindo dois tipos de
transreceptores:
- Tipo A:
+ Maior quantidade de informação trocada e maior repetição da informação;
+ Implementar Self Organized Time Division Multiple Access;
+ Obrigatório para navios IMO;
- Tipo B
+ Menos informação e menos repetição da troca de informação
+ Implementa Carrier Sense - TDMA;
+ Navios com menos de 300ton não homologados pela IMO;
Qualquer dos tipos de transreceptadores, A e B, é capaz de receber mensagens de qualquer
tipo, sendo que enviam apenas mensagens do seu próprio tipo. Os equipamentos apenas
recetores, também conseguem receber mensagens de qualquer tipo.
Das características técnicas definidas na norma, destacam-se:
* Características da camada física do transreceptor;
* Funcionamento do SOTDMA;
* Constituição dos pacotes de dados;
* Estrutura das mensagens;
Um recetor AIS será explorado como payload com o objetivo de efetuar a deteção e
identificação de embarcações com transmissores de AIS.
Estação de Comando e Controlo
Aquando da utilização de um VANT ou de equipas de VANT é necessário recorrer a
software que permita o controlo e o planeamento dos seus objetivos de missão. Este software
de interface tem de permitir a coordenação dos esforços dos veículos presentes no teatro de
29
operações e deve servir como ponto de fusão da informação proveniente de todos elementos
ativos no teatro operacional. O software em questão é executado em associação ao elemento
de missão estação de terra (Ground Control Station - GS) e, tipicamente, é fornecido como
parte integrante do piloto automático equipado no VANT. No entanto estas soluções
comerciais têm uma série de limitações visto estarem normalmente focadas no controlo
específico de uma solução de hardware, bem como a de disponibilizar apenas um conceito de
operação, o qual, por norma, favorece o controlo de VANT em modo singular, em detrimento
de operações multi-VANT cooperativas. Outro fator importante que não favorece a utilização
destas soluções stock, apesar da sua grande compatibilidade com o piloto automático nativo,
prende-se com a dificuldade em expandir as capacidades operacionais do software em questão.
Aplicações desta natureza são predominantemente fechadas, salvo exceções de pilotos
automáticos low-cost, não sendo possível ao utilizador alterar o código fonte da mesma.
Apesar destas medidas salvaguardarem os interesses do fabricante do piloto automático, elas
tornam virtualmente impossível a adequação do software de controlo a outros cenários
operacionais que não tenham sido contemplados no momento de conceção do hardware.
De forma a colmatar esta dificuldade, vários grupos de investigação e desenvolvimento
têm-se dedicado à criação de software de comando e controlo que vá para além daquele
fornecido pelo piloto automático. Muitos destes projetos começaram associados a controlo de
veículos específicos (Bruch, Powell, & Gilbreath., 2006) mas rapidamente ganharam
amplitude para incorporar não só controlo cooperativo entre veículos do mesmo tipo (Powell,
Barbour, & Gilbreath, 2012), como também controlo entre veículos heterogéneos (Simmons,
et al., 2000). Estas aplicações são normalmente utilizadas em conjunto com o software
fornecido pelos criadores do piloto automático, no entanto muitas são capazes de substituir
por completo o seu homólogo comercial.
Um exemplo destes sistemas expansivos é o sistema C4I (Command, Control,
Communications, Computers and Inteligence) Neptus desenvolvido pela Faculdade de
Engenharia da Universidade do Porto (FEUP). Este sistema é orientado para operações com
múltiplos veículos em ambiente de iniciativa mista (Almeida, Gonçalves, & Sousa, 2006),
(Gonçalves, Ferreira, Pinto, Sousa, & Gonçalves, 2011). Este sistema apoia o operador
humano em todas as fases do ciclo de vida de uma missão: representação do mundo,
planeamento, simulação da missão, execução e análise de execução. De igual forma o sistema
facilita interações de iniciativa mista com veículos heterogéneos efetuadas sobre redes de
comunicação interoperadas implementando, para o efeito, um protocolo de comunicação
30
baseado em XML (Martins, et al., 2009) e protocolos STANAG (STANAG, 2006). O Neptus
não só permite o controlo direto sobre o planeamento das manobras de um veículo, através de
manipulação de waypoints (ponto no globo terrestre precisamente definido por coordenadas
geográficas através do sistema GPS) e limites de operação, como também permite a
implementação de controlo deliberativo devido à sua integração com a framework TREX
(McGann, et al., 2008), permitindo uma maior autonomia de decisão por parte do VANT bem
como uma redução do peso operacional para o elemento humano especialmente em situações
multi-VANT. Adicionalmente todas as consolas de controlo são criadas por forma a aumentar
o nível de alerta situacional do operador ao mesmo tempo que é reduzida a sua carga de
trabalho (Fuchs, Ferreira, Sousa, & Gonçalves, 2013).
Estação de Payload
Como já vimos a estação (ou estações) de controlo é uma importante parte de um sistema
aéreo não tripulado, sendo este sistema que permite aos operadores interagir com a aeronave
que conterá a bordo, num dado espaço e tempo, o equipamento necessário para realizar uma
dada missão (o chamado payload de missão). É também através desta estação que os
operadores recebem informação sobre os subsistemas da aeronave (housekeeping data),
posição, altitude, velocidade e payload, e, em alguns casos, planeiam a missão.
Se é importante assegurar o controlo e estabilidade da aeronave, garantindo um voo seguro
e eficaz, não é menos importante fazê-lo para o payload. O controlo da aeronave é necessário
para colocá-la na área pretendida, mas será inútil para a missão a não ser que o payload seja
devidamente controlado (Austin R. , 2010). É por isso que nas equipas de operação de VANT,
não obstante a dimensão do sistema, existem sempre duas funções primárias: piloto,
responsável por voar a aeronave, e operador de payload/sensores, que controla e monitoriza
os sensores específicos para a missão. Estas funções são, preferencialmente, executadas por
pessoas diferentes, apesar de em alguns casos, principalmente em sistemas de menor
dimensão, poderem ser feitas pela mesma pessoa.
Este não é um conceito exclusivo nem originário dos sistemas não tripulados – existem
várias aeronaves tripuladas com missões atribuídas de vigilância, reconhecimento e patrulha,
que requerem o transporte a bordo de um vasto conjunto de sensores que necessitam de uma
operação continuada e dedicada. A exigência de cada função não permite que uma pessoa
31
partilhe a sua atenção por todas, sob pena de a missão, e também segurança, virem a ser
comprometidas.
Esta forma de operação, em que o controlo do payload é feito por um ou mais elementos
dedicados, foi exportada para os VANT, com a diferença de os operadores estarem, neste caso,
fora da aeronave. De seguida apresentam-se quatro exemplos de VANT onde esta filosofia é
seguida:
MQ-1B Predator – medium-altitude, long-endurance VANT para apoio aéreo próximo,
interdição aérea e ISR (Intelligence, Surveillance, Reconnaissance). Contém sensores como:
sistema de targeting multiespectral, sensores EO/IR e designadores laser. A equipa de
operação envolve um piloto, um operador de sensores e um mission intelligence coordinator.
O piloto e o operador de sensores executam as suas funções na ground control station, em
consolas independentes, mas lado a lado. Fisicamente as consolas são idênticas, e podem ser
usadas como estação de pilotagem ou de controlo de payload, mas têm funcionalidades
diferentes dependendo do modo de operação (Carrigan, 2008).
RQ-5 Hunter – VANT tático para vigilância, reconhecimento, aquisição de alvos e
avaliação de danos de batalha. O seu payload de missão inclui, entre outros: radar de abertura
sintética, multi optronic stabilized payload, IMINT (Imagery Intelligence) e capacidade de
integração COMINT & ESM (Communications Intelligence & Electronic Support Measures).
O controlo do sistema é feito através de uma ground control station, que contém consolas
independentes para três operadores, entre as quais uma para o piloto, outra para o operador de
payload (neste sistema chamado Real Time Observer) e uma terceira do tipo RVT (remote
vídeo terminal) para operação tática avançada (este operador está em comunicação com
equipas terrestres, transmitindo-lhes a sua análise do terreno a partir do feed de vídeo
recebido). Tal como no Predator, estas consolas podem ser usadas para qualquer uma das
funções (Delogne, 1999), (Israeli Weapons, LTD., 2013).
A uma menor dimensão, também se verifica esta separação entre o controlo da aeronave e
o controlo do payload de missão em modelos como o RQ-2 Pioneer e o RQ-7 Shadow, da AAI
(US Army, 2006).
32
Comunicações
A comunicação com um VANT é de primordial importância, já que a grande maioria dos
sistemas atuais não opera de forma totalmente autónoma, necessitando de um sistema fiável e
seguro de comunicações com uma estação de terra. Por esta razão, não se deve subestimar a
importância do sistema de comunicações no desenho e construção de VANT, já que esta irá
limitar a área máxima de cobertura da própria aeronave (devido a potenciais limitações do
canal, ou canais, de comunicação a serem usados), o tipo de dados a poderem ser
disponibilizados do VANT para a estação de terra (devido a limitações de largura de banda),
bem como o tipo de controlo das operações do VANT (devido à latência dos canais de
comunicações). Por outro lado, a própria arquitetura do VANT limita o tipo de comunicações
possíveis, já que as dimensões, peso e consumo energético das antenas e
transmissores/recetores são limitados pelas características físicas da aeronave.
A comunicação com um VANT tem duas funções principais:
- Controlo da aeronave (uplink), de forma a controlar a navegação da aeronave
(levantamento de voo, deslocações, a sua recuperação, etc) e também o seu payload e sensores.
- Obtenção de dados do VANT (downlink), para recolher dados de telemetria dos sensores
do VANT e o estado do sistema.
Enquanto as necessidades de ligação de uplink do VANT tipicamente são baixas em termos
de largura de banda necessária, sendo mais importante a latência da mesma (por exemplo, para
permitir o controlo teleguiado do VANT), o mesmo não pode ser dito do downlink que,
consoante o tipo de missão e payload, pode requerer uma largura de banda significativa para
transmissão de dados dos sensores (e.g., fotografias, vídeo) ou de outro tipo de telemetria.
Sistemas de VANT atuais utilizam diversas tecnologias de comunicação, que tipicamente
são divididas em três tipos de cobertura, que acabam por determinar o alcance do próprio
VANT.
2.6.1. Comunicações locais
Comunicações locais, para operações de curto alcance em linha de vista, recorrendo a
antenas omnidirecionais, normalmente em canais UHF ou VHF bidirecionais. Usualmente este
tipo de comunicações são apenas utilizadas para operações de lançamento e recuperação dadas
as suas naturais limitações de aplicação.
33
2.6.2. Comunicações em linha de vista
Comunicações de longo alcance em linha de vista (Line of Sight, LOS), tipicamente
recorrendo a ligações bidirecionais usando frequências radio e antenas direcionais. Este tipo
de comunicação é extremamente comum tanto em VANT militares como civis, tais como o
Global Hawk, Pioneer, Hunter e Pitvant.
A utilização de frequências rádio levanta uma série de questões, já que diferentes
frequências possuem características distintas. Enquanto frequências muito baixas (até 3MHz)
podem ser utilizadas até a uma distância bastante mais elevada mas com uma baixa
transmissão de dados, à medida que a frequência a ser usada é superior (de 3MHz até 300MHz)
a taxa transmissão é progressivamente maior mas menor é a cobertura/alcance, devida à cada
vez maior necessidade de ligações em linha de vista ininterruptas. Como tal, VHF (30 a
300MHz) e VHF (300MHz a 3GHz) são vistas como boas soluções de compromisso e muito
utilizadas para a comunicação de VANT (e.g., Global Hawk e Pitvant).
Uma outra característica da utilização de frequências rádio é a sua dependência entre as
altitudes das antenas em causa, isto é, da altura da antena na estação de terra e da altitude a
que se encontra o VANT.
Figura 3: Alcance máximo em linha de vista consoante a altitude de operação do VANT (Austin R. , 2010)
34
A Figura 3 mostra a variação da cobertura da linha de vista usando frequências rádio em
que o VANT se desloca até a um máximo de 1000m de altitude. Como se pode ver, em
condições ideias, e recorrendo a uma antena na estação de terra de 2m, o alcance máximo é de
sensivelmente 130km, número esse que na prática é sempre substancialmente inferior devido
às condições envolventes (e.g., presença de nuvens).
Recorrendo a tecnologias LOS, as duas principais formas de aumentar o alcance da
comunicação com VANT são:
- Através da existência de estações de terra móveis e/ou da existência de múltiplas estações
de terra, não estando limitado à comunicação com uma estação de terra fixa, fazendo
transferência do controlo das aeronaves entre estações de terra, aumentando dessa forma o
alcance máximo dos VANT.
- Recorrendo a relays, isto é a outros elementos que comuniquem diretamente com o
VANT e transmitam essa informação de e para a estação de terra, elementos esses que podem
ser fixos (e.g., estações submarinas) ou móveis (e.g., outros VANT e navios). Um exemplo do
uso desta técnica é o Tactical Unmanned Aerial Vehicle (TUAV) (US Army Intelligence
Center, 2000), um sistema VANT que pode servir de relay para outros elementos em cenários
de guerra. No futuro, a utilização de VANT de grande autonomia e alta altitude (High Altitude
Long Endurance (HALE) UAVs, (AeroVironment, Inc., 2013)) como relay de comunicações
poderá até competir com outros canais como o SATCOM, dado o potencial baixo custo destas
soluções.
Sistemas recorrendo a laser ou fibra óptica também foram projetados e desenvolvidos,
embora estes tipos de tecnologias tenham sido genericamente abandonados (Austin R. , 2010).
Dito isto, está prevista a futura utilização de comunicações ópticas em linha de vista, mas
apenas para além de 2020 (USA DoD, 2011). Outras técnicas são passiveis de utilização por
parte de VANT, tais como GPRS e WIFI, mas a sua natureza torna-as pouco interessantes e
relevantes no contexto de operações marítimas.
2.6.3. Comunicações para além de linha de vista
Os sistemas de comunicação baseados em satélite (SATCOM) para VANT têm por
objetivo estender as capacidades de comunicação dos mesmos. Este tipo de comunicações
enquadra-se nas comunicações do tipo para além de linha de vista (Beyond line of sight,
BLOS). Tipicamente o SATCOM é utilizado em plataformas de maior dimensão, por exemplo
35
Predator e Global Hawk (USA DoD, 2011), uma vez que estas, fruto das suas capacidades
podem facilmente ultrapassar as distâncias dos sistemas de comunicação para linha de vista.
O SATCOM é também muito menos dependente do meio envolvente que os sistemas LOS,
tornando-se ideal para utilização em VANT em áreas remotas e/ou com ambientes austeros.
Para além de estender o alcance das comunicações, outro aspeto fundamental da utilização
de SATCOM a ter em conta é o facto de permitir taxas de transmissões de dados muito mais
elevadas que as utilizações típicas de técnicas em linha de vista, sendo possível a utilização de
canais com taxas de vários megabits por segundo. Atualmente uma câmara eletro-óptica ou de
infravermelhos produz taxas de transmissão de 75 megabytes por segundo. Em termos de
sistemas VANT, estima-se que um Global Hawk, por exemplo, com os seus diversos sensores
disponibilize uma taxa de 500 megabytes por segundo (Austin R. , 2010). A crescente
utilização de VANT por parte das forças armadas americanas e as suas crescentes necessidades
de maiores larguras de banda são atualmente um dos motores do desenvolvimento do
SATCOM militar (Covault, 2010). A utilização de SATCOM não é, contudo, desprovida de
dificuldades, não só em termos de desenho do VANT (gastos energéticos, etc) para acomodar
a utilização da tecnologia, mas também devido ao facto desta solução ser economicamente
onerosa.
36
37
Capítulo 3
Análise do sistema
Neste capítulo serão apresentados os requisitos, a arquitetura inerentes a esta dissertação
e também os componentes de hardware utilizados. De referir ainda que requisitos referentes
às estações de terra não estão incluídos nesta análise visto estas não serem objetivo desta
dissertação, no entanto estas podem ser referidas em alguns destes requisitos, por questões de
interface.
Requisitos
Nesta secção será apresentada uma visão geral sobre os requistos do sistema e é importante
ter em conta que estes requisitos se referem ao sistema SEAGULL como um todo sendo que
os módulos implementados no âmbito desta dissertação estarão a responder às necessidades
levantadas por estes mesmos requisitos. Assim sendo, o principal requisito do sistema é
fornecer informação relevante para a criação de um conhecimento situacional marítimo, capaz
de apoiar operações marítimas em diversos contextos de missão. Este objetivo requer um
sistema a bordo do VANT capaz de:
Recolher vídeo / fotos, imagens de infravermelhos, multiespectrais e hiperespectrais;
Processar esses dados e produzir alarmes em tempo útil;
Georreferenciar e armazenar todos dados em bruto e a informação extraída para futura
disseminação e análise;
Deteção e identificação de objetos de interesse;
Deteção e evasão de colisões entre veículos;
Embora não seja economicamente interessante a transmissão em tempo-real para terra dos
dados em bruto (e.g. vídeo), a transmissão da informação resultante do seu processamento,
tendo requisitos de largura de banda bastante inferiores, torna-se bastante desejável.
Posteriormente, em terra, todos os dados poderão ser persistentemente armazenados para
análise offline. Assim o sistema deverá permitir o processamento a bordo e a posterior
transferência de dados (e.g. na aproximação à estação de terra ou depois de aterrar).
38
O sistema deve ser capaz de realizar missões pré-planeadas (por exemplo, missões pré-
programadas de patrulha costeira), permitindo o seu replaneamento em pleno voo. Em
particular este último ponto (replaneamento) irá normalmente exigir uma resposta rápida, uma
vez que estas ações de replaneamento estarão normalmente relacionadas com situações de
emergência, tais como busca e salvamento (e.g. busca de uma balsa salva-vidas), ou
fiscalização marítima (e.g. monitorização de um derrame). Em caso de mudança do tipo de
missão o módulo de deteção deverá adaptar o seu algoritmo para detetar outro tipo de objetos
caso a situação assim o exija.
Um outro aspeto fundamental prende-se com a dimensão das áreas a serem cobertas. O
sistema deverá estar dimensionado para ser capaz de monitorizar grandes áreas geográficas (o
parâmetro-chave de desempenho é a "Taxa de Aquisição Hora"). Mais, o sistema deverá estar
preparado para operar em cenários de condições meteorológicas adversas incluindo situações
de visibilidade reduzida, grande turbulência e temperaturas extremas.
Finalmente, o sistema deve ser capaz de assegurar a manutenção dos parâmetros de
segurança nomeadamente de pessoas e bens. Assim, os VANT deverão dispor da capacidade
de serem operados remotamente e da capacidade de operarem com segurança na presença de
outros meios aéreos. Assim, além de um sistema de deteção e evasão de colisões, o operador
deverá receber em tempo real o estado atualizado dos sistemas de ar, a fim de ser capaz de
monitorizar e controlar os VANT se necessário.
Assim sendo, foram criadas três tabelas de requisitos, do sistema, de hardware e de
software, as quais podem ser encontradas no Anexo A.
Arquitetura do sistema
As secções seguintes apresentam as preocupações da Meta-Arquitetura e decisões que vão
guiar todos os desenvolvimentos futuros.
3.2.1. Arquitetura aberta
O rápido crescimento nas tecnologias digitais levou a aplicações novas e melhoradas,
criando no entanto alguns problemas, dos quais se destacam a obsolescência e questões de
dependência. O problema de obsolescência é causado pelos avanços tanto no hardware como
no software que tornam muitos computadores obsoletos em três a cinco anos (Vilbrandt,
39
2004). Problemas de dependência podem surgir se as ferramentas que são necessárias para a
comunicação entre sistemas ou para a leitura de dados e formatos de representação se tornam
indisponíveis.
Quando corretamente criados os padrões abertos oferecem mais soluções de forma a evitar
que se tornem obsoletos (Vilbrandt, 2004) e são mais confiáveis e estáveis do que os formatos
proprietários (Breeding, 2002). Quando um padrão aberto se torna obsoleto, a abertura
estabelecida poderá assegurar que os dados e os sistemas atuais podem ser livremente
transformados e migrados. Os padrões abertos ajudam a aliviar problemas causados pela
obsolescência ou dependência, já que, os arquivos criados em formatos que aderem a padrões
abertos são "provavelmente mais facilmente legíveis do que os formatos proprietários após
vinte ou cinquenta anos" (Baker, 1999), permitindo uma maior flexibilidade e fácil migração
para diferentes sistemas no futuro. O uso de padrões abertos pode ajudar a garantir a
interoperabilidade dos diversos sistemas, sendo uma forma de garantir que os diversos
sistemas atuais e os sistemas futuros poderão comunicar uns com os outros, ajudando assim a
alcançar o "livre fluxo de informações através da interoperabilidade" (The Open Group, 2005).
Assim sendo, usando padrões abertos, podem ser maximizados os seguintes fatores:
Interoperabilidade;
Independência de fornecedor;
Maior flexibilidade na escolha;
Maior flexibilidade na implementação;
Menor e melhor gestão de risco;
Robustez e durabilidade;
Custo.
Tendo em conta estes pressupostos, foi tomada a decisão de construir um sistema baseado
em arquitetura aberta que pode cumprir com os princípios acima referidos. Devemos pois
maximizar a utilização de código aberto e componentes de padrão aberto, protocolos e
interfaces tanto de hardware como de software. É assim esperada a maximização da
interoperabilidade e a qualidade do sistema resultante, bem como a facilitação de roadmaps
futuros criados a partir destes protótipos.
40
3.2.2. Baixo nível de acoplamento entre funções
Um dos principais objetivos arquiteturais deste projeto é o baixo nível de acoplamento
entre os sub-sistemas. O sistema será composto por diversos módulos funcionais, os principais
dos quais lidam com o comando e controlo (SEC2) e a deteção de objetos através das câmaras
presentes a bordo da aeronave (SEP). Embora exista alguma dependência entre estes sistemas,
em termos arquiteturais pretende-se que seja possivel colocar tanto o SEC2 como o SEP
noutras aeronaves com um mínimo de alterações. Ou seja, se quisermos trocar a unidade
computacional SEP, por exemplo, apenas necessitamos que o novo sistema implemente as
mesmas interfaces de ligação da unidade lógica em questão. Da mesma forma, as dependências
dos sistemas a bordo para com o piloto automático e respetiva ground station (ETC2) deverão
ser reduzidas ao mínimo, e concentradas em módulos bem identificados, de forma que a
utilização de uma alternativa ao Piccolo seja uma simples questão de alterar o módulo que faz
a interligação com o mesmo.
Associado ao baixo nível de acoplamento está o desejo de garantir uma arquitetura que
consiga endereçar a implementação específica deste projeto mas não só, esta abordagem
permite, além de troca de componentes, o crescimento do sistema na medida em que novos
módulos podem ser acrescentados desde que tenham em conta as especificidades das
interfaces. Em particular:
Poder suportar funcionalidades não previstas de interação entre o operador de Payload
(via estação de terra de payload – ETP) e o Payload (SEP) em si. Para tal, será
necessário garantir um protocolo de comunicação suficientemente genérico e versátil
entre os dois sistemas, capaz de suportar novos comandos (ETP → VANT) ou novos
dados telemétricos (VANT → ETP) que venham a ser necessários no futuro sem que
quaisquer alterações arquiteturais sejam necessárias.
Poder suportar diferentes sensores, tipos de sensores e algoritmos de deteção de
objetos. Embora os sensores (e em particular as câmaras) a utilizar no projeto estejam
definidos, a sua utilização específica não é uma preocupação da arquitetura, antes uma
forma genérica de disponibilização de dados dos sensores (quaisquer que eles sejam)
a um ou mais módulos que os utilizem para a deteção e identificação de objetos. Ou
seja, novos sensores além daqueles que foram definidos podem ser adicionados sem
alterações à arquitetura, apenas sendo necessário ter em conta a compatibilidade dos
mesmos com as interfaces disponibilizadas. De notar que o SEP estará centrado na
41
deteção e identificação de objetos com base nos sensores a ele ligados, embora
arquitecturalmente possa facilmente ser estendido para suprir necessidades de natureza
diferente que surjam no futuro.
3.2.3. Decomposição do sistema
3.2.3.1. Vista física
A Figura 4 apresenta uma visão geral do sistema e das ligações físicas entre os vários
componentes.
Figura 4: Vista física do sistema
As secções seguintes descrevem os vários componentes presentes na Figura 4. A vista
física do sistema não inclui as antenas e demais componentes necessários à comunicação entre
o VANT (Piccolo) e a terra (ETC2, Piccolo Ground Station), já que esses componentes não
são necessários à compreensão da arquitetura, sendo assumido simplesmente que existem
(tanto no VANT como na terra) e que o canal de comunicação tem determinado número de
42
características físicas e lógicas com o qual o software a executar nas diversas plataformas terá
de lidar.
A estação de SISOM (Sistema de informação e suporte a operações marítimas) é, neste
caso uma representação abstrata e pretende apenas indicar a capacidade do sistema de fornecer
dados que possam ser utilizados por estações SISOM pelo que não será um tema abordado
nesta dissertação.
3.2.3.2. Arquitetura a bordo
Esta secção irá incluir uma visão geral dos sistemas embarcados, como se inserem no
VANT e como estão ligados entre si.
Figura 5: Visão da pilha de software/hardware dos sistemas embarcados
A Figura 5 detalha os sistemas embarcados a bordo do VANT, mais especificamente os
três componentes principais:
Microcontrolador Piccolo, sistema COTS da Cloud Cap Technology que implementa
o piloto automático da aeronave (sendo este o componente que realmente controla a
43
aeronave), providencia telemetria de navegação (recorrendo também ao seu GPS
interno) aos restantes sistemas e gere o canal de comunicações com a estação de terra
de comando e controlo (ETC2). A ligação entre o microcontrolador Picollo e qualquer
outro sistema a ele ligado (SEC2, no caso) será feita através de porta série.
Computador do Sistema Embarcado de Comando e Controlo (SEC2), que terá a
responsabilidade de fazer toda a ligação direta dos sistemas com o Piccolo, incluindo
o seu controlo por parte dos sistemas da aeronave (para as funcionalidades de sense
and avoid e target tracking), bem como a ligação com o sistema de comunicação com
a terra (através do Piccolo). O módulo Autopilot Driver servirá de interface para todos
os comandos de baixo nível dirigidos ao AP (comandos para execução de manobras
enviados pelo TT ou S&A) e telemetria de navegação necessária ao funcionamento do
sistema a bordo. Já o módulo Autopilot Comms será o interface entre o Comms Relay
(módulo que implementa a garantia de entrega das mensagens e a sua
fragementação/agregação) e o AP para a troca bidirecional de dados entre a terra e o
VANT. Dado que este computador terá a tarefa de realizar todas as operações de
comando e controlo (C2), o recetor ADS-B (ver secção 3.3.3.5) usado no contexto do
S&A (para deteção de outros VANT próximos) estará ligado a este sistema. O módulo
de S&A e o módulo de TT não podem executar em simultâneo pelo que o módulo
Control Supervisor terá como tarefa o controlo de prioridades de execução destes dois
subsistemas, garantindo assim uma execução mutuamente exclusiva. Será também
nesta unidade computacional que se irá encontrar o ROS master (Funcionalidade ROS
que garante que todos os nós lançados conseguem localizar-se e comunicar entre si).
Todos os outros nós ROS sejam eles parte do SEC2 ou do SEP, estarão ligados a este
ROS master (A variável de ambiente ROS_MASTER_URI permite definir a
localização na rede do computador onde se encontrar o ROS master). O middleware
ROS será detalhado na secção 0.
Computador do Sistema Embarcado de Payload (SEP), que conterá todas as
funcionalidades de deteção de alvos, estando por isso ligado diretamente a todos os
sensores usados para esse efeito. Dadas as necessidades computacionais da análise de
imagens das câmaras, este computador terá requisitos de desempenho mais elevados
que os restantes sistemas, e também terá de possuir um GPU compatível com OpenCL,
dada a natureza e forma de implementação dos algoritmos em questão. O SEP irá ligar-
se por Ethernet ao SEC2 de forma a obter dados de navegação (telemetria da aeronave),
44
poder ativar e fornecer posição do alvo ao módulo de target tracking e comunicar com
a terra. Todas as mensagens, antes de serem enviadas para terra, são encapsuladas em
formato MAVlink (Micro Air Vehicle Communication Protocol), uma biblioteca
header-only bastante leve utilizada para o empacotamento de estruturas C em canais
série (ver secção 3.2.4.2). Este protocolo também será usado em terra pela ETP, ou
seja, toda a comunicação entre VANT e terra será encapsulada em MAVLink.
A utilização de um sistema de navegação, no caso o Piccolo, é uma necessidade do projeto,
já que a implementação de um piloto automático está fora do seu âmbito. Já a separação entre
dois computadores das funcionalidades de comando e controlo (no SEC2) e de payload (SEP)
é uma decisão arquitetural que pretende atingir dois objetivos principais:
Não sobrecarregar o SEP com necessidades de processamento que não as relacionadas
com a deteção de objetos através dos seus sensores;
Diminuir a dependência das funções de payload das funcionalidades de comando e
controlo e vice-versa. A arquitetura adotada permitirá que o SEP seja colocado noutros
VANT de características diferentes e com um SEC2 diferente, com um número
mínimo de alterações (e nenhumas do ponto-de-vista do hardware, desde que exista o
interface Ethernet). De igual modo, deverá ser possível ao SEC2 ser utilizado noutras
aeronaves, com outros SEPs (ou mesmo sem a presença de qualquer sistema
embarcado de Payload, já que o SEC2 não dependerá de modo algum da presença de
um SEP), desde que os interfaces existentes sejam respeitados. Para além do mais,
embora o SEC2 dependa da existência de um piloto automático, fisicamente o sistema
não depende do Piccolo em concreto.
Esta decisão de utilizar dois computadores em vez de um tem o lado negativo de
acrescentar necessidades energéticas, de peso e de volume adicionais, que no entanto não
foram consideradas decisivas para levar a considerar o abandono da separação física entre os
dois sistemas.
Embora os tipos de sensores a utilizar no contexto do payload estejam perfeitamente
definidos (AIS, câmara de infravermelhos, câmara de espectro-visível e câmara híper-
espectral), a arquitetura do projeto será agnóstica desse ponto de vista, necessitando apenas
que existam interfaces compatíveis (e em número suficiente) para quaisquer sensores que a
ele sejam ligados. É necessário, naturalmente, levar em linha de conta o peso, volume e
necessidades energéticas desses mesmos sensores para se ter a certeza que são compatíveis
com a aeronave em questão.
45
3.2.3.3. Equipamentos de terra
Os equipamentos de terra são aqui apresentados de forma resumida, visto que a ETP terá
a sua implementação detalhada no capítulo 5 e a ETC2 é um sistema COTS (Commercial off-
the-shelf). Assim sendo, em terra teremos os seguintes componentes principais:
Estação de terra de comando e controlo, equipamento onde estará a executar a estação
de controlo do Piccolo controlada pelo piloto do VANT e ligada, fisicamente, às
antenas usadas para comunicar com o VANT;
Estação de terra de payload, dispositivo a ser utilizado pelo operador de payload. Esta
consola terá ligações físicas tanto à ETC2 (para troca de dados bidirecional com
VANT, configurar a própria ETC2 (e.g. envio de waypoints) e receber dados de
telemetria da aeronave) como ao sistema externo SISOM. O SISOM é completamente
agnóstico do resto do sistema, sendo apenas necessário implementar um interface (de
software) bem definido. Fisicamente, dado que a tecnologia a usar será SOA, bastará
uma ligação de rede entre ambos. De notar que a ETP poderá estar ligada a uma
(necessariamente) ou mais ETC2, dado que é assumido que cada ETC2 controla uma
única aeronave, de forma a controlar o payload de duas ou mais aeronaves.
3.2.4. Visão geral do software
A Figura 6 apresenta uma visão geral do software a ser executado tanto a bordo do VANT
como nas estações de terra, e suas localizações.
46
Figura 6: Visão geral do software
A descrição das funcionalidades de cada computador (e, logo, de cada unidade lógica) foi
enumerada na secção anterior e a divisão lógica funcional é idêntica à divisão física (SEC2
tratando de toda a gestão de ligação ao Piccolo, incluindo as comunicações, e funcionalidades
de navegação e SEP sendo responsável por todas as atividades relacionadas com a deteção de
alvos por parte do VANT). Convém no entanto ressalvar a presença de middleware ROS e dos
módulos Autopilot Driver e Comms Relay na ETP. Esta é uma necessidade arquitetural pois,
tal como no VANT necessitamos de módulos que comuniquem com o Piccolo, também em
terra é necessária a existência de módulos que comuniquem com a ETC2. Esta abordagem
quanto aos módulos de comunicação é detalhada na secção 4.1.1.
As secções seguintes descrevem os vários componentes de hardware utilizados, no entanto
importa explicitar desde já o middleware ROS e o protocolo de comunicação MAVLink, uma
vez que se tratam de componentes centrais a toda a arquitetura.
47
3.2.4.1. Middleware ROS
O Robot Operating System (ROS) é um middleware/framework open source muito
utilizado no contexto da robótica, que disponibiliza um conjunto de ferramentas e bibliotecas
que facilitam o desenvolvimento nesse domínio. A funcionalidade mais relevante no contexto
do projeto é o método de comunicação assíncrona entre nós, disponibilizado pelo ROS,
permitindo que nós publiquem mensagens em tópicos. Estas mensagens irão ser recebidas por
quaisquer outros nós que tenham subscrito o tópico para onde a mensagem foi enviada. Dessa
forma, os nós não se encontram acoplados entre si de qualquer forma, para além do
conhecimento da existência do tópico e da estrutura das mensagens enviadas no mesmo. Dito
de outra forma, os tópicos são uma forma de comunicação assíncrona e unilateral entre nós,
não existindo limite do número de processos a subscrever e a publicar num qualquer tópico.
Na prática, o ROS funciona como um bus onde os nós podem subscrever tópicos e enviar
mensagens para esses mesmos tópicos.
Para além do envio assíncrono de mensagens, o ROS permite também que processos
disponibilizem serviços síncronos, tipo RPC, em que existe uma invocação de uma função no
processo que disponibiliza o serviço, podendo esse disponibilizar uma resposta de volta após
a conclusão da operação.
O bus do ROS funciona de forma transparente entre computadores ligados em rede (na
prática os nós nem possuirão noção se os restantes nós estão a executar no mesmo computador
ou não), o que será o caso do SEC2 e SEP, dessa forma, não será necessário acrescentar
qualquer outro mecanismo de comunicação entre esses dois sistemas, estando ambos
simplesmente integrados entre si pelo ROS. Dada o alto desempenho (ethernet) da ligação
entre esses dois sistemas, e a eficiência que se prevê adequada do ROS, esta solução acaba por
ser bastante versátil, tanto do ponto de vista do resultado final como na facilidade de
desenvolvimento e realização de testes de módulos independentes.
Uma outra funcionalidade do ROS que se revela extremamente vantajosa no contexto do
projeto é a do rosbag. Quando ativada, esta funcionalidade permite gravar para disco todas as
mensagens dos tópicos desejados (quer sejam parte dos tópicos existentes ou mesmo todos)
durante a execução de uma missão, sendo depois possível recriar a execução do sistema
posteriormente. Como todos os principais módulos utilizarão principalmente as mensagens
assíncronas dos tópicos ROS para comunicarem entre si, incluindo os módulos que
disponibilizarão as imagens das câmaras (que o farão precisamente em tópicos ROS
48
específicos por cada sensor e por cada espetro), será efetivamente possível gravar toda uma
missão para posterior análise na terra, estando apenas limitado à capacidade de
armazenamento do computador onde esteja a ser guardado o rosbag.
O mecanismo de publicação/subscrição de tópicos, no ROS, em que a última (ou últimas)
mensagem enviada para esses tópicos são entregues aquando da subscrição do tópico, permite
oferecer uma forma simples e polivalente de persistência de dados a todos os componentes.
De referir que o projeto tira partido das funções disponibilizadas pelo ROS descritas em
cima, embora não dependa exclusivamente deste. O ROS poderá perfeitamente ser substituído
por outro middleware desde que este genericamente suporte a utilização de mensagens
síncronas e assíncronas, com um impacto mínimo na arquitetura do sistema.
3.2.4.2. MAVLink
O protocolo de comunicação MAVLink consiste numa biblioteca header-only bastante
leve utilizada para o empacotamento de estruturas de dados em canais série. Cada biblioteca
é gerada a partir de um ficheiro xml onde podem ser especificadas as mensagens e que é
posteriormente convertido para C++ utilizando um dos vários geradores disponíveis (C, Java,
C#, etc.). O exemplo de um ficheiro xml pode ser visto na Figura 7.
Figura 7: Ficheiro XML MAVLink
49
Hardware
Nesta secção são apresentados os componentes que irão a bordo da plataforma e as suas
características técnicas mais relevantes. Esta secção apresenta todos os componentes que
fazem parte do Sistema de Payload da plataforma, nomeadamente os sistemas computacionais
e sensores de visão.
3.3.1. Piccolo
O Piccolo (Figura 8), um produto comercial, é o piloto automático dos VANT. É o
componente que normalmente faz a pilotagem direta do avião, consoante o destino dado pelo
operador que se encontra a comandar a aeronave na terra através da Piccolo Ground Station
(ETC2).
Figura 8: Piccolo autopilot
A Figura 9 apresenta a ligação de uma estação de terra e o correspondente
microcontrolador Piccolo presente no VANT.
Figura 9: Piccolo e Piccolo Ground Station
50
A configuração visível na Figura 9 é a base na qual este projeto assenta, implementando
uma solução completa de comando de voo do VANT. O Piccolo possui todas as
funcionalidades de hardware (comunicação RF, GPS, etc.) e software de comando e controlo
de voo, pelo que as funcionalidades introduzidas pelos diversos componentes apresentados
neste documento (SEC2, SEP e ETP) irão acrescentar capacidades às funções de comunicação
e de comando e controlo já existentes no Piccolo.
De forma a permitir que capacidades de payload sejam adicionadas aos VANT que
utilizam este piloto automático, o Piccolo disponibiliza (através de uma API própria) um canal
de dados bidirecional sem garantia de entrega denominado de PayloadStream que pode ser
usado por software externo ao próprio para comunicação com o VANT. Todas as
comunicações entre a terra (isto é, a ETP, que se encontra ligada à ETC2) e o VANT (isto é,
o SEC2, que se encontra ligado ao microcontrolador Piccolo instalado a bordo da aeronave)
serão feitas recorrendo ao canal PayloadStream. O facto dos dados enviados por esse canal
não possuírem garantia de entrega é uma característica levada em linha de conta pela
arquitetura. Outra característica a tida em conta é o baixo débito (dados são transmitidos em
pequenos pacotes de 255 bytes) do canal, que poderá dificultar transferências de dados de
tamanho mais elevado (e.g., imagens), daí a existência do módulo Comms Relay.
O Piccolo fornece também outro canal (através da sua API) denominado AutopilotStream
ao qual os componentes acederão para obter informações sobre o estado e telemetria da
aeronave. Para além disso, a API também permite aos módulos o controlo das superfícies de
voo da aeronave (necessário para as manobras de slave to sensor navigation e de sense and
avoid).
3.3.2. Plataformas computacionais
No âmbito deste projeto, são usados dois sistemas computacionais diferentes para
comando e controlo (SEC2) e sistemas embarcados de payload (SEP). O hardware do sistema
computacional baseia-se na norma PC104, tipicamente utilizada em sistemas embarcados, que
apresenta uma relação adequada entre capacidade computacional, consumo energético,
possibilidade de ligação a diferentes periféricos (ou outros sistemas computacionais), massa e
volume.
51
3.3.2.1. Plataforma computacional SEC2
O SEC2 será responsável pelo controlo da trajetória da plataforma, correndo rotinas de
software que, com base na informação previamente processada proveniente dos sensores
instalados, lhe permitirá enviar referências de navegação para os módulos de controlo (e.g.
target tracking), de modo a esta realizar missões como por exemplo o seguimento de alvos ou
vigilância marítima. É também através deste sistema computacional que é estabelecida a
comunicação entre os restantes sistemas/sensores de bordo e a estação de terra de payload.
Figura 10: Plataforma computacional do SEC2
A plataforma computacional SEC2 (Figura 10) possui as seguintes características
principais:
Alimentação: VDC de 5 ou 12 V;
Consumo: Inferior a 10W;
Processador: Intel® Atom™ Dual Core N2600 CPU, 1.60GHz;
Memória: 2GB RAM (DDR3-1066, SO-DIMM204, 1.5V);
Periféricos: VGA, DVI, HDMI, DisplayPort, LVDS;
Entradas/saídas: 2x LAN, 4x SATA 3G, 8x USB2.0, 2x Portas COM RS232;
Bottom-Stacking: PCIe/104 conector tipo 2 (PCIe v1.1);
Form Factor: PCIe/104;
52
3.3.2.2. Plataforma computacional SEP
A plataforma computacional SEP é responsável pela gestão dos sensores a bordo e
respetivo processamento de sinal. Como tal, a capacidade do seu processador, memória RAM
e a placa gráfica integrada são superiores ao do sistema SEC2. Adicionalmente, a placa gráfica
deste componente é compatível com Open Computing Language (OpenCL), proporcionando
desta forma uma camada de abstração que será utilizada para o processamento dos sinais
provenientes dos sensores no seu processador e na placa gráfica.
Figura 11: Plataforma computacional do SEP
A plataforma computacional SEP visível na Figura 11 trata-se de um Leopard (VL-EPM-
35) e possui as seguintes características principais:
Alimentação: VDC de 5V;
Consumo: 21.3W (tip.);
Processador: Intel Core 2 Duo SP9300 (2.26GHz);
Memória: 4GB DDR3-1066;
Periféricos: VGA, LVDS;
Entradas/saídas: 1x LAN, 2x SATA 3G, 6x USB2.0, 5x Portas COM RS232;
3.3.3. Sensores
Os sensores a utilizar no âmbito deste projeto restringem-se a sensores passivos. No
entanto, serão sensíveis a diferentes bandas do espectro eletromagnético, sendo para tal
53
utilizados sensores para o espectro visível, infravermelhos, sensores multiespectrais e ainda
sensores híper-espectrais.
3.3.3.1. Espetro visível
O sensor de espectro visível que será utilizado é a TASE 150. Na realidade, a TASE 150
é um conjunto composto pelo sensor óptico, sistema de posicionamento e orientação desse
mesmo sensor. Este equipamento, fabricado pela Cloud Cap Tecnology, contém em si um
recetor GPS e sensores inerciais que permitem a determinação da sua solução de navegação.
Figura 12: Sensor de espectro visível - TASE 150
A TASE possui ainda dois atuadores mecânicos que lhe permitem mudar a orientação (pan
e tilt) do sensor. Este sistema pode utilizar diferentes sensores ópticos, no entanto, o que será
utilizado será uma câmara SONY FCB-EX1000 com 530 linhas de resolução, um zoom
máximo de 36 vezes e um FOV que varia entre 55.7º e 1.9º.
3.3.3.2. Infravermelhos
De forma a facilitar a deteção de alvos em ambiente com visibilidade reduzida é possível
foram escolhidas alternativas eletro-ópticas a serem equipadas nos VANT. Desta forma, foram
exploradas soluções na gama do infravermelho, com diferentes níveis de sensibilidade por
forma a maximizar o número de alvos captáveis pelo VANT.
3.3.3.2.1. Câmara JAI
A AD-080GE da JAI possui 2-CCD (Charge-coupled device) de área progressiva que
possibilita a captura simultânea do espetro visível e do espectro próximo de infravermelho
54
através do mesmo foco óptico com dois canais individuais. O primeiro canal tem um mapeador
de cor mosaico Bayer que captura a luz visível, enquanto o segundo canal tem um sensor
monocromático para a captura de luz infravermelha.
Figura 13: Câmara JAI
A câmara AD-080GE é projetada em torno dos sensores CCD de varrimento progressivos
Sony ICX-204AK e da Sony ICX-204AL (1024 x 768 pixéis). É capaz de funcionar a 30
frames por segundo em operação contínua. Usando pesquisa parcial, a câmara pode atingir
taxas de renovação mais rápidas de até 85 fps.
De uma forma mais detalhada a AD-080GE tem as seguintes especificações:
Sensor Espetro Visível: 1/3” mosaico de cor Bayer IT CCD;
Near-IR: 1/3” CCD monocromático;
Relógio Pixel: 33.75 MHz;
Frame rate: 30 frames/sec;
Área ativa: 4.76 (h) x 3.57 (v) mm;
Dimensões de célula: 4.65 (h) x 4.65 (v) μm;
Pixéis ativos: 1024 (h) x 768 (v);
Sensibilidade:
o Espectro visível: 0.5 Lux;
o Near-IR: 1.0 μW/cm2 a 800nm;
Saída de vídeo:
o Espectro visível: 30/24-bits RGB ou Bayer output raw;
o Near-IR: 8, 10, or 12-bit;
Temperatura de operação: 5°C to +45°C;
55
Vibração: 3 G (20Hz to 200 Hz XYZ);
Alimentação: 12-24V DC±10%. 7 W;
Dimensões (H x W x L): 55(H) x 55(W) x 98.3(D) mm;
Peso: 320 g.
3.3.3.2.2. Câmara Gobi
A câmara infravermelha Gobi-384 destaca-se pelo seu grande poder de cálculo interno,
mantendo-se um sistema compacto. A câmara oferece um alto grau de flexibilidade através
das de rede IP ou de ligação analógica direta.
Figura 14: Câmara Gobi
O seu funcionamento é na faixa de 8-14 mícrones de comprimento de onda. A Gobi-384
pode detetar diferenças de temperatura de 0,05 ° C. O detetor de 384 x 288 oferece um número
de pixels 44% mais elevado do que outros sistemas baseados na mesma tecnologia de deteção.
A Gobi-384 tem as seguintes especificações:
Lente incluída;
Foco de lente: 18 mm f/1, HFOV 29.9°;
Frame rate: 50Hz a 8 bit ou- 25Hz a 16 bit;
Resolução de conversão A to D: 16 bit;
56
Controlo de câmara: Ethernet (TCP/IP): Xeneth API/SDK, CameraLink: XSP;
Output digital: Ethernet (TCP/IP): 16 bit ou 8 bit, CameraLink: 16 bit base;
Output analógico: PAL ou NTSC;
Consumo: 3.6 Watt;
Alimentação: 12 V;
Temperatura de Operação: 0 aos 50 °C;
Dimensões: 70W x 74H x 65L mm³;
Peso: < 500g (sem lente);
Vibração: 4.5 G (5Hz a 500 Hz).
3.3.3.3. Câmara hiperespetral
Os espetrómetros de imagem ou digitalizadores hiperespetrais funcionam como sensores
de radiação que fornecem uma coleção contínua de imagens espectrais de uma cena não
homogénea, o que permite a obtenção de uma assinatura espectral de cada ponto da imagem.
Esta informação será depois utilizada para tentar reconhecer alvos complexos que não seria
possível detetar de outra forma, como por exemplo manchas poluentes ou substâncias tóxicas
a bordo de embarcações com pouca ou nenhuma visibilidade nos outros espectros.
Figura 15: Câmara hiperespetral
A câmara híper-espectral que irá ser utilizada neste projeto corresponde a uma Rikola
hyperspectral camera e trata-se de um desenvolvimento recente e muito inovador baseado num
57
interferómetro fundado num princípio abry-Perot que disponibiliza um filtro sintonizável e
digitalizador espectral, e deste modo permite de uma forma rápida adquirir imagens do alvo
em várias bandas espectrais adaptadas a esta aplicação. Esta câmara é neste momento
considerada pelo seu fabricante como a mais pequena e leve câmara híper-espectral para
VANT.
As suas principais características físicas são:
Campo de visão horizontal: >50º;
Campo de visão vertical: >37º;
Intervalo espectral por omissão: 500-900 nm;
Resolução espectral mínima 10 nm, FWHM (Full width at half maximum);
Fase spectral: <1 nm;
Abertura óptica: ~ʄ/2,7;
Sensor de imagem: CMV4000;
Frequência de relógio do sensor de imagem: 80MPx/seg;
Dimensão de imagem por omissão: 1024x648 pixéis;
Dimensão máxima de imagem: 2048x1296 pixéis;
Consumo elétrico: <5W;
Peso: <600g;
Dimensões máximas: 80x97x159mm.
3.3.3.4. Sensor AIS
O sistema de identificação automático (AIS) é um sistema de monitorização automático
usado em navios e por serviços de monitorização/controlo de tráfego marítimo para
identificação e localização de embarcações. Desta forma, é obrigatório por lei que
embarcações de dimensão superior a 15 metros possuam a bordo um sistema AIS para trocar
informação relativa à identificação, posição, rumo e velocidade das embarcações próximas da
sua posição. A taxa de atualização da disseminação da informação depende da velocidade de
deslocação do próprio navio e pode variar entre 3 minutos (navios atracados) e 2 segundos
(navios movendo-se a alta velocidade). A informação disseminada por cada embarcação é
adicionalmente recolhida por sistemas de controlo de tráfego marítimo nacionais, localizados
ao longo da costa, ou por sistemas de monitorização por satélite.
58
Figura 16: Sensor AIS
O VANT estará equipado com um recetor AIS que lhe permitirá obter informação relativa
à posição, rumo e velocidade dos navios que se encontrem na mesma zona da sua operação.
As suas principais características técnicas encontram-se descritas abaixo:
Ligação e alimentação via USB ao SEP;
Saída: mensagens NMEA 0183 VDM;
Capacidade de receção de dois canais: Canal A (161.975Mhz) ou Canal B
(162.025Mhz), ou alternar entre os dois;
Ligação à antena: tipo BNC;
Sensibilidade: -110dBm;
Dimensões: 75x23x8mm.
3.3.3.5. ADS-B Receiver
O recetor ADS-B (Automatic depende surveillance-boradcast) utilizado é o modelo GNS
5890 ADS-B Receiver USB-Stick da Global Navigation Systems. Esta é uma tecnologia
cooperativa de vigilância na qual uma aeronave publica periodicamente a sua posição
permitindo que seja seguida. Esta informação pode ser recebida por torres de controlo de
tráfego aéreo e outros veículos aéreos de forma a providenciar informação sobre o panorama
situacional aéreo envolvente e permitir a mudança de rumo para evitar colisões. Este recetor
59
é utilizado a bordo de VANT para que o sistema de sense and avoid possa ter acesso à posição
GPS de outras aeronaves nas proximidades e perceber se se encontram em rota de colisão.
Figura 17: ADS-B receiver GNS 5890
Na Figura 17 podemos ver o ADS-B receiver utilizado, o qual possui as seguintes
características:
Ligação e alimentação via USB ao SEP;
Frequência de funcionamento: 1090 MHz;
Raio de alcance: 300 km;
Dimensões: 61x27x9mm.
60
61
Capitulo 4
Design detalhado do sistema
O sistema está dividido em componentes de bordo e componentes de terra como pode ser
visto na Figura 18. Neste capítulo são especificados os módulos pertencentes a cada um destes
componentes e a sua função. São ainda explicitados os mecanismos de gestão de erros e
monitorização do estado de funcionamento do sistema. Todos os interfaces de comunicação
entre unidades de processamento e entre os subsistemas são também aqui referenciados.
Figura 18: Diagrama de componentes do sistema
4.1. Decomposição do sistema embarcado de
comando e controlo
O sistema embarcado de comando e controlo (SEC2) é o sistema de mais baixo nível em
termos de controlo do comportamento do VANT. Neste sistema encontram-se os componentes
que interagem diretamente com o piloto automático (AP), quer seja pela instrumentação como
modo de comunicação com as estações de terra, quer seja pela capacidade de controlar a sua
operação em termos de voo e/ou controlo de trajetória. No SEC2 encontram-se
62
fundamentalmente dois conjuntos de módulos: módulos de comunicação e módulos de
navegação.
Figura 19: Diagrama de componentes do SEC2
Na Figura 19 é possível observar a especificação de software sobre o ponto de vista das
interações dos componentes, quer internos, quer externos ao SEC2. Ao longo desta secção
serão especificados, em detalhe, cada um dos módulos de forma a apresentar as propriedades
e particularidades de cada um dos componentes deste sistema.
4.1.1. Módulos de comunicação
Os módulos de comunicação surgem na arquitetura de software com a finalidade de
agregar todas as funcionalidades envolvidas no transporte de informação entre as duas
extremidades do sistema, VANT e estações de terra. Estes módulos estão implementados, quer
no sistema embarcado, quer no sistema de terra e o seu funcionamento será muito semelhante,
distinguindo-se apenas na forma de extração dos dados do canal de físico de comunicação: A
bordo do VANT a comunicação entre SEC2 e autopilot é feita através de duas portas de série
enquanto em terra a ETC2 comunica com a ETP através de uma ligação ethernet. Isto verifica-
se porque o Piccolo fornece dois canais de comunicação distintos, sendo eles o
PAYLOAD_STREAM e o AUTOPILOT_STREAM (ver secção 3.3.1), o que leva à
necessidade de dois módulos (Autopilot Driver e Autopilot Comms) para executar a leitura (e
escrita) das portas série correspondentes, fazendo uso da API do Piccolo. Em terra a ETC2
recebe estes dois canais da parte do Piccolo mas já possui capacidades específicas para realizar
o pré-processamento dos dados e fornecer toda a informação através de uma conexão ethernet,
63
sendo utilizado o módulo Autopilot Driver para controlar os dados que circulam entre a ETC2
e a ETP. Este módulo Autopilot Driver tem a mesma implementação tanto em terra como no
VANT contendo, no seu código, instruções condicionais que modificam o seu comportamento
dependendo do caso. Para fornecer (e alterar) estes parâmetros de configuração do módulo é
utilizado um ficheiro de lançamento providenciado pelo ROS chamado de ROSLAUNCH (ver
secção 4.3.3).
Além dos dois módulos já referidos existe ainda um terceiro módulo bastante importante
no âmbito da comunicação que é o Comms Relay. Este módulo também está presente em terra
e no VANT e a sua implementação é exatamente a mesma, sendo completamente agnóstico
em relação ao conteúdo das mensagens em si pois recebe apenas cadeias de bytes, não
conhecendo qualquer forma de os descodificar em informação útil (ver secção 4.1.1.4). Visto
que tanto o Autopilot Driver como o Comms Relay têm a mesma implementação no VANT e
em terra falaremos apenas do seu design a bordo (SEC2) para efeitos de simplificação.
4.1.1.1. Autopilot Driver
O Autopilot Driver é um nó ROS que estabelece uma ligação com o Piccolo (a bordo, via
porta série) e com a ETC2 (em terra via ethernet), traduzindo o protocolo do AP para
mensagens de ROS. Esta tradução oferece a transparência de acesso a todos os sistemas de
bordo que necessitem de interagir com o AP. As principais funções deste componente são:
Receber dados do piloto automático referentes aos seguintes eventos:
o Telemetria – Informação dos diversos sensores do AP (e.g. posição GPS,
velocidade, atitude). Estes dados são consumidos pelos módulos de TT, S&A
e pelo módulo de deteção;
o Estado dos sistemas de navegação – Informação relacionada com parâmetros
de operação dos sistemas de navegação e comunicação do AP. Estes dados são
consumidos pelo módulo Control Supervisor.
Enviar dados para o piloto automático referentes aos seguintes eventos:
o Comandos de baixo nível para controlo de trajetória comandada pelos sistemas
de S2SN e S&A – Estes comandos permitem que os algoritmos de TT e S&A
controlem a trajetória do VANT, dentro dos parâmetros de segurança impostos
pelo Control Supervisor e pelo próprio AP.
64
4.1.1.1.1. Fluxo de mensagens de telemetria do AP
Figura 20: Fluxo de mensagens de telemetria do AP
Uma das funções que é requerida ao Autopilot Driver é a obtenção de dados de telemetria
do VANT que permita fornecer aos sistemas de bordo e de terra, informação do estado do
VANT. A partir da Figura 20 verifica-se a função de tradutor do Autopilot Driver, uma vez
que recebe dados de telemetria em protocolo do AP e transforma-os no formato de uma
mensagem ROS que será publicada para consumo de diversos componentes, sendo eles:
S&A para que, com base na posição/velocidade/direção do VANT possa tomar
decisões que evitem as colisões;
TT para que, com base na posição, velocidade/direção do VANT possa seguir um alvo;
Módulo de deteção para que este possa, por exemplo, georreferenciar as deteções;
Seagull Manager para que este possa, por exemplo, georreferenciar as mensagens de
erro ou eventos;
4.1.1.1.2. Fluxo de mensagens de comando para o AP
Até aqui podemos observar o fluxo de informação a circular do AP para o Autopilot
Driver. No entanto, é possível que a informação possa circular no sentido inverso de modo a
fornecer dados ao AP. Na Figura 21 podemos observar a interação com o AP quando existe a
necessidade de, por exemplo, seguir um alvo ou evitar um obstáculo uma vez que este tipo de
ações implicam que o módulo de TT ou o módulo de S&A tenham de enviar comandos de
baixo nível para o AP, ou seja, comandos que têm influência direta nas superfícies de voo do
VANT. Por exemplo, o comando ‘bank’ faz com que o VANT se incline longitudinalmente
65
de um determinado ângulo, passando a estar controlado pelo módulo que envia o comando.
Ou seja, deixa de executar um plano de voo (definido por waypoints) e passa a executar a
manobra que estiver a ser calculada pelos módulos de navegação (TT ou S&A).
Figura 21: Envio de comandos para o AP
4.1.1.2. Autopilot Comms
O módulo Autopilot Comms surge da necessidade de enviar dados para terra a partir dos
sistemas de bordo do VANT e, uma vez que a bordo não existe o encapsulamento dos dados
em protocolo Piccolo, como acontece na estação de terra (ETC2), apenas se tem acesso ao
canal lógico de PayloadStream do AP através de uma porta série. Os dados são enviados no
formato de origem, sendo estes encapsulados numa mensagem de PayloadStream, do
protocolo Piccolo, pelo próprio AP, sendo posteriormente enviados para terra. Algumas das
características deste canal lógico:
Dimensão dos dados por pacote: cada pacote PayloadStream transporta no máximo
255 bytes úteis;
Baixa Prioridade face aos pacotes de telemetria: os dados do AP com maior prioridade
para circularem no canal de dados são os referentes a comandos manuais de Piloto e
os dados de telemetria e estado do AP. Havendo algum congestionamento no canal o
AP pode descartar pacotes do tipo PayloadStream;
66
Sobrecarga do canal de dados: uma vez que os dados a serem enviados pelo
PayloadStream são do controlo de uma entidade externa ao AP, verificou-se, em
laboratório, que o envio contínuo de dados pela porta série do AP destinada a
PayloadStream pode interferir com as comunicações, podendo provocar,
ocasionalmente, a perda de ligação.
4.1.1.2.1. Fluxo de mensagens via PayloadStream do AP
O AP fornece um “canal” lógico para transporte de informação entre o VANT e os sistemas
de terra. Este canal é materializado através de uma mensagem específica (da API do AP) que
se denomina por PayloadStream. Esta mensagem tem um tamanho limitado a 255 bytes, a
abstração que é oferecida é uma cadeia contínua de bytes que é enviada entre cada uma das
extremidades sendo o empacotamento e o desempacotamento das mensagens feito pelo
sistemas da Cloud Cap Technologies (a bordo o AP e em terra a ETC2). Os sistemas externos
que usem este canal limitam-se a escrever e a ler uma cadeia de bytes.
Figura 22: Mensagens via PayloadStream
67
O papel do Autopilot Comms, como pode ser visto na Figura 22, é traduzir os dados
recebidos nas extremidades e transformá-los numa mensagem do tipo AutopilotPayload, e
vice-versa, que será publicada/subscrita em tópicos ROS consoante o sentido do fluxo de
dados (from_autopilot – do AP para o ROS ou to_autopilot – do ROS para AP). O tópico
from_autopilot será subscrito pelo módulo Comms Relay que irá implementar o protocolo
que garante a fiabilidade de entrega e a fragmentação de dados de maior dimensão (imagens).
Da mesma forma, o tópico to_autopilot é publicado pelo módulo Comms Relay que permite
tratar o envio de dados para terra através do AP.
4.1.1.3. ADSB Driver
O ADSB Driver é o módulo responsável pelo interface entre o recetor ADS-B e o nó de
Sense & Avoid, através da publicação de tópicos ROS. Toda a interação com o recetor é
realizada através deste componente, cuja principal função é converter as mensagens de input,
extended squinter modo S, para mensagens tratadas do tipo ADSBOutput (Figura 23).
Figura 23: Conversão de dados do sensor ADS-B
As mensagens recebidas pelo driver são do formato DF17 e consistem em mensagens 112
bits onde está codificada informação sobre:
Identificação única da aeronave (número de cauda);
Posição GPS – Os dados fornecidos dependem de aeronave para aeronave sendo que
a descodificação é feita apenas a dados de latitude, longitude e altitude
68
O driver tem um comportamento cíclico que permite determinar/descodificar/publicar a
informação relativa à aeronave mais próxima do VANT, a cada instante. Após a publicação
dos dados descodificados, numa mensagem do tipo ADSBOutput, é possível ao nó Sense &
Avoid aplicar a algoritmia de navegação.
4.1.1.4. Comms Relay
O módulo Comms Relay implementa toda a parte lógica da comunicação de e para o
VANT (existindo módulos idênticos a executar no VANT e na ETP), sendo através dele que
qualquer outro componente irá comunicar com o Autopilot Comms (a bordo) e com o Autopilot
Driver (em terra). O Comms Relay garantirá a todos os componentes a bordo as necessidades
de comunicação que o Piccolo não fornece por si, nomeadamente a garantia de entrega de
mensagens, o envio de dados de elevada dimensão e a correção dos dados enviados. O
componente será completamente agnóstico em relação ao conteúdo das mensagens em si
(receberá apenas cadeias de bytes, não conhecendo qualquer forma de os descodificar em
informação útil), providenciando assim uma forma genérica para envio de dados de e para o
VANT, sem que algum dos utilizadores tenha noção quer das características do canal, quer do
protocolo utilizado. De notar que a grande maioria das comunicações de e para oVANT serão
de tamanho muito reduzido (na sua maioria ordens, quer seja de planeamento, quer seja para
seguir um alvo por parte da ETP, ou comunicações de eventos por parte do SEP) com uma
única exceção: o envio de imagens captadas pelas câmaras colocadas a bordo, a pedido da
ETP ou aquando da primeira visualização de um qualquer objeto detetado, serão naturalmente
comunicações mais pesadas em termos de dimensão de dados a enviar.
Este módulo tem um interface bastante genérico para permitir a sua adaptação a qualquer
componente que queira fazer uso dos recursos de comunicação com terra (com garantia de
entrega e fragmentação de mensagens de maior dimensão). A interface é simplista,
equivalendo a um método para envio e receção de dados provenientes ou destinados a cada
uma das extremidades (Figura 22). Assim sendo, existem dois tópicos definidos:
from_comms_relay – Subscrevendo dados que são recebidos e processados pelo
módulo e cuja origem é a extremidade oposta;
to_comms_relay – Onde serão publicados os dados que se destinam à extremidade
oposta via PayloadStream.
69
4.1.1.4.1. Protocolo terra-VANT
O protocolo terra-VANT é a sequência lógica implementada pelo módulo Comms Relay
tendo em vista a garantia de entrega e a fragmentação de mensagens de maior dimensão. Este
protocolo tem como intervenientes os seguintes componentes:
Componente emissor/recetor – É o componente que inicia o processo de envio de dados
para a extremidade oposta ou a quem se destina a informação recebida
Comms Relay – É o componente que abstrai todo o modo de comunicação garantindo
as propriedades já referidas anteriormente;
Autopilot Driver – É o componente que está ligado à ETC2 (em terra) e que tem a
capacidade de encapsular os dados para a API de comunicação fornecida pelo AP;
Autopilot Comms – É o componente que está ligado ao AP (a bordo) e permite receber
e traduzir dados raw para os componentes de bordo;
A interação entre estes componentes é através do Bus de ROS, com a
subscrição/publicação de tópicos conforme se apresenta na Figura 24:
Figura 24: Tópicos envolvidos na comunicação entre extremidades
Na Tabela 2 são apresentados os parâmetros utilizados na configuração do módulo pois é
necessário definir o tamanho máximo de cada fragmento (chunk) em bytes, quanto tempo
deverá o comms relay esperar por um sinal de acknolowdge antes de reenviar o fragmento que
falhou e quantas vezes este processo deverá ser repetido antes de dar a entrega da mensagem
como falhada.
70
Tabela 2: Parâmetros do Protocolo terra-VANT
Parâmetros do protocolo
Nome Tipo Valor Default Descrição
CHUNK_MAX_SIZE uint16 255 Tamanho máximo que cada fragmento de mensagem deve ter
(como o AP tem uma limitação por pacote de 255 bytes limita-
se o tamanho ajustando a este valor)
ACK_TIMEOUT uint16 2 segundos Valor ao fim do qual se reenvia a mensagem por falta de ACK
MAX_TX_RETRIES uint8 3 Número de vezes que deverá ser tentado o reenvio de uma
mensagem sem resposta antes de assumir falha no envio.
No envio das mensagens para a extremidade oposta os dados são encapsulados usando
uma mensagem denominada ReliableMessage cuja estrutura é apresentada na Tabela 3. Esta
mensagem é recebida e enviada pelo módulo Comms Relay que existe em ambas as
extremidades.
Tabela 3: Estrutura da mensagem ReliableMessage
Nome Tipo Unidades Descrição
SOT uint16 N/A Conjunto de caracteres para sincronização da mensagem
(0xABCD)
messageType uint8 N/A Tipo da mensagem:
- (0) RequiresAck
- (1) Ack
- (2) NoAck
messageId uint16 N/A Identificador único atribuído pelo CommsRelay a cada
mensagem
sequence uint16 N/A Número de sequência no total da mensagem – No caso de
mensagens fragmentadas, no caso de mensagens simples o
valor é sempre 1
length uint32 Nº de bytes Tamanho, em bytes, da totalidade da mensagem. No caso de se
tratar de uma mensagem fragmentada cada fragmento terá o
tamanho máximo de CHUNK_MAX_SIZE exceto, eventualmente
o último fragmento que poderá ter um valor inferior.
data uint8[] N/A Dados a enviar, delimitados em tamanho por
CHUNK_MAX_SIZE
crc uint16 N/A Checksum da mensagem inclui todos os campos da mensagem
(exceto CRC) pode ser usado o CRC16-IBM
71
4.1.1.4.1.1. Filas e estruturas de controlo
Para o funcionamento do módulo comms relay são necessárias três tipos de filas:
Fila de receção de mensagens – Nesta fila guardam-se as mensagens recebidas, que
aguardam assemblagem dos fragmentos, para poderem ser entregues ao componente
destino (por exemplo, uma imagem que vai ser recebida no solo é enviada em
fragmentos, como tal têm de ser assembladas)
Fila de envio de mensagens – Nesta fila guardam-se as mensagens que aguardam
resposta da outra extremidade e as mensagens que não requerem confirmação de
receção, mas foram fragmentadas e requerem confirmação de envio.
Fila de despacho – Nesta fila são postas as mensagens prontas para envio sendo a taxa
de despacho tão rápida quanto possível. Pode ser mantida alguma estatística em relação
ao estado da ligação ou taxas de repetições para ajustar o ritmo de envio e/ou os
timeouts (pode-se usar a mensagem CommsParameters para ajustar os valores). Esta
fila será implementada seguindo uma estratégia de prioridades baseada no timestamp
de envio do fragmento. Esta prioridade permite evitar que um fragmento inicial seja
descartado porque foi inserido no fim da fila para reenvio e nunca chega a ser enviado
antes do limite de tempo.
Existe ainda uma estrutura de dados para guardar os meta-dados de gestão do envio das
mensagens que fará parte da fila de envio (Tabela 4). Esta estrutura deverá permitir controlar
timeouts do protocolo:
Tabela 4: Estrutura de controlo de cada fragmento (Chunk)
Nome Tipo Unidades Descrição
sentTimestamp uint64 Unix timestamp Estampilha temporal do momento de inserção na fila
de despacho
ackRetries uint8 N/A Número de tentativas para reenvio
Chunk ReliableMessage N/A Fragmento preparado para envio com formato
ReliableMessage
72
4.1.1.4.1.2. Envio de mensagens
Nesta secção é detalhado o processo de fragmentação e envio de uma mensagem com
destino a terra do ponto de vista do comms relay. Devido ao facto de que se trata de um
processo assíncrono, o envio de mensagens por parte do comms relay é constituído por três
passos importantes:
Envio – Este passo, descrito na Figura 25, inicia-se de cada vez que uma mensagem for
enviada com destino à outra extremidade (e.g. SEP envia uma mensagem com destino a terra).
Assim sendo começa por atribuir um número identificador a cada mensagem recebida e
verifica se esta necessita de garantia de entrega e quantos fragmentos (chunks) ocupa, tendo
em conta que o tamanho máximo por fragmento é de 255 bytes. Os chunks são então colocados
na fila de envio e na fila de despacho, sendo que na fila de despacho serão enviados
imediatamente e removidos da fila, um após o outro, já na fila de envio permanecerão lá até
que seja recebida a confirmação da sua receção em terra ou o seu envio seja dado como
falhado.
Figura 25: Diagrama de envio de mensagem (Comms Relay Callback)
73
Loop – O loop, como o próprio nome indica, consite numa thread a correr infinitamente
com uma frequência de 10 Hz, cuja função consiste em ir buscar o primeiro elemento da fila
de despacho e publicar o mesmo no tópico “to_autopilot”, com destino ao módulo de
comunicação com o AP (Autopilot Comms a bordo e Autopilot Driver em terra). No caso de o
fragmento não necessitar de garantia de entrega é imediatamente marcado como “entregue”
para que possa ser removido da fila de envio.
Figura 26: Diagrama de envio de mensagem (Comms Relay Loop)
Watchdog de envio – Este watchdog monitoriza a fila de envio com uma frequência
de 0.5Hz de forma a verificar quais as mensagens que podem ser removidos da fila de envio.
Assim sendo analisa primeiro a mensagem e verifica se esta necessita de garantia de entrega
e caso não necessite remove a mensagem da fila e passa para a mensagem seguinte caso a fila
não esteja vazia. No caso de a mensagem necessitar de garantia de entrega terão de ser
analisados todos os fragmentos da mesma de forma a confirmar que todos foram entregues.
No caso de o acknowledge do fragmento ainda não ter sido recebido há que levar em conta o
seguinte paradigma, quando um fragmento é enviado é inicializado um contador para detetar
o timeout (ACK_TIMEOUT) da resposta. Quando este timeout é ultrapassado o fragmento
que falhou é reintroduzido no início da fila de despacho de forma a garantir que será reenviado
imediatamente. Ao fim de um certo número de tentativas de reenvio (MAX_TX_RETRIES)
sem receber uma resposta a um fragmento a mensagem à qual pertence deverá ser dada como
74
falhada e, como tal, removida da fila de envio. Note-se que o timeout entre cada tentativa vai
crescendo numa relação de dobro face ao anterior o que quer dizer que o tempo total máximo
que um fragmento pode permanecer na fila de envio, antes da mensagem ser dada como
falhada, é dado por:
∑ (2𝑛 ∗ 𝐴𝐶𝐾_𝑇𝐼𝑀𝐸𝑂𝑈𝑇)
(𝑀𝐴𝑋_𝑇𝑋_𝑅𝐸𝑇𝑅𝐼𝐸𝑆 − 1)
𝑛=0
Equação 1: Tempo máximo de espera, sem resposta, para envio de mensagem
O diagrama apresentado na Figura 27 é então uma representação gráfica do acima descrito.
Figura 27: Diagrama de envio de mensagem (Comms Relay Watchdog de envio)
75
4.1.1.4.1.3. Receção de mensagens
Na secção anterior foi apresentado o processo de fragmentação e envio de mensagens para
a extremidade oposta, por parte do comms relay, pelo que nesta secção será descrito o processo
complementar, ou seja, a receção e assemblagem das mensagens recebidas (Figura 28). O
processo de receção de mensagens por parte do comms relay, tal como o processo de envio, é
também baseado numa fila de receção. As mensagens recebidas são colocadas nesta fila e é
iniciada a análise da mensagem recebida. Após verificar que o parsing da mensagem é
corretamente efetuado, é importante dividir as mensagens entre acknowledges e mensagens de
dados, sendo que no caso de ser um acknowledge o fragmento respetivo é marcado com essa
informação, na fila de envio e, caso o número de fragmentos acknowledged seja igual ao
número total de fragmentos essa mensagem é removida dessa fila. No caso de ser uma
mensagem de dados é necessário enviar o acknowledge correspondente (caso esta necessite)
e, no caso de ser o último fragmento da mensagem, assemblar a mensagem em formato
SeagullPayload e publicar a mesma no tópico “to_comms_relay”.
Figura 28: Diagrama de receção de mensagens do CommsRelay
76
Também à semelhança do processo de envio, é necessário remover as mensagens já
assembladas, e publicadas pelo comms relay, da fila de receção. Este passo é representado na
Figura 29.
Figura 29: Diagrama de monitorização da fila de receção
4.1.2. Módulos de Navegação
Os módulos de navegação agrupam os componentes que têm a capacidade de manipular a
trajetória do VANT através de comandos enviados para o AP. Estes módulos têm três
componentes principais: o control supervisor, o target tracker e o sense and avoid.
4.1.2.1. Control Supervisor
O módulo control supervisor (CS) tem como principal função implementar e aplicar regras
de segurança de voo. Este módulo é muito importante, principalmente quando o VANT está
sob o controlo de um dos módulos de TT ou S&A, uma vez que esse tipo de controlo implica
a interação com o AP através de comandos de baixo nível (Turn Rate, IAS, Heading) ao
contrário do que acontece com o voo por waypoint em que o cumprimento da trajetória é
77
regulado pelos controladores internos do AP. Na Figura 30 podemos ver a interação do control
supervisor com os restantes módulos.
Figura 30: Visão das trocas de mensagens no SEC2 e SEP relacionadas com Navegação
Este componente supervisiona o estado dos sistemas do VANT permitindo implementar
planos de contingência em casos de perda de comunicação com terra (fora dos parâmetros
aceitáveis) ou de alteração anómala de parâmetros do AP. Note-se, por exemplo, quando se
entra num modo de controlo de baixo nível (Slave to sensor navigation, S2SN), algumas
restrições de operação do AP podem ser reescritas pelo sistema que controla as manobras.
Desta forma o Control Supervisor deverá ser um intermediário que filtra os comandos para o
AP.
Um dos mecanismos implementados pelo CS é o controlo de prioridades no envio de
comandos para o AP, modelado como um escalonador de prioridades com ações preemptivas
sobre a interação dos módulos com o AP. Este tipo de escalonamento é representado no
seguinte cenário: o VANT encontra-se num modo de operação Slave to Sensor Navigation,
este modo implica que o módulo de TT controle a trajetória de seguimento do VANT, baseado
nos parâmetros providenciados pelo módulo de Deteção (através do Seagull Manager),
nomeadamente a posição de um alvo de interesse. Considerando que se encontram a operar,
78
em simultâneo, dois VANT, o módulo de S&A assinala a possibilidade de colisão e necessita
de interagir com o AP para iniciar uma manobra evasiva. O CS recebe um pedido do módulo
de S&A para iniciar o controlo do AP, que de imediato interrompe o controlo do módulo de
TT dando lugar ao módulo de S&A. Este procedimento é possível porque em termos de
interação com o AP o módulo de S&A tem uma prioridade mais alta do que o de TT.
Este módulo implementa funções síncronas materializadas pela utilização de serviços de
ROS (Anexo B - Tabela 11 e Tabela 33), como pode ser visto na Figura 31.
Figura 31: Serviços
4.1.2.2. Target Tracker
O sistema de seguimento autónomo de alvos com base em visão recorre a um algoritmo
que tem como parâmetros de entradas a posição do alvo a ser seguido, proveniente do SEP, e
o estado atual da aeronave (posição, velocidade, rumo), proveniente do Autopilot Driver
(Figura 33).
Os dados provenientes do SEP são processados de forma a assegurar: a continuidade na
injeção dos parâmetros do alvo, a estimação de parâmetros adicionais necessários ao sistema
79
de controlo (velocidade e rumo do alvo) e taxa de atualização adequada ao restante sistema de
controlo. A partir destes dados é gerado pelo target tracking controller um caminho circular
de raio pré-definido (loiter), cujo centro coincide com a posição atual do alvo e que se move
solidário com este.
Finalmente, tendo em conta o estado da aeronave, proveniente do Control Supervisor, o
algoritmo de seguimento gera comandos de pranchamento para a aeronave que permitem a
esta convergir para o caminho circular previamente gerado, seguindo desta forma o alvo.
Figura 32: Vista do sistema de seguimento de alvos
4.1.2.3. Sense & Avoid
O módulo de Sense&Avoid que vai estar instalado no SEC2 é responsável pelas seguintes
tarefas:
Deteção de possíveis colisões entre o VANT e outros veículos presentes na sua área
de operação, desde que estes estejam ativamente a difundir a sua posição e os seus
dados sejam recebidos via o recetor ADS-B;
Se existe perigo de possível colisão, envio de comandos de controlo ao módulo Control
Supervisor para que o VANT corrija a manobra e efetue uma rota segura.
Na Figura 33, é visível um diagrama de blocos que permite uma melhor perceção do
funcionamento do módulo de sense and avoid. O recetor ADS-B providenciará os dados
GPS dos veículos aéreos – que emitem este tipo de sinal – nas proximidades do VANT ao
80
algoritmo de evasão de colisões, o qual receberá também telemetria do autopilot de forma
a conseguir comparar a posição da aeronave com a posição dos veículos próximos de si.
Os resultados desta tarefa são enviados para o control supervisor caso exista o risco de
colisão, o qual filtrará estes comandos e irá transmití-los para o módulo de comunicação
com o autopilot.
Figura 33: Diagramas de blocos para o módulo Sense&Avoid
Esta tarefa só emitirá instruções caso haja necessidade, sendo que permanecerá a efetuar
cálculos internos durante o tempo restante, como é visível na Figura 34.
Figura 34: Diagrama de atividade do módulo Sense&Avoid
81
O módulo irá receber mensagens do ADSB Driver, no formato ADSBOutput, dando uso
aos dados de latitude, longitude e altitude. De igual forma o módulo recebe dados de telemetria
do VANT em questão, através do consumo de mensagens do tipo AutopilotTelemetry. Estes
serão os dados base a serem usados para o tratamento de possíveis colisões.
Relativamente aos algoritmos uma das implementações será baseada em (George &
Ghose, 2009), considerando-se que o VANT conhece as posições de todos os outros VANT
de que se quer desviar dentro de uma determinada região (a região do sensor). Consideram-se
VANT com uma restrição cinética do raio mínimo de curva e que todos os VANT voam a uma
velocidade constante e têm o mesmo raio mínimo de curvatura em voo. Serão considerados
grupos homogéneos de VANT, embora o algoritmo possa ser facilmente extensível a um grupo
heterogéneo.
A outra aplicação será um controlador desenvolvido baseado em técnicas de programação
dinâmica (Bellman, 1957), mais particularmente no tópico dos jogos diferenciais de soma zero
com dois jogadores. A programação dinâmica é uma técnica de otimização para sistemas
dinâmicos. Um sistema diz-se dinâmico se o seu estado atual depende dos estados anteriores,
tal como se observa no modelo do movimento da aeronave. A teoria dos jogos diferenciais
estende a teoria de jogos (estáticos) para problemas envolvendo sistemas dinâmicos. No caso
dos jogos diferenciais de soma zero com dois jogadores, o lucro de um dos jogadores (e.g.,
uma aeronave em fuga) será o prejuízo do outro jogador (e.g., uma aeronave em perseguição).
Esta técnica presta-se à resolução numérica deste tipo de problemas, sendo definida uma área
de interdição em torno da aeronave com base em considerações práticas de operação (e.g.,
legislação, fenómenos aerodinâmicos).
82
4.2. Decomposição do sistema embarcado de
payload
O sistema embarcado de payload é o sistema que confere ao VANT a sua capacidade de
visão e deteção. Como podemos ver na Figura 35, este sistema é composto por quatro grandes
módulos: Sensores (frame grabbers e módulo AIS), atuadores, módulo de deteção e seagull
manager. Todos estes módulos deverão trabalhar em conjunto por forma a detetar, identificar
e georreferenciar objetos de interesse. Ao longo desta secção serão especificados em detalhe
cada um dos módulos, de forma a apresentar as propriedades e particularidades de cada um
dos componentes deste sistema.
Figura 35: Diagrama de componentes do SEP
4.2.1. Seagull Manager
O seagull manager tem a tarefa de coordenar as interações entre todos os componentes no
SEP, sendo o módulo central responsável pelas comunicações com o SEC2 e com a ETP (para
os dados de payload). A Figura 36 mostra os principais tópicos ROS subscritos e publicados
pelo seagull manager e a mensagens que por eles circulam.
83
Figura 36: Visão geral das trocas de mensagens entre os módulos relacionados com o Seagull Manager
Para que estas mensagens cheguem à ETP e vice-versa será utilizado o módulo comms
relay do SEC2, o qual permite o envio e receção genéricos de mensagens de cadeias de bytes,
providenciando os mesmos ao autopilot comms que faz a interação com o autopilot Piccolo.
O seagull manager comporá e decomporá as mensagens a enviar e a receber recorrendo à
ferramenta Mavlink (Micro Air Vehicle Communication Protocol), a qual permite a fácil
definição de mensagens, gerando automaticamente funções para a codificação e
descodificação de mensagens de e para cadeias de bytes. De seguida será detalhada a
funcionalidade do seagull manager, contendo as principais interações deste módulo com a
ETP e os módulos do SEP/SEC2.
Sensores
s
Driver/Comms
84
4.2.1.1. Plano de missão
A ETP deverá enviar ao Seagull Manager um plano de missão, contendo o tipo de missão,
a partir do qual será publicada a configuração que os módulos de deteção devem adotar. Este
processo é refletido pela Figura 37.
Figura 37: Diagrama de atividade do plano de missão
O módulo de deteção, ao qual estas configurações se destinam, não faz parte do âmbito
desta dissertação pelo que, na Tabela 5, são apresentados o tipo de missão e o seu número
correspondente. Este número será o comando de configuração enviado do seagull manager
para o módulo de deteção e será da responsabilidade do módulo de deteção a calibração do
seu algoritmo para que se adapte à missão em curso (e.g. aquando de uma missão do tipo
search and rescue o algoritmo deve dar prioridade de deteção a balsas salva vidas em
detrimento de manchas de poluição). É de se notar que, do ponto de vista do Seagull Manager,
logo do SEP, não existe qualquer restrição temporal no envio de planos ou de novos planos.
Cada plano recebido é utilizado em detrimento do atual, não existindo diferença de
comunicação entre o planeamento e o replaneamento.
85
Tabela 5: Definição de missão
Número Tipo
0 Sem Missão
1 Search and Rescue
2 Fiscalização Marítima
3 Fiscalização Marítima (modo furtivo)
4 Monitorização Ambiental
4.2.1.2. Ordem para iniciar/terminar seguimento
A ETP poderá pedir ao SEP a ativação ou desativação do modo Slave to Sensor Navigation
(S2SN) para seguimento de alvos, enviando esse pedido juntamente com o identificador único
desse mesmo alvo (Figura 38). O Seagull Manager, ao receber o pedido, deverá (des)ativar
essa funcionalidade junto do Control Supervisor do SEC2, sendo que, em caso de seguimento,
deverá publicar a posição geográfica desse alvo no tópico “target_location”, tal como dada
pelo módulo de deteção.
Figura 38: Diagrama de atividade de ordem para (não) seguir alvo
86
Todo este processo pode ser visto de um modo mais detalhado na Figura 39, onde se podem
visualizar as interações, chamadas de serviços e trocas de mensagens entre os componentes
relevantes para o modo de seguimento de alvos.
Figura 39: Interações entre componentes no seguimento de um alvo
O Seagull Manager dará, através do serviço requestAction, a ordem ao Control Supervisor
para ativar o modo Slave to Sensor Navigation e enviará, através da publicação da mensagem
TargetLocation no tópico “target_location”, a última posição do objeto a seguir ao Target
Tracker. Caso o módulo TT tenha sido ativado com sucesso, o control supervisor, por sua vez,
enviará o estado do S2SN e o Id do objeto a ser seguido para o Seagull Manager, através da
publicação da mensagem CsStatus no tópico “cs_status”. Após a confirmação de ativação com
sucesso do TT, o seagull manager continuará a providenciar a posição do alvo de cada vez
que a o módulo de deteção forneça uma nova lista de objetos visíveis. Este processo será
repetido até que o modo S2SN seja desativado ou o control supervisor dê prioridade no
controlo da navegação do VANT ao S&A
87
4.2.1.3. Pedido de fotografia de alvo
A ETP poderá pedir ao SEP a obtenção de uma fotografia de um alvo com um determinado
ID, pedido esse que o seagull manager receberá e reencaminhará para o módulo de deteção
(Figura 40). De notar, que embora não seja explicitamente um requisito, arquitecturalmente
nada impede (pelo contrário) a introdução de pedidos genéricos de fotografias, sem alvo
definido, para a obtenção de uma visão do panorama marítimo, ou seja, pedidos de imagens a
um sensor. Aquando de um destes pedidos, o módulo seagull manager, irá enviar uma
mensagem do tipo RequestImage para o módulo de deteção, através da publicação da mesma
no tópico “request_image”. Será então, da responsabilidade do módulo de deteção o envio da
imagem associada ao ID do objeto ou do sensor do qual a imagem foi requerida. A receção da
imagem pedida será assíncrona, pelo que a sua publicação no tópico “to_comms_relay” será
efetuada assim que a imagem seja recebida no seagull manager.
Figura 40: Diagrama de atividade de pedido de uma fotografia de alvo
88
4.2.1.4. Notificação de deteção
Na Figura 41, podemos observar o processo de notificação de deteção de um objeto. Neste
processo o módulo de deteção enviará periodicamente uma lista contendo os objetos visíveis
pelos sensores abordo do VANT e indicará para cada objeto se se trata de um objeto novo.
Figura 41: Diagrama de atividade de notificação de deteção de um objeto
Quando se verificar a existência de um objeto novo na lista, o seagull manager irá enviar
uma notificação de nova deteção à ETP, enviando igualmente o ID do objeto, a sua localização
geográfica, o seu tipo e a sua velocidade no eixo de coordenadas x e y (dados fornecidos pelo
módulo de deteção). Esta notificação incluirá também a posição atual do VANT, proveniente
do autopilot. Após o empacotamento da mensagem mavlink PAYLOADEVENT será enviado
um pedido de fotografia ao módulo de deteção de forma a vir a disponibilizar essa mesma
fotografia à ETP, assim sendo, a fotografia do objeto é recebida assincronamente pelo seagull
manager, logo será também enviada posteriormente para a ETP. No caso de surgirem vários
novos objetos estas ações serão efetuadas para todos eles. A fotografia do objeto será enviada
89
assincronamente pelo que será também enviada posteriormente, assim que seja fornecida ao
Seagull Manager. Quando em modo Slave to Sensor Navigation, o Seagull Manager enviará
periodicamente uma notificação à ETP com a posição atual do alvo e fornecerá a mesma ao
módulo de TT.
Figura 42: Diagrama de sequência de deteção de um objeto
Como pode ser observado na Figura 42, as câmaras enviarão periodicamente imagens do
que estão a “ver” naquele momento para o módulo de deteção, o qual, irá verificar a existência
de objetos nessas imagens. Caso um objeto seja detetado o módulo de deteção deverá guardar
a imagem a ele associado e acrescentar informação sobre o mesmo à lista de objetos visíveis,
a qual será enviada periodicamente ao Seagull Manager através da publicação da mensagem
DetectionList no tópico “detection_list_to_sep”. No Seagull Manager será então verificada a
indicação de existência de novos objetos e, caso existam, será enviada uma notificação de
nova deteção à ETP e o Seagull Manager irá requisitar ao módulo de deteção a fotografia do(s)
novo(s) objeto(s), através da publicação da mensagem RequestImage no tópico
“request_image”. Aquando da receção da fotografia pedida por parte do Seagull Manager,
através da publicação da mensagem DetectionImage no tópico “detection_image_to_sep”, esta
será enviada para a terra.
90
4.2.1.5. Envio de atualização do panorama marítimo
Além do envio de notificações de deteção de novos objetos, o Seagull Manager também
deverá atualizar a ETP sobre as mudanças no panorama marítimo (e.g. mudança de posição
de um barco). Para este efeito existe uma thread que será ativada periodicamente por forma a
atualizar a última lista de objetos visíveis enviada para a ETP, com a lista mais recente enviada
pelo módulo de deteção. Assim sendo, foi criada uma mensagem Mavlink (Object), a qual
conterá informação referente ao identificador de um objeto, o seu tipo, a sua posição e a sua
velocidade. Visto que vários objetos podem ser detetados ao mesmo tempo, será enviada uma
mensagem do tipo Object correspondente a cada objeto visível naquele momento. O seu envio
para a ETP será realizado através do encapsulamento destas mensagens do tipo Object no
campo “data” de uma mensagem SeagullPayload. Antes de inserirmos os objetos no vetor
“data” é inserida uma mensagem mavlink do tipo ObjectList que contém a informação sobre
a latitude e longitude do VANT no momento em que a lista foi enviada e o número de objetos
que estão a ser enviados nesta mensagem SeagullPayload. A Figura 43 exemplifica a
composição de um vetor “data” no caso de envio de uma lista de objetos para terra.
Figura 43: Composição do vetor Data
4.2.1.6. Telemetria de payload
O Seagull Manager deverá enviar periodicamente telemetria indicativa da sua missão atual
e do estado dos seus sensores (Tabela 6), reportando-a para a estação de terra de forma a poder
ser visualizada na estação de terra pelo operador.
Tabela 6: Telemetria de payload
Tipo Parâmetro Descrição
char[150] mission_name Nome da missão em execução
uint8_t mission_type Identificador da configuração de
missão atualmente a ser executada
pelo VANT
91
Tipo Parâmetro Descrição
bool s2sn_status Estado da navegação slave to sensor
navigation
uint8_t s2sn_id O identificador único do objeto
detetado que está a ser seguido
uint8_t tase_status Estado da câmara TASE
uint8_t gobi_status Estado da câmara Gobi
uint8_t jai_eo_status Estado da câmara JAI no espetro EO
uint8_t jai_nir_status Estado da câmara JAI no espetro NIR
uint8_t sensor_ais_status Estado do sensor de AIS
4.2.2. Módulos de Aquisição de Sensores
4.2.2.1. Recetor AIS
O módulo Driver AIS, em tudo idêntico aos módulos análogos das câmaras, será acedido
diretamente através de uma porta série. O Driver AIS publicará periodicamente, com um
período configurável, no tópico ROS “ais_position_report”, a mensagem PositionReport.
Publicará também periodicamente, com um período configurável, no tópico ROS
“ais_static_voyage”, a mensagem StaticVoyage. A mudança entre tópicos dependerá do tipo
de mensagem recebida pelo módulo AIS, como pode ser visto na Figura 44.
Figura 44: Diagrama de atividade do módulo AIS
92
4.2.2.2. Sensores de imagem
Uma vez que todos os módulos do sistema estão assentes sobre ROS é necessário que as
imagens captadas sejam também elas convertidas para mensagens ROS, de modo a que os
módulos (neste caso apenas o módulo de deteção) tenham acesso às mesmas. Assim sendo
foram criados módulos (um por cada câmara) com a funcionalidade de serem “frame
grabbers”, ou seja, o único propósito destes módulos será a captura de frames provenientes
das várias câmaras (recorrendo ao suporte Video4Linux disponível no kernel do sistema
operativo), convertê-los para fomato de mensagem ROS e publicá-los no tópico
correspondente. Todas as imagens serão publicadas em tópicos diferentes de acordo com o seu
espetro e a câmara de onde provêm, sendo o único subscritor de todos estes tópicos o módulo
de deteção. A conversão é assim um passo importante, efetuado com recurso à biblioteca
OpenCV e ao pacote ROS vision_opencv, o qual contém a funcionalidade cv_bridge que
permite a conversão bidirecional entre imagens OpenCV e mensagens ROS, como pode ser
visto na Figura 45.
Figura 45: Conversão de imagens em formato OpenCV para mensagens ROS (RaduBogdanRusu, 2010)
93
Na Figura 46 temos um diagrama de atividade que permite ver o funcionamento genérico
de um frame grabber presente em cada uma das câmaras. Este diagrama é válido para todas
as câmaras presentes no VANT.
Figura 46: Diagrama de atividade de captura de uma imagem
4.2.3. Módulo de deteção
O módulo de deteção é o módulo que incorpora os algoritmos de visão computacional, de
filtragem, de estimação e de decisão. Este módulo receberá as imagens provenientes dos frame
grabbers e utilizará algoritmos para deteção de objetos de interesse. Estes objetos serão
classificados como sendo de interesse através de mensagens de configuração (mensagem ROS
DetectionConfig) que permitem fazer a filtragem conforme o tipo de missão a ser executada.
Será também neste módulo que será mantida uma base de dados de objetos detetados com as
respetivas informações e imagens sobre os mesmos. O módulo de deteção irá providenciar
ciclicamente a lista de objetos visíveis ao Seagull Manager para que este tenha noção do
panorama marítimo atual e possa informar a estação de terra do mesmo. Imagens pedidas por
parte do operador de terra, mesmo que sejam de objetos “antigos” (fora do campo de visão
atual), também serão disponibilizadas por este módulo que fará assim uso da base de dados
para fornecer a imagem pedida. Todas as imagens providenciadas pelo módulo de deteção
serão georreferenciadas pelo que este componente será um subscritor do tópico de telemetria
do Autopilot de forma a conseguir obter as coordenadas do VANT para realizar as operações
94
necessárias para o cálculo da posição do objeto. Este cálculo leverá em conta também (caso
existam) as mensagens de AIS (Automatic identification System) que alguns dos objetos
podem emitir de forma a cruzar informação sobre a posição dos mesmos, pelo que o módulo
de deteção estará em comunicação com o módulo de AIS.
4.2.4. Atuadores
O módulo de atuadores tem como finalidade o controlo da TASE. A TASE é um sistema
de controlo de payload que permite manipular o ângulo de visão e o zoom da câmara acoplada.
É particularmente útil em casos de seguimento de um alvo pois, a configuração dos seus
parâmetros, em conjunto com a telemetria a bordo do VANT, permitem que a câmara
mantenha um ângulo de rotação fixo em relação ao VANT ou então que seja controlada
manualmente ou através de um algoritmo para que o alvo se mantenha no seu ângulo de visão
enquanto o VANT o sobrevoa. Na Figura 47 podemos ver uma pequena amostra do uso da
TASE.
Figura 47: Ilustração das funcionalidades da TASE
Linha de visão Linha de visão
Lin
ha
de
vis
ão
Lin
ha
de
vis
ão
95
4.3. Health Monitoring e Error Handling
Esta secção é destinada à especificação dos métodos utilizados para responder a questões
de verificação do estado atual dos sistemas do VANT (health monitoring) e como tratar e
recuperar de erros (error handling).
4.3.1. Heartbeat
Visto que o sistema embarcado está divido em vários módulos, é necessário garantir que
todos eles estão operacionais ao longo do tempo de execução da missão, pelo que foi criada a
mensagem SeagullHeartbeat. Esta mensagem é enviada periodicamente (1Hz) e é composta
apenas por um campo (Node), que identifica o nó que emitiu a mensagem, dando assim a
conhecer ao sistema que este nó se encontra “vivo” e um cabeçalho que contém, entre outros
campos, um timestamp. A mensagem SeagullHeartbeat será publicada no tópico
to_sep_heartbeat e no tópico to_sec2_heartbeat. A publicação e subscrição destes tópicos por
parte dos módulos pode ser vista na Tabela 10 e Tabela 32. Caso algum nó interrompa a
emissão de mensagem Heartbeat durante um período de timeout (5s), será detetada a falha no
mesmo, este será reiniciado (ver secção 4.3.3) e o erro reportado para terra.
4.3.2. Error Handling
Visto que o VANT não dispõe de nenhum módulo de tratamento de erros, cabe ao seagull
manager no SEP e control supervisor no SEC2 a deteção de erros e o envio da respetiva
mensagem de erro para terra. Existem dois tipos de tratamento de erros distintos embora sejam
reportados através da mesma mensagem.
4.3.2.1. Keep Alive Error Handling
Este tipo de tratamento de erros faz uso do heartbeat por forma a ter conhecimento de
qualquer módulo que por alguma razão não esteja a funcionar (não está a transmitir o sinal de
heartbeat). Visto existirem dois sistemas computacionais distintos (SEC2 e SEP) todos os nós
presentes no SEC2 serão monitorizados pelo nó control supervisor e todos os nós presentes
96
no SEP serão monitorizados pelo nó seagull manager. Por forma garantir que todos os nós
estão a ser controlados, o control supervisor irá estar responsável por monitorizar o seagull
manager e vice-versa. Aquando da deteção de não funcionamento de um nós o seagull
manager ou control supervisor devem identificar qual o módulo afetado e contruir uma
mensagem mavlink PayloadError, a qual é enviada para terra. Este envio para terra será sempre
feito pelo seagull manager, excepto se a falha for nesse nó, situação na qual será o control
supervisor a enviar a mensagem de erro para terra (apenas neste caso terá esta capacidade). O
nó afetado deverá então ser reiniciado para retomar o normal funcionamento do VANT.
4.3.2.2. Payload Error Handling
Além de erros keep alive existem também erros de payload (e.g. pedido de fotografia de
um objeto que não existe). Estes erros são reportados pelo nó que coordena as interações entre
todos os componentes no SEP (Seagull Manager) através da mensagem mavlink PayloadError.
Além do erro, a localização do VANT é também enviada.
4.3.3. Roslaunch
Todos os nós em execução no VANT, tanto no SEP como no SEC2, estão dependentes do
mesmo MASTER NODE (roscore), estando este a ser executado na plataforma computacional
SEC2. Deve ser tido em atenção que os nós apenas dependem do master para serem iniciados,
pois, mesmo que este falhe, os nós continuam a comunicar entre si. No entanto, como já foi
referido os nós podem ter a necessidade de serem reiniciados e para isso necessitam que o
master esteja ativo. Na situação de o sistema estar em funcionamento e o master falhar e ser
reiniciado, todos os nós deverão ser reiniciados também. Este cenário é necessário porque após
a reinicialização do master, os nós que estavam a correr continuam, mas qualquer nó que seja
iniciado posteriormente à reinicialização do master não terá qualquer maneira de contactar
com os nós iniciados antes da reinicialização. Daqui advém a necessidade de ao reiniciar o
master, todos os nós serem reiniciados também por questões de comunicação entre eles.
Visto ser necessário iniciar vários nós, é utilizado um método providenciado pelo ROS
chamado roslaunch que permite o lançamento organizado de vários nós e do próprio roscore.
Este método permite também definir que os nós reiniciarão após morrerem por qualquer razão.
Visto que teremos nós a correr em ambas as máquinas utilizaremos um único roslaunch que
97
possui o username e a password do SEP por forma a lançar os nós desse sistema
computacional a partir do SEC2. O controlo do master será feito através da monitorização do
seu PID, utilizando um script que verifica periodicamente se o PID do master ainda existe e,
na sua ausência matará todos os processos ROS, reinicializará o master e lançará de novo o
roslaunch iniciando assim todos os nós do sistema.
Em caso de reinicialização do SEC2, o script já explicitado irá correr no arranque pelo que
matará todos os nós e iniciará um processo “limpo”. No caso de reinicialização do SEP é
necessário que SEC2 tenha a perceção que o SEP foi reinicializado. O Script já implementado
para monitorizar o PID do Master irá também monitorizar a resposta de um processo de “ping”
ao SEP e efetuará um arranque “limpo” do Master e de todos os nós em caso de falha.
4.4. Decomposição da estação de terra de payload
A estação de terra de payload é o componente de terra que permite a visualização, por
parte de um operador, de todos os dados referentes a telemetria de payload (e.g. estado dos
sensores, missão em execução, etc.), sendo também esta estação que contém as opções de
envio de comandos para o VANT (e.g. definição de missão a executar, início/cancelamento
de seguimento de alvo, etc). Esta estação terá também interação com o ROS para mais
facilmente comunicar com o VANT, como ilustrado na Figura 48.
Figura 48: Diagrama de componentes da ETP
98
A ETP foi implementada em Java utilizando Eclipse RCP e deverá ser composta por
componentes, os quais devem agregar funcionalidades, permitir algum isolamento de
implementação e integrarem-se entre si, de forma a fornecer a ETP como um único sistema.
A Figura 49 apresenta os componentes de software especificados para a ETP, os quais serão
detalhados nas secções seguintes.
Figura 49: Componentes de software da ETP
4.4.1. Core
O componente “core”, ilustrado na Figura 50, representa as features base da ETP em si,
sendo independente da implementação específica da sua interface gráfica (GUI). Assim,
deverão fazer parte do core quaisquer componentes relativos a comunicações (e respetivos
interfaces), algoritmia, funcionalidades do sistema e de suporte, bem como definição dos tipos
de dados utilizados.
99
Figura 50: Modelo de classes Core
4.4.1.1. Communications
Nesta secção deverão ser especificadas as interfaces entre a ETP e os sistemas externos,
sendo este o módulo responsável pela implementação dos protocolos e interfaces de
comunicação distintos entre a ETP e as entidades com que esta interage.
Figura 51: Diagrama de classes Communications
O módulo de comunicações será assim responsável pelas funcionalidades de comunicação
da ETP GUI, servindo como ponte entre a aplicação em si e os interfaces de comunicação
apresentados nesta secção.
100
Entre estas funcionalidades incluem-se:
O controlo de intervalos e ciclos de envio e receção de mensagens;
A receção de todos os resultados, status, telemetria e dados de diagnóstico relevantes;
O envio das missões e comandos de execução ou cancelamento (nomeadamente vindos
do SISOM);
A implementação de mecanismos de controlo dos IDs diferentes, garantindo o envio e
receção de dados para os VANT adequados.
4.4.1.1.1. ETP-ROS Interface
Este módulo será responsável por todas as interações da ETP com a ETC2 e VANT,
utilizando os métodos definidos na Figura 52.
Figura 52: ETP-ROS Interface
Fornecerá aos restantes componentes as seguintes funções genéricas:
Receção de mensagens do VANT (SEP – Seagull Manager) recorrendo ao método
genérico disponibilizado pelo Comms Relay. Os conteúdos principais dessas
mensagens serão fotografias e eventos de notificação de deteção de alvos.
101
Envio de mensagens para o VANT (SEP – Seagull Manager) recorrendo ao método
genérico disponibilizado pelo Comms Relay. Os conteúdos principais dessas
mensagens serão a definição de missão, pedidos para seguir (e deixar de seguir) alvos
e pedidos de fotografias de objetos detetados.
Receção da telemetria Autopilot (Piccolo) de forma a poder mostrar ao utilizador onde
o(s) VANT(s) se encontra(m) e monitorizar a missão.
Listagem, criação e remoção dos waypoints que compõem o plano de voo na ETC2,
plano esse que será gerado pelo operador de payload e/ou pelo SISOM e que consistirá
num conjunto de waypoints a serem enviados para a ETC2 como plano de voo
sugerido.
Este módulo é então responsável por implementar o interface entre a aplicação GUI como
um todo e os restantes componentes do sistema, em particular com a ETC2 (e com o SEP,
indiretamente). Para tal, é este o único componente do GUI que conhece as mensagens ROS
que circulam no bus ROS da Ground Station bem como as mensagens Mavlink trocadas entre
si e o VANT (em particular com o módulo Seagull Manager em execução no SEP). As
mensagens trocadas com o SEP e as mensagens trocadas na ETP e entre a ETC2 e a ETP
encontram-se especificadas no Anexo C.
É de se notar que tanto a definição das mensagens ROS como das mensagens Mavlink
utilizadas são comuns a todo o projeto (i.e., tanto à ETP como SEP e SEC2), sendo as próprias
estruturas de código utilizadas geradas pelas respetivas ferramentas (ROS e Mavlink para Java,
no caso da ETP).
É também de registar que toda a utilização do ROSJava é assíncrona, não existindo a
possibilidade da utilização de métodos síncronos (serviços ROS) recorrendo ao ROSJava.
As subsecções seguintes descrevem os métodos principais deste componente. Todos os
métodos que não se referem a callbacks da subscrição de tópicos ROS possuem um parâmetro
de entrada que define o identificador único do veículo sobre o qual a operação deverá ser
realizada; a razão da necessidade desse identificador é simples: o ETP ROS Interface
conseguirá lidar com um ou mais VANT, necessitando por isso de identificar de, forma única,
cada um dos VANT.
DefinePlan Este método define um novo plano de voo, escolhendo um tipo de missão a executar para
ser enviado posteriormente para execução no VANT, enviando para tal a configuração
102
necessária de payload para o SEP. Em suma, este método executa o encapsulamento de uma
mensagem MissionDefinition numa mensagem SeagullPayload com os dados da missão.
RequestSensorImage Este método requisita ao VANT que seja enviada uma fotografia de um sensor específico.
Para tal, a ETP constrói uma mensagem RequestImage do tipo Mavlink para esse efeito, e
envia a mesma através de uma mensagem ROS SeagullPayload. Após o envio desta
mensagem, é esperado que o VANT venha a responder com a fotografia pedida através da
mensagem respetiva.
RequestObjectImage Este método requisita ao VANT que seja enviada uma fotografia de um objeto específico.
Para tal, a ETP constrói uma mensagem RequestImage do tipo Mavlink para esse efeito e envia
a mesma através de uma mensagem ROS SeagullPayload. Após o envio desta mensagem, é
esperado que o VANT venha a responder com a fotografia pedida através da mensagem
respetiva.
ActivateSlaveToSensorNavigation
Este método requisita ao VANT que este comece a seguir o objeto indicado, recorrendo
para tal ao envio de uma mensagem FollowTarget encapsulada numa mensagem
SeagullPayload. A ativação desta funcionalidade por parte do VANT será visível através dos
campos relativos ao SlaveToSensorNavigation presentes nas mensagens de telemetria do
Payload.
DeactivateSlaveToSensorNavigation Este método requisita ao VANT que desative a funcionalidade de Slave To Sensor
Navigation, recorrendo para tal ao envio de uma mensagem FollowTarget encapsulada numa
mensagem SeagullPayload. A desativação desta funcionalidade por parte do VANT será
visível através dos campos relativos ao SlaveToSensorNavigation presentes nas mensagens de
telemetria do Payload.
RequestWaypoints
Este método requisita ao piloto automático que envie para a ETP o plano de voo atualmente
em execução pelo VANT, sobre a forma de uma lista de todos os waypoints existente na ETC2.
103
O envio desta mensagem tem associada uma resposta de diversas mensagens (uma por
waypoint) no callback descrito em 0, às quais se segue a mensagem recebida no callback
descrito em 0.
DeleteWaypoints Este método envia uma sugestão de atualização do plano de voo atual, solicitando ao piloto
automático que remova um determinado conjunto de waypoints, enviados sobre a forma de
uma lista de identificadores dos waypoints a remover.
InsertWaypoints
Este método envia uma sugestão de atualização do plano de voo atual, solicitando ao piloto
automático que acrescente um determinado conjunto de waypoints, enviados sobre a forma de
uma lista de identificadores dos waypoints a acrescentar, seguido de mensagens individuais
com os detalhes de cada um.
UpdateWaypoint Este método envia uma sugestão de atualização de um waypoint individual do plano de
voo atual, solicitando ao piloto automático que altere os parâmetros desse mesmo waypoint,
enviando uma mensagem com os detalhes e valores a atualizar.
SwitchFlightPlan
Este método envia uma sugestão de mudança do plano de voo em vigor, fazendo track
para um waypoint pertencente a uma gama de um plano de voo que não está a ser usado. É
solicitado ao piloto automático um comando do tipo “track”, que indica uma mudança de
trajetória para o waypoint requisitado, sendo que a disponibilização desta funcionalidade
deverá estar limitada a restrições (p.ex. credenciação de utilizador).
SendHeartbeat Este método envia ciclicamente uma mensagem (sem conteúdo particular para além do
timestamp) para o VANT, para que o SEP consiga verificar que a ETP se encontra operacional.
Esta mensagem segue encapsulada numa mensagem SeagullPayload.
104
SendDmDebug
Este método é definido para funcionalidades de suporte aos testes e desenvolvimento, não
sendo portanto um método principal da interface.
Através da definição de uma mensagem com vários parâmetros em aberto para poderem
ser usados conforme conveniente (para afinação de algoritmos, câmaras e afins) pelo módulo
de deteção que executa no SEP.
Esta mensagem segue encapsulada numa mensagem SeagullPayload, existindo também
uma mensagem igual, que é recebida no sentido inverso (do SEP para a ETP no callback de
SeagullPayload), que permita assim ler e apresentar na GUI valores dos parâmetros referidos.
SubscriberCallbackSeagullPayload Este componente subscreve o tópico ROS from_comms_relay, sendo este o método
invocado aquando da chegada de uma nova mensagem nesse tópico.
Ao ser recebida uma nova mensagem, o módulo descodificará o seu conteúdo recorrendo
ao Mavlink, conteúdo esse que poderá ser qualquer mensagem definida no Anexo C –
Interfaces terra-ar nas mensagens Mavlink aí definidas (que circule no sentido da ETP).
SubscriberCallbackAutopilotTelemetry
Este componente subscreve o tópico ROS autopilot_telemetry, sendo este o método
invocado aquando da chegada de uma nova mensagem nesse tópico.
Ao ser recebida uma nova mensagem, o módulo notificará o resto da aplicação de forma
que esta se atualize com os novos dados de telemetria recebidos e também que esses mesmos
dados sejam encaminhados para o interface com o SISOM.
SubscriberCallbackAutopilotWaypoint Este componente subscreve o tópico ROS autopilot_waypoint, sendo este o método
invocado aquando da chegada de uma nova mensagem nesse tópico.
As mensagens recebidas neste callback representam os detalhes de cada waypoint
individual existente na ETC2.
SubscriberCallbackAutopilotWPList
Este componente subscreve o tópico ROS autopilot_wp_list, sendo este o método
invocado aquando da chegada de uma nova mensagem nesse tópico.
105
As mensagens recebidas neste callback representam a lista de todos os waypoints
existentes na ETC2.
SubscriberCallbackAutopilotStatus Este componente subscreve o tópico ROS autopilot_status, sendo este o método invocado
aquando da chegada de uma nova mensagem nesse tópico.
Ao ser recebida uma nova mensagem, o módulo notificará o resto da aplicação de forma
que esta se atualize com os novos dados de posição de waypoints recebidos (origem e destino)
e também que esses mesmos dados sejam encaminhados para o interface com o SISOM.
4.4.1.1.2. SISOM Interface
A ETP é capaz de receber do SISOM as missões e comandos de execução ou
cancelamento, e de enviar os resultados, estados dos meios e outros dados de diagnóstico
relevantes. Esta comunicação com o SISOM, no âmbito desta dissertação, será meramente
uma prova de conceito pelo que a ETP apenas exportará situational reports (sitreps) para que
sejam utilizados por um web service confirmando assim esta capacidade, ou seja esta interface
será constituída apenas pelo método ExportSitrep.
4.4.1.2. DataTypes
Este componente deverá conter a definição dos tipos de dados comuns aos restantes
componentes da ETP que farão utilização dos mesmos para implementar as suas
funcionalidades. São assim um agregador comum dos principais tipos de objetos utilizados na
ETP (sob a forma de classes Java).
Figura 53: Classe Datatypes
106
4.4.1.3. Payload
Representa a algoritmia e funcionalidades relativas à missão em si, nomeadamente a
configuração de parâmetros e a sua definição, bem como a interpretação dos dados de missão
(telemetria e eventos/alertas), a partir dos quais a monitorização na aplicação da ETP é
atualizada.
Figura 54: Diagrama de classes Payload
4.4.1.4. Payload Monitoring
Este componente será responsável por funcionalidades de configuração e monitorização
de payload.
4.4.1.4.1. Configuração
No que toca a configuração, este componente será responsável por funcionalidades de
definição de missões, em particular:
Implementar o processo de configuração e preparação de missão apresentado ao
operador, despoletado por um botão da GUI “Definir Missão”;
Notificar quando houver uma missão nova enviada pelo SISOM, e implementar o
processo de importação despoletado por um botão da GUI “Importar Missão”. A ação
de importar missão resultará num processo igual ao de “Definir Missão”, onde os dados
vêm já pré-definidos com os valores recebidos do SISOM;
Preparar e enviar a definição de missão para o VANT, despoletado por um botão da
GUI “Enviar Missão para execução no VANT”;
107
Suportar o processo de envio de alterações de plano de missão, despoletado por um
botão da GUI “Enviar plano de missão” e operando em conjunto com as ferramentas
de criação de pontos;
Um screenshot exemplificativo do processo de definição de missão suportado por este
componente é ilustrado na Figura 55, apresentando o painel GUI associado:
Figura 55: Definição de missão
Após a definição de missão, esta passará a constar da lista de missões disponíveis na
aplicação, tal como ilustrado na Figura 56:
Figura 56: Lista de missões
Assim, será possível selecionar a missão que foi definida, e enviá-la para execução no
VANT, tal como ilustrado na Figura 57:
108
Figura 57: Envio de execução de missão
4.4.1.4.2. Monitoring
No que toca a monitorização, este componente será responsável pelas várias
funcionalidades de monitorização de missão. Após enviar uma missão para execução, a ETP
fará a sua monitorização contínua através de visualização no ecrã de vários dados:
Estado do VANT (Em execução/offline/etc.);
Dados de telemetria enviados periodicamente durante missões em execução;
Atualizações mediante a informação da missão em execução (posição do VANT e
eventos/erros);
Estas capacidades de monitorização e diagnóstico deverão ser disponibilizadas de forma
visual, nomeadamente através de mecanismos como tabelas, mapas e pop-ups, apresentando
os eventos e telemetria.
A ETP deverá também gerar Situation Reports (“sitreps”) ciclicamente, a partir da
informação recebida do VANT, para serem enviados para o SISOM.
A interpretação dos dados que chegam do VANT, o seu processamento e propagação para
representação visual na GUI, são assim da responsabilidade deste componente.
109
Seguindo o processo de definição e envio de missão para execução descrito na secção
4.4.1.4.1, será então recebida a indicação de que a mesma se encontra em execução, aquando
da receção e processamento da telemetria de payload por parte do módulo de monitorização.
Esta informação será assim apresentada na GUI, como ilustrado na Figura 58:
Figura 58: Monitorização de missão em execução
O módulo de monitorização garante também que a GUI apresenta todos os eventos ou
erros despoletados pelo VANT, como ilustrado na Figura 59:
Figura 59: Monitorização de erros e eventos de payload
A Figura 60 ilustra um exemplo de alguma informação apresentada para monitorização na
GUI sobre a vista de mapa, desde o estado do VANT (a verde na barra de topo), até à sua
posição (estrela), os waypoints do plano atual (círculos vermelhos), ou os erros ocorridos mais
recentemente (cruzes, apresentadas em elevado número na figura, dado o estado ser o mesmo
que foi utilizado para ilustrar a monitorização de erros na Figura 59).
110
Figura 60: Vista de mapa – Monitorização
4.4.1.5. Support
Para implementar todas as funcionalidades necessárias, a ETP GUI (ou seja a própria
aplicação Eclipse RCP) necessita de vários componentes de suporte. Este módulo representa
esses componentes de suporte à aplicação GUI.
Figura 61: Diagrama de classes Support
111
Configuration
Este componente será responsável pelos parâmetros de configuração da aplicação,
unificando todos num ficheiro único (config.properties), e implementando o seu carregamento
dinâmico sobre a forma de propriedades com valor, a serem utilizados pela aplicação.
Assim, o utilizador poderá definir num só ficheiro todos os parâmetros relevantes à
aplicação, desde dados configurações de rede, diretórios de logs, intervalos/períodos de ciclos
e comunicação, e outros valores afins.
Database
Este componente será um gestor dos dados persistentes associados à aplicação. Ao longo
do ciclo de vida, diversos tipos de dados poderão ser exportados e/ou importados, quer
ciclicamente nalguns dos casos, quer a pedido nos outros. Será a partir desta funcionalidade
que se garante algum nível de persistência aplicacional, na medida em que se a aplicação
terminar, deverá ser possível importar os dados previamente exportados e repor um estado
semelhante ao que estava em execução.
Logging
Este componente deverá ser responsável pelo logging de execução e relatórios de erros da
ETP, suportando um modo “Normal” e um modo de “Debug” com diferentes níveis de registo
de informação.
4.4.2. GUI
Representa a aplicação da ETP em si, que interage com as várias entidades (diretamente
com o utilizador), e fornece uma plataforma visual para a maioria das funcionalidades e
capacidades de monitorização.
112
Figura 62: Modelo de classes GUI
A GUI é composta por vários componentes Eclipse RCP (vistas, menus, barras de
ferramentas, etc.).
A disposição das telas no ecrã da aplicação deverá ser reorganizável pelo utilizador.
Deverá ser disponibilizado um botão ou função de menu para “Repor originais”.
4.4.2.1. Actions
Este componente implementa todas as ações da aplicação GUI através de ações RCP. Nele
estará contido o código para execução de todo o tipo de funcionalidades GUI, tais como premir
de botões, ações dos menus e barras de ferramentas.
Será a partir da chamada a estas ações que serão chamadas as funções dos módulos do
Core da aplicação (com eventuais apresentações e preenchimentos de caixas de diálogo ou
semelhantes durante o processo, como exemplificado na Figura 63).
Figura 63: Exemplo de ação da GUI
113
4.4.2.2. Advisors
Módulo que implementa os advisors, elementos necessários a qualquer aplicação Eclipse,
responsáveis por popular, suportar e controlar o ciclo de vida dos elementos da GUI.
4.4.2.3. Perspectives
Este módulo implementará a perspetiva única Eclipse RCP existente na aplicação da ETP.
A perspetiva é gerada sobre a janela principal de aplicação, e sobre ela organizam-se várias
sub-janelas denominadas por vistas. Assim, a aplicação da ETP deverá ser implementada sobre
uma única perspetiva Eclipse RCP (é suficiente e adequado para o que se pretende da
aplicação), composta por várias vistas para cada grupo de funcionalidades.
Estes componentes da GUI são complementados por barras de ferramentas e menus
“standard”, semelhantes ao que é uso comum em aplicações informáticas.
4.4.2.4. Views
Este módulo implementará as várias vistas Eclipse RCP (vistas de Missão, Mapa,
Navegação Telemetria e Payload) da perspetiva única existente na aplicação da ETP.
As várias vistas dispostas sobre uma perspetiva única (exemplificadas na Figura 64)
poderão assim ser selecionadas, redimensionadas, fechadas ou alternadas, resultando numa
apresentação da GUI adaptada às necessidades particulares do operador de Payload.
114
Figura 64: Perspetiva única e vistas da GUI
4.4.3. Data
Associada à aplicação que executa, existirá a necessidade de ter uma estrutura de diretórios
do sistema nos quais são guardados os dados do seu ciclo de vida, desde a informação
persistente (ver secção 4.4.1.5 – Database), a ficheiros de configuração a carregar no arranque
e às imagens que vão sendo recebidas durante a execução.
Assim, esta classe não representa um módulo de código propriamente dito, mas sim a
estrutura de diretórios e os respetivos dados utilizados pela aplicação, que estarão associados
a um diretório principal cuja raiz deverá ser dada à aplicação através do ficheiro de
propriedades (ver secção 4.4.1.5 – Configuration).
115
Figura 65: Modelo de classes Data
Log Neste diretório serão colocados os ficheiros de log gerados pela aplicação, originados pelo
módulo respetivo (definição na secção 4.4.1.5 – Logging).
Maps Neste diretório serão colocados os mapas a serem utilizados na aplicação.
Este diretório deverá assim conter mapas no formato a ser utilizado pela aplicação da ETP
– raster file (bmp/tif) + layers e metadata (shapefiles).
Este servidor será acedido a partir da aplicação da ETP, a qual tem uma funcionalidade
para configurar a sua parametrização e selecionar um mapa entre os disponíveis.
Missions Neste diretório serão criados subdiretórios para as várias missões definidas na aplicação,
e em cada um serão guardadas as imagens recebidas durante a execução dessa mesma missão.
Adicionalmente, poderá conter um xml, exportado pelo módulo de Database (descrito em
4.4.1.5 – Database), que terá a lista de todas as missões e os seus parâmetros, para que possa
ser carregado por outra instância da aplicação, no caso de ser reiniciada.
116
SitReps Neste diretório são guardados os SitReps (Situational Reports) gerados pela aplicação,
com um timestamp no nome do ficheiro para indicar a data desse mesmo Sitrep.
Estes ficheiros servirão quer para repor um estado “aproximado” da aplicação caso esta
seja reiniciada (através da sua importação), quer para exportar para o SISOM.
VANT Este diretório deverá conter ficheiros xml com a configuração dos VANT disponíveis que
deverão ser monitorizados e que poderão ser utilizados para executar missões pela aplicação.
Poderão existir vários ficheiros para configurações diferentes, pois a aplicação irá processar
apenas um, carregado na sua inicialização, que deverá ter como nome “vantConfig.xml”.
117
Capítulo 5
Implementação, resultados e testes.
Neste capítulo serão apresentados aspetos relacionados com a implementação do sistema
já descrito, resultados e os testes efetuados.
5.1. Implementação
5.1.1. Estrutura de um módulo ROS
A implementação de todo o sistema foi efetuada de acordo com a descrição detalhada presente
no Capitulo 4 e tendo em conta todas as interfaces definidas no Anexo B – Interfaces a bordo
e no Anexo C – Interfaces terra-ar. Devido à grande importância do midleware ROS na
arquitura deste sistema é apresentada a estrutura sobre a qual foram constituídos todos os
módulos ROS que compõem este sistema, utilizando três ficheiros principais, dois ficheiros
fonte (Figura 66 e Figura 67) e um ficheiro de cabeçalho (Figura 68).
Figura 66: Função main de um módulo
A Figura 66 representa o ficheiro principal de cada módulo, contendo a função main que
irá inicializar o mesmo, atribuindo-lhe o nome pelo qual ele será reconhecido no sistema
118
através do ROS. O método setup é chamado após a criação de um objeto da classe do módulo
em questão para que possam ser aplicadas as configurações necessárias a cada módulo, sendo
depois chamado o método loop, o qual se encontra dentro dum ciclo while que irá correr até
que o módulo receba ordem para desligar. A frequência com que este método é chamado é
variável e pode ser alterada de módulo para módulo conforme as necessidades específicas de
cada um.
Na Figura 67 podemos ver a implementação dos métodos mais utilizados por todos os
módulos do sistema. Tal como observado na figura anterior, temos o método setup e loop,
sendo que o primeiro executa a chamada de outros métodos de setup que visam a leitura de
parâmetros de um ficheiro de lançamento, a declaração de publishers, subscribers e serviços
ROS e a inicialização da emissão de heartbeat por parte do módulo em questão. É também
possível observar nesta figura o método de publicação de mensagens para um tópico,
utilizando o publisher previamente declarado, a forma de tratar mensagens recebidas no tópico
subscrito (através de uma função callback), a chamada a um serviço providenciado por outro
módulo e o handler utilizado aquando de uma chamada ao serviço disponibilizado por este
módulo.
119
Figura 67: Ficheiro fonte de um módulo (Implementação de métodos)
Na Figura 68 está exemplificado o ficheiro de cabeçalho genérico de um módulo do sistema,
sendo aqui que se encontra a declaração da classe, dos seus métodos e das suas variáveis. É
também neste ficheiro que são definidas todas as constantes e são incluídos os serviços e
mensagens utilizados pelo módulo.
120
Figura 68: Ficheiro de cabeçalho
5.1.2. Script de arranque automático do sistema
Esta organização dos ficheiros e o seu conteúdo é transversal a todos os módulos
implementados, variando ligeiramente conforme as necessidades específicas de cada um.
Tal como discutido na secção 4.3.3, foi também implementado um script de arranque
automático, em bash, que executa a configuração de todas as variáveis de ambiente
necessárias, inicia o sistema e monitoriza o seu estado. O script é apresentado na Figura 69 e
é corrido no arranque da máquina SEC2.
121
Figura 69: Init script
122
As principais funções deste script são a configuração das variáveis de ambiente, o controlo
do estado do ROS master e o controlo do estado de funcionamento do SEP. No contexto das
variáveis de ambiente é definida a ROS_MASTER_URI que representa o local onde os
módulos ROS podem encontrar o ROS master (processo que controla o registo dos módulos
e a sua comunicação) e é também definida a variável ROSLAUNCH_SSH_UNKNOW, a qual
permite que o processo de lançamento automático do ROS aceite hosts desconhecidos no
processo SSH, visto ser esta a forma utilizada para o lançamento de nós em outras máquinas.
O controlo do estado do ROS master permite também um controlo do estado da máquina
SEC2, uma vez que caso esta máquina reinicie, o processo ROS master não estará disponível
e como tal será feita uma tentativa de matar quaisquer processos essenciais ROS que possam
estar a correr e voltaremos a iniciar todos os módulos (roscore inicializa o ROS master e o
processo de roslaunch lançará todos os nós definidos no ficheiro de lançamento (Figura 70)).
O estado do SEP também é controlado neste script através de um processo de ping. Quando
o SEC2 deixa de receber resposta da parte do SEP esta situação é sinalizada e é esperado o
momento em que o SEP volta a estar disponível. Estando a máquina novamente ligada é
seguido o processo de matar todos os processos essenciais ROS que possam estar a correr e
são iniciados todos os módulos, incluindo os do SEC2.
5.1.3. Estrutura de um ficheiro roslaunch
Tal como referido anteriormente, o lançamento automático de módulos é feito através de
uma ferramente ROS chamada roslaunch. Um exemplo genérico de implementação utilizando
esta ferramenta está representado na Figura 70.
Figura 70: Ficheiro Roslaunch
123
Trata-se de um ficheiro xml com tags que são processadas pelo ROS para o lançamento
dos módulos da forma pretendida. Visto que neste sistema temos duas máquinas com módulos
que comunicam entre si foi tomada a decisão de lançar todos os módulos a partir do SEC2,
lançando os do SEP por SSH. É essa a funcionalidade da primeira linha deste exemplo, sendo
necessário fornecer o ip, o username e a password da máquina onde vamos fazer o lançamento
remoto, sendo também possível fornecer o caminho absoluto de um script de configuração de
ambiente colocado na máquina remota, o qual será executado por este ficheiro de lançamento.
Quanto aos módulos apenas é necessário especificar um nome, o nome do pacote ROS ao qual
pertencem, o nome do módulo no ambiente ROS e é possível especificar se queremos que os
outputs sejam colocados num ficheiro de log e se o módulo deve reiniciar em caso de morte.
É também neste ficheiro que podem ser especificados parâmetros específicos de cada módulo
que podem ser lidos pelo módulo quando é iniciado.
5.2. Resultados
Esta secção não se destina a apresentar os resultados dos testes referidos na secção 5.3 uma
vez que esses se encontram no Anexo D – Casos de Teste e Matriz de Rastreabilidade, mas
sim apresentar os resultados finais após a implementação e o assemblamento do hardware.
Na Figura 71 é apresentado o VANT, momentos antes de iniciar o seu primeiro ensaio de
voo já com o hardware a bordo.
Figura 71: Preparação para voo
124
Na Figura 72 podemos ver o hardware instalado a bordo do VANT na parte superior da
estrutura. Os principais componentes visíveis são:
1 – Piccolo autopilot;
2 – Computador de bordo SEP;
3 – Discos SSD para gravação de dados;
4 – Computador de bordo SEC2;
5 – Baterias auxiliares;
Figura 72:Hardware VANT - Vista superior
Tal como pode ser visto na figura anterior, as baterias foram denominadas como auxiliares,
isto deve-se ao facto de que a sua presença apenas é requerida como precaução uma vez que
a alimentação dos componentes a bordo será efetuada através de um gerador acoplado ao
motor do avião, o qual pode ser observado na Figura 73.
1
2
3 4 5
125
Figura 73: Motor e gerador do VANT
As câmaras instaladas a bordo do VANT estão instaladas na parte inferior da estrutura e
podem ser visualizadas na Figura 74, sendo elas:
1 – Gobi;
2 – JAI (Espetro visível e Near Infrared);
3 – TASE;
Figura 74: Hardware VANT - Vista inferior
1 2 3
126
5.3. Metodologia de testes
Esta secção visa a elaboração de testes de integração ao software desenvolvido no âmbito
do projeto, com o propósito final de se efetuar a cobertura dos requisitos presentes no Anexo
A - Requisitos, na secção de requisitos de software.
A elaboração de testes de integração tem como principal propósito a verificação de
componentes de software chave, de forma iterativa e incremental. Os testes de integração
focam-se então na deteção de possíveis problemas ao nível dos componentes individuais, das
ligações entre si e também na sua funcionalidade conjunta.
Em termos mais concretos, os testes têm como alvo componentes arquiteturais de alto nível
(tais como SEC2, SEP e ETP) ou subcomponentes dos mesmos, sempre que exista razão para
o efeito (isto é, por questões de criticidade). Por outro lado, serão feitos testes ao nível da
integração, que terão como alvo combinações de componentes arquiteturais de alto nível a
comunicar entre si (tais como SEC2+SEP ou ETP+SISOM), mas que em caso de falha,
deverão permitir identificar erros nos componentes individuais.
É importante referir que se trata de testes formais, que em oposição aos testes informais
(vulgarmente realizados pelos próprios desenvolvedores como parte inerente à atividade de
implementação), permitem revisão e execução independente dos testes, assim como execuções
consistentes e repetidas ao longo do tempo (testes de regressão), fornecendo ainda evidências
de verificação e um maior controlo de qualidade.
Os testes de integração seguem o processo geral apresentado na Figura 75.
Figura 75: Etapas de um teste formal
Para cada um dos itens a testar proceder-se-á à especificação de casos de teste orientados
à cobertura dos requisitos aplicáveis (Anexo D – Casos de Teste e Matriz de Rastreabilidade).
Já no contexto das tarefas de Implementação e Execução dos testes, a secção 5.3.1
(Necessidades de Ambiente) é responsável por descrever o conjunto das necessidades de
ambiente específicas, tais como ferramentas, hardware e configurações.
Especificação Implementação Execução Relatório de
Resultados
127
Por fim, os relatórios de execução dos testes são também incluídos no Anexo D – Casos
de Teste e Matriz de Rastreabilidade, tal como a monitorização global da cobertura de
requisitos (Matriz de rastreabilidade).
5.3.1. Necessidades de ambiente
Esta secção descreve o conjunto de necessidades de ambiente específicas ao
desenvolvimento e execução dos testes, tais como ferramentas, hardware e configurações (isto
é, o ambiente de testes).
5.3.1.1. Ambiente Hardware-In-The-Loop (HIL)
O ambiente de harware-in-the-loop corresponde a todo o ambiente com os seus
componentes reais, mesmo que o deslocamento do VANT, introdução de objetos e o seu
deslocamento possam ser simulados. Este ambiente é representado pela configuração presente
na Figura 76.
Figura 76: Diagrama de ligações entre os diversos componentes do sistema de testes com HIL
Utilizando esta configuração foram realizados os testes de integração do software de forma
a validar a correta implementação do sistema e cobertura dos requisitos especificados. A
informação sobre os testes realizados, os seus resultados e a matriz de rastreabilidade que
mapeia cada requisito para os seus testes podem ser vistos no Anexo D – Casos de Teste e
Matriz de Rastreabilidade.
128
129
Capítulo 6
Conclusão
A chamada Economia do Mar está em crescimento, o qual gera, inevitavelmente, um
aumento da circulação das pessoas e bens, com impacto nas atividades relacionadas com a
salvaguarda da vida humana no mar. Os VANT deverão ter, cada vez mais, um papel
importante nas tarefas levadas a cabo para um adequado conhecimento situacional marítimo,
nomeadamente na identificação, deteção e seguimento de alvos.
Enquadrada no projeto SEAGULL, que visa o desenvolvimento de sistemas de bordo
inteligentes associados a veículos aéreos não tripulados já existentes, esta dissertação focou-
se na criação de vários módulos de apoio à operação de um VANT, nomeadamente:
Garantir a comunicação bidirecional entre o VANT e a terra;
Implementar módulo para garantia de entrega e fragmentação/agregação de mensagens
em pacotes;
Implementar módulo de controlo de prioridade sobre os módulos de target tracking e
sense and avoid;
Implementar módulos para receção de dados dos sensores e câmaras;
Implementar estação de terra de payload;
Após a implementação de todas as funcionalidades já referidas os VANT equipados com
o sistema detalhado nesta dissertação são capazes de, durante o voo, enviar para terra
informação do seu estado atual, imagens de objetos que estejam a ser detetados no seu campo
de visão e avisos sobre possíveis erros que possam ocorrer a bordo, tendo a capacidade de
aterrar autonomamente em caso de falha grave ou perda de comunicação. Conseguem ainda
executar missões cooperativas sem o risco de colisão entre dois VANT devido ao seu módulo
de sense and avoid, efetuar o seguimento ativo de um alvo quando requisitado e alterar a sua
missão em pleno voo.
Esta dissertação cumpre todos os objetivos aos quais se propôs e contribui para a
possibilidade de utilização de VANT no patrulhamento da zona económica exclusiva
portuguesa, conferindo assim um aumento no conhecimento situacional marítimo por parte
das autoridades competentes e reduzindo os custos operacionais deste tipo de missões.
130
Trabalho futuro
Como trabalho futuro é importante destacar quatro pontos essenciais, dividos em duas
classes:
Melhorias no sistema implementado:
o Maior capacidade de tomada de decisões do sistema de bordo;
Melhorias nos componentes utilizados:
o Maior autonomia de voo;
o Aumentar alcance e largura de banda do canal de comunicação;
o Câmara hiperespetral;
Aumentado a capacidade de tomada de decisões por parte dos sistemas de bordo resultaria
numa menor necessidade de intervenção por parte do(s) operador(es) de terra, permitindo
assim uma redução no custo operacional. Um exemplo de melhoria neste campo seria
direcionado ao módulo de deteção por forma a permitir que o VANT, dentro dos objetos já
detetados no seu campo de visão pudesse, autonomamente, optar por seguir objetos de
interesse para a missão em curso.
Uma maior autonomia de voo permitiria missões mais longas e a cobertura de maiores
distâncias sem necessidade de regresso à base, permitindo assim, uma utilização de recursos
mais eficiente.
O aumento no alcance das comunicações, aliado ao aumento de autonomia de voo já
referido permitiria missões mais longas e maior cobertura. Este aumento no alcance pode ser
atingido recorrendo a comunicações por satélite bastando para isso a implementação de
recetores adequados a bordo do VANT e providenciando o empacotamento e
desempacotamento de dados necessário. A utilização de comunicações por satélite também
resolveria o problema da largura de banda permitindo assim o envio de imagens com maior
resolução e a cores sem o prejuízo para a performance das comunicações. Esta abordagem tem
de levar em conta os custos associados a este tipo de comunicações, tal como o peso e consumo
associados à instalação deste componente. Em termos de custo de utilização, um meio-termo
poderia ser encontrado utilizando este canal de comunicação apenas para o envio de imagens
para terra, mantendo-se a transmissão de toda a informação restante por ondas de rádio.
No caso da câmara hiperespetral, embora o seu tamanho compacto seja uma grande
evolução, ainda se trata de algo bastante recente pelo que o nível de maturidade do hardware
e respetivo software pode ser melhorado. Exemplo disso é o facto de que esta câmara não
131
permite a leitura direta das imagens, sendo para isso necessário que estas sejam guardadas
num cartão de memória e posteriormente analisadas em terra aquando do retorno à base por
parte do VANT. Um possível trabalho futuro neste aspeto seria a implementação da
capacidade de analisar as imagens hiperespetrais a bordo do VANT durante a execução de
missões por parte do mesmo, tal como acontece com todas as outras câmaras e sensores a
bordo.
132
133
Bibliografia AeroVironment, Inc. (2013). Global Observer. Obtido em 24 de October de 2013, de
http://www.avinc.com/globalobserver/missions/communications_relay
Almeida, P., Gonçalves, G., & Sousa, J. B. (2006). Multi-UAV platform for integration in
mixed-initiative coordinated missions. Em 1st IFAC Workshop on Multivehicle
Systems (pp. 70-75).
Alves, J. (2001). Recognition of ship types from an infrared image using moment invariants
and neural networks. Naval Postgraduate School.
Auslin, M. (February 24, 2011). The Case for Reviving the F-22 Fighter. The Wall Street
Journal. Obtido de
http://online.wsj.com/article/SB10001424052748704476604576158121568592568.ht
ml?mod=googlenews_wsj
Austin, R. (2010). Unmanned Aircraft Systems. Chichester, UK: John Wiley & Sons, Ltd.
Austin, R. (2010). Unmanned Aircraft Systems: UAVs Design, Development and
Deployment. Wiley.
Baker, T. (1999). TIAC White Paper on Appropriate Technology for Digital Libraries.
Bangkok: Technical Information Access Center.
Beard, R., & McLain, T. (2012). Small Unmanned Aircraft: Theory and Practice. Princeton
University Press.
Bellman, R. (1957). Dynamic Programming.
Breckon, T., & Barnes, S. (2009). Autonomous Real-time Vehicle Detection from a
Medium-Level UAV. Proc. 24th International Unmanned Air Vehicle Systems, (pp.
29.1-29-9).
Breeding, M. (2002). Preserving digital information. Information Today 19(5): pp. 48-49.
Bruch, G., Powell, M., & Gilbreath., D. (2006). Multi-robot operator control unit. SPIE,
6230.
CAP 722. (2010). Policy, Airspace:Unmanned Aircraft System Operations in UK Airspace.
Guidance Systems.
Carrigan, G. L. (2008). Human Factors Analysis of Predator B Crash. Proceedings of AUVSI
2008: Unmanned Systems. San Diego, CA.
Committee on Autonomous Vehicles in Support of Naval Operations. (2001). Autonomous
Vehicles in Support of Naval Operations. Washington, DC: The National Academies
Press.
Costa, T. A. (Setembro de 2005). ANTEX-M: Desenvolvimento de Aeronaves Não
Tripuladas na Força Aérea Portuguesa. Revista Mais Alto(357).
Covault, C. (2010). UAVs Drive SATCOM Modernization. Obtido em 24 de October de
2013, de http://www.defensemedianetwork.com/stories/uavs-drive-satcom-
modernization
Critical Software S.A. (2011). Obtido de Home - Oversee: http://www.oversee-
solutions.com/
134
Delogne, R. (October de 1999). The B-HUNTER UAV System. Development and Operation
of UAVs for Military and Civil Applications.
Dias, P., Gomes, R. M., & Pinto, J. (2006). Mission planning and specification in the Neptus
framework. International Conference on Robotics and Automation (pp. 3220–3225).
IEEE.
Duhigg, C. (April 15, 2007). The Pilotless Plane That Only Looks Like Child’s Play. New
York Times. Obtido de
http://www.nytimes.com/2007/04/15/business/yourmoney/15atomics.html
Dulski, R., Piatkowski, T., Trzaskawka, P., & Kastek, M. (2012). Testing of IR Image
Enhancement Algorithm on Maritime Objects. Symposium on Photonics and
Optoelectronics, (pp. 1-4).
Fefilatyev, S., & Goldgof, D. (2008). Detection and tracking of marine vehicles in video.
19th International Conference on Pattern Recognition, (pp. 1-4).
Fuchs, C., Ferreira, S., Sousa, J., & Gonçalves, G. (2013). Adaptive consoles for supervisory
control of multiple unmanned aerial vehicles. 5th International Conference on
Human-Computer Interaction: Interaction modalities and techniques. IV, pp. 678-
687. Berlin, Heidelberg: Springer-Verlag.
George, J., & Ghose, D. (2009). A Reactive Inverse PN Algorithm for Collision Avoidance
among Multiple Unmanned Aerial Vehicles.
Gonçalves, R., Ferreira, S., Pinto, J., Sousa, J., & Gonçalves, G. (2011). Authority sharing in
mixed initiative control of multiple uninhabited aerial vehicles. Engineering
Psychology and Cognitive Ergonomics, 530–539.
Gupta, K. M., Aha, D. W., Hartley, R., & Moore, P. G. (2009). Adaptive Maritime Video
Surveillance. Proceedings of the SPIE-09 Visual Analytics for homeland security,
7346, pp. 9-12.
Harel, J., Koch, C., & Perona, P. (2007). Graph-based visual saliency. Neural Information
Processing Systems (NIPS), (pp. 545-552).
Hou, X., & Zhang, L. (2008). Dynamic Visual Attention: Searching for Coding Length
Increments. Neural Information Processing Systems (NIPS), (pp. 8-11).
Hou, X., Harel, J., & Koch, C. (2011). Image Signature: Highlighting Sparse Salient
Regions. Pattern Analysis and Machine Intelligence, 34(1), 194–201.
International Maritime Organization. (2013a). Introduction to IMO. (I. M. Organization,
Produtor) Obtido em December de 2013, de International Maritime Organization:
http://www.imo.org/About/Pages/Default.aspx
International Maritime Organization. (2013b). Long-range identification and tracking
(LRIT). Obtido em December de 2013, de
http://www.imo.org/OurWork/Safety/Navigation/Pages/LRIT.aspx
International Maritime Organization. (2013c). AIS Transponders. Obtido em December de
2013, de http://www.imo.org/OurWork/Safety/Navigation/Pages/AIS.aspx
Israeli Weapons, LTD. (December de 2013). Hunter. Obtido de http://www.israeli-
weapons.com/weapons/aircraft/uav/hunter/Hunter.html
135
Itti, L., Koch, C., & Niebur, E. (1998). A model of saliency-based visual attention for rapid
scene analysis. Pattern Analysis and Machine Intelligence, 20(11), 1254–1259.
ITU . (04 de 2010). ITU - International Telecommunication Union. Recommendation ITU-R
M.1371-4 (04/2010) - Technical characteristics for an automatic identification
system using time-division multiple access in the VHF maritime mobile band;.
JAPCC. (2010). JAPCC Strategic Concept of Employment for Unmanned Aircraft Systems in
NATO. Obtido em 12 de March de 2011, de
http://www.japcc.de/nato_flightplan_uas.html
Kruger, W., & Orlov, Z. (2010). Robust layer-based boat detection and multi-target-tracking
in maritime environments. Waterside Security Conference (WSS).
Lieutenant General Walter E. Buchanan III, U. S. (Mar. 17, 2004). Unmanned Combat Air
Vehicle (UCAV) and Unmanned Aerial Vehicle (UAV). Obtido de
http://www.globalsecurity.org/military/library/congress/2004_hr/04-03-
17buchanan.htm
Martins, R., Dias, P. S., Marques, E. R., Pinto, J., Sousa, J. B., & Pereira, F. L. (2009). IMC:
A communication protocol for networked vehicles and sensors. OCEANS, (pp. 1-6).
McGann, C., Py, F., Rajan, K., Thomas, H., Henthorn, R., & McEwen, R. (2008). A
deliberative architecture for AUV control. International Conference on Robotics and
Automation (pp. 1049-1054). IEEE.
Military Factory. (17 de July de 2014). Obtido de Military Factory:
http://www.militaryfactory.com/aircraft/detail.asp?aircraft_id=326
Monteiro, N. S. (19 de August de 2009). Ponto de Situação do GMDSS - Global Maritime
Distress and Safety System. Revista da Marinha(RM 976).
Mortimer, G. (19 de July de 2011). sUAS News. Obtido de Unmanned Aircraft System news
for RPAS operators: http://www.suasnews.com/2011/07/6113/insitus-scaneagle-
proves-consistent-reliability-over-500000-combat-flight-hours/
Oreifej, O., Mehran, R., & Shah, M. (2010). Human identity recognition in aerial images.
Computer Vision and Pattern Recognition (CVPR).
Powell, D., Barbour, D., & Gilbreath, G. (2012). Evolution of a common controller.
Unmanned Systems Technology XIV. 8387. SPIE.
Protti, M., & Barzan, R. (2007). UAV Autonomy – Which level is desirable? – Which level is
acceptable? Alenia Aeronautica Viewpoint. Torino.
RaduBogdanRusu. (13 de 10 de 2010). cv_bridge - ROS Wiki. Obtido de ROS.org:
http://wiki.ros.org/cv_bridge
Ramakrishnan, V., Prabhavathy, A., & Devishree, J. (2012). A Survey on Vehicle Detection
Techniques in Aerial Surveillance. International Journal of Computer Applications,
55(18), 43–47.
Samama, A. (2010). Innovative Video Analytics for Maritime Surveillance. Waterside
Security Conference, (pp. 1-8).
ScanEagle Unmanned Aerial Vehicle. (2013). Obtido em 15 de October de 2013, de
http://www.boeing.com/boeing/history/boeing/scaneagle.page
Schiller, J. (2003). Mobile Communications. Great Britain: Pearson Education Limited .
136
Seibert, M., & Rhodes, B. (2006). SeeCoast port surveillance. Proceedings of DPIE,
Photonics for Port and Harbor Security II., 6204.
Shadow 200 RQ-7 Tactical Unmanned Aircraft System. (2013). Obtido em 16 de October de
2013, de http://www.army-technology.com/projects/shadow200uav/
Shane, S. (October 8, 2011). Coming Soon: The Drones Arms Race. The New York Times.
Obtido de http://www.nytimes.com/2011/10/09/sunday-review/coming-soon-the-
drone-arms-race.html?pagewanted=all&module=Search&mabReward=relbias%3Ar
Simmons, R., Apfelbaum, D., Fox, D., Goldman, R. P., Haigh, K. Z., Musliner, D. J., . . .
Thrun, S. (2000). Coordinated deployment of multiple, heterogeneous robots.
International Conference on Intelligent Robots and Systems, (pp. 2254–2260).
Sokalski, J., Breckon, T. P., & Cowling, I. (2007). Automatic Salient Object Detection In
UAV Imagery. 25th International UAV Systems Conference, (pp. 681–688).
Srivastava, H., & Limbu, Y. (2007). Airborne Infrared Search and Track Systems. Defence
Science Journal, 57(5), 739–753.
STANAG. (2006). NSA Standardization Agreement, Standard Interfaces of UAV Control
Systems (UCS) for NATO UAV Interoperability.
Teutsch, M., & Kruger, W. (2010). Classification of small boats in infrared images for
maritime surveillance. International WaterSide Security Conference, (pp. 1-7).
The Open Group. (2005). Developer Declaration of Independence. Obtido de
http://www.opengroup.org/declaration/declaration.htm
The UAV. (s.d.). Obtido de The UAV - Unmanned Aeria Vehicle: http://www.theuav.com/
Toet, A. (2002). Detection of dim point targets in cluttered maritime backgrounds through
multisensor image fusion. SPIE AeroSense, 4718, pp. 118–129.
United Kingdom Hydrographic Office. (2012/2013). Admiralty List of Radio Signals.
Global Maritime Distress and Safety System (GMDSS), Volume 5.
US Army. (2006). Army Unmanned Aircraft System Operations. Field Manual Interim, U.S.
Military, Department of Defense.
US Army Intelligence Center. (2000). Obtido em 24 de October de 2013, de Tactical
Unmanned Aerial Vehicle Concept of Operations:
http://www.fas.org/irp/program/collect/docs/TUAV-CONOPS.htm
USA DoD. (2011). Unmanned Systems Integrated Roadmap FY2011-2036. Obtido em 21 de
02 de 2013, de http://info.publicintelligence.net/DoD-UAS-2011-2036.pdf
Valavanis, K. (2007). Advances in unmanned aerial vehicles: state of the art and the road to
autonomy. Springer.
Vilbrandt, T. e. (2004). Cultural heritage preservation using constructive shape modeling.
Computer Graphics Forum 23(1): 25-41.
Westall, P., Ford, J. J., O’Shea, P., & Hrabar, S. (December de 2008). Evaluation of
Maritime Vision Techniques for Aerial Search of Humans in Maritime
Environments. Digital Image Computing: Techniques and Applications, 176–183.
Westall, P., Shea, P. O., Ford, J. J., & Hrabar, S. (2009). Improved Maritime Target Tracker
using Colour Fusion. High Performance Computing & Simulation, (pp. 230–236).
137
Anexos
Anexo A - Requisitos
Requisitos do Sistema
Tabela 7: Requisitos do sistema
Componente ID Titulo Descrição
SEC2
REQ-SYS-0010
Comunicar com estação de terra
O SEC2 deverá realizar toda a comunicação de e para o VANT, disponibilizando interfaces para os restantes componentes nele presentes, nomeadamente o SEP.
REQ-SYS-0020
Disponibilizar dados de navegação
O SEC2 deverá disponibilizar dados de navegação para os restantes componentes presentes no VANT (nomeadamente ao SEP).
REQ-SYS-0030
Comunicação por RF
O SEC2 deverá conseguir comunicar com a estação de terra através de RF em linha de vista.
REQ-SYS-0040
Sense & Avoid
O SEC2 deverá implementar uma funcionalidade de deteção de possíveis colisões entre o VANT e outros veículos presentes na sua área de operação, fornecendo comandos para uma correção de rota segura.
REQ-SYS-0050
Interface de navegação
O SEC2 deverá disponibilizar um interface para o controlo de navegação por parte de outros componentes presentes no VANT.
REQ-SYS-0060
Controlar navegação
O SEC2 deverá ser capaz de assumir o comando da navegação do VANT (i.e., após ordem da ETP para o SEP para seguimento de navio).
SEP
REQ-SYS-1000 Estabelecer ligação com o SEC2
O Sistema Embarcado Payload (SEP) deverá estabelecer comunicação com o Sistema Embarcado Comando e Controlo (SEC2).
REQ-SYS-1010 Estabelecer ligação com ETP
O SEP deverá estabelecer comunicação com a Estação de Terra Payload (ETP).
REQ-SYS-1020
Receber comandos
O SEP deverá suportar um método de entrega de mensagens/eventos de e para a ETP que garanta a entrega (i.e., que receba confirmação da receção dos dados) para todas as comunicações não cíclicas.
138
Componente ID Titulo Descrição
REQ-SYS-1030 Plano de voo (Início da Missão)
O SEP deverá ser capaz de receber a indicação da missão a realizar por parte da ETP.
REQ-SYS-1040
Leitura de sensores O SEP deverá realizar a leitura dos dados dos sensores de payload para as suas ações de deteção e seguimento.
REQ-SYS-1050 Transmitir informação dos sensores para a ETP para monitorização e controlo
O SEP deverá disponibilizar informação de telemetria sobre o estado do payload (incluindo sensores) à ETP.
REQ-SYS-1060 Permitir modificações no plano da missão durante o voo
O SEP deverá permitir que missões já em curso sejam alteradas de forma a adotar novos planos de missão no decorrer de missões.
REQ-SYS-1070
Dados de navegação O SEP deverá adquirir dados de navegação (posição, velocidade, orientação) a partir do SEC2.
REQ-SYS-1080
Selecionar e configurar sensores
O SEP deverá ser capaz de (des)ligar, (re)posicionar, (re)calibrar e selecionar os sensores a utilizar conforme a missão/situação atual.
REQ-SYS-1090
Georreferenciar e guardar todos os dados em bruto para análise futura
O SEP deverá ser capaz de armazenar dados dos sensores e estado geral do payload (georreferenciados) em bruto (dados não necessariamente enviados pelo SEP para a ETP durante a missão) para análise posterior.
REQ-SYS-1100 Detetar objeto de missão - manchas de poluição
O SEP deverá ter a capacidade de deteção de manchas de poluição (hidrocarbonetos) no seguimento da esteira de navios.
REQ-SYS-1110
Identificar embarcações
O SEP deverá ser capaz de detetar embarcações através dos sensores e cruzar a informação recolhida dos vários sensores (nomeadamente do AIS e câmaras).
REQ-SYS-1120 Detetar objeto de missão - embarcações a alta velocidade, comportamento tipicamente associado às embarcações envolvidas no narcotráfico
O SEP deverá ter a capacidade de deteção de embarcações de pequenas dimensões a alta velocidade (e.g. » 30 kts).
REQ-SYS-1130
Detetar objeto de missão – embarcação a baixa velocidade
O SEP deverá ter a capacidade de deteção de embarcações a baixa velocidade (e.g. «2kt). (Esta capacidade está diretamente correlacionada com os REQ-USR-1150 e 1170)
REQ-SYS-1140 Detetar objeto de missão – pares de navios
O SEP deverá ter a capacidade de deteção de pares de navios [i.e. uma pequena
139
Componente ID Titulo Descrição
embarcação («15mts) junto a um navio de maiores dimensões (»50mts).
REQ-SYS-1150
Detetar objeto de missão - pesca ilegal & navios constantes em listas de navios suspeitos de traficâncias
O SEP deverá ter a capacidade de deteção e identificação de embarcações em provável situação de pesca ilegal e/ou outras embarcações identificadas como suspeitas (localização e tipo), o que só é possível apurar caso seja obtida a identificação de matricula/nome da embarcação, potencialmente feita pelo operador com base em imagens recolhidas pelo VANT (e.g. só assim é possível apurar se a referida embarcação está autorizada a pescar na zona onde foi identificada ou se consta em alguma listagem de navios suspeitos).
REQ-SYS-1160
Detetar jangadas/balsas salva-vidas (balsas)
O SEP deverá ser capaz e detetar uma jangada salva-vidas na água (quer numa situação em que ocorra um afundamento/naufrágio de uma embarcação, quer numa situação de "Mass Rescue", dado que a probabilidade de existência de uma ou várias jangadas salva-vidas na água (com sobreviventes no seu interior) é elevada.
REQ-SYS-1170
Recolha de elementos de informação de embarcações
O SEP deverá conseguir recolher elementos de informação relativos à posição de uma embarcação, nome, nº IMO, ou matrícula, ou outros ID sightings (para permitir cruzamento com outras BDs). Sempre que for identificado um potencial alvo, deverá ser possível ao operador de terra requisitar a recolha de snapshots, que eventualmente permitam, posteriormente, cruzar informação.
REQ-SYS-1180 Enviar eventos
O SEP deverá ter a capacidade de enviar eventos à ETP.
REQ-SYS-1190
Notificar identificações de alvos
O SEP deverá disponibilizar a informação das embarcações (e de outros objetos), podendo conter snapshots, detetadas à ETP sob a forma de eventos.
REQ-SYS-1200 Comandos de (des)ativação
O SEP deverá ser capaz de receber comandos da ETP para ligar / desligar cada sensor e as capacidades a eles ligados.
REQ-SYS-1210 Comandos de seguimento de alvo
O SEP deverá ser capaz de receber comandos da ETP para seguir/sobrevoar (ou deixar de seguir) qualquer alvo detetado.
140
Requisitos de Hardware
Tabela 8: Requisitos de hardware
Componente ID Titulo Descrição
SEC2
REQ-HW-0010
Plataforma computacional SEC2
A plataforma computacional do SEC2 é um PC-104 com características iguais ou superiores a um Atom CPU, 1GB RAM, 16GB Flash, RS-232 e Ethernet. Inclui Auto Pilot.
REQ-HW-0020
Sensores Sense&Avoid O SEC2 deverá estar ligado a um recetor ADS-B. Este recetor será o GNS 5890 ABS-b Receiver.
SEP
REQ-HW-1000
Plataforma computacional SEP
A plataforma computacional do SEP, deverá ser o modelo Leopard (VL-EPM-35), com as seguintes características: - Intel Core 2 Duo SP9300 (2,26GHz); - 6 MB L2 cache; - 4GB RAM; - Intel GMA 4500 MHD graphics core;
REQ-HW-1010 Fonte de energia SEP
A fonte de energia do SEP, deverá ser: - VL-EPM-PS1 (50W)
REQ-HW-1020
Sensores específicos de Payload
O SEP deverá ter os seguintes sensores de payload integrados: Sensores camara visível e IR propostos: - TASE 150 Sensor Sony fcb - ex 1000; Zoom 36x; FOV 55.7º - 1.9º; orientação pan contínuo, tilt +23º / -203º; interface Analógico; - GOBI - 384; Resolução 384 x 288; frame rate 50 Hz ou 9 Hz; 8 a 14 micrómetro; interface 16-bit Ethernet and CameraLink; Sensor não orientável; -JAI AD-081GE; Resolução 1024x760 por canal; frame rate 30 Hz; Banda RGB+NearIR; GigE Vision Interface; Lente de 4mm Sensor camara hiper-espectral: - Rikola Ltd Hyperspectral Camera;
REQ-HW-1030 Sensor AIS O SEP deverá ter um sensor AIS integrado.
REQ-HW-1040 Modulo Ethernet SEP
O módulo ethernet do SEP deverá ser: - VL-EPM-E2
REQ-HW-1050
Frame grabber
Para conversão do output da câmara EO de analógico para digital o SEP deverá possuir o frame grabber: - VFG7350ER
Interfaces REQ-HW-2000
SEC2 <-> SEP : Ethernet O SEC2 e o SEP deverão conseguir comunicar entre si através de ethernet (Serial com Autopilot)
141
Requisitos de software
Tabela 9: Requisitos de software
Componente ID Titulo Descrição
SEC2
REQ-SW-0010 Sistema operativo (SEC2)
O SEC2 deverá correr sobre o sistema Linux com o middleware ROS instalado
REQ-SW-0020
Distribuição de módulos (SEC2)
O SEC2 deverá ser composto por um conjunto de nós ROS, correspondendo a executáveis individuais, para cada um dos seguintes módulos: - Control Supervisor; - Comms Relay; - Sense&Avoid; - Transponder Driver; - Target Tracker; - Autopilot Driver; - Autopilot Comms;
REQ-SW-0030
Comunicações SEC<->AP
O SEC2 deverá ser capaz de traduzir os dados recebidos nas extremidades e transformá-los numa mensagem do tipo AutopilotPayload, e vice-versa, que será publicada/subscrita em tópicos ROS consoante o sentido do fluxo de dados (do AP para o ROS ou do ROS para AP).
REQ-SW-0040
Transponder Driver
O módulo Transponder Driver servirá de interface para os dados recebidos nas suas extremidades. Aquando da chegada de dados provenientes dos Transponders irá traduzi-los e transmiti-los para o módulo de S&A.
REQ-SW-0050
Comms Relay
O Comms relay deverá implementar o protocolo que garante a fiabilidade de entrega e a fragmentação de dados de maior dimensão para serem passados ao AutoPilot Comms. Da mesma forma deverá fazer a "assemblagem" dos pacotes recebidos do Autopilot para formar a mensagem enviada.
REQ-SW-0060
Sense&Avoid
O módulo de Sense&Avoid deverá processar informação de posição, recebida de outros VANT, e realizar correções seguras à trajetória atual do VANT por forma a evitar a colisão.
REQ-SW-0070
Target Tracker
O módulo Target Tracker deverá ser ativado pelo Control Supervisor e receber do Seagull Manager a posição do objeto a ser seguido, mantendo o objeto no campo de visão do VANT.
142
Componente ID Titulo Descrição
REQ-SW-0080
Control Supervisor
O módulo Control Supervisor disponibilizará ao Seagull Manager o serviço para ativação ou desativação do Target Tracker para seguimento de alvos. Quando este serviço for ativado, o CS deverá ativar o Target Tracker.
REQ-SW-0090
Autopilot Driver
O módulo Autopilot Driver deverá ser capaz de difundir telemetria proveniente do autopilot para o VANT e receber providenciar a capacidade de enviar comandos de baixo nível para o autopilot para controlo de trajetória e navegação.
SEP
REQ-SW-1000
Sistema operativo O SEP deverá correr sobre o sistema operativo Linux com o middleware ROS instalado.
REQ-SW-1010
Distribuição de módulos
O SEP deverá ser composto por um conjunto de nós ROS, correspondendo a executáveis individuais, para cada um dos seguintes módulos: - Seagull Manager; - Tase Frame Grabber; - Gobi Frame Grabber; - JAI Frame Grabber; - Detection Module;
REQ-SW-1020
Frame Grabber
Os módulos Frame Grabbers deverão recolher as imagens dos sensores e enviá-las para o Detection module utilizando mensagens ROS.
REQ-SW-1030
Configuração Detection Module
O Detection Module deverá ativar/desativar os detetores e definir o seu "peso" na deteção de objeto em conformidade com os parâmetros de configuração fornecidos pelo Seagull Manager.
REQ-SW-1040
Detection Module
O Detection Module deverá receber imagens provenientes do Frame Grabber e realizar computações sobre as mesmas para atingir os seguintes resultados: - Georreferenciar e guardar todos os dados em bruto para análise futura; - Detetar manchas de poluição (hidrocarbonetos) no seguimento da esteira de navios; - Detetar embarcações de pequenas dimensões a alta velocidade (e.g. » 30 kts); - Detetar embarcações a baixa velocidade (e.g. « 1kt); - Detetar pares de navios [i.e. uma pequena embarcação («15mts) junto a um navio de maiores dimensões (»50mts); - Detetar e identificar embarcações em provável situação de pesca ilegal e/ou
143
Componente ID Titulo Descrição
outras embarcações identificadas como suspeitas (localização e tipo) ; - Detetar uma jangada salva-vidas na água; Todas as deteções devem ser reportadas ao Seagull Manager.
REQ-SW-1050
Identificação de embarcações
O Detection Module deverá conseguir recolher elementos de informação relativos ao nome, ou matrícula, ou outros ID sightings (para permitir cruzamento com outras BDs).
REQ-SW-1060
Tag de objeto novo O Detection Module deverá identificar como tal todos os objetos novos detetados em cada lista enviada para o Seagull Manager.
REQ-SW-1070
Envio de imagens
O Detection Module deverá ser capaz de fornecer ao módulo Seagull Manager as imagens de objetos e sensores por ele requeridas.
REQ-SW-1080
Requisição de imagens
O Seagull Manager deverá ser capaz de requisitar imagens de objetos e sensores ao Detection Module (por ordem da ETP ou em caso de objeto novo detetado) e, posteriormente, receber as imagens requisitadas e enviar as mesmas para terra.
REQ-SW-1090 Receção de listas de objetos
O Seagull Manager deverá ser capaz de receber do Detection Module, ciclicamente, listas de objetos visíveis.
REQ-SW-1100
Identificação de objeto novo
O Seagull Manager deverá analisar cada lista recebido do Detection Module e caso encontre um objeto marcado como "novo" deverá realizar os seguintes procedimentos: - Enviar um pedido de imagem do objeto em questão; - Enviar para terra um evento PAYLOADEVENT informando do objeto em questão;
REQ-SW-1110
Seguimento de alvo
Quando o VANT estiver em modo de seguimento de alvo o Seagull Manager deverá realizar os seguintes procedimentos: - Ativar o serviço de seguimento de alvo no Control Supervisor; - Fornecer informação sobre a posição e deslocamento do alvo ao módulo Target Tracker;
REQ-SW-1120
Definição de missão
O seagull Manager deverá receber a missão e fornecer os parâmetros de configuração ao Detection Module em conformidade com a mesma.
REQ-SW-1130 Envio de telemetria de payload
O seagull Manager deverá enviar ciclicamente telemetria de payload
144
Componente ID Titulo Descrição
contendo os parâmetros definidos na mensagem PAYLOADTELEMETRY
REQ-SW-1140
Atualização do panorama marítimo
O Seagull Manager deverá enviar ciclicamente listas de objetos visíveis naquele momento por forma a atualizar a visão do panorama marítimo na estação de terra.
REQ-SW-1150
Erros Erros no SEP devem ser reportados para terra utilizando a mensagem mavlink PayloadError
REQ-SW-1160
Logging e Modo de Debug Todos os módulos do SEP deverão escrever num ficheiro o log de execução e o report de erros.
REQ-SW-1170
Frequência de leitura dos sensores
Os sensores deverão captar as imagens e fornece-las periodicamente (parametrizável) aos restantes módulos que subscrevam os tópicos ROS adequados.
Interfaces
REQ-SW-2000
Suportar interação via GUI para visualização e operação
Para interface com o operador de Payload deverá ser disponibilizada uma GUI para a ETP, suportando display e operação.
REQ-SW-2010 Comunicação: interface ETP <-> SISOM
A ETP deverá disponibilizar uma interface de interação com o SISOM que deverá ocorrer através de chamadas via webservices, e de ficheiros de configuração (xml)
REQ-SW-2020 Dados de comunicação: SISOM -> ETP
No sentido de comunicação SISOM -> ETP deverão ser transmitidos os seguintes tipos de dados: - Missão (payload + dados de navegação); - Atualização de Missão (payload updates + dados de navegação); - Comando Cancelar/Abortar missão;
REQ-SW-2030 Dados de comunicação: ETP -> SISOM
No sentido de comunicação ETP -> SISOM deverão ser transmitidos Situational Reports ("sitreps") com os seguintes tipos de dados: - Resultados de Missão; - Atualização/Mudança de Missão (alteração realizada diretamente na ETP); - Eventos; - Telemetria;
REQ-SW-2040
Periodicidade de comunicação: ETP -> SISOM
No sentido de comunicação ETP -> SISOM, o envio dos dados de Telemetria&Sitreps deverá ser cíclico, de forma a garantir que há reportar contínuo. (os restantes tipos de dados deverão ser transmitidos imediatamente)
REQ-SW-2050
Comunicação: Estação SEC2 intermediária
O SEC2 deverá disponibilizar o único interface de comunicação entre o VANT (incluindo outros componentes a ela ligados, nomeadamente o SEP) e as estações de
145
Componente ID Titulo Descrição
terra (ETC2 e ETP), executando funções de roteamento entre a SEP e as estações de terra (em ambos os sentidos).
REQ-SW-2060
Comunicação: interface ETP <-> VANT
A ETP deverá ser agnóstica aos mecanismos e particularidades da implementação da comunicação ETC2<->VANT, tendo apenas de comunicar com a estação ETC2 através do interface por ela disponibilizada.
REQ-SW-2070 Comunicação: interface SEC2 <-> ETC2 para payload
A comunicação de dados de payload, feita entre o SEC2 e ETC2 (em prol do SEP e ETP), deverá utilizar o canal específico PAYLOAD_STREAM da comunicação Piccolo.
REQ-SW-2080
Comunicação: interface ETP <-> VANT
O SEP deverá ser agnóstico aos mecanismos e particularidades da implementação da comunicação SEP<->Estações de Terra, tendo apenas de utilizar o interface disponibilizado pelo SEC2.
REQ-SW-2090
Dados de comunicação: SEP -> ETP
No sentido de comunicação SEP -> ETP deverão ser transmitidos (via ETC2) os seguintes tipos de dados: - Eventos (inclui dados de missão) e Erros; - Telemetria (estado dos sensores, etc.); - Imagens;
REQ-SW-2100
Protocolo de comunicação: SEP -> ETP
Todos os dados cíclicos de telemetria no sentido de comunicação SEP -> ETP (via SEC2 e ETC2) deverão ser enviados sem garantia de entrega (i.e., num protocolo semelhante a UDP sem confirmação de receção por parte do recetor).
REQ-SW-2110
Periodicidade de comunicação: VANT -> ETP
No sentido de comunicação VANT -> ETP (via ETC2), o envio dos dados de Telemetria deverá ser cíclico, de forma a garantir que há reportar contínuo. (os restantes tipos de dados deverão ser transmitidos imediatamente)
REQ-SW-2120 Dados de comunicação: ETP -> VANT
No sentido de comunicação ETP -> VANT (via ETC2) deverão ser transmitidos os seguintes tipos de dados, garantindo a entrega dos dados: - Configuração de Missão (payload + dados de navegação) - Ordem de seguimento (ativa Slave-to-Sensor-Nav) - Atualização de Configuração (ativar/desativar sensores e capacidades) - Pedido de imagem (de sensor ou objeto previamente detetado);
REQ-SW-2130 Comunicação: SEP <-> SEC2
O SEC2 deverá publicar uma mensagem ROS com a telemetria de navegação do VANT
146
Componente ID Titulo Descrição
(posição, orientação, etc.) subscrita pelo SEP.
REQ-SW-2140 Dados de comunicação SEP -> SEC2
O SEC2 deverá disponibilizar um interface ao SEP, através de um serviço ROS, para que este possa ativar o controlo de navegação do VANT (nomeadamente para seguir alvos).
REQ-SW-2150 Dados de comunicação SEC2 -> SEP
O SEC2 deverá disponibilizar um interface ao SEP, através de um serviço ROS, para que este possa comunicar com as estações de terra, nomeadamente com a ETP.
Health
Monitoring
REQ-SW-3000 Health Monitoring e Error Handling
O sistema deverá ter funcionalidades de Health Monitoring e Error Handling
REQ-SW-3010
Health Monitoring e Error Handling - heartbeat
Os vários módulos do sistema deverão enviar ciclicamente uma mensagem (de entrega não garantida) para os módulos principais, de forma a que estes tenham conhecimento do estado operacional (ou falta dele) do estado de saúde e ligação entre os mesmos.
REQ-SW-3020 Health Monitoring e Error Handling - ETP
O módulo da ETP Core será responsável pelo HM da ETP
REQ-SW-3030 Health Monitoring e Error Handling - SEP
O módulo do Seagull Manager será responsável pelo HM do SEP
REQ-SW-3040 Health Monitoring e Error Handling - SEC2
O módulo do Control Supervisor será responsável pelo HM do SEC2
REQ-SW-3050
Health Monitoring e Error Handling - VANT
Os módulos do Seagull Manager e Control Supervisor deverão fazer o HM entre ambos, garantindo assim monitorização do estado de saúde da plataforma do VANT
REQ-SW-3060
Health Monitoring e Error Handling - Terra-Ar
A ETP deverá enviar ciclicamente uma mensagem (de entrega não garantida) para o SEP de forma que o SEP tenha conhecimento do estado operacional (ou falta dele) da ETP e da ligação entre ambos.
REQ-SW-3070
Health Monitoring e Error Handling - Ar-Terra
O SEP deverá enviar ciclicamente uma mensagem (de entrega não garantida) para a ETP de forma que a ETP tenha conhecimento do estado operacional (ou falta dele) do SEP e da ligação entre ambos.
REQ-SW-3080
Controlo de ciclo de vida de nós ROS
Os vários nós ROS deverão ter controlo do seu ciclo de vida, garantindo que reiniciam em caso de falha. No caso de falha do ROS Master (ROS Core), deverá ser implementado um mecanismo de monitorização que garanta que todos os nós são desligados, e reiniciados pela ordem adequada (primeiro o Core, e depois todos os outros nós do sistema).
147
Anexo B – Interfaces a bordo
Neste anexo são detalhadas todas as interfaces para a troca de mensagens nas plataformas
computacionais SEP e SEC2 e entre elas.
São apresentadas duas tabelas principais, uma contendo os nós presentes em cada
plataforma, as mensagens por eles publicadas/subscritas e os tópicos onde estas circulam.
Todas as outras tabelas servem para explicar em que consiste cada mensagem trocada, os
seus campos, a sua função, a sua periocidade, etc.
Especificação de Interfaces SEP Tabela 10: Interfaces SEP (P – Publica, S – Subscreve)
Sistema Package Nó Nó ID Tópico P/S Mensagem
SEP
seagull_sensors ais_driver 0 ais_position_report P PositionReport
ais_static_voyage P StaticVoyage
to_sep_heartbeat P SeagullHeartbeat
seagull_error P SeagullError
gobi_fg 1 gobi_frame_grabber P Image
to_sep_heartbeat P SeagullHeartbeat
seagull_error P SeagullError
jai_fg 2 jai_eo_frame_grabber P Image
jai_nir_frame_grabber P Image
to_sep_heartbeat P SeagullHeartbeat
seagull_error P SeagullError
tase_fg 3 tase_frame_grabber P Image
to_sep_heartbeat P SeagullHeartbeat
seagull_error P SeagullError
detection_
module
4 detection_list_to_sep P DetectionList
detection_image_to_sep P DetectionImage
request_image S RequestImage
ais_position_report S PositionReport
ais_static_voyage S StaticVoyage
148
Sistema Package Nó Nó ID Tópico P/S Mensagem
to_sep_heartbeat P SeagullHeartbeat
seagull_error P SeagullError
detection_debug_to_dm S DetectionDebug
detection_debug_to_sm P DetectionDebug
tase_camera_zoom_in P TASECameraZoom
tase_camera_command_in P TASECameraComma
nd
autopilot_telemetry S AutopilotTelemetry
tase_command_in P TASECommand
seagull_core seagull_ma
nager
5 request_image P RequestImage
detection_module_config P DetectionConfig
detection_list_to_sep S DetectionList
detection_image_to_sep S DetectionImage
from_comms_relay S SeagullPayload
to_comms_relay P SeagullPayload
autopilot_telemetry S AutopilotTelemetry
target_location P TargetLocation
cs_status S CsStatus
to_sec2_heartbeat P SeagullHeartbeat
to_sep_heartbeat S SeagullHeartbeat
seagull_error S SeagullError
detection_debug_to_dm P DetectionDebug
detection_debug_to_sm S DetectionDebug
seagull_actuator
s
tase_driver 6 tase_telemetry P TASETelemetry
tase_angle_out P TASEAngles
tase_rate_out P TASERates
tase_raw_data_in P TASERawData
tase_raw_data_out S TASERawData
tase_camera_zoom_in S TASECameraZoom
tase_camera_command_in S TASECameraComma
nd
149
Sistema Package Nó Nó ID Tópico P/S Mensagem
tase_command_in S TASECommand
tase_comm
s
7 tase_raw_data_out P TASERawData
tase_raw_data_in S TASERawData
to_gimbal P AutopilotGimbalPayl
oad
from_gimbal S AutopilotGimbalPayl
oad
Tabela 11: Serviços do SEP
Sistema Package Serviço Parâmetros In/Out
SEP seagull_manager cs_request_action_srv ActionRequest BoolResponse
Mensagem PositionReport
Tabela 12: Definição da mensagem PositionReport
Campo Definição
Nome do tipo de mensagem PositionReport
Descrição Mensagem proveniente do módulo de AIS
Origem/Origens SEP (Módulo AIS)
Destino(s) SEP (Seagull Manager)
Tópico(s) ROS ais_position_report
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
objectId uint8 N/A Código identificativo do objeto.
type uint8 N/A Tipo de mensagem
repeatIndicator uint8 N/A Contador de repetição de mensagem
mmsi uint32 N/A Identificador único do recetor
navigationStatus uint8 N/A Estado de navegação
rot int8 N/A Rate Of Turn
150
Nome Tipo Unidades Descrição
sog uint16 N/A Course Over Ground
positionAccuracy bool N/A
Indica a precisão do fix de GPS. Um valor de 1 indica DGPS
com precisão < 10m. 0, por omissão, indica uma precisão de
GNSS FIX > 10m.
longitude float32 mas Posição do objeto.
latitude float32 mas Posição do objeto.
cog float32 graus Course Over Ground
heading float32 graus Direção do VANT em relação ao norte
timestamp uint16 segundos Tempo Universal Coordenado (segundos)
manuever uint8 N/A Indicador de manobra
spare uint8 N/A Usado para alinhamento da codificação de dados
raimFlag bool
N/A Indica se a monitorização do recetor de integridade
autónoma está a ser usado para verificar o desempenho da
EPFD
radioStatus uint32 N/A Informação de diagnóstico do sistema de rádio
Mensagem StaticVoyage
Tabela 13: Definição da mensagem StaticVoyage
Campo Definição
Nome do tipo de mensagem StaticVoyage
Descrição Mensagem proveniente do módulo de AIS
Origem/Origens SEP (Módulo AIS)
Destino(s) SEP (Seagull Manager)
Tópico(s) ROS ais_static_voyage
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
objectId uint8 N/A Código identificativo do objeto.
type uint8 N/A Tipo de mensagem
151
Nome Tipo Unidades Descrição
repeatIndicator uint8 N/A Contador de repetição de mensagem
mmsi uint32 N/A Identificador único do recetor
aisVersion uint8 N/A Versão AIS
imo uint32 N/A Número identificativo IMO do navio
callSign string N/A Nome abreviado do navio
vesselName string N/A Nome do navio.
shipType uint8 N/A Tipo de navio.
toBow uint16 metros Dimensão até à proa
toStern uint16 metros Dimensão até à popa
toPort uint8 metros Dimensão para bombordo
toStarBoard uint8 metros Dimensão para estibordo
positionFixType uint8 N/A Tipo do fix usado (Indefinido,GPS,GLONASS,,Galileo)
etaMonth uint8 UTC Tempo estimado de chegada (Mês)
etaDay uint8 UTC Tempo estimado de chegada (Dia)
etaHour uint8 UTC Tempo estimado de chegada (Hora)
etaMinute uint8 UTC Tempo estimado de chegada (Minuto)
draught uint8
metros/10 Profundidade de um navio colocado na água, medida a partir
do nível da linha de água para o ponto mais baixo do casco
destination string N/A Destino
dte bool N/A Data terminal ready
spare bool N/A Usado para alinhamento da codificação de dados
Mensagem Image
Tabela 14: Definição da mensagem Image
Campo Definição
Nome do tipo de mensagem Image
Descrição Mensagem ROS já disponível para a transmissão de imagens.
Origem/Origens SEP (JAI, Gobi e Tase frame grabbers)
Destino(s) SEP (Detection Module)
Tópico(s) ROS gobi_frame_grabber
jai_eo_frame_grabber
152
Campo Definição
jai_nir_frame_grabber
tase_frame_grabber
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação sobre a fotografia.
height uint32 Nº de linhas Altura da imagem.
width uint32 Nº de colunas Largura da imagem.
encoding string N/A Codificação dos pixéis (rgb8, mono8, etc…).
is_bigendian uint8 N/A Se os dados são ou não big-endian.
step uint32 Nº de bytes/linha Número de bytes de uma linha.
data uint8[ ] N/A Matriz de dados, sendo o seu tamanho (step*colunas).
Mensagem DetectionList
Tabela 15: Definição de estrutura visibleObjects
Campos da estrutura
Nome Tipo Unidades Descrição
objectId Uint16 N/A Código identificativo do objeto.
objectLatitude float mas Posição do objeto.
objectLongitude float mas Posição do objeto.
objectType uint8 N/A Número representativo do tipo de objeto.
objectVx int16 m/s Velocidade no eixo x em relação a um referencial inercial
global
objectVy int16 m/s Velocidade no eixo y em relação a um referencial inercial
global
isNew bool N/A Flag que indica se o objeto em questão é novo (está a ser
visualizado pela primeira vez)
153
Tabela 16: Definição da mensagem DetectionList
Campo Definição
Nome do tipo de mensagem DetectionList
Descrição Mensagem proveniente do Detection Module com uma lista dos objetos visíveis e
informações sobre cada um.
Origem/Origens SEP (Detection Module)
Destino(s) SEP (Seagull Manager)
Tópico(s) ROS detection_list_to_sep
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
list visibleObjects[ ] N/A Vetor de objetos visíveis em que cada posição inclui os
campos definidos na Tabela 15.
Mensagem DetectionImage
Tabela 17: Definição da mensagem DetectionImage
Campo Definição
Nome do tipo de mensagem DetectionImage
Descrição Mensagem proveniente do Detection Module com uma imagem requisitada pelo
Seagull Manager.
Origem/Origens SEP (Detection Module)
Destino(s) SEP (Seagull Manager)
Tópico(s) ROS detection_image_to_sep
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
imagem Image N/A Mensagem do tipo Image para transmissão de imagem.
154
Nome Tipo Unidades Descrição
requestedId Uint16 N/A Identificador único do sensor/objeto ao qual corresponde a
fotografia.
imageType uint8 N/A Tipo de imagem. 0 para imagem de um sensor, 1 para
imagem de um objeto.
objectLatitude float graus Posição do objeto.
objectLongitude float graus Posição do objeto.
latitude float graus Posição do VANT aquando do envio da imagem por parte do
Detection Module.
longitude float graus Posição do VANT aquando do envio da imagem por parte do
Detection Module.
objectVx int16 m/s Velocidade no eixo x em relação a um referencial inercial
global.
objectVy int16 m/s Velocidade no eixo y em relação a um referencial inercial
global.
newImage bool N/A Indicação se a imagem corresponde a um objeto novo.
Mensagem RequestImage
Tabela 18: Definição da mensagem RequestImage
Campo Definição
Nome do tipo de mensagem RequestImage
Descrição Mensagem proveniente do Seagull Manager para requisitar uma fotografia de um
determinado objeto ao Detection Module através do identificador único desse
mesmo objeto.
Origem/Origens SEP (Seagull Manager)
Destino(s) SEP (Detection Module)
Tópico(s) ROS request_image
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
requestedId Uint16 N/A Identificador único do sensor/objeto do qual se pretende a
fotografia.
155
Nome Tipo Unidades Descrição
imageType uint8 N/A Tipo de imagem. 0 para imagem de um sensor, 1 para
imagem de um objeto.
Mensagem DetectionConfig
Tabela 19: Definição da mensagem DetectionConfig
Campo Definição
Nome do tipo de mensagem DetectionConfig
Descrição Mensagem proveniente do Seagull Manager para configuração dos parâmetros do
Detection Module.
Origem/Origens SEP (Seagull Manager)
Destino(s) SEP (Detection Module)
Tópico(s) ROS detection_module_config
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
missionType uint8 N/A Tipo de missão a ser executada actualmente
Mensagem TargetLocation
Tabela 20: Definição da mensagem TargetLocation
Campo Definição
Nome do tipo de mensagem TargetLocation
Descrição Mensagem utilizada para comunicação entre o Seagull Manager e o Control
Supervisor por forma fornecer a posição do mesmo.
Origem/Origens SEP (Seagull Manager)
Destino(s) SEC2 (Control Supervisor)
Tópico(s) ROS target_location
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica (apenas quando é necessário seguir um objeto).
Necessita de garantia de entrega Não aplicável.
156
Campo Definição
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
objectId Uint16 N/A Identificador único do objeto a ser seguido.
objectLatitude float graus Posição do objeto.
objectLongitude float graus Posição do objeto.
objectVx int16 m/s Velocidade no eixo x em relação a um referencial inercial
global
objectVy int16 m/s Velocidade no eixo y em relação a um referencial inercial
global
Mensagem SeagullHeartbeat
Tabela 21: Definição da mensagem SeagullHeartbeat
Campo Definição
Nome do tipo de mensagem SeagullHeartbeat
Descrição Mensagem heartbeat proveniente de todos os nós a bordo do VANT e monitorizada
no Seagull Manager e Control Supervisor por forma a ter conhecimento de falhas nos
nós a bordo.
Origem/Origens SEP e SEC2 (Todos os nós)
Destino(s) SEP (Seagull Manager), SEC2 (Control Supervisor)
Tópico(s) ROS to_sep_heartbeat
to_sec2_heartbeat
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
Node uint8 N/A ID do nó do qual é proveniente o sinal de heartbeat. A lista
de ID’s pode ser consultada na Tabela 10 e Tabela 32.
157
Mensagem SeagullError
Tabela 22: Definição da mensagem SeagullError
Campo Definição
Nome do tipo de mensagem SeagullError
Descrição Mensagem de erro para ser trocada a bordo do VANT entre todos os nós. Todas as
mensagens de erro serão recebidas pelo Seagull Manager por forma a serem
encapsuladas em Mavlink e enviadas para terra.
Origem/Origens SEP e SEC2 (Todos os nós)
Destino(s) SEP (Seagull Manager)
Tópico(s) ROS seagull_error
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
errorType uint8 N/A Tipo de erro. A lista com o identificador para cada tipo de erro
pode ser encontrada na Tabela 58 referente à mensagem
“PAYLOADERROR”.
errorNode uint8 N/A Identificador do nó onde o erro teve origem.
errorMsg string N/A Mensagem de erro como complemento de informação.
Mensagem DetectionDebug
Tabela 23: Definição da mensagem DetectionDebug
Campo Definição
Nome do tipo de mensagem DetectionDebug
Descrição Mensagem que envia para o VANT e recebe do mesmo valores de DEBUG do
Detection Module.
Origem/Origens SEP (Seagull Manager), SEP (Detection Module)
Destino(s) SEP (Detection Module), SEP (Seagull Manager)
Tópico(s) ROS detection_debug_to_dm (Sentido SM -> DM)
detection_debug_to_sm (Sentido DM -> SM)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
158
Campo Definição
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
cmd int32 N/A Comando a ser pedido.
param int32 N/A Nome do parâmetro (descodificado no DM).
iVal1 int32 N/A Valor DEBUG.
iVal2 int32 N/A Valor DEBUG.
iVal3 int32 N/A Valor DEBUG.
fVal1 float N/A Valor DEBUG.
fVal2 float N/A Valor DEBUG.
fVal3 float N/A Valor DEBUG.
Mensagem TASEAngles
Tabela 24: Definição da mensagem TASEAngles
Campo Definição
Nome do tipo de mensagem TASEAngles
Descrição Mensagem que contém leitura da posição angular da câmara em relação ao corpo
da TASE, no eixo de azimute (Pan), elevação (Tilt) e rolamento (Roll).
Origem/Origens SEP (Tase Driver)
Destino(s) SEP (Detection Module)
Tópico(s) ROS tase_angle_out
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
pan float32 graus Ângulo de pan da câmara em relação ao suporte da gimbal.
tilt float32 graus Ângulo de tilt da câmara em relação ao suporte da gimbal.
roll float32 graus Ângulo de roll da câmara em relação ao suporte da gimbal.
159
Mensagem TASECameraCommand
Tabela 25: Definição da mensagem TASECameraCommand
Campo Definição
Nome do tipo de mensagem TASECameraCommand
Descrição Mensagem que permite fazer a configuração dos parâmetros do sensor incluído na
Tase.
Origem/Origens SEP (Detection Module)
Destino(s) SEP (Tase Driver)
Tópico(s) ROS tase_camera_command_in
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
camera uint8 N/A Bits de informação da câmara.
hfov int16 graus Campo de visão horizontal.
focus uint8 N/A Posição do foco.
exposure uint8 N/A Selecção do modo de controlo de exposição da câmara. Os
modos disponíveis são Full auto, shutter priority (tempo de
shutter definido e auto iris e ganho), bright (especificado o
valor de luminosidade, com tempo de shutter fixo) e do not change exposure control.
shutter_speed uint8 N/A Tempo de exposição para a câmara. Este parâmetro apenas
é aplicado no caso de o campo anterior ser shutter priority ou
bright. Valores possíveis são 1, 1/2, 1/4, 1/8, 1/15, 1/30,
1/60, 1/90, 1/100, 1/125, 1/180, 1/250, 1/350,
1/500, 1/725, 1/1000, 1/1500, 1/2000, 1/3000,
1/4000, 1/6000, 1/10000 (s)
bright uint8 N/A Valor de luminosidade de referência quando modo exposure
está seleccionado como bright.
flags uint8 N/A Flags de selecção de modos adicionais de funcionamento
das câmaras. Existem alguns modos que são aplicáveis
apenas a alguns tipos específicos de câmaras. As flags são
1- No change to flags, 2-Correcção de não uniformidades da
lente, 3- Selecção de modo de saída PAL, 4- Selecção de
modo de saída HD, 5- Selecção de modo de image a preto e
branco (desativa filtro IR), 6- Selecção de modo Black hot
(default é White hot), 7-Selecção de estabilização da
câmara, 8- Selecção de apresentação de título.
160
Mensagem TASECameraZoom
Tabela 26: Definição da mensagem TASECameraZoom
Campo Definição
Nome do tipo de mensagem TASECameraZoom
Descrição Mensagem que permite a execução de zoom contínuo.
Origem/Origens SEP (Detection Module)
Destino(s) SEP (Tase Driver)
Tópico(s) ROS tase_camera_zoom_in
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
camera uint8 N/A Bits de informação da câmara.
rate int8 N/A Taxa de Zoom. De -8 até 8. Zero significa parar o zoom.
Valores negativos significam zoom out.
timeout uint8 10ms Especifica o intervalo de tempo que se mantem o comando
de zoom contínuo. Ao fim deste intervalo se não chegar um
novo comando, o zoom para.
Mensagem TASECommand
Tabela 27: Definição da mensagem TASECommand
Campo Definição
Nome do tipo de mensagem TASECommand
Descrição Mensagem que indica posições angulares ou velocidades angulares para a Tase
seguir, bem como se o modo de estabilização deve estar activo e ainda os rates de
zoom.
Origem/Origens SEP (Detection Module)
Destino(s) SEP (Tase Driver)
Tópico(s) ROS tase_command_in
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
161
Campo Definição
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp,
etc…)
pan float32 graus ou
graus/segundo
Posição angular ou velocidade angular de Pan da câmara.
tilt float32 graus ou
graus/segundo
Posição angular ou velocidade angular de Tilt da câmara.
zoom int8 N/A Movimento de Zoom da câmara. De -8 a 8 em que negativo
significa zoom out e zero indica que não houve qualquer
alteração no zoom.
zoom_timeout uint8 10ms Especificação de quanto tempo a câmara deve fazer zoom
até parar. Zero indica que não há qualquer alteração no
zoom.
flags uint8 N/A Flags que indicam a forma como os dados são
interpretados. Modo 0 a 3 são reservados. Modo 4 – Não
aplicável. Modo 5 –comando de velocidade, estabilização
desligada. Modo 6 - comando de velocidade, estabilização
ligada. Modo 7 - comando de posição, estabilização
desligada. Modo 8 - comando de posição, estabilização
ligada. Modo 9 - comando de impulso, estabilização
desligada. Modo 10 - comando de impulso, estabilização
ligada. Modo 11 e 12 - Não aplicável.
impulse_time uint8 10ms Quantidade de tempo necessária para responder a um
impulso de comando.
Mensagem TASERates
Tabela 28: Definição da mensagem TASERates
Campo Definição
Nome do tipo de mensagem TASERates
Descrição Mensagem que contem a leitura das velocidades angulares do corpo da gimbal, das
velocidades angulares da câmara em relação ao corpo da gimbal.
Origem/Origens SEP (Tase Driver)
Destino(s) SEP (Detection Module)
Tópico(s) ROS tase_rate_out
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
162
Campo Definição
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp,
etc…)
pan float32 graus/segundo Velocidade de rotação, no eixo de Pan, da câmara em
relação ao corpo da gimbal.
tilt float32 graus/segundo Velocidade de rotação, no eixo de Tilt, da câmara em relação
ao corpo da gimbal.
roll float32 graus/segundo Velocidade de rotação, no eixo de Roll, da câmara em
relação ao corpo da gimbal.
mount_roll float32 graus/segundo Velocidade de rotação, no eixo de Roll, do corpo da gimbal.
mount_pitch float32 graus/segundo Velocidade de rotação, no eixo de Pitch, do corpo da gimbal
mount_yaw float32 graus/segundo Velocidade de rotação, no eixo de Yaw, do corpo da gimbal
mode uint8 N/A Modo operacional da Câmara. Modo 0 indica se a
estabilização está activada.
Mensagem TASERawData
Tabela 29: Definição da mensagem TASERawData
Campo Definição
Nome do tipo de mensagem TASERawData
Descrição Mensagem que permite a troca de informação com câmaras que a Tase não
consegue controlar.
Origem/Origens SEP(TASEComms), SEP(TaseDriver)
Destino(s) SEP (Tase Driver), SEP(TASEComms)
Tópico(s) ROS tase_raw_data_out (TASEComms -> TaseDriver)
tase_raw_data_in (TaseDriver -> TASEComms)
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
len uint32 Nº de bytes Tamanho dos dados da mensagem a enviar.
data uint8[ ] N/A Dados da mensagem a enviar.
163
Mensagem TASEZero
Tabela 30: Definição da mensagem TASEZero
Campo Definição
Nome do tipo de mensagem TASEZero
Descrição Mensagem que indica à Tase para “zerar” os sensores de velocidade angular. Apenas
deve ser enviado quando o equipamento não se está a mover.
Origem/Origens SEP (Detection Module)
Destino(s) SEP (Tase Driver)
Tópico(s) ROS tase_zero_in
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
group uint8 N/A Identificador do grupo do pacote.
type uint8 N/A Tipo de pacote, relacionado com o identificador de grupo.
Mensagem TASETelemetry
Tabela 31: Definição da mensagem TASETelemetry
Campo Definição
Nome do tipo de mensagem TASETelemetry
Descrição Mensagem que inclui uma descrição detalhada do estado da Tase e que pode
permitir, entre outras funções, georreferenciar uma determinada imagem.
Origem/Origens SEP (Tase Driver)
Destino(s) SEP (Detection Module)
Tópico(s) ROS tase_telemetry
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
164
Campo Definição
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp,
etc…)
flags uint16 N/A Flags indicadoras de dados no pacote.
mode uint8 N/A Modo operacional da câmara.
camera uint8 N/A Bits de informação da câmara.
time uint32 ms Tempo desde o último reset.
latitude float32 graus Latitude da câmara.
longitude float32 graus Longitude da câmara.
altitude float32 metros Altitude da câmara.
vnorth float32 m/s Componente Norte da velocidade.
veast float32 m/s Componente Este da velocidade.
vdown float32 m/s Componente descendente da velocidade.
mount_roll float32 graus Ângulo de rolamento do corpo da gimbal.
mount_pitch float32 graus Ângulo de pitch do corpo da gimbal.
mount_yaw float32 graus Ângulo de yaw do corpo da gimbal.
pan float32 graus/segundo Ângulo de pan da câmara em relação ao suporte da gimbal.
tilt float32 graus/segundo Ângulo de tilt da câmara em relação ao corpo da gimbal..
roll float32 graus/segundo Ângulo de roll da câmara em relação ao corpo da gimbal.
hfov float32 graus Campo de visão horizontal.
vfov float32 graus Campo de visão vertical.
focus uint16 N/A Posição do foco.
board_temp int8 cº Temperatura
zoom_rate uint16 X Rácio de Zoom. (E.g:. x1, x2, x5, etc)
focus_mode uint8 N/A Modo de foco da câmara.
Especificação de interface SEC2
Tabela 32: Tópicos do SEC2 (P – Publica, S – Subscreve)
Sistema Package Nó Nó ID Tópico P/S Mensagem
SEC2 seagull_comms comms_relay 8 from_comms_relay P SeagullPayload
165
Sistema Package Nó Nó ID Tópico P/S Mensagem
to_comms_relay S SeagullPayload
comms_parameters S CommsParameters
to_sec2_heartbeat P SeagullHeartbeat
seagull_error P SeagullError
seagull_autopilot autopilot_driver
9 from_autopilot P AutopilotPayload
to_autopilot S AutopilotPayload
autopilot_telemetry P AutopilotTelemetry
autopilot_waypoint_
from_ap
P AutopilotWaypoint
autopilot_update_
wp_pos
S AutopilotWaypoint
autopilot_
waypoint_to_ap
S AutopilotWaypoint
autopilot_warning P AutopilotWarning
autopilot_mission_
limits_from_ap
P AutopilotMissionLimits
autopilot_mission_
limits_to_ap
S AutopilotMissionLimits
autopilot_adc_
samples
P AutopilotADCSamples
from_gimbal P AutopilotGimbalPayload
to_gimbal S AutopilotGimbalPayload
autopilot_status P AutopilotStatus
autopilot_wp_list_
from_ap
P AutopilotWPList
autopilot_wp_list_
to_ap
S AutopilotWPList
autopilot_command S AutopilotCommand
autopilot_track S AutopilotTrack
autopilot_request_
waypoints
S AutopilotRequestWaypoint
s
autopilot_user_
action
S AutopilotUserAction
166
Sistema Package Nó Nó ID Tópico P/S Mensagem
autopilot_zero_
length
S AutopilotZeroLength
to_sec2_heartbeat P SeagullHeartbeat
seagull_error P SeagullError
autopilot_comms
10 from_autopilot P AutopilotPayload
to_autopilot S AutopilotPayload
to_sec2_heartbeat P SeagullHeartbeat
Seagull_error P SeagullError
seagull_navigation
control_supervisor
11 cs_status P CsStatus
autopilot_command P AutopilotCommand
to_ap_command S FilteredAutopilotCommand
autopilot_mission_
limits_to_ap
P AutopilotMissionLimits
autopilot_mission_
limits_from_ap
S AutopilotMissionLimits
autopilot_zero_
length
P AutopilotZeroLength
to_sec2_heartbeat S SeagullHeartbeat
to_sep_heartbeat P SeagullHeartbeat
seagul_error P SeagullError
target_tracker_control
12 to_ap_command P FilteredAutopilotCommand
autopilot_telemetry S AutopilotTelemetry
target_location S TargetLocation
to_sec2_heartbeat P SeagullHeartbeat
seagull_error P SeagullError
sense_and_avoid 13 to_ap_command P FilteredAutopilotCommand
autopilot_telemetry S AutopilotTelemetry
to_sec2_heartbeat P SeagullHeartbeat
seagull_error P SeagullError
adsb_driver 14 adsb_output P ADSBOutput
167
Tabela 33: Serviços do SEC2
Sistema Package Nó Serviço Parâmetros In/Out
SEC2
seagull_navigation
control_supervisor requestAction ActionRequest BoolResponse
target_tracker_control activate bool value BoolResponse
sense_and_avoid activate bool value BoolResponse
Mensagem SeagullPayload
Tabela 34: Definição da mensagem SeagullPayload
Campo Definição
Nome do tipo de mensagem SeagullPayload
Descrição Mensagens que contêm os dados destinados ao ou provenientes do VANT (isto é,
enviados do VANT para a ETP ou vice-versa). O componente Comms Relay será
sempre a origem ou destinatário de mensagens deste tipo.
Origem/Origens SEC2 (Comms Relay), SEP (Seagull Manager)
Destino(s) SEP (Seagull Manager), SEC2 (Comms Relay)
Tópico(s) ROS from_comms_relay (sentido ETP – VANT)
to_comms_relay (sentido VANT – ETP)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
requiresAck bool N/A Indicação se a receção da mensagem a enviar terá de ser
do tipo confirmada (i.e., com garantia de entrega). Esta
indicação apenas é relevante para o pedido de envio de
mensagens para o VANT, não para a receção de mensagens
do VANT.
length uint32 Nº de bytes Tamanho dos dados da mensagem a enviar.
data uint8[] N/A Dados da mensagem a enviar/recebidos pelo Comms
Relay através do PAYLOAD_STREAM do Piccolo (envio esse
feito de forma indireta, o envio / receção direto é feito pelo
Autopilot Driver).
168
Mensagem CommsParameters
Tabela 35: Definição da mensagem CommsParameters
Campo Definição
Nome do tipo de mensagem CommsParameters
Descrição Mensagem que permite configurar/ajustar, em runtime, os parâmetros associados
às comunicações por forma a adaptar a condições mais difíceis de comunicação.
Origem/Origens SEP (Seagull Manager)
Destino(s) SEC2 (Comms Relay)
Tópico(s) ROS comms_parameters (sentido ETP – VANT)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
retries uint8 N/A Número de vezes que se deve reenviar um fragmento de
uma mensagem quando detetado ACK timeout.
timeout uint16 milissegundos Tempo esperado para receber um ACK de um envio de um
fragmento de uma mensagem.
dispatchRate uint16 Hz Taxa de envio de fragmentos para o payload stream
(número de fragmentos por segundo)
Mensagem AutopilotPayload
Tabela 36: Definição da mensagem AutopilotPayload
Campo Definição
Nome do tipo de mensagem AutopilotPayload
Descrição Mensagens que contêm os dados destinados ao ou provenientes do VANT (isto é,
enviados do VANT para a ETP ou vice-versa). O componente Autopilot Driver será
sempre a origem ou destinatário de mensagens deste tipo. Os dados contidos nesta
mensagem são os dados recebidos (ou a enviar) diretamente no PAYLOAD_STREAM
do Piccolo.
Origem/Origens SEC2 (Comms Relay), SEC2 (Autopilot Driver)
Destino(s) SEC2 (Autopilot Driver), SEC2 (Comms Relay)
Tópico(s) ROS from_autopilot (sentido ETP – VANT)
to_autopilot (sentido VANT – ETP)
169
Campo Definição
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do
Seagull.
length uint8 Nº de bytes Tamanho dos dados da mensagem a enviar.
Data uint8[] N/A Dados da mensagem a enviar/recebidos pelo Autopilot
Driver através do PAYLOAD_STREAM do Piccolo.
Mensagem AutopilotTelemetry
Tabela 37: Definição da mensagem AutopilotTelemetry
Campo Definição
Nome do tipo de mensagem AutopilotTelemetry
Descrição Telemetria de navegação do VANT disponibilizada pelo Autopilot (Piccolo).
Origem/Origens SEC2 (Autopilot Driver)
Destino(s) SEP (Seagull Manager)
SEP (Detection Module)
SEC2 (Target Tracker)
SEC2 (Sense and Avoid)
Tópico(s) ROS autopilot_telemetry
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
latitude float32 graus Posição do VANT.
longitude float32 graus Posição do VANT.
altitude float32 m Altitude do VANT, em cm acima de 1000m abaixo de
WGS84.
ias uint16 m/s IAS do VANT. 0 indica -2000 cm/s.
170
Nome Tipo Unidades Descrição
vx int16 m/s Componente x da groundspeed.
vy int16 m/s Componente y da groundspeed.
vz int16 m/s Componente z da groundspeed.
roll int16 graus Ângulo Euler do roll do VANT de –PI a PI.
pitch int16 graus Ângulo Euler do pitch do VANT de –PI/2 a PI/2.
yaw uint16 graus Ângulo Euler do yaw do VANT de 0 a 2PI.
barometricAltitude uint32 cm Altitude barométrica em centímetros acima de 1000m
abaixo de zero.
windSouth int16 cm/s Valor do vento vindo do Sul.
windWest int16 cm/s Valor do vento vindo do Oeste.
leftRPM uint16 RPM RPM do motor esquerdo.
rightRPM uint16 RPM RPM do motor direito.
staticPressure uint16 Pa Pressão estática em unidades de 2 Pascal.
accelX int16 0.005 m/s2 Aceleração no eixo dos XX em unidades de 0.005 m/s2.
accelY int16 0.005 m/s2 Aceleração no eixo dos YY em unidades de 0.005 m/s2.
accelZ int16 0.005 m/s2 Aceleração no eixo dos ZZ em unidades de 0.005 m/s2.
Mensagem AutopilotWarning
Tabela 38: Definição da mensagem AutopilotWarning
Campo Definição
Nome do tipo de mensagem AutopilotWarning
Descrição Mensagem utilizada para transportar mensagens de aviso enviadas pelo AP quando
detetado algum comando ou ação incorretos ou fora de parâmetros de missão
Origem/Origens SEC2 (AutopilotDriver)
Destino(s) SEC2 (ControlSupervisor)
Tópico(s) ROS autopilot_warning
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum às mensagens ROS do Seagull
171
Nome Tipo Unidades Descrição
command uint8 N/A Código interno do comando que originou o aviso.
code uint8 N/A Código interno da mensagem do aviso.
message string N/A Texto da mensagem de aviso
Mensagem AutopilotUserAction
Tabela 39: Definição da mensagem AutopilotUserAction
Campo Definição
Nome do tipo de mensagem AutopilotUserAction
Descrição Mensagem utilizada para assinalar uma ação pedida pelo operador da estação de
terra. Estas ações são parametrizáveis na ETC2 com um código e podem ser
interpretadas a bordo para ação.
Origem/Origens SEC2 (AutopilotDriver)
Destino(s) SEC2 (ControlSupervisor)
Tópico(s) ROS autopilot_user_action
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum às mensagens ROS do Seagull
action uint8 0-7 Código da ação assinalada. Existe um limite de 8 ações com
códigos de 0 a 7
on bool N/A Assinala se a ação foi ativada ou desativada.
Mensagem AutopilotMissionLimits
Tabela 40: Definição da mensagem AutopilotMissionLimits
Campo Definição
Nome do tipo de mensagem AutopilotMissionLimits
Descrição Mensagem utilizada para obter limites do AP estabelecidos pelo operador de terra.
Nota: Esta mensagem se for enviada para o AP com o campo ‘request’ a ‘true’ (os
outros campos não são considerados) faz com que o AP responda com uma
mensagem com os campos atualizados
Origem/Origens SEC2 (AutopilotDriver)
172
Campo Definição
Destino(s) SEC2 (ControlSupervisor)
Tópico(s) ROS autopilot_mission_limits
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum às mensagens ROS do Seagull
request bool N/A Código interno do comando que originou o aviso.
comms_timeout uint32 ms Nº máximo de milissegundos passados entre pacotes
recebidos da estação de terra para ser assinalada uma falha
de comunicação
pilot_timeout uint32 ms Nº máximo de milissegundos passados entre pacotes
recebidos do piloto, passados quais passa a modo
automático.
gps_timeout uint32 ms Nº máximo de milissegundos passados desde a última
receção de dados GPS, passados quais é assinalada uma
falha de GPS.
lost_comms_wp uint8 N/A Waypoint para o qual se deve dirigir o VANT após detetada
uma falha de comunicação
autoland_wp uint8 N/A Waypoint inicial definido para a manobra de aterragem
automática
altitude_min uint16 m Altitude mínima a que o VANT pode operar (quando violada
gera um aviso).
altitude_max uint16 m Altitude máxima a que o VANT pode operar.
fligth_timeout uint32 s Tempo estipulado para a missão (quando ultrapassado, gera
um aviso).
failure0 uint8 N/A Byte 0 flags associadas a ações a quando detetadas falhas
failure1 uint8 N/A Byte 1 flags associadas a ações a quando detetadas falhas
Mensagem CsStatus
Tabela 41: Definição da mensagem CsStatus
Campo Definição
Nome do tipo de mensagem CsStatus
Descrição Mensagem utilizada para comunicação entre o Control Supervisor e o Seagull
Manager fornecendo o estado do S2SN e do S&A.
173
Campo Definição
Origem/Origens SEC2 (Control Supervisor)
Destino(s) SEP (Seagull Manager)
Tópico(s) ROS cs_status
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
s2sn_status bool N/A Estado do Slave to Sensor Navigation (S2SN).
s2sn_id bool N/A Id do objeto a ser seguido (relevante apenas caso o S2SN
esteja activo)
Mensagem BoolResponse
Tabela 42: Definição da mensagem BoolResponse
Campo Definição
Nome do tipo de mensagem BoolResponse
Descrição Mensagem utilizada para retorno de uma condição de chamada a um serviço
(pode ser usada para compor outras mensagens que necessitem de usar um
mecanismo de retorno booleano com mensagem de motivo)
Servidor(es) target_tracker_control, sense_and_avoid_control, control_supervisor
Cliente(s) control_supervisor
Serviços ROS sa_activate_srv ,tt_activate_srv, cs_request_action_srv
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
ok bool N/A Estado
msg String N/A Mensagem associada ao estado, em caso de erro pode
devolver uma mensagem com o motivo do erro
174
Mensagem ActionRequest
Tabela 43: Definição da mensagem ActionRequest
Campo Definição
Nome do tipo de mensagem ActionRequest
Descrição Mensagem usada para fazer um pedido ao ControlSupervisor, por exemplo Slave to
Sensor Navigation (serve para iniciar ou cancelar)
Servidor(es) control_supervisor (parâmetro de entrada)
Cliente(s) seagull_manager, sense_and_avoid
Serviços ROS cs_request_action_srv
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
action int N/A Identificador da Acão (1- S2SN; 2-S&A).
activate bool N/A Flag que indica se é para ativar ou cancelar (True – Ativar,
False-Cancelar).
Mensagem ADSBOutput
Tabela 44: Definição da mensagem ADSBOutput
Campo Definição
Nome do tipo de mensagem ADSBOutput
Descrição Mensagem utilizada para comunicar ao módulo de Sense and Avoid a posição de
outros VANT.
Origem/Origens SEC2 (ADSB Driver)
Destino(s) SEC2 (Sense And Avoid)
Tópico(s) ROS adsb_output
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header Std_msgs/Header N/A Cabeçalho com informação adicional (Id, time stamp, etc…)
id uint32 N/A Identificador único do VANT detetado.
latitude float32 graus Latitude do VANT detetado.
longitude float32 graus Longitude do VANT detetado.
175
Nome Tipo Unidades Descrição
altitude float32 m Altitude do VANT detetado.
time uint16 ms Timestamp da deteção.
Mensagem AutopilotCommand
Tabela 45: Definição da mensagem AutopilotCommand
Campo Definição
Nome do tipo de mensagem AutopilotCommand
Descrição Mensagem utilizada para enviar comandos de baixo nível para o Autopilot
Origem/Origens SEC2 (Control Supervisor)
Destino(s) SEC2 (Autopilot Driver)
Tópico(s) ROS autopilot_command
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica no caso de S&A ou TT estarem activos.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
command_code uint8 N/A Tipo de comando a executar no autopilot (0-IAS; 1-Altitude;
2-Bank; 3- Flaps; 4-Heading; 5-VRate; 6-Pitch).
value float32 N/A Valor do comando a executar.
Mensagem FilteredAutopilotCommand
Tabela 46: Definição da mensagem FilteredAutopilotCommand
Campo Definição
Nome do tipo de mensagem AutopilotCommand
Descrição Mensagem utilizada para enviar comandos de baixo nível para o Autopilot. Esta
mensagem é analisada pelo Control Supervisor que é quem decide a sua publicação
ou não para o Autopilot.
Origem/Origens SEC2 (Sense And Avoid e Target Tracker)
Destino(s) SEC2 (Control Supervisor)
Tópico(s) ROS to_ap_command
Necessita de resposta Não.
176
Campo Definição
Frequência da mensagem Mensagem é cíclica no caso de S&A ou TT estarem activos.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
action uint8 N/A Identificador da ação associada ao comanda (1-S2SN; 2-
S&A).
command AutopilotCommand N/A Mensagem do tipo AutopilotCommand.
Mensagem AutopilotGimbalPayload
Tabela 47: Definição da mensagem AutopilotGimbalPayload
Campo Definição
Nome do tipo de mensagem AutopilotGimbalPayload
Descrição Mensagem de configuração de Gimbal Steering.
Origem/Origens SEC2 (Tase Comms), SEC2 (Autopilot Driver)
Destino(s) SEC2 (Autopilot Driver), SEC2 (Tase Comms)
Tópico(s) ROS to_gimbal (Tase Comms -> Autopilot Driver)
from_gimbal (Autopilot Driver -> Tase Comms)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
len uint32 N/A Tamanho do vetor data.
data uint8[ ] N/A Dados da mensagem.
Mensagem AutopilotADCSamples
Tabela 48: Definição da mensagem AutopilotADCSamples
Campo Definição
Nome do tipo de mensagem AutopilotADCSamples
Descrição Mensagem utilizada para receber as amostras das linhas analógicas do Piccolo. É
enviada com uma taxa especificada no pacote de setup da linha I/O. Contém
amostras de todas as 4 linhas analógicas.
177
Campo Definição
Origem/Origens SEC2 (Autopilot Driver)
Destino(s) N/A (Mensagem definida para possível debug)
Tópico(s) ROS autopilot_ads_samples
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
analog1 int32 N/A Amostras da linha analógica 1.
analog2 int32 N/A Amostras da linha analógica 2.
analog3 int32 N/A Amostras da linha analógica 3.
analog4 int32 N/A Amostras da linha analógica 4.
Mensagem AutopilotStatus
Tabela 49: Definição da mensagem AutopilotStatus
Campo Definição
Nome do tipo de mensagem AutopilotStatus
Descrição Status posicional de navegação do VANT disponibilizada pelo Autopilot (Piccolo).
Origem/Origens SEC2 (Autopilot Driver)
Destino(s) SEC2(Control Supervisor)
Tópico(s) ROS autopilot_status
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do
Seagull.
orbitRadius uint8 Metros Raio da órbita, em 10 ou 50 avos de metros, se o sistema
estiver a orbitar de acordo com o estado do tracker. O
multiplicador de 10 ou 50 depende da configuração.
trackerStatus uint8 N/A Estado do tracker. Indica se o VANT se encontra a orbitar
em alguma rota.
178
Nome Tipo Unidades Descrição
timeToWp uint16 Segundos Tempo estimado de chegada ao próximo waypoint.
wpFrom uint8 N/A Índice do waypoint anterior.
wpTo uint8 N/A Índice do waypoint seguinte.
airBoundaryViolated bool N/A Violação da barreira de espaço aéreo. (1- Violada; 0 –
Não violada).
autopilotEngineKill bool N/A Paragem do motor. (1- Ordem para parar o motor ativa; 0-
ordem para parar o motor inativa).
commsTimeout bool N/A Final do tempo de comunicações. (1- Tempo terminou; 0-
Tempo ainda não terminou).
flightTimerElapsed bool N/A Tempo de voo. (1- Tempo de voo terminou; 0- Tempo de
voo ainda não terminou).
flightTermination bool N/A Terminar voo. (1- Ordem para terminar o voo está ativa; 0-
Ordem para terminar o voo não está ativa).
gpsTimeout bool N/A Final do tempo de GPS. (1- Tempo terminou; 0- Tempo
ainda não terminou).
orbiting bool N/A A orbitar. (1- Se estiver a orbitar; 0- Se não estiver a
orbitar).
loopControl1 uint8 N/A Estado do loop 1.
loopControl2 uint8 N/A Estado do loop 2.
loopControl3 uint8 N/A Estado do loop 3.
loopControl4 uint8 N/A Estado do loop 4.
loopControl5 uint8 N/A Estado do loop 5.
loopControl6 uint8 N/A Estado do loop 6.
loopControl7 uint8 N/A Estado do loop 7.
loopControl8 uint8 N/A Estado do loop 8.
loopControlCount uint8 N/A Número de loops que o controlador suporta.
userAction0 bool N/A Ação de utilizador 0. (1- Ação ativa; 0- Ação inativa).
userAction1 bool N/A Ação de utilizador 1. (1- Ação ativa; 0- Ação inativa).
userAction2 bool N/A Ação de utilizador 2. (1- Ação ativa; 0- Ação inativa).
userAction3 bool N/A Ação de utilizador 3. (1- Ação ativa; 0- Ação inativa).
userAction4 bool N/A Ação de utilizador 4. (1- Ação ativa; 0- Ação inativa).
userAction5 bool N/A Ação de utilizador 5. (1- Ação ativa; 0- Ação inativa).
userAction6 bool N/A Ação de utilizador 6. (1- Ação ativa; 0- Ação inativa).
userAction7 bool N/A Ação de utilizador 7. (1- Ação ativa; 0- Ação inativa).
179
Mensagem AutopilotZeroLength
Tabela 50: Definição da mensagem AutopilotZeroLength
Campo Definição
Nome do tipo de mensagem AutopilotZeroLength
Descrição Mensagem utilizada para o envio de pacotes para o autopilot. Pacotes, tais como
CONFIG_LOCK e CONFIG_UNLOCK não necessitam de password utilizando esta
mensagem.
Origem/Origens SEC2 (Control Supervisor)
Destino(s) SEC2 (Autopilot Driver)
Tópico(s) ROS autopilot_zero_length
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
messageType int8 N/A Tipo da mensagem a enviar (número do pacote). (Ex:. 23 –
CONFIG_UNLOCK_QUIET).
180
181
Anexo C – Interfaces terra-ar
As mensagens descritas de seguida definem as mensagens trocadas na comunicação entre
a ETP e o SEP (e vice-versa), mais concretamente entre o ETP ROS Interface e o Seagull
Manager presente no SEP. Todas as mensagens desta secção são mensagens Mavlink sendo
posteriormente encapsuladas em mensagens ROS do tipo SeagullPayload (descrita na Tabela
66) para envio pelos componentes CommsRelay em execução tanto na ETP como no SEP.
Mensagem Mavlink MissionDefinition
Tabela 51: Mensagem MissionDefinition
Campo Definição
Descrição Mensagem que define o tipo de missão a executar pelo VANT e a respetiva área de
interesse.
Origem ETP (ETP ROS Interface)
Destino SEP (Seagull Manager)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Sim.
Definição MavLink <message id=”150” name=”MISSIONDEFINITION”>
<description>Define a missão do VANT</description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type=”char[150]” name=”mission_name”> Nome da missão a
executar.</field>
<field type=”uint8_t” name=”mission_type”>Identificador da configuração de
missão a ser executada pelo VANT. 0 (zero) indica que ainda não foi recebida
nenhuma definição de missão.</field>
</message>
Mensagem Mavlink RequestImage
Tabela 52: Mensagem RequestImage
Campo Definição
Descrição Mensagem que requisita o envio de uma fotografia ao VANT. Uma fotografia pode
ser pedida a um sensor específico ou sobre um objeto detetado em particular.
Origem ETP (ETP ROS Interface)
Destino SEP (Seagull Manager)
182
Campo Definição
Necessita de resposta Sim, uma mensagem do tipo ImageData.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Sim.
Definição MavLink <message id=”151” name=”REQUESTIMAGE”>
<description>Requisita uma imagem para ser enviada pelo UAV (de um objeto ou de
um sensor específico) </description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type=”uint8_t” name=”type”>Define o tipo de pedido de imagem, 0 para
sensor ou 1 para objeto previamente detetado.</field>
<field type=”uint16_t” name=”id”>Representa ou o identificador único de um
sensor, ou o identificador único de um objeto detetado, conforme o tipo de
pedido.</field>
</message>
Mensagem Mavlink FollowTarget
Tabela 53: Mensagem FollowTarget
Campo Definição
Descrição Mensagem que pede ao VANT para seguir, ou deixar de seguir, um qualquer objeto
detetado pelos seus sensores.
Origem ETP (ETP ROS Interface)
Destino SEP (Seagull Manager)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Sim.
Definição MavLink <message id=”152” name=”FOLLOWTARGET”>
<description>Requisita ao UAV para seguir (ou deixar de seguir) um objeto com o
identificador enviado.</description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type=”uint8_t” name=”action”>Define a ação a executar requisitada, , 0 para
desativar a (S2SN), ou 1 para a ativar.</field>
<field type=”uint8_t” name=”id”>O identificador único de um objeto detetado
requisitado para ser seguido. Parâmetro irrelevante quando a ação requisitada é a
desativação da funcionalidade S2SN.</field>
</message>
183
Mensagem Mavlink DmDebug Tabela 54: Mensagem DMDebug
Campo Definição
Descrição Mensagem que envia para o VANT e recebe do mesmo valores de DEBUG do
Detection Module
Origem ETP (ETP ROS Interface), SEP (Seagull Manager)
Destino SEP (Seagull Manager), ETP (ETP ROS Interface)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não.
Definição MavLink <message id=”153” name=”DMDEBUG”>
<description> Envia para o VANT e recebe do mesmo valores de DEBUG do Detection
Module.</description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type=”int32_t” name=”cmd”>Comando a ser pedido.</field>
<field type=”int32_t” name=”param”>Nome do parâmetro.</field>
<field type=”int32_t” name=”iVal1”>Valor DEBUG.</field>
<field type=”int32_t” name=”iVal2”>Valor DEBUG.</field>
<field type=”int32_t” name=”iVal3”>Valor DEBUG.</field>
<field type=”float” name=”fVal1”>Valor DEBUG.</field>
<field type=” float” name=”fVal2”>Valor DEBUG.</field>
<field type=” float” name=”fVal3”>Valor DEBUG.</field>
</message>
Mensagem Mavlink PayloadTelemetry Tabela 55: Mensagem PayloadTelemetry
Campo Definição
Descrição Mensagem cíclica contendo a telemetria genérica do estado do SEP. De notar que
esta mensagem enviada é enviada com um determinado período, período esse que
pode ser encurtado em determinadas ocasiões, já que uma mensagem deste tipo
será enviada assim que existir um mudança de estado motivada por uma
comunicação da ETP (e.g., ativação da funcionalidade de slave to sensor navigation).
Origem SEP (Seagull Manager)
Destino ETP (ETP ROS Interface)
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não.
184
Campo Definição
Definição MavLink <message id=”200” name=”PAYLOADTELEMETRY”>
<description> Telemetria cíclica do Sistema de Payload.</description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type=”char[150]” name=”mission_name”> Nome da missão em
execução.</field>
<field type=”uint8_t” name=”mission_type”>Identificador da configuração de
missão atualmente a ser executada pelo VANT. 0 (zero) indica que ainda não foi
recebida nenhuma definição de missão.</field>
<field type=”boolean” name=”s2sn_status”>Status da navegação slave to sensor
navigation, 1 para indicar que a funcionalidade se encontra ativada, ou 0 para
indicar que está desativada.</field>
<field type=”uint8_t” name=”s2sn_id”>O identificador único do objeto detetado
que está a ser seguido (relevante apenas caso o status indica que a S2SN está
ativada.</field>
<field type=”uint8_t” name=”tase_status”>Status do sensor da câmara Tase, 1
para indicar que o sensor está ligado e operacional, ou 0 para indicar que está
desligado.</field>
<field type=”uint8_t” name=”gobi_status”>Status do sensor da câmara Gobi, 1
para indicar que o sensor está ligado e operacional, ou 0 para indicar que está
desligado.</field>
<field type=”uint8_t” name=”jai_eo_status”>Status do sensor da câmara Jai no
espetro EO, 1 para indicar que o sensor está ligado e operacional, ou 0 para indicar
que está desligado.</field>
<field type=”uint8_t” name=”jai_nir_status”>Status do sensor da câmara Jai no
espetro NIR, 1 para indicar que o sensor está ligado e operacional, ou 0 para indicar
que está desligado.</field>
<field type=”uint8_t” name=”sensor_ais_status”>Status do sensor da AIS, 1 para
indicar que o sensor está ligado e operacional, ou 0 para indicar que está
desligado.</field>
</message>
Mensagem Mavlink PayloadEvent Tabela 56: Mensagem PayloadEvent
Campo Definição
Descrição Mensagem despoletada quando o VANT pretende notificar o operador de payload de
um acontecimento (e.g., deteção de um novo objeto visível nos seus sensores).
Origem SEP (Seagull Manager)
Destino ETP (ETP ROS Interface)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Sim.
185
Campo Definição
Definição MavLink <message id=”201” name=”PAYLOADEVENT”>
<description>Envia um evento de payload para terra.</description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type=”uint8_t” name=”event_type”>Tipo do evento:
1 – Novo objeto detetado.
2 – O objeto a ser perseguido (S2SN) desapareceu da linha de visão. </field>
<field type=”uint8_t” name=”object_id”>Identificador único do objeto que originou
o evento (se aplicável). 0 se não aplicável.</field>
<field type=”float” name=”latitude”>A latitude do VANT quando o evento
ocorreu.</field>
<field type=”float” name=”longitude”> A longitude do VANT quando o evento
ocorreu.</field>
<field type=”uint8_t” name=”object_type”>O tipo do objeto detetado que originou
o evento, se aplicável. Valor é 0 caso não seja aplicável (outro tipo de
evento).</field>
<field type=”float” name=”object_lat”>A latitude do objeto detetado que originou
o evento, se aplicável. 0 (zero) caso não aplicável (outro tipo de evento).</field>
<field type=”float” name=”object_long”> A longitude do objeto detetado que
originou o evento, se aplicável. 0 caso não aplicável (outro tipo de evento).</field>
<field type=”int16” name=”object_vx”> A velocidade do objeto detetado que
originou o evento, no eixo x em relação a um referencial inercial global, se aplicável.
Valor é 0 caso não aplicável (outro tipo de evento). </field>
<field type=”int16” name=”object_vy A velocidade do objeto detetado que originou
o evento, no eixo y em relação a um referencial inercial global, se aplicável. Valor é
0 caso não aplicável (outro tipo de evento). </field>
<field type=”char[150]” name=”event_msg”>Mensagem explicativa do
evento.</field>
</message>
Mensagem Mavlink ImageData Tabela 57: Mensagem ImageData
Campo Definição
Descrição Mensagem que contém uma imagem enviada pelo VANT. De notar que a imagem
não se encontra presente nos campos mavlinks, mas sim imediatamente após os
mesmos, portanto a mensagem terá o tamanho total em bytes de sizeof(imagedata)
+ (rows * columns *depth).
Mensagens deste tipo são enviadas a pedido da ETP ou espontaneamente pelo SEP
(e.g., quando um novo objeto é detetado pelo UAV).
Origem SEP (Seagull Manager)
Destino ETP (ETP ROS Interface)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
186
Campo Definição
Necessita de garantia de entrega Sim.
Definição MavLink <message id=”202” name=”IMAGEDATA”>
<description>Mensagem que contém uma imagem enviada pelo VANT
</description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type=”uint16_t” name=”requested_id”>Identificador único da imagem.
Caso a imagem do tipo sensor o id corresponde à tabela seguinte, caso seja do tipo
objeto apenas corresponde ao número do objeto.
0 – Caso não aplicável.
1 – Câmara TASE;
2 – Câmara GOBI:
3 – Câmara JAI_EO;
3 – Câmara JAI_NIR; </field>
<field type=”uint8_t” name=”image_type”> Tipo de imagem (Sensor ou
Object).</field>
<field type=”float” name=”latitude”>A latitude do VANT quando a imagem foi
recolhida.</field>
<field type=”float” name=”longitude”> A longitude do VANT quando a imagem foi
recolhida.</field>
<field type=”uint16_t” name=”rows”>O numero de linhas que a imagem
contém.</field>
<field type=”uint16_t” name=”columns”> O numero de colunas que a imagem
contém.</field>
<field type=”uint8_t” name=”depth”>A densidade de cor da imagem, expressa em
número de bytes.</field>
<field type=”uint8_t” name=”object_type”>O tipo do objeto na imagem, se
aplicável. Valor é 0 se não for aplicável.</field>
<field type=”float” name=”object_lat”>A latitude do objeto na imagem, se
aplicável. Valor é 0 se não for aplicável.</field>
<field type=”float” name=”object_long”> A longitude do objeto na imagem, se
aplicável. Valor é 0 se não for aplicável.</field>
<field type=”int16” name=”object_vx”> A velocidade do objeto na imagem, no eixo
x em relação a um referencial inercial global, se aplicável. Valor é 0 se não for
aplicável </field>
<field type=”int16” name=”object_vy”> A velocidade do objeto na imagem, no eixo
y em relação a um referencial inercial global, se aplicável. Valor é 0 se não for
aplicável </field>
</message>
187
Mensagem Mavlink PayloadError Tabela 58: Mensagem PayloadError
Campo Definição
Descrição Mensagem despoletada quando o VANT pretende notificar o operador de payload de
um erro (e.g., parâmetros de missão enviados inválidos).
Origem SEP (Seagull Manager)
Destino ETP (ETP ROS Interface)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Sim.
Definição MavLink <message id=”203” name=”PAYLOADERROR”>
<description>Mensagem que contém erros ocorridos, e que devem ser enviados
para terra. </description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type=”uint8_t” name=”error_type”>Tipo de erro:
1 – Pedido requisitado com um Sensor ID inválido (inexistente).
2 – Pedido requisitado com um Object ID inválido (inexistente).
3 – Envio de definição de missão com parâmetros inválidos.
4 – Falha na chamada ao serviço ActivateControlSupervisor
5 – Falha em sensor: JAI_EO
6 – Falha em sensor: JAI_NIR
7 – Falha em sensor: GOBI
8 – Falha em sensor: TASE
9 – Falha em sensor: AIS
10 – Falha no DetectionModule
11 – Falha de heartbeat (qualquer dos módulos, complementado pelo campo
error_msg)
</field>
<field type=”float” name=”latitude”>A latitude do VANT quando o erro
ocorreu.</field>
<field type=”float” name=”longitude”> A longitude do VANT quando o erro
ocorreu.</field>
<field type=”char[150]” name=”error_msg”>Mensagem de erro como
complemento de informação.</field>
</message>
188
Mensagem Mavlink ObjectList Tabela 59: Mensagem ObjectList
Campo Definição
Descrição Mensagem despoletada quando o VANT pretende notificar o operador de payload de
um erro (e.g., parâmetros de missão enviados inválidos).
Origem SEP (Seagull Manager)
Destino ETP (ETP ROS Interface)
Necessita de resposta Não.
Frequência da mensagem Mensagem cíclica.
Necessita de garantia de entrega Sim.
Definição MavLink <message id=”204” name=”OBJECTLIST”>
<description>Mensagem que contém a lista mais recente de objetos detetados
pelos módulos a bordo do VANT. </description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type="float" name="latitude">A latitude do VANT quando a lista foi
atualizada.</field>
<field type="float" name="longitude">A longitude do VANT quando a lista foi
atualizada.</field>
<field type="uint8_t" name="number_of_objects">O numero de objetos na
lista.</field>
</message>
Mensagem Mavlink Object Tabela 60: Mensagem Object
Campo Definição
Descrição Mensagem que contém um objeto, enviada pelo VANT. De notar que, no caso de
existir mais do que um objeto visível, mais mensagens deste tipo serão enviadas
(uma mensagem por objeto).
Mensagens deste tipo são enviadas ciclicamente pelo SEP.
Origem SEP (Seagull Manager)
Destino ETP (ETP ROS Interface)
Necessita de resposta Não.
Frequência da mensagem Mensagem cíclica.
Necessita de garantia de entrega Sim.
189
Campo Definição
Definição MavLink <message id=”205” name=”OBJECT”>
<description>Mensagem que contém um objeto detetado pelos módulos a bordo do
VANT</description>
<field type=”uint8_t” name=”object_id”>Identificador único do objeto.
<field type=”uint8_t” name=”object_type”>O tipo do objeto.</field>
<field type=”float” name=”object_lat”>A latitude do objeto.</field>
<field type=”float” name=”object_long”> A longitude do objeto.</field>
<field type=”int16” name=”object_vx”> A velocidade do objeto, no eixo x em
relação a um referencial inercial global.</field>
<field type=”int16” name=”object_vy”> A velocidade do objeto, no eixo y em
relação a um referencial inercial global. </field>
</message>
Mensagem Mavlink TargetObject Tabela 61: Mensagem TargetObject
Campo Definição
Descrição Mensagem que contem informação sobre o objeto a ser seguido.
Origem SEP (Seagull Manager)
Destino ETP (ETP ROS Interface)
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica (apenas quando o VANT está a seguir um objeto).
Necessita de garantia de entrega Não.
Definição MavLink <message id=”206” name=”TARGETOBJECT”>
<description>Mensagem que contém informação sobre o objeto a ser
seguido.</description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
<field type="uint8_t" name="object_id">Identificador único do objeto.</field>
<field type="uint8_t" name="object_type">O tipo do objeto detetado.</field>
<field type="float" name="object_lat">A latitude do objeto.</field>
<field type="float" name="object_long">A longitude do objeto.</field>
<field type="int16_t" name="object_vx">A velocidade do objeto detetado, no
eixo x em relação a um referencial inercial global.</field>
<field type="int16_t" name="object_vy">A velocidade do objeto detetado, no
eixo y em relação a um referencial inercial global.</field>
</message>
190
Mensagem Mavlink Heartbeat Tabela 62: Mensagem Heartbeat
Campo Definição
Descrição Mensagem que contem sinal de Heartbeat.
Origem SEP (Seagull Manager), ETP (ETP ROS Interface)
Destino ETP (ETP ROS Interface), SEP (Seagull Manager)
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não.
Definição MavLink <message id=”207” name=”HEARTBEAT”>
<description>Mensagem que contém sinal de Heartbeat.</description>
<timestamp type="uint64_t>Timestamp da mensagem</timestamp>
</message>
191
Especificação de interfaces ETP
As mensagens ROS descritas nesta secção são as trocadas em tópicos ROS intra-ETP (i.e.,
entre nós ROS em execução na ETP). Pelo menos parte destas mensagens serão também
trocadas no VANT (entre SEC2 e SEP), estando a definição dessas mensagens presente no
Anexo B. Na tabela seguinte é apresentado um resumo das comunicações do sistema da ETP,
indicando os tópicos e mensagens que cada nó publicará e/ou subscreverá (P-Publica, S-
Subscreve).
Tabela 63: Resumo de Comunicações ETP
Sistema Nó Tópico P/S Mensagem
ETP
ETP ROS Interface
autopilot_telemetry S AutopilotTelemetry
to_comms_relay P SeagullPayload
from_comms_relay S
autopilot_waypoint_to_ap P AutopilotWaypoint
autopilot_waypoint_from_ap S
autopilot_request_waypoints P AutopilotRequestWaypoints
autopilot_wp_list_to _ap P AutopilotWPList
autopilot_wp_list_from_ap S
autopilot_status S AutopilotStatus
autopilot_track P AutopilotTrack
Comms Relay
to_comms_relay S SeagullPayload
from_comms_relay P
to_autopilot P AutopilotPayload
from_autopilot S
Autopilot Driver
autopilot_telemetry P AutopilotTelemetry
to_autopilot S AutopilotPayload
from_autopilot P
autopilot_waypoint_to_ap S AutopilotWaypoint
autopilot_waypoint_from_ap P
autopilot_request_waypoints S AutopilotRequestWaypoints
192
Sistema Nó Tópico P/S Mensagem
autopilot_wp_list_to _ap S AutopilotWPList
autopilot_wp_list_from_ap P
autopilot_status P AutopilotStatus
autopilot_track S AutopilotTrack
Definição de Estruturas Comuns de Mensagens ETP
A estrutura seguinte é comum a algumas mensagens ROS utilizadas na ETP.
Tabela 64: Definição de estrutura SeagullHeader
Campos da mensagem
Tipo Unidade Nome Descrição
Header N/A Header Cabeçalho padrão ROS que inclui um campo de timestamp.
uint16 N/A vehicleId Identificador do VANT para onde a mensagem se destina ou
provém.
Definição de Mensagens intra ETP
As tabelas seguintes definem as mensagens ROS que circulam no bus ROS da ETP.
Mensagem AutopilotTelemetry
Tabela 65: Mensagem AutopilotTelemetry
Campo Definição
Nome do tipo de mensagem AutopilotTelemetry
Descrição Telemetria de navegação do VANT disponibilizada pelo Autopilot (Piccolo).
Origem/Origens ETP (Autopilot Driver)
Destino(s) ETP (ETP ROS Interface)
Tópico(s) ROS autopilot_telemetry
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica. Frequência definida pelas configurações do AP (tipicamente
1hz).
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
193
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
latitude float32 graus Posição do VANT.
longitude float32 graus Posição do VANT.
altitude float32 m Altitude do VANT
ias uint16 m/s Indicated Air Speed do VANT
vx int16 m/s Componente x da groundspeed.
vy int16 m/s Componente y da groundspeed.
vz int16 m/s Componente z da groundspeed.
roll int16 graus Ângulo Euler do roll do VANT, de –PI a PI.
pitch int16 graus Ângulo Euler do pitch do VANT, de –PI/2 a PI/2.
yaw float32 graus Ângulo Euler do yaw do VANTde 0 a 2PI.
barometricAltitude Int16 cm Altitude barométrica em centímetros acima de 1000m abaixo
de zero.
windSouth int16 m/s Valor do vento vindo do Sul.
windWest int16 m/s Valor do vento vindo do Oeste.
leftRPM uint16 RPM RPM do motor esquerdo.
rightRPM uint16 RPM RPM do motor direito.
staticPressure uint16 Pa Pressão estática em unidades de 2 Pascal.
accelX int16 0.005 m/s2 Aceleração no eixo dos XX em unidades de 0.005 m/s2.
accelY int16 0.005 m/s2 Aceleração no eixo dos YY em unidades de 0.005 m/s2.
accelZ int16 0.005 m/s2 Aceleração no eixo dos ZZ em unidades de 0.005 m/s2.
compass uint16 1/10000 rad True heading indicado pelo magnetómetro em unidades de
1/10000 de radiano, de 0 a 2PI.
agl uint16 m Altura acima do solo.
timestamp Uint64 ms Timestamp de envio da mensagem
194
Mensagem SeagullPayload
Tabela 66: Mensagem SeagullPayload
Campo Definição
Nome do tipo de mensagem SeagullPayload
Descrição Mensagens que contêm os dados destinados ao ou provenientes do VANT (isto é,
enviados do VANT para a ETP ou vice-versa). O componente Comms Relay será
sempre a origem ou destinatário de mensagens deste tipo.
Origem/Origens ETP (Comms Relay), ETP (ETP ROS Interface)
Destino(s) ETP (ETP ROS Interface), ETP (Comms Relay)
Tópico(s) ROS to_comms_relay (sentido ETP – VANT)
from_comms_relay (sentido VANT – ETP)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
requiresAck bool N/A Indicação se a receção da mensagem a enviar terá de ser do tipo
confirmada (i.e., com garantia de entrega). Esta indicação
apenas é relevante para o pedido de envio de mensagens para
o VANT, não para a receção de mensagens do VANT.
length uint32 Nº de bytes Tamanho dos dados da mensagem a enviar.
Data uint8[] N/A Dados da mensagem a enviar/recebidos pelo Comms Relay
através do PAYLOAD_STREAM do Piccolo (envio esse feito de
forma indireta, o envio / receção direto é feito pelo Autopilot
Driver).
Mensagem AutopilotPayload Tabela 67: Mensagem AutopilotPayload
Campo Definição
Nome do tipo de mensagem AutopilotPayload
Descrição Mensagens que contêm os dados destinados ao ou provenientes do VANT (isto é,
enviados do VANT para a ETP ou vice-versa). O componente Autopilot Driver será
sempre a origem ou destinatário de mensagens deste tipo. Os dados contidos nesta
mensagem são os dados recebidos (ou a enviar) diretamente no PAYLOAD_STREAM
do Piccolo.
Origem/Origens ETP (Comms Relay), ETP (Autopilot Driver)
195
Destino(s) ETP (Autopilot Driver), ETP (Comms Relay)
Tópico(s) ROS to_autopilot (sentido ETP – VANT)
from_autopilot (sentido VANT – ETP)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
length uint32 Nº de bytes Tamanho dos dados da mensagem a enviar.
Data uint8[] N/A Dados da mensagem a enviar/recebidos pelo Autopilot Driver
através do PAYLOAD_STREAM do Piccolo.
Mensagem AutopilotWaypoint Tabela 68: Mensagem AutopilotWaypoint
Campo Definição
Nome do tipo de mensagem AutopilotWaypoint
Descrição Definição de um waypoint, quer seja um waypoint já existente no plano da Piccolo
Ground Station ou o pedido para a sua criação.
Origem/Origens ETP (Autopilot Driver), ETP (ETP ROS Interface)
Destino(s) ETP (ETP ROS Interface), ETP (Autopilot Driver)
Tópico(s) ROS autopilot_waypoint_from_ap (listagem de waypoints existentes)
autopilot_waypoint_to_ap (criação de waypoints por parte da ETP)
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
Latitude float32 graus Posição do waypoint.
Longitude float32 graus Posição do waypoint.
deployParachute bool N/A Indicação se o 195lip-quedas será ativado quando o waypoint
for atingido.
196
Nome Tipo Unidades Descrição
deployDrop bool N/A Indicação se o deploy drop deverá ser efetuado quando o
waypoint for atingido.
orbitDirection bool N/A Indicação da direção orbital, 0 indica viragem à esquerda, 1
viragem à direita.
cameraTarget bool N/A Indicação se o waypoint deverá ser utilizado como alvo de
câmara.
landingPoint bool N/A Indicação que o waypoint é um ponto de aterragem. De notar
que um plano de aterragem apenas pode conter um waypoint
com este bit ativo.
slopeControl bool N/A Indicação se o slope control se encontra ativo. Caso esteja, o
VANT irá voar não irá atingir imediatamente a altitude alvo
quando se encontrar entre waypoints.
lightsOn bool N/A Indicação se as luzes do VANT deverão estar ligadas enquanto
o mesmo estiver a dirigir-se ao waypoint.
preTurn bool N/A Indicação se o pre-turn se encontra ativo.
orbitRadius uint8 10s ou 50s de
metro
Raio de órbita, em unidades de 10s ou 50s de metro, consoante
o valor da flag orbitMultiplier50.
altitude float32 m Altitude em metros acima da 196lipsoide WGS-84.
windFind uint8 Centenas de m Windfinding por intervalo de manobra em centenas de metros.
Quando 0, funcionalidade encontra-se desativada.
orbitTime uint8 Dezenas de m (0 a
253)
Tempo de órbita. Se 0, a aeronave irá orbitar indefinidamente.
Index uint8 N/A Índice deste waypoint.
Next uint8 N/A Índice do waypoint seguinte.
User uint8 N/A Byte de informação configurável pelo utilizador, guardado pela
Piccolo Ground Station.
orbitAbove bool N/A Indicação que o avião deverá orbitar quando acima da altitude
alvo. orbitRadius terá de ser superior a 0.
orbitBelow bool N/A Indicação que o avião deverá orbitar quando abaixo da altitude
alvo. orbitRadius terá de ser superior a 0.
hoverPoint bool N/A Indicação que o ponto é do tipo hover (apenas aplicável a
helicópteros).
altitudeToGround bool N/A Indicação que a altitude se refere à ground altitude.
orbitMultiplier50 bool N/A Indicação do multiplicador do valor do tempo de órbita (50 ou
10).
altLSB uint8 0.125 m Estes bits são utilizados para melhorar a resolução da altitude.
A altitude final do waypoint é calculada da seguinte forma:
altitude + altLSB/8.
197
Mensagem AutopilotRequestWaypoints Tabela 69: Mensagem AutopilotRequestWaypoints
Campo Definição
Nome do tipo de mensagem AutopilotRequestWaypoints
Descrição Define um pedido de uma lista de waypoints feito pela ETP à Piccolo Ground Station.
Origem/Origens ETP (ETP ROS Interface)
Destino(s) ETP (Autopilot Driver)
Tópico(s) ROS autopilot_request_waypoints
Necessita de resposta Sim, uma mensagem do tipo AutopilotWPList seguida de mensagens do tipo
AutopilotWaypoint (uma mensagem para cada waypoint existente).
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
Mensagem AutopilotWPList Tabela 70: Mensagem AutopilotWPList
Campo Definição
Nome do tipo de mensagem AutopilotWPList
Descrição Define a lista de waypoints existentes na Piccolo Ground Station. Esta mensagem é
enviada após um pedido explícito para esse efeito (através de uma mensagem
AutopilotRequestWaypoints).
Origem/Origens ETP (Autopilot Driver), ETP (ETP ROS Interface)
Destino(s) ETP (ETP ROS Interface), ETP (Autopilot Driver)
Tópico(s) ROS autopilot_wp_list_from_ap
autopilot_wp_list_to _ap
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
198
Nome Tipo Unidades Descrição
list uint8[] N/A Lista dos indicies de todos os waypoints existentes.
type uint8 N/A Indica o tipo de WPList:
0 – Resposta do Autopilot a um request;
1 – Delete Waypoints
2 – Não Utilizado
3 – Insert Waypoints (iniciar a transferência de um
bloco)
Mensagem AutopilotStatus Tabela 71: Mensagem AutopilotStatus
Campo Definição
Nome do tipo de mensagem AutopilotStatus
Descrição Status posicional de navegação do VANT disponibilizada pelo Autopilot (Piccolo).
Utilizada essencialmente para identificação de rota para waypoint específico
(restantes parâmetros disponibilizados pelo AP não são utilizados)
Origem/Origens ETP (Autopilot Driver)
Destino(s) ETP (ETP ROS Interface)
Tópico(s) ROS autopilot_status
Necessita de resposta Não.
Frequência da mensagem Mensagem é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
wpFrom uint8 N/A Índice do waypoint anterior
wpTo uint8 N/A Índice do waypoint seguinte.
Mensagem AutopilotTrack Tabela 72: Mensagem AutopilotTrack
Campo Definição
Nome do tipo de mensagem AutopilotTrack
Descrição Define um pedido de mudança de plano de voo waypoints feito pela ETP à Piccolo
Ground Station, indicando um waypoint (do plano novo) para o qual se pretende que
o VANT altere a sua rota.
199
Origem/Origens ETP (ETP ROS Interface)
Destino(s) ETP (Autopilot Driver)
Tópico(s) ROS autopilot_track
Necessita de resposta Não.
Frequência da mensagem Mensagem não é cíclica.
Necessita de garantia de entrega Não aplicável.
Campos da mensagem
Nome Tipo Unidades Descrição
header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do Seagull.
to int8 N/A O nº do waypoint para o qual o autopilot deverá seguir.
go_to int8 N/A Se for 0, utiliza o waypoint a seguir ao do campo “to” como
ínicio de rota. Caso contrario usa a posição atual.
200
201
Anexo D – Casos de Teste e Matriz de
Rastreabilidade
Testes de Integração
Esta secção é referente aos testes de integração do software (especificação e relatórios).
Casos de Teste
Esta secção apresenta a especificação de casos de teste (Test Case Specification - TCS).
TCS-SW-IT-0010 – Arquitetura de software do SEC2
Tabela 73: TCS-SW-IT-0010
Identificador: TCS-SW-IT-0010
Propósito: Arquitetura de software do SEC2
Rastreabilidade: REQ-SW-0010; REQ-SW-0020;
Especificação de
Entrada:
1. Validar que o sistema do SEC2 corre sobre middleware ROS, instalado sobre o sistema operativo
Linux;
2. Validar que o sistema do SEP é composto por nós ROS distintos, que são compilados em
executáveis individuais (e inicializados de forma independente), para os seguintes módulos:
Control Supervisor;
Comms Relay;
Sense&Avoid;
Transponder Driver;
Target Tracker;
Autopilot Driver;
Autopilot Comms;
Especificação de
Saída:
1. Validação visual;
2. Validação visual;
Notas Adicionais: N/A.
TCS-SW-IT-0020 – Arquitetura de software do SEP
Tabela 74: TCS-SW-IT-0020
Identificador: TCS-SW-IT-0020
Propósito: Arquitetura de software do SEP
Rastreabilidade: REQ-SW-1000; REQ-SW-1010;
202
Identificador: TCS-SW-IT-0020
Especificação de
Entrada:
1. Validar que o sistema do SEP corre sobre middleware ROS, instalado sobre o sistema operativo
Linux;
2. Validar que o sistema do SEP é composto por nós ROS distintos, que são compilados em
executáveis individuais (e inicializados de forma independente), para os seguintes módulos:
Seagull Manager;
Frame Grabber;
Detection Module;
Especificação de
Saída:
1. Validação visual;
2. Validação visual;
Notas Adicionais: N/A.
TCS-SW-IT-0030 – Comunicação Base Terra-Ar
Tabela 75: TCS-SW-IT-0030
Identificador: TCS-SW-IT-0030
Propósito: Este teste pretende testar a comunicação base entre os módulos em terra e os que estão no ar.
Rastreabilidade: REQ-SW-0030; REQ-SW-1020; REQ-SW-1070; REQ-SW-1080; REQ-SW-2000; REQ-SW-2050;
REQ-SW-2150;
Especificação de
Entrada:
1. Comunicação ETP-> SEP com envio de pedidos “MissionDefinition”, “FollowTarget”;
2. Comunicação ETP->ETC2 via Autopilot Driver com pedido de waypoints “Request Waypoints”;
3. Envio de telemetria de payload SEP->ETP (Payload Telemetry);
4. Envio de telemetria de payload SEC2->ETC2->ETP (AP Telemetry);
5. Envio de imagens de SEP para ETP via comms relay;
Especificação de
Saída:
1. O Seagull Manager recebe os pedidos, e atualiza a telemetria de payload de forma adequada (Atualiza
nome da missão em execução, bem como o status do S2SN);
2. O AP envia de volta para a ETP vários waypoints, seguidos da lista, informação que será apresentada
na ETP GUI;
3. A ETP apresenta a telemetria de Payload atualizada na GUI da aplicação (inclui timestamp);
4. A ETP apresenta a telemetria de AP atualizada na GUI da aplicação (inclui timestamp);
5. Os dados da imagem são visíveis no tópico respetivo (from_comms_relay), e a ETP indica que recebeu
uma imagem nova;
Notas Adicionais: Para efeitos de testes de comunicação, o fulcral no âmbito deste teste é validar as comunicações. Assim
sendo, não é obrigatório validar na GUI da ETP, podendo utilizar-se escuta sobre os tópicos ROS e
mensagens LOG dos módulos para confirmar os fluxos das comunicações.
TCS-SW-IT-0040 – Comunicação Avançada Terra-Ar
203
Tabela 76: TCS-SW-IT-0040
Identificador: TCS-SW-IT-0040
Propósito: Este teste pretende testar as funcionalidades avançadas dos vários módulos do sistema e validar o seu
funcionamento através da comunicação entre os módulos em terra e os que estão no ar.
Rastreabilidade: REQ-SW-0030; REQ-SW-0040; REQ-SW-0050; REQ-SW-0060; REQ-SW-1020; REQ-SW-1070;
REQ-SW-1080; REQ-SW-1100; REQ-SW-2000; REQ-SW-2050; REQ-SW-2150;
Especificação de
Entrada:
1. Envio de telemetria payload;
1.1. A cada 10 segundos o módulo Seagull Manager envia uma mensagem mavlink PayloadTelemetry;
2. Envio de Missão:
2.1. Envio de configuração de missão por parte da ETP especificando o tipo de missão;
3. Obtenção de imagem:
3.1. Execução dos nós de cada câmara (TASE, Gobi, JAI_EO, JAI_NIR);
4. Requerimento de imagem;
4.1. Detection Module terá de enviar uma lista de objetos visíveis;
4.2. Utilizar o botão presente na ETP para requisitar imagem de um objeto que conste ou já tenha
constado da lista de objetos visíveis;
4.3. Utilizar o botão presente na ETP para requisitar uma imagem de um dos sensores ativos;
5. Ordem de seguimento de alvo;
5.1. Detection Module terá de enviar uma lista de objetos visíveis;
5.2. Utilizar o botão presente na ETP para requisitar o seguimento de um objeto atualmente na lista
de objetos visíveis;
6. Envio de telemetria do autopilot;
6.1. Telemetria proveniente do autopilot;
7. Deteção de objeto novo;
7.1. Detection Module envia uma lista de objetos que contém pelo menos um objeto novo, identificado
pelos algoritmos de deteção executando sobre as imagens dos detetores atualmente ativos;
8. Publicação no tópico “adsb_output” uma mensagem ADSBOutput com os parâmetros de localização
de forma a simular um VANT na zona de ação do sistema de Sense and Avoid;
Especificação de
Saída:
1. Receção em terra da telemetria de payload;
1.1. Apresentação da telemetria na GUI da ETP;
1.2. Seagull Manager apresentará a mensagem “Publishing Payload Telemetry”;
2. Definição de missão;
2.1. O Seagull Manager apresentará a mensagem “Mission Type: xpto”, sendo que xpto corresponde
à missão enviada pela ETP;
2.2. A Telemetria de Payload que chega à ETP apresenta o ID do tipo de missão atualizado com o que
foi enviado;
2.3. Detection Module receberá, do Seagull Manager o tipo de missão a executar, de forma a poder
arrancar o algoritmo adequado;
3. Obtenção de imagem:
204
Identificador: TCS-SW-IT-0040
3.1. Verificar a circulação de mensagens nos tópicos respetivos às câmaras (TASE, Gobi, JAI_EO,
JAI_NIR);
4. Imagem requerida;
4.1. O Seagull Manager apresentará as seguintes mensagens e publicará a imagem destinada a terra:
“Received a request to get image from object 1”;
“Requested image received”;
“Published object: 1 with X rows and Y columns”;
"Published Image with X rows and Y columns"
4.2. O Detection Module enviará a imagem requerida para o Seagull Manager;
4.3. A imagem chegará à ETP que apresentará a sinalização de imagem recebida;
4.4. Repetir os passos 4.1 a 4.3 mas com informação de sensor em vez de objeto;
5. Seguir o alvo
5.1. Seagull Manager apresentará as seguintes mensagens e ativará o serviço do Control Supervisor:
“Requested to start following object 1”;
“Sending follow order for object 1”;
“ACTION: 1”; “ACTIVATE: 1”;
“Target Tracking activated”;
5.2. O Control Supervisor apresentará as seguintes mensagens:
“<ControlSupervisor> - Active action: deactivation done!”;
“<ControlSupervisor> - Controller deactivated: true”;
“<ControlSupervisor> - Requested action 1: activation done!”;
5.3. O Target Tracker apresentará as seguintes mensagens:
“<TargetTrackerController> - activateHandler::Received an activation”;
6. Telemetria do autopilot;
6.1. Seagull Manager apresentará a mensagem “Telemetry”, seguida dos campos da telemetria,
seguidos pela mensagem “End of Telemetry”;
6.2. A ETP apresentará a telemetria de AP atualizada na GUI da aplicação (inclui timestamp);
7. Objeto novo detectado;
7.1. O Seagull Manager apresentará as seguintes mensagens:
“New object reported with the ID: X”, onde X é o ID do novo objeto;
“Received a request to get image from object X”;
“Publishing Payload Event”;
“Requested image received”;
“Published object: X with Y rows and Z columns”;
"Published Image with Y rows and Z columns";
7.2. Detection Module deverá enviar a imagem requerida;
7.3. ETP deverá apresentar o evento recebido e a indicação de nova imagem, permitindo abrir a
mesma na aplicação GUI.
8. VANT detetado no campo de ação do sistema de Sense and Avoid:
8.1. O módulo Sense and Avoid apresentará a seguinte mensagem:
“Sense and Avoid activated”;
8.2. O módulo Sense and Avoid publicará no tópico “to_ap_command” uma mensagem do tipo
FilteredAutopilotCommand que conterá o valor de “bank” para que o VANT se desvie.
205
Identificador: TCS-SW-IT-0040
Notas Adicionais: Para efeitos de testes de comunicação, o fulcral no âmbito deste teste é validar as comunicações. Assim
sendo, não é obrigatório validar na GUI da ETP, podendo utilizar-se escuta sobre os tópicos ROS e LOG
messages dos módulos para confirmar os fluxos das comunicações.
TCS-SW-IT-0050 – Receção no SEC2 de dados de telemetria do AP
Tabela 77: TCS-SW-IT-0050
Identificador: TCS-SW-IT-0050
Propósito: Validação da comunicação entre SEC2 e AP
Rastreabilidade: REQ-SW-0030; REQ-SW-0090;
Especificação de
Entrada:
1. Configurar o ambiente referido em 5.3.1:
1.1. Ajustar parâmetros do ficheiro de lançamento onboard.launch, referentes a device name e
baudrate da porta série de ligação ao AP;
1.2. Estabelecer as ligações entre os diversos componentes apresentados na secção 5.3.1;
1.3. Iniciar o simulador do modelo dinâmico da aeronave;
1.4. Definir um plano de voo;
2. Configurar o SEC2 com o ambiente de ROS:
2.1. Executar comando de ‘source’ ao setup.bash do workspace de execução;
2.2. Executar comando: roslaunch seagull_autopilot onboard.launch, para lançamento dos nós
de ROS relacionados com o package seagull_autopilot
3. Validar recolha de dados de telemetria
3.1. Executar o comando: rostopic echo /autopilot_telemetry
Especificação de
Saída:
1. Confirmação dos dados de telemetria.
Deverão ser recebidos na consola os dados referentes à telemetria atual do UAV que deve ser
comparada com a apresentada no simulador
Notas Adicionais: Assume-se que a execução dos comandos é feita através de uma consola ligada ao sistema
computacional respetivo quer seja virtualizado ou físico.
TCS-SW-IT-0060 – Envio de comandos do SEC2 para o AP
Tabela 78: TCS-SW-IT-0060
Identificador: TCS-SW-IT-0060
Propósito: Validar o envio de comandos do SEC2 para o AP
Rastreabilidade: REQ-SW-2030; REQ-SW-2090:
Especificação de
Entrada:
1. Configurar o ambiente referido em 5.3.1.1.
206
Identificador: TCS-SW-IT-0060
1.1. Ajustar parâmetros do ficheiro de lançamento onboard.launch, referentes a device name e
baudrate da porta série de ligação ao AP;
1.2. Estabelecer as ligações entre os diversos componentes apresentados na secção 5.3.1.1;
1.3. Iniciar o simulador do modelo dinâmico da aeronave;
1.4. Definir um plano de voo;
2. Configurar o SEC2 com o ambiente de ROS:
2.1. Executar comando de ‘source’ ao setup.bash do workspace de execução;
2.2. Executar comando: roslaunch seagull_autopilot onboard.launch, para lançamento dos nós
de ROS relacionados com o package seagull_autopilot
3. Execução de comando
3.1. Executar o commando:
rostopic pub /autopilot_command seagull_autopilot_msgs/AutopilotCommand "header:
header:
seq: 0
stamp:
secs: 0
nsecs: 0
frame_id: ''
vehicleId: 1
command_code: 2
value: 10.0"
Especificação de
Saída:
1. Confirmação do comportamento de resposta ao comando.
Por observação da atitude do VANT simulador deverá verificar-se uma inclinação de 10 graus;
Deverá aparecer uma mensagem de aviso na ETC2 devido a se tratar de um comando de baixo
nível que desliga o sistema de track de um waypoint do AP;
Notas Adicionais: Assume-se que a execução dos comandos é feita através de uma consola ligada ao sistema
computacional respetivo quer seja virtualizado ou físico.
TCS-SW-IT-0070 – Target Tracking
Tabela 79: TCS-SW-IT-0070
Identificador: TCS-SW-IT-0070
Propósito: Este teste pretende testar a capacidade de o Control Supervisor fornecer ao Seagull Manager o serviço para
ativação do Target Tracking e que após um pedido de ativação se verifique o seguimento e o fornecimento
de posição do alvo por parte so Seagull Manager.
Rastreabilidade: REQ-SW-0070; REQ-SW-0080; REQ-SW-1110; REQ-SW-2140;
Especificação de
Entrada:
1. Execução do comando:
- rosservice list;
2. Pedido de seguimento de alvo na ETP;
3. Execução do comando rostopic echo “/target_location”;
Especificação de
Saída:
1. O output deverá conter o serviço “/cs_request_action”;
2. O sistema terá o seguinte output:
“Requested to start following object x” (sendo “x” um objectId presente na lista fornecida pelo
módulo de deteção.);
“Sending follow order for object x”;
“<TargetTrackerController> - activateHandler::Received an activation”;
“<ControlSupervisor> - S2SN Controller activated”;
207
Identificador: TCS-SW-IT-0070
“<SeagullManager> - Target Tracking activated”;
3. O sistema terá o seguinte output (valores ilustrativos):
“header:
seq: 1
stamp:
secs: 0
nsecs: 0
frame_id: ‘ ‘
objectId: 0
objectLatitude: 2.0
objectLongitude: 1.0
objectVx: 0
objectVy: 0”
Notas Adicionais: É assumido que todos os sistemas estão a funcionar e que o módulo de deteção está a fornecer uma lista
de objetos visíveis.
TCS-SW-IT-0080 – Detection Module
Tabela 80: TCS-SW-IT-0080
Identificador: TCS-SW-IT-0080
Propósito: Este teste pretende testar a capacidade do Detection Module de detetar objetos nas imagens fornecidas
conforme o tipo de missão a executar.
Rastreabilidade: REQ-SW-1030; REQ-SW-1040; REQ-SW-1050; REQ-SW-1060; REQ-SW-1090;
Especificação de
Entrada:
1. Execução do sistema;
1.1. Envio de missão do tipo “Fiscalização marítima”;
1.2. Execução do comando “rostopic echo /detection_image_to_sep”;
Especificação de
Saída:
1. O tópico “detection_list_to_sep” deverá conter mensagens DetectionList com objetos detetados que
sejam barcos de pesca (cíclico);
1.1. Todos os objetos contêm a sua localização e identificação são guardados na pasta definida para
o efeito;
1.2. Recepção de mensagens DetectionImage aquando da deteção de novos barcos;
Notas Adicionais: O Requisito REQ-SW-1040 especifica mais casos mas será apenas a repetição deste teste para os vários
casos.
TCS-SW-IT-0090 – Execução de Missão
Tabela 81: TCS-SW-IT-0090
Identificador: TCS-SW-IT-0090
Propósito: Este teste pretende testar as capacidades de envio de uma missão definida na ETP para execução no VANT.
Rastreabilidade: REQ-SW-1120;
Especificação de
Entrada:
1. Selecionar uma missão definida da lista da treeview da ETP, e experimentar fazer “Execute mission”
das seguintes formas:
1.1. Duplo clique;
208
Identificador: TCS-SW-IT-0090
1.2. Botão direito e “Execute Mission”;
1.3. Botão na toolbar da vista “Execute Mission”;
Especificação de
Saída:
1. Validar que aparece um diálogo de confirmação em qualquer uma das 3 opções e que após carregar
“Ok”, a missão é enviada para execução – a telemetria de payload deverá ser recebida com o nome
da nova missão;
Notas Adicionais: -
TCS-SW-IT-0100 – Monitorização de Missão
Tabela 82: TCS-SW-IT-0100
Identificador: TCS-SW-IT-0100
Propósito: Este teste pretende testar a capacidade de receção de erros, telemetria e panorama marítimo.
Rastreabilidade: REQ-SW-1130; REQ-SW-1140; REQ-SW-1150;
Especificação de
Entrada:
1. Envio para a ETP de toda a telemetria de navegação e payload e de waypoints;
2. Envio de telemetria de payload para a ETP;
3. Envio de lista de objetos visíveis para a ETP;
4. Desligar módulo detection module;
Especificação de
Saída:
1. Receção na ETP de toda a telemetria de navegação e payload e de waypoints e representação no
mapa da posição do VANT, dos erros e eventos da missão catual. A posição do VANT será atualizada
ciclicamente (receção de telemetria do AP) e de cada vez que um novo evento ou erro seja recebido
deverá também surgir uma janela pop-up com a informação associada ao mesmo;
2. O Seagull Manager publica ciclicamente a mensagem “Publishing Payload Telemetry”;
2.1. A telemetria de payload é atualizada ciclicamente na ETP;
3. O Seagull Manager publica ciclicamente a mensagem “Publishing updated list with the objects:” e a
lista dos objetos;
3.1. Ciclicamente a lista de objetos (panorama marítimo) é apresentada graficamente no mapa.
4. O Seagull Manager mostra a mensagem “Publishing Error” e envia a mensagem para a ETP;
4.1. A ETP mostra a mensagem de erro e a informação relativa à mesma durante alguns segundos
numa janela pop-up e coloca também o timestamp, e o tipo de erro na vista de payload.
Notas Adicionais: N/A
TCS-SW-IT-0110 – Logging e modo de Debug
Tabela 83: TCS-SW-IT-0110
Identificador: TCS-SW-IT-0110
Propósito: Este teste pretende garantir que os componentes principais do sistema têm um modo de Debug que
realiza logging de execução e reporting de erros.
Rastreabilidade: REQ-SW-1160;
209
Identificador: TCS-SW-IT-0110
Especificação de
Entrada:
1. Ligar os sistemas onboard, deixar executar durante algum tempo e validar que todos os módulos do SEP
escrevem num ficheiro específico o log de execução e o report de erros;
Especificação de
Saída:
1. Validar a existência de logs de execução e report de erros em ficheiros específicos no filesystem do
sistema onboard para cada módulo do SEP;
Notas Adicionais: N/A.
TCS-SW-IT-0120 – Frame Grabbers
Tabela 84: TCS-SW-IT-0120
Identificador: TCS-SW-IT-0120
Propósito: Este teste pretende testar a capacidade do sistema de capturar imagens e fornecê-las ao módulo de
deteção ciclicamente.
Rastreabilidade: REQ-SW-1170
Especificação de
Entrada:
1. Correr o nó “jai_fg” com a câmara JAI configurada para o espetro visível;
1.1. Correr o nó de testes “test_cameras”;
2. Correr o nó “jai_fg” com a câmara JAI configurada para o espetro “near infrared;
2.1. Correr o nó de testes “test_cameras”;
3. Correr o nó “gobi_fg”;
3.1. Correr o nó de testes “test_cameras”;
4. Correr o nó “tase_fg”;
4.1. Correr o nó de testes “test_cameras”;
Especificação de
Saída:
1. Deverá ser possível verificar a existência de dados no tópico “jai_eo_frame_grabber”;
1.1. Será possível a visualização da imagem;
2. Deverá ser possível verificar a existência de dados no tópico “jai_nir_frame_grabber”;
2.1. Será possível a visualização da imagem;
3. Deverá ser possível verificar a existência de dados no tópico “gobi_frame_grabber”;
3.1. Será possível a visualização da imagem;
4. Deverá ser possível verificar a existência de dados no tópico “tase_frame_grabber”;
4.1. Será possível a visualização da imagem;
Notas Adicionais: -
TCS-SW-IT-0130 – Geração e Envio de Situational Reports para o SISOM
Tabela 85: TCS-SW-IT-0130
Identificador: TCS-SW-IT-0130
Propósito: Este teste pretende testar a geração e envio cíclico de Situational Reports para o SISOM
Rastreabilidade: REQ-SW-2010; REQ-SW-2030; REQ-SW-2040;
210
Identificador: TCS-SW-IT-0130
Especificação de
Entrada:
1. A ETP gera, cíclica e automaticamente Situational Reports guardados em ficheiros xml locais;
2. A ETP envia, também cíclica e automaticamente, os SitReps mais recentes gerados (envio contínuo
imediatamente após a geração do SitRep) para o SISOM;
Especificação de
Saída:
1. Verificar no filesystem na pasta “sitreps”, que é gerado e atualizado ciclicamente o ficheiro
latest_SitRep.xml, contendo informação de missão, eventos, telemetria e outra informação de suporte;
2. Verificar num webserver externo, que os SitReps da ETP são recebidos ciclicamente e os dados
atualizados de acordo, permitindo subscrição do interface de comunicação com o SISOM e
consequentemente monitorização contínua.
Notas Adicionais: -
TCS-SW-IT-0140 – Comandos do SISOM para a ETP
Tabela 86: TCS-SW-IT-0140
Identificador: TCS-SW-IT-0140
Propósito: Este teste pretende testar o envio de comandos do SISOM para a ETP
Rastreabilidade: REQ-SW-2020;
Especificação de
Entrada:
1. Definir uma missão no servidor web do SISOM;
2. Enviar a missão para a ETP através da GUI do servidor do SISOM;
3. Após identificar na ETP a existência de uma missão do SISOM para importar, carregar em “Import
Mission from SISOM”;
Especificação de
Saída:
1. Verificar que após o envio do SISOM, aparece na ETP “New Mission sent from SISOM to be imported”;
2. Após carregar para importar a missão do SISOM, esta deverá passar a aparecer na lista de missões
disponíveis na ETP (na treeview da GUI);
Notas Adicionais: -
TCS-SW-IT-0150 – Comunicação específica ETP-VANT
Tabela 87: TCS-SW-IT-0150
Identificador: TCS-SW-IT-0150
Propósito: Este teste pretende testar a comunicação específica entre o SEC2 e o SEP.
Rastreabilidade: REQ-SW-2060; REQ-SW-2080; REQ-SW-2090; REQ-SW-2100; REQ-SW-2110; REQ-SW-2120;
Especificação de
Entrada:
1. Envio de mensagem SeagullPayload (ETP->VANT);
2. Envio de mensagem SeagullPayload (VANT->ETP);
3. Envio de dados SEP->ETP;
3.1. Envio de evento;
3.2. Envio de erro;
3.3. Envio de Telemetria de payload;
211
Identificador: TCS-SW-IT-0150
3.4. Envio de imagem;
4. Envio de dados ETP->VANT;
4.1. Envio de configuração de missão;
4.2. Envio de ordem de seguimento;
4.3. Pedido de imagem de objeto ou sensor;
Especificação de
Saída:
1. Mensagem SeagullPayload recebida no VANT;
2. Atualização da telemetria de payload e do respetivo timestamp a cada ciclo, visível na GUI da ETP;
3. Receção de dados provenientes do SEP na ETP;
3.1. A ETP recebe o evento e faz display do mesmo na PayloadView, mostrando, durante alguns
segundos os detalhes do evento numa janela pop-up.
3.2. A ETP recebe o erro e faz display do mesmo na PayloadView, mostrando, durante alguns
segundos os detalhes do evento numa janela pop-up.
3.3. A ETP recebe a telemetria e faz o display da mesma na PayloadTelemetryView;
3.4. A ETP recebe a imagem e faz o display da mesma numa janela pop-up durante alguns segundos.
A imagem passa a aparecer também na treeview da MissionView sob a missão que se encontra
a ser executada atualmente;
4. Receção de dados provenientes da ETP no VANT;
4.1. O Seagull Manager apresentará a mensagem “Mission Type: xpto”, sendo que xpto corresponde
à missão enviada pela ETP;
4.1.1. A Telemetria de Payload que chega à ETP apresenta o ID do tipo de missão atualizado
com o que foi enviado;
4.1.2. Detection Module receberá, do Seagull Manager, a definição de missão e efetuará as
configurações apropriadas ao tipo da mesma;
4.2. Seagull Manager apresentará a seguinte mensagem: “Requested to start following object X”, em
que X é o número do objeto;
4.3. O Seagull Manager apresentará a seguinte mensagem: “Received a request to get image from
object X”, em que X é o número do objeto ou “Received a request to get image from sensor X”,
em que X é o número do sensor;
Notas Adicionais: N/A.
TCS-SW-IT-0160 – Comunicação específica ETC2
Tabela 88: TCS-SW-IT-0160
Identificador: TCS-SW-IT-0160
Propósito: Este teste pretende testar a capacidade da ETC2 de providenciar capacidade de comunicação entre a ETP
e o VANT.
Rastreabilidade: REQ-SW-2070;
Especificação de
Entrada:
1. Estabelecer a ligação entre a ETP -> ETC2 -> VANT;
2. Envio de uma definição de missão.
3. Escutar os tópicos “/from_autopilot” e “/to_autopilot”;
Especificação de
Saída:
1. Após a ligação ser estabelecida a telemetria deverá ser apresentada na GUI da ETP;
2. O VANT deverá receber a missão, enviando para baixo na telemetria de payload a indicação de
alteração para nova missão, visível na ETP após a receção da mensagem;
212
Identificador: TCS-SW-IT-0160
3. As mensagens trocadas entre a ETP/ETC2 e o VANT devem ser visíveis no ecrã;
Notas Adicionais: -
TCS-SW-IT-0170 – Comunicação de telemetria de AP do SEC2 para o
SEP
Tabela 89: TCS-SW-IT-0170
Identificador: TCS-SW-IT-0170
Propósito: Este teste pretende testar a comunicação específica entre o SEC2 e o SEP, em particular o envio de
telemetria de Autopilot.
Rastreabilidade: REQ-SW-2130;
Especificação de
Entrada:
1. Chegada de telemetria proveniente do Autopilot (Piccolo);
Especificação de
Saída:
1. O Autopilot Driver (SEC2) publicará a telemetria no tópico “/autopilot_telemetry” e esta será subscrita
pelo Seagull Manager (SEP). O Seagull Manager mostrará uma mensagem a informar a receção da
telemetria;
Notas Adicionais: N/A.
TCS-SW-IT-0180 – Health Monitoring
Tabela 90: TCS-SW-IT-0180
Identificador: TCS-SW-IT-0180
Propósito: Este teste pretende testar o funcionamento do sistema de monitorização por Heartbeat e validar que todos
os módulos enviam corretamente o sinal de Heartbeat e os módulos monitorizadores recebem estes sinais
ou sinalizam a não receção dos mesmos.
Rastreabilidade: REQ-SW-1150; REQ-SW-3000; REQ-SW-3010; REQ-SW-3020; REQ-SW-3030; REQ-SW-3040;
REQ-SW-3050; REQ-SW-3060; REQ-SW-3070;
Especificação de
Entrada:
1. Monitorização do sinal de Heartbeat no SEP;
1.1. Sinal de Heartbeat do módulo de AIS;
1.1.1. Envio de um sinal de Heartbeat pelo módulo de AIS;
1.1.2. Falha no envio de um sinal de Heartbeat pelo módulo de AIS;
1.2. Sinal de Heartbeat do frame grabber da câmara Gobi;
1.2.1. Envio de um sinal de Heartbeat pelo frame grabber da câmara Gobi;
1.2.2. Falha no envio de um sinal de Heartbeat pelo frame grabber da câmara Gobi;
1.3. Sinal de Heartbeat do frame grabber da câmara JAI;
1.3.1. Envio de um sinal de Heartbeat pelo frame grabber da câmara JAI;
1.3.2. Falha no envio de um sinal de Heartbeat pelo frame grabber da câmara JAI;
1.4. Sinal de Heartbeat do frame grabber da câmara TASE;
1.4.1. Envio de um sinal de Heartbeat pelo frame grabber da câmara TASE;
1.4.2. Falha no envio de um sinal de Heartbeat pelo frame grabber da câmara TASE;
213
Identificador: TCS-SW-IT-0180
1.5. Sinal de Heartbeat do módulo de deteção;
1.5.1. Envio de um sinal de Heartbeat pelo módulo de deteção;
1.5.2. Falha no envio de um sinal de Heartbeat pelo módulo de deteção;
1.6. Sinal de Heartbeat da TASE Comms;
1.6.1. Envio de um sinal de Heartbeat pela TASE Comms;
1.6.2. Falha no envio de Heartbeat pela TASE Comms;
1.7. Sinal de Heartbeat do TASE Driver;
1.7.1. Envio de um sinal de Heartbeat pelo TASE Driver;
1.7.2. Falha no envio de um sinal de Heartbeat pelo TASE Driver;
1.8. Sinal de Heartbeat do control supervisor;
1.8.1. Envio de um sinal de Heartbeat pelo control supervisor;
1.8.2. Falha no envio de um sinal de Heartbeat pelo control supervisor;
2. Monitorização do sinal de Heartbeat no SEC2;
2.1. Sinal de Heartbeat do seagull manager;
2.1.1. Envio de um sinal de Heartbeat pelo seagull manager;
2.1.2. Falha no envio de um sinal de Heartbeat pelo seagull manager;
2.2. Sinal de Heartbeat do comms relay;
2.2.1. Envio de um sinal de Heartbeat pelo comms relay;
2.2.2. Falha no envio de um sinal de Heartbeat pelo comms relay;
2.3. Sinal de Heartbeat do autopilot driver;
2.3.1. Envio de um sinal de Heartbeat pelo autopilot driver;
2.3.2. Falha no envio de um sinal de Heartbeat pelo autopilot driver;
2.4. Sinal de Heartbeat do autopilot comms;
2.4.1. Envio de um sinal de Heartbeat pelo autopilot comms;
2.4.2. Falha no envio de um sinal de Heartbeat pelo autopilot comms;
2.5. Sinal de Heartbeat do target tracking;
2.5.1. Envio de um sinal de Heartbeat pelo target tracking;
2.5.2. Falha no envio de um sinal de Heartbeat pelo target tracking;
2.6. Sinal de Heartbeat do sense and avoid;
2.6.1. Envio de um sinal de Heartbeat pelo sense and avoid;
2.6.2. Falha no envio de um sinal de Heartbeat pelo sense and avoid;
3. Monitorização de Heartbeat SEP-ETP;
3.1. Sinal de Heartbeat do SEP;
3.1.1. Envio de um sinal de Heartbeat pelo SEP;
3.1.2. Falha no envio de um sinal de Heartbeat pelo SEP;
3.2. Sinal de Heartbeat da ETP
3.2.1. Envio de um sinal de Heartbeat pela ETP
3.2.2. Falha no envio de um sinal de Heartbeat pela ETP.
Especificação de
Saída:
1. Criação dos publishers para os tópicos “/to_sec2_heartbeat” e “/seagull_error”. Criação, também, do
subscriber do tópico “/to_sep_heartbeat”;
1.1. Criação, no módulo AIS, do publisher para o tópico “/to_sep_heartbeat”;
O tópico “/to_sep_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 0;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 0 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 0”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
214
Identificador: TCS-SW-IT-0180
1.2. Criação, no frame grabber da câmara Gobi, do publisher para o tópico “/to_sep_heartbeat”;
O tópico “/to_sep_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 1;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 1 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 1”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
1.3. Criação, no frame grabber da câmara JAI, do publisher para o tópico “/to_sep_heartbeat”;
O tópico “/to_sep_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 2;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 2 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 2”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
1.4. Criação, no frame grabber da câmara TASE, do publisher para o tópico “/to_sep_heartbeat”;
O tópico “/to_sep_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 3;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 3 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 3”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
1.5. Criação, no módulo de deteção, do publisher para o tópico “/to_sep_heartbeat”;
O tópico “/to_sep_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 4;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 4 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 4”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
1.6. Criação, na TASE Comms, do publisher para o tópico “/to_sep_heartbeat”;
O tópico “/to_sep_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 6;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 6 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 6”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
1.7. Criação, no TASE Driver, do publisher para o tópico “/to_sep_heartbeat”;
O tópico “/to_sep_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 7;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 7 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 7”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
1.8. Criação, no Control Supervisor, do publisher para o tópico “/to_sep_heartbeat”;
215
Identificador: TCS-SW-IT-0180
O tópico “/to_sep_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 11;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 11 e o campo errorMsg conterá a mensagem “Heartbeat
Failed from Node: 11”, mensagem esta que será apresentada no ficheiro de log. Este erro
será reportado à ETP através de uma mensagem mavlink PayloadError que será
apresentada na GUI como um erro do tipo 10 com os detalhes presentes na mensagem
mavlink;
2. Criação dos publishers para os tópicos “/to_sep_heartbeat” e “/seagull_error”. Criação, também, do
subscriber do tópico “/to_sec2_heartbeat”;
2.1. Criação, no Seagull Manager, do publisher para o tópico “/to_sec2_heartbeat”;
O tópico “/to_sec2_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 5;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 5 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 5”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
2.2. Criação, no Comms Relay, do publisher para o tópico “/to_sec2_heartbeat”;
O tópico “/to_sec2_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 8;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 8 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 8”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
2.3. Criação, no Autopilot Driver, do publisher para o tópico “/to_sec2_heartbeat”;
O tópico “/to_sec2_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 9;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 9 e o campo errorMsg conterá a mensagem “Heartbeat Failed
from Node: 9”, mensagem esta que será apresentada no ficheiro de log. Este erro será
reportado à ETP através de uma mensagem mavlink PayloadError que será apresentada
na GUI como um erro do tipo 10 com os detalhes presentes na mensagem mavlink;
2.4. Criação, no Autopilot Comms, do publisher para o tópico “/to_sec2_heartbeat”;
O tópico “/to_sec2_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 10;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 10 e o campo errorMsg conterá a mensagem “Heartbeat
Failed from Node: 10”, mensagem esta que será apresentada no ficheiro de log. Este erro
será reportado à ETP através de uma mensagem mavlink PayloadError que será
apresentada na GUI como um erro do tipo 10 com os detalhes presentes na mensagem
mavlink;
2.5. Criação, no Target Tracking, do publisher para o tópico “/to_sec2_heartbeat”;
O tópico “/to_sec2_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 12;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 12 e o campo errorMsg conterá a mensagem “Heartbeat
Failed from Node: 12”, mensagem esta que será apresentada no ficheiro de log. Este erro
será reportado à ETP através de uma mensagem mavlink PayloadError que será
216
Identificador: TCS-SW-IT-0180
apresentada na GUI como um erro do tipo 10 com os detalhes presentes na mensagem
mavlink;
2.6. Criação, no Sense and Avoid, do publisher para o tópico “/to_sec2_heartbeat”;
O tópico “/to_sec2_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 13;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 13 e o campo errorMsg conterá a mensagem “Heartbeat
Failed from Node: 13”, mensagem esta que será apresentada no ficheiro de log. Este erro
será reportado à ETP através de uma mensagem mavlink PayloadError que será
apresentada na GUI como um erro do tipo 10 com os detalhes presentes na mensagem
mavlink;
2.7. Criação, no ADSB Driver, do publisher para o tópico “/to_sec2_heartbeat”;
O tópico “/to_sec2_heartbeat” conterá uma mensagem do tipo SeagullHeartbeat em que
o campo “node” terá o valor 14;
O tópico “/seagull_error” conterá a mensagem SeagullError. Esta conterá os campos
errorType=10, errorNode = 14 e o campo errorMsg conterá a mensagem “Heartbeat
Failed from Node: 14”, mensagem esta que será apresentada no ficheiro de log. Este erro
será reportado à ETP através de uma mensagem mavlink PayloadError que será
apresentada na GUI como um erro do tipo 10 com os detalhes presentes na mensagem
mavlink;
3. Criação dos publishers para o tópico “/to_comms_relay” e do subscriber do tópico
“/from_comms_relay” no SEP e ETP;
3.1. Criação, no seagull manager, do publisher para o tópico “/to_comms_relay” e do subscriber do
tópico “from_comms_relay”;
Será publicada nó tópico “/to_comms_relay” uma mensagem SeagullPayload que
encapsula uma mensagem mavlink do tipo HEARTBEAT contendo o sinal de Heartbeat e
um timestamp;
A ETP mostrará na GUI uma mensagem de erro a sinalizar a falha de comunicação entre
o SEP e a ETP;
3.2. Criação, no seagull manager, do publisher para o tópico “/to_comms_relay” e do subscriber do
tópico “from_comms_relay”;
Será publicada nó tópico “/to_comms_relay” uma mensagem SeagullPayload que
encapsula uma mensagem mavlink do tipo HEARTBEAT contendo o sinal de Heartbeat e
um timestamp;
O SEP mostrará uma mensagem de erro a sinalizar a falha de comunicação entre o ETP
e o SEP;
Notas Adicionais: N/A.
TCS-SW-IT-0190 – Recuperação de erros
Tabela 91: TCS-SW-IT-0190
Identificador: TCS-SW-IT-0190
Propósito: Este teste pretende garantir que os vários nós ROS têm controlo do seu ciclo de vida, garantindo que
reiniciam em caso de falha. No caso de falha do ROS Master (ROS Core), pretende testar o mecanismo
de monitorização que força todos os nós a serem desligados e reiniciados pela ordem adequada
(primeiro o Core, e depois todos os outros nós do sistema).
217
Identificador: TCS-SW-IT-0190
Rastreabilidade: REQ-SW-3000; REQ-SW-3080;
Especificação de
Entrada:
1. Desligar um nó do SEP
2. Desligar um nó do SEC2
3. Desligar o ROS MASTER
Especificação de
Saída:
1. O nó desligado deverá reiniciar
2. O nó desligado deverá reiniciar
3. O ROS MASTER deverá reiniciar e todos os outros nós deverão também reiniciar posteriormente ao
ROS MASTER.
Notas Adicionais: N/A.
Resultados
Tabela 92: Relatório de resultados de teste
Relatório de Resultados de Teste
Ambiente de teste
utilizado
Ambiente Software-In-The-Loop:
Simulador Autopilot (Picollo PCC + ETC2) + Laptops (SEP+ETP+SEC2)
Data de Execução 12-01-2015
ID de Teste Resultado Observações
TCS-SW-IT-0010 OK 1. OK;
2. OK;
TCS-SW-IT-0020 OK 1. OK;
2. OK;
TCS-SW-IT-0030 OK
1. OK;
2. OK;
3. OK;
4. OK;
5. OK;
TCS-SW-IT-0040 OK
1. OK;
1.1. OK;
1.2. OK;
2. OK;
2.1. OK;
2.2. OK;
2.3. OK;
3. OK;
3.1. OK;
4. OK;
4.1. OK;
4.2. OK;
4.3. OK;
4.4. OK;
5. OK;
218
Relatório de Resultados de Teste
5.1. OK;
5.2. OK;
5.3. OK;
6. OK;
6.1. OK;
6.2. OK;
7. OK;
7.1. OK;
7.2. OK;
7.3. OK;
8. OK;
8.1. OK;
8.2. OK;
TCS-SW-IT-0050 OK 1. OK;
TCS-SW-IT-0060 OK 1. OK;
TCS-SW-IT-0070 OK
1. OK;
2. OK;
3. OK;
TCS-SW-IT-0080 OK
1. OK;
1.1. OK;
1.2. OK;
TCS-SW-IT-0090 OK 1. OK;
TCS-SW-IT-0100 OK
1. OK;
2. OK;
3. OK;
4. OK;
TCS-SW-IT-0110 OK 1. OK;
TCS-SW-IT-0120 OK
1. OK;
1.1. OK;
2. OK;
2.1. OK;
3. OK;
3.1. OK;
4. OK;
4.1. OK;
TCS-SW-IT-0130 OK 1. OK;
2. OK;
TCS-SW-IT-0140 NOK 1. NOK; Não implementado
2. NOK; Não implementado
TCS-SW-IT-0150 OK
1. OK;
2. OK;
3. OK;
3.1. OK;
3.2. OK;
3.3. OK;
219
Relatório de Resultados de Teste
3.4. OK;
4. OK;
4.1. OK;
4.1.1. OK;
4.1.2. OK;
4.2. OK;
4.3. OK;
TCS-SW-IT-0160 OK 1. OK;
2. OK;
TCS-SW-IT-0170 OK 1. OK;
TCS-SW-IT-0180 OK
1. OK;
1.1. OK;
1.2. OK;
1.3. OK;
1.4. OK;
1.5. OK;
1.6. OK;
1.7. OK;
1.8. OK;
2. OK;
2.1. OK;
2.2. OK;
2.3. OK;
2.4. OK;
2.5. OK;
2.6. OK;
2.7. OK;
3. OK;
3.1. OK;
3.2. OK;
TCS-SW-IT-0190 OK
1. OK;
2. OK;
3. OK;
Matriz de Rastreabilidade
Tabela 93: Matriz de rastreabilidade
Requisito de Software Caso(s) de Teste Resultado da implementação do requisito no projeto
REQ-SW-0010 TCS-SW-IT-0010 OK
OK Implementado, testado e validado com sucesso.
REQ-SW-0020 TCS-SW-IT-0010 OK Implementado, testado e validado com sucesso.
REQ-SW-0030 TCS-SW-IT-0030
TCS-SW-IT-0040
TCS-SW-IT-0050
OK
OK
OK
Implementado, testado e validado com sucesso.
220
Requisito de Software Caso(s) de Teste Resultado da implementação do requisito no projeto
REQ-SW-0040 TCS-SW-IT-0040 OK Implementado, testado e validado com sucesso.
REQ-SW-0050 TCS-SW-IT-0040 OK Implementado, testado e validado com sucesso.
REQ-SW-0060 TCS-SW-IT-0040 OK Implementado, testado e validado com sucesso.
REQ-SW-0070 TCS-SW-IT-0070 OK Implementado, testado e validado com sucesso.
REQ-SW-0080 TCS-SW-IT-0070 OK Implementado, testado e validado com sucesso.
REQ-SW-0090 TCS-SW-IT-0050 OK Implementado, testado e validado com sucesso.
REQ-SW-1000 TCS-SW-IT-0020 OK Implementado, testado e validado com sucesso.
REQ-SW-1010 TCS-SW-IT-0020 OK Implementado, testado e validado com sucesso.
REQ-SW-1020 TCS-SW-IT-0030
TCS-SW-IT-0040
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-1030 TCS-SW-IT-0080 OK Implementado, testado e validado com sucesso.
REQ-SW-1040 TCS-SW-IT-0080 OK Implementado, testado e validado com sucesso.
REQ-SW-1050 TCS-SW-IT-0080 OK Implementado, testado e validado com sucesso.
REQ-SW-1060 TCS-SW-IT-0080 OK Implementado, testado e validado com sucesso.
REQ-SW-1070 TCS-SW-IT-0030
TCS-SW-IT-0040
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-1080 TCS-SW-IT-0030
TCS-SW-IT-0040
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-1090 TCS-SW-IT-0080 OK Implementado, testado e validado com sucesso.
REQ-SW-1100 TCS-SW-IT-0040 OK Implementado, testado e validado com sucesso.
REQ-SW-1110 TCS-SW-IT-0070 OK Implementado, testado e validado com sucesso.
REQ-SW-1120 TCS-SW-IT-0090 OK Implementado, testado e validado com sucesso.
REQ-SW-1130 TCS-SW-IT-0100 OK Implementado, testado e validado com sucesso.
REQ-SW-1140 TCS-SW-IT-0100 OK Implementado, testado e validado com sucesso.
REQ-SW-1150 TCS-SW-IT-0100
TCS-SW-IT-0180
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-1160 TCS-SW-IT-0110 OK Implementado, testado e validado com sucesso.
REQ-SW-1170 TCS-SW-IT-0120 OK Implementado, testado e validado com sucesso.
REQ-SW-2000 TCS-SW-IT-0030
TCS-SW-IT-0040
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-2010 TCS-SW-IT-0130 NOK Não implementado
REQ-SW-2020 TCS-SW-IT-0140 NOK Não implementado
REQ-SW-2030 TCS-SW-IT-0060
TCS-SW-IT-0130
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-2040 TCS-SW-IT-0040
TCS-SW-IT-0130
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-2050 TCS-SW-IT-0030 OK Implementado, testado e validado com sucesso.
221
Requisito de Software Caso(s) de Teste Resultado da implementação do requisito no projeto
TCS-SW-IT-0040 OK
REQ-SW-2060 TCS-SW-IT-0150 OK Implementado, testado e validado com sucesso.
REQ-SW-2070 TCS-SW-IT-0160 OK Implementado, testado e validado com sucesso.
REQ-SW-2080 TCS-SW-IT-0150 OK Implementado, testado e validado com sucesso.
REQ-SW-2090 TCS-SW-IT-0060
TCS-SW-IT-0150
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-2100 TCS-SW-IT-0150 OK Implementado, testado e validado com sucesso.
REQ-SW-2110 TCS-SW-IT-0150 OK Implementado, testado e validado com sucesso.
REQ-SW-2120 TCS-SW-IT-0150 OK Implementado, testado e validado com sucesso.
REQ-SW-2130 TCS-SW-IT-0170 OK Implementado, testado e validado com sucesso.
REQ-SW-2140 TCS-SW-IT-0070 OK Implementado, testado e validado com sucesso.
REQ-SW-2150 TCS-SW-IT-0030
TCS-SW-IT-0040
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-3000 TCS-SW-IT-0180
TCS-SW-IT-0190
OK
OK Implementado, testado e validado com sucesso.
REQ-SW-3010 TCS-SW-IT-0180 OK Implementado, testado e validado com sucesso.
REQ-SW-3020 TCS-SW-IT-0180 OK Implementado, testado e validado com sucesso.
REQ-SW-3030 TCS-SW-IT-0180 OK Implementado, testado e validado com sucesso.
REQ-SW-3040 TCS-SW-IT-0180 OK Implementado, testado e validado com sucesso.
REQ-SW-3050 TCS-SW-IT-0180 OK Implementado, testado e validado com sucesso.
REQ-SW-3060 TCS-SW-IT-0180 OK Implementado, testado e validado com sucesso.
REQ-SW-3070 TCS-SW-IT-0180 OK Implementado, testado e validado com sucesso.
REQ-SW-3080 TCS-SW-IT-0190 OK Implementado, testado e validado com sucesso.