TCC2018 TomyMoreiraSantos

Universidade Estadual de Londrina
Centro de Tecnologia e Urbanismo

Departamento de Engenharia Elétrica
Tomy Moreira dos Santos
Protótipo de um Sistema de Telemetria

Veicular de Baixo Custo voltado para
Esportes à Motor
Londrina
2018
Centro de Tecnologia e Urbanismo
Departamento de Engenharia Elétrica
Protótipo de um Sistema de Telemetria Veicular de

Baixo Custo voltado para Esportes à Motor
Trabalho de Conclusão de Curso orientado pelo Prof. Dr. Ernesto

Fernando Ferreyra Ramirez intitulado “Protótipo de um Sistema de
Telemetria Veicular de Baixo Custo voltado para Esportes à Motor”
e apresentado à Universidade Estadual de Londrina, como parte
dos requisitos necessários para a obtenção do Título de Bacharel
em Engenharia Elétrica.
Orientador: Prof. Dr. Ernesto Fernando Ferreyra Ramirez
Londrina
2018
Ficha Catalográfica

Protótipo de um Sistema de Telemetria Veicular de Baixo Custo voltado para
Esportes à Motor - Londrina, 2018 - 89 p., 30 cm.
Orientador: Prof. Dr. Ernesto Fernando Ferreyra Ramirez
1.Telemetria. 2.Redes CAN. 3.Monitoramento. 4.Arduino. 5. Esportes à
Motor
I. Universidade Estadual de Londrina. Curso de Engenharia Elétrica. II.
Protótipo de um Sistema de Telemetria Veicular de Baixo Custo voltado para
Esportes à Motor.
Protótipo de um Sistema de Telemetria

Veicular de Baixo Custo voltado para
Esportes à Motor
Trabalho de Conclusão de Curso apresentado ao Curso de

Engenharia Elétrica da Universidade Estadual de Londrina,
como requisito parcial para a obtenção do título de Bacharel
em Engenharia Elétrica.
Comissão Examinadora
Prof. Dr. Ernesto Fernando Ferreyra

Ramirez
Orientador
Prof. Dr. Francisco Granziera Junior

Prof. Dr. Aziz Elias Demian Junior

Londrina, 17 de dezembro de 2018

Agradecimentos
Primeiramente eu gostaria de agradecer a minha mãe, Léia, e meu pai, Ivan. Vocês dois
sempre fizeram muito mais do que puderam para me ajudar passar por todos os problemas
enfrentados durante este período. Peço desculpas a vocês por ter estado ausente em muitos
momentos e agradeço muito por todo o amor e paciência dedicada à minha vida. Espero
que neste momento eu possa trazer um momento de orgulho à vocês.
Aos meus dois irmãos Henrique e Claudio. Vocês foram, são e serão parte muito
importante da minha vida. Em praticamente todos os importantes momentos da minha
vida eu tive vocês dois ao meu lado, e espero que por muitos anos assim se siga.
Aos meu amigos do Clube do Bolinha, o que com certeza também já uma família.
Todas as festividades com vocês ficam ainda melhores. Todas as dificuldades, com vocês
tornam-se mais simples. Obrigado.
A todos os irmãos que encontrei dentro do curso, em especial ao Walker Negrão, Pedro
Mantovani e ao Rodolfo Cibotto. Quantas foram as aventuras, as batalhas, os choros e as
alegrias que vivemos juntos. Vocês com certeza são pessoas que marcaram a minha vida,
e espero que não nos afastemos muito com o fim desta jornada.
Aos meus grandes amigos Marcelo Haddad, Ruan Martins, Giuliano Motter e Matias
Furlaneto. Nós fizemos parte do Indie Hour! Eu acredito muito no poder da música, e com
certeza juntos nós podemos transmitir muitas alegrias para as pessoas que nós assistiam.
Obrigado por sempre apoiarem minhas ideias e pela infinita paciência durante os ensaios
em que as coisas não saíram da melhor forma possível.
Agradeço a minha amiga Carolina. Grande parte de tudo o que vivi durante a uni-
versidade foi ao seu lado, com o seu auxilio e suporte. Te agradeço por toda paciência e
por todo carinho dedicado a mim durante esses anos. Com certeza eles foram essenciais.
Agradeço a toda banca avaliadora - professores Aziz e Granziera - pelos direcionamen-
tos durante a construção deste trabalho. Agradeço também aos técnicos de laboratório
Luís e Luís Matias por todo o empenho e prontidão sempre que foram requisitados.
Agradeço também, com muito carinho, meu orientador e professor Ernesto. Você
com certeza nos ensinou muito mais do que engenharia. Você nos ensinou a ser pessoas
melhores. Muito obrigado por toda a atenção dedicada, em especial a mim, durante esta
fase da nossa vida. Tenho certeza que se mais professores fossem como você a Universidade
seria um lugar muito melhor.
E por fim, agradeço a instituição a qual talvez eu mais tempo tenha dedicado durante
minha vida universitária, a bateria Demônios da Lagoa. As minhas amigas Bethânia,
Jéssica, Heloisa, Adriane e aos meus irmãos Giovani, Guilherme dentre tantos outros.
Vocês todos tornaram os dias mais felizes e tenho certeza que nosso trabalho tem ajudado
muitos universitários a passar por está fase da vida de uma maneira mais leve. Obrigado
por sempre me apoiarem e por me deixarem fazer parte das suas vidas.
Tomy Moreira dos Santos. Protótipo de um Sistema de Telemetria Veicular de
Baixo Custo voltado para Esportes à Motor. 2018. 89 p. Trabalho de Conclusão
de Curso em Engenharia Elétrica - Universidade Estadual de Londrina, Londrina.
Resumo
O trabalho aqui apresentado busca desenvolver um protótipo de sistema de telemetria
de baixo custo que atenda de maneira satisfatória os requisitos de categorias de esportes
à motor de nível amador. Foram desenvolvidos módulos de temperatura e aceleração
com o objetivo de simular uma instalação em diferentes partes de um veículo. O sistema
implementa uma rede CAN entre os módulos e uma central de processamento microcon-
trolada. O sistema também conta com software supervisório responsável pela recepção
dos dados e exibição de maneira gráfica ao usuário. O sistema obtido ao final do trabalho
apresentou um comportamento dentro dos padrões de desempenho esperado. O software
supervisório foi adaptado de um trabalho anterior e, devido a este fato, não apresentou o
melhor desempenho possível.
Palavras-Chave: 1.Telemetria. 2.Redes CAN. 3.Monitoramento. 4.Arduino. 5. Espor-

tes à Motor
Tomy Moreira dos Santos. Low Cost Prototype of Vehicle Telemetry System for
Motor Sports. 2018. 89 p. Monograph in Electrical Engineering - Londrina State
University, Londrina.
Abstract
The study presented here aims to develop a prototype of a low cost telemetry system
that meets the requirements of the categories. Temperature and acceleration modules
have been developed to simulate an actual application in the vehicle. The system imple-
ments a CAN network between the modules and a microcontroller processing center. The
system also has supervisory software responsible for receiving the data and displaying it
graphically to the user. The system obtained at the end showed satisfactory performance.
Supervisory software was adapted from an earlier study and, because of this, did not
perform as well as possible.
Key-words: 1.Telemetry 2.CAN Network. 3.Monitoring. 4. Arduino. 5. Motor Sport

Lista de ilustrações
Figura 2.1 – Elementos compositores um barramento CAN. . . . . . . . . . . . . . . 28

Figura 2.2 – Representação dos sinais CANH e CANL no barramento CAN. . . . . 29
Figura 2.3 – Transceptor CAN SN65HVD233 - CAN transceiver, em encapsula-
mento 8-SOIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 2.4 – Formatos de dados possíveis em um protocolo CAN. . . . . . . . . . . 31
Figura 2.5 – Formatos remotos possíveis em um protocolo CAN. . . . . . . . . . . . 32
Figura 2.6 – Formatos de erro possíveis em um protocolo CAN. . . . . . . . . . . . 33
Figura 2.7 – Formato de sobrecarga para o protocolo CAN. . . . . . . . . . . . . . . 33
Figura 2.8 – Processo de bit stuffing realizado pela rede CAN para reforçar a sin-
cronização dos dispositivos. . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 2.9 – Controlador CAN MCP2515, em encapsulamento 28-SOIC. . . . . . . . 34
Figura 2.10–Placa Arduino UNO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 2.11–Ambiente de desenvolvimento das placas Arduino. . . . . . . . . . . . . 37
Figura 3.1 – Esquemático do Sensor MLX90614. . . . . . . . . . . . . . . . . . . . . 42
Figura 3.2 – Sensor MLX90614. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 3.3 – Representação Esquemática da Arquitetura do Sistema. . . . . . . . . . 44
Figura 3.4 – Montagem teste para módulo de temperatura. . . . . . . . . . . . . . . 45
Figura 3.5 – Shield do sensor MLX90614. . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 3.6 – Representação Esquemática para o Módulo de Temperatura. . . . . . . 46
Figura 3.7 – Montagem teste para módulo acelerômetro. . . . . . . . . . . . . . . . 47
Figura 3.8 – Shield do acelerômetro MPU-6050. . . . . . . . . . . . . . . . . . . . . 47
Figura 3.9 – Orientação do acelerômetro MPU-6050. . . . . . . . . . . . . . . . . . . 48
Figura 3.10–Representação Esquemática para o Módulo Acelerômetro. . . . . . . . 48
Figura 3.11–Montagem para teste do sistema completo. . . . . . . . . . . . . . . . . 49
Figura 3.12–Esquema para módulo de processamento e transmissão e do módulo de
recepção e integração com sitema supervisório, respectivamente. . . . . 49
Figura 3.13–Interface gráfica do software Docklight. . . . . . . . . . . . . . . . . . . 50
Figura 3.14–Fluxograma de testes iniciais do sensor de temperatura. . . . . . . . . 51
Figura 3.15–Fluxograma de funcionamento do Módulo de Temperatura. . . . . . . . 52
Figura 3.16–Fluxograma da interrupção do sistema no módulo de temperatura. . . 52
Figura 3.17–Fluxograma de testes inicias do acelerômetro. . . . . . . . . . . . . . . 53
Figura 3.18–Fluxograma de funcionamento do módulo acelerômetro. . . . . . . . . . 53
Figura 3.19–Fluxograma da interrupção do sistema no módulo acelerômetro. . . . . 54
Figura 3.20–Fluxograma de funcionamento do módulo central de processamento e
transmissão de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 3.21–Fluxograma de funcionamento do módulo central de processamento e
transmissão de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 3.22–Fluxograma de funcionamento do módulo de recepção e integração com
sistema supervisório. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 4.1 – Protótipo finalizado para os módulos de temperatura. . . . . . . . . . . 59
Figura 4.2 – Visualização Tridimensional do Protótipo finalizado para os módulos
de temperatura, em ambiente de desenvolvimento. . . . . . . . . . . . . 60
Figura 4.3 – Dados enviados pelo sensor de temperatura. . . . . . . . . . . . . . . . 60
Figura 4.4 – Protótipo finalizado para o módulo acelerômetro. . . . . . . . . . . . . 61
Figura 4.5 – Visualização tridimensional do Protótipo finalizado para o módulo ace-
lerômetro, em ambiente de desenvolvimento.. . . . . . . . . . . . . . . . 61
Figura 4.6 – Dados enviados pelo acelerômetro. . . . . . . . . . . . . . . . . . . . . 62
Figura 4.7 – Protótipo finalizado para o Módulo Receptor . . . . . . . . . . . . . . 63
Figura 4.8 – Protótipo finalizado para o Módulo Transmissor . . . . . . . . . . . . . 63
Figura 4.9 – Visualização tridimensional do Módulo Receptor, em ambiente de de-
senvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 4.10–Visualização tridimensional do Módulo Transmissor, em ambiente de
desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 4.11–Dados de telemetria visto no sistema supervisório provenientes do ace-
lerômetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 4.12–Dados de telemetria visto no sistema supervisório para temperatura
ambiente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 4.13–Dados de telemetria visto no sistema supervisório para temperatura de
um objeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Lista de tabelas
Tabela 1 – Custo de Fabricação do Protótipo . . . . . . . . . . . . . . . . . . . . . 67

Tabela 2 – Custo, através de importação dos componentes, de Fabricação do Pro-
tótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Lista de Siglas e Abreviaturas
ASCII American Standard Code for Information Interchange

CAN Controller Network Area
CD-CR Collision Detection with Collition Resolution
CSMA Carrier Sense Multiple Access
DIP Dual In-line Package
GP Grand Prix
GPS Global Positioning System
GSM Global System for Mobile Communications
I2C Inter-Integrated Circuit
ISO International Organization for Standardization
PCI Placa de Circuito Impresso
SOIC Small Outline Integrated Circuit
SPI Serial Peripheral Interface
Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2 Objetivos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . 21
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 23
2.1 Esportes à motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1 Sensoriamento nos esportes à motor . . . . . . . . . . . . . . . . 23
2.2 Telemetria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1 Telemetria nos Esportes à motor . . . . . . . . . . . . . . . . . . 25
2.3 Sistemas Supervisórios . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Eletrônica Automotiva . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.1 Rede CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.1.1 Barramento CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.1.2 Protocolo CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.1.3 Controladores CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.1 Plataforma Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.6 Prototipagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6.1 Placas de Circuito Impresso - PCI . . . . . . . . . . . . . . . . . 38
2.7 Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . 38
3 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . 41
3.1 Proposta para um Protótipo de Sistema de Telemetria . . . . 41
3.2 Arquitetura de Funcionamento do Sistema . . . . . . . . . . . . 43
3.3 Arquitetura do Hardware . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.1 Módulo CAN - Temperatura . . . . . . . . . . . . . . . . . . . . . 44
3.3.2 Módulo CAN - Acelerômetro . . . . . . . . . . . . . . . . . . . . 46
3.3.3 Módulo Central de Processamento e Transmissão e Módulo
de Recepção e Integração com Sistema Supervisório . . . . . . 47
3.4 Arquitetura do Firmware . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.1 Desenvolvimento do firmware de testes para o Módulo de
Temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.2 Desenvolvimnto do firmware de testes para o Módulo Ace-
lerômetro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.3 Processamento e Transmissão de Dados pelo Módulo Central 54
3.4.4 Recepção dos Dados e Integração com Sistema Supervisório . 54
3.5 Sistema Supervisório . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1 Módulo CAN - Temperatura . . . . . . . . . . . . . . . . . . . . . 59
4.2 Módulo CAN - Acelerômetro . . . . . . . . . . . . . . . . . . . . 61
4.3 Módulos de Transmissão e Recepção . . . . . . . . . . . . . . . . 62
4.4 Sistema Supervisório . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5 Custo de Confecção do Protótipo . . . . . . . . . . . . . . . . . . 65
5 DISCUSSÕES E CONCLUSÕES . . . . . . . . . . . . . . . . . 69
5.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6 APÊNDICE A - ESQUEMÁTICO - MÓDULO DE TEMPE-

RATURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7 APÊNDICE B - ESQUEMÁTICO PARA O ACELERÔMETRO 75
8 APÊNDICE C - ESQUEMÁTICO PARA O MÓDULO TRANS-

MISSOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9 APÊNDICE D - ESQUEMÁTICO PARA O MÓDULO RE-

CEPTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
10 ANEXO A - AMOSTRA DO DATASHEET DO ATMEGA328/P 81
11 ANEXO B - AMOSTRA DO DATASHEET DO MPU-6050 . 83
12 ANEXO C - AMOSTRA DO DATASHEET DO HC-12 . . . 85
13 ANEXO D - AMOSTRA DO DATASHEET DO MCP2515 . 87
14 ANEXO E - AMOSTRA DO DATASHEET DO MLX-90614 89

19
1 Introdução
A história da humanidade tem grande parte dedicada ao desenvolvimento de formas

mais eficientes de comunicação. As primeiras formas de comunicação humana tiveram
origem junto ao surgimento da escrita, cerca de 3000 anos a.C. Podendo usar como meio
de transporte um serviçal de confiança e dados registrados em um pedaço de pergaminho,
informações foram trocadas entre grandes impérios possibilitando avanços em áreas dis-
tintas, indo desde a agricultura praticada por essas civilizações, até a informações bélicas
sobre o movimento de um exercito inimigo em um campo de batalhas. (Geraldo Magela
Machado, 2010)
Na década de 1870 e subsequentes, com a já consolidada revolução industrial, surgem
as primeira transmissão de dados utilizando-se de meios elétricos, com a invenção do
telefone e do rádio. A partir deste momento, a forma como o ser humano compreendia
o envio de uma determinada informação foi drasticamente alterada. Não se necessitava
mais de um "meio físico"para que se transmitisse uma informação. Um estudioso de
metereologia que ao observar uma mudança climática julgasse necessário transmitir essa
informação poderia, em poucos minutos, avisar a uma cidade inteira para que tomasse
as devidas precauções relacionadas a sua observação.(Thais Pacievitch, 2009) (Rainer
Gonçalves, 2010)
Já na década de 1990 o mundo sofre, novamente, uma revolução nas formas de comu-
nicação. Com a popularização da Internet, criada algumas décadas antes, a recepção e
o envio de dados tornou-se algo ainda mais popular. Um computador conectado a esta
rede poderia compartilhar qualquer tipo de dado à distancias muito grandes em uma
quantidade de tempo inimaginável até o momento. Novamente, o conceito de comunica-
ção a longas distâncias é bruscamente alterado, tornando ideias antes inviáveis bastante
próximas da realidade. (Daniela Diana, 2013)
Junto a toda esta evolução relacionada as formas de comunicação utilizada pela soci-
edade humana, surge um conceito bastante simples intimamente ligado a comunicação de
longa distância, a Telemetria.
A origem da palavra telemetria explica muito sobre este conceito - do grego tele, cujo
significado é remoto e metron cujo significado é medida.
Com o avanço das tecnologias ligadas a dispositivos eletrônicos capazes de realizar
medidas, e também dos sistemas de comunicação, a telemetria vem sendo aplicada em
diferentes áreas das atividades humanas com o objetivo de ter-se um status sobre o fun-
cionamento de um determinado equipamento. Este equipamento pode vir a ser desde um
marca-passos implantado no coração de um determinado paciente,até a um medidor de
temperatura implantado em uma determinada plantação.
Sistemas de telemetria também possibilitaram estudos relacionados a ambientes ex-
20 Capítulo 1. Introdução
tremamente inóspitos, como medidas de temperatura em vulcões, medidas de pressão

em ambientes marinhos extremamente fundos, observação do comportamento de algumas
espécies de plantas em ambientes fora do planeta Terra, dentre outros.
Um outro fator que vem tornando cada dia mais popular o uso da telemetria é a
baixa no valor do custo dos dispositivos relacionados a estes sistemas. Um exemplo desta
popularização é a utilização da telemetria em meios que anteriormente não detinham do
investimento necessário para estudos mais precisos, como o esporte. Atualmente é comum
encontrar um jogador de futebol utilizando um sistema de GPS preso ao seu corpo com o
objetivo de medir a distância percorrida por ele, ou mesmo traçar um mapa da parte do
campo que ele mais ocupa durante o jogo.
Hoje o mundo passa por uma nova revolução na forma de comunicação, popularmente
conhecida como Internet das Coisas. Está revolução tem seus conceitos baseados em siste-
mas de telemetria, onde todo e qualquer dispositivo conectado a Internet tem capacidade
de fornecer dados a um sistema superior que gerencia os mais diversos parâmetros, con-
tribuindo para a simplificação e, consequente, avanço das atividades humanas. (Marcia
Garcia, 2018)
1.1 Motivação
Com o custo de sensores e sistemas transmissores de dados tornando-se acessíveis
à aplicações com menores investimento, a utilização de sistemas de telemetria tem se
tornado cada dia mais presente. Em esportes à motor a utilização desta tecnologia já
é, a muito tempo, uma realidade em categorias de alta performace. Já nas categorias
inferiores, cujo objetivo principal é o hobby e não a competição, estes sistemas ainda são
pouco utilizados. Um dos motivos da baixa aderência está ligado ao fato de que sistemas
dessa natureza normalmente são projetados para a obtenção de uma série de parâmetros
com elevada precisão. Isto acaba por tornar o custo benefício da utilização de um sistema
de telemetria em categorias de menor investimento um pouco alto para os competidores.
1.2 Objetivos Gerais

O objetivo deste trabalho é a elaboração de um protótipo de sistema de telemetria com
alguns dos elementos básicos presentes em sistemas desta natureza. É um dos objetivos
também que esse estudo possa ser utilizado para apresentação a possíveis investidores,
podendo estes interessar-se pela implementação do sistema fora do ambiente de prototi-
pagem.
1.3. Objetivos Específicos 21
1.3 Objetivos Específicos

• Desenvolvimento de um módulo de temperatura com comunicação CAN.
• Desenvolvimento de um módulo acelerômetro com comunicação CAN.
• Desenvolvimento de um módulo central de processamento e transmissão de dados.
• Desenvolvimento de um módulo receptor de dados.
• Desenvolvimento de um sistema supervisório.
1.4 Organização do Trabalho

O trabalho de conclusão de curso que aqui se apresentará está organizado como descrito
à seguir:
• Fundamentação Teórica: São apresentados todos os conceitos relacionados ao tra-

balho, os sensores e softwares utilizados durante o desenvolvimento do mesmo.
• Desenvolvimento: Apresenta a construção do projeto dividida em etapas, expondo

os testes realizando de maneira isolada antes do sistema ser posto em funcionamento
de maneira geral.
• Resultados: Apresenta os resultados obtidos. São apresentados todos os dispositivos

confeccionados e o sistema prototipado em funcionamento de maneira completa.
• Discussões e Conclusões: Apresenta discussões sobre o desempenho do sistema,

custo relacionados ao trabalho e melhorias para trabalhos futuros.
• Apêndices e Anexos: São apresentados os códigos desenvolvidos durante o trabalho

e os principais datasheets dos componentes utilizados.
23
2 Fundamentação Teórica
2.1 Esportes à motor

O espírito humano de competição se faz presente na sociedade desde a Grécia antiga,
onde os homens que compunham aquela sociedade já se desafiavam em competições de
viés físico, como arremessos de peso, disco, dentre outras. Com o automobilismo não
foi nada diferente. Pouco tempo após a invenção do automóvel foi realizada a primeira
competição oficial que colocava a prova os veículos produzidos até então. Não tratava-se
de uma corrida mas sim de testes de desempenho relacionados a segurança, durabilidade
e também ao valor final de custo daqueles automóveis. A competição foi organizada por
Pierre Giffard, jornalista do "Le Petit Journal" e contou com a inscrição de 102 equipes,
chegando a etapa final apenas 21 delas.(Le Petit Journal, 1894)
Posterior a este marco, basicamente qualquer atividade relacionada a mobilidade que
tem como fonte motriz um motor, podendo ele ser a combustão ou elétrico, passou a ter
uma competição relacionada a ela. Passando por competições de resistência à competições
de desempenho, os esportes à motor tem se desenvolvido e ocupado um papel bastante
importante na sociedade atual. Praticamente toda a inovação tecnológica já conquistada
até os dias de hoje presentes em veículos tem sua origem em alguma competição esportiva.
Na atualidade, a categoria máxima do automobilismo, a Formula 1, tem contribuído
de maneira significante para o desenvolvimento do automobilismo mundial. Os projetos e
desenvolvimentos relacionados a otimização de potência, otimização de consumo, controle
de tração e estabilidade, menor carga de poluentes lançados na atmosfera, dentre outros,
presentes em veículos de rua tem suas bases em projetos desta categoria. (Felipe Garret,
2012)
Outra categoria que contribui, de maneira bastante significativa, a veículos presentes
em nosso dia-a-dia é o MotoGP, categoria máxima do motociclismo. Soluções como o
controle de tração em saídas de curva e o controle de frenagem, presentes em modelos de
rua são soluções de segurança vindas desta categoria. (Roberto Agresti, 2014)
2.1.1 Sensoriamento nos esportes à motor

Competições esportivas de alta performace, de maneira geral, tem seus resultados
definidos por detalhes. Sendo assim, faz-se de extrema importância a coleta de dados
relacionados aos parâmetros que venham a implicar em um maior ou menor desempenho
por parte do competidor.
Nos esportes à motor estes parâmetros estão ligados a basicamente dois fatores: o
equipamento utilizado - automóvel, motocicleta, dentro outros - e ao comportamento do
24 Capítulo 2. Fundamentação Teórica
piloto às adversidades que ele irá defrontar durante uma competição.

A engenharia, fazendo-se uso da eletrônica e áreas afins, permite a realização de me-
didas, através de sensores, dos parâmetros que venham a influenciar no desempenho de
veículo e do piloto. Em esportes à motor de pista, como o automobilismo, praticamente
todos os parâmetros são medidos por uma infinidade de sensores presentes no veículo.
Trazendo novamente como exemplo a Formula 1, sensores pressão do óleo, temperatura
dos pneus, temperatura dos freios, velocidade, aceleração que o veiculo esta sendo sub-
metido, pressão aerodinâmica em vários pontos do veículo, dentre vários outros fatores,
são monitorados em tempo real por uma equipe de engenharia responsável por esses pa-
râmetros. O piloto, em muitas das vezes, torna-se um executor das ordens vindas desta
equipe de engenheiros que, baseados na interpretação dos dados vindos dos sensores, pode
instruir o piloto a controlar melhor a potência desenvolvida pelo carro, o gasto de pneus
e até a durabilidade de um motor ou cambio, dentre outros aspectos.
2.2 Telemetria
Como citado previamente no capítulo introdutório deste trabalho, a Telemetria ocupa
um papel de grande importância na atual prática da engenharia moderna. Grande parte
dos equipamentos projetados nos dias atuais apresentam a necessidade, ou deseja-se, de
uma operação de maneira remota. (POLESE, 2017)
Um sistema de telemetria é formado, em linhas gerais, por:
• Hardware embarcado local: este sistema é responsável pela obtenção dos dados no
local em que objetiva a obtenção dos parâmetros de um dados sistema. Toda a parte
de sensores e processamento de dados é implementada neste hardware. Um aspecto
importante deste tipo de hardware está ligado a robustez de sua construção. Em
grande parte das situações em que se utiliza um sistema de telemetria, os dispositi-
vos envolvidos sofrem um desgaste considerável com ações temporais, tornando-se
necessário uma construção mecânica capaz de manter a integridade destes circuitos
e prolongar o seu funcionamento.
• Sistema de transmissão de dados: este sistema é responsável pelo envio dos dados
obtidos no local onde o hardware foi instalado para o usuário que irá realizar o
monitoramento. Devido ao fato de que sistemas de telemetria são utilizados em
situações onde a distância envolvida é relativamente grande, a forma de transmis-
são de dados mais popular para este tipo de sistema é a transmissão GSM (Global
System for Mobile Communications). Atualmente, outras tecnologias estão sendo
implementadas nos sistemas de telemetria, como por exemplo a comunicação LoRa.
Existem também sistemas de telemetria implementados de maneira cabeada, como
2.2. Telemetria 25
por exemplo sistemas implementados em usinas hidroelétricas e alguns meios indus-

triais.(WEBSTER, 1999)
• Software para supervisão: este sistema é responsável pela interação entre o usuário
que irá realizar o monitoramento e o sistema monitorado em si.
Como citado anteriormente, um exemplo de ambiente onde se encontra sistemas de

Telemetria cabeados é o ambiente industrial. Na industria, a Telemetria tem sido apli-
cada no monitoramento e na realização de ações relacionadas a parâmetros lidos de uma
determinada máquina. Em uma usina hidroelétrica, por exemplo, um operador pode mo-
nitorar a vazão de água que passa pela barragem e, caso necessário, abrir uma comporta
para que aumente-se essa vazão. Ambas as ações - de monitoramento e de uma possível
abertura de comporta - podem ser tomadas a muitos metros de distância de onde elas de
fato irão acontecer. (WEBSTER, 1999)
Já um exemplo de sistema de telemetria sem fio são os sistemas utilizados em meios
agrícolas. Este tipo de utilização da telemetria tem crescido muito nos últimos anos, con-
sequente da modernização e desenvolvimento desta área. Sendo utilizada para o monito-
ramento de parâmetros como molhamento foliar, temperatura ambiente, dentre outros, a
telemetria exerce um papel importante na prática preventiva do controle de pragas, assim
como na prevenção de doenças causadas por fatores ambientes. (BARBOSA, 2014)
2.2.1 Telemetria nos Esportes à motor

Assim como nas áreas já citadas, nos esportes à motor a telemetria tem como objetivo
a observação de parâmetros de funcionamento do veículo competidor assim como aspectos
de desempenho do piloto.
Sistemas de telemetria utilizados nessa modalidade esportiva basicamente seguem duas
arquiteturas características: uma arquitetura de dispositivos centralizada e um arquite-
tura de dispositivos descentralizada.(DANTAS, 2012)
A arquitetura centralizada apresenta uma central de processamento responsável por
receber, processar e realizar todas as ações do sistema. Este tipo de arquitetura é indicado
para ambientes que não possuam muito ruído, e que os sensores não se encontrem a
distâncias muito longas da central.(NUNES, 2016)
Já a arquitetura descentralizada pode apresentar varias centrais de processamento
dentro de um mesmo sistema, sendo este sistema o mais utilizado atualmente no automo-
bilismo. A preferência por está arquitetura se dá pela possibilidade de uma implementação
de sistema mais robusta no que tange a comunicação entre os módulos do sistema, visto
que ambientes automotivos comumente são expostos a muitas fontes de ruído.(NUNES,
2016)
2.3 Sistemas Supervisórios

