Upload
vuthuan
View
214
Download
0
Embed Size (px)
Citation preview
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 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
De�nição do Problema
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
De�nição do Problema
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
De�nição do Problema
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
Motivação e Objetivos
Figura 1.5: Rede militar DARPA - Defense Advanced Research Projects Agency [17]
Figura 1.6: Aplicação RovimViewer com o Surveyor SRV-1
8
Motivação e Objetivos
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
Redes de Comunicações em Teatro de Operações
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
Redes de Comunicações em Teatro de Operações
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
Veículos não Tripulados
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
Veículos não Tripulados
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
Veículos não Tripulados
• 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
Veículos não Tripulados
• 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
Veículos não Tripulados
• 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
Veículos não Tripulados
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
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
Levantamento de Requisitos do Sistema
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
Levantamento de Requisitos do Sistema
• 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
Levantamento de Requisitos do Sistema
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
Desenvolvimento e Explicação dos módulos do RovimViewer e a sua funcionalidade
à 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
Desenvolvimento e Explicação dos módulos do RovimViewer e a sua funcionalidade
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
Desenvolvimento e Explicação dos módulos do RovimViewer e a sua funcionalidade
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
Desenvolvimento e Explicação dos módulos do RovimViewer e a sua funcionalidade
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
Desenvolvimento e Explicação dos módulos do RovimViewer e a sua funcionalidade
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
Desenvolvimento e Explicação dos módulos do RovimViewer e a sua funcionalidade
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
Desenvolvimento e Explicação dos módulos do RovimViewer e a sua funcionalidade
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
Protocolos, capacidade do ROVIM em uso e adaptação a um novo Protocolo
Figura 3.10: Fluxo de dados da aplicação RovimViewer
45
Protocolos, capacidade do ROVIM em uso e adaptação a um novo Protocolo
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
Protocolos, capacidade do ROVIM em uso e adaptação a um novo Protocolo
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
Estimador de Movimento
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
Estimador de Movimento
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
Estimador de Movimento
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
Estimador de Movimento
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
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
Aferição de Tempos de Adaptação
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
Aferição de Tempos de Adaptação
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
Aferição de Tempos de Adaptação
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
Aferição de Tempos de Adaptação
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
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