rovim - robô de vigilância de instalações militares ... · na fase nal do projeto são...

ROVIM - Robô de Vigilância de Instalações Militares - Comunicações e

Posto de Controlo

Tiago Argentino Matos Santos

Dissertação para obtenção do Grau de Mestre em

Engenharia Eletrotécnica e de Computadores

Júri

Presidente: Professor Doutor Marcelino Bicho dos Santos

Orientador: Professor Doutor Moisés Simões Piedade

Acompanhante: Professor Doutor António Joaquim dos Santos Romão Serralheiro

Vogal: Professor Doutor Pedro Filipe Zeferino Tomás

Especialista: Tenente-Coronel João Pedro Bastos Rocha

Outubro de 2011

Agradecimentos

Deixo uma palavra de agradecimento ao: Professor Doutor António Joaquim dos Santos Romão

Serralheiro pelo feedback disponibilizado relativo à escrita da dissertação; Professor Doutor

Moisés Simões Piedade por ter aceite a tarefa de orientação desta dissertação; Diretor de

Curso, Tenente-Coronel de Transmissões Engenheiro João Pedro Pereira Bastos Rocha pela

preocupação e auxilio prestado em fornecer contactos importantes para o desenvolvimento

desta dissertação; Capitão de Transmissões Engenheiro Nuno Casteleiro Góis também pe-

los contactos fornecidos; Tenente-Coronel de Infantaria José Carlos Dias Rouco pelo parecer

militar em relação à aplicação desenvolvida e aos aspetos da de�nição do problema e levan-

tamento de requisitos; Tenente-Coronel José António Travanca Lopes e ao IGeoE - Instituto

Geográ�co do Exército - a disponibilização dos shape�les representativos das Áreas onde foram

desenvolvidas ações de teste da aplicação.

Agradecimento especial aos pilotos de teste da aplicação: Alferes de farmácia Paula Lopes,

Alferes de GNR Engenharia Jorge Costa, Alferes de Engenharia Ricardo Figueiredo, Alferes

de Transmissões Humberto Costa, Alferes de Engenharia Bruno Correia, Aspirante de Serviço

de Material João Santo e Aspirante de Serviço de Material João Calado.

Um grande Obrigado a todos aqueles que contribuíram para a minha chegada a esta fase.

Em Particular ao Alferes de Transmissões Luís Regada, Alferes de Transmissões Jorge Roças,

Alferes de Engenharia Valter Henriques e José Rafael. A todo o curso de Engenheiros �nalistas

2010/2011 da Academia Militar.

Como os últimos acabam sempre por ser os primeiros, OBRIGADO aos meus pais: Au-

gusto Nelson, Laurinda Susana; e aos irmãos: Fernando Manuel, Filipe Alexandre, Cláudia

Isabel; que independentemente dos momentos vividos sempre me apoiaram. Aos amigos: Cata-

rina, Rui, André, Cláudia, Bruno. Distantes mas sempre presentes. A estes sim, OBRIGADO.

Agradeço a todos aqueles que sem �carem esquecidos não estão aqui presentes.

iii

Resumo

Esta dissertação reporta o desenvolvimento de uma aplicação de controlo de um robô de

vigilância terrestre que se pretende que venha a ser não tripulado. À aplicação é atribuído o

nome de RovimViewer. Para o seu desenvolvimento é feito um estudo sobre as necessidades de

informação das forças terrestres, assim como, sobre as características físicas e de segurança que

têm que estar presentes neste tipo de sistemas. Existe também a preocupação em desenvolver

um sistema de baixo custo, recorre-se, para esse �m, ao uso de open-source. É então usada

a linguagem python e o ambiente de desenvolvimento grá�co QTdesigner, tudo desenvolvido

em ambiente Debian - Linux. A aplicação constitui-se por cinco módulos: Observação e

monitorização; Con�guração e controlo; Sistema de informação geográ�ca; Diário de bordo e

apresentação de mensagens assíncronas; Servidor de Protocolo e cálculo; Modelo de previsão.

É apresentado o desenvolvimento de um servidor com capacidade de tradução de protocolo

de comandos, permitindo assim controlar um ou mais novos robôs na mesma rede. É incitada

uma abstração do dispositivo face à aplicação, tornando-a independente do dispositivo robótico

usado. É incluído no sistema um modelo de previsão de rota proveniente da codi�cação linear

LPC. Na fase �nal do projeto são apresentadas as limitações da aplicação, bem como, uma

avaliação e teste aos propósitos inicialmente impostos. Esta situação re�etiu uma limitação

que suscitou a questão da qualidade de imagem versus ritmo de transferência. A nível de

conclusões é possível con�rmar a capacidade de desenvolver uma aplicação de baixo custo e

su�cientemente robusta e passível de ser usada em cenários militares.

Palavras chave: Aplicação de Controlo, Veículos não tripulados, Open Source, Codi�-

cação LPC.

v

Abstract

This paper presents an application to control unmanned ground surveillance robots, named

"RovimViewer". We have undertaken a study concerning both physical and security charac-

teristics, as well as the information required by ground forces. The application is composed of

�ve modules: observation and monitoring, con�guration and control; Geographic Information

System; Log and display of asynchronous messages; Server Protocol and calculation; Early

prediction model. We describe a server for translating of protocol commands, which allows

robots in the network to be controlled. An abstraction layer is also implemented, making the

application independent from the robotic device. Route prediction was achieved through a

Linear Prediction Coding (LPC) algorithm. Application limitations, as well as system testing

and performance evaluation are also addressed. We show that it is possible to develop an

application based on open-source software, that is both low-cost and robust.

Keywords: Unmanned vehicles, Unmanned vehicles application control, Open Source,

LPC Coding

vii

Índice

Resumo v

Abstract vii

Lista de Figuras xi

Lista de Tabelas xiii

Lista de Acrónimos xv

1 Introdução 1

1.1 De�nição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Proposta do Sistema Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Contribuições Originais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Estado da Arte 13

2.1 Redes de Comunicações em Teatro de Operações . . . . . . . . . . . . . . . . . 13

2.2 Sistemas de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Veículos não Tripulados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

ix

Conteúdo

3 Implementação do Projeto 27

3.1 Levantamento de Requisitos do Sistema . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Desenvolvimento da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.1 Desenvolvimento da arquitetura de baixo nível da Aplicação Ideal . . . . 34

3.2.2 Desenvolvimento e Explicação dos módulos do RovimViewer e a sua

funcionalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3 Protocolos, capacidade do ROVIM em uso e adaptação a um novo Protocolo . 44

3.4 Limitações do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.5 Estimador de Movimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Resultados Experimentais e Validação 55

4.1 De�nição do Objeto de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.2 Método de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 Exemplo de escrita dos relatórios RelIm e TUTELA . . . . . . . . . . . . . . . 57

4.4 Aferição de Tempos de Adaptação . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.5 Qualidade de Imagem e Ritmo de Transferência . . . . . . . . . . . . . . . . . . 63

4.6 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 Perspetivas de Trabalho Futuro e Conclusão 67

5.1 Perspetivas de Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Bibliogra�a 69

Anexos 71

A De�nição de Segurança 71

B Orgânica Militar 73

x

Lista de Figuras

1.1 Sistema Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Fluxo de dados entre as diferentes camadas da hierarquia militar . . . . . . . . 3

1.3 �Planagem� dos níveis hierárquicos de uma organização [11] . . . . . . . . . . . 4

1.4 Estrutura da moto-4 para o ROVIM . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5 Rede militar DARPA - Defense Advanced Research Projects Agency [17] . . . . . 8

1.6 Aplicação RovimViewer com o Surveyor SRV-1 . . . . . . . . . . . . . . . . . . 8

1.7 Demonstração de força do sistema Talon dos EUA[6] . . . . . . . . . . . . . . . 11

2.1 Arquitetura funcional do SIC - T . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 UGV ao serviço dos Estados Unidos - Talon[7] . . . . . . . . . . . . . . . . . . 23

2.3 UGV ao serviço de Portugal- Raposa[2] . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Robô autónomo alimentado por matéria orgânica[5] . . . . . . . . . . . . . . . . 25

2.5 UGV presente em Marte- Spirit [3] . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Diagrama de estados de uma tarefa . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Processo Iterativo de desenvolvimento da aplicação RovimViewer . . . . . . . . 40

3.3 A�nação do o�set de direção do ROVIM . . . . . . . . . . . . . . . . . . . . . . 41

3.4 Con�guração de teclas para controlo do ROVIM . . . . . . . . . . . . . . . . . 41

3.5 Visualização do meio envolvente ao ROVIM . . . . . . . . . . . . . . . . . . . . 42

3.6 Con�guração da qualidade de imagem presente no RovimViewer . . . . . . . . 42

xi

Lista de Figuras

3.7 Módulo SIG e dinâmico presente no RovimViewer . . . . . . . . . . . . . . . . 43

3.8 Local de introdução e listagem dos endereços de acesso ao ROVIM . . . . . . . 43

3.9 Diário de Bordo da missão do ROVIM . . . . . . . . . . . . . . . . . . . . . . . 44

3.10 Fluxo de dados da aplicação RovimViewer . . . . . . . . . . . . . . . . . . . . . 45

3.11 Parrot AR.Drone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.12 Imagem do Ar.drone segmentada . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.13 Exemplo de Previsão linear LPC . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.1 Esboço de descrição de um objetivo . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2 Imagem Obtida pelo ROVIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3 Ilustração do percurso de teste a novos indivíduos . . . . . . . . . . . . . . . . . 61

B.1 Classe de Praças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

B.2 Classe de Sargentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

B.3 Classe de O�ciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

xii

Lista de Tabelas

2.1 Módulos SIC-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Classi�cação de UGV's pelo peso[10] . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Vantagens e Desvantagens dos Sistemas de Tempo Real . . . . . . . . . . . . . 28

3.2 Vantagens e Desvantagens do Open-Source . . . . . . . . . . . . . . . . . . . . . 29

3.3 Uso de recursos por parte dos módulos do RovimViewer . . . . . . . . . . . . . 36

3.4 Descrição dos módulos existentes no RovimViewer . . . . . . . . . . . . . . . . 38

4.1 Adaptação à aplicação RovimViewer . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2 Ritmo de transferência em Fps consoante a qualidade de imagem . . . . . . . . 64

xiii

Lista de Tabelas

xiv

Lista de Acrónimos

ACK - Acknowledge

AP - Access Point

BE - Bulk Encryption

CAN - Controller Area Network

CCB - Centro de Comunicações do Batalhão

CCC - Módulo de CCom de Companhia

DARPA - Defense Advanced Research Projects Agency

EATR - Energetically Autonomous Tactical Robot

EOD - Explosive Ordnance Disposal

EPI - Escola Prática de Infantaria

FHz - Feixes Hertzianos

Fps - Frames por segundo

GPS - Global Position System

LPC - Linear Predictive Coding

LVD - Low Voltage Detected

LVD - Low Voltage Detected

NA - Nó de Acesso

NT - Nó de Trânsito

OO - Oriented Object

PAR - Ponto de Acesso Rádio

RL - Módulo Rear Link

RT - Real Time

SAE - Subsistema de Área Estendida

SAL - Subsistema de Área Local

xv

Lista Acrónimos

SCGS - Subsistema de Controlo e Gestão do Sistema

SHDSL - Symetric High-Speed Subscriber Line

SIG - Sistema de Informação Geográ�ca

SUM - Subsistema de Utilizador Móvel

UDP - User Datagram Protocol

UGV - Unmanned Ground Vehicle

VTLR - Viatura Tática Ligeira de Rodas

WiFi - Wireless Fidelity

xvi

Capítulo 1

Introdução

Segundo o General chinês Sun Tzu, a informação é vista como algo crucial para conseguir

vantagem sobre uma força opositora em determinada situação estratégica. A importância

de informação é visível no empenhamento de espiões[18]. Com a obtenção de informação

atempada consegue-se observar e analisar os prós e os contras de se executar determinada

ação. Pode-se alcançar, desse modo, o tão desejado efeito surpresa que poderá levar ao sucesso

da missão. Surge então a intenção de obter dados sem envolver unidades militares1 num

con�ito, situação essa, também ela observada nos textos oriundos do mesmo General. De

um modo menos ideal, considera-se crucial a obtenção de dados minimizando as situações de

con�ito direto com o inimigo. Toda essa intenção tem presente o intuito de poupar vidas

humanas e recursos materiais.

Conclui-se assim que é fulcral a obtenção de informações que contribuam para uma tomada

de decisão correta e atempada. Contudo, essas informações devem ser obtidas também numa

situação de baixo risco, sendo pertinente a redução de empenhamento da força. Tendo em

consideração que este conceito, da importância da informação, é atual, surge então a tentativa

de obter uma solução que responda a esse desa�o. Em consequência disso é sugerido o desen-

volvimento de um sistema de vigilância terrestre que permita de forma rápida e segura, obter

dados que possibilitem posteriormente conseguir vantagem em relação à força opositora.

O sistema2 proposto é constituído por um robô denominado ROVIM, que possui um vasto

conjunto de especi�cações e funcionalidades, e de uma consola de monitorização, observação1Para melhor perceção dos termos militares utilizados ao longo da dissertação é disponibilizado o Anexo

B.2Entenda-se sistema como sendo o conjunto global do projeto desenvolvido.

1

De�nição do Problema

e controlo sendo esta denominada por RovimViewer. Pode observar-se na Figura 1.1 uma

ilustração do sistema global em que se podem observar na tela principal da aplicação a/o:

1. imagem da câmara do ROVIM com o Surveyor Srv-1 na imagem;

2. módulo de informação geográ�ca - SIG;

3. lista das layers utilizada;

4. lista de IPs dos ROVIMs para seleção;

5. botões para controlo do ROVIM.

O sistema �nal proposto consiste no módulo da aplicação de interface, denominada por

RovimViewer, no módulo do sistema de navegação e controlo e no módulo de gestão e controlo

dos sub-sistemas de direção, aceleração e travagem do ROVIM. Do ponto de vista do desen-

volvimento do projeto será feita uma descrição do problema, um levantamento de requisitos

para responder ao problema, a implementação de algumas das funcionalidades dos requisitos e

uma avaliação ao sistema para veri�car se o desenvolvimento do projeto se encontra no rumo

pretendido.

Figura 1.1: Sistema Global

2


1.1 De�nição do Problema

O sistema desenvolvido no âmbito da implementação de um robô de vigilância terrestre mi-

litar, denominado ROVIM, tem como objetivo o desenvolvimento de uma ferramenta militar

de aquisição de dados para diversos escalões da hierarquia militar. Se fosse apenas disponibi-

lizada informação para a classe hierárquica de comando surgiriam latências3 desnecessárias e

prejudiciais ao sucesso da missão[11]. Então, facilmente se percebe que a tarefa de informar

os comandantes de pequenas unidades, por exemplo escalão pelotão4, sobre atividade inimiga

na sua área de missão, terá de ser em RT - Real Time. Para esse efeito tem de existir uma

diminuição dos níveis de hierarquia[11], ao nível de disponibilização de dados e informação,

como se exibe na Figura 1.3. Se se observar o Anexo B onde está representada a estrutura

militar e a Figura 1.2, observa-se de facto que os diferentes níveis de distribuição de informação

devem ser suprimidos de acordo com a Figura 1.3.

Figura 1.2: Fluxo de dados entre as diferentes camadas da hierarquia militar

O objetivo de poupar vidas humanas pode ser conseguido com a utilização deste tipo de

tecnologia. Contudo, para se conseguir poupar em termos de recursos, a tecnologia utilizada

tem de ter em conta o baixo custo de produção. Ao se obter um sistema com essa característica

é disponibilizada então de imediato uma boa relação custo/bene�cio caso se perca um ROVIM.

Considerando que uma operação militar se pode desenrolar em qualquer tipo de terreno

