PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ – PUCPR
CENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
ALEXANDRE FOLLADOR GUEDES
FRANCISCO SIMONATTO LOCATELLI
MONITORAMENTO REMOTO DE IMAGENS COM ADAPTAÇÃO DINÂMICA
DE LARGURA DE BANDA
CURITIBA
2011
ALEXANDRE FOLLADOR GUEDES
FRANCISCO SIMONATTO LOCATELLI
MONITORAMENTO REMOTO DE IMAGENS COM ADAPTAÇÃO DINÂMICA
DE LARGURA DE BANDA
Trabalho
de
conclusão
de
curso
apresentado ao curso de graduação em
engenharia
elétrica,
da
Pontifícia
Universidade Católica do Paraná, como
requisito à obtenção do titulo de
engenheiro eletricista.
Orientador: Prof. Marcelo Eduardo Pellenz
CURITIBA
2011
ALEXANDRE FOLLADOR GUEDES
FRANCISCO SIMONATTO LOCATELLI
MONITORAMENTO REMOTO DE IMAGENS COM ADAPTAÇÃO DINÂMICA
DE LARGURA DE BANDA
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em
Engenharia Elétrica, da Pontifícia Universidade Católica do Paraná, como
requisito à obtenção do título de Engenheiro Eletricista.
COMISSÃO EXAMINADORA
_____________________________________
Prof. Dr. James Baraniuk
Pontifícia Universidade Católica do Paraná
_____________________________________
Prof. Dr. Marcelo Eduardo Pellenz
Pontifícia Universidade Católica do Paraná
_____________________________________
Profa. Msc. Maria Gertrudes Te Vaarwerk
Pontifícia Universidade Católica do Paraná
Curitiba, 06 de Dezembro de 2011.
1
RESUMO
Os sistemas atuais de monitoramento remoto de imagens de vigilância
patrimonial despendem grande quantidade do tráfego e das memórias de
armazenamento para transmitir e salvar imagens redundantes. Apesar de
existirem vários métodos de compressão de vídeo implementados, há
necessidade de reduzir a quantidade de informação desnecessária trafegando
na rede, pois as conexões domésticas são idealizadas para tráfego em rajadas,
ao passo que estes sistemas utilizam tráfego praticamente constante. Este
projeto de conclusão de curso tem como objetivo apresentar uma solução para
este cenário. Utilizando técnicas de processamento de imagens, esse projeto
tem como finalidade desenvolver um sistema autônomo de vigilância
patrimonial capaz de adaptar a largura de banda consumida baseado em
detecção de movimento.
Palavras-chave:
Monitoramento Remoto. Tráfego. Largura de Banda.
Processamento de Imagens. Detecção de Movimento.
2
ABSTRACT
The current patrimonial security remote image monitoring systems spend the
greatest part of traffic and storage memory to save and transmit redundant
images. Despite having several video compression methods implemented, it is
necessary to reduce the amount of unnecessary information that travels through
network, since the domestic internet connections are designed for bursty traffic,
whereas these systems make use of barely constant traffic. This final project
aims to provide a solution for this event. By making use of image processing
techniques, this project intends to develop an autonomous patrimonial vigilance
system able to adapt the consumed bandwidth based in motion detection.
Keywords: Remote Monitoring. Traffic. Bandwidth. Image Processing. Motion
Detection.
3
LISTA DE ABREVEATURAS E SIGLAS
IP
– Internet Protocol.
HTML
– HyperText Markup Language.
JPEG
– Join t Photographic Experts Group.
MJPEG
– Motion Joint Photographic Experts Group.
CFTV
– Circuito Fechado de Televisão.
RIMS
– Remote Image Monitoring System.
VGA
– Video Graphics Array.
LAN
– Local Arena Network.
USB
– Universal Serial Bus.
RGB
– Formato de imagem sem compressão que utiliza informações
de crominância para compor o quadro (Red Green Blue).
YUV
– Formato de imagem codificado com perdas que utiliza
informações de luminância e crominância para compor o quadro.
RAM
– Random Acess Memory.
BIOS
– Basic Input/Output System.
TCP
– Transmission Control Protocol.
DVR
– Digital Video Recorder.
LED
– Light Emittin Diode.
GPIO
– General Purpose Input/Output.
ADC
– Analog to Digital Converter.
EEPROM
– Eletrically-Erasable Programmable Read-Only Memory.
SCCB
– Serial Camera Control Bus.
PNG
– Portable Network Graphics.
4
GIF
– Graphics Interchange Format.
TIFF
– Tagged Image File Format.
DIB
– Device Independent Bitmap.
JFIF
– JPEG File Interchange Format.
5
LISTA DE SÍMBOLOS
kbps -
Kilo bits por segundo.
Mbps -
Mega bits por segundo.
kB
-
Kilo Bytes.
MB
-
Mega Bytes.
GB
-
Giga Bytes.
MHz
-
Mega Hertz.
”
-
Polegada.
Mp
-
Mega Píxel.
6
Sumário
RESUMO ........................................................................................................................................ 1
ABSTRACT ...................................................................................................................................... 2
LISTA DE ABREVEATURAS E SIGLAS ............................................................................................... 3
LISTA DE SÍMBOLOS....................................................................................................................... 5
ÍNCICE DE ILUSTRAÇÕES ..................................................................................................... 8
1.
INTRODUÇÃO .................................................................................................................... 9
2.
DETALHAMENTO DO PROBLEMA............................................................................. 10
2.1.
3.
ANÁLISE DAS SOLUCÕES EXISTENTES ........................................................ 10
FUNDAMENTAÇÃO TEÓRICA ..................................................................................... 11
3.1.
PROCESSAMENTO DE IMAGENS ...................................................................... 11
3.1.1.
COMPRESSÃO .................................................................................................... 11
3.1.2.
QUANTIZAÇÃO ................................................................................................... 12
3.2.
RGB ............................................................................................................................ 13
3.2.1.
3.3.
YUV............................................................................................................................. 15
3.3.1.
3.3.
YUV 420.............................................................................................................. 15
JPEG .......................................................................................................................... 16
3.3.1.
DCT ..................................................................................................................... 17
3.3.2.
QUANTIZAÇÃO ................................................................................................ 17
3.3.3.
ORDENAÇÃO ZIG-ZAG .................................................................................. 18
3.3.4.
CODIFICAÇÃO POR ENTROPIA .................................................................. 18
3.4.
4.
RGB 555 ............................................................................................................. 14
MJPEG ....................................................................................................................... 18
DETALHAMENTO DO PROJETO ................................................................................ 20
4.1.
TECNOLOGIAS UTILIZADAS ............................................................................... 20
4.1.1.
MÓDULO FRIENDLYARM MINI 2440 .......................................................... 20
4.1.2.
MÓDULO DE CAPTURA DE IMAGEM ........................................................ 23
4.2.
AQUISIÇÃO DE IMAGEM ...................................................................................... 27
4.2.1.
CONFIGURAÇÃO DA CÂMARA ................................................................... 27
4.2.2.
FORMAÇÃO DO VETOR IMAGEM ............................................................... 28
4.2.3.
DISPONIBILIZAÇÃO DA IMAGEM ............................................................... 28
4.3.
DETECÇÃO DE MOVIMENTO .............................................................................. 29
4.3.1.
THRESHOLD ..................................................................................................... 29
7
4.3.2.
4.4.
5.
ATUAÇÃO DO DETECTOR DE MOVIMENTO ........................................... 31
COMPRESSÃO DE IMAGEM ................................................................................ 31
4.4.1.
CONVERSÃO RGB – YUV ............................................................................. 32
4.4.2.
COMPRESSÃO JPEG ..................................................................................... 33
4.4.3.
RESULTADO DA COMPRESSÃO ................................................................ 34
4.5.
TRANSMISSÃO DE DADOS ................................................................................. 35
4.6.
FUNCIONAMENTO BÁSICO DO SISTEMA ....................................................... 36
PROCEDIMENTO DE TESTES E VALIDAÇÃO......................................................... 37
5.1.
Cenário 1................................................................................................................... 38
5.2.
Cenário 2................................................................................................................... 40
5.3.
Cenário 3................................................................................................................... 41
5.4.
Cenário 4................................................................................................................... 42
5.5.
Comparativo ............................................................................................................ 43
6.
CONCLUSÃO ................................................................................................................... 44
7.
REFERÊNCIAS ................................................................................................................ 45
ANEXO A – GUIA PASSO A PASSO DE DESENVOLVIMENTO DO SISTEMA ........ 46
8
ÍNCICE DE ILUSTRAÇÕES
Figura 1 – Representação cartesiana do modelo RGB...................................................... 13
Figura 2 – Valores RGB referentes a um pixel. ................................................................... 14
Figura 3 – Diagrama em blocos de um sistema JPEG. ..................................................... 16
Figura 4 – Diagrama em blocos simplificado do sistema. .................................................. 20
Figura 5 – Kit de desenvolvimento FriendlyArm mini 2440. .............................................. 23
Figura 6 – Módulo de captura de imagem CAM130. .......................................................... 24
Figura 7 – Diagrama em blocos funcional do CAM130. ..................................................... 25
Figura 8 – Diagrama temporal de saída de dado da câmara. ........................................... 25
Figura 9 – Diagrama temporal de saída RGB555 do CAM130. ........................................ 26
Figura 10 – Processo de montagem do vetor de diferenças. ............................................ 29
Figura 11 – Equações da Transformada Discreta de Cossenos. ..................................... 33
Figura 12 – Fluxograma de funcionamento do sistema. .................................................... 36
Figura 13 – Tráfego com detecção de movimento para imagem estática. ..................... 38
Figura 14 – Imagem do cenário de testes. ........................................................................... 39
Figura 15 – Teste com movimento e estático variando de 10 em 10 segundos. ........... 40
Figura 16 – Teste com movimento e estático variando de 20 em 20 segundos. ........... 41
Figura 17 - Teste com movimento e estático variando de 30 em 30 segundos. ............ 42
Figura 18 – Comparativo entre os cenários. ........................................................................ 43
9
1. INTRODUÇÃO
A segurança de um patrimônio é sempre algo desejável. Para que seja
feita de forma eficaz, novas tecnologias vêm surgindo em um ritmo bastante
acelerado. Projetos para diversos fins, desde a proteção de um bem, como é o
caso de sistemas de alarme, até a observação remota de um local ou área,
podem ser feitos por meio de circuitos fechados de televisão (CFTV).
Acompanhar o avanço tecnológico e fazer com que novos produtos
estejam acessíveis ao usuário final não é simples. Dessa forma foi proposta
uma maneira de agregar tecnologia e novas soluções para o monitoramento de
imagens. As câmaras IP, como são conhecidas, estão tendo uma procura cada
vez maior para novos projetos de CFTV. Porém, as soluções usuais de
câmaras IP despendem boa parte da largura de banda disponível para o
usuário doméstico na tarefa de transmitir o stream de vídeo. Sendo assim,
propõe-se a criação de um módulo capaz de disponibilizar imagens via rede IP,
disponibilizando tais imagens sempre que houver uma conexão requisitando e
economizando largura de banda quando possível.
Este documento tem como objetivo demonstrar o uso de sistemas de
otimização de largura de banda baseada em detecção de movimento no
monitoramento remoto de imagens com a finalidade de segurança patrimonial.
Ao longo do capítulo 2 é feito o detalhamento do problema e uma
abordagem sobre as soluções existentes atualmente. A fundamentação teórica
essencial para o correto entendimento dos assuntos abordados neste
documento pode ser encontrada no capítulo 3. No capítulo 4 é apresentado o
detalhamento do projeto com suas principais características. O capítulo 5 traz
os procedimentos de teste e validação do projeto juntamente com seus
resultados finais. Finalmente, no capítulo 6, será apresentada a conclusão
deste documento.
10
2. DETALHAMENTO DO PROBLEMA
Um sistema de monitoramento remoto de imagens é uma estrutura
responsável por fornecer ao usuário ou operador de segurança imagens em
tempo real do patrimônio observado, distante do local em questão. Estes
sistemas utilizam conexão com a internet para realizar a transmissão das
imagens capturadas, portanto, há uma demanda crescente por evoluções
tecnológicas na área visando tornar essas tecnologias mais eficientes na
utilização da banda do usuário, visto que as conexões domésticas possuem
baixas taxas de upload. Note que os preços praticados pelas operadoras de
telecomunicações baseiam-se em uma quantidade média de tráfego por
usuário, em rajadas – picos de utilização da banda contratada –, ao longo do
dia com períodos de maior ocupação, gerando ganho estatístico para a
operadora.
2.1. ANÁLISE DAS SOLUCÕES EXISTENTES
Com a disponibilização pelas empresas de telecomunicações de
acessos cada vez mais rápidos à internet, a utilização de tecnologias utilizando
redes de dados em um projeto de CFTV é algo que deve se tornar mais comum
ao longo dos próximos anos. Hoje já é possível encontrar inúmeras soluções
de câmaras IP fabricadas pelos principais fabricantes de eletrônicos mundiais.
As diferenças entre os produtos estão na quantidade de recursos utilizados.
Entre os principais recursos dos equipamentos estão: resolução; taxa de
amostragem; capacidade para integrar vários dispositivos de imagem em um
mesmo módulo; qualidade da lente e disponibilidade de um endereço de DNS
dinâmico, evitando que o usuário tenha que arcar com os custos de possuir um
endereço de IP público fixo.
11
3. FUNDAMENTAÇÃO TEÓRICA
No âmbito do monitoramento remoto de imagens, muito se têm discutido
sobre padrões de compressão temporal, tal como MPEG, H.264, entre outros.
Porém, a maioria dos sistemas de compressão temporal é impraticável em
hardwares embarcados, pois exigem recursos de processamento muito
superiores ao exigido pelo padrão MJPEG1.
3.1. PROCESSAMENTO DE IMAGENS
Segundo Gonzalez
2
, as principais motivações que despertaram
interesse em processamento de imagens foram a melhoria de informação
visual para interpretação humana e o processamento de dados para percepção
de dados por sistemas automáticos. Neste estudo, ambas são consideradas
para obter resultados satisfatórios ao usuário do sistema e para garantir uma
estrutura com aproveitamento dinâmico de consumo de banda de transmissão.
3.1.1. COMPRESSÃO
Um dos principais desafios do processamento de imagens é o grande
volume de dados a serem processados e transmitidos. Desta forma, algumas
atitudes devem ser tomadas de modo a tornar os sistemas viáveis sob todos os
pontos de vista. Como consta em Marques Filho 3 , o termo compressão de
dados representa o processo de reduzir a quantidade de dados necessária
para recompor uma determinada informação. Os métodos de compressão com
perdas consistem em diminuir o tamanho em disco de uma imagem retirando
1
SPIELFOGEL, Jason. Why we like MJPEG compression. Jan, 2011.
GONZALEZ, Rafael; WOODS, Richard. Processamento de Imagens Digitais. 1. ed. São Paulo: Edgard
Blücher LTDA, 2000, p. 1.
3
MARQUES FILHO, Ogê; VIEIRA NETO, Hugo. Processamento Digital de Imagens. 1. ed. Rio de Janeiro:
Brasport, 1999, p. 167.
2
12
informações dessa efetuando uma relação entre redução do tamanho e
qualidade da imagem final. Entre os principais métodos de compressão com
perdas podemos citar PNG; GIF; TIFF; DIB; JFIF e JPEG. Existem formas de
realizar compressão sem perdas, ou o que alguns autores chamam de
compactação. A forma de compressão sem perdas mais popular e eficaz
chama-se Código de Huffman e consiste em codificar trechos de código binário
de acordo com as suas probabilidades de ocorrência. Sua principal
desvantagem é a necessidade de se armazenar e transmitir as tabelas de
símbolos e probabilidades com os dados codificados. Outra grande
desvantagem do Código de Huffman é a dificuldade computacional gerada
quando o número de símbolos a serem codificados é muito grande. Para
abster-se desse empecilho, pode-se utilizar o Código de Huffman Truncado
que consiste em codificar apenas um número de símbolos mais prováveis que
pode ser ajustado de acordo com a capacidade de processamento do sistema.
3.1.2. QUANTIZAÇÃO
Quantização consiste em reduzir os dados de uma determinada imagem
removendo detalhes finos da imagem mapeando grupos de informações e
atribuindo valores iguais para grupos com diferenças pequenas entre si, de
acordo com um valor limiar previamente definido.
13
3.2. RGB
RGB é a abreviatura em inglês para um formato de imagens sem perdas
onde cada pixel é representado por três informações de crominância: Red
(Vermelho); Green (verde); Blue (azul). Esse é um modelo aditivo de cores no
qual as três componentes são combinadas para formar diferentes cores do
espectro. Esta representação pode ser demonstrada por um cubo em um
sistema de coordenadas cartesianas onde três de seus vértices correspondem
às cores primárias do formato, os três vértices opostos ilustram as cores
secundárias, o preto é mostrado junto à origem e em seu vértice oposto está a
representação do branco, formando entre esses dois pontos uma reta
representando a escala de cinza, como pode ser visto na figura 1.
Figura 1 – Representação cartesiana do modelo RGB.
Fonte: Marques Filho, 1999.
14
3.2.1. RGB 555
O RGB555 é um formato de cores de 16 bits onde cada pixel é
representado por dois bytes. O nome 555 deriva do número de bits utilizado
para representar cada uma das três cores. Neste caso, são utilizados 5 bits
para cada cor. Como pode ser visto na figura 2, o bit mais significativo não é
utilizado neste formato, os 5 bits seguintes são ocupados pela informação da
cor vermelha, os próximos 5 bits (os dois menos significativos do primeiro byte
e os três mais significativos do segundo byte) guardam a informação da cor
verde, e os 5 bits menos significativos da palavra recebem a informação da cor
azul.
Figura 2 – Valores RGB referentes a um pixel.
Fonte: Elaboração própria.
15
3.3. YUV
O modelo de representação de imagem com perdas YUV considera as
limitações do olho humano referentes à capacidade de distinguir pequenas
diferenças de crominância. Os componentes da imagem são inicialmente
separados em luminância e crominância para que se possa fazer subamostragem apenas na componente de cor. Os valores de YUV podem ser
calculados utilizando o sinal RGB desta forma:
= 0,299 + 0,587 + 0,114
= −0,147 − 0,289 + 0,436
= 0,615 − 0,515 − 0,100
Estas equações devem ser reduzidas às suas formas mais simples –
conforme mostrado abaixo – quando forem inseridas em sistemas
computacionais a fim de minimizar a quantidade de processamento
utilizada.
= 0,299 + 0,587 + 0,114
= 0,492 − = 0,877 − 3.3.1. YUV 420
Neste formato, cada grupo quadrado de quatro pixels é codificado por
quatro informações de luminância (uma para cada pixel) e duas informações de
crominância. Assim, cada grupo de quatro pixels é representado por 4 bytes de
luminância (Y) e 2 bytes de crominância (U e V), totalizando 6 bytes para cada
4 pixels, gerando uma média de 1,5 byte por pixel, exatamente a metade da
quantidade de informação necessária no sistema RGB. As informações Y, U e
V devem ser armazenadas em forma de vetor. O vetor YUV420 é iniciado por
todos os valores de Y em sequência, seguidos dos valores de U e, por fim, dos
valores de V, todos em ordem crescente de índice. Apesar de dificultar a
16
criação de rotinas de leitura, a forma vetorizada é mais eficiente que a forma
matricial do ponto de vista do acesso à memória.
3.3. JPEG
Este formato de compressão foi desenvolvido para obter resultados
ótimos em imagens naturais semi-contínuas, sem bordas com grandes
diferenças de contraste ou cor. Apesar de existirem versões dessa compressão
sem perdas, o JPEG é, fundamentalmente, uma compressão com perdas
baseado na DCT (Transformada Discreta de Cossenos). Essa técnica explora
as limitações fisiológicas do olho humano, principalmente o fato de as
variações de cor serem menos perceptíveis que as variações de brilho. 4 A
figura 3 ilustra um diagrama em blocos de um sistema de codificação e
decodificação JPEG.
Figura 3 – Diagrama em blocos de um sistema JPEG.
Fonte: Marques Filho, 1999.
4
MARQUES FILHO, Ogê; VIEIRA NETO, Hugo. Processamento Digital de Imagens. 1. ed. Rio de Janeiro:
Brasport, 1999, p. 167.
17
3.3.1. DCT
A DCT (Transformada Discreta de Cossenos) recebe matrizes de 8x8
pixels em formato YUV (Luminância separada da Crominância) e codificará
esses dados de modo a transferi-los do domínio espacial para o domínio de
frequências. Como resultado dessa operação, vários coeficientes terão valores
muito próximos de zero e, posteriormente, serão descartados. Para fins
comparativos, a FFT (Transformada Rápida de Fourrier) possui igual
capacidade de compactação, porém, sua transformada inversa distorce mais
coeficientes que a DCT. Ao final dessa Transformada teremos um componente
DC (Corrente Contínua) e 63 componentes AC (Corrente Alternada) para cada
matriz 8x8, onde o componente DC representa o valor médio de crominância
da matriz, enquanto os componentes AC representam as variações em relação
à este componente DC ao longo da matriz.
3.3.2. QUANTIZAÇÃO
Após a aplicação da DCT, é necessário aproximar ainda mais os valores
dos coeficientes de zero. Neste momento, a matriz originada pela DCT é
dividida pela matriz de quantização, reduzindo ainda mais a magnitude dos
valores dos coeficientes e forçando a aproximarem-se de zero.
18
3.3.3. ORDENAÇÃO ZIG-ZAG
Os 63 componentes AC da matriz de valores são lidos em zig-zag da
esquerda para a direita, de cima para baixo. Assim, os coeficientes de baixa
frequência são armazenados antes dos coeficientes de altas frequências, pois
esses coeficientes de baixa frequência têm menos incidência de valores
próximos de zero. Os valores DC são codificados separadamente através de
técnicas preditivas, pois estes possuem alta correlação com os outros
componentes DC das matrizes adjacentes.
3.3.4. CODIFICAÇÃO POR ENTROPIA
Apesar de não ser mandatório, o algoritmo utilizado normalmente para
essa codificação é o algoritmo de Huffman. Essa codificação não introduz
perdas nos dados, pois apenas atribui códigos para símbolos binários com
grande probabilidade de ocorrência. Quanto maior a ocorrência do símbolo,
menor será o código que o representa. Desta forma, o volume de dados é
diminuído sem que perdas sejam introduzidas.
3.4. MJPEG
O método de compressão MJPEG consiste em um formato de vídeo
onde
cada
imagem é,
individualmente, comprimida em
JPEG
para,
posteriormente, serem organizadas formando uma sequência de imagens,
caracterizando um vídeo. Sua principal vantagem é necessitar baixas
capacidades de processamento em relação aos padrões de compressão
temporais. Por essa característica, esta modulação é amplamente empregada
em dispositivos móveis e em sistemas embarcados. Lamentavelmente, por não
19
haver um padrão estabelecido, o MJPEG foi implementado de formas
diferentes por cada fabricante.
20
4. DETALHAMENTO DO PROJETO
Conforme discutido anteriormente, o sistema desenvolvido deve realizar
a transmissão de imagens de monitoramento com largura de banda adaptativa.
O sistema foi concebido com etapas independentes que realizam suas tarefas
paralelamente às outras, otimizando o consumo de tempo dos processos. O
sistema faz uso de threads e semáforos para garantir solidez no
funcionamento.
Figura 4 – Diagrama em blocos simplificado do sistema.
Fonte: Elaboração Própria.
4.1. TECNOLOGIAS UTILIZADAS
4.1.1. MÓDULO FRIENDLYARM MINI 2440
O módulo adquirido para captura de vídeo, processamento de imagem e
interface é o FriendlyArm mini 2440. Esse foi definido após pesquisa e
comparação com outras soluções existentes. Pelo fato de possuir todas as
interfaces necessárias para a execução do projeto, incluindo uma interface
para uma câmara de captura de vídeo e capacidade de processamento para
21
implementar compressão, mostrou-se a solução que melhor atende aos
requisitos impostos.
Outro fator decisivo para a aceitação do módulo foi a garantia de taxa de
transferência efetiva (throughput) da interface ethernet, pois caso a taxa não
atenda aos mínimos requisitos ocorrerá atraso na transferência dos quadros de
vídeo e perda de pacotes. A perda contínua de quadros pode acarretar em um
mau serviço ofertado.
A configuração do kit também foi fator influente na escolha. Esse é
equipado com:
CPU
• Samsung S3C2440A (ARM920T), 400MHz, max. 533Mhz.
RAM
• 64MByte SDRAM;
• Barramento de 32bit;
• 100MHz Clock.
Flash
• 64MByte or 128MByte Nand Flash;
• 2MB Nor Flash com Bios.
Clock do sistema
• Cristal de 12Mhz;
LCD
• Interface touch screen resistiva de quatro fios;
• STN-Displays;
• Suporte à displays 4bit dual scan, 4bit single scan ou 8bit single scan;
• Monocromáticos, 4 níveis de cinza, 16 níveis de cinza, 256 cores ou
4096 cores;
• Resolução máxima: 1024x768 pixels;
• Display TFT LCD.
Interfaces e recursos
• 1 10/100M Ethernet RJ-45 (DM9000);
• 3 portas seriais (1 RS232);
• 1 USB Host;
• 1 USB Device;
• 1 Interface para cartões SD;
22
• 1 Saída de áudio;
• 1 Entrada de áudio;
• 1 Microfone;
• 4 LEDs;
• 6 Botões programáveis;
• 1 PWM Buzzer;
• 1 Potenciômetro (para testes do ADC);
• 1 EEPROM I2C;
• 1 Real Time Clock com bateria (RTC);
• 1 Interface de 20 pinos para câmara (2.0mm).
Tensão de alimentação
• 5V.
Dimensão
• 10 x 10 cm.
Suporte aos seguintes sistemas operacionais
• Linux 2.6;
• Android;
• Windows CE 5 e 6.
A escolha do Linux como sistema operacional embarcado para a solução
proposta auxiliou no desenvolvimento, visto que esse já possui implementadas
algumas funcionalidades como pilha TCP e comunicação facilitada com
interfaces dedicadas. Outra razão pela escolha deste sistema operacional é a
grande quantidade de literatura disponível e a comunidade mundial de
desenvolvedores em sistemas Open Source. A figura 5 apresenta o kit de
desenvolvimento FriendlyArm mini 2440.
23
Figura 5 – Kit de desenvolvimento FriendlyArm mini 2440.
Fonte: Thai Easy Elec, 2011.
4.1.2. MÓDULO DE CAPTURA DE IMAGEM
O módulo utilizado é o CAM130. Com capacidade para capturar imagens
com uma resolução de até 1,3Mp e instalada em uma placa de circuito
impresso, este recurso possui interface própria para comunicar-se com o Kit
FriendlyArm 2440, facilitando a execução do projeto. Equipado com a câmara
OV9650 do fabricante OmniVision, este equipamento fornece imagens no
formato RGB555. As descrições dos formatos de imagem e métodos utilizados
foram feitas no capítulo 3.
24
Figura 6 – Módulo de captura de imagem CAM130.
Fonte: Elaboração Própria
A programação inicial da câmara é feita através de interface SCCB.
Através dela são configurados os registradores de acordo com as
especificações da imagem que se deseja obter. A figura 7 é referente ao
diagrama em blocos da câmara.
A imagem é fornecida através dos pinos indicados como D[9:0]. Através
dos sinais HREF, PCLK e VSYNC a câmara fornece informações de referência
horizontal, início e fim de pixel e sincronização vertical, respectivamente, para
que o quadro possa ser corretamente montado.
25
Figura 7 – Diagrama em blocos funcional do CAM130.
Fonte: Arm9 Board, 2005.
Para cada início de imagem, o sinal VSYNC é fornecido como 1, sendo
em seguida informado como 0. Com o término da transmissão, o sinal sofre a
mesma alteração, indicando o início da transmissão de um novo quadro.
Figura 8 – Diagrama temporal de saída de dado da câmara.
Fonte: Arm9 Board, 2005
26
Por padrão, o sinal HREF é mantido em 0. Para cara início de linha,
esse é informado como 1, sendo forçado em 0 após o término.
A figura 9 é referente à saída dos dados em RGB. O dado fornecido
segue o padrão informado anteriormente.
Figura 9 – Diagrama temporal de saída RGB555 do CAM130.
Fonte: Arm9 Board, 2005
27
4.2. AQUISIÇÃO DE IMAGEM
Este processo consiste em receber os dados da imagem atual da
câmara CCD, montar em um vetor e disponibilizá-lo para que possa ser
processado, comprimido e transmitido. O procedimento de aquisição de
imagem é autônomo e ocorre de forma independente do restante dos
processos. A única interação entre esta etapa e as posteriores é disponibilizar
o vetor de dados da imagem sempre que essa seja atualizada pela câmara.
4.2.1. CONFIGURAÇÃO DA CÂMARA
Inicialmente, este sistema configura a câmara modificando valores em
seus registradores para controlar o modo de operação desejado. As demandas
submetidas à câmara são:
- Resolução VGA;
- Controle automático de exposição;
- Controle automático de ganho;
- Balanço automático de branco;
- Calibração automática de nível de preto;
- Formato de saída da imagem RGB555;
- Ordem dos bytes da imagem horizontal de cima para baixo.
28
4.2.2. FORMAÇÃO DO VETOR IMAGEM
Após configurar a câmara de acordo com as necessidades do projeto, o
sistema entra em um laço de repetição em que aguarda o dispositivo informar a
existência de uma nova imagem. O período de transmissão de dados de uma
mesma imagem está delimitado entre dois pulsos na saída VSINC. Os dados
são descarregados durante pulsos periódicos da saída HREF. Neste período a
câmara descarrega os dados da imagem, serialmente, em 480 rajadas
contendo informações de 640 pixels, sendo que de cada pixel possui 16 bits de
informação. Esses dados são armazenados em um vetor local e ocupam
614400 posições de um byte cada.
4.2.3. DISPONIBILIZAÇÃO DA IMAGEM
Nesta etapa, o sistema já possui uma imagem salva localmente. O
passo seguinte é disponibilizar globalmente o vetor da imagem para que outras
partes do sistema possam acessar. Para tal, é utilizado um semáforo, pois é
necessário garantir exclusividade temporal no acesso da variável. A utilização
do semáforo garante um sistema capaz de trabalhar com processos
concorrentes evitando dead locks e condições de corrida. Inicialmente é
verificado se o vetor global está livre. Se não estiver, uma nova imagem é
buscada, pois esta parte do sistema é muito mais rápida que as partes
concorrentes (cerca de 15 repetições por segundo). Se o vetor global estiver
livre, seu acesso por outras partes do código é bloqueado temporariamente, os
dados da última imagem recebida são atualizados nele e uma flag é sinalizada
simbolizando a disponibilidade de um novo frame. Em seguida, o acesso ao
vetor global é liberado novamente e o sistema de aquisição de imagem volta ao
início do processo do laço de repetição e aguarda uma nova imagem ser
disponibilizada pela câmara.
29
4.3. DETECÇÃO DE MOVIMENTO
Esta é a principal etapa do projeto por ser fundamental para que o
objetivo final seja cumprido. Essa parte baseia-se em verificar se houve
movimento entre o quadro atual e o anterior para decidir se o quadro atual será
renovado ou se ele é igual ao que já está sendo mostrado ao usuário. Dessa
forma é possível garantir que o tráfego redundante é evitado e que as imagens
de interesse do usuário serão disponibilizadas normalmente.
O início do funcionamento ocorre a partir do instante em que a segunda
imagem captada estiver acessível e o funcionamento sucede de forma
independente enquanto o sistema estiver operando.
4.3.1. THRESHOLD
Para que pudesse ser definido um limiar para separar movimento de
ruído na imagem, foi necessário encontrar um valor de threshold adequado
para essa aplicação. Para tal, um procedimento de teste se mostrou bastante
eficaz. Inicialmente, foi criado um vetor local auxiliar que recebia os valores
absolutos da subtração entre os valores de luminância Y entre a imagem atual
e a anterior, conforme mostrado na figura 10.
Figura 10 – Processo de montagem do vetor de diferenças.
Fonte: Elaboração própria.
30
Após a criação do vetor de diferenças, foi criada uma função para
imprimir esses valores no terminal. Acompanhando esses valores em cenas
estáticas e com movimento, foi possível verificar que uma pequena parcela dos
pixels difere, em valor decimal, mais de 50 quando não há movimento e que
nos locais onde o movimento ocorre esses valores ultrapassam 50. Assim, foi
definido o valor decimal 50 como o threshold que decide que houve variação no
pixel em questão.
Com o primeiro threshold definido, foi realizada a segunda parte dos
testes, que consistiu em varrer novamente os vetores das imagens anterior e
atual, e imprimir no terminal quantos pixels se diferiam em mais de 50.
Observando novamente o sistema operando e imprimindo a quantidade de
pixels que variava em mais de 50 foi possível concluir que apenas o ruído da
imagem era capaz de alterar o valor de luminância de aproximadamente 40000
pixels em mais de 50. Esse valor de 40000 variava sensivelmente de acordo
com a luminosidade do ambiente, sendo menor em ambientes de boa
luminosidade e alto em ambientes de baixa luminosidade. Inserindo movimento
nas cenas e verificando a resposta da quantidade de pixels que variavam, foi
possível atingir o threshold final de 90000 pixels que variam seus valores de Y
em, ao menos, 50. O valor de 90000 significa que além dos 40000 pixels que
variaram na cena, algum movimento fez com que mais 50000 pixels variassem.
O valor 50000 corresponde a aproximadamente 16% da área da imagem, ou
seja, será considerado movimento no quadro se, e somente se, ao menos essa
fração do quadro sofrer variação.
31
4.3.2. ATUAÇÃO DO DETECTOR DE MOVIMENTO
Sendo capaz de detectar movimento na cena, este processo atua como
fator de decisão para as outras partes do projeto. Após receber uma nova
imagem convertida de RGB555 para YUV420 ele a compara com a imagem
anterior, localizada em um vetor buffer local, e verifica se houve movimento. Se
houve movimento, o sistema atribui valor 1 à flag global que autoriza
compressão para que a imagem seja comprimida, codificada e transmitida ao
usuário. Se não houve movimento, ele verifica se faz mais de 60 frames que o
quadro está estático. Se isso for verdadeiro, o processo dá a ordem para
comprimir e enviar uma nova imagem para que o quadro não fique estático por
mais de 60 tempos de frame. Se não houve movimento nem tampouco faz
mais de 60 quadros que não há uma atualização, o sistema finaliza o laço de
repetição e aguarda a próxima atualização de imagem para repetir o processo.
4.4. COMPRESSÃO DE IMAGEM
Devido à necessidade de disponibilizar uma imagem prévia no formato
YUV420, a compressão é dividida em duas partes. Na primeira etapa, é
realizada a conversão da imagem do formato RGB555 para o formato YUV420.
A segunda parte engloba a conversão da imagem para JPEG e é o último
passo antes de realizar a transmissão ao usuário.
32
4.4.1. CONVERSÃO RGB – YUV
Inicialmente, este processo aguarda até que o valor da flag que sinaliza
um novo frame seja igual a 1. Após essa etapa, o vetor global da imagem é
copiado para um vetor local para que seu acesso seja liberado rapidamente e a
flag que sinaliza que há uma nova imagem RGB disponível é zerada. De posse
a imagem capturada, o vetor de imagem RGB é percorrido enquanto os valores
dos coeficientes Y, U e V são calculados de acordo com as seguintes
equações:
= 0,299 + 0,587 + 0,114
= 0,492 − = 0,877 − Como resultado, é obtido um vetor com coeficientes Y, U e V ordenados
em sequência e com todos os valores completos de crominância. Para a
composição do vetor YUV420, o vetor sequenciado é percorrido, com o auxílio
de um vetor buffer local, e os coeficientes são rearranjados de forma a
obedecer ao padrão do sistema YUV. Após a adequação inicial, o vetor YUV é
percorrido novamente e os coeficientes de crominância são sub-amostrados na
relação de 4:1, ou seja, cada quadrado de 2x2 pixels terá apenas uma
informação de crominância U e uma informação de crominância V. Para
realizar essa sub-amostragem, primeiramente é necessário somar 128 a cada
valor de crominância para que não existam valores negativos. Após as somas,
os valores de U são somados entre cada grupo de quatro pixels e uma média é
retirada como sub-amostragem de cor U. O mesmo ocorre para os valores de
V. Desta forma o vetor está pronto no formado YUV420, pois existe uma
amostra de luminância Y para cada pixel e duas amostras de crominância para
cada grupo de quatro pixels. O vetor local YUV420 é atribuído a um vetor
global e é atribuído o valor 1 ao flag que indica que uma nova imagem do tipo
YUV está disponível. Desta forma, o sistema de detecção de movimento irá
buscar a imagem nova para poder comparar com a anterior.
33
4.4.2. COMPRESSÃO JPEG
Esta etapa do sistema ocorrerá após a parte de detecção de movimento
atribuir valor 1 à flag que autoriza que a imagem seja comprimida. O
compressor irá copiar o conteúdo do vetor global com a imagem YUV420 para
um vetor local para que possa ser realizada a compressão.
4.4.2.1.
DCT
Para que a transformada discreta de cossenos seja feita, a imagem é
dividida em blocos de 8x8 pixels para facilitar o processamento e produzir
melhores resultados. A DCT irá deslocar os valores dos coeficientes do
domínio do tempo para o domínio da frequência de acordo com a equação
mostrada na figura 11.
Figura 11 – Equações da Transformada Discreta de Cossenos.
Fonte: Marques Filho, 1999.
Como resultado dessas operações, os componentes mais significativos
para a formação da imagem são dispostos no início do vetor, sendo que o
primeiro valor é chamado de componente DC e possui grande parte da
informação relevante para a imagem. Após a DCT, os resultados são entregues
ao quantizador.
34
4.4.2.2.
QUANTIZAÇÃO
Nesse processo, os coeficientes da imagem são divididos pela matriz
(vetor) de quantização do JPEG, forçando os termos a adquirirem valores ainda
mais próximos de zero, para que possam ser eliminados posteriormente.
4.4.2.3.
ORDENAÇÃO ZIG-ZAG
Os coeficientes dos vetores quantizados são rearranjados como se
tivessem sido alocados em uma matriz e lidos em zig-zag. Dessa forma, é
garantido que os valores maiores e mais significativos fiquem agrupados no
início do vetor e que os valores próximos e iguais a zero fiquem na parte final
para que o codificador por entropia possa ser mais efetivo.
4.4.2.4.
CODIFICAÇÃO POR ENTROPIA
Nesta etapa, o codificador de Huffman codifica os coeficientes
resultantes mapeando os símbolos gerados e codificando-os de acordo com a
probabilidade de ocorrência. Quanto maior a probabilidade de ocorrência do
símbolo, menor deve ser o código que o representa.
4.4.3. RESULTADO DA COMPRESSÃO
Ao final do processo de compressão, é entregue como resultado um
arquivo de extensão .jpeg e é atribuído valor 1 à flag que indica ao sistema de
transmissão que há uma imagem nova para ser transmitida.
35
4.5. TRANSMISSÃO DE DADOS
A disponibilização dos dados processados é feita através de interface
web. Esse sistema aguarda o compressor informar que existe uma nova
imagem para ser enviada. O módulo de transmissão entrega para o servidor
httpd (já contido na distribuição Linux utilizada) a imagem comprimida e esse
aguarda a requisição de transmissão, feita através de conexão TCP. Na
camada de aplicação, a imagem é carregada com a utilização da string <img
src="/?action=stream">. Essa string informa ao servidor que a imagem que
deve ser carregada é o stream de JPG. Ao final da transmissão, a flag de nova
imagem do sistema de compressão é zerada e o transmissor retorna ao estado
inicial onde aguarda uma nova imagem.
36
4.6. FUNCIONAMENTO BÁSICO DO SISTEMA
A figura 7 ilustra de forma simplificada o funcionamento de todas as
partes do sistema. Inicialmente são configurados alguns parâmetros de rede e
formato de imagem da câmara. Em seguida, a imagem é recebida da câmara e
entregue para que o compressor realize a conversão para o padrão YUV420. A
imagem convertida é analisada pelo sistema de detecção de movimento. Se
houver movimento ou se a cena permanece estática por mais de 60 frames
(aproximadamente 20 segundos) a imagem é entregue ao compressor para
que esse realize a compressão no formato JPEG. Após a compressão o
sistema atualiza a imagem e a disponibiliza para o usuário.
Figura 12 – Fluxograma de funcionamento do sistema.
Fonte: Elaboração própria.
37
5. PROCEDIMENTO DE TESTES E VALIDAÇÃO
Para os testes definiu-se um cenário onde era provocado movimento na
cena em intervalos periódicos. Inicialmente foi utilizado o streaming contínuo,
sem detecção de movimento, para obter a quantidade total de tráfego em um
intervalo de 10 minutos. A imagem permaneceu estática. O valor médio obtido
da imagem foi de 22870,16 bytes e o tráfego total durante o período proposto
foi de 41166296 bytes, ou 39,259 MB.
Cenário 1
Cenário 2
Cenário 3
Cenário 4
Duração do movimento
0 segundos
10 segundos
20 segundos
30 segundos
Tempo de pausa
10 minutos
10 segundos
20 segundos
30 segundos
Tabela 1 – Resumo dos cenários de testes.
Tempo total
10 minutos
10 minutos
10 minutos
10 minutos
38
5.1. Cenário 1
O segundo experimento foi feito com o algoritmo de detecção de
movimento ativo, porém mantendo a imagem estática. O gráfico mostrado na
figura 13 representa o tráfego durante essa etapa.
Taxa de transmissão(bytes) x Tempo(s)
25000
20000
15000
Tráfego
10000
5000
1
21
41
61
81
101
121
141
161
181
201
221
241
261
281
301
321
341
361
381
401
421
441
461
481
501
521
541
561
581
0
Figura 13 – Tráfego com detecção de movimento para imagem estática.
Fonte: Elaboração própria.
Conforme citado anteriormente, é feita a atualização da imagem estática
amostrada a cada 20 segundos. Desta forma, obtiveram-se 31 imagens no
intervalo de 10 minutos. O valor médio obtido das imagens foi de 22731,55
bytes e o tráfego total foi de 704678 bytes, ou 688,162 kB, sendo observada
uma diferença considerável no consumo da banda.
39
Figura 14 – Imagem do cenário de testes.
Fonte: Elaboração própria.
Na figura 14 pode-se observar uma imagem estática do cenário de
testes retirada durante um dos testes. O movimento é provocado por uma
locomotiva em escala de um ferrorama. Para facilitar as medidas corretas de
tempo, em cada uma das extremidades dos trilhos que aparecem na figuras 14
foram inseridos trilhos reversores de movimento, tornando o movimento fluido e
contínuo durante o tempo necessário. Para evitar interferências externas
durante os testes, esses foram realizados no período da noite, em um ambiente
fechado apenas com iluminação artificial constante.
40
5.2. Cenário 2
No próximo cenário de teste, provocou-se movimento na cena durante
dez segundos, permanecendo, em seguida, estática por outros dez, durante
dez minutos. O gráfico da figura 15 representa o tráfego em função do tempo.
Taxa de transmissão(bytes) x Tempo(s)
80000
70000
60000
50000
40000
Tráfego
30000
20000
10000
1
21
41
61
81
101
121
141
161
181
201
221
241
261
281
301
321
341
361
381
401
421
441
461
481
501
521
541
561
581
0
Figura 15 – Teste com movimento e estático variando de 10 em 10 segundos.
Fonte: Elaboração própria.
Essas alterações geraram uma taxa média de trinta frames. A média das
imagens com movimento foi de 22972,33 bytes. A quantidade média de tráfego
gerado por movimento foi de 688930,35 bytes e o tráfego total foi de 20675100
bytes, ou 19,717 MB em 10 minutos.
41
5.3. Cenário 3
O cenário seguinte foi composto por movimentos durante vinte segundos
seguidos de outros vinte de imagem estática, durante um período de 10
minutos. A taxa média de imagens geradas durante o movimento foi de 60
frames, e a média do tamanho das mesmas foi de 22895,92 bytes. A
quantidade média de tráfego gerado por movimento foi de 1405631,62 bytes e
o tráfego total foi de 20939628 bytes, ou 19,969 MB em 10 minutos e pode ser
observada no gráfico na figura 10.
Taxa de transmissão(bytes) x Tempo(s)
80000
70000
60000
50000
40000
Tráfego
30000
20000
10000
1
29
57
85
113
141
169
197
225
253
281
309
337
365
393
421
449
477
505
533
561
589
0
Figura 16 – Teste com movimento e estático variando de 20 em 20 segundos.
Fonte: Elaboração própria.
42
5.4. Cenário 4
Por fim, gerou-se movimento durante trinta segundos, mantendo a cena
estática por outros trinta, durante dez minutos. As cenas com movimento
tiveram, em média, 90 frames com tamanho médio de 22905,82 bytes. O
tráfego médio observado por movimento foi de 2074426,45 bytes e o tráfego
total foi de 21073171 bytes, ou 20,097 MB. O gráfico mostrado na figura 11 é
referente ao tráfego observado em 10 minutos.
Taxa de transmissão(bytes) x Tempo(s)
80000
70000
60000
50000
40000
Tráfego
30000
20000
10000
1
31
61
91
121
151
181
211
241
271
301
331
361
391
421
451
481
511
541
571
601
631
0
Figura 17 - Teste com movimento e estático variando de 30 em 30 segundos.
Fonte: Elaboração própria.
É importante ressaltar que os picos observados durante o período de
imagem estática ocorrem devido a atualização periódica (20 segundos) da
imagem mostrada quando não há detecção de movimento.
43
5.5. Comparativo
O cenário ideal desta proposta – vigilância patrimonial - pressupõe
menos ocorrência de movimento que os cenários cinéticos testados nesse
sistema. Para um cenário ideal, supõe-se um volume de tráfego mais próximo
do adquirido no estático. Porém, mesmo para cenários com 50% de
movimento, obtivemos ganho de aproximadamente 50% em efetividade.
O gráfico apresentado informa o valor percentual da banda utilizada em cada
um dos experimentos, tendo como referência o valor total trafegado quando o
algoritmo de detecção de movimento não está ativo.
60,00%
50,22%
50,87%
51,19%
10 segundo
20 segundos
30 segundos
50,00%
40,00%
30,00%
20,00%
10,00%
1,71%
0,00%
Estático
Figura 18 – Comparativo entre os cenários.
Fonte: Elaboração Própria.
44
6. CONCLUSÃO
A proposta do projeto foi criar um sistema de streaming de vídeo que
fosse inteligente do ponto de vista da rede, ou seja, que economizasse a banda
contratada do usuário evitando transmissões de informações redundantes.
Durante o desenvolvimento do projeto algumas formas de atingir o
objetivo proposto foram testadas (redução da imagem, aumento na taxa de
compressão do JPEG), porém mostraram-se inviáveis devido limitação do
hardware utilizado (capacidade de processamento). A solução encontrada, e
que posteriormente mostrou-se bastante eficiente, foi a diminuição da
quantidade de quadros mostrados.
A comparação com os resultados de tráfego obtidos sem o algoritmo
implementado e com a solução proposta indicou um ganho estatístico de banda
de até 98,39% no melhor caso (imagem estática durante todo o tempo) e
48,81% no pior dos casos (perturbações periódicas de 30 segundos e imagem
estática por outros 30), validando o projeto e tendo os resultados obtidos como
satisfatórios.
Em projetos futuros, pode-se utilizar um hardware dedicado ao
processamento de sinais e câmara de melhor qualidade (baixo ruído e maior
velocidade de frames adquiridos), de forma a aprimorar os resultados já
obtidos.
45
7. REFERÊNCIAS
GONZALEZ, Rafael; WOODS, Richard. Processamento de Imagens Digitais.
1. ed. São Paulo: Edgard Blücher LTDA, 2000.
SPIELFOGEL, Jason. Why we like MJPEG compression. Disponível em :
<http://ipsecuritywatch.com/web/online/IPSW-Columns-and-Features/Why-welike-MJPEG-compression/515$14335>. Acesso em: 29 de novembro de 2011.
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ. Sistema Integrado de
Bibliotecas. Manual de normas para trabalhos técnico-científicos: de acordo
com as normas da ABNT. 2010. Disponível em: <www.pucpr.br/biblioteca>.
Acesso em: 3 de dezembro de 2011.
MARQUES FILHO, Ogê; VIEIRA NETO, Hugo. Processamento Digital de
Imagens. 1. ed. Rio de Janeiro: Brasport, 1999.
CHRISTOPOULOS, Charilaos et al. THE JPEG2000 STILL IMAGE CODING
SYSTEM: AN OVERVIEW. IEEE, 2000, 25pp. Disponível em:
<http://pessoal.utfpr.edu.br/hvieir/download/pdi99.pdf>. Acesso em: 29 de
novembro de 2011.
THE JPEG COMMITTEE. Disponível em: <http://www.jpeg.org/>. Acesso em:
29 de novembro de 2011.
46
ANEXO A – GUIA PASSO A PASSO DE DESENVOLVIMENTO DO SISTEMA
Esse guia se propõe a ilustrar de uma forma simplificada as etapas a
serem cumpridas para construção de um sistema de monitoramento de
imagens com detecção de movimento e adaptação dinâmica de largura de
banda, similar ao descrito neste documento. O texto abaixo leva em conta que
o leitor desse documento reproduzirá os procedimentos descritos utilizando
exatamente as mesmas ferramentas de software e hardware para garantir os
mesmos resultados.
Para atingir esses objetivos, os seguintes itens são indispensáveis:
•
Kit FriendlyArm mini2440 com distribuição Linux Qtopia;
•
Câmara modelo CAM130;
•
Compilador
GCC
para
arquitetura
ARM.
(Disponível
em
http://code.google.com/p/princess-alist/downloads/detail?name=armlinux-gcc-4.3.2.tgz&can=2&q=);
•
Computador com SO Linux de qualquer distribuição;
•
Software cliente FTP Filezilla ou similar;
•
Software editor de texto, preferencialmente os que reconhecem
comandos em linguagem C, como o Gedit.
PASSO 1
Baixar e instalar na distribuição linux os softwares Filezilla, Gedit e Arm
Linux GCC. Em caso de dificuldades nesse processo, consultar o site
http://www.vivaolinux.com.br/artigo/Como-instalar-programas-no-Linux.
PASSO 2
Configurar um IP pertencente à rede local do seu computador no kit
FriendlyArm. Esse processo é feito através do software Network Configurations
presente na distribuição Qtopia. Após a configuração, conectar o kit ao roteador
47
através de um cabo UTP padrão crossover e testar a conectividade do PC com
o Kit.
PASSO 3
Para realizar a interface com a câmara, deve ser utilizada a biblioteca
videodev.h (#include <linux/videodev.h>). Essa biblioteca realiza a interface
com o hardware, possibilitando a criação de rotinas de escrita e leitura na
câmara. Desta forma, deve-se configurar os registradores da mesma para que
ela trabalhe de acordo com as necessidades do sistema. O datasheet deve ser
consultado para verificar a configuração mais adequada para cada aplicação.
A imagem capturada deve ser alocada em um vetor global, permitindo
que possa ser acessada - após o término da execução da função - por
qualquer parte do código.
PASSO 4
De posse da imagem, é necessário que uma rotina para detecção de
movimento seja escrita. O trecho de código abaixo é um exemplo de
implementação. Para alterar o threshold basta modificar o valor atribuído às
variáveis mov_threshold e pix_threshold. Os valores deverão ser tão grandes
quanto for baixa a luminosidade do cenário.
//Valor limite de pixels que variaram na cena para considerar movimento
int mov_threshold = 90000;
//Diferença mínima entre 2 píxels de mesma posição para considerar que houve variação no
pixel
int pix_threshold = 50;
//Detector de movimento
for (count = 0; count < size && diff_count < mov_threshold; count++) {
delta_mov =
abs(old_frame[count] - vd->pFramebuffer[count]);
if (delta_mov >= pix_threshold) {
diff_count++;
}
}
48
//Verdadeiro se não houver movimento
if (diff_count != mov_threshold && frames_count < 60) {
frames_count++; //Incrementa o contador de frames estáticos em sequência.
send_frame = 0; //Bloqueia o envio do frame. Um novo frame será aguardado.
}
else{//Verdadeiro se houver movimento ou se frames_count >=60
send_frame = 1; //Permite que o frame atual seja transmitido
frames_count = 0; //Zera o contador de frames estáticos em sequência.
}
//Atribuindo a imagem nova à old_frame para que possa comparar com o frame
seguinte
memcpy((unsigned char *)old_frame,
(unsigned char *)vd->pFramebuffer, vd->framesizeIn);
PASSO 4
Nesta etapa ocorre a compressão da imagem caso tenha sido detectado
movimento. Para tal, existem várias bibliotecas disponíveis e o desenvolvedor
pode escolher a que melhor atenda às necessidades do projeto. Cabe ao
programador realizar as chamadas das funções de forma adequada,
entregando os parâmetros necessários corretamente. Um arquivo no formato
JPEG deverá ser o resultado final da compressão. Posteriormente, este arquivo
será disponibilizado ao servidor HTTPD para que o stream seja realizado.
PASSO 5
Na camada de aplicação, o stream é visualizado utilizando o comando
<img src="/?action=stream">. Trata-se de uma tag HTML que invoca uma
imagem no servidor, nesse caso uma atualização sequente de forma que seja
observada no modelo de um vídeo.
Para acessar a página do stream, basta que o usuário digite o IP
previamente configurado no Kit seguido da porta utilizada e do nome da página
criada. Exemplo: 192.168.0.230:8080/stream.html.
49
PASSO 6
Após a compilação, será criado um arquivo executável. Para transferir o
arquivo ao Kit utiliza-se um cliente FTP como o Filezilla. O arquivo deve ser
colocado em uma pasta de preferência do programador e executado a partir da
mesma no terminal com o comando ./nome_do_arquivo.
PASSO 7
A medição da banda consumida pode ser feita através de aplicativos
diversos. A utilização do Wireshark é recomendada para que sejam observados
o tráfego e sinalização gerados pelo sistema. Em caso de haver necessidade
de troubleshooting, a visualização de um possível erro pode ser feita
facilmente.