Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ
ESCOLA POLITÉCNICA
CURSO DE ENGENHARIA DE COMPUTAÇÃO
FELIPE SALES DE FRANÇA
RENAN LOCATIZ FERNANDES
PROJETO FÍSICO REVISADO
ICU – CÂMERA FULLDOME
_____________________________________
Prof. Afonso F. Miguel
CURITIBA
2013
FELIPE SALES DE FRANÇA
RENAN LOCATIZ FERNANDES
PROJETO FÍSICO REVISADO
ICU – CÂMERA FULLDOME
Projeto Físico Revisado do Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Engenharia de Computação da Pontifícia Universidade Católica do Paraná. Orientador: Afonso F. Miguel.
CURITIBA
2013
SUMÁRIO
Histórico de Revisão........................................................................................... 6
RESUMO .............................................................................................................. 7
1. INTRODUÇÃO ............................................................................................ 8
2. DETALHAMENTO DO PROBLEMA .......................................................... 9
2.1 PREÇO .......................................................................................................... 9
3. DETALHAMENTO DO PROJETO ............................................................ 11
3.1 HARDWARE ................................................................................................. 12
3.1.1 Raspberry PI ............................................................................................. 12
3.1.2 HUB USB .................................................................................................. 14
3.1.3 Webcams .................................................................................................. 14
3.1.4 PCI Trigger ............................................................................................... 14
3.1.5 Mídia Removível ....................................................................................... 16
3.1.6 Cabo para alimentação do projeto ......................................................... 16
3.2 SOFTWARE .................................................................................................. 17
3.2.1 Iniciar projeto ........................................................................................... 17
3.2.2 Capturar Imagens .................................................................................... 19
4. CRONOGRAMA ....................................................................................... 23
5. PROCEDIMENTO DE TESTE DE VALIDAÇÃO ...................................... 25
5.1. TESTES DE CAIXA BRANCA ...................................................................... 25
5.1.1. Alimentação do sistema ...................................................................... 25
5.1.2. Permissões de leitura e escrita .......................................................... 26
5.1.3. Alinhamento da estrutura que suporta as câmeras ......................... 26
5.1.4. Sincronia na captura das fotos .......................................................... 27
5.1.5. Desempenho do Raspberry PI ............................................................ 27
5.2. TESTES DE CAIXA PRETA ......................................................................... 28
6. problemas apresentados e suas soluções ........................................... 30
7. ANALISE DE RICOS ................................................................................ 32
8. CONCLUSÃO ........................................................................................... 36
9. REFERÊNCIAS BIBLIOGRÁFICAS ......................................................... 37
LISTA DE FIGURAS
Figura 1 – Interação dos componentes do projeto: ................................................... 11
Figura 2 – Esquemático dos pinos de I/O do Raspberry PI e sua localização: ......... 12
Figura 3 – Circuito PCI-Trigger: ................................................................................. 14
Figura 4 – Fluxograma primeira etapa: ..................................................................... 16
Figura 5 – Pseudocódigo primeira etapa: .................................................................. 17
Figura 6 – Fluxograma segunda etapa: ..................................................................... 18
Figura 7 – Pseudocódigo segunda etapa: ................................................................. 19
Figura 8 – Cronograma atualizado parte I: ................................................................ 21
Figura 9 – Cronograma atualizado parte II: ............................................................... 22
LISTA DE TABELAS
RIS001 – Saída de algum integrante do grupo de projeto final .......................... 27
RIS002 – Não conclusão do projeto até a data prevista da defesa ................... 27
RIS003 – Danificar equipamentos durante a implementação do projeto ............ 27
RIS004 – Prover imagens com má qualidade .................................................... 28
RIS005 – Adquirir peças com defeito ................................................................. 28
RIS006 – Mau desempenho do Raspberry Pi .................................................... 28
RIS007 – Capturas dessincronizadas ................................................................ 29
RIS008 – Falhas na utilização do HUB USB ...................................................... 29
RIS009 – Processo não liberar buffer..................................................................29
Histórico de Revisão
Data Versão Descrição Autor
05/out/2103 2.0.1 Atualização no diagrama da placa trigger. Felipe
12/out/2103 2.0.2 Atualização nos planos de testes. Felipe
12/out/2103 2.0.3 Adição dos resultados ao plano de testes. Renan
17/out/2103 2.0.4 Adição da tabela de problemas
encontrados, capitulo 6.
Felipe
20/out/2103 2.1.1 Atualização na tabela dos problemas
encontrados.
Renan
28/out/2103 2.1.2 Atualização nos capítulos 4 e 5. Renan
28/out/2103 2.1.3 Atualização no item 3.2.1. Felipe
05/nov/2103 2.2.1 Atualização no capitulo 5. Felipe
10/nov/2103 2.2.2 Atualização no capitulo 7. Renan
RESUMO
O projeto tem por finalidade criar um dispositivo capaz de capturar imagens em um
ângulo de 360º na horizontal para depois, em um outro projeto, serem transformadas
em uma única foto, técnica conhecido por panorama que tem sido usada cada vez
mais nos últimos anos.
No mercado é possível encontrar apenas um fabricante que fornece esse tipo de
produto. Sem qualquer tipo de concorrência, a empresa Point Grey pode cobrar por
sua câmera especial o valor que desejar, naturalmente um valor muito alto. Por isso
neste projeto pretende-se construir um conjunto de câmeras capaz de fazer capturas
sincronizadas e salvar em uma única mídia. O projeto será orientado pelo professor
Afonso Ferreira Miguel, que é professor de diversas matérias do curso e também o
diretor. Com um vasto conhecimento e experiência na área de microcomputadores,
microprocessadores e micro controladores é o mais indicado no corpo docente da
universidade para exercer a função de orientação.
8
1. INTRODUÇÃO
Com a construção do FTD Digital Arena, localizado nas dependências da
Pontifícia Universidade Católica do Paraná (PUCPR) tem sido investido em
pesquisas para aplicar esta tecnologia. O FTD Digital Arena trata-se de um teatro
digital, junção de planetário com cinema estereoscópico (3D) com capacidade de
projetar imagens de uma maneira diferente. A ideia inicial do projeto ICU-Câmera
Fulldome partiu do professor Luiz Pavão, que como idealizador do FTD Digital Arena,
tem interesse por uma câmera capaz de criar imagens 360° poder ser desfrutada por
esta estrutura da universidade. Visando isto será construído um suporte capaz de
sustentar seis câmeras e seu computador.
Outras aplicações também podem se beneficiar deste projeto como as fotos
panorâmicas, aonde o usuário visualiza uma foto 360° como se estivesse no centro
da mesma. Para criar este tipo de foto é exigido do fotógrafo uma grande precisão
de posicionamento da câmera para evitar borrões e inconsistências durante a junção
das imagens.
Através de um botão as seis câmeras deverão ser disparadas simultaneamente
e de forma automática as imagens serão armazenadas em um mídia e agrupadas
para serem exportadas e processadas futuramente.
No decorrer deste documento será discutido o detalhamento do problema no
capítulo 2 e no capítulo 3 o detalhamento completo do projeto, incluindo todos os
seus componentes de hardware e software. Depois disso teremos nos capítulo 4, 5
e 6 respectivamente o cronograma do projeto atualizado, os procedimentos de testes
de validação e as novas análises de risco. Por fim, no capítulo 7 uma breve conclusão
deste documento seguido das referências bibliográficas, capitulo 8.
9
2. DETALHAMENTO DO PROBLEMA
O projeto ICU-Câmera Fulldome tem como finalidade, além de demonstrar os
conhecimentos adquiridos no decorrer do curso em prática, construir uma câmera
mais simples porém com um custo de aproximadamente 6% do valor das disponíveis
no mercado. Além do preço há outros problemas que devem ser considerados.
2.1 PREÇO
Uma câmera capaz de tirar fotos 360° por 180° já existe, a empresa Point Grey®
construiu uma câmera com estas características, e têm lançado várias versões desta.
A Ladybug 2 custa em média US$7.000,00 segundo alguns clientes[1], pois a empresa
não divulga o preço do produto abertamente. Um preço como este acaba afastando
interessados e entusiastas por este tipo de fotos panorâmicas, pois poucos tem uma
quantia de dinheiro como esta e estão dispostos a gastar em algo como uma câmera.
A ICU-Câmera Fulldome pode não possuir todas as funcionalidades da câmera da
Point Grey, mas em compensação os gastos planejados para o desenvolvimento do
projeto não deve passar de 6% do valor da Ladybug 2.
Estima-se que desconsiderando custos como de mão de obra, e energia elétrica
durante a implementação do projeto, ou seja, apenas levando em conta com os gastos
em materiais que compõe a ICU-Câmera Fulldome totalize em aproximadamente
quatrocentos dólares. Os preços dos materiais a serem utilizados estão listados
abaixo e em dólares:
6 x Webcam Logitech C615 ~= $ 240,00 ($40,00 cada unidade)
1 x Raspberry Pi 2.0 Model B 512Mb ~= $ 46,00
1 x 7 Port USB 2.0 High-Speed HUB Powered ~= $7,00
1 x LED verde ~= $0,05
1 x LED vermelho ~= $0,05
1 x Push Button ~= $0,20
2 x Resistor 330 Ω ~= $0,05
1x Buzzer comum ~= $0,20
10
1 x Estrutura de acrílico do projeto ~= $100,00
Placa de Circuito Impresso 5x5cm ~= $ 1,00
2.2 DEPENDÊNCIA DE UM COMPUTADOR PRESENTE
Outra característica da maioria das câmeras capazes de capturar fotos 360° por
180° é que precisam estar conectadas a um computador de uso geral com o software
da câmera instalado. Além disso, geralmente só é oferecido pelos fabricantes
suporte para Windows. Dificultando a utilização em computadores que utilizem
sistemas operacionais baseados em Unix como Mac OS e Linux. Sem falar do
incômodo de ter que carregar sempre junto à câmera um computador, mesmo que
seja dos menores notebooks atuais do mercado.
2.3 POSICIONAMENTO PARA A CAPTURA DAS IMAGENS
Quando pretende-se captar imagens panorâmicas utilizando apenas uma
câmera, o fotógrafo deve ter uma noção de espaço e precisão muito boa. Alguns
amadores acabam tendo dificuldade na hora da costura das imagens devido à
defasagem entre as mesmas.
11
3. DETALHAMENTO DO PROJETO
A ICU-Câmera Fulldome foi projetada para ser um corpo único, ou seja, nenhum
módulo externo além da própria estrutura que envolva todos os componentes
discutidos no capítulo anterior. Para que todas as seis Webcams sejam alimentadas
e o microcomputador Raspberry PI consiga reconhece-las ocupando apenas uma
porta USB, aquelas serão ligadas a um HUB com alimentação própria capaz de
sustentar as seis câmeras de alimentação e que possibilite a integração das mesmas
com o Raspberry PI. Enquanto que na segunda porta USB fornecida pelo
microcomputador fica reservada apenas para o Pen Drive em que as fotos serão
armazenadas. Testes já foram realizados com até três Webcams simultaneamente na
mesma porta USB utilizando um HUB alimentado e os resultados foram melhores que
o esperado, atendendo os requisitos para o funcionamento integral do projeto.
A sequência de disparos da ICU-Câmera Fulldome será iniciada através de um
Push Button, o qual faz parte de uma placa de circuito impresso, chamada de PCI
Trigger, que será ligada aos pinos de I/O do microcomputador.
Por fim, tanto o Raspberry quanto o HUB precisarão de uma fonte dedicada cada
um, mas para a comodidade do usuário, estas fontes estarão localizadas no interior
da estrutura do projeto e ligadas em paralelo, e apenas um simples cabo de
alimentação será externo para a conexão com a rede elétrica.
Na figura 1 pode-se visualizar o diagrama de blocos que representa a interação
entre os componentes do projeto.
12
Figura 1 – Interação dos componentes do projeto
3.1 HARDWARE
3.1.1 Raspberry PI
O Raspberry PI é o principal componente do projeto, pois será sobre ele que
todo o resto será implementado. O modelo a ser utilizado é o Raspberry Pi 2.0 Model
B 512MB ARM11 Linux System Development Board Kit, que conta com duas portas
13
USB 2.0, uma porta ethernet, saída HDMI, saída RCA e 512 MB de memória RAM.
Seu armazenamento local é feito através de um cartão SD, onde está instalado o
sistema operacional e todos os outros arquivos necessários para o projeto. Seu
processador é um Broadcom BCM2835 700MHz ARM1176JZFS, com um tamanho
reduzido porém com grande poder de processamento. Alimentado com 5 Vcc, até
carregadores de smartphones com plug micro-USB podem ser utilizados.
Este microcomputador, além de todos os componentes mais comuns
encontrados nos diversos tipos de computadores sejam eles desktops ou notebooks,
possui portas para a comunicação via sinais digitas, portas de I/O. Para este projeto
é fundamental o conhecimento da utilização de maneira correta destas portas, pois o
Raspberry é muito sensível a variações de tensão e corrente portanto muito
susceptível a danos ao seus componentes internos. Abaixo podemos ver um
esquemático obtido no website[1] da Universidade de Cambridge mostrando tanto a
ordem, nome e numeração dos pinos GPIO bem como aonde eles estão localizados
no corpo do Raspberry PI.
Figura 2 – Esquemático dos pinos de I/O do Raspberry PI e sua localização
14
3.1.2 HUB USB
Um total de seis Webcams serão utilizadas para capturar as fotos, porém como
visto no item anterior, o Raspberry PI possui apenas duas portas USB sendo que uma
delas será reservada apenas para o Pen Drive para aonde serão exportadas as fotos
uma vez processadas. Portanto há a necessidade de um HUB USB capaz de suportar
seis Webcams ao mesmo tempo, com velocidade de resposta alta e com corrente
suficiente para manter todas as câmeras ligadas 100% do tempo. O HUB a ser
utilizado é o 7 Port USB 2.0 High-Speed HUB Powered, que nos fórum dedicados à
projetos com Raspberry PI [2], fora recomendado o uso pois consegue controlar até
sete dispositivos simultaneamente sem permitir que algum deles perca conexão com
o computador em questão, seja por alimentação ou sincronia. Como o Raspberry
fornece no máximo 140mA em cada porta USB seria impossível conectar seis
câmeras à um HUB sem alimentação dedicada e obter um comportamento aceitável
das mesmas, por isso o HUB em questão está muito bem adequado aos requisitos.
3.1.3 Webcams
É fundamental para o sucesso deste projeto que as imagens obtidas possuam
uma qualidade excelente de preferência HD (High Definition). Famosa por produzir
Webcam de boa qualidade, a Logitech possui um modelo que se adequa a proposta
do projeto. Logitech C615 HD Portable 1080p Webcam está a um preço mais
acessível como visto no item 2.1 e é capaz de capturar imagens com dimensões de
até 3264 pixels de largura por 2448 pixels de altura. Tanto na qualidade quanto no
preço a Logitech C615 atende aos requisitos, portanto será utilizada neste projeto.
3.1.4 PCI Trigger
Como comentado em no item 2.3 um dos desafios para a captura de imagens
destinadas a fotos panorâmicas, é o posicionamento da câmera e os ângulos entre
cada foto. A ICU-Câmera Fulldome facilita neste aspecto para o usuário, pois além do
trabalho de ligar a câmera à rede elétrica, em interface com o usuário, haverá apenas
um botão, dois LEDs e um Buzzer indicando se a câmera está ou não pronta para
15
efetuar capturas. Para isso será construída a placa de circuito impresso PCI Trigger,
que será responsável pela interface com o usuário. A placa será alimentada pelos
pinos de I/O do Raspberry PI com 5 Vcc e tendo como referência um pino de GND do
próprio Raspberry também. Cada LED estará ligado em série com um resistor de
proteção diretamente a um pino de Output do Raspberry e em um pino de Input,
também alimentado pelo próprio, um Push Button ligado em série também a um
resistor de proteção. Quando as portas são configuradas como entradas, a tensão
máxima na mesma deve ser de 3,3 Vcc segundo esquemas fornecidos pelo
fabricante[3]. Abaixo, na Figura 2, pode-se observar o diagrama elétrico/lógico do
circuito.
Figura 3 – Circuito PCI-Trigger
16
Os pinos identificados no datasheet do Raspberry com início de GPIO podem
ser configurados para atuarem como bit de Output ou Input. Desta forma será usado
os pinos de GPIO-17 e GPIO-22 para alimentar os LEDs que indicarão os estados em
que se encontra o projeto. Verde significa que a câmera está estável, o usuário pode
iniciar uma sequência de disparos, desligar o projeto ou apenas remover o Pen Drive
da porta USB1. Já o quando o LED vermelho se acende, automaticamente o verde
deverá apagar e o Buzzer começa a emitir som, indicando que a câmera está
processando as capturas e não deve ser interrompido. Tais verificações serão
implementadas via software e explanadas mais adiante.
Apesar dos pinos quando configurados como saída emitirem uma tensão
equivalente a 5 Vcc, na configuração de entrada, aceitam apenas 3.3 Vcc por isso
entre o GPIO-01 e a alimentação do push button de haver um resistor de proteção.
3.1.5 Mídia Removível
Para facilitar a vida do usuário, basta apenas que tenha uma mídia removível
do tipo Pen Drive montada para que o projeto possa exportar as imagens. A única
porta visível na interface com o usuário será a USB1 portando não terá como cometer
erro e inverter as portas USB. Para o funcionamento correto, o Pen Drive deverá estar
formatado em FAT32, outros formatos comprometem o funcionamento do projeto.
3.1.6 Cabo para alimentação do projeto
Apesar de necessitar duas fontes distintas, uma pra o HUB e outra para o
microcomputador, a câmera possuirá apenas um cabo que deverá ser ligado à rede
elétrica. Internamente as fontes serão ligadas em paralelo por uma extensão e apenas
a saída desta extensão é que deverá ser usada. A comunicação entre o HUB e o
Raspberry é feita através de um cabo USB comum, porém há fuga de corrente
proveniente do HUB e pode ocasionar problemas de funcionamento no Raspberry PI.
Para evitar isso é necessário a implementação de um diodo impedindo que a
circulação de corrente sentido HUB-Raspberry, permitindo apenas o inverso,
Raspberry-HUB.
17
3.2 SOFTWARE
O maior desafio deste projeto será na configuração dos dispositivos e no
desenvolvimento dos softwares, pois a Logitech não dispõe para nenhum cliente o
código fonte de seus drivers e software para gerenciamento de imagem. Então além
da automação dos processos de ativação das câmeras será preciso implementar o
software responsável por gerenciar e realizar as capturas de imagens propriamente
ditas.
3.2.1 Iniciar projeto
A princípio, quando o projeto encontra-se sem alimentação, nada deverá estar
funcionado inclusive os LEDs que permanecerão apagados. Assim que a ICU-Câmera
Fulldome recebe alimentação inicia o processo de boot do sistema Operacional. Como
no projeto não possui a necessidade de um computador acoplado à câmera, assim
que carregar todo o sistema deverá abrir automaticamente o primeiro programa cujo
startup deverá estar incluso no arquivo de inicialização do Linux. Este programa será
responsável por inicializar as outras funcionalidades do projeto, como a manipulação
dos valores nos LEDs e aguardar a Trigger ativada pelo push button que dá início à
execução do programa responsável pelo gerenciamento das Webcams e imagens. O
fluxograma abaixo (Figura 3) simula esta primeira etapa.
18
Figura 4 – Fluxograma primeira etapa
Devido à necessidade de interagir com os pinos de I/O este primeiro programa
será implementado em linguagem C. Em seguida tem-se uma ideia do pseudocódigo
(Figura 4) que deverá ser implementado nesta etapa.
19
Figura 5 – Pseudocódigo primeira etapa
3.2.2 Capturar Imagens
Para que este programa funcione corretamente, durante o processo de
configuração do Raspberry deve-se lembrar de atualizar o repositório com uma lista
de pacotes atualizados e em seguida instala-los. Assim é garantido que os drivers
necessários para o reconhecimento tanto do Hub quanto das Webcams estarão
presentes.
Como a Logitech não pôde fornecer o código fonte para que pudesse ser
adaptado ao escopo deste projeto, não está sendo implementado funções baseadas
no software da Logitech. Felizmente em torno dos sistemas operacionais baseados
em Unix/Linux, há uma infinidade de softwares livre cujo o código fonte pode ser
encontrado facilmente na internet como por exemplo fswebcam [4] que tem todo os
seu código em linguagem C. Os autores do fswebcam permitem que qualquer pessoa
acesse os códigos fonte e os modifiquem conforme a sua necessidade. Este software
20
basicamente reconhece todos os dispositivos do tipo vídeo montados sobre o diretório
“/dev” e ao reconhecer inicia uma série de verificações para determinar os parâmetros
recomendados para cada dispositivo. Em seguida, aloca espaço em memória
compatível com a resolução da foto a ser capturada, salva em uma variável interna
uma string com a data e inicia o processo de captura via webcam, conforme realiza
as capturas salva em buffer e em seguida no diretório corrente. Antes de encerrar o
programa, a memória previamente alocada, é liberada e por fim o processo criado
pela execução do código morre. Para este projeto é necessário efetuar a captura
simultânea com as seis webcams, portanto uma das alterações a serem feitas é a
criação de threads correspondendo cada uma a uma webcam montada sobre o
filesystem “/dev” por exemplo “/dev/videoi” sendo “i” um número variável de zero a
cinco. Além disso a função que controla o obturador da webcam não pode ser
executado em paralelo, então um semáforo comum a todas as threads controlará qual
terá acesso a esta função. Por mais que as outras câmeras fiquem em espera durante
a captura, este chaveamento é tão rápido que um segundo é mais que o suficiente
para que as seis webcams efetuem as capturas.
Abaixo, um fluxograma exemplificando o funcionamento do software
responsável pela etapa II, a captura das imagens.
Figura 6 – Fluxograma segunda etapa
21
Um grande desafio para os desenvolvedores deste projeto, será a
implementação de toda configuração necessária a nível de sistema operacional e na
própria aplicação responsável pelas capturas. Abaixo o pseudocódigo que será
implementado para executar efetivamente a captura de imagens. A linguagem a ser
utilizada, por necessidade nas especificações do hardware do Raspberry PI, será C.
Figura 7 – Pseudocódigo segunda etapa
22
Quando o código é iniciado, é preciso importar algumas bibliotecas que serão
usadas durante a execução do código. Algumas destas bibliotecas são
especificamente para utilização da interface entre o hardware e o sistema operacional.
Junto com as bibliotecas deve-se importar os arquivos que contenham as
configurações da captura de imagens pelas webcams como formato da imagem,
tempo de abertura do obturador, etc. Após importar estes elementos, é necessário
criar uma estrutura para definir os valores de cada parâmetro necessário para a
captura das imagens e também criar um semáforo para evitar que durante a execução
as webcams invadam a vez de utilização de memória da webcam da vez. Quando
chega a execução da parte principal do código é implementado a criação de seis
threads, cada thread correspondendo a uma webcam. E dentro do loop que as cria,
definir uma etiqueta que será usada para nomear as fotos uma vez capturadas e
armazenadas.
Dentro da função iniciada por cada thread paralelamente, deve haver uma
alocação de memória para o buffer e a utilização de semáforo para garantir que
nenhuma thread atropele o buffer da thread que está capturando a foto no momento.
Por fim, as threads salvam suas respectivas imagens no cartão SD que funciona como
o Hard Drive do Raspberry PI e as nomeiam com o nome salvo na etiqueta definida
em um trecho anterior do código. Assim, o programa responsável pela captura se
encerra e retorna a execução do código da primeira etapa.
23
4. CRONOGRAMA
O cronograma previsto para o projeto tem o seu início no dia 11 de fevereiro de
2013, concluindo no dia 29 de novembro de 2013, totalizando desta maneira 292
dias incluindo o seu planejamento, desenvolvimento e fase de testes.
Figura 8 – Cronograma atualizado parte I
24
Figura 9 – Cronograma atualizado parte I
25
5. PROCEDIMENTO DE TESTE DE VALIDAÇÃO
São necessários certos testes de modo a se assegurar de que o projeto
funciona tal qual desejado, ou seja, de acordo com o que ele foi projetado. Dessa
forma, são apresentados abaixo os testes determinados para o ICU-Câmera Fulldome
divididos em duas partes, a saber:
a) Testes de caixa branca, nos quais espera-se que o desenvolvedor do projeto
os realize por necessitar um conhecimento do funcionamento interno do sistema (por
exemplo: lógica de programação, funcionamento dos sensores, funcionamento dos
protocolos de comunicação).
b) Testes de caixa preta, nos quais podem ser testados pelo usuário final uma
vez que não necessitam um conhecimento aprofundado do sistema.
5.1. TESTES DE CAIXA BRANCA
5.1.1. Alimentação do sistema
Gênero: Hardware
Escopo: Fontes de alimentação; HUB USB; Microcomputador; Câmeras
Este teste tem como objetivo verificar se as fontes de alimentação fornecem a
corrente necessária para alimentar o sistema como um todo. Isto significa que o
sistema não deve apresentar nenhum desligamento devido à falta de energia. Para
isso todos os componentes eletrônicos do projeto deverão estar ligados e executando
suas respectivas funções. Caso tudo fique ligado como o esperado, pode-se verificar
que as fontes são suficientes.
Resultado:
A fonte fornecida pelo vendedor do HUB verificou-se insuficiente, pois no pico
de sua utilização faltava alimentação aos periféricos nele acoplados.
Temporariamente, para a realização dos seguintes testes foi utilizado uma fonte de
computador. Mas para implementação final do projeto pretende-se utilizar uma fonte
que forneça pelo menos 1A.
26
5.1.2. Permissões de leitura e escrita
Gênero: Software
Escopo: Microcomputador
Para cumprir as expectativas do projeto, como obter todas as fotos capturadas
agrupadas e salvas em um Pen Drive, o computador deve possuir acesso de leitura e
escrita no diretório que serão armazenadas as fotos. Uma maneira de validar este
teste, é fazendo com que o computador crie um novo diretório com um nome
específico e posteriormente copiar as fotos para dentro deste mesmo diretório. Feito
isto, pode-se considerar que o projeto passou com sucesso por este teste.
Resultado:
Trechos de código simulando a captura das imagens e movendo as mesmas
para o Pen Drive foram implementados. Pode-se verificar que todas as imagens foram
movidas para o Pen Drive como era de se esperar, sem problemas de owner ou
permissões dos arquivos.
5.1.3. Alinhamento da estrutura que suporta as câmeras
Gênero: Hardware
Escopo: Suporte
O objetivo deste teste é verificar se a estrutura de sustentação das câmeras
possui as dimensões corretas previstas para a implementação do projeto. Como serão
utilizadas cinco câmeras para fazer a captura das imagens num campo de 360° é
necessário que cada câmera fique instalada em um lado do que seria um pentágono
regular. Para validar que a estrutura atinja a estes requisitos todos os ângulos dos
vértices deste pentágono deverão medir exatamente 72°, esta medida pode ser
efetuada com um transferidor aceitando variações de no máximo 1°. O teste se dará
concluído com sucesso caso todos os ângulos internos do pentágono estejam dentro
do previsto.
Resultado:
Não foi possível verificar este teste pois por enquanto apenas uma câmera está
disponível para testes.
27
5.1.4. Sincronia na captura das fotos
Gênero: Hardware/Software
Escopo: Câmeras; Microcomputador
O objetivo deste teste é verificar a sincronia das câmeras quando realizado a
captura. Para isso será observado no terminal Linux o processo de captura das
câmeras, onde o mesmo indica o horário em que o processo foi realizado para cada
câmera. Desta forma, será enviando o comando para disparo e então comparado o
horário de captura entre todas a câmeras com uma tolerância de dois segundos. Caso
os processos terminarem dentro do prazo, o projeto passou com sucesso por este
teste.
Resultado:
Não foi possível verificar este teste pois por enquanto apenas uma câmera está
disponível para testes.
5.1.5. Desempenho do Raspberry PI
Gênero: Hardware/Software
Escopo: Raspberry PI
A finalidade deste teste é verificar se o microcomputador suporta de forma
adequada os processos que serão realizados. Desta forma o microcomputador
possuir armazenamento, memória RAM e processamento suficientes para não gerar
atrasos nos processos. Uma forma de verificar o seu desempenho é iniciar todos os
processos que serão utilizados e verificar a quantidade de memória RAM ainda
disponível para o sistema, deverá ter uma sobra para prevenção. Uma outra forma de
verificar é no momento de captura das fotos, onde é possível observar o percentual
de utilização do processador. Caso nenhuma falha nessas ocasiões, pode-se
considerar que o teste foi realizado com sucesso.
Resultado:
Foi verificado que quando executa uma captura em resolução máxima
(1920x1080p), tanto o processador quanto a memória do Raspberry PI ficam em seu
limite de utilização, e isto apenas utilizando uma câmera. Tratando-se de seis câmeras
28
será impossível fazer a captura simultânea em Full-HD, assim todas as capturas
deverão ser iniciadas sequencialmente, prejudicando levemente o desempenho do
projeto.
5.2. TESTES DE CAIXA PRETA
5.2.1. Qualidade das câmeras
Gênero: Hardware/Software
Escopo: Webcams
A finalidade deste teste é verificar se todas as câmeras possuem captura de
imagens com a mesma qualidade. Para isto todas as câmeras devem capturar a
mesma paisagem e salvá-las como um arquivo foto, para em seguida comparar as
cores, nitidez, brilho e saturação de cada foto uma a uma. Caso seja verificado alguma
diferença relevante em qualquer um destes atributos, uma alternativa é corrigir via
software, a outra é entrar em contato com o próprio alegando irregularidade no
produto. Se nenhuma diferença significativa for encontrada, pode-se dizer que o
projeto passou pelo teste com sucesso.
Resultado:
Ao iniciar as capturas com o projeto finalizado, todas as imagens apresentam
os mesmos padrões de cores, tamanhos e qualidade, portanto o teste descrito acima
foi realizado com sucesso.
5.2.2. Captura correta das fotos
Gênero: Hardware/Software
Escopo: Câmeras; Computador; LEDs
Neste teste a finalidade é a correta captura das fotos pelas câmeras logo após
pressionado o botão de disparo. Um modo de verificar se o processo de captura está
funcionando corretamente é observando os LEDs indicadores. Para isso dois LEDs
serão utilizados para informar o estado atual do processo. O LED de cor verde indica
que o sistema está pronto e aguardando o botão de disparo ser pressionado, já o LED
vermelho junto com o Buzzer indicam que a captura está sendo realizada. Ao
29
pressionar o botão de disparo, a LED verde deverá apagar e em instantes depois a
vermelha acender e o Buzzer acionar, um tempo será tomado pelas câmeras para
captura das fotos, se não houver falhas a LED vermelha apagará e a verde acenderá
novamente indicando que a captura foi realizada com sucesso.
Resultado:
Ao efetuar a captura das imagens utilizando os pinos de I/O foi possível
reproduzir o teste descrito acima com sucesso.
5.2.3. Armazenamento das fotos
Gênero: Hardware/Software
Escopo: Câmeras; Computador; Pen Drive
Um modo de verificar que o processo de armazenamento está funcionando
corretamente, é com o sistema já inicializado, conectar o Pen Drive ao computador e
pressionar o botão de disparo. Assim que o processo de captura das fotos for
finalizado, o Pen Drive deverá ser removido e conectado em um outro computador
para verificação das fotos. Caso as seis fotos estejam em seus respectivos diretórios,
indica que o teste foi completado com sucesso.
Resultado:
Com o programa em sua versão final foi iniciado as capturas com as webcams
já funcionando. Após efetuar as capturas, o Pen Drive que estava inserido na porta
USB foi removido e verificado em um desktop que as fotos estavam salvas como o
teste acima descreve.
30
6. PROBLEMAS APRESENTADOS E SUAS SOLUÇÕES
Problemas Soluções
O HUB USB enviava uma corrente de fuga
que prejudicava o funcionamento do
Raspberry.
Um diodo do tipo 1N4007 foi soldado
diretamente no cabo que compõe o USB e é
responsável por sua alimentação, assim a
corrente flui apenas do Raspberry para o
HUB mas não o inverso.
A fonte original vendida junto ao HUB
mostrava-se insuficiente, pois quando as
câmeras ligavam simultaneamente algumas
desligavam devido à corrente ser
insuficiente.
Uma fonte capaz de oferecer até 3A,
segundo o fornecedor, fora comprada para
substituir e se mostrou suficiente.
O HUB mostrou-se incapaz de alimentar o
Raspberry e as seis câmeras. Causando mal
funcionamento do micro computador.
Fora adquirido uma fonte de alimentação
dedicada para o Raspberry capaz de suprir
suas necessidades energéticas.
Quando o programa responsável pelas
capturas entrava em funcionamento, por
possuir um loop continuo, impossibilitava a
inicialização dos pacotes de drivers do
Raspberry, assim o mesmo não reconhecia
ou montava a unidade de mídia removível,
Pen Drive.
O programa responsável pela captura das
imagens, aguarda até um processo que
inicia após a inicialização completa o
desbloquear para começar o funcionamento.
O programa não era capaz de definir
externamente, junto ao sistema operacional,
uma variável contendo um timestamp
contendo o dia, o mês, o ano, hora, minutos
e segundos da inicialização do processo das
capturas que seria utilizado no nome das
fotos.
Fora implementado uma função capaz de
definir internamente ao programa junto com
a execução do processo de capturas de
imagens, assim esta variável com o
timestamp faz parte do nome das fotos,
permitindo identifica-las.
Apesar das Webcams serem capazes de
capturas em qualidades como Full-HD, o
ângulo das fotos mostrava-se insuficiente
por conta da distância focal de cada câmera.
Assim as fotos não possuíam partes
equivalentes umas nas outras,
Foram adquiridas lentes do tipo fisheye que
aumentam o ângulo da lente da webcam em
até 180º.
31
impossibilitando a costura das imagens de
forma homogêneas.
As lentes fisheye foram suficientes para
aumentar o ângulo de tomada das imagens,
porém como uma característica deste tipo de
lentes, a mesma adicionava um efeito
circunferencial a imagem, distorcendo as
bordas da imagem, também impossibilitando
a costura.
Foram adquiridas e instaladas no lugar das
lentes fisheye lentes do tipo wide, que
proporcionam um ângulo menor do que a
fisheye.
Mesmo com lentes wide a distorção das
imagens é muito grande, impossibilitando a
costura das imagens a fim de obter um
panorama de qualidade.
As lentes foram removidas e a câmera que
inicialmente apontava para cima fora
acoplada horizontalmente junto com as
outras cinco, portanto o projeto capturará
apenas imagens horizontais e não mais
semiesféricas.
32
7. ANALISE DE RICOS
Como qualquer projeto, este está susceptível a imprevistos tais como erros durante
o desenvolvimento do projeto, atrasos, etc. Por isso é necessário estimar os impactos
e riscos destes acontecimentos. Abaixo está listado alguns problemas mais comuns e
seus detalhes.
RIS001 – Saída de algum integrante do grupo de projeto final
PROBABILIDADE
DE
OCORRÊNCIA:
1 IMPACTO: 3
SEVERIDADE: 3 RESPONSABILIDADE: Integrantes do grupo
DESCRIÇÃO: Pode acontecer por quaisquer motivos sejam, como desistir do curso, mudança,
falecimento, etc de um integrante deixar o grupo, comprometendo o desempenho
do mesmo.
CONTINGÊNCIA: Caso isto ocorra cabe ao integrante restante tentar completar sozinho o projeto ou
negociar com o professor responsável pela disciplina sobre uma possível divisão de
tarefas e apresentar o projeto mesmo sem estar concluído.
PREVENÇÃO: Manter um bom relacionamento entre os integrantes da equipe, cumprir os horários
previstos no cronograma. Quanto a fatalidades não há nada que se possa fazer.
RIS002 – Não conclusão do projeto até a data prevista da defesa
PROBABILIDADE
DE
OCORRÊNCIA:
1 IMPACTO: 3
SEVERIDADE: 3 RESPONSABILIDADE: Integrantes do grupo
DESCRIÇÃO: Os integrantes da equipe foram incapazes de finalizar o projeto até o prazo limite
CONTINGÊNCIA: -
PREVENÇÃO: Procurar seguir o cronograma e adiantar as tarefas o máximo possível
RIS003 – Danificar equipamentos durante a implementação do projeto
PROBABILIDADE
DE
OCORRÊNCIA:
2 IMPACTO: 2
33
SEVERIDADE: 1 RESPONSABILIDADE: Integrantes do grupo.
DESCRIÇÃO: Durante as fases de testes, deslocamentos com o protótipo do projeto ou até mesmo
no manuseio podem danificar os equipamentos que compõe o mesmo.
CONTINGÊNCIA: Comprar novos equipamentos com urgência, para substituir os danificados
PREVENÇÃO: Manusear os equipamentos, sejam eles, câmeras, computadores, switch, cabos, etc.
com a maior cautela possível.
RIS004 – Prover imagens com má qualidade
PROBABILIDADE
DE
OCORRÊNCIA:
1 IMPACTO: 2
SEVERIDADE: 2 RESPONSABILIDADE: Integrantes do grupo.
DESCRIÇÃO: Como o principal cliente para este projeto exige imagens em alta definição pois
conta com telas de projeções de proporções além do normal, não seria interessante
que as fotos estivesse com falhas de pixels ou qualquer outro defeito.
CONTINGÊNCIA: Caso seja insatisfatório as imagens geradas pelo projeto, pode-se pedir por um
auxílio financeiro em acordo com a universidade para adquirir câmeras de melhor
qualidade.
PREVENÇÃO: Procurar utilizar desde o início da implementação do projeto câmeras com
qualidade alta dentro do orçamento previsto do projeto.
RIS005 – Adquirir peças com defeito
PROBABILIDADE
DE
OCORRÊNCIA:
1 IMPACTO: 1
SEVERIDADE: 2 RESPONSABILIDADE: Integrantes do grupo e
fabricante do produto.
DESCRIÇÃO:
Hoje em dia os controles de qualidade, principalmente das grandes marcas tem se
tornado cada vez mais rigorosos, porém existe a possibilidade de os integrantes
importar produtos para o desenvolvimento do projeto e os mesmos virem com
defeitos de fabricação.
CONTINGÊNCIA: Entrar em contato com o fabricante o mais rápido possível e exigir do mesmo uma
atitude de reposição, troca da peça, concerto, ou devolução do dinheiro dos
integrantes do projeto.
PREVENÇÃO: Procurar fornecedores com experiência no mercado de eletrônicos, e que sejam
famosos por prover produtos de alta qualidade com baixa tolerância de falhas.
RIS006 – Má desempenho do Raspberry Pi
PROBABILIDADE
DE
OCORRÊNCIA:
1 IMPACTO: 4
SEVERIDADE: 3 RESPONSABILIDADE: Integrantes do grupo e do
produto.
DESCRIÇÃO: É certo que microcomputadores possuem um desempenho limitado, por conta disso
há a probabilidade de um único microcomputador não apresentar um desempenho
34
adequado para o projeto.
CONTINGÊNCIA:
Realizar a aquisição de mais microcomputadores até um máximo de seis, sendo um
microcomputador para cada câmera. Também utilizar a interface Lan para
comunicação entre os microcomputadores além de modificar o script utilizado para
a captura e armazenamento das fotos.
PREVENÇÃO: Realizar um estudo baseado em pesquisas e benchmarks referentes ao Raspberry Pi.
RIS007 – Capturas dessincronizadas
PROBABILIDADE
DE
OCORRÊNCIA:
1 IMPACTO: 3
SEVERIDADE: 3 RESPONSABILIDADE: Integrantes do grupo e do
produto.
DESCRIÇÃO: No processo de captura das fotos pode ocorrer por alguma deficiência no software
ou hardware o atraso de uma ou mais capturas. O atraso só é validade quando
exceder a tolerância máxima de dois segundos.
CONTINGÊNCIA: Realizar modificações no software para um melhor aproveitamento do sistema em
geral, realizar otimizações utilizando métodos como o fork para diminuir o período
entre as chamadas de função. Ou até mesmo implementar uma condição de barreira.
PREVENÇÃO: Utilizar processos de otimizações na criação do script. Aplicar técnicas avançadas
de escalonamento e duplicação de processos.
RIS008 – Falhas na utilização do HUB USB
PROBABILIDADE
DE
OCORRÊNCIA:
1 IMPACTO: 1
SEVERIDADE: 1 RESPONSABILIDADE: Integrantes do grupo e do
produto.
DESCRIÇÃO: O HUB USB apresenta falhas quando utilizado todas as câmeras simultaneamente.
Também pode apresentar falhas pela má qualidade do produto.
CONTINGÊNCIA: Realizar a compra de outro modelo de HUB USB com maior qualidade ou com uma
alimentação de maior capacidade. Modificar o HUB USB para que o mesmo atenda
aos requisitos.
PREVENÇÃO: Procurar fornecedores com experiência no mercado de eletrônicos, e que sejam
famosos por prover produtos de alta qualidade com baixa tolerância de falhas.
RIS009 – Processo não liberar buffer
PROBABILIDADE
DE
OCORRÊNCIA:
1 IMPACTO: 2
SEVERIDADE: 1 RESPONSABILIDADE: Integrantes do grupo.
DESCRIÇÃO: Por alguma falha de programação ou de hardware, logo depois de reservado o buffer
para uma câmera realizar a captura, o sistema trava e não libera o buffer para as
outras câmeras.
CONTINGÊNCIA: Revisar o software procurando possíveis erros e/ou realizar alterações utilizando
35
outros métodos avançados de programação. Verificar em outro microcomputador
se a mesma falha ocorre.
PREVENÇÃO: Utilizar desde o início, técnicas avançadas de programação indicadas para processos
multi-threads.
36
8. CONCLUSÃO
No decorrer deste projeto houve a abordagem de um problema, o preço elevado
em mercado das câmeras com tecnologia de captura Fulldome. Baseado nisto os
integrantes do grupo realizaram diversas pesquisas e testes e chegaram a conclusão
sobre quais técnicas e materiais usar. No capítulo 3 foi possível acompanhar todos
os componentes do projeto tanto de hardware como de software. Também neste
documentos teve-se uma atualização do cronograma para condizer com a situação
atual.
O maior desafio da implementação deste projeto é em relação a captura
simultânea de seis imagens em qualidade HD (High Definition) sem que haja falha
por conta de condição de corrida pois as seis câmeras dependem de um único
processador.
Para que o projeto esteja dentro dos requisitos da disciplina e também do
escopo proposto pelos integrantes da equipe, foram propostos a realização de testes
em caixa branca, ou seja, teste do ponto de vista técnico. E também para garantir a
consistência do objetivo da câmera, foram propostos testes em caixa preta,
simulando a interação de um usuário com o projeto. Por mais que o projeto já esteja
encaminhado, ainda há riscos, grande parte destes riscos foram revisados e contém
alternativas em caso do pior caso.
A impossibilidade de utilizar apenas seis câmeras para fazer toda a captura
necessária para obter uma imagem fulldome devido a distância de cada lente das
câmeras ao centro do projeto, fez com o que este desviasse um pouco do proposto
inicialmente, apenas criando imagens para serem representadas horizontalmente
em 360º, deixando de lado a preocupação com os 180º verticais.
O projeto ICU-Câmera Fulldome mostra-se um produto viável capaz de atender
as expectativas no que se refere a captura de imagens para costura para panoramas.
E embora inicialmente tinha-se a intensão de gerar imagens para representação
fulldome, o projeto ainda é capaz de fazer capturas para fotos panorâmicas com
muita precisão no que se refere a posicionamento das câmeras.
37
9. REFERÊNCIAS BIBLIOGRÁFICAS
[1] COMPUTER LABORATORY: University of Cambridge: How To: Raspberry
Section two GPIO. Disponível em:
http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/turing-machine/two.html,
Acesso em: 08 de Junho de 2013.
[2] FORUM: PingBin: How To: Raspberry PI Web Cam Server incl. SnowBoarding
HUD Pi Style, pele cases, Web Cam Server and more. Disponível em:
http://pingbin.com/2012/12/raspberry-pi-web-cam-server-motion, Acesso em: 08 de
Junho de 2013.
[3] GPIO ELETRICAL SPECIFICATIONS: MOSAIC DOCUMENTATION WEB.
Disponível em: http://www.mosaic-industries.com/embedded-
systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications,
Acesso em: 7 de Junho de 2013.
[4] GitHub repository: fsphil / fswebcam code. Disponível em:
https://github.com/fsphil/fswebcam/blob/master/CHANGELOG, Acesso em: 10 de
Junho de 2013.