ou condição climatérica, o ROVIM deve ter capacidade de acompanhar a força terrestre inde-3Entende-se por latência de um sistema, o tempo de atraso provocado pelos tempos de propagação de sinais

de informação ou por objetos virtuais ou físicos.4Ver Anexo B da Orgânica Militar

3


Figura 1.3: �Planagem� dos níveis hierárquicos de uma organização [11]

pendentemente do meio e do clima. Uma vez que o operador da aplicação RovimViewer pode,

num determinado instante, ser qualquer elemento pertencente a um pelotão5, a aplicação tem

de disponibilizar uma interface intuitiva e de fácil manipulação. Deve ter a capacidade de ser

usada em multi-plataforma de modo a poder ser utilizada numa máquina �xa (mais robusta),

como o posto de comando do Estado Maior, fornecendo dados para a intelligence do comando,

assim como, numa plataforma reduzida o su�ciente para se poder transportar e manipular

por elementos de uma unidade operacional que se encontrar no terreno. Não se pretende por-

tanto, que esta ferramenta surja como um acréscimo de peso e volume signi�cativo. Deve-se

poder recorrer ao uso de um PDA ou equivalente. Outro ponto a ter em consideração é a

5Unidade militar escalão Companhia constituída por cerca de 40 homens, pertencente a um batalhão (ver

Anexo B).

4


disponibilização dos dados de informação enquanto são válidos e oportunos. Deixa de ser útil

obter a informação que o inimigo passou num ponto X ou Y se existirem tempos de atraso

que impossibilitem uma tomada de decisão atempada. Esta situação invalida esta ferramenta

inibindo-a de ser útil do ponto de vista tático-estratégico. Então, a informação �In-Time6� tem

de estar permanentemente disponível para uma decisão correta, de acordo com as variáveis

disponibilizadas pelo conjunto sensorial do sistema. A acrescentar à informação �In-Time�

pode-se pensar também numa forma de antecipar dados, como é o caso da predição linear

LPC, que se encontra explanada em detalhe mais adiante.

Existem ainda algumas tarefas de rotina (como o deslocamento entre dois pontos por ex-

emplo) que o ROVIM deve conseguir executar autonomamente de modo a libertar o operador

do sistema para executar outras tarefas. Contudo, e para evitar situações menos favoráveis,

deve existir então um sistema de envio de mensagens assíncronas7 para comunicação de pro-

blemas e di�culdades do ROVIM. Estas mensagens são provenientes de situações de con�ito ou

de problemas oriundos do equipamento móvel ROVIM. Todas as instruções dadas ao ROVIM

a partir da consola de interface RovimViewer são deste ponto de vista síncronas, por oposição

às assíncronas. Ao enviar determinado comando para o ROVIM, este envia um ACK 8 de con-

�rmação. Contudo, numa determinada situação de problema, o ROVIM envia uma mensagem

assíncrona de warning que irá requerer especial atenção por parte da equipa que o opera.

A segurança do ROVIM e do meio circundante também não deve ser deixada ao acaso.

Reitera-se assim a necessidade de uma produção de baixo custo do sistema, necessário para uma

ótima, ou otimizada, relação custo/bene�cio. Este objetivo deverá ser explorado e melhorado

ao longo do amadurecimento do sistema em desenvolvimento. Para esta garantia de segurança,

deve estar disponível uma autonomia capaz de executar uma missão/tarefa com sucesso. Para

se alcançar sucesso após a missão, o ROVIM deverá possuir uma baixa emissão de radiação

eletromagnética para evitar deteção por parte das forças opositoras presentes no teatro de

operações. Deve possuir também um sistema de armas com capacidade de defesa e ataque

para numa situação de con�ito ou reconhecimento em força, conseguir responder com potencial

de fogo. Por �m, o ROVIM deve ter também disponível uma �caixa negra� semelhante à de

uma aeronave que registe, em situação de acidente, as condições em que esta operava para

6Em tempo útil para executar determinada ação7Mensagens às quais não é dada uma resposta de forma automática e que carecem de uma decisão do

operador.8Mensagem de Acknowledge de receção e execução do comando

5

Proposta do Sistema Global

corrigir de�ciências futuras, assim como detetar, em caso de destruição, a possível localização

de forças inimigas.

Do ponto de vista da aplicação RovimViewer, esta deve ser de fácil manuseamento para

um controlo �uido e suave de diversos ROVIMs ainda que não em simultâneo nesta fase (essa

situação só é adequada por intermédio do uso de ecrãs sensíveis ao toque). Deve possuir

capacidade de atualização, assim como todo o sistema deve possuir uma manutenção de custo

reduzido. Periodicamente deve estar também disponível uma leitura dos sensores de monito-

rização do próprio ROVIM para, de uma forma mais correta, se avaliar se o sistema está em

condições de prosseguir com a missão ou não. Deve também existir uma forma de previsão do

destino de deslocamento para detetar com antecedência possíveis erros de direção tomada por

parte do ROVIM, em modo autónomo, ou do operador em modo de controlo remoto.

1.2 Proposta do Sistema Global

Em resposta ao problema apresentado, será desenvolvido um ROVIM com capacidade de

comunicação através do protocolo TCP/IP, com uma arquitetura que possibilite processamento

de dados a bordo para deslocamento autónomo. Possuirá para esse efeito uma rede sensorial

que permita observar o meio envolvente e detetar possíveis falhas no próprio ROVIM. Esse

ROVIM terá por base a estrutura de uma moto 4 (Figura 1.4) e motores elétricos para

possibilitar o seu deslocamento através do terreno organizada do seguinte modo:

1. Compartimento das Baterias e da Arquitetura Computacional;

2. Sistema de Direção;

3. Sistema de Tração e Travagem.

O ROVIM deverá possuir ainda um equipamento de rede que permita criar uma rede

mesh9entre outros ROVIMs ou equipamentos militares, possibilitando uma topologia de rede

dinâmica e não pré-de�nida. Esta topologia de rede já existe nas forças militares portuguesas

e pode-se nelas integrar, de forma relativamente simples, este sistema em desenvolvimento.

Esta topologia de rede permite uma maior profundidade10 no terreno, assim como, uma maior

robustez face a ataques. Considerando que os alvos prioritários são as redes de comunicações,

9Rede em que cada nó funciona como router10Entenda-se profundidade como a distância da linha da frente da área de ação de uma força até à área de

reconhecimento e vigilância que o ROVIM pode alcançar.

6

Motivação e Objetivos

Figura 1.4: Estrutura da moto-4 para o ROVIM

a única forma de se conseguir manter uma rede funcional, é não ter uma estrutura dependente

de APs - Access Points �xos. Um exemplo ilustrativo pode ser observado na Figura 1.5. Nessa

ilustração percebe-se nitidamente que em caso de um dos nós de rede ser extinto, o �uxo de

dados passa rapidamente a ser conduzido por um outro caminho.

Após ter o hardware11 de�nido, é necessário considerar mais umas características do soft-

ware. Este também terá uma componente de hardware necessária que deverá ter por base um

ecrã, uma máquina que possua comunicação por rede, capacidade de processamento de dados

e imagens em tempo útil12, capacidade de armazenamento para registo de dados relativos a

missões e um controlo do tipo joystick que permita um controlo efetivo do ROVIM. Para

implementação da aplicação RovimViewer foi usado nesta fase, enquanto se aguarda a �na-

lização do protótipo em construção, um robô designado por Surveyor SRV-1. Na Figura 1.6

está presente a aplicação com uma imagem do Surveyor SRV-1, proveniente de um outro robô

igual.

11Entenda-se aqui hardware como o conjunto dos componentes materiais do projeto.12Com resposta �uida a novas frames

7


Figura 1.5: Rede militar DARPA - Defense Advanced Research Projects Agency [17]

Figura 1.6: Aplicação RovimViewer com o Surveyor SRV-1

8


1.3 Motivação e Objetivos

Após a apresentação do problema e dos sistemas globais, vai-se abordar o objetivo a

atingir nesta dissertação mediante o problema especí�co aqui apresentado. É também descrita

a motivação presente na execução das tarefas para atingir esse �m.

Em sentido lato, o objetivo a atingir é a implementação da aplicação RovimViewer, tendo

por base a motivação de conseguir um sistema funcional, ainda que não de�nitivo, que permita

disponibilizar resposta a algumas das questões levantadas na apresentação da problemática do

assunto referido.

Perante essa determinação, convém salientar a existência da intenção de conseguir desen-

volver uma aplicação, sem recurso a software proprietário, que permita obter um custo de

manutenção e operação da aplicação reduzido. Opta-se por esta abordagem uma vez que a

tendência dos modelos de negócio atuais não se situam especi�camente na venda de produtos

de forma direta, mas sim, na prestação e venda de serviço no pós venda. Pode-se observar essa

situação no momento em que se exige, para manutenção da garantia, execução de manutenções

periódicas dispendiosas em termos monetários. Contudo, ao optar por esta abordagem de de-

senvolvimento de produto com ferramentas open-source, existe sempre o risco do produto �nal

não corresponder às expetativas iniciais. De forma a evitar essa situação, são especi�cados

os requisitos do sistema, de forma detalhada e precisa, com vista a diminuição de problemas

futuros decorrentes de uma abordagem ao problema de forma errada.

Do ponto de vista de construção de um sistema, esta missão de levantamento de requisitos

é a operação mais importante de todo o processo de execução de projeto, existindo para tal uma

secção para discussão desse tema. Trata-se então de uma operação do âmbito da consultadoria

de implementação de sistemas, que tem de ser feita e registada de forma a evitar dissabores

futuros. Essa operação de estudo de alternativas, advém do facto de existir a necessidade de

contabilizar os custos de implementação de um sistema de raiz para os poder confrontar com a

aquisição de um sistema já existente no mercado. Parte-se da premissa que após esse estudo se

reúnem as condições necessárias, que possibilitam observar tanto os aspetos negativos, como

positivos das opções a ter em consideração.

Apresentadas estas duas perspetivas, facilmente se veri�ca uma existência con�ituosa de

objetivos (desenvolvimento de raiz do sistema segundo os requisitos versus aquisição de um

sistema existente que possua esses requisitos, mesmo que não na totalidade). Contudo, está

9

Contribuições Originais

implícito também, independentemente do que se pode encontrar no futuro, uma aquisição

de conhecimento, sobre a causa aqui debatida, decorrente do desenvolvimento e participação

neste projeto. Esta situação permitirá olhar para os sistemas autónomos monitorizados de

um modo mais maduro, possibilitando então, em determinada altura optar por decisões mais

acertadas e evitar a tomada de erros decorrentes de inexperiência sobre a causa apresentada.

Em suma, o objetivo desta dissertação passa pela construção de uma aplicação, capaz

de responder a algumas das necessidades de um operador do sistema de informações. Essa

aplicação terá como como objetivo a/o:

• breve levantamento de requisitos,

• monitorização, controlo e observação de diversos ROVIMs,

• obtenção de dados no teatro de operações de forma remota sem deslocamento ao terreno,

• desenvolvido de conhecimento sobre o tema o que possibilita uma visão mais abrangente

e crítica,

• veri�cação da possibilidade de construir uma aplicação que responda a este tema recor-

rendo a open-source,

• introdução do conceito de servidores de protocolos para conexão de diferentes dispositivos

na rede,

• baixo custo de produção.

1.4 Contribuições Originais

Ao desenvolver esta dissertação, observou-se uma existência considerável de produtos e projetos

com relevância sobre o tema. Após uma análise às abordagens propostas veri�caram-se duas

situações predominantes. O uso de software proprietário e a incapacidade de adaptação das

aplicações existentes a um novo protocolo e consequentemente a um novo robô. Acredita-se,

contudo, que essa tendência esteja a mudar face ao incremento da investigação existente por

parte das entidades que conferem segurança e necessitam deste tipo de sistemas.

Considerando o estado atual da solução do problema sobre o tema aqui exposto, é referida

nesta dissertação o desenvolvimento da aplicação recorrendo a open-source. Para além desta

característica vais ser também explorada a possibilidade de criar uma aplicação capaz de se

integrar com qualquer dispositivo autónomo. Este último ponto será implementado através de

um servidor de protocolo que permita à aplicação, aceder à lista de comandos que são aceites

10

Estrutura da Dissertação

por cada ROVIM presente na rede. É também apresentada a ideia e o interesse futuro de

que o sistema, apresentado no âmbito da solução deste problema, seja um sistema distribuído

de forma a evitar falhas indesejáveis. Pois, numa atividade militar qualquer elemento pode

ser um alvo. Se, por infortúnio, o alvo for o operador, é necessário que exista outro terminal

que tenha a capacidade de controlar o dispositivo robótico, e que permita, não só continuar a

missão como ainda resgatar elementos que poderão estar �sicamente condicionados em terreno

hostil. Uma imagem ilustrativa pode ser observada na Figura 1.7.

Figura 1.7: Demonstração de força do sistema Talon dos EUA[6]

Se o sistema não for todo interligado em rede, se o operador for o alvo e/ou se o equipa-

mento onde corre a aplicação falhar, pode acontecer que se perca de�nitivamente o ROVIM

e em consequência mais grave o próprio homem. Deste modo, a proposta aqui apresentada

irá salvaguardar essa situação uma vez que o ROVIM não estará unicamente dependente do

estado de uma só máquina que contém a aplicação a correr.

1.5 Estrutura da Dissertação

Esta dissertação está organizada em cinco capítulos e faz parte de um projeto que tenta

responder ao problema apresentado na secção De�nição do Problema.

O primeiro capítulo corresponde à introdução que se inicia com um preâmbulo de contex-

tualização e possui mais 5 secções. Está presente a de�nição do problema que carece de uma

11

Estrutura da Dissertação

solução para implementação, o sistema proposto que é candidato à resposta para os problemas

apresentados. É descrito o âmbito desta dissertação que consiste, como referido anteriormente,

no desenvolvimento da aplicação de interface RovimViewer.É feita uma breve descrição do que

surgiu de inovação para o tema aqui apresentado. Neste capítulo também está presente uma

descrição da estrutura de toda a dissertação.

No segundo capítulo é exposta a situação atual do tema abordado nesta dissertação. É

feita referência aos sistemas de tempo real, às redes de comunicações e também aos veículos

não tripulados. O terceiro e o quarto capítulos representam o corpo principal da disser-

tação. É onde se desenvolve a implementação da aplicação e se apresentam as suas limitações.

Observam-se também alguns resultados experimentais relativos à qualidade de imagem e ritmo

de transferência, assim como os tempos de adaptação à aplicação. Esses resultados contribuem

para a validação do projeto.

No quinto e último capítulo são apresentadas as conclusões de todo o trabalho efetuado,

assim como propostas de trabalho futuro sobre o tema.

12

Capítulo 2

Estado da Arte

2.1 Redes de Comunicações em Teatro de Operações

Existem muitas con�gurações de redes disponíveis para fornecer um serviço de telecomuni-

cações. É preciso perceber-se que a grande maioria acaba por não servir quando se transita

para o âmbito militar. Isto deve-se à especi�cidade proveniente da sua natureza, assim como, à

necessidade de integração com redes de outras nações ou instituições, como é o caso da NATO

- North Atlantic Treaty Organization.

Vai ser então descrita a situação atual presente nas Forças Terrestres portuguesas. O SIC-

T - Sistema de Comunicações Tático, é um sistema modular que permite integrar diferentes

tipos de dispositivos e redes diferentes e que foi desenvolvido para satisfazer os requisitos

táticos decorrentes duma missão. Entre os quais podem-se observar:

• Flexibilidade e Adaptabilidade - Para assegurar o seu uso em diferentes cenários e em

diferentes situações táticas em que se veri�cam alterações contínuas;

• Gestão da Frequência - Gestão automática da frequência para evitar interferências no,

já extremamente lotado, espectro eletromagnético;

• Multi-diversidade de serviços - Capacidade de transmitir mensagens, vídeo, fax, voz e

dados;