Sistemas supervisórios são sistemas integrados a sistemas de monitoramento que tem
como objetivo a realização de uma interação entre o operador e o sistema em si - conhecida
como interação homem-máquina. A utilização de sistemas supervisórios nasceu junto ao
conceito de telemetria, uma vez que na origem dos sistemas de telemetria os dados ainda
eram recebidos de maneira pura, sem nenhum tratamento gráfico.(BONIFACIO, 2018)
Atualmente os sistemas supervisórios já contam com toda a técnologia que a infor-
mática proporciona. Os dados puros, ao serem recebidos pelo sistema, são tratados e
geram-se gráficos, blocos de ativação e desativação, dentre outras formas de interação.
Existem varias vantagens na utilização de sistemas supervisórios, destacando-se três
delas:
• Operação remota do sistema: Os sistemas supervisórios possibilitam uma tomada

de decisão por parte do operador que esteja observando os parâmetros do sistemas,
mesmo que a longas distâncias.
• Análise de tendências: Através do recebimento de um pacote de dados, pode-se

analisar o comportamento de um determinado parâmetro e prever qual será o seu
estado momentos posteriores ao analisado.
• Administração de alertas do sistema: O operador pode ter a visualização de alertas

do sistema de maneira simples, tomando a melhor ação relacionada ao determinado
alerta.
2.4 Eletrônica Automotiva

Durante muito tempo, a eletrônica presente em automóveis e motocicletas foi com-
posta por uma pequena variedade de componentes básicos, como relés, fusíveis, dentre
outros. Com o salto técnologico ocorrido na década de 90, que ainda impulsiona um
forte ritmo de desenvolvimento na atualidade, a eletrônica automotiva passou a contar
com um grande número de dispositivos e sensores, dando origem a inumeras funcionali-
dades.(GUIMARAES, 2007)
A grande maioria dos modelos de automóveis populares atuais apresentam algumas
funções totalmente conectadas ao funcionamento de dispositivos eletrônicos. Um exemplo
desses dispositivos é a injeção eletrônica, presente em todos os modelos atuais de veículos,
desde o mais simples ao mais luxuoso. Com o advento da injeção eletrônica houve um salto
gigantesco em desempenho dos veículos no que diz respeito ao consumo.(GUIMARAES,
2007)
Já nos modelos mais luxuosos, a eletrônica automotiva se mostra presente de uma
maneira bem mais forte. Sensores de acendimento automático dos faróis, acionamento
2.4. Eletrônica Automotiva 27
automático dos limpadores de para-brisa, controles de tração e estabilidade, climatizadores

digitais, direção elétrica, dentre uma grande variedade de outros dispositivos, são itens
facilmente encontrados nesses modelos.
Tendo em vista esta imensa quantidade de sensores e dispositivos em um automóvel,
um outro fator que também apresentou um grande salto no que tange este tema é a
quantidade de dados gerados por um automóvel. Os modelos atuais tem embarcados
em sua eletrônica microcontroladores e microprocessadores para que sejam capazes de
administrar toda a quantidade de dados gerados por seus sensores. Um outro fator de
bastante importância é a segurança com que essa grande quantidade de dados trafega
até a unidade de processamento central do automóvel. Sensores como, por exemplo,
o acelerador necessitam de uma proteção contra falhas bastante robusta visto o risco
envolvido ao não funcionamento deste dispositivo. Devido a este fato, as montadores de
veículos utilizam-se de topologias de rede que possuem proteção contra possíveis erros de
transmissão de dados do barramento interno do veículo, como por exemplo a topologia
de rede CAN.(GUIMARAES, 2007)
2.4.1 Rede CAN

Em meados da década de 80, Robert Bosch desenvolveu um rede de comunicação
multimestre denominada CAN - Controller Area Network. A rede CAN, a partir de
então, foi utilizada nas redes de comunicação de veículos de frota pesada, como ônibus e
caminhões, mas rapidamente passou a ser adotada em varios meios de comunicação em
rede sujeitos a uma grande quantidade de ruídos.(Guimarães, A. A., 2004a)
Redes CAN utilizam-se de um método de transmissão denominado CSMA/CD-CR -
Carrier Sense Multiple Access and Collision Detection with Collition Resolution. De ma-
neira geral, este método implementa uma transmissão com os seguintes aspectos:(Microchop,
2012)
• Todos os dispositivos presentes na rede monitoram constantemente a mesma quando

não estão a transmitir uma mensagem;
• Durante um período de estado ocioso do barramento, qualquer dispositivo tem as

mesmas possibilidades de publicar uma mensagem no barramento;
• Caso dois dispositivos da rede iniciem uma transmissão ao mesmo tempo existirá
uma colisão das informações;
• Caso exista uma colisão das informações a rede tem capacidade para elencar uma
prioridade entre as mensagens, retransmitindo a mensagem de menor prioridade em
um próximo intervalo de tempo disponível.
A rede CAN pode ser compreendida dividindo-se-a em duas camadas: a camada física,
podendo também ser denominada de barramento CAN, e a camada de dados, podendo
também ser denominada de protocolo CAN.
2.4.1.1 Barramento CAN
O barramento CAN, como em alguns outros barramentos, necessita de parâmetros

bastante definidos para que o protocolo possa trafegar de maneira adequada. Esses parâ-
metros são especificados, de maneira geral, por duas normas: a ISO11898, que especifica
as características de uma rede trabalhando em alta velocidade (sendo alta velocidade uma
taxa de transmissão entre 125 Kbps a 1 Mbps), e a ISO11519, que especifica as caracte-
rísticas de uma rede trabalhando em baixa velocidade (sendo baixa velocidade uma taxa
de transmissão entre 10 Kbps e 125 Kbps). Atualmente a utilização do barramento CAN
seguindo as características apresentadas pela ISO11519 são pouco utilizadas, visto que
com o avanço das tecnologias no processamento de dados, utilizar-se de um barramento
com velocidade mais baixa não se faz necessário.(Texas Instruments, 2002)
Outra característica importante do barramento CAN é o meio pelo o qual os dados se
propagam e a impedância característica do barramento. O barramento CAN é composto
por um par de fios trançados, sendo um desses fios denominados CAN High (CANH )
e o outro CAN Low (CANL). Estes devem apresentam uma impedância bastante defi-
nida de 60 Ω, especificada pela ISO11898-2. Para obter-se essa impedância característica
utilizam-se resistores de terminação no barramento, como os apresentados na Figura 2.1,
representados por RL . Utilizando-se de resistores de 120 Ω como resistores de terminação,
pode-se obter a impedância de linha correta para o perfeito tráfego de dados do protocolo.
(Texas Instruments, 2002)
Figura 2.1 – Elementos compositores um barramento CAN.
Fonte: Introduction to the Controller Area Network (CAN) - Texas Instruments.
Uma terceira característica bastante específica do barramento CAN, sendo esta a que
o mais destaca em quesitos de robustez física do barramento, é o nível de sinal elétrico em
que os dados trafegam dentro do barramento. Em outros tipos de comunicação normal-

mente implementa-se o nível lógico alto como sendo o limite superior de tensão utilizado
pelo sistema e o nível lógico baixo como sendo o limite inferior. Já o barramento CAN
utiliza níveis de sinal bastante característicos. A primeira diferença aparece no que tange
aos tipos de nível lógico. O barramento CAN não se utiliza de níveis lógicos alto ou baixo
e sim níveis lógicos recessivos e dominantes. Este tipo de codificação de sinal não se baseia
no nível de tensão apresentado por uma linha de dados e sim pela diferença de de tensão
entre duas linhas de dados. Um exemplo de como a informação trafega no barramento
CAN é mostrado na Figura 2.2. Sendo desta forma, tendo em vista um fio de par tran-
çados, quando uma determinado ponto da linha sofre uma interferência, ambos os sinais
se deslocarão em mesmo valor de tensão, mantendo-se assim a diferença de tensão entre
eles e, consequentemente, preservando a informação. Um segundo ponto de destaque é o
valor em tensão desse sinal. Um nível lógico dominante é conseguido com uma diferença
de tensão de aproximadamente 2V entre o sinal presente no fio CANH e o sinal presente
no CANL. Em condições normais, o sinal presente em CANH é de 3,5V e em CANL de
1,5V. Já um sinal recessivo deve apresentar uma diferença de tensão menor do que 0,6V
e em condições normais ambos os sinais CANH e CANL apresentam tensão proxima a
2,5V. (Texas Instruments, 2002)
Figura 2.2 – Representação dos sinais CANH e CANL no barramento CAN.
Fonte: Overview of 3.3V CAN (Controller Area Network) Transceivers - Texas

Instruments, 2013.
Para a adaptação de sinais de nível de tensão comuns para os níveis de sinais CAN
faz-se uso de um dispositivo denominado transceptor CAN - CAN transceiver. Este dis-
positivo tem a função de receber o sinal de uma linha comum, com níveis lógicos alto e
baixo, e "traduzi-lo"para o nível lógico de funcionamento da rede CAN. Os grandes fabri-
cantes de componentes eletrônicos disponibilizam varias versões desse dispositivo, como
por exemplo o apresentado na Figura 2.3, do fabricante Texas Instruments. Outra vanta-
gem na utilização do trasnceptor CAN é a descodificação do sinal do barramento. Após

a decodificação, o nível lógico dominante é tratado como valor lógico 0 e o nível lógico
recessivo é tratado como valor lógico 1, fazendo com que os níveis de tensão diferentes do
convencional existam apenas durante a transmissão da informação dentro do barramento.
(Texas Instruments, 2008)
Figura 2.3 – Transceptor CAN SN65HVD233 - CAN transceiver, em encapsulamento 8-

SOIC.
Fonte: Internet - Disponível em: http://www.ti.com/product/SN65HVD233.
2.4.1.2 Protocolo CAN
O protocolo CAN, camada de dados da rede CAN, apresenta quatro tipos de formatos
para o envio de uma determinada informação: o formato de dados (data frame), o for-
mato remoto (remote frame), o formato de erro (error frame) e o formato de sobrecarga
(overload frame). A seguir segue-se a descrição de cada um destes formatos.(Microchop,
2012)
• Data Frame: Este é o formato utilizado no protocolo CAN para a transmissão de

uma informação comum. Existem dois formatos para este frame: o formato padrão
e o estendido. A diferença entre estes dois formatos está no campo da arbitrariedade
da mensagem. No formato padrão existem 11 bits dedicados a este campo, já no
formato estendido existem 29 bits. Um esquema para este formato é apresentado
na Figura 2.4.
O campo da arbitrariedade também pode ser entendido como o identificador de
uma determinada mensagem no barramento CAN. Outro fator bastante importante
do campo da arbitrariedade é a capacidade da rede CAN, a partir deste campo,
de criar uma prioridade entre as mensagens enviadas pelo barramento. Supondo-se
que duas mensagens diferentes sejam transmitidas ao mesmo tempo, a mensagem
que apresentar um menor valor binário no campo da arbitrariedade, sendo o valor 0
representante de um nível lógico dominante, terá uma maior prioridade de transmis-
são. Está também é uma das grandes contribuições da rede CAN para as aplicações
em que é empregada, visto que dessa forma a administração de prioridades de uma
Figura 2.4 – Formatos de dados possíveis em um protocolo CAN.
Fonte: Introduction to Controller Area Network (CAN) - Microchip Webseminars,

2012.
transmissão é tratada em nível físico e não no nível de dados, como nos diversos
outros tipos de rede.
Com a utilização do formato padrão são possíveis 2048 mensagens únicas, pois
o barramento CAN não permite a utilização de um mesmo valor no campo da
arbitrariedade para diferentes mensagens. Já com o modo estendido é possível um
valor superior a 536 milhões de mensagens únicas.
• Remote Frame: Este formato é bastante semelhante ao formato de dados, porém

com a diferença de que para este não existe o campo de dados. O formato re-
moto é utilizado para quando um determinado dispositivo do barramento requisita
dados de um outro dispositivo do barramento. A Figura 2.5 ilustra a construção
deste formato. Nota-se que este também possui dois tipos: o padrão e o estendido,
aplicando-se dessa forma as mesmas características citadas no formato de dados.
• Error Frame: Existem dois possíveis tipos de erro para este formato, sendo eles o
formato de erro ativo e o formato de erro passivo. A diferença entre eles esta na
geração e na detecção do erro por parte de outros dispositivos no barramento. A
Figura 2.6 ilustra a construção deste formato.
• Overload Frame: Este formato é utilizado para que um determinado dispositivo

presente na rede faça uma solicitação de mais tempo de processamento aos outros
dispositivos. Desta forma o restante dos dispositivos da rede inserem um delay em
Figura 2.5 – Formatos remotos possíveis em um protocolo CAN.

2012.
suas transmissões, aguardando que o dispositivo que tenha enviado o formato de

sobrecarga termine de enviar os seus dados. A Figura 2.7 ilustra este formato.
Como já citado anteriormente, a rede CAN tem sua popularidade atribuida, também,
a sua capacidade de deteção e solução de erros. Na camada de dados um desses métodos
está relacionado aos problemas gerados pela sincronização da transmissão. Como pode-se
notar até este momento, o barramento CAN não apresenta uma linha de sinal dedicada
a sincronização do envio das mensagens, forçando-se assim que todos os dispositivos da
rede apresentem uma mesma configuração de clock. Porém isto não é suficiente para uma
comunicação precisa, visto que mesmo operando em mesma frequência, garantir que todos
os dispositivos de uma rede CAN operem em fase seria uma atividade bastante complexa.
Para isso o protocolo CAN utiliza-se de um método de sincronização denominado bit
stuffing, ilustrado na Figura 2.8.(Microchop, 2012)
O bit stuffing trata-se de um artifício para se forçar uma borda em uma dada trans-
missão, com o objetivo de que os dispositivos possam sincronizar-se a partir desta. No
protocolo CAN a cada 5 bits de mesmo valor transmitido o sexto é, obrigatoriamente, de
valor oposto. Isso força o sistema a identificar uma borda a cada 5 bits transmitidos de
mesmo valor, fato este que, caso não ocoresse, poderia causar uma dessincronização entre
os dispositivos do barramento visto a ausência de um sinal de clock. Este bit não tem valor
lógico para o sistema e é descartado no momento do processamento dos dados.(Microchop,
2012)
Figura 2.6 – Formatos de erro possíveis em um protocolo CAN.

2012.
Figura 2.7 – Formato de sobrecarga para o protocolo CAN.

2012.
2.4.1.3 Controladores CAN
As redes CAN apresentam muitos parâmetros de controle e manipulação dos dados

