Universidade Federal do Rio Grande do NorteInstituto Metrópole Digital

SmartMetropolis – Plataforma e Aplicações para Cidades Inteligentes

WP3 – Sensoriamento

Relatório de Atividades - T1

Natal-RN, BrasilAbril/2017

Equipe TécnicaDocentes

Prof. Dr. Allan Martins - DEE/UFRNProf. MSc. Aluízio F. Rocha Neto - IMD/UFRNProf. Dr. Diomadson Belfort - IMD/UFRNProf. Dr. Gustavo Girão - IMD/UFRNProf. Dr. Leonardo Miranda - DIMAp/UFRNProf. Dr. Ivanovitch Silva (Coordenador) – IMD/UFRNProf. MSc. Wellington Silva de Souza - IMD/UFRN

DiscentesAnderson de Araujo SantosBianor Galdino de Lima NetoDanilo Costa BarrosElton de Souza VieiraJoilson AbrantesLeonardo Augusto de Aquino MarquesRafael Pereira ClementeRaphaela Kethlim Souza SilvaThaís Alves de FreitasVinícius Campos Tinoco RibeiroVitor Rodrigues Greati

3

Sumário1 Introdução 7

2 Monitoramento de Frotas 72.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 OBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Modos de operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 APIs e bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Hardwares de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1 Placas de escaneamento: ELM327 e STN1110 . . . . . . . . . . . . . . . . . . 102.3.2 CC3200 vs ESP32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Arquitetura Geral da Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.1 SmartFleet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.2 SmartFleet Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.3 Hardware de captura de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 Próximos Passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Detecção de placas 223.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 OpenALPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2 Experimentos e resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Método próprio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.1 Detecção da placa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.2 Processamento pré-segmentação . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.3 Segmentação dos caracteres . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.4 Reconhecimento ótico dos caracteres . . . . . . . . . . . . . . . . . . . . . . . 283.3.5 Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.6 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Próximos Passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Estacionamento inteligente 314.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Perpectivas Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3 Soluções de Processamento de Imagens . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.1 Smart Parking System using Image Processing Techniques in Wireless SensorNetwork Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.2 Intelligent Parking Space Detection System Based on Image Processing . . . . . 344.3.3 Intelligent Parking Management System Based on Image Processing . . . . . . . 354.3.4 A Marker-Based Image Processing Method for Detecting Available Parking Slots

from UAVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3.5 A Method of Parking Space Detection Based on Image Segmentation and LBP . 364.3.6 Car Parking Vacancy Detection and Its Application in 24-Hour Statistical Analysis 364.3.7 A Multi-Classifier Image Based Vacant Parking Detection System . . . . . . . . 36

4.4 Full-automatic recognition of various parking slot markings using a hierarchical treestructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Protótipo para Detecção de Objetos em Cena . . . . . . . . . . . . . . . . . . . . . . . 374.6 Tecnologias de Infraestrutura de Software . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6.1 Tecnologias Para o Serviço Web . . . . . . . . . . . . . . . . . . . . . . . . . . 384.6.2 Tecnologias Para o Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . 40

4.7 Progresso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.8 Próximos Passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Considerações Finais 42

6 Referências 43

