Diogo André Dias Salgueirorepositorium.sdum.uminho.pt/bitstream/1822/46721/1/Tese... · 2017-10-19 · Diogo André Dias Salgueiro Sistema de monitorização para veículos aéreos

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


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


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 83: TCS-SW-IT-0110 ............................................................................................... 208


Tabela 87: TCS-SW-IT-0150 ............................................................................................... 210 Tabela 88: TCS-SW-IT-0160 ............................................................................................... 211


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)


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


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


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


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


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


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


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


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


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


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


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


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


(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



jai_fg 2 jai_eo_frame_grabber P Image

jai_nir_frame_grabber P Image



tase_fg 3 tase_frame_grabber P Image



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




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


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


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


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


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)


Tópico(s) ROS ais_static_voyage




Campos da mensagem



objectId uint8 N/A Código identificativo do objeto.

type uint8 N/A Tipo de mensagem

151


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


Frequência da mensagem Mensagem é cíclica.


Campos da mensagem


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


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)


Tópico(s) ROS detection_list_to_sep




Campos da mensagem



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.



Tópico(s) ROS detection_image_to_sep




Campos da mensagem



imagem Image N/A Mensagem do tipo Image para transmissão de imagem.

154


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.


global.


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)


Tópico(s) ROS request_image




Campos da mensagem



requestedId Uint16 N/A Identificador único do sensor/objeto do qual se pretende a

fotografia.

155


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.



Tópico(s) ROS detection_module_config




Campos da mensagem



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.


Destino(s) SEC2 (Control Supervisor)

Tópico(s) ROS target_location


Frequência da mensagem Mensagem é cíclica (apenas quando é necessário seguir um objeto).


156

Campo Definição

Campos da mensagem



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.


global


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




Campos da mensagem



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)


Tópico(s) ROS seagull_error




Campos da mensagem



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)



158

Campo Definição


Campos da mensagem



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.



fVal1 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)


Tópico(s) ROS tase_angle_out




Campos da mensagem



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.


Destino(s) SEP (Tase Driver)

Tópico(s) ROS tase_camera_command_in




Campos da mensagem



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.



Tópico(s) ROS tase_camera_zoom_in




Campos da mensagem




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.



Tópico(s) ROS tase_command_in



161

Campo Definição


Campos da mensagem


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.



Tópico(s) ROS tase_rate_out




162

Campo Definição

Campos da mensagem



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)




Campos da mensagem



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.



Tópico(s) ROS tase_zero_in




Campos da mensagem



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.



Tópico(s) ROS tase_telemetry




164

Campo Definição

Campos da mensagem



etc…)

flags uint16 N/A Flags indicadoras de dados no pacote.

mode uint8 N/A Modo operacional 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)


SEC2 seagull_comms comms_relay 8 from_comms_relay P SeagullPayload

165


to_comms_relay S SeagullPayload

comms_parameters S CommsParameters



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


autopilot_zero_

length

S AutopilotZeroLength



autopilot_comms

10 from_autopilot P AutopilotPayload



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


seagul_error P SeagullError

target_tracker_control

12 to_ap_command P FilteredAutopilotCommand


target_location S TargetLocation



sense_and_avoid 13 to_ap_command P FilteredAutopilotCommand




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)




Campos da mensagem


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.


Destino(s) SEC2 (Comms Relay)

Tópico(s) ROS comms_parameters (sentido ETP – VANT)




Campos da mensagem



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


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




Campos da mensagem


header SeagullHeader N/A Cabeçalho comum a todas as mensagens ROS do

Seagull.


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)


SEP (Detection Module)

SEC2 (Target Tracker)

SEC2 (Sense and Avoid)

Tópico(s) ROS autopilot_telemetry




Campos da mensagem



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


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




Campos da mensagem


header SeagullHeader N/A Cabeçalho comum às mensagens ROS do Seagull

171


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.



Tópico(s) ROS autopilot_user_action




Campos da mensagem



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


172

Campo Definição


Tópico(s) ROS autopilot_mission_limits




Campos da mensagem



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)


Tópico(s) ROS cs_status




Campos da mensagem



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



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



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




Campos da mensagem



id uint32 N/A Identificador único do VANT detetado.

latitude float32 graus Latitude do VANT detetado.

longitude float32 graus Longitude do VANT detetado.

175


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


Destino(s) SEC2 (Autopilot Driver)

Tópico(s) ROS autopilot_command


Frequência da mensagem Mensagem é cíclica no caso de S&A ou TT estarem activos.


Campos da mensagem



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


176

Campo Definição

Frequência da mensagem Mensagem é cíclica no caso de S&A ou TT estarem activos.


Campos da mensagem


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)




Campos da mensagem



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


Destino(s) N/A (Mensagem definida para possível debug)

Tópico(s) ROS autopilot_ads_samples




Campos da mensagem



analog1 int32 N/A Amostras da linha analógica 1.




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).


Destino(s) SEC2(Control Supervisor)

Tópico(s) ROS autopilot_status




Campos da mensagem


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


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.








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).








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.


Destino(s) SEC2 (Autopilot Driver)

Tópico(s) ROS autopilot_zero_length




Campos da mensagem



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 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.



182

Campo Definição

Necessita de resposta Sim, uma mensagem do tipo ImageData.



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>


<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.






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>


<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 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>


<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=”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)




184

Campo Definição

Definição MavLink <message id=”200” name=”PAYLOADTELEMETRY”>

<description> Telemetria cíclica do Sistema de Payload.</description>


<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).






185

Campo Definição

Definição MavLink <message id=”201” name=”PAYLOADEVENT”>

<description>Envia um evento de payload para terra.</description>