transmitidos. As seções 2.4.1.1 e 2.4.1.2 apresentam boa parte destes parâmetros, dei-
xando evidente a complexidade da implementação deste tipo de rede. Tendo em vista
este problema e a crescente procura pela implementação das redes CAN nos dias atuais,
Figura 2.8 – Processo de bit stuffing realizado pela rede CAN para reforçar a sincronização
dos dispositivos.
Fonte: Introduction to Controller Area Network (CAN) - Microchip Webseminars.
os maiores fabricantes de componentes eletrônicos da atualidade produzem controladores

CAN. Estes controladores implementam todo o protocolo CAN, e aliados aos transcepto-
res CAN, solucionam toda a complexidade deste tipo de rede.(Guimarães, A. A., 2004b)
A utilização destes controladores torna-se ainda mais simples visto que boa parte deles
adota protocolos de comunicação bastante difundidos como meio de interface entre estes e
os microcontroladores, como por exemplo o protocolo SPI. Desta forma, de maneira geral,
o usuário de um controlador CAN necessita apenas enviar a informação a qual ele quer
transmitir e alguns dados de configuração para o controlador CAN e ele irá administrar
toda a montagem e transmissão do protocolo, com todas os requisitos necessários.
Um exemplo deste tipo de controlador é o MCP2515, ilustrado na Figura 2.9, da
empresa Microchip.
Figura 2.9 – Controlador CAN MCP2515, em encapsulamento 28-SOIC.
Fonte: Internet - Disponível em:

https://www.microchip.com/wwwproducts/en/MCP2515.
2.5. Sistemas Embarcados 35
2.5 Sistemas Embarcados

Com o avanço da tecnologia na atualidade, a utilização de sistemas digitais de pro-
cessamento, sensores, atuadores, dentre outros dispositivos eletrônicos, tem crescido e
popularizado-se cada dia mais.
Um sistema embarcado integra todo esse conjunto de tecnologias, utilizando-as para
uma determinada finalidade em um determinado equipamento. Atualmente equipamentos
domésticos, antes bastante simples, como por exemplo uma máquina de lavar roupas, já
contam com todo um sistema embarcado responsável pela automação de várias funções
antes realizadas de maneira manual.
A utilização destes sistemas, em tempos passados, sempre foi dificultada pelo grande
conhecimento de eletrônica e programação que se exigia para a confecção e manipulação
destes. Objetivando suprir essa barreira, ou torna-la menor, os fabricantes de componentes
de sistemas embarcados começaram a produzir plataformas de desenvolvimento, sendo
essas sistemas embarcados ainda não embarcados - sem uma aplicação final definida.
Esta ação tornou mais acessível, financeiramente e intelectualmente, o desenvolvimento
de soluções fazendo-se uso de sistemas embarcados.
Esta postura de mercado dos grandes fabricantes também deu origem a uma grande
tendência mundial, onde projetistas do mundo todo passaram a desenvolver soluções com o
objetivo de diminuir a carga intelectual necessária para utilizar-se de soluções embarcadas
nos mais diversos projetos existentes.
2.5.1 Plataforma Arduino

O projeto Arduino teve seu início no ano de 2005, na cidade de Ivrea - Itália, no
Instituto de Design de Interação. Massimo Banzi, um dos professores do corpo docente do
instituto, objetivava uma proposta de baixo custo, e que não demandasse uma longa carga
horária de estudo, para que os seus alunos pudessem aplicar seus conceitos de design junto
a ferramentas de prototipagem relacionadas a eletrônica e sistemas embarcados. Com a
ajuda de David Guatielles, pesquisador da Universidade de Malmo - Suécia, o projeto
efetivamente teve início. (EVANS, 2013)
Algumas propostas semelhantes já existiam no mercado, porém o diferencial do pro-
jeto Arduino estava em suas características de baixo custo - a ideia inicial era de que a
plataforma não apresentasse valor superior ao de uma refeição - e a facilidade no processo
de utilização do mesmo, visualizando-se que a placa de desenvolvimento junto de um cabo
USB e componentes eletrônicos simples seriam suficientes para a realização dos primeiros
projetos.
Com a integração de outros membros no desenvolvimento do projeto, o Arduino
tornou-se uma das ferramentas de prototipagem mais populares no universo dos siste-
mas embarcados, auxiliando tanto no ensino e na iniciação de estudantes em áreas como
robótica e sistemas embarcados, quanto na rápida prototipagem e na prova de conceitos

por profissionais dessa área.
Junto ao propósito de tornar o ensino e a prototipagem de sistemas eletrônicos embar-
cados mais simples, um outro conceito que as plataformas Arduino tiveram total influência
é o conceito open-source, que também pode ser considerada uma filosofia. Esta filosofia
tem como princípio básico o compartilhamento do conhecimento produzido. Tanto no
desenvolvimento das placas da plataforma Arduino quanto na produção de materiais de
estudos, resultados obtidos, na produção de códigos de exemplo, dentre outros, está fi-
losofia é amplamente aplicada, criando uma comunidade orgânica que tende a crescer e
fortalecer-se cada dia mais.
A placa mais popular produzida é o Arduino Uno, que pode ser vista na Figura 2.10.
Esta placa utiliza como microcontrolador o ATmega328P, da empresa Atmel, atualmente
pertencente a Microchip. Algumas características básicas desta placa estão citadas a
seguir:(Arduino Company, 2018)
• Tensão de operação de 5 V.
• 14 pinos de entrada e saída.
• Suporta corrente de até 20 mA em cada pino de entrada e saída.
• 32 KB de memória Flash
• 2 KB de memória SRAM
• 1 KB de memória EEPROM
• Velocidade de processamento (clock) de 16 MHz.
• 1 interface UART, com nível lógico de comunicação de 5 V (TTL).
Para a programação desta e das demais placas do projeto Arduino, que neste ponto
já pode também ser chamada de empresa, existe um ambiente de desenvolvimento (IDE)
desenvolvido especificamente para esta função. A linguagem utilizada para a programação
é especifica para a plataforma, porém é bastante semelhante as linguagens C e C++. A
Figura 2.11 exibe a janela da IDE Arduino com a estrutura básica para a programação
das placas.
De maneira geral duas estruturas podem ser vistas na Figura 2, sendo elas a função
setup, responsável pelas configurações gerais da placa que será utilizada, e a função loop,
onde será inserido efetivamente o código executado durante o tempo de funcionamento
da placa.
Atualmente existem várias versões das placas Arduino, algumas delas apresentam mi-
croprocessadores com maior capacidade de processamento, maior número de portas de
2.5. Sistemas Embarcados 37
Figura 2.10 – Placa Arduino UNO.
Fonte: Internet - Disponível em: https://www.arduino.cc/
Figura 2.11 – Ambiente de desenvolvimento das placas Arduino.
Fonte: Internet - Disponível em: https://www.arduino.cc/
entrada e saída disponíveis, maior memória de programação, dentre outras funcionalida-

des.
Com a popularização do uso das placas da empresa, algumas dessas deixaram também
de ter como propósito o ensino de programação para alunos iniciantes neste universo e
passaram a comportar cargas de processamento de projetos de extrema complexidade,
passando a exercer um papel importante na prototipagem de projetos complexos.(Adilson
Thomsen, 2014)
2.6 Prototipagem
A prototipagem é um conceito bastante antigo que vem evoluindo desde os primórdios
de sua utilização. Na atualidade existem ferramentas extremamente complexas destinadas
a esta atividade, capazes muitas vezes de simular o comportamento de uma determinada
estrutura ou, no campo da engenharia elétrica, um determinado circuito.
Em linhas gerais, o objetivo da prototipagem é a prova de um conceito que envolva
uma estrutura complexa através de uma estrutura mais simples.
No ramo de atividades da engenharia a utilização da prototipagem é algo de vital
importância no desenvolvimento de um projeto. Protótipos que aproximem-se de proje-
tos reais são capazes de trazer boas previsões do funcionamento deste em sua aplicação
final. Essas previsões poupam tempo para a resolução de possíveis problemas e recursos
financeiros, para o caso de grandes produções.(PALHAIS, 2015)
2.6.1 Placas de Circuito Impresso - PCI

A utilização de placas de circuito impresso (PCI) na prototipagem de sistemas em-
barcados é uma prática que vem ganhando força com o desenvolvimento dos métodos de
fabricação destas. Em tempos anteriores a utilização de protoboards era a forma mais
adequada de realização de alguns testes eletrônicos devido ao alto custo de projeto de
uma PCI.
Com o avanço dos softwares de simulação de circuitos eletrônicos - como o OrCAD,
Proteus, dentre outros - tem-se a capacidade de gerar protótipos de PCIs com maior
confiabilidade do funcionamento do circuito, fazendo-se assim com que a realização de
testes torne-se mais simples e os resultados provenientes do protótipo tenham uma maior
confiabilidade.
2.7 Considerações Finais do Capítulo

A utilização de sistemas de telemetria na atualidade não é mais um avanço e sim uma
tendência tecnológica. Com o barateamento de dispositivos integradores destes sistemas,
a utilização deles tem se tornado cada dia mais popular nas mais diversas atividades
exercidas pela humanidade. Os sistemas de telemetria são formados por diferentes áreas
com um razoável nível de complexidade entre si. Por sua vez, estas diferentes áreas devem
trabalhar de maneira integrada para que se tenha um sistemas que apresente uma boa
confiabilidade. Sistemas de telemetria aplicados aos esportes à motor trazem consigo
ainda os estudos relacionados as características especificas de ambientes desta natureza,
como por exemplo a rede CAN, que se faz necessária devido a grande quantidade de
ruídos presentes nesses ambientes. Desta forma a utilização de um sistema prototipado
2.7. Considerações Finais do Capítulo 39
que possa vir a realizar uma prova de conceito sobre a natureza deste tipo de projeto é a
melhor forma de iniciar um possível desenvolvimento de produto nesta área.
41
3 Desenvolvimento
Este capítulo apresenta todas as etapas de desenvolvimento do trabalho. Estão descritos
os procedimentos utilizados para o desenvolvimento do esquema de funcionamento do
sistema de forma geral, os testes dos dispositivos utilizados, a confecção dos elementos
formadores do sistema e a codificação do firmware de cada um desses.
3.1 Proposta para um Protótipo de Sistema de Tele-

metria
O sistema de telemetria apresentado neste trabalho é um protótipo de sistema que
tem como objetivo a validação dos conceitos envolvidos e a mensuração de funcionalida-
des e custos do sistema como um todo. Os sensores utilizados e toda a arquitetura de
funcionamento do sistema são apresentados nas seções seguintes.
Algumas adaptações a realidade em que o sistema final possa ser aplicado foram re-
alizadas para esta prototipagem. Sistemas automobilísticos normalmente operam com
tensões de 12 V. Já o protótipo aqui apresentado opera com tensões de 9 V, provenientes
de baterias comuns. Outra adaptação realizada esta relacionada a transmissão de dados:
nesta prototipagem usou-se um transmissor de pequeno alcance, aproximadamente 300
metros de alcance em campo aberto sem a utilização de antenas, porém para uma apli-
cação final em que este sistema venha a ser utilizado sabe-se que o transmissor deve ter
capacidade para um alcance de no mínimo 5 Km.
O protótipo proposto é composto pelos componentes listados a seguir:
• Dois sensores de temperatura MLX90614: O MLX90614 é um termômetro infraver-

melho desenvolvido pela empresa Melexis – Microeletronic Integrated Systems. Sua
maior aplicação é o sensoriamento de temperatura sem a necessidade de contato
entre o objeto que deseja-se medir a temperatura e o sensor. Este sensor utiliza o
protocolo de comunicação I2C para comunicar-se com o microcontrolador que irá
receber as medidas de temperatura. Está disponível através de um encapsulamento
TO-39 de quatro pinos. A Figura 3.1 exibe o esquemático elétrico necessário para
o funcionamento do sensor e a Figura 3.2 exibe uma imagem do sensor.
O MLX90614, através de seu encapsulamento TO-39, é constituído por dois sensores

de temperatura. Um deles, ligado a estrutura do encapsulamento, é dedicado a
realização de medidas de temperatura ambiente. Já o segundo utiliza medidas de
radiação infravermelho que entram dentro do sensor através de seu visor para a
determinação da temperatura de um objeto – ou um conjunto deles. O valor de
42 Capítulo 3. Desenvolvimento
Figura 3.1 – Esquemático do Sensor MLX90614.
Fonte: Folha de dados do sensor.

Figura 3.2 – Sensor MLX90614.
Fonte: Folha de dados do sensor.
temperatura final obtido através deste segundo método é a média das temperaturas
que o sensor infravermelho detecta dentro do seu campo de visada.
• Um módulo MPU-6050: O módulo MPU-6050 da empresa TDK - Inven Sense é

constituído por dois sensores: um sensor acelerômetro de três eixos e um sensor
girômetro, também de três eixos. As principais aplicações desse módulo de sensores
são dispositivos de interação motora como os smartphones, tablets e controles de
jogos de videogame. Este módulo de sensores utiliza o protocolo de comunicação
I2C para comunicar-se com o microcontrolador responsável pelo processamento dos
dados provenientes dele. Está disponível em um encapsulamento 24-VFQFN.
• Dois módulos HC-12: Este módulo é responsável pela transmissão e recepção dos
dados enviados através do sistema instalado no local de analise para o sistema super-
visório. Fabricado pela empresa Elecrow opera com um espectro de frequências entre
3.2. Arquitetura de Funcionamento do Sistema 43
433 MHz à 473 MHz, disponibilizados em mais de 100 canais de comunicação. Este
módulo utiliza-se de um microcontrolador STM8S, da empresa ST Eletronics, para
o gerenciamento de suas funções. A configuração do mesmo é feita via comandos
ASCII - popularmente conhecidos como comandos AT - enviados por comunicação
UART, assim como os dados a serem transmitidos. Ele pode ser configurado para
operar como receptor ou transmissor, adotando em ambas os modos de operação
a característica de broadcast 1 . Sistemas de transmissão do tipo broadcast necessi-
tam de um tratamento em firmware para a segurança dos dados, caso assim seja
necessário.
• Quatro controladores MCP2515: Os controladores MCP2515 da empresa Microchip,

implementam todo o protocolo CAN necessário para o funcionamento de uma rede
CAN. Estes controladores utilizam um interface de comunicação com microcontrola-
dor do tipo SPI. Todos os parâmetros discutidos na seção 2.4.1.2 são implementados
por este controlador.
• Quatro placas Arduino: A seção 2.5.1 aborda todos os aspectos relacionados as

placas arduino, não sendo necessário cita-los novamente.
Uma das formas de simplificação do uso desses sensores que o mercado vem desenvol-
vendo é a fabricação de shields. Um shields de um determinado sensor trata-se de uma
pequena placa de circuito impresso que implementa todo o hardware necessário para o
funcionamento de um determinado sensor. O uso de shields é uma prática que acelera a
prototipagem de projetos diminuindo o tempo desta etapa e facilitando o experimento de
diferentes sensores em um projeto.
A utilização de todos os sensores acima citados foi feita através de shields e os mesmos
serão com mais detalhes apresentados nas próximas seções.
3.2 Arquitetura de Funcionamento do Sistema

O funcionamento do sistema está baseado em um fluxo de informações que inicia-se
através da leitura dos sensores, terminando na exibição dos dados gerados pelo sistema
supervisório. A Figura 3.3 ilustra os blocos funcionais presentes no sistema.
Como citado na seção 3.1, a alimentação do sistema é feita por baterias de 9V. O
bloco "Central de processamento e transmissão"e o bloco "Central de recepção"operam
com tensões de 5V e necessitam de um regulador de tensão para baixar as tensões de
1
A transmissão ou recepção do tipo broadcast acontece quando o transmissor emite um sinal e qualquer
receptor, operando em mesma frequência, recebe o sinal transmitido. Tratando-se da recepção, o
receptor recebe dados transmitidos de qualquer fonte, não importando se o dado transmitido tinha
como destino ele ou não
Figura 3.3 – Representação Esquemática da Arquitetura do Sistema.
Fonte: O autor.
alimentação para o valor adequado de operação. Os regulador utilizado para esta função
é o LM7805 com encapsulamento TO-220, da empresa Texas Instruments.
3.3 Arquitetura do Hardware

O Hardware do sistema pode ser divido em 5 módulos, sendo eles: um módulo ace-
lerômetro, dois módulos de temperatura, um módulo de processamento e transmissão dos
dados e um módulo de recpção e comunicação com o sistema supervisório. Nas próximas
subseções é descrito o processo de desenvolvimento de cada um deles.
3.3.1 Módulo CAN - Temperatura

Em um primeiro momento, objetivou-se a realização de pequenos testes realizados com
todos os elementos compositores do sistema. Para isto, montou-se todos eles através de
seus shields e fios de jumper e deu-se inicio a escrita de um firmware base para testes. A
Figura 3.4 exibe a montagem antes da realização dos testes.
3.3. Arquitetura do Hardware 45
Figura 3.4 – Montagem teste para módulo de temperatura.
Fonte: O autor.
Para a construção dos módulos de temperatura foi utilizado o mesmo shield mostrado
na Figura 3.4 - localizado na região inferior esquerda da imagem, que implementa o
hardware necessário apara a utilização do sensor MLX90614, como citado na seção 3.1.
A Figura 3.5 exibe o dispositivo em mais detalhes.
Figura 3.5 – Shield do sensor MLX90614.
Fonte: Site FILIPEFLOP - Disponível em

https://www.filipeflop.com/produto/sensor-de-temperatura-ir-mlx90614/.
Como já citado na seção 3.1, este sensor possui a capacidade de obter dados de tempe-
ratura ambiente e de uma determinada região, de acordo com as ondas de infravermelho
que estiverem eu seu campo de visada. Porém, dado o objetivo do projeto, montou-se dois
módulos de temperatura, um deles dedicado a realizar medidas de uma região específica
e o outro dedicado a realizar medidas de temperatura ambiente. Ambos os módulos pos-
suem um microcontrolador ATmega328P, o mesmo que compõem as placas Arduino Uno.
Desta forma pode-se utilizar o mesmo ambiente de desenvolvimento das placas Arduino,
simplificando assim o processo de implementação do firmware, descrito na seção 3.4. A

Figura 3.6 exibe um esquema para a arquitetura dos módulos de temperatura, sendo a
única diferença entre o módulo dedicado a medidas de temperatura ambiente e o dedi-
cado a medidas de temperatura de uma área o firmware embarcado em cada um deles. O
Anexo A, ao final deste trabalho, apresenta o esquemático utilizado para roteamento da
placa de circuito impresso, desenhado no software Altium.
Figura 3.6 – Representação Esquemática para o Módulo de Temperatura.
Fonte: O autor.
Na Figura 3.6 nota-se a adição de mais um regulador de tensão. Este se faz necessário
devido a tensão de operação dos sensores, sendo esta de 3.3V. O regulador utilizado para
esta função foi o LM78L33, da empresa ST Eletronics.
3.3.2 Módulo CAN - Acelerômetro

Para a realização dos testes iniciais dos elementos deste módulo montou-se os dispo-
sitivos através de shields e fios de jumper, como mostrado na Figura 3.7.
Para a construção do módulo acelerômetro novamente foi utilizado o shield para a
implementação do hardware básico para o funcionamento do módulo de sensores MPU-
6050, como citado na seção 3.1. A Figura 3.8 exibe o dispositivo em mais detalhes e a
Figura 3.9 apresenta a orientação cartesiana do módulo.
Para a confecção do circuito dedicado ao funcionamento desde módulo, novamente,
utilizou-se o microcontrolador ATmega328P visto as simplificações na produção de firmware
que o mesmo apresenta. A Figura 3.10 exibe um esquema para a arquitetura de hard-
ware do módulo e o Anexo B, ao final deste trabalho, exibe o esquemático do circuito,
produzido no software Altium.
3.3. Arquitetura do Hardware 47
Figura 3.7 – Montagem teste para módulo acelerômetro.
Fonte: O autor.
Figura 3.8 – Shield do acelerômetro MPU-6050.
Fonte: Site Robocore - Disponível em:

https://www.robocore.net/loja/produtos/acelerometro-e-giroscopio-mpu6050.html.
3.3.3 Módulo Central de Processamento e Transmissão e Mó-

dulo de Recepção e Integração com Sistema Supervisório
A metodologia de confecção de ambos os módulos seguiu os passos citados nas seções
3.3.1 e 3.3.2. Porém, para a realização dos testes de processamento, transmissão e recep-
ção, todo o sistema foi previamente montado para que pudesse-se testar com uma maior
confiabilidade os aspectos destes dois módulos. Desta forma, montou-se cada módulo do
sistema para que pudesse-se validar os aspectos relacionados a rede CAN e a transmissão
de dados, assim como a recepção, do sistema como um todo. Esta montagem esta exibida
Figura 3.9 – Orientação do acelerômetro MPU-6050.
Fonte: Folha de dados do MPU-6050
Figura 3.10 – Representação Esquemática para o Módulo Acelerômetro.
Fonte: O autor.
na Figura 3.11.
A partir do funcionamento e da validação dos módulos de transmissão e recepção como

mostrados na Figura 3.11, pode-se partir para a montagem de placas de circuito impresso
dedicada a cada uma das duas funções. A Figura 3.12 exibe o esquema para a arquitetura
de cada uma dos módulos. O Anexo C exibe o esquemático para o módulo transmissor e o
Anexo D exibe o esquemático para o receptor, ambos produzidos com o software Altium.
3.4. Arquitetura do Firmware 49
Figura 3.11 – Montagem para teste do sistema completo.
Fonte: O autor.
Figura 3.12 – Esquema para módulo de processamento e transmissão e do módulo de

recepção e integração com sitema supervisório, respectivamente.
Fonte: O autor.
3.4 Arquitetura do Firmware

A metodologia utilizada para a confecção do firmware do sistema foi dividir-se o código
final, completo, em pequenos trechos de código com o objetivo de testar-se cada parte
do sistema de maneira individual para, em uma etapa final, integrar todos os trechos de
código funcionais em um firmware final.
Nas próximas seções são apresentados os fluxogramas dos firmwares desenvolvidos e
os dados de teste obtidos.
Para o desenvolvimento do firmware utilizou-se o ambiente de desenvolvimento das
placas Arduino. O uso deste ambiente de desenvolvimento apresenta grande integração

com o microcontrolador utilizado para os desenvolvimento assim como uma grande quan-
tidade de materiais e tutoriais disponíveis.
Em ambos os desenvolvimentos utilizou-se também comunicação serial para verificar-
se o funcionamento do firmware. O terminal serial utilizado foi o Docklight. Este terminal
serial foi escolhido por apresentar recursos interessantes na analise e interação de dados
via comunicação serial. A Figura 3.13 ilustra a interface gráfica deste software.
Figura 3.13 – Interface gráfica do software Docklight.
Fonte: O autor.
3.4.1 Desenvolvimento do firmware de testes para o Módulo de

Temperatura
Para o desenvolvimento do firmware dos módulos de temperatura foram utilizados os
protocolos de comunicação I2C, para comunicação com o sensor de temperatura, UART,
para a conferência dos dados provenientes do sensor, e SPI para o controle do módulo
MCP2515, responsável pelo envio dos dados ao barramento CAN.
O sensor MLX90614, como citado na seção 3.1, pode ser utilizado para medidas de
temperatura tanto de uma região específica como para temperatura ambiente. No âmbito
de desenvolvimento de firmware, está diferença se dá pelo endereço de acesso para leitura
I2C, utilizado no momento de uma requisição de dados. Utilizando-se o endereço hexa-
decimal 0x06, tem-se acesso a medidas de temperatura ambiente. Utilizando o endereço
hexadecimal 0x08, tem-se acesso a medidas de temperatura de uma região.
Em um primeiro momento, com o objetivo de realizar uma leitura dos valores do sensor
de maneira simples, implementou-se o fluxograma apresentado na Figura 3.14.
Figura 3.14 – Fluxograma de testes iniciais do sensor de temperatura.
Fonte: O autor.
Posterior a validação desta leitura, objetivou uma implementação de firmware que

maior se adequasse a realidade do projeto, que só pode ser testada com todo o sistema em
funcionamento, visto a necessidade de comunicação deste módulo com os demais módulos
da rede. A Figura 3.15 exibe o fluxograma implementado.
O funcionamento do firmware do módulo de temperatura é atrelado a uma rotina
interrupção do temporizador do microcontrolador. Essa interrupção é responsável por
temporizar o envio de dados ao barramento CAN. As interrupções foram configuradas para
acontecerem a cada 1 milissegundo e uma variável auxiliar conta o número de interrupções
que ocorreram, enviando uma mensagem ao barramento CAN a cada 100 interrupções
acontecidas, o que é equivalente a 100 milissegundos.
Está técnica de temporização é interessante pois não se cria trechos de código blo-
queante no sistema e pode-se conseguir uma boa variedade de temporizadores a partir de
uma unidade de tempo definida, que para este caso foi de um milissegundo.
O fluxograma para a rotina de interrupção, que acontece de maneira paralela ao apre-
sentado na Figura 3.15 é apresentado na Figura 3.16.
3.4.2 Desenvolvimnto do firmware de testes para o Módulo

Acelerômetro.
Para o desenvolvimento do firmware do módulo acelerômetro foram utilizados os mes-
mos protocolos de comunicação citados na seção 3.4.1.
Figura 3.15 – Fluxograma de funcionamento do Módulo de Temperatura.
Fonte: O autor.
Figura 3.16 – Fluxograma da interrupção do sistema no módulo de temperatura.
Fonte: O autor.
O módulo MPU-6050 pode ser configurado para diferentes sensibilidades aceleração.

Por padrão, ele utiliza uma uma configuração de aceleração máxima de duas vezes a
aceleração da gravidade (±2 g), mas pode ser configurado com aceleração máxima de ±4
g, ±8 g ou ±16 g. Ele disponibiliza o valor de aceleração em dois registradores de 8 bits
cara um, sendo o valor final formado por 16 bits. Esses 16 bits, na configuração padrão,
são responsáveis por representar um valor entre −2 g e +2 g, em forma de complemento
de dois.
O fluxograma para implementação do primeiro teste é exibido na Figura 3.17.
Como nos procedimentos descritos na seção 3.4.1, após a realização deste teste inicial
implementou-se o firmware mais completo, com as características necessárias para o fun-
Figura 3.17 – Fluxograma de testes inicias do acelerômetro.
Fonte: O autor.
cionamento do sistema como um todo. A mesma técnica de temporização, com o mesmo

objetivo, foi implementada neste firmware, mantendo-se assim um padrão para o sistema.
O Figura 3.18 e 3.19 exibem o fluxograma de funcionamento do firmware para o módulo
acelerômetro e o fluxograma para a interrupção do temporizar, respectivamente.
Figura 3.18 – Fluxograma de funcionamento do módulo acelerômetro.
Fonte: O autor.
Figura 3.19 – Fluxograma da interrupção do sistema no módulo acelerômetro.
Fonte: O autor.
3.4.3 Processamento e Transmissão de Dados pelo Módulo Cen-

tral
A implementação do firmware para o módulo de transmissão necessitou que todos os
módulos do sistema estarem em funcionamento. O firmware implementado apresenta um
trecho relacionado ao reconhecimento da origem da mensagem vinda através do barra-
mento CAN e, posterior, armazenamento dos dados nas variáveis dedicadas a cada uma
das três origens de mensagens - dados provenientes do módulo de temperatura ambiente,
dados provenientes do módulo de temperatura de uma região (temperatura de um ob-
jeto) ou dados provenientes do módulo acelerômetro. Posterior a verificação dos dados, o
firmware verifica se a transmissão da mensagem já esta habilitada, sendo ela habilitada
via interrupção do temporizador do microcontrolador.
O fluxograma apresentado na Figura 3.20 ilustra a arquitetura para o firmware imple-
mentado.
O fluxograma para interrupção do temporizador deste sistema, que seguiu o padrão
de implementação dos outros módulos, é exibida na Figura 3.21.
3.4.4 Recepção dos Dados e Integração com Sistema Supervisó-

rio
O módulo de recepção apresenta implementação mais simples dentre os módulos anteri-
ores. Sua única função é a recepção dos dados via UART e o envio ao sistema supervisório.
A Figura 3.22 ilustra o fluxograma implementado.
3.5 Sistema Supervisório

Visto que o objetivo principal deste projeto é o desenvolvimento do firmware e hardware
de um sistema de telemetria, utilizou-se o sistema supervisório utilizado desenvolvido no
3.5. Sistema Supervisório 55
Figura 3.20 – Fluxograma de funcionamento do módulo central de processamento e trans-

missão de dados.
Fonte: O autor.
trabalho "Desenvolvimento de Sistema Supervisório para Aquisição de Dados de Sensores

Embarcados Através do Protocolo TCP/IP", apresentado como trabalho de conclusão de
curso por Pedro H. B. Bonifácio. (BONIFACIO, 2018)
Para o sistema aqui proposto realizou-se apenas algumas adaptações, visto que o
sistema supervisório original desenvolvido no trabalho citado é compatível com algumas
das necessidades do projeto de telemetria aqui proposto.
Figura 3.21 – Fluxograma de funcionamento do módulo central de processamento e trans-

missão de dados.
Fonte: O autor.
Figura 3.22 – Fluxograma de funcionamento do módulo de recepção e integração com
sistema supervisório.
Fonte: O autor.