• Interoperabilidade - Interfaces apropriadas para operar em missões combinadas, conjun-

tas ou mesmo com entidades civis;

• Segurança - O SIC-T cumpre todas as normas de segurança impostas pela NATO;

13

Redes de Comunicações em Teatro de Operações

• Sobrevivência - Assegurada através da redundância, capacidade de reorganização/re-

constituição, dispersão e mobilidade.

A arquitetura do SIC-T é baseada no TACOMS POST-200011 e é constituído por quatro

subsistemas.

O SAE - Subsistema de Área Estendida, é o suporte principal da rede que é composto

por um conjunto de NT's - Nós de Trânsito. Esses nós possuem sempre entre si redundância

de ligações, podendo mesmo haver mais de duas ligações entre cada dois nós. Além disso,

caso todas as ligações entre dois nós sejam destruídas, ou se não forem seguras, há sempre

a possibilidade desses dois nós comunicarem através de um terceiro ou quarto nó. Com isto

criam-se assim caminhos alternativos para a informação circular o que faz com que a rede

tenha uma estrutura entrelaçada - rede mesh.

O SAL - Subsistema de Área Local, fornece aos utilizadores os vários serviços que são:

voz, dados, mensagens, fax e vídeo através de um nó de acesso, para um grupo de utilizadores

especí�co, comummente situados no Posto de Comando.

O SUM - Subsistema de Utilizador Móvel, permite estabelecer ligação com a rede tática

dos vários utilizadores móveis. Os serviços existentes para este sub-sistema são os mesmos que

existem no SAL com a única diferença que a largura de banda é mais restrita. Os utilizadores

deste subsistema podem aceder à rede através de 1 de 3 modos:

• Rede Rádio de Combate (homens com rádio),

• Acesso Rádio de Canal Único,

• Rede Rádio Compacto.

Cada utilizador móvel é automaticamente reconhecido e ligado a toda a rede através do PAR

- Ponto de Acesso Rádio responsável por aquela área.

O SCGS - Subsistema de Controlo e Gestão do Sistema, é responsável pela administração

e funções de controlo. Este subsistema é o cérebro de toda a rede, permitindo ao o�cial de

transmissões2 uma supervisão e controlo dos equipamentos da rede que estão em atividade. É

neste subsistema que deverá ser colocada a gestão dos Rovim's disponibilizando um local de

con�guração destes equipamentos.

1TACOMS Post 2000 é uma iniciativa de 13 nações na NATO para de�nir os novos padrões da emergente

rede de telecomunicações táticas.2Entidade responsável pela gestão da rede de comunicações.

14


Os NT's são o principal elemento da rede. O SAE é construído sob estes módulos. As

comunicações feitas com outras redes de comunicações são feitas através dos nós de trânsito,

os quais possuem um rádio digital multi-canal de 4 Megabytes. Em alternativa, ou de forma

redundante, pode estar �bra ótica ou DSL - Digital Subscriber Line3. Como se pode ver

na Figura 2.1, cada NT possui sempre ligação a outros dois nós no mínimo. O NT poderá

Figura 2.1: Arquitetura funcional do SIC - T

estabelecer até 4 links, com base em FHz - Feixes Hertzianos, na banda 4 a 8 Mbps. Este

módulo disponibiliza também outros suportes físicos para o estabelecimento da ligação, como:

• Cabo ótico (distâncias de 300, 1000, 5000 e 10000m)

• Par de cobre WD1TT4 associado à tecnologia Symetric High-Speed Subscriber Line

(SHDSL) até aproximadamente 4000m.

Na Tabela 2.1 são apresentados de forma sintética os módulos apresentados anteriormente. A

segurança nos links de Feixes Hertzianos é garantida recorrendo a um sistema de BE - Bulk

Encryption, onde se realiza a simulação de tráfego no link, com ritmos aleatórios, independen-

temente de haver tráfego no link ou não.

A complexidade subjacente ao NA e a necessidade de dispersão no terreno, como já foi

referido, obrigou à sua conceção em duas shelters5, uma de Transmissão e outra de C26 &

Gestão.

A shelter de transmissão pode estabelecer:

3É uma tecnologia que fornece um meio de transmissão digital de dados, aproveitando a própria rede

telefónica.4Designação do par de cobre usado no Exército.5Shelter - Cabine de comunicações que se encontra afastada do Posto de Comando6Terminologia militar que signi�ca Comando e Controlo.

15


Designação dos módulos Qtd

Módulo de Nó de Acesso (NA) Cmd Controlo & Gestão 1

Transmissão 1

Módulo de CCom de Batalhão (CCB) Cmd Controlo & Gestão 1

Transmissão 1

Módulo de CCom de Companhia (CCC) 1

Módulo de Nó de Trânsito (NT) 1

Módulo Rear Link (RL) 1

Módulo de Ponto de Acesso Rádio (PAR) 1

Tabela 2.1: Módulos SIC-T

• 3 links de FHz a 8 Mbps;

• Satélite INMARSAT em ambiente IP (com Largura de banda limitada) e em terminal

analógico tipo Mini-M;

• 4 acessos HDSL (WD1TT);

• 5 acesso óticos (Expansão, shelter de C2 & Gestão, módulo RED, TINA e reserva).

A shelter de C2 & Gestão disponibiliza as seguintes possibilidades:

• Acesso IP (WIFI) e GSM;

• Multiconferência até 8 utilizadores (voz ou vídeo), capacidade que se pode estender a

toda a rede;

• Central de comutação;

• Comutação em ambiente IP (telefones IP).

O CCB tem uma conceção similar ao Nó de Acesso, daí ser composto pelo mesmo número

de sub-módulos, �Transmissão� e �C2 & Gestão�. É no módulo de Transmissão que existem

as maiores diferenças, pela exigência de ligação ao escalão superior e subordinado, tendo este

grandes necessidades de mobilidade e de comunicações especí�cas características das redes

rádio de combate.

• Integra o rádio de alta capacidade (HCDR);

• Integra a componente de Combat Net Radio (CNR) .

A shelter de transmissão tem as seguintes possibilidades:

• Rádio de banda larga (UHF) para ligação ao escalão superior por Feixes Hertzianos;

16

Sistemas de Tempo Real

• Mini links LOS a 2 Mbps;

• Satélite INMARSAT em ambiente IP (com Largura de banda limitada);

• 4 acessos HDSL (WD1TT);

• Acesso óticos;

• Rádio de Combate (PAR).

A shelter de C2 & Gestão disponibiliza as seguintes possibilidades:

• Acesso IP (WIFI) e GSM;

• Multi-conferência até 8 utilizadores (voz ou vídeo), capacidade que se pode estender a

toda a rede;

• Central de comutação;

• Comutação em ambiente IP (telefones IP).

O CCC tem uma estrutura bastante mais ligeira, compatível com a mobilidade da unidade.

Trata-se de um único shelter a ser instalado numa Viatura Tática Ligeira de Rodas (VTLR),

onde para além dos equipamentos de comunicações, tem ainda integrado uma componente de

energia e antenas. O módulo contempla:

• Uma componente de gestão e controlo;

• 5 Interfaces ótico,

• 4 Interfaces SHDSL;

• Telefones analógicos (suportados por WD1TT);

• Telefones IP;

• Acesso IP (WiFi);

• Rádio de Banda Larga;

• Mini links LOS a 2 Mbps, para ligação ao escalão superior;

• Capacidade de integração rádio de combate em ambiente IP;

• Satélite INMARSAT em ambiente IP.

O RL tem como �nalidade garantir a ligação à retaguarda (tipicamente território nacional)

quando uma Força é projetada.

17

Sistemas de Tempo Real

2.2 Sistemas de Tempo Real

Antes de proceder à explicação da importância deste modelo de sistema, vai ser explicada a

noção de tempo real - Real-Time. Este termo aparece da observação do mundo em que o

tempo corre, continuamente, e que em todo o espaço físico existente conhecido, tem o seu

próprio ritmo. Com a necessidade de controlar autonomamente muitos desses eventos (caso

da indústria fabril), surgem então os sistema computacionais de tempo real.

No âmbito dos sistemas controlados e da robótica os requisitos de real-time têm de ser tidos

em consideração uma vez que se pretende adotar uma ação para um conjunto pré-estabelecido

de entradas no sistema a controlar. Como a não tomada de ação ou mesmo um atraso na

decisão pode provocar danos e custos elevados (caso das aeronaves), aparece a necessidade de

estabelecer nitidamente quais a metas temporais para responder a determinada crise. Para

cada sistema está então atribuída uma restrição temporal, que traduz a necessidade de resposta

às entradas do sistema, consoante o custo que se poderá obter proveniente de uma resposta

tardia do sistema de controlo. Para classi�car o tipo de sistema a implementar existem três

tipos distintos de sistemas de tempo real.

• Suave (Soft Real-Time) � Restrição temporal em que o resultado da resposta do sis-

tema associado mantém alguma utilidade para a aplicação, mesmo depois do limite

pré-estabelecido. Veri�ca-se, após esse limite, uma degradação da qualidade de serviço.

• Firme (Firm Real-Time) � Restrição temporal em que o resultado da resposta do sistema

associado perde qualquer utilidade para a aplicação depois do limite pré-estabelecido.

• Rígida (Hard Real-Time) � Restrição temporal que, quando não cumprida, pode originar

uma falha catastró�ca.

Este tipo de sistemas passa em grande parte pela utilização de sistemas operativos de tempo

real de baixa latência7 e com escalonamento de tarefas que permita saber o pior caso em termos

de tempo de processamento. Para isto acontecer é necessário que não exista possibilidade de

uma tarefa bloquear outra por tempo indeterminado. As tarefas têm de ser executadas dentro

de um tempo pré-determinado sem possuir bloqueios permanentes.

Para perceber um pouco melhor as diferenças entre os sistemas de tempo de real aqui

apresentados vai-se pensar numa máquina que recebe pacotes de dados provenientes de uma

determinada fonte sensorial. Se os tempos de entrega desses pacotes forem tais que possa

7Com tempos de mudança de tarefa e de interrupções reduzidos

18

Veículos não Tripulados

implicar alguma perda de dados8, se estivermos perante uma situação de transmissão de mul-

timédia (no cinema por ex.) esse mau funcionamento resulta numa redução da qualidade de

serviço e em consequência máxima algum desconforto por parte dos espetadores. Essa situação

re�ete um sistema de Soft Real-Time. Por outro lado, se esses dados pertencerem ao conjunto

de pacotes de dados provenientes dos sensores dinâmicos de uma aeronave (altímetro e ve-

locímetro por ex.), a mesma quantidade de pacotes perdidos vão certamente provocar não só

uma redução da qualidade de serviço e desconforto nos utilizadores, como muito possivelmente

um acidente com graves consequências incluindo perdas materiais avultadas e/ou perdas de

vidas. Facilmente se percebe a necessidade de utilização de sistemas de Hard Real-Time. Fica

agora por exempli�car uma situação de Firm Real-Time. Essa situação é fácil de perceber ao

se pensar num sistema de posicionamento global , GPS. No caso de se perderem alguns pacotes

de dados, ainda que se recebam esses mesmos pacotes num tempo posterior ao pretendido,

não vão acrescentar qualquer valor à informação atual uma vez que pode já estar disponível a

nova localização. Imaginemos um percurso de um automóvel antes e depois da entrada de num

túnel subterrâneo. Conseguir-se-á visualizar a viatura a aproximar-se do túnel, contudo, não

se observará, por GPS, o seu deslocamento no interior do mesmo. Imagine-se agora que por

algum motivo na saída do túnel se obtém o conjunto de coordenadas que a viatura percorreu

no percurso interno do túnel. Nesta altura, não existe vantagem nenhuma em mostrar esse

percurso uma vez que a localização da viatura já se encontra no exterior do mesmo. Con-

tudo os dados podem �car disponíveis para mostrar mais tarde todo o percurso efetuado pela

viatura.

Em suma desta explicação, pode-se �car com a ideia que o Firm Real-Time pode estar

presente em qualquer um dos outros dois. Atualmente todos os sistemas fabris, sistemas de

aviação, sistemas presentes nos automóveis, entre outros, são essencialmente sistemas de Hard

Real-Time. Este texto re�ete apenas em termos ideais assim como o conceito do que existe.

Em termos tecnológicos existem as redes CAN - Controller Area Network (muito presentes na

industria automóvel), os sistemas operativos de tempo real como o ECOS ou QNX, ou com a

instalação do Kernel de linux-RT num SO - Sistema Operativo Linux.

8Em sistemas de tempo real, existe sempre um tempo pré-determinado para ignorar dados não enviados,

sendo essa a situação em que ocorre um mau funcionamento

19


2.3 Veículos não Tripulados

Com a necessidade de obtenção de informação e libertação de entidades humanas para tarefas

que requerem mais atenção e um poder de decisão superior, surge então a necessidade de criar

um mecanismo de obtenção de dados autónomo. Com esse intuito surgem então em deter-

minada altura os denominados UxV - Unmanned x-environment Vehicle que são veículos que

possuem capacidade de deslocamento autónomo, podendo possuir ou não, navegação no meio

a que se destinam também de forma autónoma, sendo esta situação apenas uma funcionalidade

acessória à designação real de um UxV. O intuito inicial de um UxV é somente a utilização de

um veículo, em operações de reconhecimento, vigilância, defesa, ataque e socorro que não seja

tripulado. Ao se pensar então num veículo não tripulado, surge então de imediato a questão

da automação. Essa situação torna-se então a mais difícil de implementar uma vez que implica

a atribuição de capacidades cognitivas e de decisão a um sistema oriundo da robótica. Após

a breve descrição do conceito de um veículo não tripulado, vai-se agora falar sobre os veículos

terrestres não tripulados em especi�co, as suas missões e as funcionalidades que possuem nos

dias que correrem.

Como o nome sugere, um UGV -Unmanned Ground Vehicle, em português, VTNT -

Veículo Terrestre não Tripulado é um objeto, que se desloca pelo meio terrestre sem qualquer

tripulação a bordo[10]. Pode tomar qualquer tipo de forma ou tamanho e com a hipótese de

possuir algoritmos internos de aprendizagem automática que permitam responder de forma

autónoma, a determinados acontecimentos que possam surgir durante o desenrolar de uma

missão, previamente atribuída à equipa que está destinada à operação desse equipamento. No

que respeita à operação, esta pode ser[10]:

• Autónoma - Apenas é atribuído o percurso e a missão (por exemplo, �lmar e fotografar

determinado local) ao UGV �cando este sem comunicação até ao seu regresso, ou até

um instante previamente determinado ou uma determinada situação detetada pelo seu

sistema sensorial que implique uma comunicação imediata com o operador, como por

exemplo, a ocorrência de falha no equipamento ou uma emboscada por parte de uma

força inimiga[10];

• Tele-Operada - O sistema é totalmente controlado pelo operador;

• Semi-Autónoma - O uso mais vulgar, em que o veículo se desloca autonomamente até

determinado local e depois passa a ser totalmente controlado pelo operador;

20


Designação Limites de Massas

Micro <3,63 Kg

Miniatura 3,68-13,61 Kg

Pequeno (leve) 14,06-181,44 Kg

Pequeno (médio) 0,18 -1,13 (103)Kg

Pequeno (pesado) 1,13 -9,07 (103)Kg

Médio 9,07-13,61 (103)Kg

Grande >13,61 (103)Kg

Tabela 2.2: Classi�cação de UGV's pelo peso[10]

• Controlo Remoto - Quando o UGV é operado diretamente pelo operador sem possuir

qualquer tipo de processamento de auxilio a quem o opera.

Os UGV's podem ser classi�cados segundo a sua massa assim como pelo seu nível de

automação. Uma tabela de classi�cação por massa pode ser vista na tabela 2.2. Ao nível da

automação, podemos encontrar a classi�cação de UGV's nos seguintes itens[10]:

