PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA...

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


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


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


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


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


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


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


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


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.

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA...

Documents

Transcript of PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA...