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
ii
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 pelos contactos fornecidos; Tenente-Coronel de Infantaria José Carlos Dias Rouco pelo parecer
militar em relação à aplicação desenvolvida e aos aspetos da denição do problema e levantamento de requisitos; Tenente-Coronel José António Travanca Lopes e ao IGeoE - Instituto
Geográco do Exército - a disponibilização dos
shapeles 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: Augusto Nelson, Laurinda Susana; e aos irmãos: Fernando Manuel, Filipe Alexandre, Cláudia
Isabel; que independentemente dos momentos vividos sempre me apoiaram. Aos amigos: Catarina, 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
iv
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
a linguagem
python
em ambiente
e o ambiente de desenvolvimento gráco
Debian - Linux.
open-source.
QTdesigner,
É então usada
tudo desenvolvido
A aplicação constitui-se por cinco módulos:
Observação e
monitorização; Conguraçã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 codicaçã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 reetiu 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 conrmar a capacidade de desenvolver uma aplicação de baixo custo e
sucientemente 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
vi
Abstract
This paper presents an application to control unmanned ground surveillance robots, named
"RovimViewer". We have undertaken a study concerning both physical and security characteristics, as well as the information required by ground forces. The application is composed of
ve modules: observation and monitoring, conguration 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.
application based on
Keywords:
open-source
We show that it is possible to develop an
software, that is both low-cost and robust.
Unmanned vehicles, Unmanned vehicles application control, Open Source,
LPC Coding
vii
viii
Índice
Resumo
v
Abstract
vii
Lista de Figuras
xi
Lista de Tabelas
xiii
Lista de Acrónimos
xv
1 Introdução
1
1.1
Deniçã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
funcionalidade
RovimViewer
e a sua
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Protocolos, capacidade do
3.4
Limitações do Projeto
3.5
Estimador de Movimento
ROVIM
em uso e adaptação a um novo Protocolo
36
.
44
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Resultados Experimentais e Validação
49
55
4.1
Denição do Objeto de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.2
Método de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.3
Exemplo de escrita dos relatórios
4.4
Aferição de Tempos de Adaptação
RelIm e TUTELA
. . . . . . . . . . . . . . .
57
. . . . . . . . . . . . . . . . . . . . . . . . .
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
Bibliograa
69
Anexos
71
A Denição de Segurança
71
B Orgânica Militar
73
x
Lista de Figuras
1.1
Sistema Global
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Fluxo de dados entre as diferentes camadas da hierarquia militar
1.3
Planagem dos níveis hierárquicos de uma organização [11]
1.4
Estrutura da moto-4 para o
1.5
Rede militar DARPA -
1.6
Aplicação
1.7
Demonstração de força do
ROVIM
2
. . . . . . . .
3
. . . . . . . . . . .
4
. . . . . . . . . . . . . . . . . . . . . . . .
7
Defense Advanced Research Projects Agency [17] .
. . . .
8
. . . . . . . . . . . . . . . . . .
8
Talon dos EUA[6] . . . . . . . . . . . . . . .
11
2.1
Arquitetura funcional do SIC - T . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
UGV ao serviço dos Estados Unidos -
2.3
UGV ao serviço de Portugal-
RovimViewer
com o
Surveyor SRV-1
sistema
Talon [7]
. . . . . . . . . . . . . . . . . .
23
. . . . . . . . . . . . . . . . . . . . . .
24
2.4
Robô autónomo alimentado por matéria orgânica[5] . . . . . . . . . . . . . . . .
25
2.5
UGV presente em Marte-
. . . . . . . . . . . . . . . . . . . . . . . . .
25
3.1
Diagrama de estados de uma tarefa . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2
Processo Iterativo de desenvolvimento da aplicação
3.3
Anação do oset de direção do
3.4
Conguração de teclas para controlo do
3.5
Visualização do meio envolvente ao
3.6
Conguração da qualidade de imagem presente no
Raposa [2] .
Spirit [3]
ROVIM
. . . . . . . .
40
. . . . . . . . . . . . . . . . . . . . . .
41
ROVIM
ROVIM
xi
RovimViewer
. . . . . . . . . . . . . . . . .
41
. . . . . . . . . . . . . . . . . . . .
42
RovimViewer
. . . . . . . .
42
Lista de Figuras
RovimViewer
3.7
Módulo SIG e dinâmico presente no
3.8
Local de introdução e listagem dos endereços de acesso ao
3.9
Diário de Bordo da missão do
3.10 Fluxo de dados da aplicação
ROVIM
. . . . . . . . . . . . . . . .
ROVIM
43
. . . . . . .
43
. . . . . . . . . . . . . . . . . . . . . . .
44
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
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 Ociais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
ROVIM
xii
Lista de Tabelas
2.1
Módulos SIC-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.2
Classicaçã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
. . . . . . . . . . . . . . . . . . . . .
29
3.3
Uso de recursos por parte dos módulos do
3.4
Descrição dos módulos existentes no
4.1
Adaptação à aplicação
4.2
Ritmo de transferência em Fps consoante a qualidade de imagem
Open-Source
RovimViewer
. . . . . . . . . . . . .
36
. . . . . . . . . . . . . . . .
38
. . . . . . . . . . . . . . . . . . . . . . . .
62
RovimViewer
RovimViewer
xiii
. . . . . . . .
64
Lista de Tabelas
xiv
Lista de Acrónimos
ACK - Acknowledge
AP - Access Point
BE - Bulk Encryption
CAN - Controller Area Network
CCB - Centro de Comunicações do Batalhão
CCC - Módulo de CCom de Companhia
DARPA - Defense Advanced Research Projects Agency
EATR - Energetically Autonomous Tactical Robot
EOD - Explosive Ordnance Disposal
EPI - Escola Prática de Infantaria
FHz - Feixes Hertzianos
Fps - Frames por segundo
GPS - Global Position System
LPC - Linear Predictive Coding
LVD - Low Voltage Detected
LVD - Low Voltage Detected
NA - Nó de Acesso
NT - Nó de Trânsito
OO - Oriented Object
PAR - Ponto de Acesso Rádio
RL - Módulo Rear Link
RT - Real Time
SAE - Subsistema de Área Estendida
SAL - Subsistema de Área Local
xv
Lista Acrónimos
SCGS - Subsistema de Controlo e Gestão do Sistema
SHDSL - Symetric High-Speed Subscriber Line
SIG - Sistema de Informação Geográca
SUM - Subsistema de Utilizador Móvel
UDP - User Datagram Protocol
UGV - Unmanned Ground Vehicle
VTLR - Viatura Tática Ligeira de Rodas
WiFi - Wireless Fidelity
xvi
Capítulo 1
Introdução
Segundo o General chinês Sun Tzu, a informação é vista como algo crucial para conseguir
vantagem sobre uma força opositora em determinada situação estratégica.
de informação é visível no empenhamento de espiões[18].
A importância
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 militares
1 num
conito, 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
conito 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 desao. Em consequência disso é sugerido o desenvolvimento 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
sistema 2 proposto é constituído por um robô denominado ROVIM, que possui um vasto
conjunto de especicações e funcionalidades, e de uma consola de monitorização, observação
B.
1
Para melhor perceção dos termos militares utilizados ao longo da dissertação é disponibilizado o Anexo
2
Entenda-se sistema como sendo o conjunto global do projeto desenvolvido.
1
Deniçã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 vericar se o desenvolvimento do projeto se encontra no rumo
pretendido.
Figura 1.1: Sistema Global
2
Denição do Problema
1.1 Denição do Problema
O sistema desenvolvido no âmbito da implementação de um robô de vigilância terrestre militar, 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 disponibilizada informação para a classe hierárquica de comando surgiriam latências
3 desnecessárias e
prejudiciais ao sucesso da missão[11]. Então, facilmente se percebe que a tarefa de informar
4
os comandantes de pequenas unidades, por exemplo escalão pelotão , 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/benecio 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
3
ROVIM
deve ter capacidade de acompanhar a força terrestre inde-
Entende-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.
4
Ver Anexo B da Orgânica Militar
3
Deniçã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,
5
num determinado instante, ser qualquer elemento pertencente a um pelotão , 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 suciente para se poder transportar e manipular
por elementos de uma unidade operacional que se encontrar no terreno. Não se pretende portanto, que esta ferramenta surja como um acréscimo de peso e volume signicativo. Deve-se
poder recorrer ao uso de um PDA ou equivalente.
5
Outro ponto a ter em consideração é a
Unidade militar escalão Companhia constituída por cerca de 40 homens, pertencente a um batalhão (ver
Anexo B).
4
Deniçã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
6
inibindo-a de ser útil do ponto de vista tático-estratégico. Então, a informação In-Time 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 exemplo) 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íncronas
blemas e diculdades do
ROVIM. Estas mensagens são provenientes de situações de conito ou
de problemas oriundos do equipamento móvel
a partir da consola de interface
RovimViewer
ROVIM. Todas as instruções dadas ao ROVIM
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
assíncrona de
warning
A segurança do
7 para comunicação de pro-
ROVIM
envia uma mensagem
que irá requerer especial atenção por parte da equipa que o opera.
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/benecio. 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 conito 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
6
7
Em tempo útil para executar determinada ação
Mensagens às quais não é dada uma resposta de forma automática e que carecem de uma decisão do
operador.
8
Mensagem de Acknowledge de receção e execução do comando
5
Proposta do Sistema Global
corrigir deciê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,
um controlo uido e suave de diversos
ROVIMs
esta deve ser de fácil manuseamento para
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 monitorizaçã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
terá por base a estrutura de uma
moto 4
ROVIM.
Esse
(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
mesh 9 entre outros ROVIMs
ou equipamentos militares, possibilitando uma topologia de rede
dinâmica e não pré-denida. Esta topologia de rede já existe nas forças militares portuguesas
e pode-se nelas integrar, de forma relativamente simples, este
Esta topologia de rede permite uma maior profundidade
sistema
em desenvolvimento.
10 no terreno, assim como, uma maior
robustez face a ataques. Considerando que os alvos prioritários são as redes de comunicações,
9
10
Rede em que cada nó funciona como router
Entenda-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
ware.
hardware 11 denido, é necessário considerar mais umas características do soft-
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
12 , capacidade de armazenamento para registo de dados relativos a
e imagens em tempo útil
missões e um controlo do tipo
implementação da aplicação
joystick
que permita um controlo efetivo do
RovimViewer
está presente a aplicação com uma imagem do
Surveyor SRV-1.
Na Figura 1.6
Surveyor SRV-1, proveniente de um outro robô
igual.
12
Para
foi usado nesta fase, enquanto se aguarda a na-
lização do protótipo em construção, um robô designado por
11
ROVIM.
Entenda-se aqui hardware como o conjunto dos componentes materiais do projeto.
Com resposta uida a novas frames
7
Motivação e Objetivos
Figura 1.5: Rede militar DARPA -
Figura 1.6: Aplicação
Defense Advanced Research Projects Agency [17]
RovimViewer
8
com o
Surveyor SRV-1
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 denitivo, 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 desenvolver 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 especicamente 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 desenvolvimento de produto com ferramentas
não corresponder às expetativas iniciais.
open-source, existe sempre o risco do produto nal
De forma a evitar essa situação, são especicados
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 verica uma existência conituosa 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
•
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
ROVIMs,
e crítica,
•
vericação da possibilidade de construir uma aplicação que responda a este tema recorrendo 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 vericaram-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 equipamento onde corre a aplicação falhar, pode acontecer que se perca denitivamente o
ROVIM
e em consequência mais grave o próprio homem. Deste modo, a proposta aqui apresentada
ROVIM
irá salvaguardar essa situação uma vez que o
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
Denição do Problema.
introdução que se inicia com um preâmbulo de contexEstá presente a denição do problema que carece de uma
O primeiro capítulo corresponde à
tualização e possui mais 5 secções.
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 congurações de redes disponíveis para fornecer um serviço de telecomunicações. É preciso perceber-se que a grande maioria acaba por não servir quando se transita
para o âmbito militar. Isto deve-se à especicidade 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 vericam 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, conjuntas 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/reconstituição, dispersão e mobilidade.
1 e é constituído por quatro
A arquitetura do SIC-T é baseada no TACOMS POST-20001
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 ocial de
2 uma supervisão e controlo dos equipamentos da rede que estão em atividade. É
transmissões
neste subsistema que deverá ser colocada a gestão dos
Rovim's
disponibilizando um local de
conguração destes equipamentos.
1
TACOMS Post 2000 é uma iniciativa de 13 nações na NATO para denir os novos padrões da emergente
rede de telecomunicações táticas.
2
Entidade 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
redundante, pode estar bra ótica ou DSL -
Megabytes.
Em alternativa, ou de forma
Digital Subscriber Line 3 .
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 WD1TT
4 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, independentemente 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
5
referido, obrigou à sua conceção em duas shelters , uma de Transmissão e outra de C2
6 &
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.
4
Designação do par de cobre usado no Exército.
5
Shelter - Cabine de comunicações que se encontra afastada do Posto de Comando
6
Terminologia militar que signica 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)
Módulo de CCom de Batalhão (CCB)
Cmd Controlo & Gestão
1
Transmissão
1
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 classicar 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 sistema associado mantém alguma utilidade para a aplicação, mesmo depois do limite
pré-estabelecido. Verica-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
7 e com escalonamento de tarefas que permita saber o pior caso em termos
real de baixa latência
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.
7
Se os tempos de entrega desses pacotes forem tais que possa
Com tempos de mudança de tarefa e de interrupções reduzidos
18
Veículos não Tripulados
8
implicar alguma perda de dados , se estivermos perante uma situação de transmissão de multimé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
reete 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 velocí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 exemplicar 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 reete 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.
8
Em 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.
minada altura os denominados UxV -
Com esse intuito surgem então em deter-
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
x
acessória à designação real de um U V. 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 especico, as suas missões e as funcionalidades que possuem nos
dias que correrem.
Como o nome sugere, um UGV -
Veículo Terrestre não Tripulado
Unmanned Ground Vehicle,
em português, VTNT -
é 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
3
Pequeno (médio)
0,18 -1,13 (10 )Kg
Pequeno (pesado)
1,13 -9,07 (10 )Kg
Médio
9,07-13,61 (10 )Kg
3
3
3
>13,61 (10 )Kg
Grande
Tabela 2.2: Classicaçã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 classicados segundo a sua massa assim como pelo seu nível de
automação. Uma tabela de classicação por massa pode ser vista na tabela 2.2. Ao nível da
automação, podemos encontrar a classicaçã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 informado 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.
usado a nível mundial, designado por
Talon, pertence aos Estados Unidos.
O sistema mais
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 -
•
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-
Universal Serial Bus
para transferência de dados;
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 deslocaçã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.
Disposal
Exemplo disso são os equipamentos de EOD -
Explosive Ordnance
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 particulares, 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, enando tubos e/ou pequenos
robots em aberturas, para levar ar, transportar água, comida e medicamentos a indiví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, ecaz 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 Opportunity. 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
Figura
matéria orgânica[5]
Spirit [3]
25
2.5:
UGV
presente
em
Marte-
Veículos não Tripulados
26
Capítulo 3
Implementação do Projeto
Antes de proceder à exaustiva explicação da construção da aplicação, vai ser descrita a base e a
linha de pensamento pela qual se manteve sempre alinhado o desenvolvimento desta aplicação.
Como foi referido anteriormente, nos sistemas de automação e remotamente controlados existe
sempre a necessidade de manter metas temporais que permitam instruir o mecanismo a controlar 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 sistema associado mantém alguma utilidade para a aplicação, mesmo depois do limite
pré-estabelecido. Verica-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 sistema 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, nomeadamente 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 im27
Implementação do Projeto
Sistema
Soft
Vantagens
•
Desvantagens
Fácil implementação (apenas tem de
•
temas críticos;
obedecer ao cumprimento de metas
•
temporais);
•
Baixo custo de implementação;
•
O incumprimento da meta tempo-
Não pode ser usado em sis-
Possui
tempos
de
resposta
mais elevados.
ral, apesar de dever ser evitado, não
afeta a estabilidade do sistema.
Hard
•
Tempo de resposta baixo;
•
Implementação complexa;
•
Garantia de segurança dos sistemas
•
Custo elevado devido ao con-
críticos;
•
Vocacionado
junto do hardware necessário
para
os
sistemas
e do tempo dispendido na im-
autónomos.
plementação do sistema;
•
O
incumprimento
temporal
pode
da
meta
provocar
catástrofes.
Firm
•
Pode-se descartar os dados que não
•
se obterem até à meta temporal;
•
Vocacionado para os sistemas de previsão;
•
Ao se falhar a meta temporal,
a computação ca obsoleta;
•
As
falhas
signicam
quebra nos lucros.
Vocacionado para os sistemas de previsão.
Tabela 3.1: Vantagens e Desvantagens dos Sistemas de Tempo Real
28
uma
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 denido, ainda que por um tempo limitado, pois este tipo
de tecnologia é desenvolvida a um ritmo difícil de acompanhar.
a utilização de
Open Source.
Neste projeto foi imposta
A opção tomada tem vantagens e desvantagens como se pode
observar na Tabela 3.2
Vantagens
•
•
Desvantagens
Acesso a ferramentas gratuitas de
•
Suporte à aplicação reduzido;
desenvolvimento;
•
Não se tem garantia de qual-
Possibilidade de se obter uma apli-
•
cação de baixo custo;
•
Possibilidade
de
idade;
aceder
e
alterar
código já existente.
A falta de suporte pode originar tempo de trabalho excessivo 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 operador (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, é instalar 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 funcionalidade implementar um LVD -
Low Voltage Detected
29
que permite mediante um sensor
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
mecânico até à consola de interface
do ponto de vista da aplicação
sistema, desde o mais simples sistema
RovimViewer, ser relativa a um robô de vigilância terrestre,
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
exemplo o caso de LVD;
30
ROVIM
como por
Levantamento de Requisitos do Sistema
ROVIM ;
•
Especicação da rota ou destino a seguir autonomamente por parte do
•
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
blema.
ROVIM,
as especicações estão referidas na secção Denição do Pro-
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 am 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
percurso a cargo do processamento interno do
percorrer, cando depois a execução do
ROVIM ;
Por m, do ponto de vista dos requisitos da aplicação
robótico
ROVIM,
RovimViewer
e do dispositivo
tendo em consideração o destino militar a que se propõem, observação
e vigilância do teatro de operações, conituoso 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 signicado 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
•
Deve estar disponível na aplicação um local para escrita de relatórios que tenham a
31
ROVIMs ;
Levantamento de Requisitos do Sistema
possibilidade de ser difundidos pela rede;
•
Controlo e comando do
•
Capacidade de fornecer
ROVIM
de forma uida e suave;
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 articiais;
•
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;
ROVIMs ;
•
Capacidade de interação entre os diferentes
•
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 reduzido;
•
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,
intuito de obter uma aplicação que permitisse controlar remotamente o
ROVIM,
com o
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 especicaçõ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;
ROVIMs
•
A aplicação deve controlar múltiplos
•
A consola de interface deve ser intuitiva, fácil de usar e com capacidade de atualização;
•
Especicação da rota ou destino a seguir autonomamente por parte do
•
Algoritmos de previsão de deslocamento;
•
Todo o sistema construido deve disponibilizar uma manutenção fácil e com custo re-
de forma fácil e intuitiva;
ROVIM ;
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 desen33
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 deniçõ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
às necessidades do
desenvolvida neste projeto, é apresentada como uma resposta
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 diferentes 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
raster 1 ou numa imagem vetorial2
3
previamente adquirida ;
ROVIM ;
•
Controlar e monitorizar o
•
Algoritmos de previsão da trajetória.
Verica-se a necessidade de implementar um sistema RT multi-tarefa que permita as funcionalidades 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
eciente, alcançar as funcionalidades propostas. Um sistema RT tem associado uma diversidade 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
1
2
sistema
é fácil observar de imediato
Imagem aérea geo-referênciada que se pode adicionar à aplicação.
Imagem constituida por pontos geo-referênciados que constituem linhas e/ou polígonos que representam
uma área de terreno
3
Disponibilizada 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 hardware. Consegue-se assim um desempenho adequado para o objetivo da aplicação desenvolvida.
Associado a uma
tarefa
está também um estado. Estes estados reetem 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 reete 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
tema
sis-
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
estados a tarefas, consoante as situações observadas no contexto
e a sua funcionalidade
4 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 indenidamente bloqueada.
existentes por intermédio de
Existe a necessidade de gerir os recursos
mutexes e semáforos 5 .
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 vericar 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 simplicada, de modo a perceber efetivamente a necessidade de implementação desta
arquitetura.
Tarefas
GPS
Imagem
Controlo
ROVIM
Rede
Processador
monitor
√
√
√
√
√
√
√
√
√
√
√
Algoritmos de Previsão
Tabela 3.3: Uso de recursos por parte dos módulos do
3.2.2
Desenvolvimento e Explicação dos módulos do
RovimViewer
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
4
5
ROVIMs, da rede (devido
Entende-se por contexto o conjunto de variáveis e alocação de memória de cada tarefa.
Sã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ênciada. Também são expostas as soluções para a diversidade de conguraçõ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;
•
Conguraçã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 implementados. 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 conrmaçã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
Módulo
Funcionalidade
Observação e monitor-
Presente na etiqueta
ização
visualizar o meio envolvente ao
ROVIM
e a sua funcionalidade
da aplicação, tem como objetivo
ROVIM,
assim como monitorizar
o estado dinâmico e físico deste.
Conguração e controlo
Disponibilizada a opção de conguração de teclas de atalho às
funções e comandos disponíveis na aplicação. É também disponibilizada uma
joystick
thread
com uma rotina de captação de sinal de um
para um melhor controlo sobre o
ROVIM.
ROVIM
SIG - Sistema de Infor-
Observação do meio envolvente ao
mação Geográca
informação geográca
Diário de bordo e apre-
Serve o operador com informação relativa à missão, ao percurso
sentação de mensagens
efetuado, à localização de forças hostis, assim como mensagens de
assíncronas
alerta relativas a casos críticos observados pelo sistema sensorial
do
Servidor
de
atribuição
recorrendo ao uso de
vetorial e raster
ROVIM
Tarefa a correr numa máquina independente que distribuí a lista
ROVIM. Este servidor poderá
de protocolo e cálculo de
de comandos aceite por IP de cada
tarefas adicionais
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
Neste módulo está presente o algoritmo matemático de previsão
de dados e informação
de rota consoante os últimos pontos.
relativos
-
mento
ao
posiciona-
Linear Predictive Coding
É usado o algoritmo LPC
recorrendo ao algoritmo de Levinson-
Durbin para cálculo dos coecientes.
Tabela 3.4: Descrição dos módulos existentes no
38
RovimViewer
Desenvolvimento e Explicação dos módulos do
RovimViewer
Ao observar o código visualiza-se a utilização de um
RovimViewer
mutex
por intermédio da instrução locksock.acquire().
e a sua funcionalidade
de controlo de recursos do
É possível ainda vericar a
implementação de um método que permite que a tarefa não que bloqueada no
método está presente na denição de um
linha do código aqui transcrito.
é captada pelo except.
timeout do socket.
Ao ocorrer o sinal de
mutex.
Esse
Essa instrução é visível na primeira
timeout,
é lançada uma exceção que
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
Designer.
QT-
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 aplicaçã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
Designer
rovim.ui
e o
é a consola construida em modo gráco por intermédio da aplicação
rovim_add.py
QT
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 funcionalidade. 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 problemas mecânicos é de salientar as diferenças de
oset
da direção no deslocamento. Surge então
a implementação da barra de anação de direção no
39
RovimViewer.
Esta barra é crítica uma
Desenvolvimento e Explicação dos módulos do
RovimViewer
Figura 3.2: Processo Iterativo de desenvolvimento da aplicação
e a sua funcionalidade
RovimViewer
vez que após ser implementada pode-se congurar 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.
correção de
oset
Contudo, devido à
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 anação do oset, neste caso para a esquerda.
possuir a anação do
Ainda assim, verica-se que é preferível
oset, 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 anação de
oset
nesse
instante.Pode-se observar na Figura 3.3 a representação do anador de direção. Nessa gura
é possível observar também um conjunto de botões para controlar o
pensou-se apenas na colocação de um controlo do tipo
joystick,
ROVIM.
Inicialmente
contudo vericou-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. Vericou-se que surgiu a necessidade de se criar um local de conguração de teclas de atalho para o controlo do
ROVIM. Criou-se então a etiqueta controlos
que
permite congurar as teclas de controlo do equipamento autónomo como se pode observar na
Figura 3.4. Outras conguraçõ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 conguraçã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: Anação do oset de direção do
ROVIM
Figura 3.4: Conguração de teclas para controlo do
Ao se falar do sistema de controlo remoto do
ROVIM
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 imagem 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 conguraçã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.6: Conguração da qualidade de im-
Figura 3.5: Visualização do meio envolvente
ao
ROVIM
agem presente no
RovimViewer
A imagem do ambiente envolvente é extremamente importante para o seu controlo. Contudo, não é suciente 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 informação é disponibilizado um SIG - Sistema de Informação Geográca que permita visualizar
o
ROVIM
atual do
de uma vista aérea, assim como, as coordenada referentes ao posicionamento global
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
biente envolvente do
ROVIM
através de vista aérea.
raster
que permite visualizar o am-
Ainda em relação ao módulo SIG, é
possível efetuar uma gestão das camadas de visualização utilizadas por intermédio da
List
e das ferramentas disponibilizadas no topo da janela do
no terreno representado por uma marca circular vermelha.
observar o estado atual da bateria presente no
RovimViewer.
Layer
O posicionamento
Nessa gura também é possível
ROVIM.
De acordo com o objetivo proposto inicialmente de controlar múltiplos
42
ROVIMs
surge,
Desenvolvimento e Explicação dos módulos do
RovimViewer
Figura 3.7: Módulo SIG e dinâmico presente no
e a sua funcionalidade
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 apresentação do módulo de diário de bordo.
um percurso efetuado pelo
ROVIM,
Pode-se observar na gura 3.9 uma ilustração de
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, é conveniente mostrar a funcionalidade interna assim como todo o uxo de dados existente na apli43
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
3.3 Protocolos, capacidade do
ROVIM
ROVIM.
em uso e adaptação a
um novo Protocolo
Para desenvolvimento da aplicação foi usado um robot adquirido à
Surveyor SRV-1 Blackn.
Este
ROVIM
possui um
rmware
Surveyor
designado por
com um conjunto de operações
predenidas.
Como se pretende uma aplicação que seja independente do protocolo de comunicação e
transparente nesse aspeto para o operador do
acontece com o servidor de nomes DNS os comandos do
Surveyor SRV-1
RovimViewer,
decidiu-se à semelhança do que
Domain Name System, criar um servidor que traduza
para os comandos de cada
ROVIM
especíco. Dessa forma,
apenas o gestor do sistema pode, denir, alterar ou criar comandos de interação com o
ROVIM,
inibindo dessa forma, o acesso a esse tipo de conguraçõ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
45
RovimViewer
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
um
ROVIM
ROVIMs.
Isto possibilita adicionar facilmente
à 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,
Figura 3.11. Este equipamento tem como protocolo de comandos o
AT
presente na
que tem a seguinte
estrutura:
Syntax :
AT*PCMD = %d, %d, %d, %d, %d, %d <LF>
Argumento 1 : Número de sequência
Argument 2 :
modo
ag
que habilita o uso de comandos progressivos e/ou os combinados no
Yaw (biteld )
Argument 3 : esquerda-direita Argument 4 : frente-trás -
oating-point
oating-point
no intervalo [-1..1]
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 para o IP e o
Porto
do
User Datagram Protocol
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, ARDroneAddress, ARDrone.VideoPort);
socketvideo.send(packetsnd);
A partir de agora o
ARDrone
vai envia os pacotes de imagem tal como o
47
Surveyour SRV-
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
imagem na
RovimViewer.
parsing
da string e carregar a
Para mais detalhes recomenda-se a consulta das especicaçõ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.
tempo disponível para desenvolvimento deste protótipo.
Deverá ter-se em conta o curto
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
por cada
wireless
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.
48
Este é um ponto que carece de uma maior
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 proveniente 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 temporá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 exemplo) 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ínimo 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 simplicada, 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 inuê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
X
ak x[n − k] + e[n]
(3.1)
k=1
min E e(n)2
Rxx (k) =
nX
0 +N
(3.2)
xn xn−k
(3.3)
n=n0 +N +k
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(1)

 
 
 
 
