DAELN - DEPARTAMENTO ACADˆ
EMICO DE ELETR ˆ
ONICA
CURSO DE ENGENHARIA ELETR ˆ
ONICA
ANDR´
E LUIZ BERTONI
DIEGO VIEIRA DE SOUZA FEDER
REDE NEURAL CONVOLUCIONAL APLICADA `
A VIS ˜
AO
COMPUTACIONAL PARA DETEC ¸
C ˜
AO DE INCˆ
ENDIO
TRABALHO DE CONCLUS˜
AO DE CURSO
CURITIBA
2018
DIEGO VIEIRA DE SOUZA FEDER
REDE NEURAL CONVOLUCIONAL APLICADA `
A VIS ˜
AO
COMPUTACIONAL PARA DETEC ¸
C ˜
AO DE INCˆ
ENDIO
Trabalho de Conclus˜ao de Curso apresentado ao Curso de Engenharia Eletrˆonica da Universidade Tecnol´ogica Federal do Paran´a, como requisito parcial para a obten¸c˜ao do t´ıtulo de Bacharel.
Orientador: Prof. Daniel Rossato de Oliveira
Universidade Tecnol´ogica Federal do Paran´a
CURITIBA
2018
ANDRÉ LUIZ BERTONI DIEGO VIEIRA DE SOUZA FEDER
REDE NEURAL CONVOLUCIONAL APLICADA À VISÃO
COMPUTACIONAL PARA DETECÇÃO DE INCÊNDIO
Este Trabalho de Conclusão de Curso de Graduação foi apresentado como requisito parcial para obtenção do título de Engenheiro Eletrônico, do curso de Engenharia Eletrônica do Departamento Acadêmico de Eletrônica (DAELN) outorgado pela Universidade Tecnológica Federal do Paraná (UTFPR). Os alunos foram arguidos pela Banca Examinadora composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho aprovado.
Curitiba, 07 de dezembro de 2018.
____________________________________ Prof. Dr. Robinson Vida Noronha
Coordenador de Curso Engenharia Eletrônica
____________________________________ Profª. Drª. Carmen Caroline Rasera
Responsável pelos Trabalhos de Conclusão de Curso de Engenharia Eletrônica do DAELN
BANCA EXAMINADORA
______________________________________ Prof. Me. Daniel Rossato de Oliveira
Universidade Tecnológica Federal do Paraná Orientador
_____________________________________ Prof. Dr. Robinson Vida Noronha
Universidade Tecnológica Federal do Paraná
_____________________________________ Prof. Me. Luiz Fernando Copetti
Universidade Tecnológica Federal do Paraná
Agradecemos `as nossas fam´ılias e amigos por todo amor e apoio incondicional fornecido, at´e nos momentos de maior dificuldade.
Agradecemos a todos os professores que nos ensinaram durante essa trajet´oria e guiaram nossos aprendizados para a conclus˜ao dessa etapa.
Agradecemos tamb´em a Universidade Tecnol´ogica Federal do Paran´a, seu corpo docente, dire¸c˜ao e administra¸c˜ao por toda a estrutura providenciada ao longo desse per´ıodo.
BERTONI, Andr´e L.; FEDER, Diego V. de S.;. Rede Neural Convolucional Aplicada `a Vis˜ao Computacional para Detec¸c˜ao de Incˆendio. 2018. 80 f. Trabalho de Conclus˜ao de Curso – Curso de Engenharia Eletrˆonica, Universidade Tecnol´ogica Federal do Paran´a. Curitiba, 2018. Para este projeto foi desenvolvido um sistema de alerta de incˆendio que utiliza: uma cˆamera, um Raspberry Pi, um sistema de vis˜ao computacional e um aplicativo android.
Utilizamos o Raspberry Pi como bloco principal. ´E ele que est´a conectado diretamente `a cˆamera e processa a imagem recebida com um algoritmo inteligente.
O algoritmo do sistema consiste em trˆes partes: filtragem de cores, detec¸c˜ao de movimento e auto-aprendizagem. Avaliando assim se existe um princ´ıpio de incˆendio occorendo.
O aplicativo android foi desenvolvido com uma interface user-friendly, e tem como fun¸c˜oes enviar avisos ao usu´ario e garantir acesso `a cˆamera do sistema em tempo real.
Palavras-chave: Seguran¸ca, Alarme, Incˆendio, Vis˜ao Computacional, Processamento de Ima-gens, Android
BERTONI, Andr´e L.; FEDER, Diego V. de S.;. Convolutional Neural Network Based Fire Detection through Computer Vision. 2018. 80 f. Trabalho de Conclus˜ao de Curso – Curso de Engenharia Eletrˆonica, Universidade Tecnol´ogica Federal do Paran´a. Curitiba, 2018.
In this project, we developed a fire alarm system consisting in: a camera, a Raspberry Pi, a computer vision system and an android application.
The Raspberry Pi is considered the leading piece. It is connected directly to a digital camera that processes the received image with an intelligent algorithm.
The system algorithm consists of three parts: color filtering, motion detection and self-learning. Evaluating then, if there is a fire principle occurring.
The Android application was developed with a user-friendly interface, with the duty to send warnings to the user and provide access to the system camera in real time.
Figura 1 – Diagrama funcional da utiliza¸c˜ao de um sistema embarcado. . . 14
Figura 2 – Funcionamento b´asico de uma cˆamera digital. . . 15
Figura 3 – Esquem´atico informa¸c˜ao e decis˜ao. . . 16
Figura 4 – Representa¸c˜ao entrada e sa´ıda - rede neural artificial. . . 18
Figura 5 – Pilha de software - TensorFlow. . . 20
Figura 6 – Representa¸c˜ao de um modelo LeNet. . . 21
Figura 7 – Ambiente de Desenvolvimento Android Studio. . . 22
Figura 8 – A pilha de software do Android. . . 23
Figura 9 – Ciclo de vida da atividade. . . 25
Figura 10 – Representa¸c˜ao de comunica¸c˜ao por sockets entre servidor e cliente. . . 26
Figura 11 – Raspberry Pi 3. . . 28
Figura 12 – Cˆamera USB (Logitech C270) utilizada. . . 29
Figura 13 – Busca google imagens - velas acesas. . . 31
Figura 14 – C´odigo para salvar as URLs das imagens exibidas. . . 31
Figura 15 – Estrutura dos diret´orios contendo as imagens do dataset. . . 32
Figura 16 – C´odigo Python para download das imagens. . . 32
Figura 17 – C´odigo respons´avel pela verifica¸c˜ao da integridade das imagens baixadas. . 33
Figura 18 – Download das imagens pelo terminal Anaconda. . . 33
Figura 19 – C´odigo respons´avel pela constru¸c˜ao do classificador de imagens Keras. . . . 34
Figura 20 – Bibliotecas utilizadas no arquivo train network.py. . . 35
Figura 21 – C´odigo respons´avel pela entrada dos argumentos. . . 35
Figura 22 – C´odigo de inicializa¸c˜ao das vari´aveis de treinamento, listas e diret´orios. . . 36
Figura 23 – C´odigo para pr´e-processamento das imagens. . . 36
Figura 24 – Estrutura do diret´orio do dataset. . . 37
Figura 25 – C´odigo para alterar escala das imagens e criar splits. . . 37
Figura 26 – Cria¸c˜ao de dados atrav´es da ImageDataGenerator(). . . 38
Figura 27 – C´odigo para inicializar, treinar e salvar modelo de rede. . . 38
Figura 28 – Rede neural com 26 epochs e precis˜ao de 96,45%. . . 39
Figura 29 – Treinamento de redes neurais - precis˜ao e perdas. . . 39
Figura 30 – Diferentes estados do aplicativo TCC - Fire Alarm. . . 40
Figura 31 – Notifica¸c˜ao gerada pela troca ao estado DANGER! . . . 41
Figura 32 – Notifica¸c˜ao gerada pela troca ao estado WARNING. . . 41
Figura 33 – Visualiza¸c˜ao da CameraActivity. . . 42
Figura 34 – Fluxograma simplificado da MainActivity. . . 42
berry Pi. . . 44
Figura 37 – Comandos utilizados para instala¸c˜ao das bibliotecas HDF5 e h5py no Rasp-berry Pi. . . 44
Figura 38 – Comandos utilizados para instala¸c˜ao das bibliotecas HDF5 e h5py no Rasp-berry Pi. . . 44
Figura 39 – Comandos utilizados para importar as bibliotecas j´a compiladas no Raspberry Pi. . . 45
Figura 40 – Declara e importa o modelo de rede neural a ser utilizado pelo Raspberry Pi. 45 Figura 41 – C´odigo de inicializa¸c˜ao e parametriza¸c˜ao do sistema de detec¸c˜ao de incˆendio. 45 Figura 42 – C´odigo de carregamento do modelo de rede e inicializa¸c˜ao da cˆamera. . . . 46
Figura 43 – C´odigo de captura de frames da stream de v´ıdeo. . . 46
Figura 44 – C´odigo para pr´e-processamento e envio dos frames para a rede neural. . . . 47
Figura 45 – C´odigo de classifica¸c˜ao das imagens. . . 47
Figura 46 – C´odigo de acionamento do alarme. . . 47
Figura 47 – Reinicializa¸c˜ao da contagem de frames consecutivos. . . 47
Figura 48 – Constru¸c˜ao do frame para exibi¸c˜ao na tela. . . 48
Figura 49 – Detec¸c˜ao de fogo na imagem com 93,88% de confian¸ca. . . 48
Figura 50 – C´odigo respons´avel pelo envio de novos eventos. . . 49
Figura 51 – C´odigo respons´avel pela visualiza¸c˜ao do v´ıdeo. . . 50
Figura 52 – Fluxograma do funcionamento do c´odigo. . . 50
Figura 53 – Captura de tela durante teste da rede neural. . . 51
Figura 54 – Captura de tela durante teste da rede neural. . . 52
Figura 55 – Captura de tela durante teste da rede neural. . . 52
Figura 56 – Teste em luminosidade, luz - antes do treinamento. . . 53
Figura 57 – Teste em luminosidade, luz - ap´os devido treinamento. . . 54
Figura 58 – Captura de tela durante teste de tempo real. . . 55
API Application Program Interface
ART Android Runtime
CNN Convolutional Neural Network
DNN Deep Neural Network
FPS Frames Per Second
HAL Hardware Abstraction Layer
ID Identification
IP Internet Protocol
RAM Random Access Memory
RGB Red Green Blue
SMS Short Message Service SSD Single Shot Detector
SSH Secure Shell
TCP Transmission Control Protocol
UI User Interface
USB Universal Serial Bus Wi-Fi Wireless Fidelity
1 – INTRODU ¸C ˜AO . . . 11 1.1 OBJETIVOS . . . 12 1.1.1 Objetivo geral . . . 12 1.1.2 Objetivos espec´ıficos . . . 12 1.2 JUSTIFICATIVA . . . 12 2 – FUNDAMENTA¸C ˜AO TE ´ORICA . . . 14 2.1 SISTEMAS EMBARCADOS . . . 14 2.2 CˆAMERAS DE V´IDEO . . . 15 2.3 VIS˜AO COMPUTACIONAL . . . 15 2.3.1 Aquisi¸c˜ao de imagens . . . 16 2.3.2 Processamento de imagem . . . 16
2.3.3 An´alise e compreens˜ao de imagens . . . 16
2.3.4 OpenCV . . . 17
2.4 APRENDIZAGEM DE M´AQUINA . . . 17
2.4.1 M´etodos de aprendizagem de m´aquina . . . 17
2.4.2 Redes neurais artificiais . . . 17
2.4.3 Deep Learning . . . 19 2.4.4 TensorFlow . . . 19 2.4.5 Keras . . . 20 2.4.6 LeNet . . . 21 2.5 SISTEMA ANDROID . . . 21 2.5.1 Android Studio . . . 21 2.5.2 Arquitetura Android . . . 22 2.5.3 Atividades . . . 24 2.5.4 Android Manifest . . . 25 2.6 SOCKETS . . . 26
3 – PROCEDIMENTOS METODOL ´OGICOS . . . 28
3.1 RASPBERRY PI . . . 28
3.2 CˆAMERA USB . . . 29
3.3 REDE NEURAL CONVOLUCIONAL . . . 30
3.3.1 Criando um dataset . . . 30
3.3.2 Modelando a rede neural . . . 33
3.3.3 Treinando a rede neural . . . 34
3.6 ALGORITMOS E C ´ODIGOS . . . 43
3.6.1 Implementa¸c˜ao no Raspberry Pi . . . 43
3.6.2 Inicializa¸c˜ao do sistema . . . 44
3.6.3 Obten¸c˜ao do frame da cˆamera e classifica¸c˜ao das imagens . . . 46
3.6.4 Envio de evento e recebimento de notifica¸c˜ao . . . 48
3.6.5 Transmiss˜ao e visualiza¸c˜ao de v´ıdeo . . . 49
3.6.6 Fluxograma do funcionamento geral do sistema . . . 50
4 – APRESENTA¸C ˜AO E AN ´ALISE DE RESULTADOS . . . 51
4.1 AN´ALISE E RESULTADOS DA REDE NEURAL . . . 51
4.2 AN´ALISE E RESULTADOS DO SISTEMA EM TEMPO REAL . . . 54
5 – CONCLUS ˜AO . . . 56
Referˆencias . . . 57
Apˆ
endices
58
APˆENDICE A – C´odigo para download das imagens do dataset . . . 59APˆENDICE B – C´odigo da arquitetura da rede LeNet . . . 61
APˆENDICE C – C´odigo para treinamento da rede neural . . . 62
APˆENDICE D–C´odigo para teste da rede neural . . . 65
APˆENDICE E – C´odigo de detec¸c˜ao de incˆendio no sistema embarcado . . . . 67
APˆENDICE F – C´odigo das activities do aplicativo Android . . . 70
APˆENDICE G – C´odigo dos layouts do aplicativo Android . . . 76
APˆENDICE H–C´odigo do Android Manifest . . . 79 APˆENDICE I – C´odigo para comunica¸c˜ao do Raspberry Pi ao aplicativo Android 80
1 INTRODU ¸C ˜AO
O homem sempre teve fasc´ınio pelo fogo e durante milhares de anos foi aprimorando as t´ecnicas de dom´ınio e controle da igni¸c˜ao. Esse dom´ınio do fogo permitiu grande avan¸co da sociedade: com um melhor preparo de alimentos, prote¸c˜ao contra o frio, ilumina¸c˜ao, r´apida locomo¸c˜ao, etc. No entanto, o risco atrelado ao fogo ´e alto, e muitos dos incˆendios marcados em nossa hist´oria originou grande perda de vidas e propriedades. Al´em disso, devido aos impactos sociais, ambientais e econˆomicos que um incˆendio pode causar, as seguradoras e os equipamentos de seguran¸ca imp˜oe um alto custo no mercado.
De acordo com a Secretaria Nacional de Seguran¸ca P´ublica (Senasp) do Minist´erio da Justi¸ca, o Brasil tem uma m´edia anual de 267 mil incˆendios (incluindo ocorrˆencias florestais e residenciais). Outros dados confirmam que em 2011 o Brasil alcan¸cou a posica¸c˜ao de terceiro lugar no ranking mundial de mortes por incˆendio ou exposi¸c˜ao a fuma¸ca. Esta constata¸c˜ao se baseou no cruzamento de dados informados pelo Sistema ´Unico de Sa´ude (SUS) com uma pesquisa realizada pela Geneva Association (SPRINKLER, 2015).
Esse quadro, ainda existente em nosso pa´ıs, ´e resultado da falta de informa¸c˜ao e da n˜ao utiliza¸c˜ao de equipamentos de seguran¸ca. Muitas empresas ainda consideram incˆendios como uma quest˜ao de sorte ou azar. E poucos s˜ao os que se preparam e se importam com os cinco princ´ıpios de seguran¸ca b´asica (preven¸c˜ao, prote¸c˜ao, combate, meios de escape, gerenciamento).
Recentemente foi poss´ıvel atentar a expressividade de um incˆendio pelo importuno acontecimento na cidade de Paradise - California. Situada a nordeste do Vale do Sacramento, j´a ´e constatado como o maior incˆendio florestal da hist´oria do estado, estima-se que um total de 13.000 casas foram destru´ıdas e os preju´ızos das propriedades podem se aproximar de 4 bilh˜oes de d´olares. O que traz a tona a importˆancia e o cuidado que deve ser levado diante desses desastres.
Com o objetivo de implementar medidas de prote¸c˜ao e combate ao incˆendio, este projeto visa desenvolver uma solu¸c˜ao fidedigna, barata e eficaz. Este documento inicia apontando o aspecto geral do sistema em quest˜ao e salientando os requisitos do projeto. Posteriormente indica a metodologia adotada, especificando cada ferramenta utilizada no desenvolvimento. Por fim, informa todo o processo de implementa¸c˜ao de hardware, software, da implanta¸c˜ao do sistema em detalhes e traz uma an´alise de resultados juntamente `a conclus˜ao do trabalho.
1.1 OBJETIVOS 1.1.1 Objetivo geral
O objetivo geral deste projeto ´e desenvolver um sistema protecional residencial, com foco na detec¸c˜ao de incˆendio atrav´es de processamento de imagens utilizando uma rede neural convolucional, uma cˆamera e um aplicativo m´ovel para notifica¸c˜ao e visualiza¸c˜ao do estado de risco existente.
Para o funcionamento do sistema, exige-se uma placa de desenvolvimento Raspberry Pi, uma cˆamera USB e um smartphone hospedado com o sistema operacional Android. 1.1.2 Objetivos espec´ıficos
´
E preciso garantir que os requisitos sejam precisos, comprometendo que `as expectativas de resultado final sejam atendidas. A seguir s˜ao listados todos os objetivos espec´ıficos do projeto:
• Aprendizagem de m´aquina: Ser´a implementado um algoritmo inteligente para treinamento do sistema. Ser´a utilizado uma Rede Neural Convolucional (CNN) para identificar fogo em v´ıdeos;
• Comunica¸c˜ao: O aplicativo ser´a dinˆamico. Ele ir´a interagir com o usu´ario instantaneamente de acordo com as entradas que recebe. Deve-se utilizar sockets para a comunica¸c˜ao cliente-servidor entre o raspberry pi e o smartphone.
• Notifica¸c˜ao: O usu´ario deve receber notifica¸c˜oes sempre que um evento acontecer. Portanto, o aplicativo deve continuar sua execu¸c˜ao em segundo plano, sem sofrer interrup¸c˜oes.
• Visualiza¸c˜ao: O usu´ario poder´a acessar o sistema sempre que ligado e com conex˜ao `a internet. A conex˜ao deve permitir a visualiza¸c˜ao da cˆamera em tempo real, ´util para averiguar a condi¸c˜ao do sistema.
• Usabilidade: A aplica¸c˜ao deve ser f´acil de usar e intuitiva. O aplicativo deve ter uma interface amig´avel, simples e clara.
• Desempenho: O software embarcado no raspberry pi n˜ao pode sobrecarregar o sistema mesmo que processe uma alta quantidade de dados (v´ıdeo) em tempo real. O sistema deve responder rapidamente `as solicita¸c˜oes do usu´ario.
• Mem´oria: O aplicativo n˜ao deve ocupar muito espa¸co, se adequando aos crit´erios do Android.
1.2 JUSTIFICATIVA
Tanto em propriedades comerciais quanto residenciais, a importˆancia de se ter um sistema de alarme ou de atua¸c˜ao e combate a incˆendios n˜ao pode ser subestimada. Esses
sistemas salvam vidas e n˜ao pode haver incentivo maior do que garantir que as pessoas que entram em um pr´edio, seja comercial ou residencial, estejam totalmente protegidas.
Com a popularidade gradual da instala¸c˜ao de sistemas de vigilˆancia visual e sistemas protecionais nas ´ultimas d´ecadas, a detec¸c˜ao incˆendio tornou-se uma quest˜ao muito importante, pois est´a intimamente relacionada a seguran¸ca e a propriedade das pessoas. Atualmente, as t´ecnicas de detec¸c˜ao de chama usadas com mais frequˆencia s˜ao geralmente baseadas em amostragem de part´ıculas, amostragem de temperatura e testes de transparˆencia de ar, al´em dos tradicionais detectores de chamas ultravioleta e infravermelho (ARRUE; DIOS, 2000).
No entanto, a maioria desses detectores sofre de alguns problemas graves. Eles exigem uma proximidade com a chama. Al´em disso, nem sempre s˜ao confi´aveis, porque boa parte deles n˜ao detectam a pr´opria combust˜ao, ao inv´es disso, detectam os subprodutos da combust˜ao, que podem ser produzidos de outras maneiras. Portanto, eles geralmente resultam em uma maior incidˆencia de alarmes falsos. No sistema em apre¸co a detec¸c˜ao ´e feita atr´aves do reconhecimento visual do fogo, permitindo um tempo de resposta menor e mais fidedigno.
2 FUNDAMENTA¸C ˜AO TE ´ORICA
Este cap´ıtulo tem como finalidade explicar os princ´ıpios te´oricos e t´ecnicos que foram utilizados ao desenvolver o projeto. Para tal, foram julgados como necess´arios os seguintes temas: Sistemas embarcados (Se¸c˜ao 2.1), Cˆameras de v´ıdeo (Se¸c˜ao 2.2), Vis˜ao computacional (Se¸c˜ao 2.3), Aprendizagem de m´aquina (Se¸c˜ao 2.4), Sistema Android (Se¸c˜ao 2.5), Sockets (Se¸c˜ao 2.6).
2.1 SISTEMAS EMBARCADOS
Um sistema embarcado pode ser definido como um sistema computacional com um prop´osito de aplica¸c˜ao ´unico, ao contr´ario de um computador pessoal convencional, o qual pode ser chamado de sistema computacional de prop´osito generalizado. O sistema embarcado normalmente far´a parte de outro sistema maior, servindo como uma esp´ecie de “c´erebro” do equipamento em quest˜ao, atuando como controlador de eventos com sensores e atuadores e das interfaces com sistemas externos e com usu´arios. Exemplos de equipamentos que utilizam sistemas embarcados: ve´ıculos, equipamentos m´edicos, equipamentos agr´ıcolas, equipamentos militares, etc (RENAUX, 2016). Na figura 1 ´e poss´ıvel observar um diagrama funcional de um sistema embarcado.
Figura 1 – Diagrama funcional da utiliza¸c˜ao de um sistema embarcado.
2.2 CˆAMERAS DE V´IDEO
Uma cˆamera de v´ıdeo digital ´e um dispositivo que captura informa¸c˜oes de imagem de ambientes ao vivo, codificando-as em dados que podem ser decodificados ou transcodificados em m´ıdia visual eletrˆonica. Uma cˆamera digital t´ıpica consiste em uma lente, sensor de imagem, m´ıdia de armazenamento e v´arios outros recursos que tamb´em podem ser encontrados em outras cˆameras (como abertura escalon´avel, filtros e flash)(TECHOPEDIA, 2018) .
Uma cˆamera digital usa uma variedade de fotossensores para registrar o padr˜ao de entrada de luz. Cada sensor retorna uma corrente el´etrica quando ´e atingido pela luz recebida. Como a quantidade de corrente que ´e retornada varia com a quantidade de luz, os circuitos eletrˆonicos da cˆamera digital podem combinar os diferentes n´ıveis de corrente em um padr˜ao composto de dados que representa a luz recebida - em outras palavras, uma imagem na forma de um arquivo bin´ario. A figura 2 ilustra isso.
Figura 2 – Funcionamento b´asico de uma cˆamera digital.
Fonte: Website Dummies - How Does a Digital Camera Work (2018)
2.3 VIS˜AO COMPUTACIONAL
Utilizamos nossos olhos e c´erebro para ver e interpretar visualmente o mundo ao nosso redor. O objetivo da vis˜ao computacional ´e dar essa capacidade de ver a uma m´aquina. A vis˜ao computacional extrai e analisa automaticamente informa¸c˜oes ´uteis de uma imagem ou sequˆencia de imagens. Um computador tamb´em pode ver coisas que n˜ao podemos, com v´arios canais de percep¸c˜ao, o que significa que as m´aquinas tˆem mais recursos visuais do que n´os
(SZELISKI, 2010). Devido a esse poder de ver sobre-humano, existe um grande potencial para que a vis˜ao computacional tenha um impacto profundo em nossas vidas (REED, 2017).
A vis˜ao computacional emula a vis˜ao humana usando imagens digitais atrav´es de trˆes componentes principais de processamento, executados um ap´os o outro, vide figura 3:
1. Aquisi¸c˜ao de imagem; 2. Processamento de imagem;
3. An´alise e compreens˜ao de imagens;
Como nossa compreens˜ao visual humana do mundo ´e refletida em nossa capacidade de tomar decis˜oes atrav´es do que vemos, fornecer tal entendimento visual aos computadores ´e o princ´ıpal objetivo da vis˜ao computacional.
Figura 3 – Esquem´atico informa¸c˜ao e decis˜ao.
Fonte: Autoria pr´opria (2018)
2.3.1 Aquisi¸c˜ao de imagens
A aquisi¸c˜ao de imagens ´e o processo de traduzir o mundo anal´ogico ao nosso redor em dados bin´arios compostos de zeros e uns, interpretados como imagens digitais. Na maioria das vezes, os dados brutos adquiridos nessa etapa precisam ser p´os-processados para serem mais eficientes.
2.3.2 Processamento de imagem
O segundo componente da vis˜ao computacional ´e o processamento de imagens de baixo n´ıvel. Algoritmos s˜ao aplicados aos dados bin´arios adquiridos na primeira etapa para inferir informa¸c˜oes de baixo n´ıvel em partes da imagem. Esse tipo de informa¸c˜ao ´e caracterizado por bordas de imagem, recursos de ponto ou segmentos, por exemplo. Eles s˜ao todos os elementos geom´etricos b´asicos que constroem objetos em imagens. Essa segunda etapa geralmente envolve algoritmos e t´ecnicas avan¸cadas de matem´atica aplicada (TARTU, 2015).
2.3.3 An´alise e compreens˜ao de imagens
A ´ultima etapa do pipeline de vis˜ao computacional ´e a an´alise dos dados, que permitir´a a tomada de decis˜ao. Algoritmos de alto n´ıvel s˜ao aplicados, usando os dados da imagem e as
informa¸c˜oes de baixo n´ıvel calculadas nas etapas anteriores. 2.3.4 OpenCV
OpenCV ´e uma biblioteca open-source multiplataforma que inclui centenas de algorit-mos de vis˜ao computacional, com interfaces para C, C++, Python e Java. A biblioteca possui uma estrutura modular, contendo m´odulos espec´ıficos para processamento digital de imagens, processamento de v´ıdeos, detec¸c˜ao de objetos, etc.
2.4 APRENDIZAGEM DE M´AQUINA
A aprendizagem de m´aquina (machine learning ) ´e apenas uma das muitas ramifica¸c˜oes do estudo da inteligˆencia artificial. ´E um termo gen´erico que se referencia a qualquer algoritmo que permita identificar padr˜oes em dados fornecidos, construir modelos e fazer predi¸c˜oes sem estar explicitamente programado para tal. Essas caracter´ısticas s˜ao de extrema importˆancia em cen´arios onde as tarefas a serem executadas n˜ao s˜ao claras ou n˜ao haja uma rela¸c˜ao de entrada e sa´ıda t˜ao concisa. Algoritmos de aprendizagem de m´aquina se sobressaem em ambientes que variam com o tempo e que requerem readapta¸c˜ao constante. Atualmente o aprendizado de m´aquina est´a presente em diversas ´areas e aplica¸c˜oes, dentre elas o reconhecimento de voz, a vis˜ao computacional, predi¸c˜oes financeiras e aux´ılio nos diagn´osticos m´edicos (BISHOP, 2006). 2.4.1 M´etodos de aprendizagem de m´aquina
Os algoritmos de aprendizado de m´aquina geralmente s˜ao classificados como supervi-sionados ou n˜ao supervisionados.
Algoritmos de aprendizado de m´aquina supervisionados podem aplicar o que foi aprendido no passado a novos dados usando exemplos rotulados para prever eventos futuros. A partir da an´alise de um conjunto de dados de treinamento conhecido, o algoritmo de aprendizado produz uma fun¸c˜ao inferida para fazer previs˜oes sobre os valores de sa´ıda. O sistema ´e capaz interpretar qualquer nova entrada ap´os treinamento suficiente. O algoritmo de aprendizado tamb´em pode comparar sua sa´ıda com a sa´ıda correta e planejada e encontrar erros para modificar o modelo de acordo. Em contraste, os algoritmos de aprendizado de m´aquina n˜ao supervisionados s˜ao usados quando as informa¸c˜oes utilizadas para treinamento n˜ao s˜ao classificadas nem rotuladas. A aprendizagem n˜ao supervisionada estuda como os sistemas podem inferir uma fun¸c˜ao para descrever uma estrutura oculta a partir de dados n˜ao rotulados. O sistema n˜ao calcula a sa´ıda correta, mas explora os dados e pode extrair inferˆencias de conjuntos de dados para descrever estruturas ocultas de dados n˜ao rotulados.
2.4.2 Redes neurais artificiais
As redes neurais artificiais s˜ao uma das principais ferramentas utilizadas no aprendizado de m´aquinas. Como a parte“neural”de seu nome sugere, eles s˜ao sistemas inspirados no c´erebro
que se destinam a replicar a maneira como os humanos aprendem. As redes neurais consistem em camadas de entrada e sa´ıda, bem como (na maioria dos casos) uma camada oculta que consiste em unidades que transformam a entrada em algo que a camada de sa´ıda pode usar. Eles s˜ao excelentes ferramentas para encontrar padr˜oes que s˜ao muito complexos ou numerosos para um programador humano extrair e ensinar a m´aquina a reconhecer.
Embora as redes neurais (tamb´em chamadas “perceptrons”) existam desde os anos 1940, ´e somente nas ´ultimas d´ecadas que elas se tornaram uma parte importante da inteligˆencia artificial. Isso se deve `a chegada de uma t´ecnica chamada ”retropropaga¸c˜ao”, que permite que as redes ajustem suas camadas ocultas de neurˆonios em situa¸c˜oes em que o resultado n˜ao corresponde ao que o criador espera - como uma rede projetada para reconhecer c˜aes, que identifica erroneamente um gato, por exemplo.
Outro avan¸co importante tem sido a chegada de redes neurais de aprendizagem pro-funda (deep learning neural networks), nas quais diferentes camadas de uma rede multicamada extraem diferentes caracter´ısticas at´e que ela possa reconhecer o que est´a procurando.
Para uma ideia b´asica de como uma rede neural de aprendizagem profunda aprende, imagine uma linha de f´abrica. Depois que as mat´erias-primas (o conjunto de dados) s˜ao inseridas, elas s˜ao passadas pela esteira transportadora, com cada parada ou camada subsequente extraindo um conjunto diferente de recursos de alto n´ıvel. Se a rede se destina a reconhecer um objeto, a primeira camada pode analisar o brilho de seus pixels.
Figura 4 – Representa¸c˜ao entrada e sa´ıda - rede neural artificial.
Fonte: Google imagens (2018)
A pr´oxima camada poderia identificar quaisquer arestas na imagem, com base em linhas de pixels semelhantes. Depois disso, outra camada pode reconhecer texturas e formas, e assim por diante. Quando a quarta ou quinta camada for atingida, a rede de aprendizagem
profunda ter´a criado detectores de recursos complexos. Ele pode descobrir que certos elementos da imagem (como um par de olhos, um nariz e uma boca) s˜ao comumente encontrados juntos.
Feito isso, os pesquisadores que treinaram a rede podem fornecer r´otulos para a sa´ıda e, em seguida, usar a retropropaga¸c˜ao para corrigir os erros cometidos. Depois de um tempo, a rede pode realizar suas pr´oprias tarefas de classifica¸c˜ao sem precisar de humanos para ajudar todas as vezes.
2.4.3 Deep Learning
O Deep Learning, tamb´em conhecido como aprendizado hier´arquico, ´e uma das partes do aprendizado de m´aquina e tem como objetivo aprender diferentes representa¸c˜oes dos dados de forma a facilitar a extra¸c˜ao de informa¸c˜oes em sistemas classificadores e preditores (BENGIO, 2014). ´E composto por algoritmos de alto n´ıvel de abstra¸c˜ao e multiplas transforma¸c˜oes n˜ao-lineares.
As redes neurais que aplicam o conceito de Deep Learning s˜ao denominadas Deep Neu-ral Networks (DNN).A estrutura b´asica das DNNs ´e similar `as redes tradicionais, diferenciando-se apenas pelo n´umero de camadas. Um maior n´umero de camadas resulta em uma representa¸c˜ao mais complexa e abstrata dos dados e consequentemente uma “profundidade” maior da rede. N˜ao h´a um consenso sobre o qu˜ao profundo um modelo precisa ser para ser qualificado como ”deep”. Contudo, o Deep Learning pode ser seguramente definido como o estudo de modelos que envolvem uma grande composi¸c˜ao de fun¸c˜oes ou conceitos aprendidos comparado ao aprendizado de m´aquina tradicional (GOODFELLOW; BENGIO; COURVILLE, 2017).
´
E tudo sobre escala. `A medida que constru´ımos redes neurais maiores e as treinamos com mais e mais dados, seu desempenho continua a aumentar. Isso geralmente ´e diferente de outras t´ecnicas de aprendizado de m´aquina que atingem um platˆo no desempenho.
2.4.4 TensorFlow
TensorFlow ´e uma biblioteca de software de c´odigo aberto para computa¸c˜ao num´erica de alto desempenho. Sua arquitetura flex´ıvel permite a f´acil implanta¸c˜ao de computa¸c˜ao em v´arias plataformas (CPUs, GPUs, TPUs) e de desktops a clusters de servidores para dispositivos m´oveis e perif´ericos. Originalmente desenvolvido por pesquisadores e engenheiros da equipe do Google Brain na organiza¸c˜ao de IA do Google, ele oferece um forte suporte para aprendizado de m´aquina e aprendizado profundo, e o n´ucleo flex´ıvel de computa¸c˜ao num´erica ´e usado em muitos outros dom´ınios cient´ıficos. O mecanismo de execu¸c˜ao distribu´ıdo do TensorFlow abstrai os muitos dispositivos suportados e fornece um n´ucleo de alto desempenho implementado em C ++ para a plataforma TensorFlow.
Em alto n´ıvel, TensorFlow ´e uma biblioteca Python que permite aos usu´arios ex-pressarem computa¸c˜ao arbitr´aria como um gr´afico de fluxos de dados. Os n´os neste gr´afico representam opera¸c˜oes matem´aticas, enquanto as arestas representam dados comunicados de um n´o para outro. Os dados no TensorFlow s˜ao representados como tensores, que s˜ao matrizes
Figura 5 – Pilha de software - TensorFlow.
Fonte: TensorFlow (2018)
multidimensionais. Embora essa estrutura para pensar sobre computa¸c˜ao seja valiosa em muitos campos diferentes, TensorFlow ´e usado principalmente para o aprendizado profundo (deep learning) em pesquisa e desenvolvimento.
2.4.5 Keras
Keras ´e uma API de redes neurais de alto n´ıvel, escrita em Python e capaz de rodar em cima do TensorFlow, CNTK ou Theano. Foi desenvolvida para tornar a implementa¸c˜ao de modelos de deep learning o mais r´apido e f´acil poss´ıvel para pesquisa e desenvolvimento. Compat´ıvel com Python 2.7 ou 3.5, pode ser executada perfeitamente em GPUs e CPUs, considerando as estruturas subjacentes.
Keras foi desenvolvida por Fran¸cois Chollet, um engenheiro do Google, usando quatro princ´ıpios orientadores:
• Modularidade: Um modelo pode ser entendido como uma sequˆencia ou um gr´afico sozinho. Todas as preocupa¸c˜oes de um modelo de deep learning s˜ao componentes discretos que podem ser combinados de maneiras arbitr´arias.
• Minimalismo: A biblioteca fornece apenas o suficiente para alcan¸car um resultado, sem frescuras e maximizando a legibilidade.
• Extensibilidade: Novos componentes s˜ao intencionalmente f´aceis de adicionar e usar dentro da estrutura, destinados a pesquisadores para testar e explorar novas ideias. • Python: Nenhum arquivo de modelo separado com formatos de arquivo personalizados.
2.4.6 LeNet
O LeNet foi uma das primeiras redes neurais convolucionais que ajudaram a impulsionar o campo do Aprendizado Profundo. Este trabalho pioneiro de Yann LeCun foi denominado LeNet5 ap´os muitas itera¸c˜oes anteriores bem sucedidas desde o ano de 1988 . Naquela ´epoca, a arquitetura LeNet era usada principalmente para tarefas de reconhecimento de caracteres, como leitura de CEPs, d´ıgitos, etc.
A arquitetura LeNet ´e simples e pequena (em termos de mem´oria ocupada), ela pode at´e mesmo rodar puramente em uma CPU, tornando-a uma ´otima arquitetura para aplica¸c˜oes envolvendo CNNs e sistemas embarcados (LECUN, 1998).
Camadas esparsas e convolucionais e pool m´aximo s˜ao o cora¸c˜ao da fam´ılia de modelos LeNet. Embora os detalhes exatos do modelo variem muito, a figura 6 mostra uma representa¸c˜ao gr´afica de um modelo LeNet.
Figura 6 – Representa¸c˜ao de um modelo LeNet.
Fonte: Google imagens (2018)
2.5 SISTEMA ANDROID
O Android ´e o sistema operacional m´ovel mais popular do mundo, utilizado em bilh˜oes de dispositivos, de telefones a rel´ogios, tablets, TVs, ve´ıculos e muito mais. ´E uma plataforma completa, de c´odigo aberto, envolve uma rica interface visual, diversas aplica¸c˜oes pr´e-instaladas e um ambiente de desenvolvimento poderoso que est´a sempre se atualizando.
Foi desenvolvido pela Open Handset Alliance (OHA), por empresas como Google, HTC, LG, Motorola, Samsung, Sony Ericsson, Toshiba e muitas outras, que tiveram por objetivo padronizar uma plataforma de c´odigo aberto e livre para celulares, para atender as necessidades do mercado atual (LECHETTA, 2010).
2.5.1 Android Studio
O Android Studio ´e um ambiente de desenvolvimento disponibilizado gratuitamente pelo Google para desenvolvedores Android. Baseado no IntelliJ IDEA, foi feito para incentivar a
cria¸c˜ao de aplicativos da mais alta qualidade. Ele oferece ferramentas personalizadas, incluindo ferramentas avan¸cadas de edi¸c˜ao, depura¸c˜ao, teste e cria¸c˜ao de perfis de c´odigo. Com ele qualquer um pode construir aplicativos para celulares, tablets, smartwatches, etc. A figura 7 apresenta a interface do Android Studio:
Figura 7 – Ambiente de Desenvolvimento Android Studio.
Fonte: Autoria pr´opria (2018)
Uma das peculiaridades mais interessantes do Android Studio ´e a execu¸c˜ao instantˆanea. Quando clicado em “Executar” ou “Depurar”, o recurso envia altera¸c˜oes de c´odigo ao aplicativo em execu¸c˜ao e as entrega sem reiniciar ou recriar o aplicativo.
Tamb´em conta com um editor de c´odigo inteligente que auxilia o desenvolvedor a escrever um c´odigo melhor, trabalhar mais r´apido e ser mais produtivo. Este, oferece preenchimento autom´atico de c´odigo e an´alise de erros antes da compila¸c˜ao.
2.5.2 Arquitetura Android
O Android ´e uma pilha de software baseada em Linux. A arquitetura ´e dividida em seis camadas: n´ucleo (kernel) Linux, camada de abstra¸c˜ao de hardware (HAL), Android Runtime (ART), bibliotecas nativas C/C++, framework da API JAVA e a camada de aplica¸c˜oes. A figura 8, a seguir, apresenta os principais componentes para cada camada:
A camada mais baixa da arquitetura, Linux kernel, ´e respons´avel por gerenciar os processos, threads, arquivos, diret´orios e drivers dos dispositivos. ´E a funda¸c˜ao da plataforma. Ela permite que o Android aproveite dos recursos de seguran¸ca existentes em Linux e que os fabricantes dos dispositivos desenvolvam drivers de hardware para um n´ucleo j´a conhecido.
Figura 8 – A pilha de software do Android.
Fonte: Android Developers (2018)
A HAL consiste em m´odulos de biblioteca, que servem de interface para certos componentes de hardware, como o m´odulo de cˆamera, modulo bluetooth, o acelerˆometro, etc. A HAL tamb´em fornece interfaces que exp˜oem as capacidades de hardware para a estrutura da API Java. Quando a API faz uma chamada para acessar o hardware do dispositivo, o sistema Android carrega o m´odulo da biblioteca para este componente de hardware.
Toda e qualquer aplica¸c˜ao em Android roda dentro de seu pr´oprio processo, isto ´
e, no contexto da sua instˆancia de m´aquina virtual, no caso o Android Runtime. O ART ´e projetado para que os dispositivos possam suportar m´ultiplas m´aquinas virtuais eficientemente. Ele executa arquivos com extens˜ao .dex - um tipo de Java bytecode otimizado para o Android.
Alguns dos recursos principais de ART s˜ao: Compila¸c˜ao AOT (Ahead-Of-Time) e JIT (Just-In-Time), coleta de lixo (Garbage Collector) otimizada, melhor suporte em depura¸c˜ao e vasta capacidade de definir watchpoints.
V´arios componentes e servi¸cos do sistema Android, como ART e HAL, s˜ao imple-mentados em c´odigo nativo e exigem bibliotecas nativas programadas em C e C++. Algumas dessas bibliotecas s˜ao descritas a seguir:
• Surface manager – gerencia o display
• Media Framework – biblioteca de m´ıdia para reprodu¸c˜ao de ´audio e v´ıdeo • SQLite – fornece suporte a banco de dados
• OpenGL | ES – bibliotecas gr´aficas para gr´aficos 2D e 3D
• FreeType – fornece suporte a opera¸c˜oes relacionadas a fontes de texto • SGL – bibliotecas gr´aficas
• WebKit – navegador da Web integrado e seguran¸ca da Internet • SSL – fornece seguran¸ca na Internet e no navegador da Web
• libc – ssuporte para servi¸cos espec´ıficos do Android, como propriedades do sistema O Android tamb´em cont´em um conjunto de bibliotecas que fornecem a maioria das funcionalidades da linguagem de programa¸c˜ao Java, inclusive alguns recursos da linguagem Java 8.
O framework da API JAVA fornece classes empregadas para criar os aplicativos. Ele tamb´em fornece uma abstra¸c˜ao gen´erica para acesso ao hardware e gerencia a interface do usu´ario e os recursos do aplicativo. A camada de aplica¸c˜ao ´e o local dos aplicativos executados sobre o sistema operacional. Nesta camada est´a localizada uma lista de aplica¸c˜oes padr˜oes como cliente de e-mail, programa de SMS, calend´ario, mapas, navegador, gerenciador de contato e qualquer aplicativo de terceiros.
2.5.3 Atividades
Atividade ou Activity ´e um componente de aplicativo que fornece uma tela com a qual os usu´arios podem interagir para fazer algo, como discar um n´umero no telefone, tirar uma foto, enviar um e-mail ou ver um mapa. Cada atividade recebe uma janela que exibe a interface do usu´ario. Geralmente a janela preenche toda a tela, mas pode ser que seja menor que a tela e ainda flutuar sobre outras janelas (ANDROID, 2018).
Geralmente um aplicativo ´e composto por v´arias atividades que se relacionam. Uma dessas atividades ´e especificada como ”principal”(main) e ´e apresentada ao usu´ario ao iniciar o aplicativo. Uma atividade pode inicializar e executar outra atividade para executar diferentes a¸c˜oes. Quando isto acontece o sistema conserva a atividade em uma ”pilha de retorno”. Esta pilha de retorno segue o mecanismo b´asico de pilhas LIFO (Last In First Out). Assim, quando o usu´ario terminar a atividade atual e apertar o bot˜ao Voltar, ela sair´a da pilha (sendo destru´ıda) e a atividade anterior ser´a retomada.
Figura 9 – Ciclo de vida da atividade.
Fonte: Android Developers (2018)
Quando uma atividade ´e interrompida devido ao in´ıcio de uma nova atividade, ela ´e notificada acerca dessa altera¸c˜ao de estado por meio de m´etodos de retorno de chamada do ciclo de vida da atividade. Cada retorno de chamada oferece uma oportunidade de executar trabalhos espec´ıficos adequados a essa altera¸c˜ao de estado. Por exemplo: quando interrompida, a atividade deve liberar todos os objetos grandes, como conex˜oes com a rede ou com um banco de dados. Quando a atividade for retomada, ser´a poss´ıvel readquirir os recursos necess´arios e retomar as a¸c˜oes interrompidas. Essas transi¸c˜oes de estado s˜ao parte do ciclo de vida da atividade apresentado na figura 9.
2.5.4 Android Manifest
O AndroidManifest.xml ´e um arquivo de existˆencia obrigat´oria no qual s˜ao acopladas as configura¸c˜oes gerais da aplica¸c˜ao e dos componentes utilizados por ela. ´E neste arquivo que
s˜ao definidos os nomes das activities, o modo de orienta¸c˜ao da tela, como os componentes que fazem parte da aplica¸c˜ao interagem entre si e como eles s˜ao declarados. Este arquivo lista tamb´em as permiss˜oes para utilizar recursos como GPS, acelerˆometro, acesso a internet, ativamento de notifica¸c˜oes e, por fim, define a hierarquia das activities.
2.6 SOCKETS
A conex˜ao por sockets tem origem em 1980, quando a ARPA (Advanced Research Pro-jects Agency, Agˆencia de Projetos de Pesquisa Avan¸cados), ´org˜ao do governo norte americano, forneceu recursos financeiros para que a Universidade da Calif´ornia Berkeley oferecesse uma implementa¸c˜ao UNIX do pacote de protocolos TCP/IP. O que foi desenvolvido ficou conhecido ent˜ao como interface de sockets de Berkeley.
Sockets s˜ao estruturas que habilitam que dois ou mais aplicativos do tipo cliente/ser-vidor, que est˜ao em rede, se conectem entre si. Um computador ´e chamado servidor (ele abre um socket e presta aten¸c˜ao `as conex˜oes), o outro computador denomina-se cliente (ele chama o socket servidor para iniciar a conex˜ao). Vide figura 10:
Figura 10 – Representa¸c˜ao de comunica¸c˜ao por sockets entre servidor e cliente.
Fonte: Autoria pr´opria (2018)
Utilizar sockets de internet ´e a maneira mais comum de executar a comunica¸c˜ao de rede entre servidor e cliente. Para conseguir fazer uma conex˜ao cliente-servidor, o servidor ter´a que conter um socket com uma porta dedicada para receber conex˜oes. ´E necess´ario ter conhecimento do n´umero de IP ou HOST do computador e o n´umero de porta do aplicativo ao qual se quer realizar a conex˜ao. O endere¸co IP identifica uma m´aquina espec´ıfica na Internet e o n´umero de porta ´e uma maneira de diferenciar os processos que est˜ao sendo executados no mesmo computador. Tipicamente o comportamento do servidor ´e ficar em um loop aguardando novas conex˜oes para atender as solicita¸c˜oes de clientes.
Os segmentos TCP s˜ao encapsulados e enviados em pacotes de dados. Uma forma de melhor visualizar o funcionamento de socket TCP seria compar´a-lo a uma liga¸c˜ao telefˆonica onde algu´em faz uma liga¸c˜ao para outra pessoa e quando esta atende, ´e criado um canal de comunica¸c˜ao entre os dois falantes.
3 PROCEDIMENTOS METODOL ´OGICOS
Este cap´ıtulo tem como finalidade descrever a metodologia e os procedimentos ado-tados na confec¸c˜ao deste projeto, bem como tamb´em realizar uma consolida¸c˜ao de todos os m´etodos aqui utilizados e apresentar o funcionamento do sistema como um todo. Para tal, os procedimentos metodol´ogicos foram divididos da seguinte forma: Raspberry Pi (Se¸c˜ao 3.1); Cˆamera USB (Se¸c˜ao 3.2); Criando um dataset, treinando e implantando a rede neural no sistema embarcado (Se¸c˜ao 3.3); Desenvolvimento do aplicativo Android (Se¸c˜ao 3.4); Estabelecendo modelo cliente e servidor (Se¸c˜ao 3.5); Algoritmos e C´odigos (Se¸c˜ao 3.6).
3.1 RASPBERRY PI
O sistema embarcado selecionado para realizar o projeto foi o Raspberry Pi 3, conforme figura 11. Essa sele¸c˜ao se d´a por diversos motivos:
• Sistema com alto poder de processamento; • Boa rela¸c˜ao custo x benef´ıcio;
• Versatilidade;
• Facilidade de implementa¸c˜ao.
Figura 11 – Raspberry Pi 3.
Fonte: Magpi (2016)
A Raspberry Pi 3 possui 1 microprocessador ARM Cortex A53 de 1,2 GHz com 4 n´ucleos e um microprocessador de v´ıdeo no mesmo chip, da fabricante Broadcom, uma mem´oria RAM de 1 GB, al´em da conectividade 802.11n Wi-Fi. Foi instalado na placa o sistema operacional Raspbian.
Por comodidade, todo o acesso da Raspberry no projeto ´e feito por Secure Shell (SSH), de forma a possibilitar o acesso remoto `a placa e n˜ao necessitando de conex˜oes f´ısicas nela como de um monitor, al´em de perif´ericos como teclado e mouse. Isso torna a utiliza¸c˜ao da placa muito pr´atica, pois ´e poss´ıvel realizar toda a sua programa¸c˜ao atrav´es da rede. A placa foi conectada `a rede atrav´es da interface de rede wireless. Um dos softwares desenvolvidos no projeto para a Raspberry foi programado na linguagem Python e outro em Java.
3.2 CˆAMERA USB
Uma cˆamera USB consiste em basicamente uma cˆamera de v´ıdeo digital que transmite todo seu fluxo de dados de v´ıdeo atrav´es de sua interface USB. Este tipo de cˆamera foi escolhida pela sua facilidade de transmiss˜ao de dados para qualquer dispositivo, inclusive para o escolhido sistema embarcado. Na figura 12 observa-se a cˆamera do projeto.
Figura 12 – Cˆamera USB (Logitech C270) utilizada.
Fonte: Logitech (2018)
A cˆamera, da fabricante Logitech, modelo C270, foi escolhida pelo fato de j´a ser possu´ıda por um dos membros da equipe. A cˆamera cont´em conex˜ao USB 2.0 de alta velocidade e filma em resolu¸c˜ao 1280 x 960 pixels, podendo alcan¸car um frame rate de at´e 30 FPS em uma configura¸c˜ao inferior (640 x 480).
3.3 REDE NEURAL CONVOLUCIONAL
Redes neurais convolucionais (CNNs) s˜ao a atual arquitetura de modelo de ´ultima gera¸c˜ao para tarefas de classifica¸c˜ao de imagens. As CNNs aplicam uma s´erie de filtros aos dados de pixel brutos de uma imagem para extrair e aprender recursos de n´ıvel mais alto, que o modelo pode usar para classifica¸c˜ao. CNNs cont´em trˆes componentes:
Camadas convolucionais, que aplicam um n´umero especificado de filtros de convolu¸c˜ao `
a imagem. Para cada sub-regi˜ao, a camada executa um conjunto de opera¸c˜oes matem´aticas para produzir um ´unico valor no mapa de recursos de sa´ıda. Camadas convolucionais ent˜ao tipicamente aplicam uma fun¸c˜ao de ativa¸c˜ao ReLU na sa´ıda para introduzir n˜ao-linearidades no modelo.
Agrupamento de camadas, que reduz a resolu¸c˜ao dos dados da imagem extra´ıdos pelas camadas convolucionais para reduzir a dimensionalidade do mapa de recursos para diminuir o tempo de processamento. Um algoritmo de pooling comumente usado ´e o pool m´aximo, que extrai sub-regi˜oes do mapa de recursos (por exemplo, blocos de 2x2 pixels), mant´em seu valor m´aximo e descarta todos os outros valores.
Camadas densas (totalmente conectadas), que realizam a classifica¸c˜ao nas caracte-r´ısticas extra´ıdas pelas camadas convolucionais e diminu´ıdas pelas camadas de agrupamento. Em uma camada densa, todos os n´os da camada s˜ao conectados a todos os n´os da camada anterior.
Normalmente, uma CNN ´e composta de uma pilha de m´odulos convolucionais que executam a extra¸c˜ao de recursos. Cada m´odulo consiste em uma camada convolucional seguida por uma camada de pooling. O ´ultimo m´odulo convolucional ´e seguido por uma ou mais camadas densas que executam a classifica¸c˜ao. A camada densa final em uma CNN cont´em um ´unico n´o para cada classe alvo no modelo (todas as classes poss´ıveis que o modelo pode prever), com uma fun¸c˜ao de ativa¸c˜ao softmax para gerar um valor entre 0 e 1 para cada n´o (a soma de todos esses valores softmax s˜ao iguais a 1). Podemos interpretar os valores softmax para uma determinada imagem como medidas relativas de como ´e prov´avel que a imagem caia em cada classe alvo.
3.3.1 Criando um dataset
Sem dados de treinamento suficientes, os modelos de machine e deep learning n˜ao podem aprender os padr˜oes subjacentes e discriminativos necess´arios para criar classifica¸c˜oes robustas. Algoritmos de deep learning, especialmente Redes Neurais Convolucionais (CNN), necessitam de uma grande quantidade de dados para se tornarem vi´aveis.
Para este projeto, foi montado um dataset de 500 imagens contendo fogo, as quais serviram de exemplo positivo e, outras 500 imagens aleat´orias as quais n˜ao continham fogo, consideradas exemplos negativos, permitindo a rede diferenciar ambientes com fogo de ambientes sem fogo. Posteriormente ainda utilizamos um dataset contendo outras 100 imagens, com e
sem fogo, para aferir a acertividade da rede neural.
Para evitar a necessidade de selecionar e realizar o download de imagem por imagem, utilizou-se o Google Imagens como reposit´orio, e uma combina¸c˜ao de JavaScript e Python para a realiza¸c˜ao do download e verifica¸c˜ao das imagens.
Para encontrar imagens de exemplo positivo inserimos, no Google Imagens, termos de consulta que arremetem a fogo, tais como “casa em chamas” e “incˆendio”. Na figura 13 pode-se observar as imagens encontradas ao se inserir o termo de pesquisa “velas queimando” no Google Imagens.
Figura 13 – Busca google imagens - velas acesas.
Fonte: Google Imagens (2018)
Selecionado os termos de pesquisa, foi utilizado um c´odigo em JavaScript para reunir as URLs das imagens exibidas pelo Google Imagens e salv´a-las em um arquivo texto.
Figura 14 – C´odigo para salvar as URLs das imagens exibidas.
Fonte: Autoria pr´opria (2018)
Foi utilizado um programa em Python para o download, a partir das URLs salvas no arquivo texto, de todas as imagens exibidas pelo Google Imagens ap´os a inser¸c˜ao dos termos
de pesquisa citados anteriormente. O c´odigo foi desenvolvido de maneira a salvar a primeira imagem com o nome 00000000.jpg e, seguindo este template, incrementar o nome das pr´oximas imagens. Ter as imagens nomeadas em sequˆencia simplifica o processo de treinamento da rede neural. Se algum erro for encontrado durante a execu¸c˜ao, a exce¸c˜ao ser´a tratada e uma mensagem ser´a impressa no terminal.
Figura 15 – Estrutura dos diret´orios contendo as imagens do dataset.
Fonte: Autoria pr´opria (2018)
Figura 16 – C´odigo Python para download das imagens.
Fonte: Autoria pr´opria (2018)
N˜ao obstante, ao finalizar o download das imagens, o programa testa cada uma das imagens com um comando da biblioteca OpenCV. Caso haja alguma falha durante esta execu¸c˜ao, o programa ir´a deletar a imagem, de maneira a expurgar imagens corrompidas do dataset.
Figura 17 – C´odigo respons´avel pela verifica¸c˜ao da integridade das imagens baixadas.
Fonte: Autoria pr´opria (2018)
Figura 18 – Download das imagens pelo terminal Anaconda.
Fonte: Autoria pr´opria (2018)
3.3.2 Modelando a rede neural
Para a constru¸c˜ao do nosso modelo de rede neural utilizamos do modelo sequˆencial do Keras, visto que a API sequencial permite criar modelos camada por camada para a maioria dos problemas. ´E limitado porque n˜ao permite criar modelos que compartilhem camadas ou tenham v´arias entradas ou sa´ıdas, por´em n˜ao ´e um fator limitante para este projeto, visto que n˜ao necessitamos de m´ultiplas sa´ıdas e entradas. Assim, modelamos a rede neural da seguinte maneira:
• Camada Convolucional # 1: Aplica 20 filtros 5x5 (extraindo sub-regi˜oes de 5x5 pixels), com fun¸c˜ao de ativa¸c˜ao ReLU.
• Camada de Pooling # 1: Executa o pool m´aximo com um filtro 2x2 e stride de 2 (o que especifica que as regi˜oes agrupadas n˜ao se sobrep˜oem).
• Camada Convolucional # 2: Aplica 50 filtros 5x5, com fun¸c˜ao de ativa¸c˜ao ReLU. • Camada de Pooling # 2: Novamente, realiza o pool m´aximo com um filtro 2x2 e um
passo de 2.
• Camada Densa # 1: 500 neurˆonios.
• Camada Densa # 2 (Camada de Logits): 2 neurˆonios, um para cada classe alvo, ‘fogo’ e ‘n˜ao fogo’.
Os m´etodos utilizados na cria¸c˜ao dos trˆes tipos de layers necess´arios para a nossa rede neural foram os seguintes:
• conv2d () - Constr´oi uma camada convolucional bidimensional. Obt´em o n´umero de filtros, o tamanho do kernel do filtro, o preenchimento e a fun¸c˜ao de ativa¸c˜ao como argumentos.
• max pooling2d () - Constr´oi uma camada de pool bidimensional usando o algoritmo de pool m´aximo. Leva o tamanho do filtro de pool e stride como argumentos.
• dense() - Constr´oi uma camada densa. Leva n´umero de neurˆonios e fun¸c˜ao de ativa¸c˜ao como argumentos.
Cada um desses m´etodos aceita um tensor como entrada e retorna um tensor transfor-mado como sa´ıda, de maneira que basta pegar a sa´ıda do m´etodo de cria¸c˜ao de uma camada e fornecˆe-la como entrada para outra.
Figura 19 – C´odigo respons´avel pela constru¸c˜ao do classificador de imagens Keras.
Fonte: Autoria pr´opria (2018)
3.3.3 Treinando a rede neural
Keras ´e uma poderosa biblioteca Python f´acil de usar para desenvolvimento e avalia¸c˜ao de modelos de aprendizagem profunda. Ele envolve a eficiente biblioteca de computa¸c˜ao num´erica TensorFlow e nos permite definir e treinar modelos de redes neurais em algumas linhas curtas de c´odigo. E atrav´es desta combina¸c˜ao de Keras e TensorFlow que criamos o arquivo train network.py para carregar, definir, compilar e avaliar nosso modelo de rede neural.
Figura 20 – Bibliotecas utilizadas no arquivo train network.py.
Fonte: Autoria pr´opria (2018)
Na figura 21 observamos dois argumentos de linha de comando obrigat´orios, -dataset e -model, bem como um caminho opcional para nosso gr´afico de precis˜ao / perda, -plot.
Figura 21 – C´odigo respons´avel pela entrada dos argumentos.
Fonte: Autoria pr´opria (2018)
A op¸c˜ao -dataset deve apontar para o diret´orio que cont´em as imagens nas quais estaremos treinando nosso classificador de imagens (ou seja, as imagens ”Santa”e ”N˜ao Santa”) enquanto a op¸c˜ao -model controla onde salvaremos nosso classificador de imagem serializado depois de ter sido treinado.
Na figura 22 definimos algumas vari´aveis de treinamento, inicializamos listas e reunimos caminhos para imagens.
Quantidade de epochs, taxa de aprendizagem, tamanho do batch e itera¸c˜oes s˜ao determinadas de acordo com o algoritmo de otimiza¸c˜ao iterativo gradiente descendente. Onde batch ´e a quantidade de pacotes de imagens utilizadas no treinamento da rede neural, neste caso, nosso total de imagens ser´a divido em 32 batches. J´a a vari´avel epoch determina quantas vezes nosso dataset ir´a passar pela rede neural, ou seja, neste caso, iremos passar todos os 32 batches pela rede neural 25 vezes. A taxa de aprendizado inicial determina a velocidade com que os pesos do gradiente descendente mudam, tentando eviar uma sobrecorre¸c˜ao em cada itera¸c˜ao da rede neural durante o treinamento. Todos os parˆametros aqui citados s˜ao conhecidos como hiper-parˆametros, portanto seus valores s˜ao definidos atrav´es de testes e ajustes finos.
Figura 22 – C´odigo de inicializa¸c˜ao das vari´aveis de treinamento, listas e diret´orios.
Fonte: Autoria pr´opria (2018)
Em seguida, conforme ilustrado na figura 23, realizamos o pr´e-processamento das imagens.
Figura 23 – C´odigo para pr´e-processamento das imagens.
Fonte: Autoria pr´opria (2018)
O loop da figura 23 simplesmente carrega e redimensiona cada imagem para 28x28 pixels fixos (as dimens˜oes espaciais necess´arias para o LeNet) e acrescenta o array de imagem `
a lista de dados, seguido pela extra¸c˜ao do r´otulo de classe do imagePath.
Podemos executar essa extra¸c˜ao de r´otulo de classe pois a estrutura de diret´orios do conjunto de dados ´e organizada da seguinte maneira:
Portanto, de um exemplo de imagePath: • images/fire/00000042.jpg
Depois de extrair o r´otulo, o resultado ser´a: • fire
A organiza¸c˜ao de conjuntos de dados de imagens de aprendizado profundo dessa maneira nos permite organizar eficientemente nosso conjunto de dados e analisar r´otulos de classe sem a necessidade de usar um arquivo de ´ındice/pesquisa separado.
Figura 24 – Estrutura do diret´orio do dataset.
Fonte: Autoria pr´opria (2018)
Em seguida, n´os pr´e-processamos nossos dados de entrada alterando a escala dos pontos de dados de [0, 255] (os valores RGB m´ınimo e m´aximo da imagem) para o intervalo [0, 1]. Realizamos uma divis˜ao de treinamento/teste nos dados usando 75% das imagens para treinamento e 25% para testes. Essa ´e uma divis˜ao t´ıpica para essa quantidade de dados. Tamb´em convertemos r´otulos em vetores usando uma codifica¸c˜ao simples.
Figura 25 – C´odigo para alterar escala das imagens e criar splits.
Fonte: Autoria pr´opria (2018)
Posteriormente, executamos alguns aumentos de dados, permitindo gerar dados de treinamento adicionais e transformando aleatoriamente as imagens de entrada usando os parˆametros abaixo.
Keras fornece a classe ImageDataGenerator, a qual define a configura¸c˜ao para pre-para¸c˜ao e aumento de dados de imagem. Em vez de executar as opera¸c˜oes em todo o seu conjunto de dados de imagem na mem´oria, a API foi projetada para ser iterada pelo processo de ajuste do modelo de aprendizado profundo, criando dados de imagem aumentados just-in-time. Isso reduz a sobrecarga de mem´oria, mas adiciona algum custo de tempo adicional durante o
Figura 26 – Cria¸c˜ao de dados atrav´es da ImageDataGenerator().
Fonte: Autoria pr´opria (2018)
treinamento do modelo.
Essencialmente, a ImageDataGenerator cria um objeto gerador de imagens que executa rota¸c˜oes aleat´orias, espelhamento, invers˜oes, desvios e varia¸c˜oes em nosso conjunto de dados de imagens. Isso nos permite alcan¸car bons resultados mesmo com um conjunto de dados menor.
A LeNet foi a arquitetura selecionada, dentre diversos fatores, principalmente por ser pequena, possibilitando o treinamento da mesma em um computador com uma GPU simples e em um curto espa¸co de tempo, ao passo que arquiteturas mais complexas necessitam de computadores com GPUs de ´ultima gera¸c˜ao e, ainda sim, levam dias para serem treinadas.
Constru´ımos nosso modelo LeNet com o otimizador Adam. Como esse ´e um problema de classifica¸c˜ao de duas classes, optamos pela entropia cruzada bin´aria como nossa fun¸c˜ao de perda.
Figura 27 – C´odigo para inicializar, treinar e salvar modelo de rede.
Fonte: Autoria pr´opria (2018)
O treinamento da rede ´e iniciado quando chamamos model.fit generator, fornecendo nosso objeto de aumento de dados, dados de treinamento, teste e o n´umero de epochs pelos quais queremos treinar. Em sequˆencia, salvamos o modelo em disco, para depois utilizarmos nosso classificador de imagens sem a necessidade de reconstruir o modelo.
Utilizando-se do terminal de comando Anaconda, executamos o c´odigo train network.py afim de inicializar, treinar e compilar nosso modelo de rede neural.
A rede treinou por 25 epochs e obtivemos 96,45% de precis˜ao nos testes e baixa perda de treinamento, vide figuras 28 e 29.
Figura 28 – Rede neural com 26 epochs e precis˜ao de 96,45%.
Fonte: Autoria pr´opria (2018)
Figura 29 – Treinamento de redes neurais - precis˜ao e perdas.
3.4 APLICATIVO ANDROID
O aplicativo foi desenvolvido nas linguages Java e XML, ambas linguagens oficiais do ambiente de desenvolvimento Android Studio. Utiliza-se a linguagem XML para construir o layout da activity, ou seja, a interface do usu´ario. OJava geralmente ´e utiliizado para desenvolver as fun¸c˜oes da aplica¸c˜ao, mas det´em liberdade e pode ser empregado para alterar os elementos da interface j´a que as linguagens trabalham em conjunto e est˜ao interligadas.
Para o aplicativo existem duas fun¸c˜oes de grande importˆancia: avisar o usu´ario sobre um poss´ıvel perigo e providenciar acesso direto `a visualiza¸c˜ao da cˆamera digital. A visualiza¸c˜ao da cˆamera ´e disponibilizada em tempo real para que o usu´ario possa confirmar a veracidade de um poss´ıvel incˆendio ou evento. Para que o usu´ario interaja com o sistema, receba a notifica¸c˜ao ou acesse a imagem da cˆamera, ´e necess´ario que o celular tenha conectividade com a internet. As duas grandes fun¸c˜oes mencionadas acima foram desenvolvidas separadamente em duas activities:
• MainActivty • CameraActivity
A MainActivity ´e respons´avel por alertar o usu´ario sobre qualquer mudan¸ca que aconte¸ca no estado do sistema. Para este projeto existem trˆes estados de seguran¸ca (NORMAL, WARNING, DANGER!) alter´aveis `a efeito da interpreta¸c˜ao e do resultado obtido pela rede neural.
Figura 30 – Diferentes estados do aplicativo TCC - Fire Alarm.
Fonte: Autoria pr´opria (2018)
O estado NORMAL ´e essencialmente o modo ocioso da aplica¸c˜ao. Resultado de uma mudan¸ca caso n˜ao haja mais perigo ou risco de fogo, ou aparente na inicializa¸c˜ao do aplicativo quando, at´e o momento, nada foi exposto ao sistema.
Dissemelhante, o estado DANGER! ´e ativado logo ap´os o algoritmo de interpreta¸c˜ao verificar alguma chama ou luz muito forte. Neste caso uma notifica¸c˜ao com prioridade alta ´e gerada e enviada ao dispositivo Android. O estado do sistema ´e alterado imediatamente para uma cor chamativa, tamb´em com o intuito de induzir o usu´ario que um problema real est´a em
quest˜ao. O sistema continua notificando o usu´ario at´e que algum contato com o aplicativo seja realizado. A figura31 representa a mensagem de notifica¸c˜ao deste estado.
Figura 31 – Notifica¸c˜ao gerada pela troca ao estado DANGER!
Fonte: Autoria pr´opria (2018)
De maneira an´aloga, o estado WARNING, tamb´em troca a cor e o texto da barra de ”status” e gera uma notifica¸c˜ao, mas para entrar neste caso a o algoritmo de rede neural tem que estar indeciso se o que est´a sendo interpretado ´e realmente um incˆendio. Essa notifica¸c˜ao, enviada do aplicativo ao smartphone, tem o intuito de criar um acesso r´apido `a tela CameraActivity, vide figura 32. Assim, o usu´ario tem agilidade para verificar se realmente existe um problema em evidˆencia ou se uma m´a interpreta¸c˜ao do algoritmo ou um alarme falso foi concebido. Clicar em cima desta notifica¸c˜ao abre diretamente a tela de visualiza¸c˜ao da cˆamera.
Figura 32 – Notifica¸c˜ao gerada pela troca ao estado WARNING.
Fonte: Autoria pr´opria (2018)
Outra maneira de acessar a visualiza¸c˜ao da cˆamera ´e clicando no bot˜ao ”View Camera”, que, coloca a MainActivity em segundo plano (na pilha de atividades) e imp˜oe a CameraActivity em evidˆencia. Esta atividade tem a fun¸c˜ao de apresentar o conte´udo da cˆamera digital em tempo real. Para isso, disp˜oe de uma l´ogica de acesso a uma p´agina internet, onde o conte´udo da cˆamera est´a sendo transmitido.
O v´ıdeo ´e transmitido do Raspberry Pi. No Android utilizamos a engine WebKit, que fornece um conjunto de classes com a finalidade de exibir o conte´udo de uma p´agina na internet. Basicamente, a classe WebView possibilita re-criar todo o conte´udo de um site para o modelo de visualiza¸cao do aplicativo, vide figura 33.
O fluxograma 34 explica de maneira mais simplificada como a MainActivity ´e executada, qual a sua l´ogica de programa¸c˜ao e quais s˜ao os seus principais processos e m´etodos utilizados. As notifica¸c˜oes enviadas para o usu´ario s˜ao criadas no aplicativo logo ap´os a solicita¸c˜ao do cliente ser interpretada. Isto ser´a explicado em detalhes no item 3.5.
Figura 33 – Visualiza¸c˜ao da CameraActivity.
Fonte: Autoria pr´opria (2018)
Figura 34 – Fluxograma simplificado da MainActivity.
3.5 MODELO CLIENTE-SERVIDOR
Para a comunica¸c˜ao entre as duas partes, foi utilizado o modelo cliente-servidor. O Raspberry Pi executa a aplica¸c˜ao de cliente, enquanto o aplicativo Android o outro. Para isto foi utilizado as classes Socket e ServerSocket do pacote java.net.
A classe Socket implementa a parte do cliente e ´e utilizada para se conectar a um host remoto. De outra parte, um objeto da classe ServerSocket aguarda a chegada de solicita¸c˜oes pela rede. Na utiliza¸c˜ao destas classes e, de modo que ´e necess´ario enviar e receber mensagens com exatid˜ao, utiliza-se as estruturas de InputStreams e OutputStreams, obtido atrav´es dos m´etodos Socket.getInputStream() e Socket.getOutputStream().
Como a aplica¸c˜ao de cliente foi desenvolvida em Java e o software de detec¸c˜ao de fogo em Pyhton, foi necess´ario realizar chamadas de sistema que, no caso, invocam uma solicita¸c˜ao do Raspberry pi para o servidor sempre que um evento ou perigo ´e detectado. O servidor est´a hospedado em uma thread que ´e instanciada no in´ıcio da atividade principal do aplicativo Fire Alarm e fica ativa esperando um contato da parte do cliente. Desse modo ocorre a comunica¸c˜ao entre as duas partes e como consequˆencia o estado do sistema ´e notificado ao usu´ario.
3.6 ALGORITMOS E C ´ODIGOS
Nesta se¸c˜ao ser˜ao explicados com mais detalhes os algoritmos e c´odigos utilizados para a constru¸c˜ao totalit´aria deste sistema de detec¸c˜ao e alarme de incˆendio.
3.6.1 Implementa¸c˜ao no Raspberry Pi
o Raspberry Pi n˜ao ´e adequado para treinar uma rede neural. No entanto, ele pode ser usado para implantar uma rede neural depois de j´a ter sido treinada, desde que o modelo possa caber em um espa¸co de mem´oria pequeno e compat´ıvel com o Raspberry Pi.
J´a que n˜ao h´a uma distribui¸c˜ao oficial do TensorFlow para Raspberry Pi, decidimos utilizar os bin´arios pr´e-compilados criados por Sam Abrahams
Figura 35 – Comandos utilizados para instala¸c˜ao do TensorFlow no Raspberry Pi.
Fonte: Autoria pr´opria (2018)
Uma vez que o TensorFlow se encontra instalado e compilado, instalamos o HDF5 e o h5py, bibliotecas que nos permitir˜a carregar nosso modelo pr´e-treinado a partir do cart˜ao SD:
Para finalizar, instalamos o Keras, Imutils e Scipy, necess´arias para a executa¸c˜ao deste projeto:
Figura 36 – Comandos utilizados para instala¸c˜ao das bibliotecas HDF5 e h5py no Raspberry Pi.
Fonte: Autoria pr´opria (2018)
Figura 37 – Comandos utilizados para instala¸c˜ao das bibliotecas HDF5 e h5py no Raspberry Pi.
Fonte: Autoria pr´opria (2018)
Para testar se o ambiente estava corretamente configurado e com todas as bibliotecas compiladas, executamos os seguintes comandos no Raspberry Pi:
Figura 38 – Comandos utilizados para instala¸c˜ao das bibliotecas HDF5 e h5py no Raspberry Pi.
Fonte: Autoria pr´opria (2018)
3.6.2 Inicializa¸c˜ao do sistema
Com o sistema configurado, criamos o programa fire detector.py, o qual ir´a rodar no Raspberry Pi e ser´a respons´avel por carregar a rede neural (.model) e realizar toda a
comunica¸c˜ao com o sistema embarcado, obtendo os frames da camˆera, alimentando a rede neural com as imagens obtidas e mantendo o pipeline de comunica¸c˜ao com o servidor Android ativo, o informando de eventuais eventos detectados pelo sistema.
Figura 39 – Comandos utilizados para importar as bibliotecas j´a compiladas no Raspberry Pi.
Fonte: Autoria pr´opria (2018)
Figura 40 – Declara e importa o modelo de rede neural a ser utilizado pelo Raspberry Pi.
Fonte: Autoria pr´opria (2018)
Tamb´em inicializamos os parˆametros usados para detec¸c˜ao, que incluem TOTAL CONSEC e TOTAL THRESH. Esses dois valores representam o n´umero de quadros que contˆem fogo e o limite no qual enviaremos uma notifica¸c˜ao de alarme de incˆendio ao servidor. A ´ultima inicializa¸c˜ao, booleana, ´e FIRE = False. Utilizamos a vari´avel FIRE posteriormente no script como um sinalizador de status para ajudar na l´ogica de detec¸c˜ao.
Figura 41 – C´odigo de inicializa¸c˜ao e parametriza¸c˜ao do sistema de detec¸c˜ao de incˆendio.
Em sequˆencia, carregamos o modelo da rede neural no Raspberry e inicializamos a cˆamera.
Figura 42 – C´odigo de carregamento do modelo de rede e inicializa¸c˜ao da cˆamera.
Fonte: Autoria pr´opria (2018)
3.6.3 Obten¸c˜ao do frame da cˆamera e classifica¸c˜ao das imagens
Realizada a inicializa¸c˜ao da cˆamera atrav´es da fun¸c˜ao VideoStream da biblioteca Imutils, utilizamos a fun¸c˜ao vs.read para capturar frame por frame do stream de v´ıdeo.
Figura 43 – C´odigo de captura de frames da stream de v´ıdeo.
Fonte: Autoria pr´opria (2018)
Pr´e-processamos cada frame antes de envi´a-los atrav´es do nosso modelo de rede neural, portanto, em seguida, redimensionamos o quadro para width = 400, mantendo a propor¸c˜ao, e preparamos a imagem para envio a rede. A partir da´ı, chamamos model.predict com nossa imagem como argumento. Isso envia a imagem atrav´es da rede neural, retornando um tuple contendo probabilidades de classe, sendo elas Fire e noFire. O sistema ´e inicializado com o label No Fire e probalidade noFire, evitando o envio de um alarme falso durante a inicializa¸c˜ao do sistema.
Em sequˆencia, o c´odigo verifica se existe fogo na imagem comparando a probabilidade de Fire (fogo na imagem) com a probabilidade de noFire (sem sinais de fogo na imagem). Se a probabilidade de existir fogo for maior que a de n˜ao exisitir fogo no frame, o label e a probabilidade (proba) s˜ao atualizados para Fire e a vari´avel TOTAL CONSEC ´e incrementada de maneira a nos possibilitar contar quantos frames consecutivos acusaram a existˆencia de fogo.
Verificada a existˆencia de fogo em uma quantidade suficiente de frames consecutivos, o alarme de incˆendio ´e acionado.
Figura 44 – C´odigo para pr´e-processamento e envio dos frames para a rede neural.
Fonte: Autoria pr´opria (2018)
Figura 45 – C´odigo de classifica¸c˜ao das imagens.
Fonte: Autoria pr´opria (2018)
Figura 46 – C´odigo de acionamento do alarme.
Fonte: Autoria pr´opria (2018)
Caso contr´ario, (FIRE ´e TRUE ou TOTAL THRESH n˜ao ´e atendido), zeramos TOTAL CONSEC para zero e FIRE para False.
Figura 47 – Reinicializa¸c˜ao da contagem de frames consecutivos.
Fonte: Autoria pr´opria (2018)
Por fim, exibimos os frames em nossa tela. Utilizando o cv2.putText do OpenCV, podemos escrever o r´otulo na parte superior do quadro antes de exibir a imagem na tela, assim o valor de probabilidade ´e anexado ao r´otulo contendo ”Fire”ou ”Not Fire”, como exemplificado na figura 49, em que a rede neural indica a existˆencia de fogo na lareira com 93,88% de confian¸ca.
Figura 48 – Constru¸c˜ao do frame para exibi¸c˜ao na tela.
Fonte: Autoria pr´opria (2018)
Figura 49 – Detec¸c˜ao de fogo na imagem com 93,88% de confian¸ca.
Fonte: Autoria pr´opria (2018)
3.6.4 Envio de evento e recebimento de notifica¸c˜ao
Toda vez que o sistema identifica uma mudan¸ca de estado, seja esta com um risco maior ou menor de seguran¸ca o usu´ario ´e notificado. Para que o usu´ario seja notificado, o Raspberry Pi cria um Socket que ´e associado ao aplicativo Android pelo IP destino (Ex: 192.168.100.52) e ent˜ao envia um fluxo de dados, exibido em detalhes na figura 50.
A MainActivity ´e respons´avel por interpretar essas mensagens e notificar o usu´ario. Para isto, uma thread fica ativa com a fun¸c˜ao de servidor esperando qualquer requisi¸c˜ao do cliente. Quando uma requisi¸c˜ao ´e interpretada pelo aplciativo Android o estado do layout ´e alterado e o sistema entra em atua¸c˜ao. O aparelho ent˜ao come¸ca a vibrar e bipar com o intuito de chamar a aten¸c˜ao do usu´ario. E o sistema s´o entra em repouso ap´os outra intera¸c˜ao do usu´ario, consentindo que a notifica¸c˜ao foi recebida e que est´a ciente da altera¸c˜ao do estado de perigo.
