Video Processing Unit for USV Collision
Avoidance Demonstrator
Ricardo Filipe Cunha Santos
Relatório de Projecto
Mestrado Integrado em Engenharia Informática e Computação
Orientador: Armando Jorge Miranda de Sousa Responsáveis pelo acompanhamento na empresa:
Marco António Manso Ventura Nuno Alexandre Duro dos Santos
demonstrator
Ricardo Filipe Cunha Santos
Relatório de Projecto
Mestrado Integrado em Engenharia Informática e Computação
Aprovado em provas públicas pelo Júri:
Presidente: António Augusto de Sousa (PhD)
____________________________________________________
Arguente: César Analide (PhD)
things do not become more comprehensible,
but more mysterious.”
“À medida que vamos adquirindo mais conhecimentos,
as coisas não se tornam mais compreensíveis,
mas mais misteriosas.”
Resumo
A utilização de máquinas ou sistemas computorizados para desempenhar as funções de humanos tem assumido um papel cada vez mais importante no mundo actual, pois estes sistemas permitem efectuar tarefas desmotivantes, impossíveis ou de elevado risco para humanos.
A Critical Software, S.A. está envolvida num projecto, denominado USVCAD, para apoiar a navegação de uma embarcação não tripulada para detecção de minas. Este trabalho apresenta o sistema de visão para a aplicação em desenvolvimento, que permitirá a quem controla remotamente a embarcação, visualizar em tempo real o mundo exterior onde ela se insere, guardar os vídeos e imagens correspondentes e posteriormente reproduzir essa informação.
É apresentada uma análise dos conceitos, tecnologias e funcionamento dos equipamentos inerentes e sobre os quais o sistema assenta, bem como as decisões tomadas no seu desenvolvimento.
Abstract
The use of machines and computer systems to act as human has taken an increasingly important role in today's world, because these systems can perform uninteresting, impossible or of high risk tasks to humans.
Critical Software, S.A. is involved in a project to support the navigation of an unmanned vessel to detect mines. This paper presents the vision system for the platform under development, which will allow who remotely control the vessel, view in real time the outside world, save the videos and images corresponding and then re-play it.
This document also presented an analysis of concepts, technologies and operation of associated equipment on which the system is based and the decisions taken in their development.
Agradecimentos
Aos meus pais, à Pi, à Ana, ao Martim e a toda a minha família,
que sempre acreditaram nas minhas capacidades.
Aos meus orientadores:
Professor Doutor Armando Jorge Miranda de Sousa, pela confiança e disponibilidade demonstrada.
Engenheiro Marco António Manso Ventura,
pelo empenho na minha integração na empresa, pela ajuda e cooperação.
A todos os colaboradores da Critical Software, S.A., que me ajudaram a ultrapassar as dificuldades encontradas,
com especial atenção para o Nuno Duro, pela confiança, disponibilidade e apoio demonstrado,
aspectos fulcrais no desenvolvimento do projecto.
Aos meus amigos,
pela companhia e motivação nos momentos mais difíceis.
A todos, um Muito Obrigado, o vosso apoio foi imprescindível!!
Índice
1 Introdução... 1
1.1 Enquadramento e apresentação da instituição de estágio... 1
1.2 O projecto na instituição de estágio... 2
1.3 Estudo e desenvolvimento do protótipo no projecto... 3
1.4 Organização e temas abordados neste documento... 3
2 Revisão Bibliográfica... 4
2.1 Tecnologias existentes streaming de vídeo... 4
2.1.1 Java Media Framework... 4
2.1.2 QuickTime for Java... 4
2.1.3 JVLC... 4 2.1.4 FMJ... 5 2.2 Aplicações... 5 2.2.1 ComfyJ... 5 2.2.2 EZJCom... 5 2.3 Dispositivos de captura... 5 2.3.1 Funcionamento... 6 2.3.2 Zoom... 10 2.3.3 Pan e Tilt... 11 2.4 Streaming de vídeo... 11 3 Análise do problema... 12
3.1 Enquadramento do projecto na empresa... 12
3.1.1 Objectivo do projecto... 12
3.1.2 Parcerias... 13
3.2 Requisitos... 13
3.2.1 Representação de um requisito... 13
3.2.2 Análise dos requisitos... 14
3.2.3 Análise da interface... 16
3.3 Plano do projecto... 19
3.3.1 Fase 1... 19
3.3.2 Fase2... 19
3.3.3 Fase3... 19
4 Solução e visualização de sinópticos... 20
4.1 Apresentação da solução... 20
4.1.1 Diagrama de casos de utilização... 22
4.2 Arquitectura do sistema... 22
4.2.1 Hardware... 22
4.2.2 Software... 23
4.2.3 Diagramas de classes... 27
5.1 Introdução... 33
5.2 Fase 1 – Aprendizagem e pesquisa de soluções... 34
5.3 Fase 2 – Streaming e gravação de vídeo... 37
5.3.1 Logitech QuickCam... 38
5.3.2 Bosch Autodome e Axis 2100... 41
5.4 Fase 3 – Controlo Pan, Tilt e Zoom... 42
5.5 Fase 4 – Reprodução de vídeo... 43
5.6 Fase 5 – Preferências... 44
5.7 Fase 6 – Tratamento de acontecimentos inesperados... 45
5.8 Fase 6 – Criação de Instalador... 45
5.9 Integração na aplicação... 46
6 Conclusão... 47
6.1 Conclusão... 47
6.2 Contribuição e Satisfação dos Objectivos... 48
6.3 Trabalho Futuro... 48
Referências... 49
Anexo A: Código Exemplo... 51
A.1 Script NSIS de criação do instalador... 51
A.2 Camera.html (com.criticalsoftware.display.video.devices.bosch.autodome)...60
Lista de Figuras
Figura 1.1: Apresentação USVCAD... 2
Figura 2.1: Funcionamento ComfyJ, adaptado de [6]... 5
Figura 2.2: Modelo "Pinhole"... 6
Figura 2.3: Modelo da Câmara, retirado de [8]... 6
Figura 2.4: Tipos de distorções, adaptado de [11]... 8
Figura 2.5: Exemplo de uma correcção... 9
Figura 2.6: Funcionamento de uma lente do tipo zoom... 10
Figura 2.7: Movimento horizontal... 11
Figura 2.8: Movimento vertical... 11
Figura 3.1: Utilização de dispositivos USVCAD... 13
Figura 3.2: Screenshot USVCAD... 17
Figura 3.3: Aplicação RCP genérica, adaptado de [16]... 18
Figura 4.1: Screenshot Video Viewer (protótipo)... 20
Figura 4.2: Screenshot Video Viewer... 21
Figura 4.3: Diagrama de casos de utilização... 22
Figura 4.4: Diagrama de hardware USVCAD, adaptado de [18]... 23
Figura 4.5: Dispositivos utilizados no projecto... 23
Figura 4.6: Diagrama de componentes inicial, retirado de [18] ... 24
Figura 4.7: Diagrama de componentes final, retirado de [18]... 24
Figura 4.8: Diagrama das principais packages (plugin principal)... 25
Figura 4.9: Diagrama das principais packages (plugin Bosch)... 26
Figura 4.10: Diagrama de classes (módulo File Viewer)... 27
Figura 4.11: Diagrama de classes (módulo Video Viewer)... 28
Figura 4.12: Diagrama de classes (módulo Camera Editor)... 29
Figura 4.13: Diagrama de classes (módulo selecção)... 30
Figura 4.14: Diagrama de classes (plugins das câmaras)... 30
Figura 4.15: Vista geral da arquitectura do sistema... 31
Figura 5.1: Arquitectura de um sistema em RCP, adaptado de [19]... 33
Figura 5.2: Arquitectura Eclipse RCP, retirado de [19]... 34
Figura 5.3: Janela com activeX da Bosch integrado... 35
Figura 5.4: Classe de teste e output da sua execução... 35
Figura 5.5: Funcionamento do streaming JMF, adaptado de [2]... 39
Figura 5.6: Gravação e streaming em simultâneo JMF, adaptado de [2]... 41
Figura 5.7: Funções PTZ... 43
Figura 5.8: Exemplo de mensagem de erro... 45
Lista de Tabelas
Tabela 2.1: Coeficientes "K" de algumas câmaras, adaptado de [11]... 9
Tabela 3.1: Requisitos especificados [VV]... 14
Tabela 3.2: Requisitos especificados [CF]... 15
Tabela 3.3: Requisitos especificados [GV]... 15
Tabela 3.4: Requisitos especificados [RV]... 16
Abreviaturas e Símbolos
CCD Charged Couple Device COM Component Object Model CSW Critical Software, S.A. DLL Dynamic Link Library DOM Document Object Model FAST
FMJ
Flexible Agile Sweep Technology Freedom for Media in Java GUI Graphical User Interface HTML Hyper Text Mark-up Language IBM International Business Machines IDE Integrated Development Environment JMF Java Media Framework
JNA Java Native Access JNI Jana Native Interface
NSIS Nullsoft Scriptable Install System PTZ Pan, Tilt, Zoom
RCP Rich Client Platform R&D Research and Development SDK Software Development Kit URL Uniform Resource Locator USB Universal Serial Bus
USVCAD Unmanned Surface Vehicle Collision Avoidance Demonstrator WMP Windows Media Player
1 Introdução
Este capítulo tem como objectivo fazer o enquadramento do projecto, apresentando a instituição onde foi realizado, os projectos e programas em que está inserido, bem como os seus objectivos. No final do capítulo é também efectuada uma apresentação dos temas abordados no presente relatório.
1.1 Enquadramento e apresentação da instituição de estágio
Este trabalho surge no âmbito do projecto final do Mestrado Integrado em Informática e Computação, realizado na Faculdade de Engenharia da Universidade do Porto.
O projecto foi realizado na Critical Software, S.A., empresa Portuguesa fundada em 1998, resultado de uma spin-off1 do Instituto Pedro Nunes, em Coimbra. Actualmente a empresa
está situada em Coimbra, Porto, Lisboa, Southampton (Reino Unido), San José (EUA) e Bucareste (Roménia). A Critical Software, S.A. fornece tecnologias confiáveis, inovadoras e soluções de engenharia para missões e sistemas de informação críticos de diversos mercados, sendo eles a defesa, energia, telecomunicações, governo, indústria e aeroespacial.
A empresa tem várias áreas de expertise2, destacando-se as seguintes áreas: integração
de aplicações empresarias; sistemas embebidos e de tempo-real; infra-estruturas e segurança; verificação e validação; bases de dados; computação de alta performance; e comando e controlo; onde está incorporado o projecto desenvolvido. Esta última área fornece soluções para controlo de missão, simulação, processamento de dados, modelação e sistemas inteligentes de comando e controlo, esta secção aborda problemas que envolvem múltiplos sistemas heterogéneos e onde se desenvolveu uma forte capacidade de modelação de software, é uma área essencialmente centrada no espaço, defesa e segurança interna. O controlo de missão é uma área destinada a gerir todas as informações relativas à monitorização e comando, aquisição de dados, planeamento da missão e avaliação do desempenho. A simulação incide sobre o desenvolvimento, validação e exploração de modelos e simuladores, relacionados com o espaço, sistemas terrestres e aéreos. Quanto ao processamento de dados é efectuado o seu tratamento, desde a recepção do satélite até à apresentação ao utilizador final, a nível de processamento de imagem, calibração e geo-localização. Portanto, o enfoque desta área é desenvolvimento de infra-estruturas de fiscalização e controlo de alvos, abrangendo todo o ciclo de vida do software,
análise, design, desenvolvimento e manutenção. Adicionalmente, consultoria e estudos científicos também são realizados.
1.2 O projecto na instituição de estágio
O projecto de estágio insere-se num projecto da empresa supra citada designado por USVCAD, Unmanned Surface Vehicle Collision Avoidance Demonstrator, ver Figura 1.1. O USVCAD é um sistema demonstrador para detectar e identificar obstáculos, através de um radar e uma câmara comercial, permitindo evitar colisões manualmente através da Plataforma de Comando e Controlo existente, esta aplicação insere-se num programa denominado por FAST,
Flexible Agile Sweep Technology, tratando-se de um programa de demonstração de tecnologia
do Ministério da Defesa Inglês.
O cliente do Ministério da Defesa é o MPH IPT, Minewarfare, Patrol and
Hydrographic Integrated Project Team e o consórcio que executa o programa denomina-se por Atlas-QED team. Este consórcio é liderado pela Atlas Elektronik UK e conta com a participação
do QinetiQ e EDO Corporation.
O demonstrador tem por objectivo detectar minas no mar, recorrendo a uma embarcação pneumática rígida de 9 metros de comprimento. Esta embarcação não tripulada estará equipada com um cabo que gerará sinais magnéticos e acústicos, que uma mina hostil inteligente identificaria como as assinaturas de uma grande embarcação.
No âmbito deste projecto a CSW pretende apoiar a Atlas Elektronik e o QinetiQ na navegação da embarcação não tripulada através da sua Plataforma de Comando e Controlo.
1.3 Estudo e desenvolvimento do protótipo no projecto
O projecto proposto para o estágio teve como objectivo, o desenvolvimento de uma aplicação, para controlar e receber dados de várias câmaras, denominada Video Viewer, sendo o seu objectivo final a integração na aplicação USVCAD, permitindo apresentar nesta, uma perspectiva com todas as funcionalidades implementadas.
O Video Viewer tem como objectivos a visualização em tempo-real, gravação e reprodução de vídeo, captação de imagens e quando o dispositivo permitir, o controlo das suas funções PTZ, Pan, Tilt, Zoom. Os dispositivos utilizados na execução do projecto foram uma câmara USB, Logitech QuickCam e câmaras remotas, AXIS 2100 Network Camera e Bosch
AutoDome 200 series, sendo esta última utilizada no projecto USVCAD.
A aplicação foi desenvolvida utilizando a plataforma Eclipse RCP e apoia-se numa arquitectura de plugins, permitindo assim a utilização de componentes já desenvolvidos e facilitando a integração e contribuição das funcionalidades noutras aplicações.
1.4 Organização e temas abordados neste documento
Inicialmente este documento apresenta o enquadramento do projecto na empresa, os projectos e programas em que se insere, as entidades envolvidas e os principais objectivos pretendidos.
Posteriormente é feita uma avaliação tecnológica do estado da arte e área científica onde o projecto se insere, permitindo compreender as soluções existentes neste domínio e conceitos inerentes ao projecto.
Seguidamente é efectuada uma abordagem mais específica ao problema, apresentando os equipamentos e tecnologias utilizadas, pormenorizando os requisitos seguidos, enumerando as considerações tomadas no desenho da interface e é apresentado o plano de actividades proposto.
Após esta contextualização a nível de equipamentos e tecnologias utilizadas são descritos os aspectos característicos da aplicação desenvolvida, seguindo-se os problemas encontrados, as soluções respectivas e os pormenores da implementação.
De seguida são avaliados os resultados do projecto, terminando com as conclusões e perspectivas para o futuro.
2 Revisão Bibliográfica
Neste capítulo, inicialmente são apresentadas algumas tecnologias existentes a nível de
streaming de vídeo na linguagem JAVA e algumas aplicações ao nível de comunicação entre
JAVA e ActiveX, posteriormente são descritos os princípios do funcionamento de uma câmara e o modo como é efectuado o mapeamento entre o mundo 3D para uma imagem 2D. O capítulo termina com a descrição, de algumas funções dos dispositivos de captura e dos tipos de
streaming existentes.
2.1 Tecnologias existentes streaming de vídeo
2.1.1 Java Media Framework
JMF foi desenvolvida pela Sun e IBM e possibilita a adição de ficheiros media a aplicações JAVA. Possibilita a captura, edição, reprodução e streaming de vídeo [1], [2].
2.1.2 QuickTime for Java
QTJ é uma biblioteca que habilita funções multimédia, através de chamadas à biblioteca nativa do QuickTime. Possibilita a captura, edição, reprodução de vídeo, em aplicações JAVA, a executar nos sistemas operativos MAC e Windows [3].
2.1.3 JVLC
O projecto JVLC pretende criar uma biblioteca multimédia flexível e fácil de utilizar, para JAVA. JVLC assenta no player multimédia VideoLAN, originando assim a leitura e descodificação de quase todos os tipos de ficheiros media e possibilita ainda, o streaming através da Internet [4].
2.1.4 FMJ
FMJ é um projecto open-source que tem como objectivo promover uma alternativa ao JMF, enquanto continua compatível com JMF através da sua API. Esta compatibilidade possibilita utilizar os codecs de JMF existentes, mas por vezes estes codecs não funcionam e é necessário encontrar alternativas. FMJ pretende a criação de uma framework que permite capturar, reproduzir, fazer streaming de vídeo independentemente do sistema operativo utilizado [5].
2.2 Aplicações
2.2.1 ComfyJ
É um produto shareware desenvolvido pela TeamDev, com o objectivo de integrar Java e COM, permitindo a comunicação bidireccional entre estas duas tecnologias [6], possibilitando assim integrar aplicações nativas em código JAVA. A principal vantagem é que não necessita de desenvolvimento de código nativo.
2.2.2 EZJCom
Ferramenta desenvolvida pela EZJCom, que permite invocar a partir de JAVA componentes ActiveX [7], sem ser necessário qualquer conhecimento sobre objectos COM ou linguagens próprias dos ActiveX.
2.3 Dispositivos de captura
Os dispositivos de captura também são designados por câmaras e são utilizados para capturar imagens ou sequências de imagens do exterior, fazendo um mapeamento entre o mundo a 3 dimensões e uma imagem a 2 dimensões.
Uma câmara consiste numa caixa com uma pequena abertura pela qual entra a luz e uma superfície onde esta é projectada. Inicialmente foram desenvolvidas para a indústria da
televisão, mas actualmente são aplicadas em vários sistemas, sendo de destacar os sistemas de vigilância, robóticos e vídeo-conferência.
2.3.1 Funcionamento
O modelo utilizado normalmente para exemplificar o funcionamento de uma câmara é apresentado na Figura 2.2 e designa-se por “pinhole”, que é um orifício extremamente pequeno, onde a luz é captada para dentro de uma câmara, sendo a imagem real projectada na parede oposta ao orifício, sofrendo uma inversão. Na realidade é utilizada uma lente que altera as proporções entre a imagem visível na cena real e o tamanho da imagem projectada no sensor de imagem. Para lentes do tipo zoom, essa proporção é alterável através da rotação de um anel no exterior da lente.
Nesta parede é colocada uma tela translúcida para visualização em tempo-real ou um sensor de imagem, normalmente este sensor é um CCD, charge-coupled device, para processamento da imagem, a quantidade de células fotoeléctricas do CCD é responsável pela capacidade de resolução e detalhe da imagem [8], [9].
A inversão sofrida pela imagem é inconveniente na análise do problema, assim vamos utilizar o modelo geométrico apresentado na Figura 2.3, em que o plano da imagem se encontra entre o objecto e o plano focal, obtendo-se uma imagem equivalente.
Figura 2.3: Modelo da Câmara, retirado de [8] Figura 2.2: Modelo "Pinhole"
Segundo este modelo, um ponto no espaço com as coordenadas X= (x,y,z), é mapeado no plano da imagem no ponto x=(x,y,z_plano_da_imagem), resultante da intersecção deste com a recta r. Assumindo que o ponto P, intercepção do eixo óptico com o plano da imagem, é a origem das coordenadas da imagem. Este mapeamento é descrito pela seguinte fórmula:
x , y , z fx/ z , fy /z , f
(2.1)caso contrário as coordenadas da imagem são dadas por:
x , y , z fx/ z Px , fy / zPy , f
(2.2) Esta equação pode ser exemplificada em detrimento das suas coordenadas homogéneas:
x y z 1
fxzPx fyZPy z
=[
f Px 0 f Py 0 1 0]
x y z 1
(2.3) resultando em: k =[
f f PxPy 1]
(2.4)Sendo esta a matriz de calibração da câmara, que contém os factores internos ou parâmetros intrínsecos que afectam o processamento da imagem.
No caso das câmaras CCD, também existe a possibilidade dos pixéis não serem quadrados o que leva a uma alteração na matriz de calibração,
k =
[
mxf
myf
mxPx
myPy
1
]
(2.5)
Na qual mx e my representam o número de pixéis por unidade de comprimento no eixo Ox e Oy, respectivamente, que podem ser substituídos por
e aplicados num só eixo, como podemos observar a seguir. Existe ainda a possibilidade de introdução do parâmetro s, skew, que modela o ângulo entre as linhas e colunas do CCD [10], quando os eixos não são perpendiculares, situação muito improvável, que origina.k =
[
f
s
f
Px
Py
1
]
(2.6)
Em relação aos parâmetros intrínsecos falta só referir a distorção causada na imagem pela lente, esta distorção pode ser classificada de dois modos modo, distorção em barril ou em almofada, pin-cushion, estas distorções são apresentadas na Figura 2.4.
A distorção radial pode ser corrigida ou minimizada através de um função
L r
[12], podendo assim, ser determinadas as coordenadas correctas x’=(x’,y’) a partir das coordenadas da imagem distorcida x=(x,y), através de:{
x '= xcL r x− xc y ' = ycL r y− yc (2.7) sendo{
L r =1k1rk2r
2
k3r
3
...
r =
x−xc
2
y− yc
2 (2.8)Os coeficientes
{
k1 , k2 , k3 , ...}
são valores estimados da distorção da lente. Este método de correcção pode ainda ser substituído por:{
x '= xc1kr
2
x−xc
y ' = yc1kr
2
y − yc
(2.9) Figura 2.4: Tipos de distorções, adaptado de [11]Onde k é a relação geométrica utilizada para corrigir a distorção de uma imagem, sendo positivo em distorções do tipo barril e negativo no caso do pin-cushion, na Figura 2.5 é apresentado um exemplo de uma correcção e na Tabela 2.1 apresentados valores “k” de algumas câmaras.
Tabela 2.1: Coeficientes "K" de algumas câmaras, adaptado de [11]
Câmara Resolução da imagem (megapixels) Coeficiente de distorção “k” (tele-photo) Coeficiente de distorção “k” (wide-angle)
Canon PowerShot S30 3.2 -1.1e-8 -1.36e-8
Olympus Camedia C-2040 2.1 ~0 -7.344e-9
Toshiba PDR-M25 2.2 -1.173e-8 -1.173e-8
Sony 5.1 7.741e-9 -2.014e-9
Canon EOS digital rebel 6.2 -2.69e-9 -7.303e-9
Foram encontrados assim, todos os parâmetros intrínsecos de uma câmara:
●
f
- distância focal, distância entre o plano da imagem e o centro óptico.● Px e Py - coordenadas do centro óptico, no referencial exterior.
●
s
- parâmetro “skew” , modelação do ângulo entre as linhas e colunas do CCD.● k - parâmetro de distorção da lente.
●
- relação entre a largura e comprimento dos pixéis, que faz variar o número de pixéis por unidade de comprimento no eixo Ox em relação ao Oy.Geralmente, ao contrário da situação apresentada, o referencial do mundo real não coincide com o referencial da câmara, mas encontram-se relacionados através de uma translação e de uma rotação. Assim, correspondendo um ponto X no referencial da câmara a um ponto X’ no referencial exterior, as coordenadas do ponto X são dadas por:
X =R X ´−C
(2.10) Onde C, representa as coordenadas do centro óptico no referencial exterior e R a matriz de orientação do plano da câmara. Os parâmetros R e C representam os parâmetros extrínsecos da câmara.X =
[
R −RC
0
1
]
x
y
z
1
=
[
R −RC
0
1
]
X '
(2.11)2.3.2 Zoom
Certas câmaras também utilizam lentes do tipo Zoom, sendo consideradas deste tipo, lentes constituídas por duas partes: uma lente standard fixa e um sistema de lentes que podem ser movimentadas com o intuito de redimensionar o feixe de luz e consequentemente o tamanho da imagem, este funcionamento é apresentado na Figura 2.6.
Considerando o sistema de visão como um conjunto, os parâmetros intrínsecos da câmara são alterados quando se altera o factor de Zoom.
Figura 2.6: Funcionamento de uma lente do tipo zoom
2.3.3 Pan e Tilt
O controlo das funções Pan e Tilt de uma câmara permite uma maior cobertura utilizando apenas um dispositivo, visto esta ter a possibilidade de ser movimentada horizontalmente, Pan e verticalmente, Tilt.
Estes movimentos realizados pela câmara, vão fazer com que os parâmetros extrínsecos da câmara sejam alterados.
2.4 Streaming de vídeo
A captura e streaming de vídeo tornou-se extremamente popular através da Internet e redes locais. Existem actualmente três maneiras para enviar um vídeo de um servidor para uma aplicação de um cliente. No primeiro método, é feito o download completo do ficheiro e só depois é reproduzido. Este método apenas é adoptado para vídeos pequenos e em situações que não é necessária uma visualização em tempo real. O segundo método, possibilita começar a ver o vídeo enquanto este está a ser descarregado, é ideal para ficheiros de grandes dimensões, mas tem um atraso na visualização, já que tem que ser armazenado numa cache. O terceiro método passa por enviar o vídeo do servidor para o cliente em tempo real, sendo necessária uma grande largura de banda para uma transmissão mais rápida que os métodos anteriores. Este é o único método para assistir a um vídeo em directo. Esta entrega imediata do vídeo gera um elevado tráfego na rede, o que por vezes conduz à perda de alguns frames, sendo esta situação aceitável, ao contrário da situação de atraso na recepção dos frames. Assim, de acordo com o pretendido devemos balançar entre uma boa qualidade de vídeo e um elevado frame rate [13].
Figura 2.7: Movimento horizontal
Figura 2.8: Movimento vertical
3 Análise do problema
Nesta secção é feito um enquadramento do projecto na empresa e no projecto em que se insere, é justificado o porquê da utilização da câmara na embarcação, são apresentados os requisitos especificados para a aplicação USVCAD e as decisões tomadas na construção da interface. Por fim é apresentado o plano de actividades traçado no início do projecto.
3.1 Enquadramento do projecto na empresa
O projecto de estágio, como já foi referido anteriormente, insere-se no USVCAD, que é projecto interno de R&D, Research & Development, que resulta da identificação por parte da CSW, de um mercado a conquistar nas plataformas de Command, Control and Intelligence (C2I).
3.1.1 Objectivo do projecto
O objectivo do estágio é o desenvolvimento de uma aplicação, que permita o controlo da câmara utilizada na embarcação. A aplicação terá que ser desenvolvida em Eclipse RCP para usufruir da arquitectura de plugins e vantagens que daí advêm, como facilidade de integração, reutilização de plugins, estrutura modular, entre outras. Estas características das aplicações RCP são essenciais pois a aplicação pretende estender e ser integrada na aplicação existente na CSW, desenvolvida utilizando esta ferramenta.
Em relação ao projecto USVCAD, a necessidade de utilização de uma câmara, na embarcação, prende-se com o facto de os radares não possibilitarem a detecção de obstáculos a curtas distâncias, daí a introdução de um sistema visual, para permitir identificar os obstáculos que surjam neste espectro não captado pelo radar, ver Figura 3.1. Assim é utilizada a câmara para identificar os obstáculos a partir dos 3 metros e o radar é utilizado a partir dos 30 metros [14].
3.1.2 Parcerias
Atlas Elektronik UK- Empresa com vasta experiência e líder na área de equipamentos electrónicos e sistemas de defesa naval.
EDO Corporation (investigação Americana) - É um grupo especializado na prestação de serviços de engenharia e soluções Electronic Warfare. Desenvolve, altera, integra e faz manutenção de produtos de alta tecnologia militares e governamentais.
QinetiQ (investigação Inglesa) - É uma das empresas líderes mundiais em tecnologia de defesa e segurança, fornecendo investigação, serviços de consultoria e soluções tecnológicas.
3.2 Requisitos
Os requisitos para o projecto são uma decomposição dos especificados no Documento de Requisitos do USVCAD, “CSW-USVCAD-2007-SRS-9106” [14] para a vista de vídeo, pois o projecto iniciou-se já na fase “design engineering” do USVCAD, sendo assim já tinha sido feito o levantamento de requisitos e bastou fazer-se uma análise e uma generalização dos mesmos [15]. Os requisitos iniciais foram estendidos a outros dispositivos, resultando o projecto numa aplicação mais genérica.
A nível de tecnologias o projecto restringia-se à utilização do Eclipse RCP e consequentemente à linguagem JAVA com recurso exclusivo a ferramentas open-source.
3.2.1 Representação de um requisito
Os requisitos são apresentados com a seguinte estrutura.
ID Descrição Prioridade
ID - composto por 2 campos.
● 2 letras para identificar a categoria (VV- visualização de vídeo, CF- controlo PTZ, GI- gravação de imagens, GV- gravação de vídeo, RV- reprodução de vídeo e CC- configuração das câmaras) .
● 2 dígitos para o numero do requisito.
Descrição - texto do requisito.
Prioridade – representado por 3 estados
● Obrigatório - este requisito tem que ser implementado.
● Desejável - este requisito deve ser implementado mas não é obrigatório, é considerado uma evolução do sistema.
● Opcional – requisito em avaliação, acrescenta valor ao sistema.
3.2.2 Análise dos requisitos
Em relação ao problema, os requisitos foram identificados com base no projecto USVCAD, que utiliza a Bosch Autodome. A utilização de outros dispositivos foi introduzida como um “proof of concept”, para avaliar o comportamento do sistema com vários dispositivos e aumentar a flexibilidade da aplicação, motivo pelo qual estes requisitos surgem com um grau de prioridade mais baixo.
Sendo o objectivo principal da câmara a identificação de obstáculos, para posteriormente ser efectuado o controlo manual do trajecto do USV, é necessário a aplicação fazer um streaming de vídeo em tempo real, para dar tempo ao operador de evitar determinadas colisões.
Tabela 3.1: Requisitos especificados [VV] Visualização de Vídeo em tempo real [VV]
ID Descrição Prioridade
VV-01 Visualização de vídeo através de Bosch Autodome Obrigatório VV-02 Visualização de vídeo através de AXIS 2100 Desejável VV-03 Visualização de vídeo através de dispositivos USB Desejável
A utilização das funções PTZ da câmara, possibilitam uma maior cobertura visual do espaço, auxiliando o operador na identificação e classificação de obstáculos, no caso em que a detecção efectuada pelo radar é ambígua, ver Tabela 3.2.
Para além, do controlo PTZ, é também interessante o controlo de funções de focus e
iris, pois são vantajosas na medida que permitem um melhoramento da imagem, aumentando
assim a validade da classificação efectuada acerca dos obstáculos identificados.
Este controlo da câmara, em situações de risco, pode dar origem a falhas ou erros nos movimentos efectuados. Para combater esta situação foi introduzido um mecanismo de posições predefinidas, em que através de uma simples click a câmara é movimentada para um posição guardada anteriormente. As posições guardadas mantêm, para além da orientação e posição em relação ao exterior, o factor de zoom.
Tabela
3.2: Requisitos especificados [CF]
Controlo de funções PTZ [CF]
ID Descrição Prioridade
CF-01 Controlo de funções PTZ da Bosch Autodome Obrigatório
CF-02 Controlo de focus. Desejável
CF-03 Controlo da abertura da câmara Opcional
CF-04 Posições predefinidas Desejável
Todas as visualizações efectuadas necessitam de ser guardadas, funcionando a aplicação como uma caixa preta da embarcação, permitindo posteriormente verificar erros na navegação que causaram destruição total ou parcial do USV, analisar cenários e trajectos utilizados, ver Tabela 3.3. Assim, é muito importante para estes sistemas de visão ou outros sistemas de vigilância manter um histórico dos acontecimentos.
Tabela
3.3: Requisitos especificados [GV]
Gravação de imagem [GI] e vídeo [GV]
ID Descrição Prioridade
GI-01 Gravação de imagens da Bosch Autodome Obrigatório GI-02 Gravação de imagens da AXIS2100 Opcional GI-03 Gravação de imagens de dispositivos USB Opcional GV-01 Gravação de vídeo da Bosch Autodome Obrigatório GV-02 Gravação de vídeo da AXIS2100 Desejável GV-03 Gravação de vídeo de dispositivos USB Desejável
A inserção de um módulo de reprodução na aplicação é essencial, para não ser necessário recorrer a aplicações third-parties, para efectuar a análise dos vídeos anteriormente capturados, ver Tabela 3.4. A análise dos métodos de reprodução, vem justificar ainda mais a inserção deste módulo, pois existem formatos de vídeo proprietários, que apenas podem ser reproduzidos através dos controlos ActiveX dos fabricantes.
Tabela
3.4: Requisitos especificados [RV]
Reprodução de Vídeo [RV]
ID Descrição Prioridade
RV-01 Reprodução de vídeos gravados Obrigatório RV-02 Controlo sobre vídeo em reprodução Desejável
A aplicação deve também permitir a leitura de ficheiros de configuração, pois no caso da utilização de mais que um dispositivo, a comunicação e acesso às câmaras é transparente ao operador, não sendo necessário especificar os endereços dos dispositivos sempre que a aplicação é utilizada. A aplicação também deve permitir predefinir determinadas configurações e preferências, aumentando a usabilidade e performance do sistema, pois cada vez que é necessário efectuar a gravação de um vídeo ou de uma imagem, esta acção é efectuada no momento em que o utilizador a solicita, pois o destino da a informação a capturar já foi introduzido no sistema, ver Tabela 3.5.
No sistema também foi introduzido um método de comunicação segura, permitindo restringir o acesso a determinadas câmaras, por parte de alguns utilizadores. As credenciais utilizadas são completamente transparentes aos operadores e podem ser definidas antes ou depois da instalação, esta transparência resulta do mecanismo de acesso às câmaras.
Tabela
3.5: Requisitos especificados [CC]
Configurações das câmaras [CC]
ID Descrição Prioridade
CC-01 Leitura de configuração da câmara a partir de um ficheiro Obrigatório CC-02 Alteração de ficheiro de configuração Obrigatório CC-03 Gravação de preferências da câmara Desejável CC-04 Comunicação segura com Bosch Autodome (user/pass) Opcional
3.2.3 Análise da interface
A nível de interface, foram feitos 2 estudos, o primeiro estudo baseou-se na análise de vários produtos de vigilância e controlo de câmaras existentes no mercado e de onde foram retiradas as seguintes conclusões:
● Agrupamento de botões de acordo com as funções que executam.
● Aspecto dos componentes
● Todos os ícones sem texto associado, disponibilizam tooltips.
● As funções desempenhadas pelos botões relacionam-se inteiramente com o aspecto visual dos mesmos.
● Funcionamento dos botões.
Para permitir comandar toda a aplicação e sistema visual do barco, foram definidas três classes de funções, de acordo com a importância e frequência de utilização. Assim a divisão de de funcionalidades foi feita da seguinte forma:
1. Controlo das funções da câmara - Estas funções ocupam uma view única, e dispõem de botões de controlo de grandes dimensões dispostos de forma intuitiva. Estas características são importantes pois estes são os comandos mais utilizados na utilização da aplicação. As funções PTZ podem ainda ser controladas através de click's no componente de vídeo, ver 75.4.
2. Controlo dos vídeo em reprodução - A view de controlo da reprodução ocupa uma área com menos relevância que a da view de controlo PTZ, pois as funcionalidades que fornece são utilizadas com menos frequência.
3. Controlo das funções de gravação - Estas funções foram agrupadas na toolbar, em ícones pequenos, pois durante uma utilização da aplicação geralmente só são executadas no início e no fim.
Estes grupos de funcionalidades apenas são apresentados ao utilizador, quando a execução das funções que realizam é permitida.
O segundo estudo foi feito à aplicação USVCAD onde o projecto foi integrado, ver Figura 3.2, e foi utilizado para analisar a disposições dos componentes na aplicação.
Esta análise resultou na criação de uma estrutura e disposição de componentes idêntica à do USVCAD e de aplicações RCP, ver Figura 3.3, em que no caso do Video Viewer é utilizado um resource navigator na área 1, a view de controlo das funções PTZ, é apresentado na área 2, a view de controlo do player, na área 4 e o componente principal onde é apresentado o
streaming de vídeo e a reprodução de ficheiros na área 3.
Todos estes componentes visuais podem ser movíveis e redimensionados de acordo com a preferência dos utilizadores do sistema, permitindo assim esconder views que não sejam necessárias no momento.
3.3 Plano do projecto
Seguidamente é apresentado o plano de actividades especificado no ínicio do projecto.
3.3.1 Fase 1
Objectivo:
● Visualização de vídeo em tempo-real e Controlo PTZ Actividades:
● Análise (HW, arquitectura de SW, protocolos de comunicação, métodos a utilizar).
● Proof-of concept:
● Bosch AutoDome, Genérico (JMF: USB, Webcams), Axis
● Rever documento de arquitectura
● Fazer uma stand alone aplication (build 1) integrada num Instalador.
3.3.2 Fase2
Objectivo:
● Gravação e Reprodução de vídeo.
● Processamento de video (opcional) Actividades:
● Análise (arquitectura, métodos a utilizar).
● Proof-of concept
● Bosch AutoDome, Genérico (JMF: USB, Webcams), Axis
● Rever documento de arquitectura
● Fazer uma stand alone aplication (build 2) integrada num instalador
3.3.3 Fase3
Objectivo:
● Integração no projecto USVCAD Actividades:
● Análise (arquitectura e métodos a utilizar)
4 Solução e visualização de sinópticos
Neste capítulo é apresentada a solução proposta, para o problema em questão, sendo apresentada toda a sua estrutura a nível de módulos desenvolvidos e interligação entre os mesmos. Para melhor compreender a arquitectura do sistema são apresentados os diagramas de classes, componentes e os casos de utilização da aplicação. O capítulo termina com a enumeração das principais vantagens competitivas desta aplicação.
4.1 Apresentação da solução
A solução proposta partiu do protótipo desenvolvido, que teve como objectivo aplicar os conceitos de RCP [16], ver Figura 4.1, originando assim o Video Viewer.
O Video Viewer é uma aplicação stand-alone que permite a um utilizador pesquisar, através de um resource navigator, ficheiros XML de configuração de câmaras previamente criados, dando ao utilizador dois tipos de ferramentas para abrir os ficheiros deste tipo, o Video Viewer ou o Camera Editor. Se utilizar o Camera Editor é apresentado um editor com as configurações de ligação, se utilizar o Video Viewer é apresentado um editor com a visualização em tempo-real da câmara. Neste último caso juntamente com a apresentação do vídeo é lançada uma view para controlo das funções PTZ, e na Tool bar aparecem os ícones para gravação de vídeo e imagens. Na Figura 4.2 evidencia-se a estrutura do Video Viewer.
Em relação às funções de gravação, quando o utilizador pretende fazer uma gravação tem que seleccionar, caso não tenha definidas preferências, o destino onde deseja guardar o ficheiro. Estas preferências podem ser definidas na MenuBar em File-> preferences, permitindo predefinir o destino onde são gravados os ficheiros, sendo de referir que no caso da Bosch também se podem definir as credencias de acesso a câmara.Em relação aos vídeos gravados, o mesmo resource navigator, utilizado anteriormente, é aproveitado para explorar os ficheiros de vídeo, permitindo fazer a sua reprodução através do File Viewer, um editor que lança uma view com os controlos e estado do vídeo.
Todas estas funcionalidades são independentes, permitindo simultaneamente, visualizar várias câmaras, gravar e reproduzir vídeos, através dos vários editores de visualização, que podem ser movíveis e empilháveis. Seguidamente são apresentados diagramas, desenvolvidos com [17], para melhor compreensão do sistema.
4.1.1 Diagrama de casos de utilização
Na Figura 4.3 são apresentadas em alto nível as funcionalidades do sistema.
4.2 Arquitectura do sistema
4.2.1 Hardware
A nível de hardware já tinha sido feita a escolha dos equipamentos para o projecto USVCAD, onde foi integrado o Video Viewer, assim foi analisado o documento de arquitectura,“CSW-USVCAD-2007-SAS-9218” [18] e identificados os equipamentos, restringindo-se a arquitectura do Video Viewer à apresentada na Figura 4.4, onde esta evidenciado o equipamento utilizado.
No entanto o Vídeo Viewer além da Bosch Autodome 200 series, destacada anteriormente, permite a utilização de câmaras AXIS e Câmaras USB suportadas pelo JMF, os dispositivos utilizados podem ser observados na Figura 4.5.
4.2.2 Software
A arquitectura definida inicialmente e apresentada na Figura 4.6, era constituída por um
plugin principal “com.criticalsoftware.display.video” que era estendido por três plugins o
“com.criticalsoftware.display.resourcenavigator”, para aceder ao sistema de ficheiros, o “com.criticalsoftware.processing.videoaccess”, que permitiria visualizar o vídeo através de JMF ou de um controlo ActiveX e um terceiro plugin “com.criticalsoftware.display.video.controller”,
Figura 4.4: Diagrama de hardware USVCAD, adaptado de [18]
Após alguma análise do sistema a desenvolver optou-se por uma arquitectura mais modular, que é apresentada na Figura 4.7. Esta alteração teve como objectivo tornar o sistema o mais escalável possível, em que a implementação de novas câmaras é feita facilmente, bastando seguir como exemplo os plugins já desenvolvidos. Este tipo de arquitectura também permite uma poupança de recursos pois os plugins só são carregados quando necessários e podem ser actualizados dinamicamente, sem ser necessário reiniciar a aplicação.
Assim a arquitectura do sistema foi redesenhada, passando a um plugin principal ”com.criticalsoftware.display.video”, onde é definida toda a estrutura da aplicação a nível de
Figura 4.6: Diagrama de componentes inicial, retirado de [18]
GUI, graphical user interface, são definidas as views, os editors e as actions necessárias para a interacção com os dispositivos. Este plugin cria um extension point para estender algumas das suas classes e receber contribuições dos plugins que, utilizando bibliotecas third-parties, permitem a descodificação e apresentação dos vídeo e controlo PTZ das câmaras. Além disso também é estendido outro plugin, para lhe contribuir com as referências do sistema de ficheiros, ”com.criticalsoftware.display.resourcenavigator”.
Plugin “com.criticalsoftware.display.video”
Na Figura 4.8 é apresentada uma estrutura dos principais componentes do plugin principal.
Plugins pertencentes a “com.criticalsoftware.display.video.devices”
Em relação aos plugins das câmaras, o da Bosch e o da Axis estão desenvolvidos do mesmo modo, divergindo deles o da Logitech onde não existe o ficheiro *.html, necessitando a comunicação com a câmara ser efectuada a nível da linguagem JAVA, esta estrutura pode ser verificada na Figura 4.9.
4.2.3 Diagramas de classes
Nesta secção são apresentadas as principais classes dos módulos existentes na aplicação.
File Viewer
Como podemos observar na Figura 4.10, em relação à reprodução de vídeo existe uma classe denominada de FileViewer que recebe um VideoResource, referência para um ficheiro de vídeo seleccionado no Resource Navigator. Esta classe instancia um player de acordo com a extensão do ficheiro, MediaPlayer para *.mp4 e AXISPlayer para *.mpg e *.mov. Estes players são subclasses da classe AbstractPlayerControls e contribuem no editor com um componente de video.
O FileViewer lança também uma view com os controlos necessários à reprodução do vídeo, denominada por PlayerControllerView.
Video Viewer
A classe VideoViewer recebe um VideoResource do tipo file.cam e instancia um objecto do tipo CameraModel., apresentado em 4.2.3, que faz a leitura das configurações relativas a câmara em questão, preenchendo assim a sua estrutura de dados. Seguidamente verifica o tipo de câmara e através do extension point instancia um objecto da classe VídeoDisplay do plugin relativo à câmara referenciada, subclasse da AbstractVideoDisplay. A partir daqui o plugin principal aceita contribuições e executa operações sobre o plugin da câmara.
A classe VideoViewerActionDelegate recebe um ActionId relativo ao botão seleccionado e verificando o tipo de editor aberto, realiza a operação pretendida no plugin da câmara. A classe VideoViewer também lança uma view que habilita o controlo das funções PTZ da câmara, ver Figura 4.11.
Camera Editor e Camera Model
A classe CameraEditor é utilizada para tratar o mesmo tipo de ficheiros que o VideoViewer, ficheiros file.cam, recebe também um VideoResource e posteriormente instancia um objecto do tipo CameraModel. Esta classe, CameraModel, é responsável por ler o ficheiro XML e preencher a estrutura de dados relativa à câmara, permitindo assim a apresentação dos dados ao utilizador por parte do editor CameraEditor. Estes dados podem ser alterados e são posteriormente gravados no ficheiro XML, novamente através do CameraModel, estas duas classes são apresentadas na Figura 4.12.
Figura 4.12: Diagrama de classes (módulo Camera Editor)
Video Resource e ControllerViewSelection
Estas duas classes estão relacionadas com os três módulos descritos anteriormente. Em relação à classe VideoResource, é ela a responsável pela referência passada as classes VideoViewer, FileViewer e CameraEditor. A classe ControllerViewSelection foi implementada com o intuito de controlar o tipo de operações apresentadas de acordo com o tipo de editor aberto, remove ou apresenta, a view de controlo das funções PTZ, a view de controlo do vídeo e os botões das actions, ver Figura 4.13
VideoDisplay
Como se pode observar na Figura 4.14, cada plugin contém uma classe denominada VideoDisplay que contribui com o componente de vídeo no plugin principal, mais concretamente no VideoViewer e realiza as operações pretendidas invocadas por este. Além desta classe, cada plugin tem também uma classe PreferencePage. responsável por fazer a leitura e gravação no ficheiro file.properties, das preferências de cada câmara.
Figura 4.13: Diagrama de classes (módulo selecção)
Diagrama geral
Na Figura 4.15, para melhor compreender a estrutura geral do sistema, podemos identificar as interacções existentes entre todos os módulos apresentados anteriormente.
4.3 Vantagens competitivas
As principais vantagens do Video Viewer são a possibilidade de utilizar câmaras de diferentes fabricantes e permitir além do streaming de vídeo, controlar as funções PTZ das câmaras, bem como fazer a reprodução dos vídeos recolhidos, tudo na mesma aplicação.
Neste momento permite a utilização de todas as câmaras locais (USB ou integradas no computador) e das câmaras remotas da Bosch e da Axis. A adição de novos dispositivos é realizada facilmente, devido a arquitectura utilizada.
Pode funcionar no modo stand-alone ou ser integrada facilmente em qualquer aplicação desenvolvida em Eclipse RCP.
Não é necessária a instalação de drivers dos dispositivos e permite uma ligação segura com os mesmos.
A utilização de ActiveX permite a visualização em tempo real, sendo os equipamentos de comunicações responsáveis por atrasos na recepção do vídeo.
5 Implementação
Neste capítulo são apresentadas as fases contempladas na implementação do projecto e justificadas as opções tomadas durante o seu desenvolvimento. É neste capítulo que são evidenciados os métodos e pormenores da implementação do sistema.
5.1 Introdução
A implementação do Vídeo Viewer dividiu-se em vária fases e foi efectuada em Eclipse RCP, ver Figura 5.1, um IDE para JAVA. O recurso a este ambiente de desenvolvimento e à linguagem JAVA deve-se ao facto do VideoViewer pretender ser integrado na plataforma existente na CSW que está a ser desenvolvida em RCP. O Eclipse RCP é baseada numa arquitectura de plugins colaborativos, que comunicam entre si, permitindo assim desenvolver sistemas acopláveis e extensíveis, através de reutilização de plugins e utilização de bibliotecas
third-parties. É o Eclipse RCP que fornece os componentes movíveis e empilháveis, views e editors, bem como todas as funcionalidades do Workbench. O Eclipse RCP assenta em Equinox,
uma implementação do OSGI [19].
Figura 5.1: Arquitectura de um sistema em RCP, adaptado de [19]
5.2 Fase 1 – Aprendizagem e pesquisa de soluções
A primeira fase iniciou-se com uma aprendizagem de Eclipse RCP e de JMF. Em relação ao RCP foram assimilados os principais conceitos associados a esta plataforma, views,
editors, actions, ver Figura 5.2, e os métodos de contribuição entre plugins, extension points;
quanto ao JMF, foi avaliado o seu funcionamento e possíveis aplicações. Nesta fase, também foram avaliados os métodos a utilizar na comunicação com as câmaras.
Inicialmente tentou-se comunicar com a câmara Bosch através do JMF, situação que não funcionou, apesar da câmara suportar alguns dos protocolos necessários para o efeito. Mas esta investigação foi rapidamente abortada, pois mesmo que se conseguisse fazer o streaming através do JMF, ficaria por resolver a situação de controlo das funções PTZ, verificou-se assim, a necessidade de utilizar outra metodologia.
Teríamos então que partir para outra solução, que seria integrar os controlos ActiveX fornecidos pelo fabricante, na linguagem JAVA.
Foi realizada uma investigação das soluções existentes para esse efeito e identificou-se uma package para JAVA “org.eclipse.swt.ole.win32”, que permite a integração de ActiveX e objectos COM, dentro de um widget. Foi implementada uma classe para testar essa integração e verificar se era possível aceder ao ActiveX, sendo para isso era necessário identificar no registo do Windows, regedit, o progID correspondente ao ActiveX da Bosch, obtendo-se “Cameo.Cameo.1”.
Neste caso obtiveram-se os resultados esperados e foi integrado o controlo da Bosch, ver Figura 5.3, mas para os objectos COM, necessários para fazer a ligação à câmara a mesma situação não se verificou, motivo pelo qual teve que ser abandonada esta solução.
Na Figura 5.4 podemos observar a classe implementada utilizada para o efeito e que faz a listagem das funções que o controlo possibilita, para posterior invocação das mesmas, pois não podemos utilizar o SDK fornecido, visto ter sido desenvolvido apenas para aplicações desenvolvidas em Visual Studio .NET, Microsoft Visual C++, Microsoft Visual Basic, Internet Explorer (VBScript e Javascipt).
Figura 5.3: Janela com activeX da Bosch integrado
O não cumprimento das expectativas por parte desta solução, originou uma nova investigação no sentido de utilizar o SDK fornecido, tendo sido encontradas duas outras soluções, o JNI e o JNA.
Em relação ao JNI não foi utilizado pois era necessário desenvolver código utilizando uma linguagem suportada pelo SDK e posteriormente fazer um wrapper em JAVA, o que resultaria numa baixa performance e dificuldade na identificação de possíveis erros. O JNA contorna esta questão e permite o acesso a bibliotecas nativas, utilizando apenas código JAVA, mas a necessidade de conhecimento da declaração das estruturas de dados das funções dos dll’s, fez com que esta hipótese tenha sido descartada.
Assim foi alcançado o limite da linguagem JAVA neste domínio, o que originou a abordagem ao problema de outra forma e já que o servidor web da câmara possibilita o seu controlo através de um browser, voltou-se à package “org.eclipse.swt.ole.win32”, mas desta vez não para integrar directamente o controlo, mas sim um browser para abrir uma página HTML, que embebia os objectos COM e o ActiveX e executasse funções de controlo através de Javascript, linguagem aceite pelo SDK da Bosch. Esta solução foi de fácil implementação, bastando alterar o progID, na classe apresentada anteriormente para ”Shell.Explorer.1”, identificador do Internet Explorer.
Porém a necessidade de interagir com a página através de código JAVA e não apenas executando as operações numa página HTML, incentivou a pesquisa de mais soluções neste domínio, identificando-se assim a package “org.eclipse.swt.browser”, que é um widget que permite visualizar páginas HTML e executar funções Javascript, através do código da aplicação, em JAVA. Esta solução mostrou-se uma boa opção pois também pode ser aplicada a câmara da Axis, em que fabricante também disponibiliza um controlo ActiveX para interagir com os seus dispositivos.
Assim, em relação à câmara Bosch e à câmara Axis, a solução tinha sido encontrada, bastando encontrar a solução para a câmara Logitech. O estudo realizado anteriormente permitiu concluir que o JMF seria a melhor opção, pois permite-nos implementar todas as funções que pretendemos e sendo a Logitech um dispositivo USB, funciona perfeitamente.
Assim estava terminada a primeira fase da implementação, estando definidos os métodos que seriam utilizados na comunicação com as câmaras.
5.3 Fase 2 – Streaming e gravação de vídeo
Nesta fase foi iniciado o desenvolvimento da aplicação que teve com base o mock-up3 que já continha uma view com o resource navigator. Foram implementados dois editores o VideoViewer e o CameraEditor, já referidos em (4.2.3.2) e (4.2.3.3), respectivamente. É de salientar que é através do VideoViewer que é utilizado o extension point, mecanismo oferecido pelo Eclipse RCP para estender comportamentos entre plugins, através do qual um plugin pode consultar o Extension Registry e instanciar objectos contribuídos por outros plugins, neste caso, aceitar contribuições das câmaras. O método que através de um elemento identificador da câmara executa o plugin respectivo, devolvendo o objecto instanciado é denominada por
getVideoDisplay(), o objecto é uma instância da classe VideoDisplay do plugin respectivo, que
implementa os métodos abstractos da classe AbstractVideoDisplay.
/**
* Creates and returns a new instance of the executable extension identified * by the named attribute of this configuration element
*
* @param elementName
* @return the executable instance *
*/
public AbstractVideoDisplay getVideoDisplay(String elementName) { String point =
"com.criticalsoftware.display.video.extensions.videodisplay";
IConfigurationElement[] decls = Platform.getExtensionRegistry() .getConfigurationElementsFor(point);
for (int i = 0; i < decls.length; i++) {
IConfigurationElement element = decls[i];
if (elementName.equals(element.getAttribute("name"))) {
try {
return (AbstractVideoDisplay) element
.createExecutableExtension("class"); } catch (CoreException e) { e.printStackTrace(); } } } return null; }
Os métodos abstractos que terão que ser implementados por cada plugin, para estender o VideoViewer são os seguintes.
5.3.1 Logitech QuickCam
A classe VideoDisplay do “com.criticalsoftware.display.video.devices.logitech.quickcam”, implementa os métodos da classe AbstractVideoDisplay, utilizado o JMF para comunicar com a câmara, ver Figura 5.5.
Streaming
O streaming de vídeo é efectuado através da implementação do método abstracto,
public abstract void connect(Composite parent, CameraModel cameraConfiguration);
e os passos seguintes explicam o funcionamento:
1. Criar um DataSource utililizando o MediaLocator correspondente à câmara "vfw://0".
public abstract void connect(Composite parent,
CameraModel cameraConfiguration);
public abstract void capture();
public abstract void record();
public abstract void stopRecord();
public abstract void close();
public abstract void goToPreset(int i);
public abstract void ptz(int p, int t, int z);
public abstract void focus(int f);
public abstract void iris(int i);
public abstract void setPreset();
locator = new MediaLocator("vfw://0");
2. Criar um player com DataSource criado anteriormente.
3. Receber o componente visual do player, que irá ser apresentado no editor.
4. Iniciar o player.
Gravação
A gravação é efectuada através da implementação do método
publicabstractvoid record();
e os passos seguidos são, ver Figura 5.6:
1.
Criar um DataSource utililizando o MediaLocator correspondente à câmara "vfw://0".2. Criar um DataSource com a possibilidade de ser clonavel.
player = Manager.createRealizedPlayer(source);
comp = player.getVisualComponent();
player.start();
locator = new MediaLocator("vfw://0");
source = javax.media.Manager.createDataSource(locator);
source = Manager.createCloneableDataSource(source);
3. Criar um processor com o DataSource anterior, para fazer a gravação,
especificando o tipo de saída.
4. Criar um clone do DataSource.
5. Criar um player com o clone do DataSource original, para fazer streaming.
6. Receber o componente visual.
7. Iniciar o player.
8. Receber o DataSource de saída do processor.
9. Construir um File Writer Datasink, passando-lhe o DataSource de saída.
10. Abrir o ficheiro.
11. Iniciar o Datasink e o processor.
formats[0] = new VideoFormat(VideoFormat.CINEPAK); outputType = new FileTypeDescriptor("video.quicktime");
processor = Manager.createRealizedProcessor(new
ProcessorModel(source, formats, outputType));
filewriter = Manager.createDataSink(source, dest);
source2 = ((SourceCloneable) source).createClone();
player2 = Manager.createRealizedPlayer(source2);
comp = player2.getVisualComponent();
player2.start();
source = processor.getDataOutput();
filewriter = Manager.createDataSink(source, dest);
filewriter.open();
filewriter.start();
5.3.2 Bosch Autodome e Axis 2100
Em relação a estas duas câmaras, que utilizam ActiveX, como já tinha sido referido foi utilizado um widget “Browser”, que faz a apresentação dos conteúdos de uma página HTML, onde os objectos COM são inseridos através do seu progID, da seguinte forma.
O facto das implementações serem idênticas, variando apenas no SDK utilizado, leva-nos a só referir uma delas, tendo sido escolhida a Bosch [20].
Para interagir com a página camera.html da Bosch e da Axis, ver 7Camera.html (com.criticalsoftware.display.video.devices.bosch.autodome), é utilizado o método execute deste widget. Vamos fazer a apresentação de apenas um dos métodos pois o seu funcionamento é idêntico, em anexo segue o código HTML.
Se quisermos fazer gravação de um vídeo vamos implementar o método record(), que invocará o método execute, em que o parâmetro é a chamada a uma função Javascript, contida na página.
1. Criação de um Browser
2. Invocação de uma função
Esta invocação resultará no acesso à função, em que media é o objecto correspondente ao COM object “MediaFileWriter”, que possibilita a gravação de media para o sistema de ficheiros.
<OBJECT CLASSID="clsid:D8DBD7F1-A4F8-4DF1-B05F-568830EC2AF3"ID=media></OBJECT>
browser = new Browser(parent, SWT.EMBEDDED);
browser.setUrl(fileURL.toString());
browser.execute("Record('" + dest + "')");
No caso contrário, para receber dados a partir da página HTML, é necessário associar o resultado de uma função ou o parâmetro a receber, ao HTML DOM status, que é uma propriedade utilizada para verificar o status de uma janela.
E assim utilizando o StatusTextListener do browser, podemos receber o parâmetro pretendido e colocá-lo numa variável interna do widget, definida como “query”.
Seguidamente para aceder ao valor da variável basta invocar.
Assim foram apresentados os aspectos relevantes da implementação.
5.4 Fase 3 – Controlo Pan, Tilt e Zoom
O controlo PTZ da câmara é feito também através do ActiveX, segue em anexo o ficheiro camera.html do plugin correspondente.
O controlo destas funções pode ser efectuado de duas formas, através da view de controlo, onde existem botões para realizar as funções pretendidas, o que permite um controlo total das funções da câmara. Em que para além do pan, tilt e zoom, permite focar a imagem, controlar a abertura do diafragma e predefinir posições da câmara. Estas posições predefinidas, possibilitam ao operador movimentar a câmara rapidamente para áreas que foram definidas por si, como posições de interesse.
O outro método, permite controlar apenas as funções pan, tilt e zoom, através da selecção de áreas do componente de vídeo, ver Figura 5.7. Em que a câmara é movimenta no
function Record(x) { path = x try { media.AddStream(proxy.VideoInputs(1).Stream,2,1,"",deviceUrl,0); media.FileFormat = 1 media.FileSizeLimitKB = 15000000; media.StartRecording(path,"Autodome"); } catch(err) {
txt = "Error Description : " + err.description; alert(txt);
} }
browser.execute("window.status=getValue();");
browser.addStatusTextListener(new StatusTextListener() {
public void changed(StatusTextEvent event) {
browser.setData("query", event.text); }
});