r(p − 2)   a(2)   r(2)
 
•
  ..  =  ..
.
.


 
.
  .   .
r(P )
a(P )
r(0)







r(0)
r(1)
· · · r(P − 1)
r(1)
r(2)
···
.
.
.
.
.
.
..
.
r(P − 1) r(P − 2) · · ·




R=



r(0)
r(1)
 
r(2)
···
.
.
.
.
.
.
..
.
r(P − 1) r(P − 2) · · ·


· · · r(P − 1)
r(1)
50
a(1)
(3.4)



r(p − 2) 


.
.

.

r(0)
(3.5)
Estimador de Movimento

a(1)





 a(2) 

A= . 

 .. 


a(P )

r(1)
(3.6)





 r(2) 

P = . 

 .. 


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 coecientes 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, verica-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 computacional para determinar os coecientes do ltro de um modo mais eciente. De seguida é
descrito o algoritmo recursivo
Levinson-Durbin :
Tendo em conta a seguinte notação:
R[i] - Auto-correlação das entradas
A[i] - Coecientes do ltro
K - Coecientes de reexã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=
Pi−1
j=1 (R[j]*A[i-j]) + R[i] (2)
51
Estimador de Movimento
K = -S/Alpha
An[j]
=
Pi−1
j=1 A[j] + K*A[i-j] /*Onde An[i] são os novos coecientes*/ (3)
An[i] = K
Alpha = Alpha * (1-K^2)
End
Após a conclusão do algoritmo obtêm-se os coecientes 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 coecientes:
[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:
Erro de:
-9.14000700014
-2.79998587551e-05
Obteve-se os coecientes:
[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
Estimador de Movimento
54
Capítulo 4
Resultados Experimentais e Validação
4.1 Deniçã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 denidas aquando a deniçã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, é ecaz.
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 desenvolver, 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-
1
mento de dados. Esses relatórios são escritos e transmitidos via rádio para o escalão superior .
Desses formulários podem destacar-se a mnemónica TUTELA e RelIm:
TUTELA - Relatório de noticia sobre presença de IN -
•
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;
1
Inimigo
Entidade que comanda a atividade da força no teatro de operações
55
no teatro de operações
Método de Avaliação
•
A - Atividade que a força observada desenvolve.
RelIm - Relatório Imediato sobre o IN.
•
Localização;
•
N
•
Armamento e equipamento;
•
Atividade que desenvolve;
•
Proposta de modalidade de ação para atacar;
•
Outras informações importantes.
o de elementos;
Desse relatórios é desencadeado o processo de decisão que tem como fatores de inuencia
os que são designados pela mnemónica MITM TC. Esses fatores de inuê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.
situação apenas iria reetir a inadaptação do
hardware2
Essa
à missão militar proposta. Contudo,
é necessário vericar se a aplicação se apresenta acessível na manipulação para os utilizadores.
4.2 Método de Avaliação
Em contacto com ociais 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.
2
Entenda-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
vericar se é possível usar dispositivos robotizados que reduzam o risco e consequentemente
a perda de vidas humanas.
protótipo do
ROVIM,
imagem a partir do
o
Nesse sentido avalia-se a aplicação
Surveyor Srv-1.
ROVIM
RovimViewer
usando um
Uma das avaliações consiste na recolha de uma
e vericar 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 cumprimento 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 informação, assim como, tomar decisões antecipadas.
3 militar da
Um dos métodos de avaliação consiste em obter uma imagem da Parada
Academia Militar - Sede, sobre a qual se vai desenvolver um dos relatórios descritos anteriormente.
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 sucientemente 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 exemplicativo
não existindo portanto qualquer tipo de realismo na imagem obtida, ainda que esta seja obtida
por intermédio do
3
ROVIM.
Local 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
4
manual de patrulhas da EPI - Escola Prática de Infantaria . Um exemplo deste tipo de esboço
de observação pode ser visível na Figura 4.1.
Nessa gura é possível vericar que possui a
identicação da unidade que construiu esse relatório (canto superior esquerdo), assim como
a identicaçã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.
originou este relatório tivesse a aplicação
RovimViewer
Ora, se a força que
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
fotograa.
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
na Figura 3.2 (Processo Iterativo de desenvolvimento da aplicação
RovimViewer
RovimViewer )
descrita
é 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, à identicaçã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 desao de percorrer
um determinado percurso. Este percurso inclui não só um trajeto pré-denido, assim como
4
Escola 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.
ROVIM
Ao introduzir esse endereço na aplicação é controlado o segundo
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
ROVIM
com o auxilio do
joystick,
como introduzir os valores do endereço IP do
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 vericar se existe uma melhoria signicativa nos tempos
de adaptação.
Nesse intuito chegou-se à conclusão que esses tempos melhoraram signica60
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:
a Tentativa - Familiarização com a aplicação - try1;
•
1
•
2
•
3
a Tentativa - Adaptação à dinâmica do controlo - try2;
a 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 desenvolvimento desenvolvimento da secção seguinte. Contudo, um utilizador com algumas horas
de experiência consegue efetuar todo o percurso num tempo inferior a 1'5000. A aplicação
61
Aferição de Tempos de Adaptação
PT1
PT2
PT3
PT4
PT5
PT6
PT7
Média
try1
3'2282
3'4982
4'3095
3'4128
4'5283
3'5298
4'3009
04'0582
try2
3'0729
2'2265
2'5587
2'2615
2'2666
2'5071
2'4094
2'4147
try3
2'2147
2'0615
2'4637
2'0053
2'1578
2'2585
2'0837
2'1779
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 situação observa-se nitidamente em casos de sobrecarga da rede. Surge então, nessa altura, uma
diculdade 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.
a resolução de imagem.
Encontra-se assim uma relação entre o ritmo de transferência e
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
Média
160X120 160X120 320X240 320X240 640X480
640X480
1280X1024
1280X1024
Q8
Q1
Q8
Q1
Q8
Q1
Q8
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
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, verica-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
adequadas às necessidades de visualização e monitorização do
versus
ritmo de transferência
ROVIM.
É necessário ter em
conta o próprio desempenho do processador am 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 vericar que
mediante a denição de imagem disponível se torna fácil observar e identicar militares, tanto
apeados como em viaturas, assim como o equipamento que transportam.
65
Resultados
66
Capítulo 5
Perspetivas de Trabalho Futuro e
Conclusão
5.1 Perspetivas de Trabalho Futuro
Ao se conrmar 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 à
especicaçã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 denição dos objetivos iniciais, que de forma resumida consistiam em:
Rovim
•
Criar uma aplicação de monitorização e controlo do
•
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,
com baixo custo associado,
Pode-se observar que é possível implementar essa aplicação recorrendo a
tempo razoável.
open-source, num
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 vericar,
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
Bibliograa
[1] Developer guide sdk 1.6.
https://projects.ardrone.org/attachments/download/335/
ARDrone_SDK_1_6_Developer_Guide.pdf,
[2] Projeto raposa ao serviço dos sapadores.
Acesso em 1 Outubro de 2011.
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,
[4] Especicações do robô ao serviço dos eua -
2010/04/09/talon-specifications/,
Acesso em 12 Setembro de 2011.
Talon. http://roboinfo.wordpress.com/
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.
the Digital Firm.
[12] Jane W. S. Liu.
Management Information Systems: Managing
Prentice Hall, 11th edition, 2010.
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.
municações.
Enquadramento da segurança das co-
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.
site/redemesh/,
[18] Sun Tzu.
http://sites.google.com/
Acesso em 15 Agosto de 2011.
The Art of War.
Coisas de Ler, Almargem do Bispo, 2007.
70
Apêndice A
Deniçã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 exemplicado
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
Denição de Segurança
será o conjunto de meios humanos, técnicos e de procedimentos que visam evitar acidentes/incidentes provocados intencionalmente pela acção humana.
A segurança militar enquadra-se tipicamente no conceito de security, mas não em exclusivo.
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 condencialidade, 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]
1
Na 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 chea que se designam por Estado Maior presentes a partir da unidade brigada.
Em termos de efetivo pode-se considerar o seguinte:
5 homens
•
Esquadra -
•
Secção - 2 esquadras + Comandante de secção (furriel ou 2
•
Pelotão 3 secções + Comandante de pelotão (Alferes ou Tenente) + Adjunto de pelotão
o sargento) -
11 homens
o Sargento) + Socorrista + RTL - Homem equipado com sistema de telecomunicações
(1
+ 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 signicativamente e tem como comandante 1 Coronel ou TenenteCoronel.
•
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ços
1 que constituem a Brigada. Estes disponibilizam o seu parecer técnico,
como ociais, 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 Ociais na gura B.3
Figura B.1: Classe de Praças
Figura B.2: Classe de Sargentos
Figura B.3: Classe de Ociais
1
Entende-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