Lista de Figuras1 Localizações comuns do conector OBD-II no veículo. . . . . . . . . . . . . . . . . . . . 82 Conector OBD II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Pinagem do conector OBD II. [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Placa da Sparkfun que utiliza o chip STN1110. . . . . . . . . . . . . . . . . . . . . . . 135 Configuração da placa para programação. . . . . . . . . . . . . . . . . . . . . . . . . . 146 SmartFleet - Visão Geral da Arquitetura. . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Formato do parâmetro da operação de salvar dados dos sensores de um veículo. . . . . . 168 Formato do parâmetro da operação de listar dados dos sensores de um veículo. . . . . . . 169 Formato do retorno da operação de listar dados dos sensores de um veículo. . . . . . . . 1710 Diagrama de classes do SmartFleet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811 SmartFleet Mobile - Entidade a ser enviada para nuvem. . . . . . . . . . . . . . . . . . 1912 SmartFleet Mobile - Diagrama de Atividades . . . . . . . . . . . . . . . . . . . . . . . 2013 Hardwares utilizados para simulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2014 Cabo DB9/OBD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2115 Placa protótipo versão 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2216 Etapas do método de RAP proposto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2517 Placa original e binarizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2718 Templates utilizados no reconhecimento de caracteres. . . . . . . . . . . . . . . . . . . 2919 Imagens com os 4 tipos de placas (Normal, escura, sombreada e inclinada). . . . . . . . 2920 Tipos de erros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3021 Gráfico de tempo ⇥ resolução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3122 Comparação de background entre vaga vazia e vaga ocupada . . . . . . . . . . . . . . . 3423 Processo de detecção do estado da vaga. . . . . . . . . . . . . . . . . . . . . . . . . . . 3524 Local de testes da rede neural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3725 Formato de vagas utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3826 Primeira Arquitetura do Sistema de Estacionamento Inteligente . . . . . . . . . . . . . . 3927 Primeiro Modelo ER do Banco de Dados do Estacionamento Inteligente . . . . . . . . . 4028 Protótipo da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4129 Módulo Esp8266 e sensor HC-SR04 usados nos testes . . . . . . . . . . . . . . . . . . . 41

Lista de Tabelas1 Lista de comandos AT’s para definir protocolo. . . . . . . . . . . . . . . . . . . . . . . 122 Exemplo de comandos e respostas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Comparação entre ELM327 e STN1110. . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Comparação entre CC3200 e ESP32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Operações REST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Resultado dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Classificações corretas por resolução. . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Trabalhos Encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7

1 Introdução

O grupo de trabalho WP-03, nomeado de Sensoriamento, surgiu com a necessidade de desenvolver solu-ções de hardware e software embarcados para o Projeto Smart Metropolis. De acordo com o planejamentodo segundo ano do projeto as seguintes iniciativas serão de responsabilidade do WP-03:

1. Monitoramento de Frotas

2. Detecção de Placas

3. Estacionamento Inteligente

4. Poste Inteligente

Os primeiros três meses de execução foram concentrados no levantamento do estado da arte, soluçõescomerciais já existentes, identificação de software e hardwares adaptados aos problemas, levantamento derequisitos iniciais, projeto das arquiteturas (hardware e software) a serem implementadas e alguns testesiniciais. Em especial, a iniciativa do Poste Inteligente concentrou em testes de autonomia energético emcontinuidade ao ano anterior. Os resultados dos testes da iniciativa do Poste Inteligente encontra-se emdocumento anexado ao relatório.

2 Monitoramento de Frotas

2.1 Introdução

Um dos grandes desafios do setor produtivo e instituições públicas e privadas está relacionada com a ges-tão da sua frota veicular. Manutenção, padrão de utilização, consumo demasiado, identificação são algunsdesses desafios. Uma grande parte das operações para se manter o bom funcionamento de um automóvelsão realizadas por sistemas eletrônicos. Esses sistemas tais como injeção eletrônica de combustível e defreios antibloqueantes, são formados por um conjunto de sensores e atuadores. Esses sistemas tambémcontam com alguns mecanismos de diagnóstico de falhas que comprometem o funcionamento do veí-culo. Todas essas informações são passíveis de serem extraídas automaticamente pelo veículo a fim decriar um gerenciamento de frotas eficiente a partir de protocolos de comunicação padronizados para áreaveicular. A iniciativa de monitoramento de frotas descrita nesse projeto pretende criar um sistema capazde coletar e analisar, a partir de hardware próprio, todos os sensores disponibilizados pelos veículos afimde criar métricas de manutenção e utilização de veículos.

2.2 OBD

O termo OBD (do inglês On-Board Diagnosis) refere-se a um sistema de autodiagnóstico disponível namaioria dos veículos que circulam atualmente. A leitura de dados é realizada a partir de um dispositivo“plug and play” diretamente na ECU (Unidade de controle do motor, do inglês Engine Control Unit) doveículo. Através dessa porta é possível coletar uma série de dados, incluindo o status da luz da injeçãoeletrônica, códigos de diagnóstico de problemas (DTCs, do inglês Diagnostic Trouble Codes) além dedezenas de parâmetros em tempo real, como rotação do motor, velocidade, temperatura do líquido dearrefecimento, dentre outros.

8

O conjunto de informações disponíveis varia de acordo com a montadora. Na realidade, carros domesmo modelo, produzidos no mesmo dia, podem disponibilizar um conjunto diferente de informações,dependendo da ECU instalada.

O sistema OBD surgiu nos EUA com o intuito de diminuir a emissão de gases poluentes, mas atu-almente nos permite ter acesso a diversos dados de operação do veículo, como foi citado inicialmente.Nos EUA e Europa, o sistema é obrigatório como item de série desde 1996, no Brasil, o mesmo veioacontecer apenas em 2010.

A primeira geração do sistema de autodiagnóstico, chamada OBD-I foi desenvolvida pela CaliforniaAir Resources Board (CARB) e implementada em 1988. Porém, a partir da necessidade de expandir acapacidade do sistema, uma segunda geração foi publicada pela CARB em 1992, ficando conhecida porOBD-II.

O conector de interface OBD-II, conhecido por DLC (“Diagnostic Link Connector”) possui 16 pinose é utilizado em praticamente todos os veículos produzidos a partir de 1996. Geralmente é encontradoembaixo do lado esquerdo do painel do veículo, porém sua localização depende do modelo e ano docarro. A Figura 1 mostra as localizações mais comuns para o conector.

Figura 1: Localizações comuns do conector OBD-II no veículo.

2.2.1 Modos de operação

Quando trabalhamos com o sistema OBD temos disponíveis 10 modos de operação . Cada um é destinadoa uma finalidade específica e não obrigatoriamente os scanners disponíveis no mercado serão equipadoscom todos os modos. A explicação dos 10 modos será tratada de modo superficial (uma explanação bemdetalhada pode sem encontrada em [10]) , visto que no projeto visamos trabalhar, inicialmente, apenascom o modo 1.

Modo 1Este modo retorna os valores em tempo real de diversos parâmetros do carro (captados a partirde sensores) como rotação do motor, velocidade e temperatura do líquido de arrefecimento. Cadasensor é caracterizado por um número em hexadecimal chamado PID (Identidade do Parâmetro, doInglês “Parameter Identifier”, uma lista completa de comandos PID pode ser encontrada em [28]).Por exemplo, para fazer a leitura da velocidade RPM do motor, enviamos o comando “010C”onde “01” indica que estamos trabalhando no modo 1 e “0C” é o PID equivalente à velocidade emquestão.

9

Modo 2O modo 2 disponibiliza as informações de um sensor no momento em que ocorreu uma falha.Quando uma falha acontece, o computador do veículo tenta guardar o máximo de informaçãopossível, ou seja, a quantidade de informação a que teremos acesso depende do veículo e não doscanner.

Modo 3Este modo disponibiliza os DTCs armazenados. Esses códigos são padronizados para todos osveículos e são divididos em quatro categorias, de acordo com o setor onde ocorreu a falha (motore transmissão, corpo do veículo, chassi e rede de comunicação).

Modo 4O modo 4 é utilizado para limpar DTCs que estejam armazenado no computador do carro e apagara luz da injeção eletrônica.

Modo 5O modo 5 retorna os resultados do autodiagnóstico realizado na sonda lambda. Aplica-se princi-palmente a veículos movidos à gasolina.

Modo 6Este modo retorna os resultados do autodiagnóstico de sistemas que não estão sujeitos à monito-ramento constante (sensores de oxigênio e do ar-condicionado, por exemplo).

Modo 7O modo 7 é muito utilizado após um reparo para verificar se um código de erro reaparece semprecisar fazer um teste de longa duração. Os códigos utilizados são idênticos ao do modo 3.

Modo 8Este modo permite que o scanner também realize a escrita de instruções, além da leitura de dados.Este modo é muito utilizado por mecânicos para encontrar mais precisamente o local de uma falha.

Modo 9O modo 9 retorna algumas informações acerca do veículo, como o número de identificação doveículo (VPN, do inglês vehicle identification number).

Modo 10Por último, o modo 10, também conhecido como Modo A retorna códigos de erro que, diferente-mente do modo 3, não podem ser apagados.

2.2.2 Protocolos

A interface OBD-II permite diferentes protocolos, no entanto, em geral, cada veículo implementa apenasum deles. Dessa forma, o protocolo mais utilizado é o CAN (Controller Area Network), que foi criadopela Bosh em 1980. O principal objetivo de sua criação foi permitir a comunicação entre diferentesECUs (Engine Control Unit) [16]. No entanto, além dele, também são muito utilizados os protocolos:SAE J1850 PWM, SAE J1850 VPW, ISO 9141-2 e ISO 14230 KWP2000.

10

2.2.3 APIs e bibliotecas

Existem várias APIs já desenvolvidas para auxiliar a conexão entre o OBD e o software desenvolvido(Todas utilizando o padrão de adaptadores ELM327 OBD-II).

PythonA biblioteca python-OBD1 está disponível sob a licença GNU GPL v22 e pode ser instalada atra-vés do pip (“Python Package Index”) pelo comando pip install obd.

JavaExiste a obd-java-api [24], que está disponível sob a licença Apache-2.03.

C++ Foi desenvolvido pela Freematics [13] o ArduinoOBD4, uma biblioteca otimizada para Arduino,sob a licença BSD5.

C# A Microsoft, através do Project Detroit, desenvolveu o OBD-II Manager6, que está disponívelsob a licença Microsoft Public License (MS-PL)7.

PHPFoi criada uma classe para auto-diagnóstico veicular, denominada OBD8, sob a licença MIT9.

RubyExiste uma Gem chamada OBD10 (sem licença disponível), que pode ser instalada através docomando gem install obd.

2.3 Hardwares de Comunicação

2.3.1 Placas de escaneamento: ELM327 e STN1110

O ELM327 é um microcontrolador desenvolvido para traduzir os protocolos OBDII realizando a leiturados dados provenientes do veículo. Originalmente o ELM327 é implementado no PIC18F2480, . Elerealiza a comunicação com todos os protocolos necessários e identifica automaticamente o protocolo decomunicação que o veículo utiliza, fazendo a comunicação com o veículo através de um conector OBDII.

Na Figura 3 é possível analisar a pinagem do conector OBDII além de ser possível verificar quaispinos são referentes para cada tipo de protocolo de comunicação suportada .Para se comunicar como EML327, atraves de um computador ou outro microcontrolador, é utilizado a comunicação serial, enela escrever diretamente no ELM327 através de comandos AT. É necessário digitar o comando “AT+”seguido do parâmetro desejado, como exemplo “AT+SP0”, com esse comando o usuário está definindoque o protocolo utilizado será reconhecido automaticamente pelo OBDII.

A comunicação se inicia mandando o comando ATZ, que representa significa o reset total, após este,o ATSP0, que define que o protocolo será reconhecido automaticamente, porém se não quiser que seja

1https://github.com/brendan-w/python-OBD2https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html3https://www.apache.org/licenses/LICENSE-2.0.html4https://github.com/stanleyhuangyc/ArduinoOBD5https://opensource.org/licenses/BSD-2-Clause6https://obd.codeplex.com/7https://opensource.org/licenses/MS-PL8https://github.com/mdlayher/obd9https://opensource.org/licenses/MIT

10https://github.com/jeffpeterson/obd

11

Figura 2: Conector OBD II

PIN Description PIN Description1 Vendor option 9 Vendor option2 J1850 BUS+ 10 J1850 BUS3 Vendor option 11 Vendor option4 Chassis ground 12 Vendor option5 Signal ground 13 Vendor option6 CAN (J-2234) high 14 CAN (J-2234) low7 ISO 9141-2 K-line 15 ISO 9141-2 low8 Vendor option 16 Battery power

Figura 3: Pinagem do conector OBD II. [7]

automático, pode selecionar dentre os comandos listados na Tabela 1. Para requisitar a leitura de umparâmetro do carro basta digitar o código PID correspondente, alguns exemplos de códigos PID’s podemser vistos na Tabela 2.

12

Protocolo Descrição

0 Automatic1 SAE J1850 PWM (41.6 kbaud)2 SAE J1850 VPM (10.4 kbaud)3 ISO 9141-2 (5 baud init)4 ISO 14230-4 KWP (5 baud init)5 ISO 14230-4 KWP (fast init)6 ISO 15765-4 CAN (11 bit ID, 500 kbaud)7 ISO 15765-4 CAN (29 bit ID, 500 kbaud)8 ISO 15765-4 CAN (11 bit ID, 250 kbaud)9 ISO 15765-4 CAN (29 bit ID, 250 kbaud)A SAE J1939 CAN (29 bit ID, 250* kbaud)B User1 CAN (11* bit ID, 125* kbaud)C User2 CAN (11* bit ID, 50 kbaud)

Tabela 1: Lista de comandos AT’s para definir protocolo.

Comando Resposta Detalhes

01 04 41 04 00 Carga do motor01 05 41 05 00 Temperatura do líquido de arrefecimento01 0B 41 0B 00 Pressão no coletor de admissão01 0C 41 0C 00 Rotação atual do motor01 0D 41 0D 00 Velocidade instantânea do veículo01 11 41 11 32 Posição da válvula borboleta - TPS

Tabela 2: Exemplo de comandos e respostas.

Após solicitar a temperatura de arrefecimento (oC) através do comando 01 05, um exemplo de res-posta é 41 05 7B, que significa:

41 40 (Resposta) + 1 (módulo 1);

05 PID 05, isto é, a temperatura do motor em graus Celsius;

7B 0x7B = 123 assim, o resultado retornado, de acordo com a lista de comandos, é o valor_retornado� 40,substituindo: 123 � 40 = 83oC.

Após solicitar a rotação instantânea do motor através do comando 01 0C, um exemplo de resposta é41 0C 1A F8, que significa:

41 40 (Resposta) + 1 (módulo 1);

0C PID 0C, Rotações do motor em RPM;

1A F8 0x1AF8 = 6904 assim, o resultado retornado, de acordo com a lista de comandos, é ovalor_retornado / 4, substituindo: 6904 / 4 = 1726RPM.

13

O chip STN1110 é um interpretador OBD para UART totalmente compatível com o conjunto decomandos ELM327 mencionados acima. Baseado em um núcleo de processador de 16 bits, o STN1110oferece mais recursos e melhor desempenho do que qualquer outro IC compatível com ELM327, comopor exemplo preço, tamanho, estabilidade, desempenho e recurso. Algumas comparações podem servisualizadas na tabela a seguir:

Características ELM327 v1.4 STN1110

Arquitetura 8 bits 16 bitsVelocidade de processamento 4 MIPS 40 MIPSFLASH (ROM) 32 kb 128 kbRAM 1.5 kb 8 kbBaudrate UART suportados 9600bps a 500kbps 38bps a 10MbpsFirmware atualizável Não Sim

Tabela 3: Comparação entre ELM327 e STN1110.

A princípio, na fases de testes, iremos utilizar a placa STN1110 da sparkfun, que se baseia no chipSTN1110 e necessita de poucos componentes externos para funcionar, com isto, vai ser mais escalávelpara montar os protótipos futuros.

Figura 4: Placa da Sparkfun que utiliza o chip STN1110.

2.3.2 CC3200 vs ESP32

A CC3200 é um microcontrolador (MCU) com WI-FI integrado desenvolvida para ser utilizada em pro-jetos de Internet das coisas. Graças a seu processador de alta performance (ARM Cortex-M4), projetistasconseguem desenvolver todo um projeto utilizando apenas um circuito integrado (IC).

Para programar a MCU primeiramente devemos conectar um jumper entre os pinos SOP 2 e TCK,como mostra a Figura 5. Em seguida, conectamos a placa de desenvolvimento a um computador pormeio de um cabo micro USB. Com o driver devidamente instalado basta abrir o Energia, plataforma dedesenvolvimento utilizada para programar a CC3200, e carregar um código.

14

Figura 5: Configuração da placa para programação.

Programar a CC3200 é muito simples, utilizamos a linguagem C e as bibliotecas já definidas no Ener-gia são muito semelhantes à da conhecida placa Arduíno. Com o decorrer do projeto, surgiu a possibili-dade de passarmos a utilizar a ESP32, cuja principal vantagem é o Bluetooth já integrado ao microcon-trolador. Outro ganho notável foi o tamanho bastante reduzido da placa em relação a CC3200.

A programação da ESP continuou no mesmo nível de dificuldade, visto que passamos a utilizar a IDEdo próprio Arduíno, sendo necessário apenas a instalação de um CORE para que possamos adicionar aESP ao gerenciador de placas.

Características CC3200 ESP32

Flash (ROM) 32 kb 448 kbRAM 256k 520kUART 2 3SPI 1 4I2C 1 2GPIO 27 28Wi-Fi Sim SimBluetooth Não Sim

Tabela 4: Comparação entre CC3200 e ESP32.

2.4 Arquitetura Geral da Proposta

A leitura dos dados dos sensores veiculares é feita por intermédio de um hardware que utiliza a tec-nologia OBD para se conectar ao veículo. Um aplicativo mobile se conecta via Bluetooth ao hardwareOBD, obtém os dados dos sensores e os envia através de uma conexão GPRS ou Wifi para o SmartFleetLightweight que, por sua vez, possui a responsabilidade de armazenar e servir os dados para as aplicaçõesde análise. Esse modelo pode ser melhor compreendido através da Figura 6.

15

Figura 6: SmartFleet - Visão Geral da Arquitetura.

2.4.1 SmartFleet

O SmartFleet é a aplicação responsável por armazenar os dados dos sensores dos carros enviado pelosdispositivos móveis. Também tem a responsabilidade de rodar algoritmos de análise sobre os dados dossensores, a fim de gerar informações úteis à tomada de decisão, seja pelo dono do veículo ou de interessesocial (por exemplo, o nível de poluição do veículo). Os algoritmos não fazem parte dessa entrega e serãodesenvolvidos a partir do próximo ciclo.

O SmartFleet conta com uma API (Application Programming Interface) REST para inserir e buscardados. A Tabela Tabela 5 descreve os métodos de inserir e buscar dados.

Operação URL Parâmetro(s)

1 http://[IP]:[PORTA]/salvar dadosVeiculoJSON2 http://[IP]:[PORTA]/listar busca

Tabela 5: Operações REST.

Para a operação 1 é esperado como parâmetro um JSON no formato mostrado na Figura 7. Esse JSONcontém o identificador do veículo, sua localização, o tempo de coleta dos dados e os dados dos sensoresdo carro. Essa operação retorna se os dados foram salvos ou não com sucesso no SmartFleet.

16

1 {

2 "latitude": 44.0,

3 "longitude": 55.0,

4 "altitude": 21.0,

5 "vehicleid": "veiculo1",

6 "timestamp": 1493060441516,

7 "dadosMap": {

8 "sensor-a": "9",

9 "sensor-b": "10.8"

10 }

11 }

Figura 7: Formato do parâmetro da operação de salvar dados dos sensores de um veículo.

Para a operação 2 é esperado como o parâmetro um JSON no formato na Figura 8. Que contém aspropriedades veiculoid, dataInicio e dataFim.

1 {

2 "veiculoid": "veiculo1",

3 "dataInicio": 1493053953090,

4 "dataFim": 1493058753090

5 }

Figura 8: Formato do parâmetro da operação de listar dados dos sensores de um veículo.

É esperado como retorno da operação 2 uma lista de dados no formato JSON para o veículo e períodoinformado como mostrado na Figura 8.

17

1 [

2 {

3 "latitude": 44.0,

4 "longitude": 55.0,

5 "altitude": 21.0,

6 "vehicleid": "veiculo1",

7 "timestamp": 1493059450328,

8 "dadosMap": {

9 "sensor-b": "10.7",

10 "sensor-a": "9"

11 }

12 },

13 {

14 "latitude": 44.0,

15 "longitude": 45.0,

16 "altitude": 21.0,

17 "vehicleid": "veiculo1",

18 "timestamp": 1493059459531,

19 "dadosMap": {

20 "sensor-a": "9.1",

21 "sensor-b": "10.8"

22 }

23 }

24 ]

Figura 9: Formato do retorno da operação de listar dados dos sensores de um veículo.

Na Figura 10 é mostrado o diagrama de classes da aplicação. Que é divido nos pacotes a seguir.

• model: contém as classes de domínio da aplicação.

• dao: contém as classes de acesso ao banco de dados.

• service: responsável por realizar as operações de salvar e listar dados dos sensores.

• controller: responsável por disponibilizar as funções da API Rest.

• validator: realizar a validação dos dados enviados pelo usuário, verificando se não existe nenhumainconsistência. Como por exemplo na operação de salvar não informar o veiculoid.

• config: contém as classes responsáveis por carregar as configurações da aplicação.

• main: contém as classes que inicialização a aplicação.

18

Figura 10: Diagrama de classes do SmartFleet.

2.4.2 SmartFleet Mobile

O SmartFleet Mobile é um aplicativo para dispositivos móveis (sendo desenvolvido inicialmente paraAndroid [15]) com o intuito de obter os dados do hardware de coleta de dados veiculares (Subsubse-ção 2.4.3) e enviar para a versão na nuvem do SmartFleet (Subsubseção 2.4.1), o qual se encarregarádo armazenamento e processamento os dados, conforme explicitado na arquitetura da solução (Subse-ção 2.4).

Para que os dados sejam enviados para a nuvem, é necessário que o dispositivo esteja conectado àinternet, no entanto, essa condição nem sempre pode ser atendida, portanto, para que dados não sejamperdidos, o aplicativo conta com um Banco de Dados local (SQLite [5]) que armazena os dados coleta-dos do veículo até que haja uma conexão estável com a internet, permitindo assim que os dados sejamenviados.

Dessa forma, a aplicação pode ser dividida em 3 módulos. O primeiro, é responsável por se conectarao Hardware no veículo via Bluetooth, e realizar a coleta dos dados veiculares. O segundo, realiza oarmazenamento local dos dados coletados para evitar a perda de dados quando não houver uma cone-

19

xão estável. E, por fim, o módulo de sincronização de dados com a nuvem, enviando assim o que estáarmazenado no banco local para a versão online da aplicação e os deletando (para que não haja umaredundância desnecessária de dados, haja vista que não haverá processamento de dados no dispositivo,conforme especificado na Subseção 2.4).

Visando evitar retrabalho, foi realizada uma pesquisa por projetos semelhantes já desenvolvidos (ou emdesenvolvimento) antes de ser dado início o desenvolvimento. Por conseguinte, foi encontrado o projetochamado android-obd-reader [23], criado pelo mesmo desenvolvedor da obd-java-api [24] e distribuídode forma Open Source sob a licença Apache-2.0. Após uma análise das funcionalidades oferecidas, foidefinido que esse projeto seria utilizado como base para o desenvolvimento, pois já contava com módulosde conexão e leitura dos dados oriundos do adaptador OBD instalado no veículo, e com o de envio paraum servidor na nuvem.

No entanto, após uma profunda análise no código e em sua arquitetura, foi verificado que, por setratar de um projeto descontinuado por seu autor e que, consequentemente, não recebia atualizaçõessignificativas há um considerável período, além de ter sido desenvolvido para a API 21 do Android [15],ao passo em que no momento em que esse artigo é escrito, a versão atual é a 25. Além da utilização dedependências já descontinuadas, tornando assim inviável a refatoração e atualização do projeto. À vistadisso, foi decidido que para que houvesse uma garantia de qualidade e escalabilidade, a aplicação nãodeveria se basear nesse projeto descontinuado.

Figura 11: SmartFleet Mobile - Entidade a ser enviada para nuvem.

Para realizar a requisição dos dados oriundos do adaptador OBD, faz-se a utilização de um Service,para que haja a comunicação recorrente via Bluetooth entre o dispositivo e o hardware. Feito isso, osdados da leitura são armazenados no formato Map<String, String>, possuindo como chave umaString correspondente ao código do sensor, e como valor, a string de resposta com o valor correspondenteao sensor. Por ser utilizado um banco de dados relacional (SQLite [5]) para o armazenamento local dosdados, é feita uma serialização do dicionário, convertendo assim para uma String contendo um JSON(JavaScript Object Notation).

Para que haja a identificação do veículo em que foram realizadas as leituras, também é salvo na en-tidade um identificador VIN (Vehicle Identification Number), que é um código único de 17 caracteresutilizado pela indústria automotiva para identificar o motor de cada veículo [7], dado esse obtido atravésdo hardware coletor de dados. São salvos ainda os dados de latitude e longitude oriundos do GPS do dis-positivo, e um timestamp com o momento em que a leitura foi realizada. A classe de entidade utilizadapara armazenar os dados da leitura pode ser visualizada na Figura 11.

20

Figura 12: SmartFleet Mobile - Diagrama de Atividades

Destarte, o fluxo de atividades do aplicativo pode ser melhor compreendido através de seu diagramade atividades (Figura 12). Com os atores principais do sistema sendo representados em raias. Por se tratarde uma coleta recorrente de dados, o diagrama retrata as atividades realizadas pelo Service.

(a) Freematics OBD-II Emula-tor MK2.

(b) OBDLink R�LX.

Figura 13: Hardwares utilizados para simulação.

Porquanto os dados a serem lidos pela aplicação são gerados exclusivamente por veículos, seria deve-ras complicado e arriscado a realização de experimentos em tempo de desenvolvimento, por esta razãoestá sendo utilizado o OBD-II Emulator MK2 (Figura 13a) juntamente com o seu Software GUI, ambosdesenvolvidos pela Freematics [13] e o OBDLink R�LX11 desenvolvido pela OBDLink R� (Figura 13b).Além dessas duas soluções, está sendo utilizado em ambiente UNIX o OBDSim12, desenvolvido pelaicculus.org.

11http://www.obdlink.com/lxbt/12https://icculus.org/obdgpslogger/obdsim.html

21

2.4.3 Hardware de captura de dados

Após o estudo de todas as possíveis arquiteturas que poderíamos utilizar, foi escolhido o chip STN1110como interpretador OBD. Os motivos foram relacionados ao desempenho, capacidade de processamentoe comunicação. Foi observando também questões relacionadas com a factibilidade de conexão com oESP32. A partir dessa decisão, foi projetado a primeira placa do coletor OBD baseado no chip STN1110.A princípio, um dos principais requisitos almejados era o tamanho reduzido, tendo em vista que o mó-dulo será conectado diretamente a porta OBD do veiculo. O projeto da placa resultou em um tamanhode 57x66mm. Porém, para não prejudicar esteticamente o interior do veículo caso o local do conectorOBD seja muito exposto, ou se desejar colocar o hardware de captura de dados em outro local, temos aalternativa de conectar entre o conector OBD e o hardware, um cabo DB9-OBD(Figura 14). Para tanto,foi também adicionado no protótipo um conector DB9.

Figura 14: Cabo DB9/OBD.

A placa possui alguns espaços livres que foram projetados justamente para serem adicionados algunsoutros módulos futuramente, por exemplo um acelerômetro ou outros sensores. Assim, o protótipo poderásofrer algumas alterações devido a arquitetura final estabelecida. Em termos de alimentação de energia,deverá ser adicionado reguladores de tensão além do já existente nesta versão (o veículo através do OBDfornece 12v) para deixar todos os componentes trabalhando no nível de tensão adequados STN1110 (5v)e ESP32 (3.3v). Em relação a exportação dos dados obtidos (STN1110 e GPS), todos serão analisadose processados pelo ESP32 e em seguida exportados ou por GSM/GPRS presente do Módulos SIM808ou via Wi-Fi e Bluetooth presentes no ESP32. Em todos os casos, todos os dados serão armazenadoslocalmente em um módulo SD disponibilizado no coletor OBD.

2.5 Próximos Passos

Dado a avaliação de viabilidades da solução e os resultados obtidos nesse ciclo de pesquisa/desenvolvi-mento. Pretende-se para o próximo ciclo de desenvolvimento/pesquisa os seguintes passos:

1. Após a definição de utilização da placa STN1110 e do ESP32, iremos executar todos os testespossíveis para determinar se esta junção vai atender todos os requisitos necessários presentes nesteprojeto.

22

Figura 15: Placa protótipo versão 1.

2. Pretendemos acrescentar os módulos GPS/GPRS e SD para obter informações como posição erota, além de uma possibilidade a mais de envio dos dados (em acréscimo a Wi-fi e ao Bluetooth).

3. Finalização e consolidação da estrutura de captura de dados dos carros via OBD.

4. Pretende-se testar a integração desta proposta utilizando o módulo de IoT do Fiware, fazendo usode uma instância do Fiware disponibilizada pelo WP-Infraestrutura.

5. Desenvolvimento de algoritmos para extrair informações dos dados coletados. Já está em anda-mento, por exemplo, a especificação e desenvolvimento do algoritmo de inferência da liberação doteor de CO2 por um veículo.

6. Será feita uma pesquisa para determinar as informações que se deve extrair dos dados e que sejade interesse da instituição proprietária do veículo.

3 Detecção de placas

3.1 Introdução

A extração automática do conteúdo das placas de automóveis a partir de imagens viabiliza uma vastaquantidade de aplicações. Para agentes de segurança dos centros urbanos, por exemplo, permite iden-tificar veículos roubados ou irregulares, monitorar vias para multar precisamente motoristas infratorese controlar o acesso a estacionamentos [8]. Pelo interesse mercadológico e pelos desafios tecnológicosenvolvidos, executar essa tarefa com acurácia e precisão é um problema muito abordado na área de VisãoComputacional.

Os métodos para solucionar esse problema, geralmente referenciados como de Reconhecimento Au-tomático de Placas (RAP) ou, em Inglês, Automatic License Plate Recognition (ALPR), consistem em,dada uma imagem, executar três etapas: localização da placa na cena, segmentação dos caracteres e reco-nhecimento óptico dos caracteres segmentados. Com frequência, esse fluxo necessita incorporar proces-samentos intermediários, com vistas a eliminar ruídos derivados das condições da captura ou do própriométodo.

Na literatura, são comuns os artigos que tratam apenas de um dos três estágios isoladamente [12].Como a tarefa de reconhecimento depende do bom funcionamento conjunto dessas etapas, métodoscompletos são de comparação mais útil para o que este projeto se propõe. Um exemplo deles é o de [9],o qual apresenta um sistema embarcado em um hardware com processador Texas InstrumentsTM C64que produz o resultado esperado com elevada acurácia e em cerca de 55ms. Este, porém, demanda um

23

tráfego de veículos em uma mesma direção e uma calibração das cenas, pois se baseia em previsões dasposições dos carros para reduzir o espaço de busca.

Em outro trabalho, [29] apresenta um sistema composto de unidades de hardware instaladas em locaisfixos, além de unidades de firmware e de software, que alcançou uma taxa de acerto de 95.6%, levandopouco mais de 1s para o processamento em um computador com processador Pentium 500MHz. Valesalientar, contudo, que esses resultados foram obtidos apenas em ambiente nas condições controladaspelos autores.

[19], por sua vez, desenvolveram um método para sistemas comerciais adaptados para placas bra-sileiras, nos quais os usuários podem informar as placas passíveis de reconhecimento. Eles utilizaramtécnicas de processamento de imagens, como Transformada de Hough e thresholding, além de redesneurais para o reconhecimento de caracteres, obtendo uma taxa de 94% de acerto. As imagens de teste,entretanto, apresentavam inclinação insignificante e sem problemas de sombras ou luminosidade.

[18], em sua pesquisa, aplicaram técnicas de detecção de bordas e alternância entre cores para extrairas placas, um algoritmo de thresholding baseado em lógica Fuzzy para segmentar os caracteres e duasredes neurais Multilayer Perceptron (MLP) para o reconhecimento. Conseguiram 85% de acerto semcondições de ambiente fixadas, em tempo não especificado pelos autores.

Em produção recente, [11] obteve 92.55% de acerto na detecção de placas e 88.40% na detecção dedígitos, com tempo médio de 0.5s, utilizando classificadores em cascata para a localização da placa; al-goritmos de limiarização, projeção, detecção de contornos e morfologia matemática para a segmentação;e um critério sobre transição de pixels para o reconhecimento.

O objetivo deste trabalho é produzir um sistema de RAP para uso hardwares diversos, desde compu-tadores pessoais, até dispositivos móveis e como sistema embarcado. Para tanto, buscou-se, em primeiromomento, um método já implementado, para ser otimizado. Tendo em vista o insucesso dessa tentativa,iniciou-se um estudo do estado da arte para se conceber um método próprio, completo e robusto, apli-cando técnicas de processamento de imagens e reconhecimento de padrões, destinado à aplicação emimagens estáticas. Após estudos de diversas técnicas, o estado atual do método é uma composição declassificadores em cascata baseados em Haar-like features, que detectam uma ou mais placas na cena;em seguida, a combinação de diversos filtros, morfologia matemática e thresholding para a segmentação;e, por fim, do uso da técnica de template matching para o reconhecimento.

O método foi testado em um computador pessoal e em um Raspberry Pi 2 modelo B, com imagens deum ambiente não controlado, apresentando placas em condições limitadas de iluminação e alinhamento.As contribuições efetivas do estado atual do método podem ser assim resumidas:

1. Resultados comparáveis aos da literatura [11, 18] utilizando uma combinação de técnicas de baixocusto computacional (classificadores em cascata, morfologia matemática e template matching);

2. Robustez a ambientes não controlados, em diferentes horários do dia, considerando placas escuras,cortadas por sombras ou inclinadas, diferentemente do que se observa em trabalhos como os de[19], [29] e [9];

3. Viabilidade de execução em Raspberry Pi 2 modelo B, qualidade ainda não observada no estadoda arte e importante dada a adesão e aplicabilidade dessa plataforma.

O restante do relatório está organizado da seguinte forma: a Seção 3.2 abarca a tentativa de uso dosistema pronto OpenALPR no contexto brasileiro, explicando os testes realizados e os problemas encon-trados; a Seção 3.3 abarca o método proposto, explicando aspectos teóricos e práticos de cada técnica

24

aplicada, bem como os experimentos e resultados obtidos até o estado atual da pesquisa; finalmente, aSeção 3.4 traz as considerações finais sobre o andamento do trabalho e expõe os próximos passos.

3.2 OpenALPR

3.2.1 Metodologia

Visando evitar retrabalho e agilizar a concepção do sistema, decidiu-se por buscar ferramentas RAP jáimplementadas. A única encontrada para uso aberto, ainda que sob licença AGPL, foi o OpenALPR [20],projeto open-source destinado ao RAP que se utiliza das bibliotecas OpenCV [22] e Tesseract[25] para astarefas de processamento de imagens e reconhecimento ótico de caracteres, respectivamente. O sucessoem placas europeias e norte-americanas inspirou otimismo quanto à aplicação no contexto brasileiro.

Os esforços se concentraram, a partir daí, em compilar o OpenALPR para ser utilizado no RaspberryPi Zero e no sistema Android, e, a partir de análises sobre o funcionamento nesses dispositivos, decidirpor continuar com essa biblioteca ou rumar para uma implementação própria.

Para utilizar o OpenALPR no Raspberry Pi Zero, realizou-se todo o processo de compilação e, emseguida, estudou-se como relacionar a câmera com essa biblioteca. Pela facilidade em se trabalhar comPython nesse minicomputador, optou-se por fazer a programação da aplicação almejada nessa linguagem.

Quanto à programação para Android, a biblioteca OpenALPR possui uma implementação de um bin-ding para a linguagem Java que se utiliza da Java Native Interface (JNI) para adaptar código nativo emC++ para Java. Ela foi, então, aproveitada nas tentativas de incorporação da biblioteca ao ambiente dedesenvolvimento Android Studio.

3.2.2 Experimentos e resultados

A compilação para o Raspberry Pi Zero foi bem sucedida, sendo possível executar uma pequena aplica-ção em Python para checar a acurácia dos resultados, que recebe uma imagem e responde com a possívelplaca, além de mostrar a confiança do resultado obtido. Porém, como o treinamento do classificadorTesseract não foi dirigido às placas brasileiras, os resultados foram pouco satisfatórios, como mostra aTabela 6.

# Valor absoluto Percentagem

Acertos 13 12,75%Erros 89 87,25%Total 102 100%

Tabela 6: Resultado dos testes

Já com o sistema Android, não se conseguiu passar da fase de compilação do OpenALPR, devido aproblemas com a JNI. Na Internet, havia versões precompiladas da biblioteca, porém eram limitadasapenas ao uso em imagens estáticas, inviabilizando os streams de vídeo. Ademais, os tutoriais e ma-nuais disponíveis continham trechos desatualizados, aumentando a propensão aos erros no processo decompilação.

Com isso, percebeu-se que a biblioteca OpenALPR não apresentou a aplicabilidade e o desempenhoesperados, principalmente por problemas relacionados à compilação para a plataforma Android e à ele-vada imprecisão para placas brasileiras. Há, de fato, maneiras de se treinar o classificador para melhorareste último aspecto, porém as demais dificuldades desencorajam o uso da biblioteca. Como ela era a única

25

Figura 16: Etapas do método de RAP proposto.

disponível, decidiu-se, para as etapas seguintes da pesquisa, investir tempo e esforços na implementaçãoprópria de um método para RAP.

3.3 Método próprio

A Figura 16 apresenta o fluxo de execução do método proposto. A maioria das implementações dosalgoritmos de Visão Computacional foram baseadas na biblioteca [21], em sua versão 3.2 na linguagemC++.

A partir desse ponto, considera-se uma imagem como uma função com domínio em {1, . . . ,m} ⇥{1, . . . , n} ✓ N ⇥ N, onde m e n são, respectivamente, a largura e a altura, e contradomínio em R, nocaso de imagens em escala de cinza, ou R3, para imagens no espaço RGB. Adicionalmente, dada umaimagem f , o seu domínio é denotado por D(f), sua largura por w(f) e sua altura por h(f).

3.3.1 Detecção da placa

O primeiro passo após a captura de uma cena, assumindo-se que ela se encontra na resolução desejada, éa detecção e o recorte de uma ou mais regiões identificadas como placas. O conjunto de técnicas aplicadasneste trabalho para essa tarefa combina features simples em uma cascata de classificadores otimizada,como descrito a seguir.

Dada uma imagem f , pode-se determinar um retângulo, rf

, de canto superior esquerdo ha, bi 2 D(f),largura m0 e altura n0, tal que a + m0 w(f) e b + n0 h(f), como sendo uma restrição de f deassinatura r

f

: {a, . . . , a+m0}⇥ {b, . . . , b+ n0} ! R, tal que

rf

(x, y) = f(x, y). (1)

Define-se também sobre f uma janela (ou kernel) formada por retângulos adjacentes, rotulados comobrancos ou pretos. Uma divisão desse tipo é base para as conhecidas Haar-like features. Representandouma feature dessa como H = hP ,Bi, onde a primeira componente é o conjunto de retângulos pretos ea segunda, o de brancos, determina-se o valor dela pela fórmula [11]:

V (H) =X

b2B

X

x2D(b)

b(x)�X

p2P

X

x2D(p)

p(x). (2)

26

Uma imagem, mesmo pequena, pode conter milhares de Haar-like features, o que significa muitoesforço computacional para todas as operações de soma de pixels envolvidas. A fim de mitigar esseproblema, [26] introduziram o conceito de imagem integral. Para f , a imagem integral, ii

f

, é tal que

iif

(x, y) =X

x

0x,y

0y

f(x0, y0). (3)

Essa imagem pode ser calculada em apenas um percorrimento, usando as recorrências

s(x, y) = s(x, y � 1) + f(x, y), e (4)

iif

(x, y) = iif

(x� 1, y) + s(x, y). (5)

Dispondo de iif

, qualquer soma retangular pode ser computada com apenas quatro referências a umamatriz, representando um ganho muito elevado em eficiência em comparação às somas pixel a pixel.

Ocorre que, mesmo se calculando rapidamente as features, elas ainda são numerosas e muitas sãoirrelevantes para a classificação. Objetivando encontrar um classificador de alto desempenho baseadoapenas em features relevantes, [14] desenvolveram um método de boosting chamado AdaBoost, o qualcombina classificadores fracos para encontrar as features mais úteis e produzir resultados de elevadaacurácia.

Para tanto, o algoritmo inicia com um conjunto de n exemplos classificados, hhx1, y1i, . . . , hxn, ynii,sendo, para 1 i n, x

i

a instância e yi

a classe; uma distribuição D; um número máximo de iteraçõesT ; e um vetor de pesos w tal que, na primeira iteração, w

i

= D(i), 1 i n.Nas próximas repetições, o algoritmo treina um classificador fraco para cada feature, selecionando

aquele que produz menor erro. Ao final, apresenta uma função de predição considerando os classifi-cadores selecionados em todas as iterações. Com esse processo, apenas as features mais importantescontribuem para a decisão.

Mesmo que o conjunto de features, após o AdaBoost, seja muito reduzido, a classificação pode serainda ineficiente. Para resolver essa questão, [26] apresentaram uma cascata de classificadores capaz depoupar a análise de regiões que certamente não são parte do objeto de interesse. Para isso, inicia comclassificadores menores e, portanto, mais rápidos, configurados para minimizar a quantidade de falsospositivos. Para cada janela na imagem, quando um resultado positivo é obtido, um segundo classificadoré ativado, e assim por diante. Um resultado negativo, porém, causa a imediata rejeição da janela. Essacascata de classificadores reduz substancialmente o esforço computacional exigido.

Neste trabalho, uma cascata de classificadores, baseados em Haar-like features e construídos com oAdaBoost, foi utilizada para a tarefa de detecção de uma ou mais placas em uma cena f

s

. Utilizou-se umtreinamento disponível na Internet [17] para placas brasileiras e a função do OpenCV que implementaa técnica. Os parâmetros aplicados foram: scaleFactor = 1.1, minNeighbors = 4, flags = 0, minSize =(w(f

s

) · 0.045, w(fs)·0.0454 ).

Após essa etapa, cada uma das supostas placas detectadas, representada por um recorte retangular dacena, é submetida ao processamento descrito a seguir.

3.3.2 Processamento pré-segmentação

Esta etapa toma a imagem da suposta placa detectada e executa dois tratamentos sobre ela: transformaçãopara escala de cinza e limiarização. O objetivo é remover ruídos e efeitos indesejados das condições deiluminação, preparando a imagem para a fase de segmentação.

27

Figura 17: Placa original e binarizada

Considere fc

uma possível placa detectada na etapa anterior. Como a cena está no espaço RGB, fc

pode ser denotada porfc

(p) = hf r

c

(p), fg

c

(p), f b

c

(p)i, (6)

com p = (x, y) 2 D(fc

). Assim, a conversão para escala de cinza [21] é realizada de forma a gerar umaimagem f

g

: D(fc

) ! R, na qual, para todo p 2 D(fc

),

fg

(p) = f r

c

(p) · 0.299 + fg

c

(p) · 0.587 + f b

c

(p) · 0.114 (7)

O segundo tratamento, por sua vez, é baseado no trabalho de [27] e aplica morfologia matemáticae uma sequência de filtros para limiarizar f

g

. Nesse sentido, define-se um elemento estruturante h, oqual, neste trabalho, possui forma de cruz e representação em matriz de ordem três. Depois, calcula-se aabertura e o fechamento de f

g

por h, definidos em [27], respectivamente, como:

fg

� h = (fg

� h)� h (8)

fg

• h = (fg

� h)� h (9)

onde � e � são, na ordem, as operações de dilatação e erosão, aplicadas no operando à esquerda utili-zando o operando à direita como elemento estruturante.

A seguir, determinam-se as transformações top-hat, THT , e bottom-hat, BHT , segundo as equações:

THT (fg

) = fg

� fg

� h (10)

BHT (fg

) = fg

• h� fg

(11)

Aplica-se, então, o filtro de nome MMLPF [27] de acordo com a fórmula:

MMLPF (fg

) = fg

� THT (fg

)�BHT (fg

) (12)

Em sequência, aplicam-se outros três filtros conhecidos: de média, gaussiano e de mediana, todos comum mesmo kernel de tamanho K⇥K, onde K 2 R é sensível à resolução da cena e foi determinado em-piricamente (vide Seção ??). O resultado disso, denotado aqui por f⇤

g

, é, finalmente, binarizado, gerandoa imagem f

b

, pela regrafb

(p) = f⇤g

(p)� fg

(p)� c > 0 ? 255 : 0, (13)

em que c é uma constante relacionada à luminosidade da cena, sendo determinada, como proposta destetrabalho, pela fórmula

c =1

↵n

X

p2D(fb)

fb

(p) (14)

onde ↵ é definida empiricamente, variando com a resolução da cena.

28

3.3.3 Segmentação dos caracteres

Para segmentar os caracteres da suposta placa fb

extraída, rotulam-se os componentes conectados con-siderando adjacência-8. Obtêm-se, com isso, um conjunto de pixels de background, o qual é ignorado, euma família de n componentes C = {c

i

}, 1 i n, cada um podendo ser visto como um retângulo defb

e, portanto, também uma imagem.Se f

b

é, de fato, uma placa e se a segmentação da etapa anterior foi bem sucedida, sete dos componen-tes em C representam os caracteres desejados. Deve-se, portanto, propor uma estratégia para selecioná-los entre os demais componentes e, mais ainda, como os caracteres em uma placa aparecem em umaordem específica, retorná-los como uma tupla T = hc1, . . . , c7i, onde c

i

, 1 i < 7, aparece, na placa, àesquerda de c

j

, para todo i j 7.Neste método, o algoritmo inicialmente organiza os componentes por ordem decrescente de área

(quantidade de pixels do componente) e seleciona, em seguida, os dez primeiros. Depois, elimina aque-les cuja altura seja menor que a largura. Caso esse novo conjunto, denotado por C 0, tenha sete ou maiscomponentes, calcula a média das larguras, w, e a média das alturas, h, dos seus elementos. Finalmente,coloca no conjunto C⇤ de saída os componentes c 2 C 0 cujo vetor hw(c), h(c)i menos se distancia dovetor hw, hi, utilizando a distância euclidiana como norma.

Caso C⇤ = ;, fb

é considerada um falso positivo detectado na etapa de extração (vide Seção 3.3.1).Do contrário, o conjunto C⇤ é ordenado segundo a relação {hc

i

, cj

i 2 C⇤ ⇥ C⇤ : ulcx

(ci

) < ulcx

(cj

)},onde ulc

x

(c) retorna a abscissa da coordenada do primeiro pixel para algum c 2 C⇤. Esse conjunto,assim organizado, equivale à tupla de componentes T = hc1, . . . , c7i desejada.

Por fim, um último processamento é realizado sobre os componentes em T , com o objetivo de eliminarpossíveis ruídos na parte inferior, bem como superposições dos recortes, graças a parafusos muito encon-trados nas placas brasileiras, situados entre o segundo e o terceiro, e entre o quinto e o sexto caracteres.

Para tanto, calcula-se h0 = h(c1)+h(c4)+h(c7)3 e recortam-se, de baixo para cima, os componentes do

conjunto {c2, c3, c5, c6} cuja altura ultrapasse h0, até que tenham altura h0. A fim de eliminar super-posições, verifica-se, para cada par hc

i

, ci+1i, 1 i < 7, se ulc

x

(ci

) + w(ci

) � ulcx

(ci+1). Caso

ocorra, recorta-se o componente ci

da direita para a esquerda, de forma que, ao final, sua largura sejaulc

x

(ci

) + w(ci

)� ulcx

(ci+1).

3.3.4 Reconhecimento ótico dos caracteres

Para esta última etapa, aplicou-se a técnica de template matching. Ela exige que haja um modelo (tem-plate) para cada caracter e, dado um caracter ainda não reconhecido, mede-se o grau de similaridade,segundo alguma métrica, dele para todos os templates, atribuindo a classe do modelo mais similar.

Sejam ⌃L

= {a, . . . , z}, ⌃N

= {0, . . . , 9} e ⌃ = ⌃L

[ ⌃N

, respectivamente, o conjunto de letras,de números e de caracteres possíveis, e F = {f

i

} uma família de cenas. Com o objetivo de comporos templates para cada caracter, considere C⇤

i

o conjunto resultante da aplicação das etapas anteriores àcena f

i

2 F . Além disso, defina CF =S{C⇤

i

} e considere I : CF ! ⌃ a função que retorna o caracterrepresentado por um componente, cujos mapeamentos foram determinados à mão pelos autores. Tem-se,com isso, o kernel ⇠ de I , o espaço quociente CF/⇠ e uma bijeção � : CF/⇠ ! ⌃. Define-se, então,T = {t

l

}l2⌃ a família de templates, tal que, para todo l 2 ⌃,

tl

(i, j) =1

|��1(l)|X

c2��1(l)

c⇤(i, j) (15)

onde c⇤ é o componente c redimensionado para 15 ⇥ 20 e hi, ji 2 D(c⇤). A Figura 18 demonstra o

29

Figura 18: Templates utilizados no reconhecimento de caracteres.

Figura 19: Imagens com os 4 tipos de placas (Normal, escura, sombreada e inclinada).

conjunto de todos os templates resultantes desse processo.O próximo passo é definir um vetor de características que represente tanto componentes quanto tem-

plates. Assim, seja c uma imagem na dimensão 15 ⇥ 20. Define-se o vetor correspondente a c comovc = hvc1, . . . , vc300i tal que vc

i

= c�⌃

i

20

⌥, ((i� 1) mod 20) + 1

�, 1 i 300. Quando um compo-

nente c0 chega à etapa de reconhecimento, ele é redimensionado para o tamanho 15⇥20 e calcula-se vc0 .Seleciona-se, em seguida, o template t

r

2 T , r 2 ⌃⇤ ✓ ⌃, tal que

tr

= argmintk2T ,k2⌃⇤

||vc0 � vt||, (16)

onde a norma utilizada é a euclidiana. Classifica-se, finalmente, o componente c0 como sendo o caracterr.

Considerando-se a tupla T de caracteres segmentados, no caso das placas brasileiras, a saída do algo-ritmo é uma sequência de caracteres a1a2 . . . a7, na qual a1, . . . , a3 2 ⌃

L

e a4, . . . , a7 2 ⌃N

. Por essarazão, para as três primeiras componentes da tupla T , ⌃⇤ = ⌃

L

e, para as quatro últimas, ⌃⇤ = ⌃N

, oque reduz o espaço de busca e os erros de classificação.

3.3.5 Experimentos

Utilizando a câmera de um tablet Samsung Galaxy Tab 10.1 de resolução 3264 ⇥ 1836, obteve-se, noestacionamento do Instituto Metrópole Digital (IMD), situado na Universidade Federal do Rio Grande doNorte (UFRN), um conjunto de 481 cenas, fotografadas em período diurno, sem restrições de iluminação,e com distância aos veículos variando entre 1m e 7m. Nessas cenas, identificaram-se 581 placas, as quaisforam classificadas em quatro grupos: normais (N), com 274 placas; escuras (E), com 62; sombreadas(S), com 86; e com inclinação entre 4� e 12� (I), com 159 placas. A Figura 19 exemplifica cada grupo.

Dois hardwares distintos serviram como ambiente de execução: um Raspberry Pi 2 Modelo B (RP2)e um Dell Inspiron 5558 (DELL). O primeiro possui um processador ARM Cortex-A7 quad-core, comfrequencia de 900MHz e 1GB de memória RAM. O segundo, por sua vez, conta com processadorIntel(R) Core(TM) i5-5200U quad-core, de frequência 2.20GHz e 8GB de memória RAM.

Visto que a resolução da cena influencia em parâmetros do algoritmo (Seção 3.3.2) e no esforço com-putacional, principalmente, da etapa de detecção (Seção 3.3.1), os testes consistiram na execução do

30

método sobre as cenas redimensionadas para oito frações das dimensões originais: 100%, 90%, 80%,70%, 60%, 50%, 40% e 30%.

3.3.6 Resultados

A Tabela 7 mostra os resultados obtidos nos testes, variando-se os valores de ↵ e K (Seção 3.3.2),pretendendo obter a melhor acurácia para cada resolução.

Resolução ↵ K N E S I Total

100% 7 55 85.40% 90.32% 66.27% 71.69% 79.34%90% 7 65 85.40% 90.32% 74.41% 76.10% 81.75%80% 6 55 83.57% 91.93% 66.27% 71.06% 78.48%70% 6 55 83.94% 93.54% 79.06% 71.69% 80.89%60% 5 25 82.84% 88.70% 72.09% 69.81% 78.31%50% 7 55 82.48% 83.87% 66.27% 69.81% 76.59%40% 5 25 76.27% 88.70% 62.79% 73.58% 74.87%30% 5 75 68.97% 77.41% 48.83% 56.60% 63.51%

Tabela 7: Classificações corretas por resolução.

A Tabela 7 mostra que a melhor configuração do método produz uma acurácia geral de 81.75%, resul-tado satisfatório por aproximar-se de alguns da literatura [11, 18] e dadas as condições não controladasde captura das cenas. Além disso, percebe-se que o método comporta-se bem para os cenários de baixailuminação e com cortes de sombra, com destaque para o redimensionamento a 70%, o qual permitiuacurácia de 93.54% para placas escuras, 79.06% para sombreadas e 80.89% no geral, muito próximo damelhor configuração.

Figura 20: Tipos de erros.

Quanto ao tempo de processamento, a Figura 21 mostra que as melhores medidas de acurácia, obtidascom 90% e 70% de redimensionamento, ocorreram com tempo médio de 178ms e 210ms, no hardwareDELL, suficiente para permitir o uso em aplicações cujo tempo de execução é recurso crítico. Para oRP2, entretanto, esses tempos foram de 1074ms e 1304ms, o que pode inviabilizar algumas aplicações.Contudo, analisando a Tabela 7, pode-se conseguir, com 50% de redimensionamento, uma acurácia geralde 76.59% gastando-se 875ms em média.

3.4 Próximos Passos

Neste projeto, busca-se a implementação de um sistema de Reconhecimento Automático de Placas (RAP)para veículos brasileiros adaptada para hardwares diversos. A primeira tentativa consistiu na pesquisapor um sistema pronto, resultando no estudo do OpenALPR. Após alguns experimentos, concluiu-se queele não seria viável para os propósitos deste trabalho.

31

20% 40% 60% 80% 100%

200

400

600

800

1,000

1,200

1,400

80 109 145 190 178 201 210 218

510

662

875

10821074

12061304

1191

Resolução (%)

Tem

pom

édio

(ms)

Dell Inspiron 5588Raspberry Pi 2

Figura 21: Gráfico de tempo ⇥ resolução.

No estado atual, o projeto conta com um método próprio para o reconhecimento automático de placasbrasileiras, utilizando técnicas de baixo custo computacional, e robusto para cenas com condições diver-sas de iluminação, sombras e posicionamento. O melhor resultado obtido, considerando todas as placasdo conjunto de teste, foi de 81.75%, levando apenas 210ms na máquina DELL. Em testes com o RP2,esse tempo cresce para 1304ms, porém é possível ajustar a dimensão das imagens para obter temposmenores, com baixa queda de acurácia.

Verificou-se que se faz necessário melhorar o algoritmo para tratar casos onde há caracteres ligadospor parafusos ou com falhas, como visto na Figura 20, respectivamente. Além desses erros, existe anecessidade de refinamento do reconhecimento ótico dos caracteres, pois acontecem, com frequência,erros entre as letras D, O e Q.

Além desses refinamentos, pretende-se, nos trabalhos futuros, testar o método com streams de vídeo,visando a criação de uma aplicação que consiga executar em tempo real. Em paralelo aos testes comstreams, desenvolver-se-á uma aplicação Android que será utilizada pela Polícia Militar na busca porveículos roubados. Por fim, pretende-se criar protótipos com diversos hardwares (Raspberry Pi 0, Rasp-berry Pi 2 e BeagleBone Black) em busca de um produto final utilizável por qualquer aplicação quenecessite de reconhecimento automático de placas.

4 Estacionamento inteligente

4.1 Introdução

A tarefa de encontrar uma vaga de estacionamento em grandes cidades, feriados, grandes eventos tornou-se uma atividade que consome muito tempo do motorista, além de contribuir para o aumento do congesti-onamento do trânsito, gasto com combustível e poluição. Isso se deve muitas vezes a falta de implantaçãode tecnologias disponíveis para auxiliar o usuário de forma eficiente. Este projeto tem como objetivo serum sistema de estacionamento inteligente, que oferecerá serviços tanto para estacionamentos públicoscomo privados. Iremos solucionar, com nosso sistema, uma parte bastante difícil do cotidiano de quemprecisa sair de casa com o seu carro, que é encontrar vagas para estacionar.

Na nossa solução o usuário poderá interagir, por meio de uma aplicação android, com o nosso sistema

32

e saber onde existe vagas para que ele possa estacionar. Existirá uma parte física que irá monitorar pormeio de sensores e câmeras as mudanças de estados, livre ou ocupada, das vagas. Uma outra forma deobter a informação sobre as vagas disponíveis é a utilização de algoritmos de processamento de imagem,aproveitando o fato de que uma câmera pode capturar mais de uma vaga e diversos estacionamentos jápossuem câmeras de vigilância.

Este relatório apresenta a primeira etapa no processo de levantamento de estado da arte de técnicas quese utilizam do processamento de imagem para detecção das vagas disponíveis em um estacionamento etambém um simples protótipo utilizando uma das técnicas descritas. Para melhor visualização organiza-mos os trabalhos encontrados na tabela 8. Em seguida são apresentadas soluções tecnológicas existentesno aspecto de infraestrutura de serviço web, banco de dados e aplicações para dispositivos móveis aserem utilizadas no âmbito do projeto.

4.2 Perpectivas Gerais

O sistema funcionará de forma que teremos uma parte física composta por sensores e uma câmera,que serão responsáveis por monitorar os estados de cada vaga. A cada determinado espaço de tempoesses sensores e câmeras atualizarão os estados das vagas na nossa instância de middleware. Teremosum serviço web, desenvolvido com base na arquitetura REST, que será responsável de recuperar essesestados de vagas e repassar para uma aplicação android, esse serviço web guardará um histórico contendoinformações sobre o usuário e a vaga que ele utilizou. A aplicação android buscará as informações noserviço web e mostrará de forma amigável para os nossos usuários.

O estacionamento inteligente possui algumas restrições para que ele funcione satisfatoriamente. Irá sernecessário que haja internet para que nossos sensores possam se conectar e enviar os dados necessáriospara o nosso middleware. A nossa câmera necessitará de uma placa, como a raspberry pi ou Galileo gen2, para que o algoritmo de identificação de imagens possa executar.

4.3 Soluções de Processamento de Imagens

Nesta seção Serão descritos trabalhos relacionados ao uso de técnicas de processamento de imagens paradetecção de objetos em cena no âmbito de estacionamentos inteligentes. Com base nestes trabalhos po-deremos decidir sobre autilização de algumas destas tecnologias no escopo deste projeto. Estas soluçõesserão futuramente implementadas e avaliadas quanto ao grau de eficiência para que possam ser adotadasda maneira correta. A tabela 8 a seguir resume estes trabalhos.

4.3.1 Smart Parking System using Image Processing Techniques in Wireless SensorNetwork Environment

Para a implantação de um sistema de estacionamento inteligente, Idris et al propõe a utilização das se-guintes tecnologias: técnicas de processamento de imagem (PDI) para detecção de vaga disponível, redesde sensores sem fio e algoritmos de cálculo de menor rota entre os carros e as vagas a serem ocupadas.É proposto um sistema completo de auxílio ao motorista, sendo assim o usuário tem a informação daquantidade de vagas disponíveis e a menor distancia para a vaga desejada ao utilizar um painel na en-trada do estacionamento. O autor propõe que técnicas de PDI sejam os sensores de vaga disponível dosistema, esse escolha é devido principalmente ao fato de que uma câmera pode capturar múltiplas vagascom um menor custo de manutenção quando comparada a outros sensores. O algoritmo de detecção devagas proposto utiliza-se de técnicas baseadas na mudança de background entre uma vaga vazia e uma

33

Autoria Título Local e ano da publi-cação

Palavras chave

M.Y.I. Idris, E.M. Ta-mil, Z. Razak, N.M.Noor, L.W. Kin

Smart Parking Systemusing Image Proces-sing Techniques in Wi-reless Sensor NetworkEnvironment

Information Tech-nology Journal 8,114-127,2009

Smart parking system,WSN, CCTV, A*, mi-crocontroller

R. Yusnita, F. Nor-baya, N. Basharuddin

Intelligent ParkingSpace Detection Sys-tem Based on ImageProcessing

International Jour-nal of Innovation,Management andTechnology, Vol. 3,No. 3, June 2012

Intelligent parking,parking space detec-tion, image processing

H. Al-Kharusi, I. Al-Bahadly

Intelligent ParkingManagement Sys-tem Based on ImageProcessing

World Journal of En-gineering and Techno-logy, 2014

Intelligent Parking,Image Processing,Space Detection

M. D’Aloia, M. Rizzi,R. Russo, M. Notarni-cola, L. Pellicani

A Marker-BasedImage ProcessingMethod for DetectingAvailable ParkingSlots from UAVs

International Con-ference on ImageAnalysis and Pro-cessing, Workshops,LNCS 9281, pp.275–281, 2015

Image processing,Shape recognition,Smart parking, UAV,Urban areas, Markerdetection

W. Lixia, J. Dalin A method of Parkingspace detection basedon image segmenta-tion and LBP

Fourth Internatio-nal Conference onMultimedia Informa-tion Networking andSecurity, 2012

Vehicle Detection,image segmentation,mean shift, LBP

J. Jermsurawong, M.U. Ahsan, A. Haidar

Car Parking VacancyDetection and Its Ap-plication in 24-HourStatistical Analysis

10th InternationalConference on Fron-tiers of InformationTechnology, 2012

Empty slot detection,single camera, multi-car parking monito-ring.

J. Liu, M. Mohandes,M. Deriche

A Multi-ClassifierImage Based VacantParking DetectionSystem

IEEE 20th Internati-onal Conference onElectronics, Circuits,and Systems (ICECS),2013

Smart Parking, VacantParking Space Detec-tion, Image Proces-sing, Edge Detection,Boundary Features

J. K. Suhr, H. G. Jung Full-automatic re-cognition of variousparking slot markingsusing a hierarchicaltree structure

Optical Engineering,2013

Driver assist system,parking assist system,parking slot markingrecognition, hierarchi-cal tree structure

Tabela 8: Trabalhos Encontrados

34

vaga ocupada, essa mudança pode ser observada na figura 22. O limiar de decisão entre vaga ocupadae vaga vazia é decidido empiricamente, enquanto que a decisão de locais de vaga é feito manualmentee uma única vez na fase de setup do software do sistema. Todo o processamento da imagem é feito deforma local, escrito em C em um microcontrolador RabbitCore, que tem embarcado uma câmera e ummódulo ZigBee para comunicação de dados. Uma vez terminado o processamento da imagem, é enviadoao servidor de forma wireless através do módulo ZigBee um mapa de ocupação do estacionamento.Umproblema mencionado pelo autor é que a câmera pode detectar a presença de sombras na vaga e de-terminar um falso positivo, considerando aquela vaga ocupada, o autor não implementa uma soluçãopara este problema mas a indica através do uso da transformada SIFT (Scale-invariant feature trans-form). Não é feito teste em um estacionamento real de funcionalidade do sistema, apenas simulações defuncionamento.

Figura 22: Comparação de background entre vaga vazia e vaga ocupada .

4.3.2 Intelligent Parking Space Detection System Based on Image Processing

Yusnita et al propõe a detecção de círculos marrons pintados no solo do estacionamento como forma demarcação e detecção de vagas. O sistema proposto é composto de cinco módulos:

1. Inicialização do sistema: É feito apenas uma vez, é pintado em cada vaga do estacionamento vazioum circulo de cor marrom. Isto é feito para uma detecção automática do local das vagas.

2. Aquisição da imagem: Uma câmera é posicionada de forma fixa, com altura suficiente para obteruma imagem clara, sem obstrução e de forma a capturar a maior quantidade de vagas possível.Esta câmera é então conectada a uma unidade de processamento

3. Segmentação da imagem: A imagem adquirida é convertida do plano de cor RGB para tons decinza e depois para o formato binário com cores branco e preto. A imagem binária possui toda ainformação sobre os contornos e posição dos objetos presentes.

4. Aprimoramento da imagem: Técnicas morfológicas de PDI são utilizadas para remoção de possí-veis ruídos adquiridos durante as fases anteriores do sistema. É feito a detecção de contornos daimagem, objetos com contornos fechados são detectados

5. Detecção da imagem: São estimados o perímetro e área dos objetos detectados e a fórmula abaixoé utilizada, um círculo é detectado se forma for igual a 1.

Forma =4 ⇤ ⇡ ⇤ areaPerimetro2

Com estes módulos implementados, o autor realizou um experimento onde foi utilizado o Matlab eum PC como linguagem e plataforma de processamento de imagem. A detecção foi feita com sucesso,sendo um sistema on/off de detecção ou não detecção de círculos e considerando um limiar de detecçãode 0.9 na equação acima. Cabe salientar que o ambiente de testes era totalmente controlado.

35

Figura 23: Processo de detecção do estado da vaga.

4.3.3 Intelligent Parking Management System Based on Image Processing

Al-Kharusi et al propõe uma detecção de vagas também baseada em marcações circulares no terreno,porém a cor da marcação é utilizada como fator adicional no momento de decisão do local da vaga. Oautor mostra através de gráficos que marcações da cor verde são facilmente distinguíveis dos outros ob-jetos presentes na imagem. É desenvolvido um protótipo onde as marcações são feitas manualmente emuma imagem e não fisicamente no terremo, onde todas as vagas estão livres. Através de uma sequênciade filtros o autor retira o background da imagem e compara a posição dos círculos previamente marcadoscom a imagem filtrada. A imagem filtrada é formada por duas cores, sendo o background branco e o quenão é background preto, finalmente a comparação entre círculos e imagem filtrada é feita, se a cor dacoordenada do centro do círculo na imagem filtrada for preto, a vaga está ocupada, se não, a vaga estálivre. A figura 23 resume o processo de detecção. O sistema foi implementado utilizando câmeras padrãoconectadas a um rádio transmissor que são alimentados por um fonte de 12V DC recarregadas por umaplaca solar, o transmissor envia as imagens a uma taxa não especificada pelo autor para um PC onde umFPGA realiza processamento da imagem, consequentemente o processamento não é realizado de formalocal, não há maiores especificações sobre o hardware utilizado. O autor comenta que variações climáti-cas podem interferir na confiabilidade do sistema e para solução deste problema filtros mais complexospodem ser utilizados.

4.3.4 A Marker-Based Image Processing Method for Detecting Available Parking Slotsfrom UAVs

M’.D’ Aloia et al propõe que o gerenciamento de vagas em estacionamentos outdoor pode ser feita uti-lizando veículos aéreos não tripulados (UAV), comumente conhecidos como drones. A utilização destesdispositivos é argumentada pelo autor pelo motivo do drone ser mais economicamente viável e mais es-calável para monitoramento de cidades do que múltiplas câmeras ou sensores. O autor supõe que as vagas

36

serão rotuladas com um marcador de formato padrão impresso no asfalto, técnicas de shape mathing sãoutilizadas e o reconhecimento é feito independente do ponto de vista da câmera acoplada ao drone. Testesreais realizados mostraram alta confiabilidade do sistema e que o sistema é independente de escala, derotação, pode detectar o marcador mesmo com um certo grau de distorção e possui certa independên-cia a mudanças de luminosidade. O processamento é realizado de forma local no drone, porém não éinformado maiores detalhes sobre o hardware e software utilizados.

4.3.5 A Method of Parking Space Detection Based on Image Segmentation and LBP

Lixia e Dalin propõe um sistema onde as posições das vagas são definidas manualmente e a detecçãodo estado da vaga é feita através do algoritmo mean shift para realização da segmentação da imagem. Oalgoritmo leva em conta para diferenciar vagas vazias de ocupadas, a presença de componentes presentesem veículos que geralmente não estão presentes no asfalto, como janelas, teto, placas de identificação,pneus, etc. Para a decisão se a vaga está ocupada ou não, é feito uma contagem do número de componen-tes encontrados, vagas ocupadas tendem a ter um alto número de componentes. O algoritmo foi testadoem estacionamentos indoor e outdoor com taxa de sucesso de 97% porém o método falha quando objetosque não são veículos estão presentes na vaga ou quando a cor do asfalto e do carro são semelhantes. Pararesolver este problema é implementado outro método baseado na extração das características de texturada imagem, esses dados alimentam uma máquina de vetores de suporte que compara os dados de vagavazia ou vaga ocupada para realizar a decisão do estado da vaga, por fim também são usadas técnicasde probabilidade para obter uma maior confiabilidade do sistema. Os dois métodos descritos são usadossimultaneamente e caso algum dê resultado positivo para vaga ocupada, a vaga é considerada ocupada.Não são informados detalhes de hardware, linguagem de programação ou tempo de resposta do sistema.

4.3.6 Car Parking Vacancy Detection and Its Application in 24-Hour Statistical Analysis

Jermsurawon et al, propõe uma solução baseada em rede neural para a detecção de vagas em um es-tacionamento. Esta solução tem em vista solucionar três problemas comuns encontrados em sistemasde estacionamento inteligente, mudanças na intensidade da luz ambiente, imagens com pouca luz e adetecção em período noturno. Uma câmera foi posicionada sobre um prédio de 29 andares, detectando126 vagas de estacionamento, esse setup pode ser visto na figura 24. Uma rede neural foi construídae treinada com amostras dos frames de vídeo de uma gravação de 24 horas do estacionamento, após otreinamento a rede foi usada para analisar 24 horas completas de gravação. O autor implementou duasredes filhas que trabalham independentemente, uma para análise no período do dia e outra para o períododa noite. O vídeo de 24 horas tem um framerate de 25 frames por segundo, foram usados 326 framespara treinamento da rede diurna e 112 frames para treinando da rede noturna. Foram utilizados paratreinamento as seguintes características: Iluminação, arranjo de pixels, contornos, cor e tempo. Após otreinamento, o vídeo completo foi analisado, extraindo-se um frame a cada 10 segundos para processa-mento, o método obteve uma acurácia de 99.9% na detecção de vagas ocupadas e 97.9% na detecção devagas livres, o trabalho também apresenta o padrão de preenchimento do estacionamento em diferentesmomentos do dia. Não são informados detalhes de hardware, linguagem de programação ou tempo deresposta do sistema.

4.3.7 A Multi-Classifier Image Based Vacant Parking Detection System

Liu et al propõe que a maioria das técnicas de detecção do estado de vagas de estacionamento, utili-zando PDI, baseiam-se em um grupo de características, como por exemplo: Detecção de bordas, objetos,

37

Figura 24: Local de testes da rede neural

blocos, variações estatísticas da imagem, etc. Um classificador baseado em três grupos é proposto, deforma a obter um sistema mais robusto e confiável. Primeiramente a detecção do local da vaga é feitamanualmente, escolhendo os pontos fixos da imagem que marcarão a vaga, após isso os classificadoressão iniciados. O primeiro classificador é baseado na detecção e contagem de contornos, o segundo nacontagem de objetos e o terceiro na distinção entre o asfalto e os veículos da imagem, cabe salientar queos classificadores atuam de forma independente, gerando um resultado, o resultado final utiliza a regra damaioria para a decisão de vaga livre ou ocupada. Foi utilizada uma câmera Canon 600D para a realizaçãodos testes experimentais, no teste inicial o autor mostra através de tabelas que o sistema está detectandoa vagas com sucesso, porém não é descrito o número de testes realizados ou a porcentagem de acertodo algoritmo. A câmera utilizada foi especificada, mas não foi informado maiores detalhes de hardware,linguagem de programação ou tempo de resposta do sistema.

4.4 Full-automatic recognition of various parking slot markings using a hierarchical treestructure

Suhr et al propõe um sistema para identificação automática do local das vagas em um estacionamento,a motivação do estudo segundo o autor, é que a maioria dos sistemas de estacionamento tem comodefinição do local da vaga um sistema manual de escolha. A definição do local da vaga é feita definindo4 possíveis formatos de estacionamento, mostrados na figura 25, e realizando técnicas de detecção dejunções, ângulos e template matching. O sistema foi testado em 608 situações reais de estacionamentocom variados tipos de marcação de vaga, utilizando uma câmera na parte traseira do veículo. Em 95.9%das vezes o sistema conseguiu encontrar a vaga mais próxima do carro e em 97.2% das vezes o sistemaconseguiu a identificação da vaga do estacionamento, o tempo de processamento de um frame do vídeofoi de 667 ms em um computador de 3.40 Ghz Intel Core i7-2600 CPU com 4GB de RAM, o algoritmofoi implementado em MATLAB.

4.5 Protótipo para Detecção de Objetos em Cena

Com o intuito de validar os artigos apresentados foi implementado um simples protótipo de detecção devagas baseado no método da seção 4.3.1. O protótipo foi escrito em c++ utilizando a biblioteca OpenCV,foi testada a situação de mudança de estado de vaga, de vazia para ocupada, no estacionamento do Insti-

38

Figura 25: Formato de vagas utilizado

tuto Metrópole Digital, utilizando um veículo e uma vaga a ser preenchida. O sistema conseguiu detectara mudança com sucesso, porém cabe salientar que foi testado apenas um cenário, em um mesmo períodode tempo e com condições climáticas constantes. Futuramente o sistema vai ser testado utilizando grava-ções de diferentes períodos do dia e condições climáticas, para termos a informação de quais estratégiasdevem ser implementadas para a obtenção de um método eficiente e funcional.

4.6 Tecnologias de Infraestrutura de Software

As tecnologias que serão descritas neste parte do relatório, são tecnologias responsáveis pela a parteservidor do sistema. O que será discutido neste tópico são as opções de mercados para o desenvolvimentodo banco de dados e do serviço web usando o padrão REST(do inglês Representational State Transfer).

A arquitetura do sistema será baseada no padrão cliente/servidor, onde teremos a aplicação como ocliente. O sistema terá três partes como pode ver na figura 26. Na primeira parte ficarão os periféricos dehardware: sensores ultrasônicos, sensores RFID (do inglês "Radio-Frequency IDentification") e câmera;Na segunda parte do sistema ficarão tanto o serviço web quanto a instância do middleware, e por últimona terceira parte ficará a aplicação android.

4.6.1 Tecnologias Para o Serviço Web

Para a implementação do serviço web iremos optar pelo a implementação do padrão arquitetural webRESTful que é a implementação completa do REST. O padrão REST é um modelo web bastante conso-lidado nos meios comerciais e acadêmicos, ele é baseado no modelo cliente/servidor e usa o protocoloHTTP e seus metodos(GET, PUT, POST, DELETE) para fazer as trocas de mensagens, geralmente égerado com respostas um JSON ou XML com as informações requeridas para o usuário.

Foram levadas em conta para a análise das ferramentas dois frameworks que já são consolidados nomercado, o Spring Framework [4] e o Vraptor[6], e a possibilidade da junção de ferramentas diferentes

39

Figura 26: Primeira Arquitetura do Sistema de Estacionamento Inteligente

para a implementação de cada parte específica do serviço web.A primeira opção que temos para o desenvolvimento do serviço web é o Spring framework. Spring é

um framework MVC(model-view-controller) bastante usado tanto no meio acadêmico quanto no meioprofissional. Ele é uma ferramenta para a linguagem de programação java com finalidade de desenvol-ver aplicações web. O Spring possui incluída em seu core, funcionalidades que são extremamente úteispara programadores experientes e iniciantes. Algumas das funcionalidades interessantes da ferramentasão a implementação do padrão injeção de dependências, abstração para a camada JDBC(do inglês JavaDatabase Connectivity), integração com ferramentas de persistência. A ferramenta é bastante fácil deconfigurar, com bastante informação e tutoriais em seu site. O Spring possui um módulo bastante inte-ressante o Spring boot. O Spring boot possui todas as funcionalidades do spring MVC, mas nesse móduloele possui o Tomcat[1], tomcat é um container web leve usado para hospedar sistemas web, como con-tainer web embutido, além de gerar um executável java o que deixa bastante flexível suas aplicaçõesweb.

O Vraptor é a segunda opção considerada para desenvolver o serviço web do sistema. Assim comoo spring o vraptor é um framework MVC voltado para desenvolvimento java, ele começou a ser desen-volvido em 2003 pelo o IME-USP porém agora a Caelum ficou responsável por manter a ferramenta. OVraptor usa padrões como injeção de dependências e inversão de controle para diminuir muito o tempoque seria perdido como códigos repetitivos. O vraptor possui uma curva de aprendizado bastante baixa,e isso acontece por alguns motivos: a ferramenta é brasileira então sua documentação é basicamentetoda em português, a comunidade é bastante ativa, a caelum é patrocinadora da ferramenta então possuibastante tutoriais de como utilizá la em seus sites; todos esses motivos fazem o Vraptor uma ferramenta

40

bastante atraente para desenvolver um sistema web.Como última opção foi considerada que poderia ser interessante usar ferramentas específicas para

cada parte do serviço web. Para a implementação de um serviço web é necessário que se implemente asespecificações do Java Enterprise Edition(EE). Java EE especifica basicamente como se deve ser feita apersistência ou comunicação web do sistema por exemplo, e isso é interessante para que aplicações comtecnologias diferentes uma das outras possam conversar. As duas ferramentas apresentadas implementamgrande parte dessas especificações, o que é bastante interessante para o nosso projeto, porém dependendodo ambiente em que os sistemas desenvolvidos com essas ferramentas vão rodar, pode ocorrer um esforçomuito grande para a plataforma. Para evitar esforços desnecessários e otimizar recursos da plataforma,que podemos usar ferramentas diferentes para cada parte da especificação, por exemplo: Frameworkjersey que fornece implementação para a parte de comunicação web(REST).

4.6.2 Tecnologias Para o Banco de Dados

Assim como as ferramentas para a implementação web do sistema, separamos três bancos de dados parauma análise e possível escolha a fim de que possa ser usado no nosso sistema. Desses três bancos dedados um deles é um banco de dados comum e dois deles são sistemas de gerenciamento de banco dedados(SGBD), SGBD são sistemas que garantem a consistência das operações feitas em seus banco dedados. PostgreSQL e Mysql são sgbd, o Sqlite3 é um banco de dados comum.

Figura 27: Primeiro Modelo ER do Banco de Dados do Estacionamento Inteligente

Na figura 27 podemos ver um primeiro esquemático das tabelas que estarão no banco de dados es-colhido. Nesse refinamento temos cinco entidades: User, Car, History, RFIDcard e Spot; Cada entidaderepresentará uma um entidade do nosso sistema, na tabela User por exemplo será guardada as informa-ções dos usuários, como: Nome, se ele é um usuário que possui deficiência, a idade, se ele dispõe deum cartão RFID. Como esse modelo do banco é apenas uma visão inicial do sistema ele poderá sofrer

41

mudanças ao longo do tempo do projeto, porém ele é suficiente para esboçar como será guardada cadatipo de informação.

Tanto o PostgreSQL[3] como o Mysql [2] são bastante parecidos, o fato de ambos serem SGBD influ-encia muito isso, então não poderíamos discutir um sem falar do outro. Ambos são bastante utilizadosno cenário acadêmico e comercial. Ao ponto que o mysql fornece mais performance de máquina o post-gresql ganha em robustez em operações além de possuir muito mais recursos que o mysql. Coisas comorollback, commit, view e trigger já existiam muito antes no postgresql do que no mysql. É aconselhá-vel usar o mysql em sistemas que não precisem de operações transacionais muitos complexas comoback-end de sites web e sistemas que possuem basicamente consultas e adições de dados. O postgresql éaconselhado para sistemas com operações complexas, ou com tipos de dados especializados.

O Sqlite3 diferentemente dos outros dois banco de dados discutidos não é um SGBD, porém isso nãoo torna menos competitivo. O sqlite é bastante flexível em vários aspectos: não requer muito proces-samento, um banco de dados pode ser literalmente copiado e colado para outra máquina sem perda dedados, fácil de instalar e usar. Por motivo dele não ser um SGBD, como já foi mencionado, faz comele não seja usado em grandes aplicações onde a persistência de dados tem que ser bastante consis-tente, porém ele foi praticamente adotado como banco de dados oficial de aplicações móveis. Toda essaversatilidade dele o torna bastante atrativo.

4.7 Progresso

Nessa primeira parte do projeto foram feitos alguns testes, dois testes para ser exato, para validar o queestávamos pensando para o sistema. Nesses primeiros testes foi avaliado a integração do protótipo inicialda aplicação android com o middleware, e dos sensores que serão utilizados para monitorar as vagas como middleware.

Figura 28: Protótipo da AplicaçãoFigura 29: Módulo Esp8266 e sensor HC-

SR04 usados nos testes

Na figura 28 podemos ver um protótipo inicial da aplicação android, esta aplicação é apenas a imple-mentação inicial da aplicação que foi usada nos testes que foram feitos, conforme for avançando o projeto

42

essa aplicação irá melhorando tanto esteticamente quanto com funcionalidades. A aplicação mostra essespontos no mapa onde está a vaga e qual é seu estado, o ponto vermelho mostra que a vaga está ocupada,verde que está livre e azul é um vaga especial vaga. Na figura 29 mostra os sensores que foram usadospara identificar se existe um carro na vaga e então enviar para o middleware essa informação.

No primeiro teste foi desenvolvido um programa onde ele apenas simularia as mudanças de status dasvagas cadastradas, ele não possuía muito fidelidade com um cenário real porém era o suficiente parasaber se seríamos capazes de coletar esses dados gerados pelo o programa por meio de uma aplicaçãoandroid.

No segundo teste foi utilizado um módulo Esp8266 nodeMCU para enviar os dados para o middleware,neste teste utilizamos uma lógica mas parecida com um cenário real para coletar os dados da vaga. Nesseteste utilizamos um sensor ultrasônico HC-SR04 para determinar se um carro estava estacionado navaga monitorada, quando ele chegava a uma determinada distância do sensor o programa enviava para omiddleware uma mensagem HTTP POST avisando que a vaga agora estava ocupada.

Ambos os teste foram um sucesso, e nos deram um embasamento de como o sistema poderá funcionar.Para os próximos passos estamos planejando a integração de um feed da câmera, que irá atualizar todasas vagas que ela conseguir monitorar. Após a integração da câmara dos sistema o próximo passo lógicoé integrar as informações da câmera junto com as dos sensores e ver como o sistema irá funcionar.

4.8 Próximos Passos

Para as próximas etapas do projeto decidimos usar o framework Spring junto com o banco de dadospostgresql. O spring por ser bastante flexível e possuir muitas funcionalidades que serão interessantespara o nosso projeto, ele também possui uma licença apache 2.0 o que irá ajudar caso queiramos registraro nosso sistema. O postgresql é bastante conhecido, além de ser bastante robusto com as operações queele fornece e possuir uma licença BSD que possibilita um possível registro da nossas solução mais afrente.

Por mais que tenhamos escolhidos essas ferramentas para prosseguirmos no nosso projeto não significaque elas serão imutáveis, dependendo do contexto que nosso sistema se encontre se houver a necessidadede mudar as tecnologias para outro que se encaixe melhor no contexto será feito a troca, se caso precisarincluir outras tecnologias que agregam valor ao projeto também iremos adicioná las.

Os passos seguintes agora do projeto é tentarmos unir tudo que já temos em um protótipo que se possainteragir em um cenário real, os sensores e câmeras poderem alterar os valores das vagas simultâneo eindependente umas das outras.

5 Considerações Finais

Os três primeiros meses de execução do Projeto Smart Metropolis (Ano 2) referente ao WP-Sensoriamentoforam focados no desenvolvimento inicial das iniciativas de Monitoramento de Frotas, Detecção de Pla-cas e Estacionamento Inteligente. Estudos sobre as principais soluções (literatura, coorporativo), análisede viabilidade das tecnologias, levantamento de requisitos e especificação das arquiteturas de software ehardware foram as principais ações desenvolvidas. Protótipos embrionários foram também implementa-dos em todas as iniciativas mencionadas. Em relação a iniciativa do Poste Inteligente, um arquivo anexoao relatório descreve os testes de autonomia energética executados. O grupo de pesquisadores envolvi-dos no WP-Sensoriamento considera que as tarefas planejadas para o período foram implementadas comsucesso.

43

6 Referências

[1] Apache tomcat. http://tomcat.apache.org/.

[2] Mysql. https://www.mysql.com/.

[3] Postgresql. https://www.postgresql.org/.

[4] Spring framework. https://spring.io/.

[5] Sqlite. https://www.sqlite.org/.

[6] Vraptor framework. http://www.vraptor.org/.

[7] N. A. Ali, M. AbuElkhair, and S. Bouktif. Utilizing VIN for improved vehicular sensing. In IEEEWireless Communications and Networking Conference, WCNC 2016, Doha, Qatar, April 3-6, 2016,pages 1–6, 2016.

[8] C. N. Anagnostopoulos, I. E. Anagnostopoulos, I. D. Psoroulas, V. Loumos, and E. Kayafas. Li-cense plate recognition from still images and video sequences: A survey. Trans. Intell. Transport.Sys., 9(3):377–391, Sept. 2008.

[9] C. Arth, F. Limberger, and H. Bischof. Real-time license plate recognition on an embedded dsp-platform. In CVPR. IEEE Computer Society, 2007.

[10] T. best obdii scanners. 10 modes of operation for obd2 scanners, sep 2014.

[11] G. Corneto, F. A. da Silva, D. R. Pereira, L. L. de Almeida, A. O. Artero, J. P. Papa, V. H. de Albu-querque, and H. M. Sapia. A new method for automatic vehicle license plate detection. IEEE LatinAmerica Transactions, 15:75 – 80, 2017.

[12] S. Du, M. Ibrahim, M. Shehata, and W. Badawy. Automatic license plate recognition (alpr): Astate-of-the-art review. IEEE Trans. Cir. and Sys. for Video Technol., 23(2):311–325, Feb. 2013.

[13] Freematics. Freematics, feb 2017.

[14] Y. Freund and R. E. Schapire. A decision-theoretic generalization of on-line learning and an appli-cation to boosting. Journal of Computer and System Sciences, 55(1):119 – 139, 1997.

[15] Google. Android, oct 2016.

[16] S. hyun Baek and J.-W. Jang. Implementation of integrated obd-ii connector with external network.Information Systems, 50:69 – 75, 2015.

[17] Jovargas. br.xml, feb 2017.

[18] C. A. Mello and D. C. Costa. A complete system for vehicle license plate recognition. In IWSSIP2009. IEEE Computer Society, 2009.

[19] E. C. Neto, S. L. Gomes, P. P. R. Filho, and V. H. C. de Albuquerque. Brazilian vehicle identificationusing a new embedded plate recognition system. Measurement, 70:36 – 46, 2015.

[20] OpenALPR. Github - openalpr, oct 2016.

[21] OpenCV. Opencv, apr 2017.

[22] G. OpenCV. Github - opencv, oct 2016.

[23] P. Pires. Github - android-obd-reader, feb 2017.

44

[24] P. Pires. Github - obd-java-api, feb 2017.

[25] Tesseract. Github - tesseract, oct 2016.

[26] P. Viola and M. Jones. Rapid object detection using a boosted cascade of simple features. InProceeding of the CCVPR, pages 511–518, 2001.

[27] Y. Wang, B. Fang, L.-J. Lan, H.-W. Luo, and Y.-Y. Tang. Adaptive binarization: a new approachto license plate characters segmentation. In Proceedings of the 2012 International Conference onWavelet Analysis and Pattern Recognition. IEEE Computer Society, 2012.

[28] Wikipedia. Obd-ii pids, apr 2017.

[29] B.-F. Wu. Extracting characters from real vehicle licence plates out-of-doors. IET Computer Vision,1:2–10(8), March 2007.

PLATAFORMA AUTONOMICA DE CONECTIVIDADE E SENSORIAMENTO PARACIDADES INTELIGENTES

Aluizio Rocha Neto

⇤, Rafael Clemente

†, Tha

´

ıs Freitas

‡

⇤Instituto Metropole Digital

Campus Universitario, UFRN, Lagoa Nova, s/n

Natal, RN, Brasil

Emails: aluizio@imd.ufrn.br, rafaelpereirac@ufrn.edu.br, thaisalvesfr@gmail.com

Abstract— The use of smart solutions for urban applications, like environmental control and security, it hasbeen the point of many works on Smart Cities. These solutions, must involve capable researches with the SmartCities proposal, with clean energy, low coast and autonomy. This article, presents the development of a computerautonomic platform that uses a smart pole compounded by solar panel for energy generation, sensoring based onLinux, open-hardware and mechanisms of WiFi connectivity, which one can be applied in many situations.

Keywords— Internet of Things (IoT); Smart Cities; Solar Energy.

Resumo— O uso de solucoes inteligentes para aplicacoes urbanas, como controle ambiental e seguranca, temsido o foco de trabalhos para cidades inteligentes. Tais solucoes devem envolver recursos compatıveis com aproposta de cidades inteligentes, isto e, que envolvam energia limpa, baixo custo e autonomia. Este artigoapresenta o desenvolvimento de uma plataforma computacional autonomica que faz uso de um poste inteligentecomposto por painel solar para geracao de energia, sistema de sensoriamento baseado em Linux e open-hardware

e mecanismos de conectividade sem fio, cujo proposito pode ser destinado a diversas aplicacoes.

Palavras-chave— Internet das Coisas; Cidades Inteligentes; Energia Solar.

1 Introducao

O desenvolvimento de solucoes a partir de dis-positivos de baixo custo, tais como Arduino1 eRaspberryPi2, tem impulsionado a criacao de di-versas aplicacoes para a Internet das Coisas (IoT)(Pfister, 2011). Nesse contexto, a Internet e a in-fraestrutura de comunicacao universal que inter-liga todo tipo de dispositivo, geralmente carrega-dos de sensores, que produzem diversos dados so-bre os locais onde estao instalados. Muitas dasaplicacoes da IoT sao solucoes para as chamadascidades inteligentes, onde diversas informacoes eservicos sao providenciados para facilitar a vidados cidadaos.

Tudo isso e possıvel gracas a evolucao da ele-tronica embarcada, que viabiliza a construcao dechips cada vez menores e de menor custo, baixıs-simo consumo de energia e com um bom podercomputacional. Estes novos dispositivos da IoTfez surgir a cultura DIY (Do It Yourself – facavoce mesmo), pela qual qualquer pessoa pode criaro seu prototipo de “coisa inteligente”, carregadade sensores e atuadores, gerando informacoes emtempo real e controlados remotamente pela Inter-net.

Paralelo a este cenario, estudos demonstramque a radiacao solar que chega a terra e capaz defornecer o correspondente a 10.000 vezes o con-sumo mundial de energia. A cidade de Natal,conforme mostrado em (Pereira et al., 2006), e pri-vilegiada com esta fonte de energia inesgotavel elimpa. Acoes que aproveitem esse potencial ener-

1https://www.arduino.cc2https://www.raspberrypi.org

getico sao sempre requeridas, principalmente pelaquestao da sustentabilidade em nosso planeta.

Neste trabalho, e feito um experimento de ge-racao de energia eletrica atraves do uso de painelsolar para alimentar uma plataforma computacio-nal que prove conectividade com a Internet e sen-soriamento para cidades inteligentes. Tal plata-forma e disponibilizada aos cidadaos na forma deum conjunto de dispositivos instalados nos postesda cidade.

2 Energia Solar

Estudos demonstram que a radiacao solar quechega a terra e capaz de fornecer o correspondentea 10.000 vezes o consumo mundial de energia. Acidade de Natal, assim como outras dentro da zonatropical, e privilegiada com esta fonte de energiainesgotavel e limpa. Acoes que aproveitem essepotencial energetico sao sempre requeridas, prin-cipalmente no Brasil que concentra praticamentetoda a sua producao de energia a usinas hidroele-tricas e sofre com perıodos de secas prolongadas.Atualmente, a Alemanha e o paıs que mais usaenergia solar fotovoltaica. Sua capacidade insta-lada e de 20GW (giga Watts), superior a de todosos outros paıses juntos. A melhor insolacao daAlemanha e cerca de 3500 Wh/m2 (watt-hora pormetro quadrado) por dia, disponıvel em uma pe-quena regiao de seu territorio. Para comparacao,o Brasil apresenta valores de insolacao diaria entre4500 Wh/m2 e 6000 Wh/m2, o qual permitiria oBrasil chegar a uma producao de 200GW de ele-tricidade a partir da luz do Sol (Villalva, 2015).

Aliando este potencial de geracao limpa de

energia com o baixo consumo de eletricidade dosdispositivos de IoT, o projeto do poste inteligentese mostrou extremamente viavel e com grandeaceitacao, dado que postes talvez seja a coisa maisencontrada em qualquer cidade de todo o mundo.Facilmente, e possıvel acrescentar as funcionali-dades do poste recursos de iluminacao publica einteligente, utilizando um controle automatizadode lampadas de LEDs que possuem um baixo con-sumo de energia.

Para o experimento, foi utilizado um painelsolar monocristalino da marca RENOGY, modeloRNG-100D, com potencia maxima de 100W, ten-sao de maxima potencia 18,9V, corrente de ma-xima potencia 5,29A, tensao de circuito aberto22,5V e corrente de curto-circuito 5,75A.

O painel so gera energia quando ha incidenciade raios solares no mesmo. Assim, para que o sis-tema funcione nos perıodos noturnos ou muito nu-blado, e preciso armazenar a energia gerada pelopainel em baterias e usar esta energia armazenadanestes momentos. O controle da producao e con-sumo de energia em todo o sistema solar e feitopelo controlador EPsolar VS2024BN, visto na Fi-gura 1. A bateria e uma de chumbo-acida regu-lada por valvula (VRLA) da marca UNIPOWER,modelo UP12400 de 12V e 40Ah.

Figura 1: Controlador EPsolar VS2024BN.

Para proteger e englobar todo o sistema decontrole, carga e alimentacao, foi construıda emferro uma estrutura do topo do poste com umacaixa devidamente isolada, porem facilmente aces-sıvel para manutencao, onde ficam as baterias edemais equipamentos da solucao (Figura 2).

A medida que o modulo solar capta uma de-terminada quantidade de energia e esta nao e con-sumida por todo o sistema, o controlador uti-liza esta energia excedente para carregar a bate-ria. Nossos resultados mostraram que o dimen-sionamento das capacidades do painel e da bate-ria foram suficientes para que o sistema funcioneininterruptamente, mesmo em dias chuvosos compouca producao de energia.

3 Sistema de Coleta de Dados

O primeiro desafio foi obter em tempo real os da-dos da producao e consumo de energia de todo osistema, de forma a redimensionar o painel ou a

Figura 2: Estrutura principal do poste com o pai-nel solar.

bateria, ou mesmo a quantidade de equipamentosligados ou tentar reduzir o consumo eletrico decada um.

A plataforma de sensoriamento foi feita uti-lizado o microcomputador Beaglebone3 visto naFigura 3. Esta placa coleta do controlador solaros dados sobre a producao e o consumo de energia,alem de prover portas para sensores e atuadoresusados no poste.

Figura 3: Placa BeagleBone Black.

Para a coleta dos dados do controlador naBeaglebone, foi utilizado um codigo aberto emPython, desenvolvido pelo finlandes Jarkko Son-ninen e disponibilizado sob Licenca Apache 2.0no GitHub https://github.com/kasbert/epsolar-tracer. Este codigo de Sonninen implementa oprotocolo de comunicacao ModBus4, utilizado naporta RS-485 do controlador solar utilizado.

3http://beagleboard.org4https://en.wikipedia.org/wiki/Modbus

Os dados do controlador sobre a producaoe consumo de energia sao coletados em perıodosde 5 minutos e enviados via HTTP RESTfulpara a plataforma de IoT ThingSpeak5. Comoesta plataforma limita em 8 a quantidade dedados por canal, foram criados 3 canais: umcanal com dados sobre a producao de energia(https://thingspeak.com/channels/225747),outro com os dados sobre o consumo(https://thingspeak.com/channels/225824) eum terceiro canal com os dados estatısticosda producao e consumo diario, mensal e anual(https://thingspeak.com/channels/229212). AFigura 4 mostra o grafico gerado automati-camente pela plataforma ThingSpeak para aproducao de energia diaria do poste.

Figura 4: Grafico mostrando a producao de ener-gia diaria.

4 Sistema de Conectividade

Para prover o acesso a Internet ao poste foramutilizados um par de radios Ubiquiti PowerBeamM5 com antena direcional (prato de microondasde 30cm) de 22dBi e frequencia de 5GHz. O radioque prove o acesso fica em cima de uma edificacaoprovedora do acesso a Internet e o outro no poste,conforme pode ser observado na Figura 2.

O poste compartilha o seu acesso a Inter-net com os transeuntes atraves de um Access

Point Wi-Fi Ubiquiti NanoStation M2 de 2.4GHz.Para capturar as imagens do local o poste uti-liza uma camera IP Ubiquiti Unifi Video CameraHD 720p e LEDs de infravermelho para visao no-turna. Tanto a camera quanto o Access Point po-dem tambem serem observados na Figura 2.

Para interligar todos os equipamentos noposte, foi utilizado um TOUGHSwitch PoE de5 portas tambem da Ubiquiti, que oferece 24Vvia PoE (Power over Ethernet) em cada porta.Sua alimentacao padrao e atraves de uma fonteAC/DC 24V. Como no poste nao ha corrente AC,

5https://thingspeak.com

e o controlador/bateria fornece 12V DC, foi utili-zado um conversor de tensao DC/DC Step Up 12Vpara 24V, o qual alimenta o switch, que por suavez alimenta todos os outros equipamentos Ubi-quiti. A alimentacao da Beaglebone e atraves deum outro conversor de tensao DC/DC Step Down12V para 5V.

A Figura 5 mostra a topologia das redes deenergia e de logica montadas no poste.

Figura 5: Redes Logica e Eletrica no poste.

5 Fundamentacao pratica

Para a preparacao deste artigo, utilizamos os da-dos coletados a partir do controlador solar, paraa producao e o consumo diario de energia, no mesde marco de 2017. Os dados deste mes foram inte-ressantes pois e caracterizado por um perıodo in-termediario entre o verao (maior producao solar) eo inverno (menor producao solar), e que em Natalaconteceu, pelo menos, dois dias inteiros de muitachuva: 02 e 23/marco/2017. Os ındices de preci-pitacao em Natal foram obtidos a partir do sitedo INPE (http://bancodedados.cptec.inpe.br). OGrafico da Figura 6 cruza os dados de producao econsumo de energia do poste com os de precipita-cao em Natal.

Figura 6: Energia e precipitacao em Marco/2017.

Percebe-se por este grafico que o consumo deenergia da solucao e de cerca de 200 Watts por

dia e a producao de energia tem uma media diariade 310 Watts, a qual inclui alimentar os equipa-mentos e carregar a bateria. O consumo de todosequipamentos durante o dia e percebido atraves docalculo da potencia individual em Watts por hora(Wh) multiplicada pelas 24 horas do dia. Chega-se ao valor teorico de 0.264KW/h, se levado emconsideracao as condicoes maximas de consumode energia, na qual todas as portas PoE do Switchestao em uso, alem da Beaglebone ter picos de cor-rente de 160mA, e o acrescimo de 2 Wh no perıodonoturno quando os LEDs de infravermelho da ca-mera sao ligados.

O mais interessante de ser observado no Gra-fico da Figura 6 e o aumento consideravel de pro-ducao de energia no dia seguinte a um dia chu-voso. E possıvel perceber este fenomeno nos diaschuvosos 02 e 23 de marco, com um aumento daproducao de energia nos dias 03 e 24 de marco,respectivamente, nos quais o sol apareceu por umperıodo suficiente para carregar totalmente a ba-teria. No dia 03 de marco, inclusive, chegou achover 12mm no perıodo de luz do sol (entre 5h e18h), e 25,8mm no total.

Isso demonstra que o sistema de geracao deenergia solar trabalha sob demanda de acordo coma carga necessaria para alimentar todos os equipa-mentos. Percebe-se pelos resultados obtidos ateagora que pode haver ainda uma capacidade deenergia desperdicada por falta de demanda, o quenos permitiria ligar mais equipamentos na solucaodo poste. Atualmente, em dias normais de sol, abateria e 100% carregada antes mesmo do meiodia, fazendo com que nao se utilize de maneiraplena o sol do perıodo da tarde.

6 Aplicacoes para Cidades Inteligentes

Com o desenvolvimento desta Plataforma de PosteInteligente, diversas aplicacoes para cidades inte-ligentes foram pensadas, algumas ja em fase dedesenvolvimento no campus da UFRN em Natal.

As aplicacoes ja disponıveis com os equipa-mentos instalados no poste sao:

• Provimento de acesso Wi-Fi aos transeuntesnas proximidades do poste;

• Camera de seguranca em locais onde a rededo campus nao chega, como por exemplo, asparadas de onibus; e

• Sensoriamento das condicoes de poluicao am-biental e sonora, atraves do uso de sensoresde temperatura, umidade, gases e ruıdos so-noros.

Outras aplicacoes que podem facilmente se-rem beneficiadas com o Poste Inteligente sao:

• Controle automatizado da ocupacao de es-tacionamentos, a partir das imagens geradas

pela camera percebendo quais vagas ainda es-tao livres;

• Ponto de iluminacao autonomica e inteligentea partir de lampadas de LED;

• Disponibilizacao de paineis digitais com in-formacoes uteis atualizadas em tempo real;

• Controle automatizado de semaforos ao per-ceber, pela imagem da camera, que ha umcarro precisando cruzar a rua.

Testes iniciais mostraram que boa parte des-tas aplicacoes podem realizar o processamento dosdados provenientes dos sensores no proprio poste,no microcomputador Beaglebone usado neste pro-jeto.

7 Conclusoes

O desenvolvimento de um poste alimentado porenergia solar, como uma plataforma para disposi-tivos da IoT, se mostrou bastante viavel e nos per-mitiu vislumbrar diversas aplicacoes para cidadeinteligentes. Os sensores de imagem (camera) edas condicoes ambientais (temperatura, umidade,gases, sons, etc.) possibilitam obter dados dosmais variados tipos para geracao de informacoesque facilitem a vida dos cidadaos.

O processamento em tempo-real do grande vo-lume de dados gerados pelos sensores e um dosprincipais desafios das aplicacoes de IoT. Micro-computadores de tamanho reduzidos, com baixoconsumo de energia e boa capacidade computa-cional podem realizar este processamento direta-mente na fonte do dado, permitindo amenizar ovolume de dados de sensores trafegados na Inter-net.

Por fim, conclui-se que a plataforma desenvol-vida tem grande potencial de aplicabilidade e acei-tacao. Aplicacoes de monitoramento ambiental ede seguranca publica, que necessitam de um sis-tema de sensoriamento instalado em pontos estra-tegicos da cidade, sao potenciais candidatos parauso desta infraestrutura autonomica computacio-nal.

Agradecimentos

Agradecemos a todos os colabora-dores do Projeto Smart Metropolis(http://smartmetropolis.imd.ufrn.br/) do Insti-tuto Metropole Digital da UFRN, que direta ouindiretamente contribuıram com o desenvolvi-mento deste projeto.

Referencias

Pereira, E., Martins, F., Abreu, S. and Ruther,R. (2006). Atlas Brasileiro de Energia Solar,Sao Jose dos Campos : INPE.

Pfister, C. (2011). Getting Started with the Inter-

net of Things: Connecting Sensors and Mi-

crocontrollers to the Cloud, 1st edn, O’ReillyMedia, Inc.

Villalva, M. G. (2015). Energia Solar Foto-

voltaica: conceitos e aplicacoes, 2nd edn,Erica/Saraiva.