• Tele-operação - O operador controla todas as operações de missão;

• Gestão por consentimento - O sistema recomenda ações a tomar pelo operador;

• Gestão por exceção - O sistema executa sempre a decisão quando o operador não consegue

ter reação para a tomar;

• Automação total - Todas as funcionalidade são autónomas devendo o operador ser in-

formado sempre que possível.

Os sistemas robóticos autónomos são utilizados tanto no meio civil, como no militar.

Considerando a índole militar desta dissertação, estes sistemas têm como funções[10]:

• Deteção e neutralização de engenhos explosivos;

• Reconhecimento, vigilância e aquisição de alvos;

• Penetrar no território inimigo;

• Proteção da força;

• Segurança física;

• Logística;

• Combate a incêndios;

• Combate urbano;

21


• Emprego de armas;

• Operações em áreas contaminadas;

• Operações de busca e salvamento;

• Operações de índole policial.

Do ponto de vista atual todas estas funcionalidades estão disponíveis em equipamentos

pertencentes a inúmeros países como os Estados Unidos, Reino Unido assim como por muitos

outros países ou entidades privadas. Na maioria das vezes os sistemas usufruem de comu-

nicações via satélite para obtenção de sinal em toda a superfície terrestre. O sistema mais

usado a nível mundial, designado por Talon, pertence aos Estados Unidos. Esse sistema está

representado na Figura 2.2 e permite:

• Comunicação de dados wireless e câmara de transmissão de imagem analógica até 800m

em linha de vista;

• Controlo Remoto por intermédio de um joystick e um display;

• Porto RS 232 e um USB - Universal Serial Bus para transferência de dados;

• Possibilidade de ligação por �bra óptica;

• Sistema de áudio por duas vias;

• Desempenha missões de reconhecimento, EOD, deteção de agentes nucleares, radiológi-

cos, biológicos e químicos assim como missões de segurança, defesa e resgate,

• Tem capacidade para subir escadas, passar através de escombros e de arame farpado;

• Possui uma vasta lista de sensores onde se podem encontrar câmaras térmicas, de visão

noturna e de proximidade da vizinhança;

• Capacidade de processamento e aquisição de dados sobre o meio envolvente, para deslo-

cação autónoma no terreno, usando o sistema GPS e algoritmos especí�cos para o efeito;

• Autonomia para executar missões em longo raio de alcance;

• Interoperabilidade com os restantes meios de vigilância não tripulada.

Tem ainda como opções:

• �High Gain Antenna 1200m LOS;

• Thermal Color Camera;

• Thermal Black and White Camera;

• Night Vision Camera;

• Two isolated �ring circuits;

• Universal disrupter mount;

22


• PAN, RE-73, Royal Arms;

• Shotgun mount;

• Portable X-ray mount (pending);

• Wire cutting tool;

• GPS compass;

• Heavy duty tracks and sprockets;

• Reusable shipping/storage containers;

• Arm ski (ascending and descending tool);

• Scraper;

• Loud Hailer: 120 decibels max�[4].

Figura 2.2: UGV ao serviço dos Estados Unidos - Talon[7]

Em Portugal também existem sistemas a funcionar ao serviço das diferentes forças de

segurança e policiais. Exemplo disso são os equipamentos de EOD - Explosive Ordnance

Disposal da GNR e da unidade de Engenharia do Exército. Existe também um equipamento

ao serviço dos Sapadores, denominado �Raposa� - Figura 2.3, para operações de BeS - Busca

e Salvamento, em áreas perigosas e de visibilidade reduzida.

�O objectivo a longo prazo deste (...) projecto é o desenvolvimento de equipas de robots

heterogéneos (aéreos e terrestres, autónomos e tele-operados) especializados em tarefas parti-

culares, que actuem cooperativamente no terreno para auxiliar, de uma forma coordenada, as

equipas humanas de BeS, tais como:

23


• Robots que se deslocam sobre estruturas colapsadas, en�ando tubos e/ou pequenos

robots em aberturas, para levar ar, transportar água, comida e medicamentos a indi-

víduos presos debaixo dos escombros;

• Robots que são capazes de detectar vítimas sobre ou debaixo dos escombros;

• Robots aéreos que conseguem uma visão panorâmica da área destruída e mapeiam os

graus de destruição de cada zona.

A sua coordenação com outros meios, tais como serviços de informação geográ�ca e modelos

geológicos, poderá no futuro desencadear uma intervenção rápida, e�caz e objectiva após a

ocorrência de um desastre.�[2]

Figura 2.3: UGV ao serviço de Portugal- Raposa[2]

Também em Marte existem sistemas de reconhecimento terrestre. O �Spirit� e o �Oppor-

tunity�. Uma imagem ilustrativa pode ser observada na Figura 2.5. Ambos os sistemas têm

capacidade de se alimentar através de energia solar.

Existe também um sistema, presente na Figura 2.4, a ser desenvolvido atualmente por uma

empresa de Maryland, para o Pentágono, designado por EATR - Energetically Autonomous

Tactical Robot e terá a capacidade de �encontrar, ingerir e extrair energia da biomassa presente