Conforme exposto nas seções acima, para o desenvolvimento dos dispositivos que in-
tegram o sistema de telemetria proposto neste trabalho seccionou-se as frentes de desen-
volvimento em firmware e hardware.
Em ambas as frentes, uma estrutura bastante semelhante de desenvolvimento foi ado-
tada entre os módulos, fazendo com que dessa forma se obtivesse uma economia de tempo
no processo de desenvolvimento, visto que elementos comuns aos módulos foram desen-
volvidos apenas uma vez e reaproveitados em outros momentos.
Para o desenvolvimento da estrutura de hardware buscou-se adotar um posicionamento
semelhante dos componentes na placa entre os diferentes módulos. Está metodologia traz
vantagens para investigação de possíveis erros gerados durante o processo de fabricação
das placas.
Assim como no desenvolvimento do hardware, para o desenvolvimento e implementação

do firmware de cada um dos módulos também buscou-se uma padronização para que
possíveis depurações e implementações futuras sejam realizadas de maneira simples.
As semelhanças no desenvolvimento do hardware e firmware ficam evidentes analisando-
se as representações esquemáticas e os fluxogramas presentes neste capítulo.
59
4 Resultados
4.1 Módulo CAN - Temperatura

Para o a confecção do módulo CAN de Temperatura utilizou-se a ferramenta de desen-
volvimento de placas de circuito impresso Altium. O protótipo final, ainda na ferramenta
de desenvolvimento Altium, pode ser visto na Figura 4.1, diferindo a segunda imagem
da primeira na visualização das trilhas da parte superior e inferior da placa - as trilhas
em cor azul estão na parte inferior da placa e as trilhas em cor vermelha estão na parte
superior da placa. Já a Figura 4.2 exibe a visualização tridimensional da placa, ainda em
ambiente de desenvolvimento. Os esquemáticos do circuito estão expostos no Apêndice
A, ao final deste trabalho.
Figura 4.1 – Protótipo finalizado para os módulos de temperatura.
Fonte: O autor.
A realização dos testes, feitos com as placas Arduino, em um primeiro momento tive-
ram como objetivo a confirmação da leitura dos dados através do protocolo I2C. A Figura
4.3 exibe os dados provenientes do sensor para uma medida de temperatura ambiente.
Os valores hexadecimais 0x01 e 0x04 são utilizado única e exclusivamente para a
denotação do inicio e do final da mensagem, não fazendo parte efetivamente dos dados.
Nota-se que esses são valores puros, ainda não tendo significado claro aparente. Através
da folha de dados do sensor, sabe-se que o mesmo apresenta uma precisão de 0,02 K,
sendo necessário o calculo apresentado na equação 4.1 para obter-se um valor em graus
Celcius.
M edida(◦ C) = REG16bits · 0, 02 − 273, 15, (4.1)

Observando os valores apresentados na Figura 4.3, tomando com base o ultimo valor
apresentado (0x3A65) e realizando o calculo apresentado na equação 4.1 pode notar-se
60 Capítulo 4. Resultados
Figura 4.2 – Visualização Tridimensional do Protótipo finalizado para os módulos de tem-

peratura, em ambiente de desenvolvimento.
Fonte: O autor.
Figura 4.3 – Dados enviados pelo sensor de temperatura.
Fonte: O autor.
que o valor apresentado no momento da medida era de 25,8◦ C, sendo este valor condi-
zente com a temperatura medida no local durante os testes. Desta forma confirmou-se
que o algoritmo para leitura do sensor funciona. A realização para medidas de tempera-
tura de um objeto seguem os mesmos padrões de leitura, não sendo necessária realizar o
procedimento de testes novamente.
4.2. Módulo CAN - Acelerômetro 61
4.2 Módulo CAN - Acelerômetro

Para a confecção do módulo CAN Acelerômetro novamente utilizou-se a ferramenta
Altium. O protótipo final pode ser visto na Figura 4.4, sendo as diferenças entre a primeira
e a segunda imagem exatamente as mesmas citadas na seção anterior. Já a Figura 4.5
exibe a visualização tridimensional da placa, ainda em ambiente de desenvolvimento. Os
esquemáticos do circuito estão expostos no Apêndice B, ao final deste trabalho.
Figura 4.4 – Protótipo finalizado para o módulo acelerômetro.
Fonte: O autor.
Figura 4.5 – Visualização tridimensional do Protótipo finalizado para o módulo acelerô-

metro, em ambiente de desenvolvimento..
Fonte: O autor.
Novamente, testes inicias foram realizados com o objetivo de confirmar as leituras

realizadas do dispositivo. O mesmo foi posicionado de maneira a obter-se uma aceleração
de aproximadamente 1 g em seu eixo de coordenada x. Os dados obtidos pela leitura do
sensor estão exibidos na Figura 4.6.
Novamente, os valores 0x01 e 0x04 são unicamente responsáveis pela determinação do
inicio e fim da mensagem enviada através do microcontrolador, não tento nenhum valor
lógico neste momento.
Figura 4.6 – Dados enviados pelo acelerômetro.
Fonte: O autor.
Para o calculo dos valores úteis deste módulo, utiliza-se do calculo apresentado na
equação 4.2.
REG16bits · 2 · g
M edida(m/s2 ) = (4.2)
32767
Aplicando-a aos valores obtidos na Figura 4.6, obtem-se valores próximos a 9,8 m/s2 ,
confirmando-se assim a funcionalidade do algoritmo de medida. Nota-se que o 2 g na
Equação 4.2 foi inserido devido a configuração do módulo. Caso a sensibilidade do mesmo
seja alterada, este valor também será. Outra notação é a da medida para valores negativos:
caso os valores provenientes do sensor sejam maiores do que 32767, a equação para obter-se
os valores úteis do sensor modifica-se para a equação 4.3.
(REG16bits − 32767) · 2 · g
M edida(m/s2 ) = − (4.3)
32767
Para solucionar a qual equação utilizar para o calculo, em firmware, basta utilizar do
recurso if, utilizando a Equação 4.2 caso o valor lido seja menor ou igual a 32767, e a
Equação 4.3 caso o valor seja maior.
4.3 Módulos de Transmissão e Recepção

Para a confecção dos módulos de transmissão e recepção, como nas seções anterio-
res, utilizou-se da ferramenta de desenvolvimento de PCIs Altium. As Figuras 4.7 e 4.8
4.4. Sistema Supervisório 63
exibem o protótipo final, no ambiente de desenvolvimento. Os Apêndices C e D apresen-

tam os esquemáticos dos módulos transmissor e receptor, respectivamente, sendo estes
encontrados ao final deste trabalho.
Figura 4.7 – Protótipo finalizado para o Módulo Receptor
Fonte: O autor.
Figura 4.8 – Protótipo finalizado para o Módulo Transmissor
Fonte: O autor.
As Figuras 4.9 e 4.10 exibem uma visualização tridimensional das placas, em ambiente
de desenvolvimento.
Os testes realizados com estes módulos envolveram o funcionamento do sistema de
maneira completa, sendo o funcionamento obtido apresentado na seção 4.4.
4.4 Sistema Supervisório

Para a obtensão do sistema supervisório utilizado foram realizadas, em linhas gerais,
duas alterações.
A primeira dela diz respeito ao pacote de dados utilizados no sistema original. O pacote
de dados original contava com alguns campos destinados a verificações de redundância
dos dados recebidos, manipulação de dados por byte stuffing, dentre outros campos, sendo
Figura 4.9 – Visualização tridimensional do Módulo Receptor, em ambiente de desenvol-

vimento
Fonte: O autor.
Figura 4.10 – Visualização tridimensional do Módulo Transmissor, em ambiente de de-

senvolvimento
Fonte: O autor.
esses não necessários para a aplicação posposta por este trabalho e, desta forma, retirados
do pacote.
A segunda alteração foi relacionada aos tipos de dados exibidos e a forma de exibição
destes. O sistema original já contava com o tratamento de uma cadeia de dados de
temperatura, sendo esta etapa apenas replicada para mais um cadeia de dados. Já os
dados de aceleração, também tratados de certa forma no sistema original, tiveram sua
forma de exibição alterada, utilizando-se, como para o caso das temperaturas, gráficos em
linha.
A Figura 4.11 exibe a aba do sistema supervisório dedicada a realizações de medidas
de aceleração. Nesta pode-se observar um comportamento de repentina mudança nas
leituras do sensor. Este comportamento pode traduzir-se em meios automotivos com uma
4.5. Custo de Confecção do Protótipo 65
utilização brusca do sistemas de freio, ou uma saída de curva com o acelerador muito
pressionado - a diferença de uma situação e outra dependeria da orientação do sensor em
relação ao veículo.
Figura 4.11 – Dados de telemetria visto no sistema supervisório provenientes do acelerô-

metro
Fonte: O autor.
A Figura 4.12 exibe a aba do sistema supervisório dedicada a realizações de medidas

de temperatura ambiente. Este parâmetro, durante a realização dos testes, não foi forçado
a ter alterações, buscando-se ter uma percepção de como o sistema comportaria-se em
medidas sem muitas variações.
A Figura 4.13 exibe a aba do sistema supervisório dedicada a realizações de medidas de
temperatura de um objeto, ou região, específicos. A variação de temperaturas mostrada
na figura foi conseguida ao colocar-se o dedo próximo ao campo de visada do sensor. Se
considerar-se que a temperatura do corpo humano em suas extremidades é ligeiramente
menor do que em regiões próximas ao tronco, pode considerar-se está uma boa medida.
4.5 Custo de Confecção do Protótipo

Para a confecção do protótipo aqui apresentado foram utilizados os shields de cada
um dos sensores, do receptor e transmissor, e quatro kits standalone das placas Arduino
Uno. Esses kits foram adquiridos através da loja online Instituto Digital - disponível
em: http://www.institutodigital.com.br/. Já os módulos foram adquiridos através de
vendedores do site Mercado Livre. Neste site os valores apresentam alguma variação
entre os vendedores, porém para a realização do calculo de custo do protótipo utilizou-se
um valor médio, dentre os encontrados.
Figura 4.12 – Dados de telemetria visto no sistema supervisório para temperatura ambi-
ente.
Fonte: O autor.
Figura 4.13 – Dados de telemetria visto no sistema supervisório para temperatura de um

objeto.
Fonte: O autor.
A Tabela 1 exibe os custos individuais de cada componente adquirido e o valor total

do protótipo.
Para uma estimativa ainda mais precisa de custos, devem ser levados em consideração
o valor das horas de trabalho do desenvolvedor responsável e também o custo de produção
das PCIs. Desconsiderando estes valores, com objetivo de gerar-se uma breve estimava
Tabela 1 – Custo de Fabricação do Protótipo
Custo Individual Custo Total

Item Quantidade
(R$) (R$)
Módulo HC-12 2 27,49 54,98
Kit Arduino Standalone 4 17,10 68,40
Módulo MCP2515 4 18,90 75,60
Módulo MLX90614 2 47,00 94,00
Módulo MPU-6050 1 12,40 12,40
Total 305,38
Tabela 2 – Custo, através de importação dos componentes, de Fabricação do Protótipo
Custo Individual Custo Total

Item Quantidade
(U$) (U$)
Módulo Transmissor
2 5,00 10,00
(semelhante ao utilizado)
ATmega328/P 4 2,14 4,28
Módulo MCP2515 4 1,87 7,48
Módulo MLX90614 2 14,78 29,56
Módulo MPU-6050 1 3,52 3,52
Total 54,84
de custos, o valor de R$305, 38 já é bastante inferior a um sistema de telemetria para

esportes à motor comercial - cujo custo varia entre R$5000, 00 à R$10000, 00, para um
sistema completo.1
A Tabela 2 apresenta os custos do protótipo orçados internacionalmente - a loja utili-
zada para o levantamento destes valores foi a Digikey, disponível em: www.digikey.com/.
Como pode-se notar, considerando-se que o valor de U $1, 00 seja equivalente a R$3, 90, o
custo total seria de aproximadamente R$213, 88. Sabendo-se que os valores apresentados
na Tabela 2 são para os sensores sem o hardware básico de implementação para o seu
funcionamento, uma boa estimativa de valor para a compra dos componentes necessários
para a implementação completa do hardware é de 20% do custo total do projeto. Desta
forma, o valor final do custo deste protótipo não seria maior que R$256, 66, R$48, 72 a
menos do que os custos levantados em mercados nacionais.

Os testes realizados para comprovação de funcionamento do sistema foram realizados
com o sistema montado nos esquemas apresentados na seção 3.3.
O funcionamento do sistema de aquisição de dados foi bastante eficiente, sendo os
dados obtidos por ele todos condizentes com os esperados dentro dos testes realizados.
1
Estes valores de custos foram levantados com praticantes da modalidade em competições regionais,
visto que o acesso a esta informação por parte de um fabricante é bastante complicado de se obter.
Já o sistema supervisório apresentou um processamento de dados um pouco lento. Este

comportamento tem justificativa nas adaptações utilizadas para este sistema, visto que
o mesmo não foi desenvolvido para atender exclusivamente a realidade do projeto aqui
proposto.
No que tange os custos do protótipo, pode-se notar que o sistema aqui proposto
apresenta um valor de produção menor do que sistemas comercializados atualmente. Ob-
viamente, a precisão e a quantidade de dados obtidos através do sistema aqui proposto é
bem menor do que de sistemas profissionais, porém o objetivo do protótipo é tornar-se um
produto que atenda justamente categorias dos esportes à motor em que não se necessite
de grande precisão em suas medidas e também não se disponha de grandes investimentos
para sistemas de telemetria profissionais.
69
5 Discussões e Conclusões
Atualmente o processo de prototipagem apresenta muito mais recursos do que a poucos