<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).





186

Campo Definição


Definição MavLink <message id=”202” name=”IMAGEDATA”>

<description>Mensagem que contém uma imagem enviada pelo VANT

</description>


<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


<field type=”float” name=”object_long”> A longitude do objeto na imagem, se


<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


um erro (e.g., parâmetros de missão enviados inválidos).






Definição MavLink <message id=”203” name=”PAYLOADERROR”>

<description>Mensagem que contém erros ocorridos, e que devem ser enviados

para terra. </description>


<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


um erro (e.g., parâmetros de missão enviados inválidos).




Frequência da mensagem Mensagem cíclica.


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>


<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.




Frequência da mensagem Mensagem cíclica.


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.




Frequência da mensagem Mensagem é cíclica (apenas quando o VANT está a seguir um objeto).


Definição MavLink <message id=”206” name=”TARGETOBJECT”>

<description>Mensagem que contém informação sobre o objeto a ser

seguido.</description>


<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)




Definição MavLink <message id=”207” name=”HEARTBEAT”>

<description>Mensagem que contém sinal de Heartbeat.</description>


</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


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


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


Frequência da mensagem Mensagem é cíclica. Frequência definida pelas configurações do AP (tipicamente

1hz).


Campos da mensagem

193



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


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)




Campos da mensagem



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.


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


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)




Campos da mensagem




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)




Campos da mensagem



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


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).



Campos da mensagem



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




Campos da mensagem



198


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




Campos da mensagem



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




Campos da mensagem



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;


Notas Adicionais: N/A.

TCS-SW-IT-0020 – Arquitetura de software do SEP



Propósito: Arquitetura de software do SEP


202


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:




TCS-SW-IT-0030 – Comunicação Base Terra-Ar



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



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.


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


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


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



Propósito: Validação da comunicação entre SEC2 e AP


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



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


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



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


“<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



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



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


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



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



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.


209


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;


TCS-SW-IT-0120 – Frame Grabbers



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;


3. Correr o nó “gobi_fg”;


4. Correr o nó “tase_fg”;


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”;


3. Deverá ser possível verificar a existência de dados no tópico “gobi_frame_grabber”;


4. Deverá ser possível verificar a existência de dados no tópico “tase_frame_grabber”;


Notas Adicionais: -

TCS-SW-IT-0130 – Geração e Envio de Situational Reports para o SISOM



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


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



Propósito: Este teste pretende testar o envio de comandos do SISOM para a ETP


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



Propósito: Este teste pretende testar a comunicação específica entre o SEC2 e o SEP.


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


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;


TCS-SW-IT-0160 – Comunicação específica ETC2



Propósito: Este teste pretende testar a capacidade da ETC2 de providenciar capacidade de comunicação entre a ETP

e o VANT.


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


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



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.


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;


TCS-SW-IT-0180 – Health Monitoring



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.


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


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


1.2. Criação, no frame grabber da câmara Gobi, do publisher para o tópico “/to_sep_heartbeat”;








1.3. Criação, no frame grabber da câmara JAI, do publisher para o tópico “/to_sep_heartbeat”;








1.4. Criação, no frame grabber da câmara TASE, do publisher para o tópico “/to_sep_heartbeat”;








1.5. Criação, no módulo de deteção, do publisher para o tópico “/to_sep_heartbeat”;








1.6. Criação, na TASE Comms, do publisher para o tópico “/to_sep_heartbeat”;








1.7. Criação, no TASE Driver, do publisher para o tópico “/to_sep_heartbeat”;








1.8. Criação, no Control Supervisor, do publisher para o tópico “/to_sep_heartbeat”;

215





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







2.2. Criação, no Comms Relay, do publisher para o tópico “/to_sec2_heartbeat”;








2.3. Criação, no Autopilot Driver, do publisher para o tópico “/to_sec2_heartbeat”;








2.4. Criação, no Autopilot Comms, do publisher para o tópico “/to_sec2_heartbeat”;








mavlink;

2.5. Criação, no Target Tracking, do publisher para o tópico “/to_sec2_heartbeat”;







216



mavlink;

2.6. Criação, no Sense and Avoid, do publisher para o tópico “/to_sec2_heartbeat”;








mavlink;

2.7. Criação, no ADSB Driver, do publisher para o tópico “/to_sec2_heartbeat”;








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;


TCS-SW-IT-0190 – Recuperação de erros



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



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.


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;


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


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-0070 OK

1. OK;

2. OK;

3. OK;

TCS-SW-IT-0080 OK

1. OK;

1.1. OK;

1.2. OK;


TCS-SW-IT-0100 OK

1. OK;

2. OK;

3. OK;

4. 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;


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


3.4. OK;

4. OK;

4.1. OK;

4.1.1. OK;

4.1.2. OK;

4.2. OK;

4.3. OK;


2. 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











TCS-SW-IT-0040

OK







TCS-SW-IT-0040

OK



TCS-SW-IT-0040

OK









TCS-SW-IT-0180

OK





TCS-SW-IT-0040

OK


REQ-SW-2010 TCS-SW-IT-0130 NOK Não implementado

REQ-SW-2020 TCS-SW-IT-0140 NOK Não implementado


TCS-SW-IT-0130

OK



TCS-SW-IT-0130

OK



221


TCS-SW-IT-0040 OK





TCS-SW-IT-0150

OK








TCS-SW-IT-0040

OK



TCS-SW-IT-0190

OK










Documents

Diogo André Dias Salgueirorepositorium.sdum.uminho.pt/bitstream/1822/46721/1/Tese... · 2017-10-19 · Diogo André Dias Salgueiro Sistema de monitorização para veículos aéreos