no ambiente� ou recorrer a �combustíveis convencionais e alternativos (como gasolina, gasóleo,

propano [. . . .]�, entre muitos outros. O EATR será alimentado por um motor de combustão

que queima combustível para aquecer água e gerar electricidade a partir do vapor que daí

24


resulta. A Robotic Technologies está a desenvolver o EATR para �ns militares. O objectivo

�nal é criar uma máquina extremamente �exível em termos de fontes de combustível, que

possa vir a funcionar de forma autónoma durante meses ou mesmo anos.�[5]

Figura 2.4: Robô autónomo alimentado por

matéria orgânica[5]

Figura 2.5: UGV presente em Marte-

Spirit [3]

25


26

Capítulo 3

Implementação do Projeto

Antes de proceder à exaustiva explicação da construção da aplicação, vai ser descrita a base e a

linha de pensamento pela qual se manteve sempre alinhado o desenvolvimento desta aplicação.

Como foi referido anteriormente, nos sistemas de automação e remotamente controlados existe

sempre a necessidade de manter metas temporais que permitam instruir o mecanismo a con-

trolar de forma atempada, com vista a evitar acidentes e consequentemente, custos materiais

ou mesmo humanos. Garante-se assim a segurança do espaço envolvente. Dessa forma tem de

ser adotada uma postura de sistema em Real-Time numa das suas seguinte vertentes:

• Suave (Soft Real-Time) � Restrição temporal em que o resultado da resposta do sis-

tema associado mantém alguma utilidade para a aplicação, mesmo depois do limite

pré-estabelecido. Veri�ca-se, após esse limite, uma degradação da qualidade de serviço;

• Firme (Firm Real-Time) � Restrição temporal em que o resultado da resposta do sistema

associado perde qualquer utilidade para a aplicação depois do limite pré-estabelecido;

• Rígida (Hard Real-Time) � Restrição temporal que, quando não cumprida, pode originar

uma falha catastró�ca.

Para melhor perceção deste tipo de sistema é apresentada na Tabela 4.1 de vantagens e

desvantagens dos sistemas referidos anteriormente.

Dadas as características apresentadas, facilmente nesta fase inicial se optaria por um sis-

tema de soft real-time. Contudo isso teria de implicar o uso do protocolo UDP que nesta fase

poderá trazer implicações que poderão prejudicar o desenvolvimento da aplicação, nomeada-

mente a perca de instruções e consequentemente a segurança. A opção tomada passa em boa

parte nesta fase por obter no tempo disponível, uma aplicação funcional não inteiramente im-

27

Implementação do Projeto

Sistema Vantagens Desvantagens

Soft• Fácil implementação (apenas tem de

obedecer ao cumprimento de metas

temporais);

• Baixo custo de implementação;

• O incumprimento da meta tempo-

ral, apesar de dever ser evitado, não

afeta a estabilidade do sistema.

• Não pode ser usado em sis-

temas críticos;

• Possui tempos de resposta

mais elevados.

Hard• Tempo de resposta baixo;

• Garantia de segurança dos sistemas

críticos;

• Vocacionado para os sistemas

autónomos.

• Implementação complexa;

• Custo elevado devido ao con-

junto do hardware necessário

e do tempo dispendido na im-

plementação do sistema;

• O incumprimento da meta

temporal pode provocar

catástrofes.

Firm• Pode-se descartar os dados que não

se obterem até à meta temporal;

• Vocacionado para os sistemas de pre-

visão;

• Vocacionado para os sistemas de pre-

visão.

• Ao se falhar a meta temporal,

a computação �ca obsoleta;

• As falhas signi�cam uma

quebra nos lucros.

Tabela 3.1: Vantagens e Desvantagens dos Sistemas de Tempo Real

28

Levantamento de Requisitos do Sistema

plementada por se tratar de um projeto a longo prazo. Contudo, o levantamento de requisitos

deste sistema terá de �car bem de�nido, ainda que por um tempo limitado, pois este tipo

de tecnologia é desenvolvida a um ritmo difícil de acompanhar. Neste projeto foi imposta

a utilização de Open Source. A opção tomada tem vantagens e desvantagens como se pode

observar na Tabela 3.2

Vantagens Desvantagens

• Acesso a ferramentas gratuitas de

desenvolvimento;

• Possibilidade de se obter uma apli-

cação de baixo custo;

• Possibilidade de aceder e alterar

código já existente.

• Suporte à aplicação reduzido;

• Não se tem garantia de qual-

idade;

• A falta de suporte pode origi-

nar tempo de trabalho exces-

sivo por parte da equipa de

desenvolvimento.

Tabela 3.2: Vantagens e Desvantagens do Open-Source

3.1 Levantamento de Requisitos do Sistema

Seguindo a linha de orientação referida no texto anterior, o desenvolvimento desta aplicação

passa por implementar um sistema capaz de monitorizar, recolher informação, controlar o

ROVIM remotamente e eventualmente desenvolver capacidade de deslocamento autónomo,

ainda que as instruções sejam dadas pela consola de aplicação sem intervenção direta do ope-

rador (situação essa que não segue as linhas de requisitos do Sistema, pois o algoritmo de

navegação autónoma deve correr em pleno na máquina a bordo do ROVIM ), assim como atu-

ar sobre alguns acontecimentos exteriores ao sistema. Outra funcionalidade que é requerida

quando se pensa em sistemas que pressupõem deslocamentos num determinado meio, é insta-

lar uma metodologia que permita em qualquer momento obter um registo de todo o percurso

efetuado, ou seja, um diário de bordo. Bastante similar à �caixa negra� dos aviões, com as

respetivas considerações de segurança dada a probabilidade de se poder divulgar a entidades

alheias informação crucial à nossa segurança. É possível ainda com vista a essa mesma fun-

cionalidade implementar um LVD - Low Voltage Detected que permite mediante um sensor

29


de tensão enviar informação da posição GPS atual quando se detetar uma quebra de tensão

abaixo de um nível pré-determinado. Esse tipo de sensor é de extrema importância uma vez

que, em muitas situações, uma falha de tensão está associada a uma falha de sistema. Logo,

visto ser esta uma aplicação militar, essa situação pode ser indício de atividade de uma força

inimiga no terreno. Essa ocorrência terá uma elevada probabilidade de ser o caso de um

ataque ao equipamento presente no teatro de operações. Contudo, esta funcionalidade terá

de ser implementada ao nível do ROVIM e que é alheio ao trabalho realizado ao longo desta

dissertação. Apenas �ca implementado na aplicação o referido diário de bordo com informação

de término de sinal do ROVIM ao receber a informação proveniente do LVD.

Apesar do desenvolvimento desta arquitetura, todo o sistema, desde o mais simples sistema

mecânico até à consola de interface RovimViewer, ser relativa a um robô de vigilância terrestre,

do ponto de vista da aplicação RovimViewer, foco primário desta dissertação, o �veículo� a

controlar será transparente para a consola de interface. Dito isto, essa ideia concretiza-se a

partir do momento em que o operador da aplicação pode controlar qualquer tipo de aparelho

que disponha da mesma ligação física, desde que se tenha disponível a lista de comandos

e protocolo de comunicação que o equipamento reconhece. Para se obter essa abstração a

um protocolo especí�co, vai ser implementado um servidor que permita traduzir as mensagens

oriundas da RovimViewer para o dispositivo de destino ter capacidade de interpretar a intenção

do operador.

Para além destas características, uma aplicação de controlo de um sistema robótico deste

género deve permitir uma série de requisitos que são incrementados após a consciencialização

de se tratar de uma aplicação militar. Neste ponto, deve ser possível construir um relatório

na aplicação e transmitir esse relatório de forma imediata. No âmbito de uma aplicação de

controlo e monitorização genérica de robótica, tem de se ter em conta todas as características

observadas em[16], assim como mais uns quantos requisitos:

• Envio periódico de sinais da aplicação para o ROVIM que permita um controlo linear e

�uido permanente;

• Monitorização do estado dinâmico do ROVIM, que inclua, velocidade, direção, estado

de bateria de modo a transmitir segurança e controlo ao operador;

• Obtenção regular dos diversos sensores de observação do ambiente envolvente;

• Transmissão assíncrona de mensagens de erro ou instabilidades do ROVIM como por

exemplo o caso de LVD;

30


• Especi�cação da rota ou destino a seguir autonomamente por parte do ROVIM ;

• Capacidade de ligação série para descarregar dados, imagens e vídeo oriundos da missão

executada;

• Possibilidade de controlar equipamentos, ROVIMs, que se desloquem por qualquer meio,

ar, água (incluindo o meio sub-aquático), de modo transparente para a aplicação.

Do ponto de vista do ROVIM, as especi�cações estão referidas na secção De�nição do Pro-

blema. Contudo, de acordo com a mesma dissertação citada anteriormente[16], existem os

seguintes requisitos para o ROVIM :

• Possuir capacidade de processamento e execução de rotinas pré-programadas;

• Executar de algoritmos de aprendizagem automática como o caso das redes neuronais;

• Deverá ter a capacidade de detetar eventuais falhas de comunicação a�m de evitar colocar

em risco o próprio aparelho ou o meio envolvente, entrando nessa altura em modo seguro;

• Observação periódica dos sensores a bordo do e envio de informações respeitantes a

possíveis erros para o operador do ROVIM que se encontra no RovimViewer ;

• Deve ter capacidade de enfrentar condições climatéricas adversas que poderiam provocar

danos irreversíveis ao equipamento;

• Os algoritmos de navegação autónoma são executados a bordo. A aplicação atribuirá

apenas pontos de referência para o ROVIM percorrer, �cando depois a execução do

percurso a cargo do processamento interno do ROVIM ;

Por �m, do ponto de vista dos requisitos da aplicação RovimViewer e do dispositivo

robótico ROVIM, tendo em consideração o destino militar a que se propõem, observação

e vigilância do teatro de operações, con�ituoso ou não, existem uma série de requisitos de

robustez, segurança física e segurança de dados a ter em consideração. Neste aspeto deve-se

perceber bem qual o conceito de segurança assim como qual o seu signi�cado e importância

no mundo das operações militares, algo que pode ser visto no anexo A. Observam-se então os

seguintes requisitos:

• Dispor de uma consola de interface que permita uma utilização por parte do comando e

serviços de Intelligence do Estado Maior, tal como, por elementos de pequenas unidades

de escalão pelotão;

• A consola de interface deve ser intuitiva, fácil de usar e com capacidade de atualização;

• A aplicação deve ter um controlo fácil e intuitivo de múltiplos ROVIMs;

• Deve estar disponível na aplicação um local para escrita de relatórios que tenham a

31


possibilidade de ser difundidos pela rede;

• Controlo e comando do ROVIM de forma �uida e suave;

• Capacidade de fornecer In-Time, dados para o comando das forças no teatro de ope-

rações;

• Capacidade de realizar algumas tarefas autonomamente como o deslocamento de um

ponto A para um ponto B, incluindo a transposição de obstáculos. No caso de insucesso

na transposição, deve ser transmitida uma mensagem de alerta para o operador assumir

o controlo do ROVIM ;

• Disponibilizar um relatório de leitura de sensores periódica, para se perceber de forma

clara o estado do ROVIM ;

• Disponibilizar níveis de segurança e imobilização consoante a missão/tarefa que o ROVIM

está a desempenhar, com o intuito de evitar danos e perdas de valor acrescentado, tanto

para o ROVIM, como para o meio envolvente;

• Capacidade de acompanhar uma força terrestre, implicando desse modo, a capacidade

de enfrentar os diversos obstáculos existentes no terreno, que tanto podem ser naturais

como arti�ciais;

• Resistência do equipamento às condições climatéricas adversas;

• Uma autonomia que permita realizar missões/tarefas em segurança e com sucesso;

• Devido aos meios de informação e contra-informação do opositor no teatro de operações,

existe a necessidade de manter um curto raio de alcance de comunicações devido ao

espetro eletromagnético criado pelas ligações sem �os;

• Disponibilizar uma arma que possibilite reconhecimento em força, ou mesmo uma defesa

extra em caso de uma ofensiva da força opositora;

• Capacidade de interação entre os diferentes ROVIMs;

• Possuir diferentes tipos de sensores (térmicos, de inclinação, bússola, GPS, tensão);

• Algoritmos de previsão de deslocamento;

• Envio de mensagens assíncronas imediatamente após se detetar que possivelmente vai

ocorrer uma falha do sistema com informação da localização, hora, estado da bateria,

velocidade e direção;

• Todo o sistema construido deve disponibilizar uma manutenção fácil e com custo re-

duzido;

• Baixo custo de produção que permita uma boa relação custo/benefício.

32

Desenvolvimento da Aplicação

Facilmente se percebe que existem conceitos que requerem mais tempo e conhecimento para

a sua correta implementação. Iniciou-se assim o desenvolvimento do RovimViewer, com o

intuito de obter uma aplicação que permitisse controlar remotamente o ROVIM, de forma

�uida e estável, dentro daquilo que o protocolo TCP/IP permite. À medida que a aplicação

foi tomando forma, foram-se então introduzindo novas funcionalidades. Dadas as especi�cações

do sistema a implementar, após a conclusão desta dissertação �carão a funcionar os seguintes:

• Dispor de uma consola de interface que permita uma utilização por parte do comando e

serviços de Intelligence do Estado Maior, tal como, por elementos de pequenas unidades

de escalão pelotão;

• Capacidade de fornecer In-Time, dados para o comando das forças no teatro de ope-

rações;

• Possibilidade de controlar equipamentos, ROVIMs, que se desloquem por qualquer meio,

ar, água (incluindo o meio sub-aquático), de modo transparente para a aplicação;

• Monitorização do estado dinâmico do ROVIM, que inclua, velocidade, direção, estado

de bateria de modo a transmitir segurança e controlo ao operador;

• Envio periódico de sinais da aplicação para o ROVIM que permita um controlo suave,

linear e �uido permanentemente;

• A aplicação deve controlar múltiplos ROVIMs de forma fácil e intuitiva;

• A consola de interface deve ser intuitiva, fácil de usar e com capacidade de atualização;

• Especi�cação da rota ou destino a seguir autonomamente por parte do ROVIM ;

• Algoritmos de previsão de deslocamento;

• Todo o sistema construido deve disponibilizar uma manutenção fácil e com custo re-

duzido;

• Baixo custo de produção que permita uma boa relação custo/benefício.

3.2 Desenvolvimento da Aplicação

Esta secção é composta por duas sub-secções que apresentam de forma distinta duas situações:

o desenvolvimento da Aplicação Ideal, em relação à implementação de projeto no âmbito da

camada de baixo nível do RovimViewer em �oposição� ao que se desenvolveu efetivamente no

âmbito do mesmo problema. As duas situações são iguais no que respeita à camada de alto

nível do RovimViewer. Esta situação deveu-se às limitações temporais existentes para o desen-

33

Desenvolvimento da arquitetura de baixo nível da Aplicação Ideal

volvimento do projeto em conjunto com a maior complexidade existente no desenvolvimento

da arquitetura descrita na primeira secção.

3.2.1 Desenvolvimento da arquitetura de baixo nível da Aplicação Ideal

Vai-se agora proceder à implementação da aplicação que vai contribuir para a construção de um

sistema de vigilância terrestre de baixo custo. Nesta secção vai ser demonstrado como deveria

ser desenvolvido o projeto de forma correta e adequada da aplicação em termos de tempo

real, programação paralela, sincronização de tarefas e exclusão mútua. As restantes de�nições

da aplicação (aspeto e funcionalidade) são comuns ao que foi implementado efetivamente.

Nesta secção traduz-se as metodologias e as linhas de orientação dos requisitos relativos à

programação de baixo nível.

A aplicação, RovimViewer desenvolvida neste projeto, é apresentada como uma resposta

às necessidades do sistema global em termos de software de interação com o utilizador. É

necessário então, desenvolver um algoritmo de base que permita conjugar e articular as dife-

rentes tarefas propostas para esse sistema. Ao surgir a necessidade de implementar uma

aplicação, em tempo real, com as funções de:

• Recolher e apresentar imagem de vídeo;

• Recolher sinal de GPS e mostrar posicionamento num raster1 ou numa imagem vetorial2

previamente adquirida3;

• Controlar e monitorizar o ROVIM ;

• Algoritmos de previsão da trajetória.

Veri�ca-se a necessidade de implementar um sistema RT multi-tarefa que permita as fun-

cionalidades anteriores. O sistema RT serve para garantir que determinada função é executada

dentro de um prazo pré-determinado, enquanto a componente multi-tarefa tem a função de

executar as diferentes tarefas de forma paralela (em simultâneo) que permitam, de um modo

e�ciente, alcançar as funcionalidades propostas. Um sistema RT tem associado uma diversi-

dade de conceitos que têm de ser abordados. Existem os conceitos de criação, execução, estados

de tarefas, escalonamento e partilha de recursos. Neste sistema é fácil observar de imediato

1Imagem aérea geo-referênciada que se pode adicionar à aplicação.2Imagem constituida por pontos geo-referênciados que constituem linhas e/ou polígonos que representam

uma área de terreno3Disponibilizada pelo Instituto Geográ�co do Exército

34

Desenvolvimento da arquitetura de baixo nível da Aplicação Ideal

que cada uma das funções referidas anteriormente, serão executadas em tarefas independentes

de modo a fazer uso dos diferentes núcleos de processamento existentes na plataforma de hard-

ware. Consegue-se assim um desempenho adequado para o objetivo da aplicação desenvolvida.

Associado a uma tarefa está também um estado. Estes estados re�etem a não existência de

núcleos de processamento para cada uma das tarefas existentes. Existe assim a necessidade

de atribuição de estados a tarefas de modo a que todas possam ser executadas. Uma tarefa

diz-se Pronta a executar após a sua ativação. Esse estado re�ete a situação em que uma

tarefa se encontra na �la de espera do processador a aguardar pelo estado de Execução. Esta

�la é ordenada consoante o escalonamento adotado para o sistema. Ao ser terminada a tarefa,

esta passa para o estado Dormente. Uma tarefa assume o estado de Bloqueada quando

tenta aceder a um recurso partilhado que se encontra ocupado. Após libertado o recurso a

tarefa passa ao estado de Pronta (Esta situação implica o desenvolvimento de um gestor

de recurso). Em determinados casos, a economia de recursos energéticos (necessários ao sis-

tema proposto), é conveniente que a tarefa que não está a ser requisitada entre no modo de

Suspensão. Pode-se observar um diagrama na Figura 3.1 que resume as ideias transcritas.

Figura 3.1: Diagrama de estados de uma tarefa

Após a explicação dos problemas provenientes da programação multi-tarefa, é necessário

reter alguns conceitos essenciais à construção da arquitetura RT desenvolvida no projeto ideal.

Nesse projeto existe um gestor de tarefas com capacidade de criar, destruir, ativar e atribuir

35

Desenvolvimento e Explicação dos módulos do RovimViewer e a sua funcionalidade

estados a tarefas, consoante as situações observadas no contexto4 individual de cada tarefa. Ao

existir este gestor de tarefas, também deve estar presente um gestor de tempo que monitorize

os intervalos temporais de permanência de uma tarefa em determinado estado. É necessário

evitar que esta �que inde�nidamente bloqueada. Existe a necessidade de gerir os recursos

existentes por intermédio de mutexes e semáforos5.

Na aplicação desenvolvida, existe a utilização do recurso de uma única placa de rede para

o envio de comandos, receção de dados e de imagem. Observam-se três funcionalidades que

correm em tarefas distintas (multi-threading) que recorrem ao mesmo recurso. Observa-se

então a necessidade de implementar uma gestão de recursos partilhados. Ao veri�car que está

presente na aplicação o uso de imagem de vídeo, estão também presentes restrições temporais

acentuadas. A não preempção também tem de ser cumprida assim como, as precedências.

Tem de se conseguir, perante os recursos disponíveis, todos esses requisitos de modo a obter

um escalonamento que seja exequível. Um dos métodos de implementação de escalonamento

é o da meta-temporal. Este consiste em executar a tarefa que tem uma meta temporal mais

próxima, �cando essa como mais prioritária. A Tabela 3.3 apresenta a utilização de recursos

de forma simpli�cada, de modo a perceber efetivamente a necessidade de implementação desta

arquitetura.

Tarefas Rede Processador monitor

GPS√ √ √

Imagem√ √ √

Controlo ROVIM√ √ √

Algoritmos de Previsão√ √

Tabela 3.3: Uso de recursos por parte dos módulos do RovimViewer

3.2.2 Desenvolvimento e Explicação dos módulos do RovimViewer e a sua

funcionalidade

Nesta secção vai ser descrita de forma detalhada o desenvolvimento da aplicação, em termos

efetivos, face às limitações dos recursos temporais e físicos. São também apresentadas as

soluções para os problemas oriundos da dinâmica da mecânica dos ROVIMs, da rede (devido

4Entende-se por contexto o conjunto de variáveis e alocação de memória de cada tarefa.5São métodos que permitem inibir ou autorizar o acesso a determinado recurso.

36


à transmissão de imagem e de comandos sobre diferentes níveis de ocupação da largura de

banda disponível), da sincronização de tarefas e da apresentação de informação georeferênci-

ada. Também são expostas as soluções para a diversidade de con�gurações disponíveis. De

um modo menos incisivo também se apresenta alguma implementação ao nível do baixo nível

da aplicação.

O projeto desenvolvido tem na sua constituição seis módulos integrados e interligados que

constituem a aplicação RovimViewer. Encontram-se na aplicação os módulos de:

• Observação e monitorização;

• Con�guração e controlo;

• SIG - Sistema de Informação Geográ�ca;

• Diário de bordo e apresentação de mensagens assíncronas;

• Servidor de atribuição de protocolo e cálculo de tarefas adicionais;

• Sistema de antecipação de dados e informação relativos ao posicionamento.

Vai-se proceder à explicação da constituição de cada um dos módulos a serem implemen-

tados. Apesar do RovimViewer ser desenvolvido em linguagem OO - Orientada a Objetos, não

se tem em exclusivo um módulo por objeto. Existe sim a conjugação de um ou mais módulos

por objeto. Para uma leitura mais acessível é então descrita a funcionalidade de cada módulo,

apresentado anteriormente, na tabela 3.4.

Os módulos apresentados são guarnecidos pela exclusão mútua de recursos recorrendo ao

uso simples de mutex. Esta situação pode-se observar na seguinte transcrição de código da

aplicação:

�sock.settimeout(500) #Tempo em milissegundos de espera para receção de dados

locksock.acquire() #Teste de entrada em zona crítica recorrendo a um mutex

front=pack('cbbb','M',leftmotor,rightmotor,durationtime) #Sting de instrução

sock.sendall(front) #Envio da intrução por intermédio do socket

try:

datain = sock.recv(stringlenght) #Receção do Ack de con�rmação

locksock.release() #Libertação do mutex

print "Received:", repr(datain) #Apresentação do Ack para debug

except: #Em caso de timeout do socket

locksock.release() #É libertado o acesso ao recurso

37


Módulo Funcionalidade

Observação e monitor-

ização

Presente na etiqueta ROVIM da aplicação, tem como objetivo

visualizar o meio envolvente ao ROVIM, assim como monitorizar

o estado dinâmico e físico deste.

Con�guração e controlo Disponibilizada a opção de con�guração de teclas de atalho às

funções e comandos disponíveis na aplicação. É também disponi-

bilizada uma thread com uma rotina de captação de sinal de um

joystick para um melhor controlo sobre o ROVIM.

SIG - Sistema de Infor-

mação Geográ�ca

Observação do meio envolvente ao ROVIM recorrendo ao uso de

informação geográ�ca vetorial e raster

Diário de bordo e apre-

sentação de mensagens

assíncronas

Serve o operador com informação relativa à missão, ao percurso

efetuado, à localização de forças hostis, assim como mensagens de

alerta relativas a casos críticos observados pelo sistema sensorial

do ROVIM

Servidor de atribuição

de protocolo e cálculo de

tarefas adicionais

Tarefa a correr numa máquina independente que distribuí a lista

de comandos aceite por IP de cada ROVIM. Este servidor poderá

fazer também tarefas de cálculo mais moroso de modo a evitar

ocupação de processamento na máquina que corre o RovimViewer.

Sistema de antecipação

de dados e informação

relativos ao posiciona-

mento

Neste módulo está presente o algoritmo matemático de previsão

de rota consoante os últimos pontos. É usado o algoritmo LPC

- Linear Predictive Coding recorrendo ao algoritmo de Levinson-

Durbin para cálculo dos coe�cientes.

Tabela 3.4: Descrição dos módulos existentes no RovimViewer

38


Ao observar o código visualiza-se a utilização de um mutex de controlo de recursos do

RovimViewer por intermédio da instrução �locksock.acquire()�. É possível ainda veri�car a

implementação de um método que permite que a tarefa não �que bloqueada no mutex. Esse

método está presente na de�nição de um timeout do socket. Essa instrução é visível na primeira

linha do código aqui transcrito. Ao ocorrer o sinal de timeout, é lançada uma exceção que

é captada pelo �except�. Então, ao ser apanhada essa exceção é então libertado o recurso

permitindo desse modo o acesso de outra tarefa ao recurso.

O alto nível da aplicação é desenvolvido recorrendo ao software de desenvolvimento QT-

Designer. Neste software é desenvolvida a base da aplicação que consiste na colocação e apre-

sentação de botões e janelas grá�cas, sem qualquer tipo de funcionalidade. Após a obtenção

deste �esboço� da aplicação é corrido na consola um comando que permite obter o código em

linguagem python que vai ser trabalhado e alterado até se obter o produto �nal. Contudo, até

chegar a este software de desenvolvimento grá�co teve de se escolher e perceber qual a apli-

cação que se adaptava às necessidades de desenvolvimento da aplicação. É desenvolvido então,

um processo de implementação iterativo da aplicação. Esse processo foi pensado de modo a

voltar sempre a um ponto anterior que permita a construção de metodologias e abordagens

de desenvolvimento que permita, após o término do ciclo recursivo, obter a aplicação com

uma maior correção. Através do comando pyuic4 -x rovim.ui -o rovim_add.py obtém-se o �es-

queleto� de código da aplicação que tem de ser posteriormente desenvolvido e implementado.

O �cheiro rovim.ui é a consola construida em modo grá�co por intermédio da aplicação QT

Designer e o rovim_add.py conterá o código em python da aplicação. Esse código foi sempre

reajustado à aplicação utilizando o ambiente de programação Geany assim como se recorreu

diversas vezes à ferramenta de desenvolvimento grá�ca para acrescentar novos objetos grá�cos

à aplicação. Esse processo pode ser observado na Figura 3.2.

O aspeto grá�co da aplicação RovimViewer foi desenvolvida consoante a necessidade de

resposta aos problemas apresentados e a vontade de se ver implementada determinada fun-

cionalidade. Em relação às necessidades, tiveram-se em conta as de dissolução de problemas

mecânicos, assim como de problemas de �uxo de dados e acesso a novos ROVIMs, para além de

todas aquelas que foram apresentadas no levantamento de requisitos. Em relação aos proble-

mas mecânicos é de salientar as diferenças de o�set da direção no deslocamento. Surge então

a implementação da barra de a�nação de direção no RovimViewer. Esta barra é crítica uma

39


Figura 3.2: Processo Iterativo de desenvolvimento da aplicação RovimViewer

vez que após ser implementada pode-se con�gurar a aplicação para �empurrar� o ROVIM para

a esquerda. Essa situação revela efetivamente um deslocamento mais retilíneo por parte do

ROVIM se este tiver uma tendência natural de deslizar para a direita. Contudo, devido à

correção de o�set não estar corretamente implementada, devido ao elevado número de en-

tradas no sistema de controlo, o ROVIM acaba por ter uma resposta mais rápida no sentido

da a�nação do o�set, neste caso para a esquerda. Ainda assim, veri�ca-se que é preferível

possuir a a�nação do o�set, ainda que não totalmente correta no momento em que é exposta a

aplicação à prova a novos operadores. A solução deste problema passa por implementar uma

rotina de deteção da intenção do operador e eliminar os efeitos de a�nação de o�set nesse

instante.Pode-se observar na Figura 3.3 a representação do a�nador de direção. Nessa �gura

é possível observar também um conjunto de botões para controlar o ROVIM. Inicialmente

pensou-se apenas na colocação de um controlo do tipo joystick, contudo veri�cou-se que ex-

iste necessidade de garantir que se possa controlar o equipamento em situações de falha desse

40


periférico de controlo. Veri�cou-se que surgiu a necessidade de se criar um local de con�gu-

ração de teclas de atalho para o controlo do ROVIM. Criou-se então a etiqueta �controlos� que

permite con�gurar as teclas de controlo do equipamento autónomo como se pode observar na

Figura 3.4. Outras con�gurações são necessárias pois tem de ser prever um elevado número e

diferentes tipologias de dispositivos passíveis de ser controlados. Contudo, pela limitação de

tempo disponível não foi possível implementar �cando o objetivo de implementação limitado

ao robô existente para teste da aplicação. Porém, existem por intermédio do joystick mais

níveis de liberdade e de con�guração que permitem uma adaptação mais fácil. Na próxima

secção será então detalhado, a título de exemplo, como se pode adaptar a aplicação a um

dispositivo móvel voador.

Figura 3.3: A�nação do o�set de direção do ROVIM

Figura 3.4: Con�guração de teclas para controlo do ROVIM

Ao se falar do sistema de controlo remoto do ROVIM, observa-se a necessidade de imple-

mentar uma janela de visualização do ambiente em redor do ROVIM. Essa janela tem inerente

um problema bastante crítico: a sua dimensão. Se for consideravelmente superior a 420X290

ocupa demasiado espaço na janela da aplicação e introduz um tempo de processamento de im-

agem proporcionalmente mais elevado, devido ao desempenho de processamento disponível por

41


parte dos equipamentos. Essa situação é explorada e observada e experimentada no capítulo

dos resultados experimentais por intermédio da Tabela 4.2. Para solucionar esse problema,

é colocada à disposição uma con�guração da qualidade de imagem para o utilizador onde se

pode observar nas Figuras 3.5 e 3.6. Em utilização é notável a diferença de resposta da

imagem consoante a sua qualidade.

Figura 3.5: Visualização do meio envolvente

ao ROVIM

Figura 3.6: Con�guração da qualidade de im-

agem presente no RovimViewer

A imagem do ambiente envolvente é extremamente importante para o seu controlo. Con-

tudo, não é su�ciente para descrever o ambiente que envolve efetivamente o ROVIM nem para

descrever o estado dinâmico em que este se encontra. Para um melhor detalhe sobre essa in-

formação é disponibilizado um SIG - Sistema de Informação Geográ�ca que permita visualizar

o ROVIM de uma vista aérea, assim como, as coordenada referentes ao posicionamento global

atual do ROVIM. Na Figura 3.7 está ilustrado (com valores de localização adulterados proposi-

tadamente) o RovimViewer a disponibilizar as informações relativas à velocidade, direção de

deslocamento, posicionamento por intermédio de imagem raster que permite visualizar o am-

biente envolvente do ROVIM através de vista aérea. Ainda em relação ao módulo SIG, é

possível efetuar uma gestão das camadas de visualização utilizadas por intermédio da Layer

List e das ferramentas disponibilizadas no topo da janela do RovimViewer. O posicionamento

no terreno representado por uma marca circular vermelha. Nessa �gura também é possível

observar o estado atual da bateria presente no ROVIM.

De acordo com o objetivo proposto inicialmente de controlar múltiplos ROVIMs surge,

42


Figura 3.7: Módulo SIG e dinâmico presente no RovimViewer

também, um local para introduzir os endereços IP de cada equipamento. O local de introdução

pode ser visto na Figura 3.8 no objeto Lita Rovim.

Figura 3.8: Local de introdução e listagem dos endereços de acesso ao ROVIM

Para concluir a descrição da funcionalidade da aplicação, Fica apenas a faltar a apre-

sentação do módulo de diário de bordo. Pode-se observar na �gura 3.9 uma ilustração de

um percurso efetuado pelo ROVIM, assim como o tempo despendido a executar a missão.

Portanto, também aqui está presente o módulo SIG.

Após a apresentação de toda a funcionalidade existente visível pelo operador, é conve-

niente mostrar a funcionalidade interna assim como todo o �uxo de dados existente na apli-

43

Protocolos, capacidade do ROVIM em uso e adaptação a um novo Protocolo

Figura 3.9: Diário de Bordo da missão do ROVIM

cação. Torna-se apropriado explorar este assunto visto que é um dos métodos de análise de

desempenho de código. Contudo, não será feita essa análise remetendo esse trabalho para

proposta futura. A �gura 3.10 ilustra o trânsito de informação entre as tarefas e o ROVIM.

3.3 Protocolos, capacidade do ROVIM em uso e adaptação a

um novo Protocolo

Para desenvolvimento da aplicação foi usado um robot adquirido à Surveyor designado por

Surveyor SRV-1 Black�n. Este ROVIM possui um �rmware com um conjunto de operações

prede�nidas.

Como se pretende uma aplicação que seja independente do protocolo de comunicação e

transparente nesse aspeto para o operador do RovimViewer, decidiu-se à semelhança do que

acontece com o servidor de nomes DNS - Domain Name System, criar um servidor que traduza

os comandos do Surveyor SRV-1 para os comandos de cada ROVIM especí�co. Dessa forma,

apenas o gestor do sistema pode, de�nir, alterar ou criar comandos de interação com o ROVIM,

inibindo dessa forma, o acesso a esse tipo de con�gurações ao operador. Esta opção foi tomada

44


Figura 3.10: Fluxo de dados da aplicação RovimViewer

45


face ao equipamento usado, para desenvolvimento da aplicação, ser �limitado� em termos de

recursos. Por outro lado, para existir uma abstração do protocolo de comandos, a aplicação

RovimViewer necessita de enviar sinal para o interpretador de comandos. Sinal esse que será a

indicação do IP do ROVIM a controlar. Inicialmente optou-se por usar o protocolo já existente

para controlar diretamente o ROVIM sendo desenvolvido, à posteriori numa segunda fase, um

interpretador de comandos para os diferentes ROVIMs. Isto possibilita adicionar facilmente

um ROVIM à rede permitindo desse modo (desde que possua um protocolo de comandos e

use o mesmo protocolo de comunicações da aplicação, neste caso TCP/IP) passar a controla-lo

diretamente a partir da aplicação RovimViewer.

O dispositivo que será adaptado à aplicação vai ser o Ar.Drone Parrot, presente na

Figura 3.11. Este equipamento tem como protocolo de comandos o AT que tem a seguinte

estrutura:

Syntax : AT*PCMD = %d, %d, %d, %d, %d, %d <LF>

Argumento 1 : Número de sequência

Argument 2 : �ag que habilita o uso de comandos progressivos e/ou os combinados no

modo Yaw (bit�eld)

Argument 3 : esquerda-direita - �oating-point no intervalo [-1..1]

Argument 4 : frente-trás - �oating-point no intervalo [-1..1]

Argument 5 : velocidade vertical - �oating-point no intervalo [-1..1]

Argument 6 : velocidade angular - �oating-point no intervalo [-1..1]

Do joystick é capturado o sinal em relação aos vários eixos:

j = pygame.joystick.Joystick(0)

j.init()

pygame.event.pump();

axisX=j.get_axis(0);

axisY=j.get_axis(1);

axish=j.get_axis(2);

axisw=j.get_axis(3);

46


Figura 3.11: Parrot AR.Drone

Todos os valores obtidos são compreendidos entre [-1..1]. Dado isto, basta na tarefa que

envia os comando de controlo, enviar a seguinte sintax via UDP - User Datagram Protocol

para o IP e o Porto do ROVIM :

AT*PCMD = numseq++, �agyaw, axisX, axisY, axish, axisw <LF>

Em relação à imagem do Ar.drone esta tem uma construção um pouco mais complexa

assim como os comando para a obter o são. Essa imagem é obtida em pipeline uma vez que

vem segmentada como se pode observar na Figura 3.12.

Para obter essa imagem, na tarefa de obtenção de imagem tem de vir a seguinte sequência

de código:

bufsnd = { 0x01, 0x00, 0x00, 0x00 }; \* Comando para chamar a rotina do Ar.drone de

envio de imagem *\.

DatagramPacket packetsnd = new DatagramPacket (bufsnd, bufsnd.length, ARDroneAd-

dress, ARDrone.VideoPort);

socketvideo.send(packetsnd);

A partir de agora o ARDrone vai envia os pacotes de imagem tal como o Surveyour SRV-

47

Limitações do Projeto

Figura 3.12: Imagem do Ar.drone segmentada

1. Contudo neste caso vem a imagem em faixas. O inicio de cada faixa tem como cabeçalho

�GOBSC� seguido dos bytes de imagem. É necessário fazer o parsing da string e carregar a

imagem na RovimViewer. Para mais detalhes recomenda-se a consulta das especi�cações em:

ARDrone_SDK_1_6_Developer_Guide.pdf[1].

3.4 Limitações do Projeto

Nesta secção serão relatados todos os problemas encontrados na fase de testes e observação

da aplicação RovimViewer. Vão-se tornar problemas conhecidos, que terão tendência natural

para aumentar à medida que se vai usando a aplicação. Deverá ter-se em conta o curto

tempo disponível para desenvolvimento deste protótipo. Não é recomendado desenvolver a

aplicação que dará origem à versão �nal partindo do código aqui exposto como se observa nas

metodologias de desenvolvimento de produtos em[11].

Todo o projeto necessita de ser controlado desde o seu planeamento até à sua �nalização.

Tendo em conta a �nalidade do projeto, o sistema de RT implementado carece de atenção

face aos protocolos utilizados. Ainda em referência ao mesmo tipo de sistema, é necessário

alterar o �uxo de dados de digital para analógico e em canal independente de modo a evitar

latências do �uxo de dados de imagem. Passa-se deste modo a possuir duas ligações wireless

por cada ROVIM. Também não é de todo aconselhada esta situação uma vez que se vai ocupar

o espetro eletromagnético de uma forma mais acentuada podendo divulgar inoportunamente

a existência das forças aliadas às forças hostis. Este é um ponto que carece de uma maior

48

Estimador de Movimento

atenção face aos prós e aos contras das duas soluções. A proposta exposta nesta dissertação

é a utilização de ambos os sistemas no ROVIM onde se pode escolher remotamente qual o

modo de operação a utilizar.

Existe também uma latência acrescida no momento em que se passa a controlar o ROVIM

em relação ao carregamento de mapas no módulo SIG. Como a visualização da imagem prove-

niente do ROVIM é uma tarefa prioritária, tal como a tarefa de controlo por intermédio do

joystick, ao solicitar o processador para executar uma tarefa com prioridade mais baixa, este

não vai responder corretamente acabando mesmo por não avançar com essa tarefa. Existe

assim necessidade de colocar em funcionamento um escalonador de tarefas que por intermédio

de um time-slice vá permitindo que a tarefa de prioridade mais baixa se execute.

3.5 Estimador de Movimento

A previsão da trajetória do(s) ROVIM(s) pode ter bastante interesse no caso de quebra tem-

porária de comunicação ou, mesmo, para uma perceção da movimentação no terreno. A ideia

subjacente é a de que a posição no futuro próximo (no instante temporal seguinte, por exem-

plo) se possa obter como uma combinação linear das posições atual e passadas como ilustrado

na Equação 3.1. Trata-se, no fundo, de introduzir um efeito de memória o que, do ponto de

vista matemático se pode traduzir através de uma �ltragem por um sistema linear cuja função

de transferência apenas apresenta pólos. Esta previsão encerra um erro que se pretende mín-

imo 3.2. Assim, os pesos da combinação linear mencionada podem ser obtidos através de um

mínimo, xy, que tenha em conta um funcional de custo baseado nesse erro. Concretamente,

nestas aplicações, é usual utilizar-se uma métrica quadrática: trata-se pois, de minimizar o

valor expectável do erro quadrático. Este processo tem sido alvo de estudo exaustivo há várias

décadas para as mais diversas aplicações [Sistemas autónomos, especulação de economia de

mercados, ...] mas que, de uma forma simpli�cada, se baseia na resolução de um sistema linear

de equações visível na Equação 3.4

Neste caso concreto, tenta-se prever de uma forma aproximada o destino do ROVIM tendo

em consideração o percurso anterior. Recorre-se assim ao algoritmo de predição linear LPC -

Linear Predictive Coding.

Para perceber o modo de funcionamento do LPC, deve existir um foco de atenção sobre a

equação 3.1. Sendo x[n] o ponto a prever, por analogia x[n−k] serão todos os pontos anteriores,

49


os quais se podem denominar entradas do sistema. Surge então a necessidade de encontrar

uma metodologia que forneça os pesos ótimos para o cálculo do novo ponto. Sugere-se então o

cálculo da auto-correlação. Este termo vem do facto de se efetuar um cálculo de correlação de

um determinado conjunto de dados com ele próprio. O valor obtido de correlação corresponde

à forma como cada elemento in�uência a sua vizinhança. Quer isto dizer que este valor indica,

em sentido lato, se existe algum padrão entre os valores de dois conjuntos. Esse cálculo pode

ser observado em 3.3.

x[n] - Conjunto dos pontos que se obtiveram até ao momento

N - Número de elementos presente no mesmo conjunto.

x[n] =P∑

k=1

akx[n− k] + e[n] (3.1)

min E{e(n)2

}(3.2)

Rxx(k) =

n0+N∑n=n0+N+k

xnxn−k (3.3)

Após o cálculo da matriz de auto-correlação toma-se então a igualdade representada

em 3.4. Nesta notação os r(x) representam a matriz de auto-correlação dos pontos anteri-

ores obtidos até ao momento. Para se perceber o método, vai-se atribuir a cada uma das

componentes dessa equação uma variável distinta como se pode observar em 3.5, 3.6, 3.7.

r(0) r(1) · · · r(P − 1)

r(1) r(2) · · · r(p− 2)...

.... . .

...

r(P − 1) r(P − 2) · · · r(0)

•

a(1)

a(2)...

a(P )

=

r(1)

r(2)...

r(P )

(3.4)

R =

r(0) r(1) · · · r(P − 1)

r(1) r(2) · · · r(p− 2)...

.... . .

...

r(P − 1) r(P − 2) · · · r(0)

(3.5)

50


A =

a(1)

a(2)...

a(P )

(3.6)

P =

r(1)

r(2)...

r(P )

(3.7)

Obtém-se deste modo R·A=P. Como R e P são obtidos diretamente a partir da matriz

de auto-correlação Rxx, é fácil obter os coe�cientes do �ltro que estão presentes na matriz A.

Efetuando o passo intermédio inv(R)·R·A=inv(R)·P, obtém-se A=Inv(R)·P. Assumindo que o

�ltro tem uma dimensão considerável, este método de cálculo pode ser bastante demorado o

que pode provocar atrasos prejudiciais ao desempenho da aplicação. Considerando esse facto

e observando mais atentamente a matriz de auto-correlação, veri�ca-se que esta é simétrica e

todas as diagonais são constituídas pelo mesmo valor.

Surge agora a possibilidade, dada a característica anterior, de utilizar um algoritmo com-

putacional para determinar os coe�cientes do �ltro de um modo mais e�ciente. De seguida é

descrito o algoritmo recursivo Levinson-Durbin:

Tendo em conta a seguinte notação:

R[i] - Auto-correlação das entradas

A[i] - Coe�cientes do �ltro

K - Coe�cientes de re�exão

Alpha - Ganho de previsão

Executa-se o seguinte algoritmo:

A[0] = 1

K = -R[1]/R[0]

A[1] = K

Alpha = R[0]* (1-K^2) (1)

For i = 2 To M

S=∑i−1

j=1(R[j]*A[i-j]) + R[i] (2)

51


K = -S/Alpha

An[j] =∑i−1

j=1A[j] + K*A[i-j] /*Onde An[i] são os novos coe�cientes*/ (3)

An[i] = K

Alpha = Alpha * (1-K^2)

End

Após a conclusão do algoritmo obtêm-se os coe�cientes do �ltro que permitem estimar

o ponto que se vai obter. Apesar de ser um método não trivial é possível obter-se uma boa

noção de todo o processo envolvido neste cálculo. Contudo, e para se proceder de uma forma

mais rigorosa é possível melhorar o método utilizado.

Como exemplo consideramos o conjunto de entrada que representa as coordenadas geográ-

�cas (Latitude e Longitude) obtidas anteriormente:

[(38.726904,-9.140234),(38.726907,-9.140228),(38.726908,-9.140222),(38.726909,-9.140216),

(38.726912,-9.140209),(38.726913,-9.140191),(38.726912,-9.140181),(38.726914,-9.140175),

(38.726917,-9.140165),(38.726926,-9.140156),(38.726927,-9.140149),(38.72693,-9.140144),

(38.726935,-9.140133),(38.726936,-9.140125),(38.726934,-9.140117),(38.726931,-9.14011),

(38.726928,-9.1401),(38.726927,-9.14009),(38.726931,-9.140077),(38.726928,-9.140058),

(38.726919,-9.140043),(38.726913,-9.140023),(38.726902,-9.14002),(38.726893,-9.140023),

(38.726887,-9.140028)]

Obteve-se os coe�cientes:

[0, -1.999998796517388, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -0.12455971971021439,

0.062279897331493951]

LPC da previsão do novo ponto de Longitude: -9.14000700014

Erro de: -2.79998587551e-05

Obteve-se os coe�cientes:

[0, -2.0000002323966473, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -0.12402389607037402,

0.06201194082950344]

LPC do novo ponto de Latitude: 38.726908

52


Erro de: -2.70000000882e-05

Contudo, ao expor esses dados na �gura 3.13, observa-se alguma fragilidade no algoritmo

LPC visto que o ponto previsto se afasta da realidade. O símbolo amarelo representa a

posição real (-9.140035,38.726881) enquanto que o símbolo a vermelho representa a posição

prevista pelo algoritmo em uso (-9.14000700014,38.726908). Isto acontece devido ao algoritmo

de Levinson-Durbin não estar adaptado ao modelo aqui de movimento aqui exposto. Terá de

se optar por outro tipo de �ltros como por exemplo o �ltro de Kalman.

Figura 3.13: Exemplo de Previsão linear LPC

53


54

Capítulo 4

Resultados Experimentais e Validação

4.1 De�nição do Objeto de Avaliação

Como se trata de uma aplicação ainda em desenvolvimento, vai-se tentar saber, tal como deve

ser feito em qualquer projeto, se o desenvolvimento da aplicação está a ser levado segundo

as linhas de orientação de�nidas aquando a de�nição do problema. Desse modo, pretende-se

então, mediante o método de avaliação exposto na secção seguinte, saber a ferramenta que

está a ser desenvolvida, no âmbito da obtenção de informação, é e�caz.

Ao analisar a missão base de um homem em funções de reconhecimento e progressão no

campo de batalha observa-se que o objetivo principal é a recolha de dados que permita desen-

volver, após o seu tratamento, o processo de tomada de decisão de um modo mais correto e

metodológico. Existem um conjunto de formulários base para escrita de relatórios de forneci-

mento de dados. Esses relatórios são escritos e transmitidos via rádio para o escalão superior1.

Desses formulários podem destacar-se a mnemónica TUTELA e RelIm:

TUTELA - Relatório de noticia sobre presença de IN - Inimigo no teatro de operações

• T - Tamanho da unidade que se observa;

• U - Unidade que se observa;

• T - Instante em que ocorre a observação;

• E - Equipamento usado pela força observada;

• L - A localização da força observada;

1Entidade que comanda a atividade da força no teatro de operações

55

Método de Avaliação

• A - Atividade que a força observada desenvolve.

RelIm - Relatório Imediato sobre o IN.

• Localização;

• No de elementos;

• Armamento e equipamento;

• Atividade que desenvolve;

• Proposta de modalidade de ação para atacar;

• Outras informações importantes.

Desse relatórios é desencadeado o processo de decisão que tem como fatores de in�uencia

os que são designados pela mnemónica MITM TC. Esses fatores de in�uência são retirados

dos relatórios anteriores.

• Missão;

• Inimigo;

• Terreno;

• Meios;

• Tempo;

• Considerações de natureza civil.

Vai-se então avaliar se a aplicação RovimViewer permite construir um desses relatórios

em tempo útil e sem custos humanos para se obter uma tomada de decisão mais segura.

Uma vez que o ROVIM que a aplicação monitoriza e controla é independente desta, não

será contabilizado o tempo que o dispositivo mecânico demora a chegar ao objeto. Essa

situação apenas iria re�etir a inadaptação do hardware2 à missão militar proposta. Contudo,

é necessário veri�car se a aplicação se apresenta acessível na manipulação para os utilizadores.

4.2 Método de Avaliação

Em contacto com o�ciais militares superiores obteve-se a perceção da importância da recolha

de dados e informação para a tomada de decisão. Esta recolha de dados é o processo que mais

empenhamento deve possuir, uma vez que é o que mais contribui para a tomada de decisão.

Contudo, este processo tem também um elevado risco associado.

2Entenda-se aqui por hardware o dispositivo mecânico que pode ser controlado remotamente pela aplicação.

56

Exemplo de escrita dos relatórios RelIm e TUTELA

Assim como no mundo civil, no meio militar quanto maior o risco, maior poderá ser a

vantagem obtida sobre a oposição. Obtida a aplicação aqui desenvolvida, vai-se tentar perceber

se a mesma consegue obter a mesma quantidade de informação reduzindo o risco. Vai-se

veri�car se é possível usar dispositivos robotizados que reduzam o risco e consequentemente

a perda de vidas humanas. Nesse sentido avalia-se a aplicação RovimViewer usando um

protótipo do ROVIM, o Surveyor Srv-1. Uma das avaliações consiste na recolha de uma

imagem a partir do ROVIM e veri�car se é possível obter os relatórios RelIm e TUTELA por

intermédio desta. Ao se obter esses relatórios �ca disponível de imediato a possibilidade de se

entrar no processo de tomada de decisão. Esses relatórios serão apenas ilustrativos.

O sistema desenvolvido não será usado para diminuir o efetivo necessário para o cumpri-

mento da missão. Este sistema apenas irá fornecer uma ferramenta adicional que permita

executar uma missão com um desempenho melhor, reduzindo os tempos de aquisição de infor-

mação, assim como, tomar decisões antecipadas.

Um dos métodos de avaliação consiste em obter uma imagem da Parada3 militar da

Academia Militar - Sede, sobre a qual se vai desenvolver um dos relatórios descritos anteri-

ormente. A aplicação dará a localização global e a imagem descritiva do terreno. Cabe ao

operador escrever os relatórios. Neste exemplo apenas se vai ter em consideração o relatório

TUTELA, uma vez que o RelIm do ponto de vista conceptual de apresentação é semelhante.

O segundo método de avaliação é tentar perceber se a aplicação tem uma interface su�-

cientemente simples para que um novo utilizador se consiga adaptar facilmente à aplicação. A

título de perceção das condicionantes do RovimViewer, será também feito um estudo entre a

qualidade de imagem e o ritmo de transferência.

4.3 Exemplo de escrita dos relatórios RelIm e TUTELA

Como referido anteriormente, vai-se proceder à escrita de relatórios de divulgação do cenário

observado no terreno recorrendo ao uso do sistema ROVIM. Vai ser então apresentada uma

imagem sobre a qual se vai focar o relatório. Este relatório é apenas descritivo e exempli�cativo

não existindo portanto qualquer tipo de realismo na imagem obtida, ainda que esta seja obtida

por intermédio do ROVIM.

3Local onde decorrem cerimónias militares.

57

Aferição de Tempos de Adaptação

Os relatórios de observação são feitos no durante a execução de uma patrulha. Esses

relatórios incluem na maioria das vezes um esboço. Esse esboço permite que haja maior rigor

na informação a transmitir constituindo um registo precioso. Vai-se então tentar perceber

se a aplicação desenvolvida permite desenvolver um relatório de forma remota (sem existir

efetivamente um militar no terreno) capaz de disponibilizar um esboço como é descrito no

manual de patrulhas da EPI - Escola Prática de Infantaria4. Um exemplo deste tipo de esboço

de observação pode ser visível na Figura 4.1. Nessa �gura é possível veri�car que possui a

identi�cação da unidade que construiu esse relatório (canto superior esquerdo), assim como

a identi�cação do autor (canto superior direito).Está também disponível o relatório segundo

a mnemónica TUTELA assim como um esboço ilustrativo do terreno. Ora, se a força que

originou este relatório tivesse a aplicação RovimViewer disponível, esse relatório poderia ter

o aspeto da Figura 4.2, onde em vez de estar presente um desenho manual pode estar uma

fotogra�a.

Observa-se então que a imagem disponibilizada pelo ROVIM contribui para o processo

de tomada de decisão. Seguindo a metodologia de desenvolvimento do RovimViewer descrita

na Figura 3.2 (Processo Iterativo de desenvolvimento da aplicação RovimViewer) é possível

acrescentar mais funcionalidade neste âmbito permitindo que o operador construa este relatório

diretamente na aplicação. Com esse intuito é conveniente que o relatório esteja pré-preenchido

quando se utilizar essa funcionalidade. Deverão estar disponíveis de modo automático as

informações relativas à localização, à unidade que explora o terreno, à identi�cação do operador

assim como a imagem capturada pelo ROVIM.

4.4 Aferição de Tempos de Adaptação

Considerando que a aplicação RovimViewer se destina à manipulação, por parte de diferentes

indivíduos, em ambientes de tensão e stress elevados, esta tem de ser simples, fácil de operar e

com uma adaptação, ao controlo do ROVIM, acessível e rápida. Com este intuito, observa-se

a necessidade de comprovar essa característica colocando o ambiente de comando e controlo

do RovimViewer exposto a elementos que desconhecem a aplicação. Nesse âmbito foi pedido

a um conjunto de militares escolhidos ocasionalmente para enfrentar o desa�o de percorrer

um determinado percurso. Este percurso inclui não só um trajeto pré-de�nido, assim como

4Escola de formação de militares da arma de infantaria

58


Figura 4.1: Esboço de descrição de um objetivo

a utilização de dois ROVIMs distintos durante a execução da missão. Ao longo do percurso

é solicitado ao operador que enfrente diversos obstáculos, entre eles uma série de curvas,

a descrição de um �8�, a leitura de um endereço IP e de um porto, de acesso ao segundo

ROVIM, inscrito numa folha. Ao introduzir esse endereço na aplicação é controlado o segundo

ROVIM até este se encontrar dentro de um quadrado pré-delimitado (Fim percurso). Volta-

se a controlar o primeiro ROVIM conduzindo este até ao encontro do anterior no mesmo

quadrado. Uma ilustração do percurso pode ser visualizado na Figura 4.3. Para todos os testes

59


Figura 4.2: Imagem Obtida pelo ROVIM

as indicações foram iguais de modo a manter a coerência dos dados obtidos. Foi indicado como

controlar o ROVIM com o auxilio do joystick, como introduzir os valores do endereço IP do

ROVIM e como se deveria proceder em relação à abordagem de cada obstáculo. Em todos os

casos foi dado auxilio verbal durante a primeira tentativa de modo a efetuar transferência de

conhecimento por prática da tarefa e de instrução verbal.

Com este percurso pretende-se veri�car se existe uma melhoria signi�cativa nos tempos

de adaptação. Nesse intuito chegou-se à conclusão que esses tempos melhoraram signi�ca-

60


Figura 4.3: Ilustração do percurso de teste a novos indivíduos

tivamente apenas em três tentativas. A cada uma das tentativas foi atribuída a seguinte

designação:

• 1a Tentativa - Familiarização com a aplicação - try1;

• 2a Tentativa - Adaptação à dinâmica do controlo - try2;

• 3a Tentativa - Observação de Controlo e adaptação consolidada sem prática- try3.

Como os próprios nomes indicam, esperou-se, após o desenvolvimento da aplicação focado

na ideia da simplicidade que após três contactos com a aplicação se conseguisse controlar

em pleno o ROVIM. São apresentados os resultados obtidos na tabela 4.1 onde as colunas

representam os pilotos de teste - PT e as linhas as fases de adaptação. A tabela é preenchida

com os tempos em minutos' segundos� centésimos de cada elemento.

Observa-se na tabela um decaimento considerável dos tempos de adaptação à aplicação.

Em média, o tempo despendido foi reduzido a perto de metade da primeira tentativa para a

última. Na maioria dos casos existiu a queixa de atrasos na imagem, o que motivou o desen-

volvimento desenvolvimento da secção seguinte. Contudo, um utilizador com algumas horas

de experiência consegue efetuar todo o percurso num tempo inferior a 1'50�00. A aplicação

61


PT1 PT2 PT3 PT4 PT5 PT6 PT7 Média

try1 3'22�82 3'49�82 4'30�95 3'41�28 4'52�83 3'52�98 4'30�09 04'05�82

try2 3'07�29 2'22�65 2'55�87 2'26�15 2'26�66 2'50�71 2'40�94 2'41�47

try3 2'21�47 2'06�15 2'46�37 2'00�53 2'15�78 2'25�85 2'08�37 2'17�79

Tabela 4.1: Adaptação à aplicação RovimViewer

RovimViewer assentou em cima de um protocolo de comunicação limitado em termos de RT.

O TCP/IP não serve para produzir sistemas de RT devido à existência de colisões de pacotes

que ocorrem de forma aleatória. Não se consegue determinar, por esse motivo, um tempo

máximo para o qual se tem a certeza de que o pacote enviado chegou ao destino. Esta situ-

ação observa-se nitidamente em casos de sobrecarga da rede. Surge então, nessa altura, uma

di�culdade acrescida no controlo do ROVIM.

62

Qualidade de Imagem e Ritmo de Transferência

4.5 Qualidade de Imagem e Ritmo de Transferência

O surveyor SRV-1 possui resoluções de 160x128, de 320X240, 640X480 e 1280x1024 pixels. Para

cada resolução existem 8 níveis de qualidade. Com o intuito de perceber a disponibilidade da

largura de banda é feita uma experiência de obtenção de Fps - Frames por segundo, consoante

uma variação do nível de qualidade. Esse teste consiste em partir da resolução mais baixa até

à resolução mais alta. Dentro de cada resolução é observado o nível de qualidade mais alto e

mais baixo extraindo desse modo os valores de Fps.

É apresentada na tabela 4.2 a taxa de ritmo de transferência em Fps consoante as diferentes

resoluções e qualidades. A tabela está organizada da esquerda para a direita por ordem

crescente de resolução. Para cada uma das resoluções primeiro aparece sempre a qualidade

mais baixa Q8 seguida da qualidade mais alta Q1. É notório o decréscimo de Fps. Iniciando

a observação da tabela da esquerda para a direita na linha que contém a média das leituras

efetuadas, observa-se que a passagem para a coluna seguinte representa um decaimento para

metade do valor anterior. Encontra-se assim uma relação entre o ritmo de transferência e

a resolução de imagem. Contudo, esta observação não é independente do processador de

imagem utilizado. as leituras de Fps variam bastante caso se minimize a janela de visualização

da câmara do ROVIM. Para uma melhor perceção dessa relação deverá ser efetuado um teste

em diferentes máquinas. Essa análise já sai fora do âmbito desta dissertação.

63

Qualidade de Imagem e Ritmo de Transferência

160X120

Q8

160X120

Q1

320X240

Q8

320X240

Q1

640X480

Q8

640X480

Q1

1280X1024

Q8

1280X1024

Q1

21,26 10,16 7,63 3,49 1,67 1,02 0,70 0,42

18,97 8,47 5,72 2,92 1,98 0,91 0,70 0,34

20,89 9,55 7,82 3,28 1,95 0,93 0,48 0,32

18,85 9,66 7,96 3,38 1,91 0,92 0,62 0,31

21,48 9,68 3,88 3,48 1,98 0,66 0,49 0,37

18,68 9,63 4,88 3,40 1,64 0,96 0,69 0,34

24,55 10,02 4,89 2,15 1,63 0,90 0,61 0,32

19,00 8,94 7,94 3,37 1,95 0,97 0,70 0,27

20,37 8,32 5,51 2,65 1,63 0,66 0,59 0,30

18,80 9,72 4,87 3,48 1,84 0,96 0,59 0,29

21,10 9,70 7,66 3,42 1,72 0,65 0,48 0,26

17,94 10,16 4,87 3,42 1,62 0,97 0,66 0,30

Média 20,16 9,50 6,14 3,20 1,79 0,87 0,61 0,32

Tabela 4.2: Ritmo de transferência em Fps consoante a qualidade de imagem

64

Resultados

4.6 Resultados

Após uma análise conclusiva sobre os dados obtidos, veri�ca-se que é possível incrementar o

desempenho de uma força recorrendo a esta aplicação. Pode-se observar ainda que a grande

limitação desta aplicação é o uso de um sistema sem recurso a técnicas de RT com metas

temporais apertadas que possibilitem uma qualidade de imagem versus ritmo de transferência

adequadas às necessidades de visualização e monitorização do ROVIM. É necessário ter em

conta o próprio desempenho do processador a�m de se conseguir cumprir essas mesmas metas

temporais uma vez que quanto maior a imagem pretendida mais recurso de processador é

usado. Daqui também resulta uma limitação em termos de hardware.

Em relação à capacidade de adaptação por parte de novos membros, é possível comprovar

a facilidade de maneio do ROVIM considerando a redução de tempo observada nas medições

de tempos de adaptação. Esta avaliação não se pode dissociar da facilidade de aprendizagem

individual de cada elemento. Contudo, em diversos casos e já fora do âmbito de teste, os

indivíduos que tiveram oportunidade de treinar mais um pouco conseguiram efetuar o percurso

proposto em menos de dois minutos. Contudo, essa não pode ser considerada uma barreira a

ser ultrapassada por todos os indivíduos uma vez que existem capacidades psicomotoras únicas

que são intrínsecas à natureza pessoal.

Em relação à construção dos relatórios propriamente militares, é possível veri�car que

mediante a de�nição de imagem disponível se torna fácil observar e identi�car militares, tanto

apeados como em viaturas, assim como o equipamento que transportam.

65

Resultados

66

Capítulo 5

Perspetivas de Trabalho Futuro e

Conclusão

5.1 Perspetivas de Trabalho Futuro

Ao se con�rmar a utilidade desta aplicação, na recolha de informação e de dados que se

introduzem no processo de tomada de decisão, pode-se pensar em desenvolver tecnologias

que permitam melhorar a QOS - Qualidade de Serviço do sistema. Como por exemplo o

desenvolvimento de antenas e de sistemas de transmissão que permitam adaptar a tecnologia

sem-�os a um sistema RT com metas temporais reduzidas. Surge então a necessidade de criar

e desenvolver um sistema de rede em RT.

Contudo, devido à utilização do protocolo TCP/IP, que se apresenta como incompatível

com os sistemas de Tempo Real, é sugerida a alteração de protocolo da aplicação. É tam-

bém, ainda do ponto de vista das redes, necessário desenvolver as alterações necessárias à

especi�cação da aplicação de modo a que esta se possa interligar de forma perfeita com o

SIC-T.

Dado o âmbito militar da aplicação, é necessário �estender� o sistema para um sistema

distribuído. Só assim se consegue garantir um funcionamento permanente do sistema em caso

de falhas inopinadas ou de �agelo de algum equipamento por parte da força opositora. Seria

também interessante e crucial continuar a investigação de implementação multi-plataforma.

Em relação ao atraso encontrado na imagem, deve ser disponibilizada uma câmara com

ligação através de rádio de modo a minimizar os atrasos de imagem provenientes de uma

67

Conclusão

ligação digital. Neste âmbito é então solicitado o estudo de adaptação e integração de sinais

analógicos e/ou digitais numa mesma rede ou aplicação.

5.2 Conclusão

Após a de�nição dos objetivos iniciais, que de forma resumida consistiam em:

• Criar uma aplicação de monitorização e controlo do Rovim com baixo custo associado,

• Fornecer um conjunto de requisitos essenciais à prática da tomada de decisão militar,

• Demonstração da aplicabilidade de se utilizar em missões de reconhecimento e vigilância,

Pode-se observar que é possível implementar essa aplicação recorrendo a open-source, num

tempo razoável. Para esse efeito deverá ser constituído um grupo de trabalho que permita

recolher, agrupar e articular as diversas componentes da aplicação de modo a atingir um

produto estável e apropriado a esse tipo de missão. A aplicação desenvolvida não tem o

intuito de ser utilizada como produto �nal mas sim extrair a perceção sobre a possibilidade e

viabilidade de construir um sistema deste tipo de raiz.

Ao se partir do princípio que se consegue construir um sistema distribuído que garanta

coerência no �uxo de instruções, após a implementação deste protótipo é possível veri�car,

mediante os testes realizados durante a fase �nal de desenvolvimento, que é possível e viável

construir este tipo de aplicação de raiz. É para esse efeito necessário e imprescindível a criação

de um grupo de trabalho que possibilite coerência de ideias e orientações especí�cas para a

realização do projeto.

Como foi dito anteriormente, uma versão de protótipo nunca dever ser utilizada para se

partir de base para o projeto. Então, é aconselhado o uso de uma linguagem de programação

diferente[11]. É fácil observar que esta aplicação tem bastantes problemas de implementação

derivados do tempo disponível para a realização da mesma.

68

Bibliogra�a

[1] Developer guide sdk 1.6. https://projects.ardrone.org/attachments/download/335/

ARDrone_SDK_1_6_Developer_Guide.pdf, Acesso em 1 Outubro de 2011.

[2] Projeto raposa ao serviço dos sapadores. http://raposa.idmind.pt/?qual=objectivos,

Acesso em 1 Setembro de 2011.

[3] Equipamento "spirit"presente em marte. http://comoze2.blogspot.com/2010/06/

spirit-mars-rover-2003-peso-180-kg-comp.html, Acesso em 12 Setembro de 2011.

[4] Especi�cações do robô ao serviço dos eua - Talon. http://roboinfo.wordpress.com/

2010/04/09/talon-specifications/, Acesso em 13 Setembro de 2011.

[5] Robô autónomo alimentado por matéria orgânica. http://aeiou.exameinformatica.

pt/robo-militar-que-se-alimenta-de-cadaveres=f1002932, Acesso em 13 Setembro

de 2011.

[6] Ugv talon a rebocar homem. https://wiki.nps.edu/display/CRUSER/UGV, Acesso em

23 Setembro de 2011.

[7] Talon ao serviço dos estados unidos da américa. http://bemil.chosun.com/nbrd/

gallery/view.html?b_bbs_id=10044&pn=0&num=41387, Acesso em 25 Agosto de 2011.

[8] Jeremy Bradbury. Linear predictive coding, December 5, 2000.

[9] Giorgio C. Butazzo. Hard Real-Time Computer Systems: Predictable Scheduling Algo-

rithms and Applications. Springer, Italy, second edition, 2005.

[10] Fábio Manuel Quinas da Cruz. Os veículos terrestre não tripulados nas unidades de

reconhecimento. Master's thesis, AM - Academia Militar, Setembro 2011.

69

Conclusão

[11] Kenneth C. Laudon and Jane P. Laudon. Management Information Systems: Managing

the Digital Firm. Prentice Hall, 11th edition, 2010.

[12] Jane W. S. Liu. Real-Time Systems. Prentice Hall, 2000.

[13] Paulo Pedreiras. Estados de uma tarefa, Accessed October 14, 2011.

[14] António José Caessa Alves do Sacramento. Enquadramento da segurança das co-

municações. http://www.revistamilitar.pt/modules/articles/article.php?id=60,

Acesso em 31 Julho de 2011.

[15] Eduardo Alexandre Pereira da Silva. Controlo de veículos autónomos. PhD thesis, FEUP

- Faculdade de Engenharia do Porto, 2002.

[16] Jorge Manuel Estrela da Silva. Software para controlo e gestão de missões de veículos

autónomos. Master's thesis, FEUP - Faculdade de Engenharia do Porto, 2001.

[17] Teixeira. Aplicação da rede mesh desenvolvida pelo darpa. http://sites.google.com/

site/redemesh/, Acesso em 15 Agosto de 2011.

[18] Sun Tzu. The Art of War. Coisas de Ler, Almargem do Bispo, 2007.

70

Apêndice A

De�nição de Segurança

"A palavra �segurança� é empregue na língua portuguesa com múltiplos sentidos, pelo que

a consideramos uma palavra delicada. Parece-nos assim adequado começar por apresentar

uma breve introdução ao conceito de segurança sobre que nos propomos efectuar algumas

considerações, ao longo deste artigo.

A palavra �segurança� é empregue, por exemplo, quando analisamos a capacidade de

resistência à intrusão de um determinado edifício, por hipotéticos assaltantes. Diremos então

que tal edifício será mais ou menos seguro, consoante o maior ou menor grau de resistência

avaliada. Também empregamos o termo �segurança�, ao analisarmos algumas características

observadas na estrada de acesso a esse mesmo edifício e nos referimos, por exemplo, à ausência

de sinalização especí�ca que alerte da existência de curvas apertadas com bermas abruptas e

não protegidas por rails. Estas �seguranças� são obviamente distintas.

No primeiro caso, exemplo da intrusão, estaremos a analisar a forma de impedir uma acção

directa, uma intenção de um ou vários indivíduos terem acesso intencional a esse edifício e ao

que de valor (humano, material ou de informação) nele possa ser obtido. No segundo caso,

estaremos a falar de acções indirectas, sem intervenção intencional humana. No primeiro caso

estamos a falar da segurança a que corresponde na língua inglesa o vocábulo security e, no

segundo, ao vocábulo safety. A complementaridade dos dois conceitos pode ser exempli�cado

pela expressão seguinte:

(Segurança) Português = (Safety + Security) Inglês

Safety pode traduzir-se por um conjunto de meios humanos, técnicos e de procedimentos

que visam evitar acidentes/incidentes não originados pela acção humana intencional. Security

71

De�nição de Segurança

será o conjunto de meios humanos, técnicos e de procedimentos que visam evitar acidentes/in-

cidentes provocados intencionalmente pela acção humana.

A segurança militar enquadra-se tipicamente no conceito de security, mas não em exclu-

sivo. Nos tempos mais recentes ela tem vindo a englobar algumas áreas conceptualmente

enquadradas na safety, como se observa, por exemplo, quando as unidades militares elaboram

planos de prevenção contra catástrofes naturais, ou naturalmente cumprem com as normas de

prevenção de acidentes e segurança no trabalho nos diversos órgãos das suas instituições em

que esta obrigatoriedade se enquadra.

A segurança militar é fundamentada em doutrina e gerida por normas e procedimentos

e ao seu não cumprimento estão sempre associadas sanções que poderão vir a ser do foro

disciplinar ou criminal. Tanto a quem cria as normas reguladoras da segurança como a quem

observa o seu cumprimento (inspectores), são muitas vezes encarados como entidades que

exercem �poder�, o que, em nossa opinião, constitui um conceito errado. A segurança em

si, não é poder. A segurança associada a um sistema de informação e comunicações (SIC)1

militares, que apoia o comando, controlo, comunicações, informações e redes de computadores,

conferindo-lhe con�dencialidade, integridade, disponibilidade e não repúdio da comunicação,

veicula a decisão e a capacidade de comando de quem efectivamente exerce o poder."[14]

1Na terminologia inglesa designa-se CIS (Communications and Information Systems)

72

Apêndice B

Orgânica Militar

Uma força militar em termos genéricos é constituída hierarquicamente por esquadra, secção,

pelotão, companhia, batalhão, regimento e brigada. Todas estas designações são unidades

militares e são aquelas que constituem a hierarquia militar em Portugal. Existem ainda orgãos

de direção e che�a que se designam por Estado Maior presentes a partir da unidade brigada.

Em termos de efetivo pode-se considerar o seguinte:

• Esquadra - 5 homens

• Secção - 2 esquadras + Comandante de secção (furriel ou 2o sargento) - 11 homens

• Pelotão 3 secções + Comandante de pelotão (Alferes ou Tenente) + Adjunto de pelotão

(1o Sargento) + Socorrista + RTL - Homem equipado com sistema de telecomunicações

+ 2 esquadras ML-Metralhadora Ligeira (apontador, municiador e remuniciador) + OAV

- Observador Avançado. + Anti-carro - 45 homens - Este valor pode variar entre os 35

e os 50 homens consoante a necessidade.

• Batalhão - Composto por mais de duas companhias com efetivo - 1000 homens - po-

dendo este valor variar signi�cativamente e tem como comandante 1 Coronel ou Tenente-

Coronel.

• Brigada/Regimento - Vários Batalhões - 5000 homens número este este que também

pode sofrer alterações e possui na sua orgânica de comando um General comandante de

duas ou três estrelas mais o seu estado maior, composto por especialistas das diferentes

73

Orgânica Militar

armas ou serviços1 que constituem a Brigada. Estes disponibilizam o seu parecer técnico,

como o�ciais, em cada situação.

Para se visualizar os postos existentes no Exército podem se observar a classe de Praças

na �gura B.1, a clase de Sargentos na �gura B.2 e a classe de O�ciais na �gura B.3

Figura B.1: Classe de Praças Figura B.2: Classe de Sargentos

Figura B.3: Classe de O�ciais

1Entende-se por arma ou serviço uma unidade militar que possui um conjunto de características especí�cas

para desenvolver determinada missão. Como Armas exitem: Infantaria, Artilharia, Cavalaria, Engenharia

Militar e as Transmissões. Nos serviços observam-se: Administração Militar, Serviço de Saúde e o Serviço de

Material

74

rovim - robô de vigilância de instalações militares ... · na fase nal do projeto são...

Documents