anos atrás. Com a já consolidação e popularização da plataforma Arduino e tudo o que
ela envolve, acabam-se por facilitar muitos processos de prototipagem e, com alguns dias
de trabalho, consegue-se ter os primeiros dados de um sistema simples.
Para o ambiente deste projeto está realidade não se mostrou diferente. A facilidade
na compra dos shields, das placas Arduino e do restante dos suplementos, foi um fator de
extrema importância para que a construção do sistema não encontrasse nenhuma barreira
durante o desenvolvimento.
A grande quantidade de materiais disponíveis, mesmo que muitos deles de referências
não tão consolidadas, também é um fator que potencializa a construção de projetos como
estes, sem que existam possíveis falhas de hardware ou software que ainda não tenham
sido, em algum momento, encontradas e corrigidas.
A grande dificuldade do projeto, e do mercado nacional com um todo, está no passo
seguinte a prototipação. Visto que este trabalho tem como objetivo realizar um estudo
do que possa vir a se tornar um produto, somente no que tange a disponibilidade de
componentes eletrônicos no mercado nacional é um passo enorme a ser dado.
O que se observa é que, para que sistemas como o aqui apresentado saírem do ambiente
de protótipo e passarem ao ambiente de projeto deve-se criar sistemas completamente
dedicados as respectivas tarefas. Porém a compra de componentes dedicados "em natura",
ou seja, fora dos shields, acaba por tornar boa parte dos projetos desenvolvido em território
nacional inviável visto o custo de importação desses componentes. A solução para estas
situações é a compra de grandes quantias de um produto, o que mesmo assim acaba saindo
fora da realidade de muitos desenvolvedores do país.
Na seção 4.5, são apresentados os custos para a montagem do protótipo tendo como
referência o mercado nacional e internacional. Dois pontos são bastante importantes
de se analisar destes valores. O primeiro é no que diz respeito aos valores do mercado
internacional, visto que os valores observados na Tabela 2 poderiam ser consideravelmente
menores caso a quantidade de componentes orçada fosse maior - para uma produção de
1000 peças, por exemplo. Já o segundo é o que diz respeito a taxas de importação de
produtos eletrônicos: as taxas alfandegarias brasileiras para este tipo de importação são
extremamente altas, muitas das vezes chegando a triplicar o valor do produto. Estas taxas
acabam por imobilizar o desenvolvedor nacional, visto que os projetos normalmente ficam
presos na etapa de protótipo, não sendo viável uma produção em baixa ou média escala.
Relacionado ao sistema desenvolvido, observou-se a necessidade de um sistema super-
visório projetado especificamente para atender aos requisitos do projeto. Sistemas desta
natureza, quando adaptados a uma realidade diferente à que foram projetados, acabam
70 Capítulo 5. Discussões e Conclusões
por se tornar lentos - fato este comprovado neste trabalho. O sistema supervisório, ape-
sar de se mostrado eficaz, apresentou um comportamento ligeiramente lento ao esperado.
Este problema seria solucionado caso o sistema supervisório utilizado fosse dedicado a
realidade do projeto.
5.1 Trabalhos Futuros

A proposta apresentada neste trabalho tem um potencial grande e não tão complexo
de expandir-se em próximos trabalhos.
O primeiro ponto a citar-se é o desenvolvimento de placas de circuito impresso dedi-
cadas a realidade do projeto. Este trabalho pode torna-se ligeiramente complexo no que
tange a compra dos componentes, sendo a maioria deles encontrado apenas em mercado
internacional.
Uma outra abordagem que trabalhos futuros podem utilizar é a de sistemas de su-
pervisórios para este fim, projetados de maneira dedicada a integrar-se com o hardware
proposto. Este trabalho poderia ter um cunho mais voltado a áreas de computação, po-
rém a carga horária de programação apresentada em nosso curso é suficiente para que
o aluno possa integrar-se a esse novo ambiente de programação e, rapidamente, dar ini-
cio a um desenvolvimento deste tipo de sistema, mesmo que com recursos simples de
processamento.
Uma terceira, e última, abordagem à trabalhos futuros partindo-se do aqui apresen-
tado é a integração a do sistema à um veículo real. A comunidade envolvida neste tipo
de esporte é receptiva a novas tecnologias e sempre está interessada em participar de
desenvolvimentos desta natureza.
71
Referências
Adilson Thomsen. O que é Arduino. 2014. Disponível em: <https://www.filipeflop.com/

blog/o-que-e-arduino/>. 37
Arduino Company. 2018. Disponível em: <https://www.arduino.cc/>. 36
BARBOSA, R. Z. P. M. J. E. M. Desenvolvimento de um Sistema de Telemetria para

Monitoramento Térmico em Casas de Vegetação. Botucatu, SP, Brasil: Brazilian Journal
of Biosystems Engineering v. 8(1): 25-33, 2014. 25
BONIFACIO, P. H. B. Desenvolvimento de Sistema Supervisório para Aquisição de

Dados de Sensores Embarcados Através do Protocolo TCP/IP. Londrina, PR, Brasil:
Universidade Estadual de Londrina, 2018. 26, 55
Daniela Diana. História da Internet. 2013. Disponível em: <https://www.todamateria.

com.br/historia-da-internet/>. 19
DANTAS, D. H. Sistema de Telemetria para Kart. Brasília - DF, Brasil: Centro

Universitário de Brasília, 2012. 25
EVANS, M. Arduino em Ação. São Paulo, SP, Brasil: Novatec, 2013. 35
Felipe Garret. A técnologia da F1 no seu carro. 2012. Disponível em: <https://www.

techtudo.com.br/artigos/noticia/2012/05/tecnologia-da-f1-no-seu-carro-atual.html>. 23
Geraldo Magela Machado. História da Comunicação Humana. 2010. Disponível em:

<https://www.infoescola.com/historia/historia-da-comunicacao-humana/>. 19
GUIMARAES, A. A. Eletrônica Embarcada Automotiva. São Paulo, SP, Brasil: Érica,

2007. 26, 27
Guimarães, A. A. Barramento Controller Network Area - Conceituação. 2004. Disponível

em: <http://www.alexag.com.br/CAN_Bus_Parte_2.html>. 27
Guimarães, A. A. Barramento Controller Network Area - Conceituação. 2004. Disponível

em: <http://www.alexag.com.br/CAN_Bus_Parte_3.html>. 34
Le Petit Journal. La Grande Journée. 1894. Disponível em: <https://gallica.bnf.fr/ark:

/12148/bpt6k613226v.langFR>. 23
Marcia Garcia. A Revolução da IoT. 2018. Disponível em: <https://www.arcon.com.br/

blog/a-revolucao-iot>. 20
Microchop. Introduction to controller area network. Microchip WebSeminars, 2012. 27,

30, 32
NUNES, T. F. Telemetria de um Veículo Baja SAE através de Rede CAN. Natal, RN,
Brasil: Universidade Federal do Rio Grande do Norte, 2016. 25
PALHAIS, C. B. C. Prototipagem - Uma Abordagem ao Processo de Desenvolvimento de

um Produto. Lisboa, Portugal: Universidade de Lisboa, 2015. 38
72 Referências
POLESE, B. Dispositivo de Telemetria Multiprotocolo com transmissão via Internet.

Passo Fundo, RS, Brasil: Universidade de Passo Fundo, 2017. 24
Rainer Gonçalves. Landell de Moura, o inventor do rádio. 2010. Dis-

ponível em: <https://historiadomundo.uol.com.br/idade-contemporanea/
landell-de-moura-o-inventor-do-radio.htm>. 19
Roberto Agresti. Do Dakar ao MotoGP: competições ajudam evolução de motos de rua.

2014. Disponível em: <http://g1.globo.com/carros/dicas-de-motos/noticia/2014/01/
do-dakar-ao-motogp-competicoes-ajudam-evolucao-de-motos-de-rua.html>. 23
Texas Instruments. Introduction to the controller area network. Application Report,

2002. 28, 29
Texas Instruments. Sn65hvd233-ht 3.3-v can transceiver. 2008. 30
Thais Pacievitch. História do Telefone. 2009. Disponível em: <https://www.infoescola.

com/curiosidades/historia-do-telefone/>. 19
WEBSTER, J. G. The Measurement, Instrumentation and Sensors Handbook. Boca

Raton, FL, Estados Unidos: CRC PRESS, 1999. 25
73
6 Apêndice A - Esquemático - Mó-
1 2 3 4
CN1 D1 U1 LM7805 5V
1 3
2 IN OUT
1 GND
1N4007
10uF/25V
BR902V R1
10uF/25V
A C1 C2 A
2
470R - 1/4W
GND
LD1
GND WP7113ID 3.3V
IC1
1 3
VCC SCL SCL
2 4
GND SDA SDA
GND MLX90614-MOD
5V U2 LM7833 3.3V
3 1
IN OUT
GND
dulo de Temperatura
GND
10uF/25V
10uF/25V
C3 C4
2
B B
5V
U3
GND 7
VCC
20 23
AVCC PC0 (ADC0/PCINT8)
21 24
AREF PC1 (ADC1/PCINT9)
25
PC2 (ADC2/PCINT10)
26
PC3 (ADC3/PCINT11)
5V 27
PC4 (ADC4/SDA/PCINT12) SDA
28
PC5 (ADC5/SCL/PCINT13) SCL
1 5V
R2 PC6 (RESET/PCINT14) RESET
IC2
10K - 1/4W
VCC SI SI
2
PD0 (RXD/PCINT16) GND SO SO
1 3 3
PD1 (TXD/PCINT17) INT CS CS
2 4 4
RESET PD2 (INT0/PCINT18) SCK SCK
S1 5
C PD3 (PCINT19/OC2B/INT1) C
6 MCP2515 - MOD
PD4 (PCINT20/XCK/T0)
GND 11 GND
PD5 (PCINT21/OC0B/T1)
12
PD6 (PCINT22/OC0A/AIN0)
13
PD7 (PCINT23/AIN1)
14
PB0 (PCINT0/CLKO/ICP1)
15
PB1 (PCINT1/OC1A)
C5 16
PB2 (PCINT2/SS/OC1B) CS
17
XTAL1 PB3 (PCINT3/OC2A/MOSI) SI
18
22pF/50V PB4 (PCINT4/MISO) SO
8 19
GND PB5 (SCK/PCINT5) SCK
1
9
X1 PB6 (PCINT6/XTAL1/TOSC1) XTAL1
22 10
16MHz GND PB7 (PCINT7/XTAL2/TOSC2) XTAL2
2
C6 ATmega328P-AU
XTAL2
GND
22pF/50V Title
D D
GND
Size Number Revision
A4
Date: 04/12/2018 Sheet of
File: C:\Users\..\main.SchDoc Drawn By:
1 2 3 4
75
7 Apêndice B - Esquemático para o
1 2 3 4
CN1 D1 U1 LM7805 5V
1 3
2 IN OUT
1 GND
1N4007
10uF/25V
BR902V R1
10uF/25V
A C1 C2 A
2
470R - 1/4W
GND
LD1
GND WP7113ID 3.3V
IC1
1 3
VCC SCL SCL
2 4
GND SDA SDA
7 ADO XDA
5
GND 8 INT XCL
6
5V U2 LM7833 3.3V MPU-6050
3 1
IN OUT
GND
GND
10uF/25V
10uF/25V
C3 C4
2
B B
5V
U3
GND 7
VCC
20 23
21 24
25
PC2 (ADC2/PCINT10)
26
PC3 (ADC3/PCINT11)
5V 27
PC4 (ADC4/SDA/PCINT12) SDA
28
PC5 (ADC5/SCL/PCINT13) SCL
1 5V
IC2
10K - 1/4W
VCC SI SI
Acelerômetro
2
1 3 3
2 4 4
S1 5
6 MCP2515 - MOD
GND 11 GND
12
13
PD7 (PCINT23/AIN1)
14
PB0 (PCINT0/CLKO/ICP1)
15
PB1 (PCINT1/OC1A)
C5 16
17
18
8 19
1
9
22 10
2
C6 ATmega328P-AU
XTAL2
GND
22pF/50V Title
D D
GND
A4
1 2 3 4
77
8 Apêndice C - Esquemático para o
1 2 3 4
CN1 D1 U1 LM7805 5V
1 3
2 IN OUT
1 GND
1N4007
10uF/25V
BR902V R1
10uF/25V
A C1 C2 A
2
470R - 1/4W
GND
LD1
GND WP7113ID 5V
IC1
1 3 5V CN2
VCC RX RX
2 4
GND TX TX 1
5
SET 2
GND
3
HC-12-MOD
BMO-03-1-E
GND
GND
Módulo Transmissor
B B
5V
U2
7
VCC
20 23
21 24
25
PC2 (ADC2/PCINT10)
26
PC3 (ADC3/PCINT11)
5V 27
PC4 (ADC4/SDA/PCINT12)
28
PC5 (ADC5/SCL/PCINT13)
1 5V
IC2
10K - 1/4W
VCC SI SI
2
1 3 3
2 4 4
S1 5
6 MCP2515 - MOD
GND 11 GND
12
13
PD7 (PCINT23/AIN1)
14
PB0 (PCINT0/CLKO/ICP1) RX
15
PB1 (PCINT1/OC1A) TX
C3 16
17
18
8 19
1
9
22 10
2
C4 ATmega328P-AU
XTAL2
GND
22pF/50V Title
D D
GND
A4
1 2 3 4
79
9 Apêndice D - Esquemático para o
1 2 3 4
CN1 D1 U1 LM7805 5V
1 3
2 IN OUT
1 GND
1N4007
10uF/25V
BR902V R1
10uF/25V
A C1 C2 A
2
470R - 1/4W 5V
IC1
GND 1 3 5V CN2
VCC RX RX
2 4
GND TX TX 1
5
LD1
SET 2
WP7113ID 3
GND HC-12-MOD
BMO-03-1-E
GND
GND
GND
5V
U2
7
VCC
20 23
B AVCC PC0 (ADC0/PCINT8) B
21 24
25
PC2 (ADC2/PCINT10)
5V 26
PC3 (ADC3/PCINT11)
27
PC4 (ADC4/SDA/PCINT12)
28
R2 PC5 (ADC5/SCL/PCINT13)
Módulo Receptor
1
PC6 (RESET/PCINT14) RESET
10K - 1/4W
1 3 2
PD0 (RXD/PCINT16)
2 4 3 5V
RESET PD1 (TXD/PCINT17)
S1 4 IC2
PD2 (INT0/PCINT18)
5
PD3 (PCINT19/OC2B/INT1) VCC TX TX_USB
GND 6
PD4 (PCINT20/XCK/T0) GND RX RX_USB
11
PD5 (PCINT21/OC0B/T1) CTS DTR
12
13 USB/UART - MOD
PD7 (PCINT23/AIN1)
GND
14
C PB0 (PCINT0/CLKO/ICP1) C
15
PB1 (PCINT1/OC1A)
16
PB2 (PCINT2/SS/OC1B) TX_USB
17
PB3 (PCINT3/OC2A/MOSI) RX_USB
18
PB4 (PCINT4/MISO) TX
8 19
GND PB5 (SCK/PCINT5) RX
9
PB6 (PCINT6/XTAL1/TOSC1) XTAL1
22 10
GND PB7 (PCINT7/XTAL2/TOSC2) XTAL2
C3 ATmega328P-AU
XTAL1
GND
22pF/50V
1
X1
16MHz
2
C4
XTAL2
22pF/50V Title
D D
GND
A4
1 2 3 4
81
10 Anexo A - Amostra do Da-

tasheet do ATmega328/P
8-bit AVR Microcontrollers
ATmega328/P
DATASHEET COMPLETE
Introduction
® ®
The Atmel picoPower ATmega328/P is a low-power CMOS 8-bit
microcontroller based on the AVR® enhanced RISC architecture. By
executing powerful instructions in a single clock cycle, the ATmega328/P
achieves throughputs close to 1MIPS per MHz. This empowers system
designer to optimize the device for power consumption versus processing
speed.
Feature
High Performance, Low Power Atmel®AVR® 8-Bit Microcontroller Family
• Advanced RISC Architecture
– 131 Powerful Instructions
– Most Single Clock Cycle Execution
– 32 x 8 General Purpose Working Registers
– Fully Static Operation
– Up to 20 MIPS Throughput at 20MHz
– On-chip 2-cycle Multiplier
• High Endurance Non-volatile Memory Segments
– 32KBytes of In-System Self-Programmable Flash program
Memory
– 1KBytes EEPROM
– 2KBytes Internal SRAM
– Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
– Data Retention: 20 years at 85°C/100 years at 25°C(1)
– Optional Boot Code Section with Independent Lock Bits
• In-System Programming by On-chip Boot Program
• True Read-While-Write Operation
– Programming Lock for Software Security
• Atmel® QTouch® Library Support
– Capacitive Touch Buttons, Sliders and Wheels
– QTouch and QMatrix® Acquisition
– Up to 64 sense channels
Atmel-42735B-ATmega328/P_Datasheet_Complete-11/2016
83
11 Anexo B - Amostra do Da-

tasheet do MPU-6050
Document Number: PS-MPU-6000A-00

MPU-6000/MPU-6050 Product Specification Revision: 3.4
Release Date: 08/19/2013
7 Applications Information
7.1 Pin Out and Signal Description
MPU- MPU-
Pin Number Pin Name Pin Description
6000 6050
1 Y Y CLKIN Optional external reference clock input. Connect to GND if unused.
6 Y Y AUX_DA I2C master serial data, for connecting to external sensors
7 Y Y AUX_CL I2C Master serial clock, for connecting to external sensors
8 Y /CS SPI chip select (0=SPI mode)
8 Y VLOGIC Digital I/O supply voltage
9 Y AD0 / SDO I2C Slave Address LSB (AD0); SPI serial data output (SDO)
9 Y AD0 I2C Slave Address LSB (AD0)
10 Y Y REGOUT Regulator filter capacitor connection
11 Y Y FSYNC Frame synchronization digital input. Connect to GND if unused.
12 Y Y INT Interrupt digital output (totem pole or open-drain)
13 Y Y VDD Power supply voltage and Digital I/O supply voltage
18 Y Y GND Power supply ground
19, 21 Y Y RESV Reserved. Do not connect.
20 Y Y CPOUT Charge pump capacitor connection
22 Y Y RESV Reserved. Do not connect.
23 Y SCL / SCLK I2C serial clock (SCL); SPI serial clock (SCLK)
23 Y SCL I2C serial clock (SCL)
24 Y SDA / SDI I2C serial data (SDA); SPI serial data input (SDI)
24 Y SDA I2C serial data (SDA)
2, 3, 4, 5, 14,
Y Y NC Not internally connected. May be used for PCB trace routing.
15, 16, 17
Top View Top View

SCL/SCLK
SDA/SDI
CPOUT
CPOUT
RESV
RESV
RESV
RESV
RESV
RESV
SDA
SCL
24 23 22 21 20 19 24 23 22 21 20 19 +Z
CLKIN 1 18 GND CLKIN 1 18 GND

+Z +Y
NC 2 17 NC NC 2 17 NC
M
NC 3 16 NC NC 3 16 NC MP PU- +Y
MPU-6000 U- 600
MPU-6050 60
50 0
NC 4 15 NC NC 4 15 NC
NC 5 14 NC NC 5 14 NC
+X +X
AUX_DA 6 13 VDD AUX_DA 6 13 VDD
7 8 9 10 11 12 7 8 9 10 11 12
AUX_CL
/CS
AD0/SDO
REGOUT
FSYNC
INT
AUX_CL
VLOGIC
AD0
REGOUT
FSYNC
INT
QFN Package QFN Package Orientation of Axes of Sensitivity and

24-pin, 4mm x 4mm x 0.9mm 24-pin, 4mm x 4mm x 0.9mm Polarity of Rotation
21 of 52
85
12 Anexo C - Amostra do Da-

tasheet do HC-12
HC-12 Wireless Serial Port Communication Module

User Manual V1.18
Product Application
 Wireless sensor
 Community building security
 Robot wireless control
 Industrial remote control and telemetering
 Automatic data acquisition
 Container information management
 POS system
 Wireless acquisition of gas meter data
 Vehicle keyless entry system
 PC wireless networking
……
Document: 2012/10
87
13 Anexo D - Amostra do Da-

tasheet do MCP2515
MCP2515
Stand-Alone CAN Controller with SPI Interface
Features Description
• Implements CAN V2.0B at 1 Mb/s: Microchip Technology’s MCP2515 is a stand-alone
Controller Area Network (CAN) controller that imple-
- 0 to 8-byte length in the data field
ments the CAN specification, Version 2.0B. It is capable
- Standard and extended data and remote of transmitting and receiving both standard and
frames extended data and remote frames. The MCP2515 has
• Receive Buffers, Masks and Filters: two acceptance masks and six acceptance filters that
- Two receive buffers with prioritized message are used to filter out unwanted messages, thereby
storage reducing the host MCU’s overhead. The MCP2515
- Six 29-bit filters interfaces with microcontrollers (MCUs) via an industry
- Two 29-bit masks standard Serial Peripheral Interface (SPI).
• Data Byte Filtering on the First Two Data Bytes Package Types
(applies to standard data frames) 18-Lead PDIP/SOIC
• Three Transmit Buffers with Prioritization and
Abort Features TXCAN 1 18 VDD
• High-Speed SPI Interface (10 MHz): RXCAN 2 17 RESET
- SPI modes 0,0 and 1,1 CLKOUT/SOF 3 16 CS
• One-Shot mode Ensures Message Transmission TX0RTS 4 MCP2515 15 SO
is Attempted Only One Time TX1RTS 5 14 SI
• Clock Out Pin with Programmable Prescaler: TX2RTS 6 13 SCK
- Can be used as a clock source for other OSC2 7 12 INT
device(s) OSC1 8 11 RX0BF
• Start-of-Frame (SOF) Signal is Available for VSS 9 10 RX1BF
Monitoring the SOF Signal:
- Can be used for time slot-based protocols 20-Lead TSSOP
and/or bus diagnostics to detect early bus TXCAN 1 20 VDD
degradation RXCAN 2 19 RESET
CLKOUT/SOF 3 18 CS
• Interrupt Output Pin with Selectable Enables
MCP2515
TX0RTS 4 17 SO
• Buffer Full Output Pins Configurable as: TX1RTS 5 16 SI
- Interrupt output for each receive buffer NC 6 15 NC
TX2RTS 7 14 SCK
- General purpose output 8 13
OSC2 INT
• Request-to-Send (RTS) Input Pins Individually OSC1 9 12 RX0BF
Configurable as: VSS 10 11 RX1BF
- Control pins to request transmission for each
RXCAN
20-Lead QFN*
RESET
TXCAN
transmit buffer
VDD
CS
- General purpose inputs

• Low-Power CMOS Technology: 20 19 18 17 16
- Operates from 2.7V-5.5V CLKOUT 1 15 SO
- 5 mA active current (typical) TX0RTS 2 14 SI

EP
- 1 µA standby current (typical) (Sleep mode) TX1RTS 3 21 13 NC
• Temperature Ranges Supported: NC 4 12 SCK
- Industrial (I): -40°C to +85°C TX2RTS 5 11 INT
6 7 8 9 10
- Extended (E): -40°C to +125°C
RX1BF
RX0BF
OSC2
OSC1
GND
* Includes Exposed Thermal Pad (EP); see Table 1-1.
 2003-2016 Microchip Technology Inc. DS20001801H-page 1

89
14 Anexo E - Amostra do Da-

tasheet do MLX-90614
MLX90614 family
Single and Dual Zone
Infra Red Thermometer in TO-39
Features and Benefits Applications Examples

Small size, low cost High precision non-contact temperature
Easy to integrate measurements
Factory calibrated in wide temperature range: Thermal Comfort sensor for Mobile Air
-40…+125˚C for sensor temperature and Conditioning control system
-70…+380˚C for object temperature. Temperature sensing element for residential,
High accuracy of 0.5°C in a wide temperature commercial and industrial building air
range (0…+50°C for both Ta and To) conditioning
High (medical) accuracy calibration Windshield defogging
Measurement resolution of 0.02°C Automotive blind angle detection
Single and dual zone versions Industrial temperature control of moving parts
SMBus compatible digital interface Temperature control in printers and copiers
Customizable PWM output for continuous Home appliances with temperature control
reading Healthcare
Available in 3V and 5V versions Livestock monitoring
Simple adaptation for 8…16V applications Movement detection
Sleep mode for reduced power consumption Multiple zone temperature control – up to 127
Different package options for applications and sensors can be read via common 2 wires
measurements versatility Thermal relay / alert
Automotive grade Body temperature measurement
Ordering Information
Part No. Temperature Package - Option Code Standard Packing
Code Code -X X X part form
MLX90614 E (-40°C...85°C) SF (TO-39) (1) (2) (3) -000 -TU
K (-40°C…125°C)
(1) Supply Voltage/ Accuracy (2) Number of thermopiles: (3) Package options:
A - 5V A – single zone A – Standard package
B - 3V B – dual zone B – Reserved
C - Reserved C – gradient compensated* C – 35° FOV
D - 3V medical accuracy D/E – Reserved
F – 10° FOV
G – Reserved
H – 12° FOV (refractive lens)
I – 5° FOV
Example:
MLX90614ESF-BAA-000-TU * : See page 2
1 Functional diagram 2 General Description

MLX90614Axx: Vdd=4.5...5.5V The MLX90614 is an Infra Red thermometer for non
J1 1 MLX90614 contact temperature measurements. Both the IR sensitive
SCL U1
SCL Vz thermopile detector chip and the signal conditioning ASSP
SDA
PWM Vss 4 are integrated in the same TO-39 can.
2 SDA
Thanks to its low noise amplifier, 17-bit ADC and
Vdd Vdd
C1 powerful DSP unit, a high accuracy and resolution of the
3
GND thermometer is achieved.
CON1 0.1uF The thermometer comes factory calibrated with a digital
C1 value and type may differ
in different applications
PWM and SMBus (System Management Bus) output.
for optimum EMC As a standard, the 10-bit PWM is configured to
continuously transmit the measured temperature in range
MLX90614 connection to SMBus of -20…120˚C, with an output resolution of 0.14˚C.
Figure 1: Typical application schematics The factory default POR setting is SMBus.
3901090614 Page 1 of 52 Data Sheet

Rev 009 June 29, 2015

TCC2018 TomyMoreiraSantos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC2018 TomyMoreiraSantos

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Estadual de Londrina

Centro de Tecnologia e Urbanismo

Tomy Moreira dos Santos

Protótipo de um Sistema de Telemetria

Tomy Moreira dos Santos

Protótipo de um Sistema de Telemetria Veicular de

Trabalho de Conclusão de Curso orientado pelo Prof. Dr. Ernesto

Orientador: Prof. Dr. Ernesto Fernando Ferreyra Ramirez

Tomy Moreira dos Santos

Protótipo de um Sistema de Telemetria

Trabalho de Conclusão de Curso apresentado ao Curso de

Prof. Dr. Ernesto Fernando Ferreyra

Prof. Dr. Francisco Granziera Junior

Prof. Dr. Aziz Elias Demian Junior

Londrina, 17 de dezembro de 2018

Palavras-Chave: 1.Telemetria. 2.Redes CAN. 3.Monitoramento. 4.Arduino. 5. Espor-

Key-words: 1.Telemetry 2.CAN Network. 3.Monitoring. 4. Arduino. 5. Motor Sport

Figura 2.1 – Elementos compositores um barramento CAN. . . . . . . . . . . . . . . 28

Tabela 1 – Custo de Fabricação do Protótipo . . . . . . . . . . . . . . . . . . . . . 67

ASCII American Standard Code for Information Interchange

6 APÊNDICE A - ESQUEMÁTICO - MÓDULO DE TEMPE-

7 APÊNDICE B - ESQUEMÁTICO PARA O ACELERÔMETRO 75

8 APÊNDICE C - ESQUEMÁTICO PARA O MÓDULO TRANS-

9 APÊNDICE D - ESQUEMÁTICO PARA O MÓDULO RE-

10 ANEXO A - AMOSTRA DO DATASHEET DO ATMEGA328/P 81

11 ANEXO B - AMOSTRA DO DATASHEET DO MPU-6050 . 83

12 ANEXO C - AMOSTRA DO DATASHEET DO HC-12 . . . 85

13 ANEXO D - AMOSTRA DO DATASHEET DO MCP2515 . 87

14 ANEXO E - AMOSTRA DO DATASHEET DO MLX-90614 89

A história da humanidade tem grande parte dedicada ao desenvolvimento de formas

tremamente inóspitos, como medidas de temperatura em vulcões, medidas de pressão

1.2 Objetivos Gerais

1.3 Objetivos Específicos

• Desenvolvimento de um módulo acelerômetro com comunicação CAN.

• Desenvolvimento de um módulo central de processamento e transmissão de dados.

• Desenvolvimento de um módulo receptor de dados.

• Desenvolvimento de um sistema supervisório.

1.4 Organização do Trabalho

• Fundamentação Teórica: São apresentados todos os conceitos relacionados ao tra-

• Desenvolvimento: Apresenta a construção do projeto dividida em etapas, expondo

• Resultados: Apresenta os resultados obtidos. São apresentados todos os dispositivos

• Discussões e Conclusões: Apresenta discussões sobre o desempenho do sistema,

• Apêndices e Anexos: São apresentados os códigos desenvolvidos durante o trabalho

2.1 Esportes à motor

2.1.1 Sensoriamento nos esportes à motor

piloto às adversidades que ele irá defrontar durante uma competição.

por exemplo sistemas implementados em usinas hidroelétricas e alguns meios indus-

Como citado anteriormente, um exemplo de ambiente onde se encontra sistemas de

2.2.1 Telemetria nos Esportes à motor

2.3 Sistemas Supervisórios

• Operação remota do sistema: Os sistemas supervisórios possibilitam uma tomada

• Análise de tendências: Através do recebimento de um pacote de dados, pode-se

• Administração de alertas do sistema: O operador pode ter a visualização de alertas

2.4 Eletrônica Automotiva

automático dos limpadores de para-brisa, controles de tração e estabilidade, climatizadores

2.4.1 Rede CAN

• Todos os dispositivos presentes na rede monitoram constantemente a mesma quando

• Durante um período de estado ocioso do barramento, qualquer dispositivo tem as

2.4.1.1 Barramento CAN

O barramento CAN, como em alguns outros barramentos, necessita de parâmetros

Figura 2.1 – Elementos compositores um barramento CAN.

Fonte: Introduction to the Controller Area Network (CAN) - Texas Instruments.

que os dados trafegam dentro do barramento. Em outros tipos de comunicação normal-