UNIVERSIDADE DE PASSO FUNDO FACULDADE DE ENGENHARIA E ARQUITETURA

ENGENHARIA ELÉTRICA

SISTEMA DE TELEMETRIA AUTOMOTIVA PARA BAJA SAE UPF

Disciplina: Projeto de Graduação

Acadêmico: Kristofer Becker Kochhann

Professor: Carlos Allan Caballero Petersen

Passo Fundo, julho de 2009.

2

Kristofer Becker Kochhann

Sistema de Telemetria Automotiva para Baja SAE UPF

Trabalho de conclusão apresentado ao curso de Engenharia Elétrica, da Faculdade de Engenharia e Arquitetura, da Universidade de Passo Fundo, como requisito para a obtenção do título de Engenheiro Eletricista, sob orientação do Professor Dr. Carlos Allan Caballero Petersen.

Passo Fundo

2009

3

Kristofer Becker Kochhann

Sistema de Telemetria Automotiva para Baja SAE UPF

Banca Examinadora:

Professor Dr. Carlos Allan Caballero Petersen – UPF – Orientador

Professor MSc. Adriano Luiz Toazza – UPF – Examinador

Professor Dr. Mikhail Polonski – UPF - Examinador

Passo Fundo

2009

4

Dedico a realização deste projeto a meus

pais, Rainoldo e Marga, por me darem

condições de realizar um curso de nível

superior, assim como seu apoio e

compreensão durante esses últimos cinco

anos e meio em especial. Dedico também

ao professor Carlos A. Cabellero P., não

só pelos ensinamentos durante todo o

curso, mas também por acreditar neste

projeto.

5

Agradecimentos

Agradeço a todos que de uma maneira ou outra contribuíram para minha formação

acadêmica e humana. Aos familiares e amigos, pelo apoio e compreensão, por terem me

incentivado e me ajudado nos momentos mais difíceis. Aos professores que me

transmitiram conhecimentos teóricos e práticos para minha formação acadêmica. Ao

professor Carlos, orientador e colaborador deste trabalho por ter acreditado na minha

capacidade. A meus colegas da Elomed pelo apoio e incentivo, em especial aos amigos

Diego A. Silveira, Alisson Ianiski, Tiago Ianiski, Luís Eduardo Spalding, Cassiano Groth,

Eduardo Tende, Cristiano Gradaschi, Cristiano Bouvié, Ismael Zanetti e Adenílson Risi.

Um agradecimento especial aos colegas Cristian Reginatto, Helder Marcon, Thales

Marafon e Marcelo Witzgall, com quem compartilhei boa parte desta caminhada, entre

tantos outros com quem tive o privilégio de conviver neste período.

6

RESUMO

Todo esporte automotor é caracterizado pelo constante desenvolvimento, sendo este

visando desempenho ou durabilidade. Como em qualquer sistema, em um automotor é

necessário ter informação sobre as deficiências existentes no projeto, de modo a melhorá-

lo. Partindo desse princípio, muitas equipes de diferentes categorias se utilizam de sensores

elétricos, como sensores de temperatura, pressão, força gravitacional, carga, entre outros.

O presente projeto consiste na aquisição de dados através de determinados sensores

e o envio destes dados para a equipe de box analisá-los. Para melhor avaliação das

condições do carro Baja SAE, no qual deve ser instalado o sistema. As medições e a

transmissão devem ocorrer em espaço de tempo muito pequeno, de modo a caracterizar

este sistema de telemetria como online, ou ‘em tempo real’.

Partindo da condição do carro não ter velocímetro e conta-giros, essas informações

básicas foram adicionadas. Também foi implementada medição de força-G em três eixos,

temperatura do motor e curso de suspensão¹.

A parte de comunicação é feita através de módulos RF, padrão XBee-PRO/IEEE

802.15.4 similar ao ZigBee.

Para interface entre sensores e a transmissão dados, além da adequação destes, é

utilizado a placa de desenvolvimento Arduino Duemilanove, que conta com

microprocessador ATmega168 como principal componente.

Palavras chaves: telemetria, Baja SAE, Arduino Duemilanove, sensores,

comunicação RF, XBee/ZigBee, temperatura, suspensão, força G.

¹ Considerações importantes no item 2.1.

7

LISTA DE FIGURAS

FIGURA 1.1 - ENGENHEIROS ANALISANDO INFORMAÇÕES DO CARRO. .............................................................. 18 FIGURA 1.2 - ESPECTRO DE FREQÜÊNCIA DEMONSTRANDO 16 CANAIS SELECIONÁVEIS.................................... 19 FIGURA 1.3 - ZIGBEE, MESH NETWORKING ....................................................................................................... 23 FIGURA 1.4 - EXEMPLO DE COMANDO AT. ....................................................................................................... 24 FIGURA 1.5 - COMUNICAÇÃO PONTO A MULTIPONTO. ....................................................................................... 25 FIGURA 1.6 - CONFIGURAÇÃO PONTO A PONTO................................................................................................. 25 FIGURA 1.7 - ARDUINO DUEMILANOVE. ........................................................................................................... 27 FIGURA 1.8 - BAJA SAE - UPF ......................................................................................................................... 29 FIGURA 2.1 - DIAGRAMA DE BLOCOS DO SISTEMA DE TELEMETRIA. ................................................................. 31 FIGURA 2.2 – FUNCIONAMENTO DOS SENSORES LVDT . .................................................................................. 33 FIGURA 2.3 – CIRCUITO DO ACELERÔMETRO TRI-AXIAL. .................................................................................. 35 FIGURA 2.4 - CONFIGURAÇÃO DE SENSOR CENTÍGRADO BÁSICO, LM35........................................................... 36 FIGURA 2.5 - REPRESENTAÇÃO DA CHAVE HALL. .............................................................................................. 37 FIGURA 2.6 - CIRCUITO PARA ADEQUAR O SINAL AO ARDUINO. ....................................................................... 38 FIGURA 2.7 - LIGAÇÃO ENTRE ARDUINO E XBEE ............................................................................................. 41 FIGURA 2.8 – LIGAÇÕES ENTRE ARDUINO E OUTROS ELEMENTOS DO SISTEMA................................................. 42 FIGURA 2.9 – FLUXOGRAMA SIMPLIFICADO DO FIRMWARE. .............................................................................. 44 FIGURA 2.10 - DSSS E RUÍDO. .......................................................................................................................... 46 FIGURA 2.11 – FONTE DE ALIMENTAÇÃO. ......................................................................................................... 49 FIGURA 2.12 – FLUXOGRAMA DAS VERIFICAÇÕES DE VELOCIDADE. ................................................................ 59 FIGURA 2.13 – FLUXOGRAMA DAS VERIFICAÇÕES REFERENTES A RPM. ............................................................ 60 FIGURA 2.14 - PLACA PARA CONEXÃO ENTRE XBEE-PC E NOTEBOOK. ............................................................. 61 FIGURA 2.15 - INFORMAÇÃO CON USBEE ...................................................................................................... 61

8

LISTA DE TABELAS

TABELA 1.1 - CARACTERÍSTICAS DOS MÓDULOS XBEE E XBEE-PRO. ..................................20 TABELA 1.2 - COMUNICAÇÃO WIRELESS. ..............................................................................21 TABELA 1.3 – CAPACIDADE DE ARMAZENAMENTO ATMEGA................................................28 TABELA 2.1 - CONFIGURAÇÕES XBEE-ARDUINO. .................................................................48 TABELA 2.2 - CONFIGURAÇÕES XBEE-PC. ...........................................................................48

9

LISTA DE ABREVIATURAS

Ω – Ohm;

°C – graus Celsius;

A – Ampère;

A/D – analógico/digital, conversor;

AES – padrão de criptografia avançado;

AMPOP – Amplificador Operacional;

AREF – tensão analógica de referência;

AVR – arquitetura modificada da Harvard, 8 bits RISC;

Baja SAE – competição organizada pela Sociedade de Engenheiros de Mobilidade;

bit – dígito binário;

BPSK – chaveamento binário por mudança de fase, técnica de modulação;

byte – conjunto de 8 bits;

C/C++ - linguagens de programação, alto nível;

CI – Circuito Integrado;

COM – interface de comunicação com o computador;

CSMA-CA – técnica anti-ruído IEEE 802.15.4;

DC – Tensão Contínua;

dBmW – decibel referido a miliwatt;

DSSS – seqüência direta de espectro espalhado, técnica de modulação;

EEPROM – memória programável/apagável eletricamente somente de leitura;

FIA – Federação Internacional de Automobilismo;

Flash – memória computacional não-volátil, escrita e apagada eletricamente.

Força G – força gravitacional, aceleração;

GHz – giga Hertz, bilhão de Hertz;

GND – terra, referencial;

GPS – sistema de posicionamento global;

GTS – garantir espaço de tempo;

Hertz – freqüência, ciclos por segundo;

10

I/O – entrada/saída;

I²C – barramento “multi mestre” serial, desenvolvido pela Philips;

ISM – industrial, cientifica, médica;

IEEE – Instituto de Engenheiros Eletricistas e Eletrônicos;

kilo – mil;

kbps – kilo bit por segundo;

kg – kilograma;

LAN – Local Acces Network, rede de trabalho com acesso local;

LED – diodo emissor de luz;

LVDT - linear variable differential transformer, sensor de deslocamento linear;

m – metro;

MAC – Controle de acesso médio;

MAN – Metropolitan Access Network, rede de trabalho de acesso metropolitano;

MIP – milhões de instruções por segundo;

ηF – nano farad (1E-9);

O-QPSK – chaveamento em quadratura por mudança de fase com offset;

PAN – rede de trabalho de área pessoal;

PHY – physical layer specifications, especificações da camada física;

PWM – Modulação por Largura de Pulso;

RAM – memória de acesso aleatório;

RF – radiofreqüência;

RPM – rotação por minuto;

RS232 – padrão para comunicação serial entre um terminal e um comunicador;

Rx – recepção, receptor;

SNR – relação sinal/ruído;

SPI – comunicação serial síncrona, desenvolvida pela Motorola;

T/C – temporizador/contador;

TWI – Interface de 2 fios, I²C “genérica”;

Tx – transmissão, transmissor;

USART – Transmissor/Receptor universal, síncrono e assíncrono;

USB – barramento serial universal;

VBE – tensão entre base e emissor de um BJT;

VCC – tensão DC positiva de alimentação;

W – Watt;

11

SUMÁRIO

INTRODUÇÃO ...................................................................................................................13 1. Fundamentação Teórica...................................................................................................14

1.1. Telemetria na História ..............................................................................................14 1.2. Telemetria em diferentes situações...........................................................................14

1.2.1. Agricultura .........................................................................................................15 1.2.2. Gerenciamento de Água.....................................................................................15 1.2.3. Sistemas de Defesa, Espaciais e de Exploração de Recursos ............................15 1.2.4. Medicina ............................................................................................................16 1.2.5. Estudo e controle da vida selvagem...................................................................16 1.2.6. Telemetria em Competições Automobilísticas ..................................................16

1.2.6.1. Formula1 equipe AT&T WilliamsF1 .........................................................17 1.3. Telemetria com cabos ...............................................................................................18 1.4. Módulo XBee............................................................................................................19

1.4.1. Padrão IEEE 802.15.4........................................................................................20 1.4.2. ZigBee................................................................................................................22 1.4.3. Comandos AT....................................................................................................24

1.5. Placa Arduino Duemilanove.....................................................................................26 1.5.1. Microcontrolador ...................................................................................................28 1.6. Baja SAE...................................................................................................................29

2. Sistema Desenvolvido......................................................................................................31 2.1. Sensores ....................................................................................................................32

2.1.1. Curso de Suspensão ...........................................................................................33 2.1.2. Força G ..............................................................................................................34 2.1.3. Temperatura do Motor .......................................................................................36 2.1.4. Velocidade .........................................................................................................37 2.1.5. Freqüência do motor - rpm ................................................................................38

2.2. Arduino Duemilanove...............................................................................................39 2.2.1. Sensores .............................................................................................................39

2.2.1.1. Nível Analógico de Tensão.........................................................................39 2.2.1.2. Contagem de Pulsos....................................................................................40

2.2.2. Interface com XBee ...........................................................................................41 2.2.3 Função Geral.......................................................................................................42 2.2.4 Firmware ............................................................................................................43

2.3. XBee - Canal.............................................................................................................45 2.3.1. Comunicação entre XBee’s ...............................................................................45

2.3.1.1. Imunidade a Ruído......................................................................................45 2.3.1.2. Imunidade a Interferência ...........................................................................46 2.3.1.3. Baixo Consumo...........................................................................................47 2.3.1.4. Potência de Transmissão e Sensibilidade de Recepção ..............................48

2.3.2. Comandos AT, configurações............................................................................48 2.4. Fonte de Alimentação ...............................................................................................49 2.5. Intervalos de Tempo, Freqüências e Taxas...............................................................50

12

2.5.1. Conversão A/D ..................................................................................................51 2.5.2. Leitura por Pulsos ..............................................................................................51

2.5.2.1. Rotações do Motor......................................................................................52 2.5.2.2. Velocidade ..................................................................................................53

2.5.3. Envio dos Dados para XBee-Arduino ...............................................................53 2.5.4. Envio dos Dados do XBee-Arduino para o XBee-PC .......................................54 2.5.5. Envio dos Dados do XBee para PC ...................................................................54 2.5.6. Atrasos ...............................................................................................................54

2.5.6.1 Período de Um Ciclo de Transmissão..........................................................55 2.5.6.2 Delay geral do Ciclo de Transmissão ..........................................................56

2.6. Firmware ..................................................................................................................57 2.6.1. Velocidade .........................................................................................................57 2.6.1. RPM...................................................................................................................59

2.7. Computador ..............................................................................................................60 2.7.1. Conexão XBee - PC...........................................................................................60 2.7.2. Software .............................................................................................................62

CONSIDERAÇÕES FINAIS ..............................................................................................65 REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................66 ANEXO A – Esquema elétrico do Arduino Duemilanove ..................................................68 ANEXO B – Firmware utilizado no Arduino Duemilanove ...............................................69 ANEXO C – Teste A/D do Arduino....................................................................................72 ANEXO D – Teste Interrupção Externa do Arduino...........................................................73 ANEXO E – Teste do Modo Captura do Arduino...............................................................74

13

INTRODUÇÃO

Sistema de telemetria pode ser considerado um Sistema de Aquisição de Dados

(SAD), no qual os dados são enviados a um local remoto, para serem vistos/analisados a

distância. São utilizados nas mais diversas situações, desde monitoramento de temperatura

nas proximidades de um vulcão, até nível de oxigênio em uma estação espacial.

No presente caso, uma sub-área que por si só poderia ser considerada uma ciência,

a telemetria automotiva. Estando presente na área industrial, porém, o destaque fica para as

competições.

Presente em praticamente todas as categorias automobilísticas, só não sendo

utilizado em categorias onde não representam vantagens, ou tendo alto custo/benefício.

Nas categorias de alto nível, todas as equipes utilizam algum tipo de sistema de telemetria,

de modo geral complexos, com alto número de sensores, de alta precisão e qualidade; e em

tempo real.

Os principais benefícios decorrem de poder prever defeitos em peças e

equipamentos, tanto na fase de projeto quanto no decorrer de corridas. Além disso, saber as

condições sob qual determinado componente está atuando pode ser crucial. Por exemplo:

os pneus de um Formula1 têm melhor rendimento quando sua temperatura está entre 80 e

110°C.

Tendo esse conhecimento, desenvolveu-se um sistema de telemetria para o

automóvel Baja SAE da UPF, equipe ‘Mas Baja Tchê!’, utilizado em competições

universitárias em todo o país. Para realização deste projeto, foi utilizada a placa micro-

processada Arduino, com objetivo de adquirir mais conhecimento a respeito de seu

funcionamento.

14

1. Fundamentação Teórica

1.1. Telemetria na História

Telemetria é definida como um processo de comunicação altamente automatizado, no

qual medições são feitas e coletadas em um ponto remoto ou inacessível e então

transmitidas a um receptor para monitoramento. [1]

O primeiro sistema de telemetria não funcionava de modo contínuo, sendo usado para

monitorar distribuição de energia elétrica. No primeiro sistema desse tipo, instalado em

Chicago em 1912, linhas telefônicas eram usadas para transmitir dados referentes à

operação de usinas geradoras de energia elétrica a um escritório central. Desde então,

telemetria se espalhou para outros campos, cada qual resultando em melhorias e

modificações para se adequar a seu propósito. [1]

Considerando que telemetria é um termo usado para descrever um processo

generalizado que pode envolver diferentes tecnologias, vários inventores podem ser citados

em seu complexo desenvolvimento. [1]

Na área aeroespacial, em 1930, teve início com a ‘rádio sonda’, um aparelho que

media automaticamente temperatura, pressão barométrica e umidade de um balão no

espaço e enviava os dados para a Terra usando um sinal de rádio. Para foguetes e satélites,

começou em 1957, com o lançamento do satélite Soviético, Sputnik. O desenvolvimento

tecnológico da telemetria aeroespacial chegou à indústria, em diferentes operações; i.e.

testando motores de combustão interna, monitorando turbinas a vapor em operação ou

esteiras transportadoras em fornos industriais. [1]

Em 1960, o princípio pergunta-resposta foi desenvolvido. Sendo este, um processo

altamente automatizado no qual o transmissor, no local das medições, só transmite os

dados após receber um sinal. Este princípio é utilizado hoje em inúmeras aplicações. [1]

1.2. Telemetria em diferentes situações

Neste sub-item serão abordadas, de forma breve, algumas das diferentes aplicações

em que é utilizado telemetria.

15

1.2.1. Agricultura

A maioria das atividades relacionadas ao cultivo sadio de agro produtos está ligada

à disponibilidade de água. Assim sendo, estações metereológicas sem fio têm grande

importância em irrigação de precisão, assim como no papel de previsão de doenças,

possibilitando que o agricultor não desperdice água ou defensivos agrícolas. [2]

Não é necessária transmissão de dados em tempo real, uma vez que as mudanças,

ainda que importantes, levam tempo para acontecer. Intervalo de 15 minutos entre as

medições fornece dados suficientes para as decisões.

Sensores utilizados: temperatura do ar, umidade relativa, molhamento solar,

radiação solar, velocidade do vento e umidade do solo.

1.2.2. Gerenciamento de Água

A telemetria se tornou indispensável para determinar a qualidade da água, assim

como para verificar as forças exercidas por grandes quantidades de água sobre

determinadas estruturas, como barragens. As principais aplicações incluem leitura

automática de distância, monitoramento subterrâneo de água, detecção de vazamentos em

distribuição por tubos e vigilância sobre funcionamento de equipamentos. [2]

Nesse caso, o envio dos dados em tempo real ajuda a tomar decisões rápidas quanto

às ocorrências. [2]

1.2.3. Sistemas de Defesa, Espaciais e de Exploração de Recursos

Telemetria é uma tecnologia que habilita a existência de sistemas grandes e

complexos como mísseis, espaçonaves, extração de petróleo e usinas químicas pois

possibilita monitoramento automático, alertas e gravação de dados necessários para

16

operações seguras e eficientes. Agências espaciais como a NASA se utilizam de sistemas

de telemetria/telecomando para coletar dados. [2]

A transmissão de dados à distância se mostra vital na fase de desenvolvimento de

mísseis, satélites e aeronaves, pois a cada teste existe o risco de o protótipo ser destruído.

Os engenheiros precisam de parâmetros críticos do sistema para analisar e melhorar a

performance do mesmo. Sem a telemetria esses dados não estariam à disposição. [2]

1.2.4. Medicina

A telemetria também é usada em pacientes que estão sobre risco de atividade

cardíaca anormal, normalmente com uma unidade de monitoramento da coronária, nesse

caso sendo chamada de biotelemetria. Esse tipo de paciente é vestido com aparelhos de

medição, gravação e transmissão. A informação adquirida normalmente é útil para

diagnosticar o paciente. Uma função de alerta pode avisar enfermeiras sobre estado crítico

de um paciente dentro de um hospital ou clínica. [2]

1.2.5. Estudo e controle da vida selvagem

Recentemente a telemetria foi adotada para estudar animais selvagens, sendo

particularmente útil para monitorar espécies ameaçadas de extinção em nível individual.

Animais sob estudo podem ser estudados com instrumentos que variam de simples

etiquetas até câmeras, aparelhos GPS e transmissores para identificar a posição e outras

informações básicas para cientistas e vigilantes. [2]

1.2.6. Telemetria em Competições Automobilísticas

A telemetria tem sido um fator decisivo no esporte-motor moderno. Os engenheiros

conseguem interpretar a vasta quantidade de dados coletados durante testes ou corridas,

usando essa informação para adaptar o carro para ótimo desempenho. Sistemas utilizados

17

em algumas categorias, como a Formula1, avançaram ao ponto de poder calcular o tempo

de volta potencial do carro, sendo esta a meta do piloto. [2]

Alguns exemplos de medições úteis em um carro de corrida incluem aceleração

(força G) tri-axial, leitura de temperatura em diferentes pontos do carro, velocidade nas

rodas e curso de suspensão. Na Formula1, as ações do piloto também são medidas,

objetivando melhora no desempenho do piloto, assim como, em caso de um acidente, a

FIA determinar se houve ou não algum erro por parte do piloto. [2]

Apesar de não ser legal na Formula1, existem categorias em que é permitida a

telemetria de “ida e vinda”. Telemetria de ida e vinda sugere que engenheiros tem a

possibilidade de atualizar calibrações no carro em tempo real, possivelmente enquanto o

carro está na pista. Na Formula1, telemetria de “ida e vinda” apareceu no começo da

década de 90 com a TAG electronics, consistindo simplesmente de uma mensagem enviada

para o volante, a qual a equipe podia mudar a qualquer momento. Seu desenvolvimento

continuou até maio de 2001, quando foi pela primeira vez permitida nos carros. Em 2002

as equipes conseguiam mudar o mapeamento do motor e desativar sensores específicos do

motor diretamente do box enquanto o carro estava na pista. Porém, na temporada de 2003 a

FIA baniu este tipo de telemetria. Contudo, a telemetria de “ida e vinda” continua existindo

em outras categorias em que seu uso é permitido, assim como em alguns carros de rua. [2]

1.2.6.1. Formula1 equipe AT&T WilliamsF1

A telemetria se tornou tão importante na Formula1 a ponto de hoje, todas as

equipes terem patrocinadores/suporte de alguma grande empresa da área de eletrônica,

informática e/ou telecomunicações. No caso da tradicional equipe Williams, uma empresa

de telecomunicações tem tanta influência e interesse na categoria, que seu nome foi

incorporado à equipe. Além disso, uma empresa do setor de informática auxilia a Williams

no quesito telemetria, como mostra a imagem na Figura 1.1.

18

Figura 1.1 - Engenheiros analisando informações do carro.

Esses poderosos sistemas provêm um fluxo constante de informação, a partir do

qual a equipe pode fazer ajustes importantes e melhorias mecânicas para maximizar a

performance do carro e do piloto. [3]

O chefe de projetos da equipe, Gavin Fisher confirma a importância de telemetria

na categoria: "Os dados representam o sangue da vida do projeto. Trata-se da maneira mais

direta para se determinar o comportamento do carro em diferentes situações. A analise

desses dados é utilizada para corroborar com modelos teóricos, estimulando seguir certa

direção em novos projetos. Um carro novo sempre é produto de desenvolver o bom e

erradicar o ruim do carro antigo. Os dados da telemetria têm papel vital nessa função.". [3]

A gama de sensores espalhados pelo carro é grande, os dados adquiridos vão desde

eficiência aerodinâmica até ações do piloto, como a posição do pedal do acelerador. [3]

Os números são impressionantes. Segundo informações de 2002, a cada segundo

são feitas 150.000 medições pelo computador central do carro, de aproximadamente 200

sensores espalhados pelo carro. Esses dados são transmitidos com segurança, usando

tecnologia de microondas. [3]

As transmissões são feitas a cada 2ms, através de 2000 canais.

1.3. Telemetria com cabos

Originária do idioma grego, a palavra telemetria (medição à distância) sugere a

utilização de sistemas sem fio (wireless) para a transmissão de medições.

19

Todavia, não existe a restrição de um sistema que se utilize de cabos ser chamado

de telemetria. Como já mencionado, os primeiros sistemas de telemetria se utilizavam de

linhas telefônicas para envio de informações.

Atualmente, a melhor opção para este tipo de telemetria é a utilização de cabos de

fibra ótica, que consiste basicamente de uma guia para sinais de luz. É uma tecnologia que

entre suas principais vantagens consta a imunidade contra interferência eletro-magnética.

1.4. Módulo XBee

Os módulos de comunicação via radiofreqüência (RF) XBee, fabricados pela

MAXTREAM, são módulos que incluem todo hardware e lógica necessários para

implementar uma rede ZigBee. [4]

Basicamente, existem dois tipos de módulos, o XBee e o XBee-PRO, os quais se

diferenciam principalmente pela potência de emissão e sensibilidade de recepção, logo, o

alcance da comunicação é diferente.

O modelo padrão dispõe de 16 canais de transmissão, selecionáveis por software,

com suporte para 65536 endereços por canal e encriptação 128-bits AES. Devido à maior

potência do XBee-PRO, esse modelo tem opção por 12 canais de transmissão como

resultado do espalhamento de espectro.

A maioria dos módulos XBee opera na faixa de 2,4 GHz, como demonstra a Figura

1.2.

Figura 1.2 - Espectro de freqüência demonstrando 16 canais selecionáveis.

20

Os módulos XBee e XBee-PRO apresentam a mesma pinagem, assim como as

mesmas funções de configuração. A Tabela 1.1 faz breve comparação entre os dois

modelos.

Tabela 1.1 - Características dos módulos XBee e Xbee-PRO.

Existem dois protocolos de comunicação que podem ser utilizados por um XBee,

são eles o padrão IEEE 802.15.4 e o ZigBee.

1.4.1. Padrão IEEE 802.15.4

O IEEE 802.15.4 é um protocolo base, um padrão para o estabelecimento de

comunicação wireless desenvolvido pelo IEEE (Instituto de Engenheiros Eletricistas e

Eletrônicos). O IEEE é uma associação técnica e profissional que já desenvolveu uma

grande quantidade de standards (padrões) para promover o crescimento e compatibilidade

entre tecnologias recentes e tecnologias já existentes. Vários standards já foram definidos

pelo IEEE, como Firewire, wirelessLAN, wireless MAN (802.16, Wi-Fi

802.11g,Bluetooth). Enquanto esses padrões foram desenvolvidos com preocupação em

21

grande largura de banda, para serem usados em aplicações com acesso à internet, o IEEE

802.15.4 foi desenvolvido com menor taxa de transmissão, fácil conectividade e mínimo

consumo de energia. [4]

Na Tabela 1.2 apresenta-se uma comparação entre os diferentes padrões de

comunicação wireless.

Tabela 1.2 - Comunicação wireless.

Pela especificação, a comunicação pode ocorrer em 3 bandas diferentes, destinadas

a aplicações científicas, industriais e médicas (ISM):

- 868 - 868,8 MHz

- 902 - 928 MHz

- 2.400 - 2.4835 MHz

Apesar de qualquer uma destas bandas poderem ser utilizada para os dispositivos

802.15.4, a banda mais utilizada é a dos 2,4 GHz, uma vez que esta é uma banda livre na

maioria dos países do mundo. [4]

Enquanto que nas bandas dos 868 MHz e 915 MHz se utiliza a modulação BPSK

(Binary Phase Shift Keying), na banda dos 2,4 GHz o protocolo IEEE 802.15.4 utiliza O-

22

QPSK (Offset Quadrature Phase Shift Keying) com forma de meia senóide para modular a

portadora de radiofreqüência. [4]

1.4.2. ZigBee

O ZigBee é um protocolo que utiliza o standard IEEE 802.15.4 como base e

acrescenta uma funcionalidade muito útil: a capacidade de estabelecer redes e fazer

routing. O protocolo ZigBee foi desenvolvido pela ZigBee Aliance. A ZigBee Aliance é um

grupo de empresas que trabalharam em conjunto para desenvolver um protocolo para o

estabelecimento de redes que pudessem ser utilizadas em diversos ambientes, como por

exemplo o comércio e a indústria, em que não se exigem taxas de transmissão elevadas.

Deste modo, o ZigBee foi concebido de modo acrescentar a implementação de mesh

networking ao conjunto de funcionalidades ao IEEE 802.15.4. [4]

O tipo de rede em malha (mesh networking) é principalmente utilizado em

aplicações em que se pretende efetuar a transmissão de dados entre dois nós que estão fora

do alcance um do outro. Deste modo, os dados são transmitidos para outros nós

intermédios que fazem o redirecionamento da informação até que esta chegue ao

destinatário. [4]

Como exemplo, a situação da Figura 1.3. Supondo que seja necessário transmitir

informação do ponto A para o ponto B, porém, a distância é grande demais entre os dois

pontos. A informação poderia ser transmitida passando por outros pontos tais como o

ponto C.

23

Figura 1.3 - ZigBee, mesh networking

O protocolo ZigBee foi concebido de maneira que independentemente da

localização e disposição dos pontos de envio e recepção de dados, a rede se formasse

automaticamente sem necessitar da intervenção do utilizador na configuração da mesma.

Deste modo, o protocolo encarrega-se de todo o processo de reenvio, confirmações de

recepção e routing das mensagens. No caso de algum dos pontos de envio e recepção de

dados for removido ou desligado, uma nova rede será gerada automaticamente. A esta

última capacidade do ZigBee pode-se chamar de Self-Healing. Se o ponto C for removido

do sistema por alguma razão, um novo caminho seria utilizado para transmitir dados de A

para B. [4]

Qualquer dispositivo que se encontre dentro das normas ZigBee pode ser utilizado

como dispositivos de envio, recepção, ou ambos. Neste último caso, é possível ter simples

dispositivos de comunicação bidirecional ou assumir ainda funções de routing e

coordenação. Uma vez que o protocolo ZigBee utiliza o IEEE 802.15.4 como base para

definir as camadas PHY e MAC, a freqüência, a largura de banda do sinal e as técnicas de

modulação são semelhantes. [4]

24

1.4.3. Comandos AT

Para este projeto foi selecionado o modo de comunicação ‘Transparente’, que

basicamente funciona como “uma ligação RS232 sem fio”. Neste modo, para modificar ou

ler os parâmetros do módulo RF, são utilizados comandos do tipo AT. Cujo formato está

ilustrado na Figura 1.4.

Figura 1.4 - Exemplo de comando AT.

Para entrar no modo de comando, é necessário enviar os caracteres ‘+++’ e esperar

1 segundo sem enviar qualquer caractere. Caso não ocorram problemas, o XBee responde

‘OK’, sinalizando que seus parâmetros podem ser lidos/alterados.

No exemplo da Figura 1.6, está sendo alterado o endereço de destino, a parte baixa

deste. O endereçamento é feito por 2 bytes (16 bits – 65536 possibilidades), DL é o byte

menos significativo e DH o mais significativo. Pelo fato do valor padrão de DH ser 0x00,

não será necessário alterá-lo.

Outro comando de endereçamento importante é o MY. Este comando define o

endereço do próprio módulo. Para comunicação bilateral entre 2 nós, é necessário que o

valor MY de um seja igual ao DL do outro. A Figura 1.5 exemplifica este saco.

25

Figura 1.5 - Comunicação ponto a multiponto.

É possível, também, definir o nó que receberá a transmissão através do nome dado

a um módulo. Através do comando NI é possível definir o nome do modo que está sendo

configurado, com limite de 20 caracteres. Para selecionar o nó destino, utiliza-se o

comando DN seguido do nome do módulo que deverá receber os dados. Caso este nome

não ser conhecido, é possível fazer varredura dos módulos que estão ao alcance, através do

comando ND, que retornará nome e endereço dos nós descobertos. Figura 1.6 demonstra

este tipo de seleção.

Figura 1.6 - Configuração ponto a ponto

26

Além desses, existem muitos parâmetros que são configurados por comandos AT.

Alguns exemplos interessantes são:

SC: procura por canais de comunicação que não estão sendo utilizados. Útil quando

se está em ambientes onde existem outros aparelhos usando freqüências próximas.

ED: mede energia em cada canal. Útil quando se deseja monitorar atividades de

alguma rede, ou mesmo para selecionar um canal para utilização.

PL: diminui a potência de saída. Dessa forma é possível se adequar às leis de

determinado país, como Japão. Muito útil também quando 2 nós não estão muito distante

um do outro, desse modo, ao diminuir a potência de saída o consumo é reduzido.

SM: diferentes configurações do modo sleep. Uma das principais vantagens do

ZigBee/802.15.4 é o baixo consumo de energia, cujo principal motivo é o modo sleep.

RO: determina o número de caracteres a serem armazenados no buffer antes da

transmissão.

DB: detecta o nível do sinal recebido.

KY: chave de encriptação 128-bit AES. É uma palavra com até 32 caracteres

hexadecimais. O destinatário deve apresentar a mesma palavra que o transmissor, caso

contrário não receberá os dados.

WR: grava os valores atuais das configurações na memória não-volátil.

CN: encerra o modo de comando.

Ainda existe uma série de comandos para controlar o uso e transmissão dos 6 canais

de A/D embarcados no módulo, assim como saídas de PWM e transmissão de valores em

pinos digitais.

1.5. Placa Arduino Duemilanove

Arduino é uma ferramenta de desenvolvimento. Neste projeto, o modelo utilizado é

Duemilanove.

Inspirado na ideologia open-source, trata-se de uma plataforma computacional

física, baseado em uma placa microcontrolada e um ambiente de desenvolvimento para

escrever e gravar o firmware no microcontrolador. [8]

27

A linguagem de programação é uma implementação do Wiring, que se trata de uma

plataforma similar, por sua vez baseada no ambiente Processing de programação

multimídia. [8]

Algumas das vantagens do Arduino sobre outros kits são:

• Baixo custo: alguns modelos podem ser adquiridos por menos de U$ 50.

• Multi-plataforma: software funciona em ambientes Windows, Mac e Linux.

• Ambiente de programação simples: easy-to-use para iniciantes, e mesmo

assim versátil o suficiente para usuários avançados. Possui várias built-in

functions, facilitando uso geral.

• Open source: ferramenta de código-aberto, pode ser expandida por

programadores experientes por bibliotecas em C++. Além da programação,

é disponibilizado todas informações necessárias para montar o próprio

Arduino, seus componentes e ligações.

• Informações de compatibilidade: por ter adquirido atenção de

programadores, certos fabricantes fazem seus equipamentos compatíveis

com Arduino, usando essa característica como atrativo. [8]

Além dessas características, o tamanho reduzido e opção de gravar firmware via

USB são atrativos. Vale ressaltar que quando conectado à USB de um computador, não

existe necessidade de outro tipo de alimentação no circuito. Na Figura 1.7, o Arduino.

Figura 1.7 - Arduino Duemilanove.

28

1.5.1. Microcontrolador

O modelo Duemilanove apresenta três opções de microcontrolador:

ATmega88

ATmega168

ATmega328

Sendo que entre esses a única diferença é a capacidade de memória, tanto RAM

quanto Flash e EEPROM. A Tabela 1.3 mostra a capacidade de cada modelo.

Tabela 1.3 – Capacidade de armazenamento ATmega. Modelo Flash EEPROM RAM

ATmega88 8k byte 512 byte 1k byte

ATmega168 16k byte 512 byte 1k byte

ATmega328 32k byte 1k byte 2k byte

Entre as semelhanças desses modelos, a arquitetura AVR. Deste modo, é possível

utilizar qualquer biblioteca desenvolvida para microcontroladores com esta arquitetura.

Dados importantes:

Pinos de I/O: 14 disponibilizados pelo Arduino, dos quais, 6 podem

fornecer saída em PWM. Cada pino suporta 40 mA. [8]

Conversor A/D: conversor com 10 bits de resolução, tensão de referência,

multiplexado em 6 canais. [8]

Temporizadores: 3 timer/counters disponíveis. Destes, dois de 8 bits (com

prescaler) e um de 16 bits. Porém, quando utiliza-se built-in functions

relacionadas aos temporizadores, como a função delay(), compromete-se o

uso de 1 T/C.

Comunicação: suporte para USART, SPI e TWI (I²C).

Interrupções: ao todo são 26, desde interrupção por overflow de um timer a

interrupção externa.

Clock: Arduino vem com cristal de 16 MHz. O ATmega168 possibilita 16

MIPS neste caso, podendo ser alterada para 2 MIPS (Divisão por 8) se

houver interesse em redução de consumo, por exemplo.

29

1.6. Baja SAE

O projeto Baja SAE é uma competição entre Instituições de Ensino Superior que

desafia estudantes de engenharia através da simulação de um caso real de desenvolvimento

de projeto, com todas as atividades que envolvem o mesmo, visando a aplicação prática

dos conhecimentos adquiridos em sala de aula.

O protótipo em questão foi desenvolvido pela equipe da UPF ‘Mas Baja Tchê!’,

composta em sua maioria por acadêmicos do curso de Engenharia Mecânica. Foto

ilustrativa na Figura 1.8.

Figura 1.8 - Baja SAE - UPF

30

Com este veículo a equipe participa dos campeonatos regional e nacional de Baja

SAE. Foi concebido de acordo com a regulamentação deste desafio, que tem por objetivo

simular as necessidades e dificuldades de um projeto real de engenharia.

Os Baja SAE são protótipos de estrutura tubular em aço, monopostos, para uso off-

road, robusto, com quatro ou mais rodas.

O veículo deve ser seguro e apto a vencer terrenos acidentados em qualquer

condição climática sem apresentar danos. Deve ser capaz de transportar pessoas com até

1,90m de altura e pesando até 113,4 kg. O motor padrão é de 10 cv, 1 cilindro. Os sistemas

de suspensão, transmissão, freios e o próprio chassi são desenvolvidos pelas equipes, que

têm, ainda, a tarefa de buscar patrocínio para viabilizar o projeto.

Apesar de, aparentemente, ser um desafio para engenharia mecânica, não existe

restrição quanto a curso. Embora exista restrição quanto ao uso de recursos eletrônicos no

sistema motor, a utilização de sensores, aquisição de dados e, por conseguinte, telemetria é

permitida.

31

2. Sistema Desenvolvido

Neste item, serão definidos os dispositivos utilizados na construção do sistema de

telemetria. Algumas considerações devem ser feitas visando desempenho final satisfatório:

Leitura dos sensores e transmissão dos dados deve ocorrer no menor

intervalo de tempo possível, de modo que se tenha informação atualizada a

cada instante. Idealmente, intervalo inferior a 400ms.

A comunicação via RF deve ter alcance acima de 400 metros, para que seja

possível enviar os dados para a equipe de qualquer ponto do circuito.

Um automóvel de competição representa um ambiente hostil a componentes

eletrônicos que dependem de bom contato elétrico. O sistema deve ser

projetado de acordo a agüentar as vibrações que uma competição do tipo

off-road-cross implica.

Os circuitos das competições são basicamente sobre terra, o que descarta

uso de qualquer elemento ótico. Não que utilizar seja impossível, mas trata-

se de um risco não necessário.

De acordo com as necessidades descritas acima, definiu-se o seguinte diagrama de

blocos. Expresso pela Figura 2.1.

Figura 2.1 - Diagrama de blocos do sistema de telemetria.

32

Embora esteja presente no diagrama de blocos do projeto, a parte de programação

do software para o computador não será realizada, por falta de tempo hábil. Neste bloco,

então, será somente descrita a maneira que os dados serão enviados à COM do

computador, para que este software possa ser feito por quem tenha o devido conhecimento.

Na seqüência, a descrição da funcionalidade de cada bloco, do diagrama mostrado

na Figura 2.1, com suas características e soluções adotadas.

2.1. Sensores

Como citado no item 2, evita-se o uso de sensores ópticos.

São utilizados 5 tipos de sensores. Quatro para medir curso de suspensão, um em

cada braço de suspensão; um acelerômetro tri-axial para medir força G em três eixos,

gerando assim, três medições; um sensor de temperatura para medir a temperatura do

motor; uma chave magnética colocada no eixo dianteiro para medir velocidade; e um

circuito ligado à bobina de ignição para determinar o número de rotações por minuto (rpm)

do motor.

Entretanto, os quatro sensores de curso de suspensão foram extraviados pela

equipe. E o único membro com conhecimento sobre o funcionamento de tais sensores não

respondeu às tentativas de contato. Dessa forma, reservaram-se quatro entradas analógicas

disponíveis. As informações sobre este sensor são baseadas em informações de um colega

que viu o projeto, porém não tem condições de oferecer mais informações.

É necessário comentar, que caso o modelo dos sensores LDVT tenham saída em

forma de tensão analógica, não haveria entradas analógica suficientes, logo, será utilizado

um multiplexador analógico (UTC4053) para solucionar esse problema.

33

2.1.1. Curso de Suspensão

Foi utilizado um sensor magnético do tipo LVDT. Esse sensor consegue medir a

posição com altíssima precisão e excelente para a operação em questão. Ilustrado na Figura

2.2.

Figura 2.2 – Funcionamento dos sensores LVDT .

Em sensores desse tipo, uma corrente alternada é aplicada na bobina primária,

fazendo com que uma tensão seja induzida em cada bobina secundária proporcionalmente

à indutância mútua com a bobina primária. A freqüência da corrente alternada está

geralmente entre 1 e 10 kHz. [11]

De acordo com a movimentação do núcleo, esta indutância mútua muda, fazendo

com que as tensões nas bobinas secundárias mude também. As bobinas são conectadas em

série reversa, com isso a tensão de saída é a diferença entre as duas tensões secundárias.

Quando o núcleo está na posição central, eqüidistante em relação às duas bobinas

secundárias, tensões de mesma amplitude porém opostas são induzidas nestas duas

bobinas, assim, a tensão de saída é zero. [11]

Quando o núcleo é movimentado em uma direção a tensão em uma das bobinas

secundárias aumenta enquanto a outra diminui, fazendo com que a tensão aumente de zero

para um máximo. Esta tensão está em fase com a tensão primária. Quando o núcleo se

move em outra direção, a tensão de saída também aumenta de zero para um máximo, mas

sua fase é oposta à fase primária. A amplitude da tensão de saída é proporcional à distância

34

movida pelo núcleo (até o seu limite de curso), sendo assim denominação "linear" para o

sensor. Assim, a fase da tensão indica a direção do deslocamento. [11]

Trata-se de uma informação útil para analise do projeto da estrutura tubular e

também do próprio sistema de suspensão. Ajustes podem ser feitos de corrida para corrida,

dependendo do percurso, para melhor adaptação do carro a determinados obstáculos, como

“costeletas” e saltos.

2.1.2. Força G

Um acelerômetro tri-axial mede forças inerciais, aceleração, no eixo longitudinal,

horizontal e vertical. Através dessa informação, determina-se a magnitude das forças sobre

qual chassi e eixos são submetidos, podendo convergir para diminuir a espessura tubular, e,

por conseguinte, o peso do veículo.

Não obstante a isso, tal informação é de utilidade também para o piloto. Ao fazer

uma curva, é exercida uma força lateral, proveniente da inércia, chamada de força

centrífuga. Tal força se dá em uma direção diferente da desejada pelo piloto, fazendo

assim, com que o carro derrape, perca aderência e velocidade. Com informação sobre força

lateral, o piloto pode testar métodos de minimizar o efeito de tais forças, melhorando seu

desempenho.

O acelerômetro escolhido é o ADXL330. Trata-se de um acelerômetro tri-axial (3

eixos) com saídas em tensão analógica. Entre as principais características está o baixo

consumo, 200µA com alimentação de 3.3V. Além disso, boa estabilidade térmica e

resistência à aceleração de 10 G, porém quanto a medições só é garantido até ±3 vezes a

gravidade terrestre.

Existindo a necessidade de posicionar o acelerômetro no centro de massa do

automóvel, foi confeccionada uma placa de circuito impresso separada da placa principal.

O circuito dessa placa está ilustrado na Figura 2.3.

35

Figura 2.3 – Circuito do acelerômetro tri-axial.

No circuito acima, os capacitores C1, C2 e C3 têm a função de delimitar o

bandwidth das saídas analógicas, sendo que o valor mínimo recomendado é de 4,7 ηF. Por

medida de segurança, foi definido um valor um pouco maior, 10 ηF.

Os pinos 12, 10 e 8 do ADXL330, que indicam aceleração nos eixos X, Y e Z,

respectivamente, são conectados diretamente a 3 entradas analógicas distintas do Arduino.

O ADXL330 tem resposta linear à aceleração, sendo 300mV o valor típico para 1

G. Parte-se desse valor, podendo ser alterado no decorrer dos testes. Equação (1)

demonstra o funcionamento:

, , [ ]0,3

INX Y Z

VA G

V= (1)

O valor é relativo à gravidade terrestre, cujo valor aproximado é de 9,81m/s².

Mais informações sobre testes no item 3.

36

2.1.3. Temperatura do Motor

Apesar de não ser crítico neste caso, é interessante monitorar a temperatura do

motor para saber quando está sendo exigido demais do mesmo. Caso a temperatura alcance

valores acima do estipulado pelo fabricante do motor, a equipe pode avisar o piloto para

reduzir o ritmo, utilizando o pedal acelerador de maneira mais suave nas saídas de curva,

ou em caso extremo, parar.

Para tanto, é utilizado o CI sensor de temperatura LM35, capaz de medir

temperaturas de -55ºC até 150ºC. Com precisão típica de 0,25°C e mínima de 0,75°C. Com

saída na forma de tensão analógica, fornece 10 mV a cada °C. Demonstrado pela equação

(2):

( ) 10V Temperatura C x mV= ° (2)

Considerando uma temperatura de 25ºC, por exemplo, tem se:

25 10 250 0,25V x mV mV V= = = (3)

Pelo fato de não haver offset nem interesse em medições negativas, é utilizada

configuração de sensor centígrado básico, com precisão em temperaturas de 2°C a 150°C,

representada na Figura 2.4:

Figura 2.4 - Configuração de sensor centígrado básico, LM35.

37

Para maior fidelidade da medição da temperatura, o LM35 é fixado no bloco do

motor, de maneira a não haver perda de precisão. Espera-se que a temperatura do motor

varie entre 70°C e 130°C.

2.1.4. Velocidade

Embora seja um item fundamental, o automóvel da equipe ‘Mas Baja Tchê’ não

dispõe desta informação.

Para fazer um velocímetro foi utilizado um sensor (chave) de Efeito Hall.

Um pequeno imã é fixado na parte interior da roda dianteira esquerda. Então, a

chave de Efeito Hall A3240 fica acoplada a uma parte fixa próxima a roda, de maneira que

quando, pela rotação, o imã se aproximar da chave hall, esta se fecha, contando uma

rotação. A saída do A3240 é ligada ao Arduino, o qual através de um timer determinará o

intervalo a cada rotação completa da roda. Sabendo-se a medida da circunferência externa

do pneu, determina-se a velocidade. A equação (4) demonstra a lógica:

( ) ( )[ / ] 3,6 [ / ]

( ) ( )

Circunferência m Circunferência mVelocidade m s ou Velocidade km h

TempodeRotação s TempodeRotação s= = ×

(4)

Figura 2.5 representando o funcionamento do A3240.

Figura 2.5 - Representação da chave hall.

Segundo o fabricante, é altamente recomendável utilizar um capacitor de 100ηF nos

pinos de alimentação, o mais próximo possível dos mesmos.

38

2.1.5. Freqüência do motor - rpm

Importante para averiguar o funcionamento do motor, também útil para equipe

determinar as relações entre engrenagens do sistema de câmbio. Um fator importante,

considerando-se que existe um limite de 3800 rpm por parte do regulamento.

Tendo em mente que o ciclo do motor utilizado pelo Baja é de quatro tempos, sabe-

se que ocorre uma explosão a cada duas rotações. Assim sendo, a vela atua 1 vez a cada 2

ciclos, sendo este o ponto de medição. A idéia baseia-se em determinar o intervalo de

tempo entre dois acionamentos da vela. Para isso, foi desenvolvido o circuito da Figura

2.6.

Figura 2.6 - Circuito para adequar o sinal ao Arduino.

Como na maioria dos carros de rua, utiliza-se o sinal proveniente da bobina do

sistema de ignição para determinar o número de rotações por minuto. R1 tem por

finalidade diminuir o nível de corrente, enquanto D1 e D2 têm o objetivo de limitar a

tensão VBE. R2 funciona como resistor de pull-up, evitando curto-circuito quando Q1 está

conduzindo, e levando a tensão de saída a VCC quando Q1 está aberto. O sinal de saída é

levado ao Arduino, que utiliza um timer para determinar a freqüência de giros do motor.

Descrito pela equação (5):

( º ) 2( º ) 2[ ] [ ]

60

n de pulsosf n de pulsos Hz ou f rpm

×= × = (5)

39

2.2. Arduino Duemilanove

As características deste componente já foram citadas no item 1.5, desse modo, no

presente item será tratado o modo como é feita a leitura dos sensores e ligação com o

módulo XBee.

2.2.1. Sensores

Neste projeto, o Arduino tem dois modos de ler a informação proveniente dos

sensores: leitura analógica e contagem de pulsos.

2.2.1.1. Nível Analógico de Tensão

Estão disponíveis no Arduino 6 canais A/D. Um canal A/D trata-se de um caminho

(pino) cujo nível de tensão será interpretado de maneira digital, também conhecido como

conversor analógico-digital.

O conversor em questão tem 10 bits de resolução, possibilitando a diferenciação de

1024 diferentes níveis de tensão. A faixa de tensão com que o A/D trabalha está

compreendida entre a referência de zero volts (GND) e uma tensão externa de referência

(AREF). Ao invés de utilizar uma referência externa, pode-se configurar como 5V (VCC)

ou 1,1V, por software. Neste projeto, é utilizada uma referência 3,3V, para ter maior

precisão nos níveis de saída dos sensores em questão.

Quanto à lógica de programação, o ambiente Arduino trás uma função pronta

(built-in function) que facilita muita a leitura das entradas analógicas: analogRead(n),

sendo n o número referente ao canal analógico utilizado.

No Anexo C, a demonstração de um teste realizado.

40

2.2.1.2. Contagem de Pulsos

Ao trabalhar com grandezas que dependem do intervalo de tempo com que certo

evento ocorre, é comum utilizar chaves, que geram pulsos. Para determinar, então, a

grandeza, é necessário um medidor de freqüência. Neste projeto, o responsável por isso é o

microcontrolador do Arduino Duemilanove, através de seus módulos

temporizador/contador, também conhecidos como timer/counter ou T/Cs.

O Arduino apresenta três módulos T/C, Timer/counter0, Timer/counter1 e

Timer/counter2. Todos os 3 apresentam diferentes prescalers, sendo o maior de 1:1024.

O Timer0 e o Timer2 são contadores de 8 bits (256 contagens). Já que o Timer1 tem

16 bits (65536 contagens), e apresenta um modo que nenhum dos outros timers tem, o

modo de captura. Este modo espera um evento externo (mudança de nível ou um nível

lógico especifico) para iniciar a contagem, armazenando o valor da contagem quando

ocorre outro evento igual ao que iniciou a contagem.

Tendo conhecimento do fato de o duty cicle em ambos os casos (em que é usado o

sistema de contagem de pulsos) não ser 50%, a lógica de detecção não pode ser baseada

simplesmente em qualquer mudança de nível, mas sim considerar bordas de subida ou

descida apenas.

No Anexo D e Anexo E, demonstrações de dois testes realizados.

41

2.2.2. Interface com XBee

Primeiramente, é importante salientar a diferença entre as tensões de XBee e

Arduino. Enquanto o Arduino trabalha com 5V de alimentação, mesma tensão que entrega

como nível lógico alto, os módulos XBee trabalham com 3,3V, não sendo recomendado

colocar mais do que 3,4V em seus pinos, havendo risco de dano. Para tanto, se faz

necessária adequação do sinal provindo do Arduino, no caso, o pino Tx (transmissão).

Como ilustrado na Figura 2.7.

Figura 2.7 - Ligação entre Arduino e XBee

42

Percebe-se pelo esquema, também, que a comunicação entre Arduino e XBee se dá

de forma serial. De fato, segue exatamente o protocolo RS232, utilizado em portas serial

de computadores. Mais uma vez, o ambiente de programação do Arduino se mostra útil,

tendo uma função (built-in) que facilita a escrita serial: Serial.print(var, HEX), onde var é a

variável cujo valor será enviado e HEX representa o formato em que o valor será enviado,

nesse caso, em hexadecimal.

2.2.3 Função Geral

A funções do Arduino nesse projeto são de interpretar as informações provindas

dos sensores e envia-las para o módulo XBee-PRO. Na Figura 2.8, o esquema de ligações

do Arduino.

Figura 2.8 – Ligações entre Arduino e outros elementos do sistema.

43

As 3 saídas do acelerômetro são ligadas diretamente a 3 entradas analógicas do

Arduino. Entretanto, a saída do sensor de temperatura, assim como os 4 sinais referentes

aos sensores de LVDT são selecionados através do CI 4053, um multiplexador analógico.

A seleção é feita pelo Arduino, através de 3 pinos digitais (lado direito na Figura 2.8).

A adequação entre os níveis do Arduino (5V) e XBee(3,3V) é feita através de um

divisor resistivo no Tx do Arduino. A equação (6) apresenta o cálculo desse divisor:

5 2 5 19 63,31

1 2 10 19 6

V R V kV V V

R R k k= ⇔ =

+ +

i i

(6)

Neste projeto, o Arduino é alimentado pela bateria do Baja (+12V). A placa conta

com reguladores de 5V e 3,3V. Entretanto, para possibilitar a utilização de outros sensores,

ou outro tipo de recurso, o que implica em cargas maiores, foram adicionados 2

reguladores de tensão ao projeto. O CI LM1117 para +3,3V e o 7805 para +5V, ficam em

paralelo com os reguladores do Arduino, aumentando a capacidade de corrente geral.

2.2.4 Firmware

Um fator importante para este projeto é o intervalo entre medições, o fluxo de

informações recebidas pela equipe. É necessário saber os valores das grandezas

instantaneamente. Pensando assim, o firmware foi escrito de maneira que não se perca

tempo processando minuciosamente a informação, mas sim, passá-la adiante o mais rápido

possível. O fluxograma simplificado é demonstrado pela Figura 2.9.

44

Figura 2.9 – Fluxograma simplificado do firmware.

Enquanto os sensores com saída analógica são facilmente interpretados pela função

analogRead(pino), determinar velocidade e rotação do motor constituem dificuldades. Para

esses 2 casos é necessário determinar a freqüência dos sinais.

Utilizar o Arduino como freqüencímetro em si não é um problema. A dificuldade

está em fazer isso sem comprometer a leitura dos sensores e transmissão de dados.

Como explicado anteriormente, deseja-se realizar leituras e transmissões no menor

intervalo de tempo possível, logo, descarta-se a idéia de contar número de pulsos durante

certo período. Visando rapidez, foi escolhido medir o tempo entre 2 pulsos, o que gera

outros problemas:

• Caso se espere 2 pulsos para continuar com as transmissões, o sistema só

funcionará com o carro andando e motor ligado. Outra desvantagem é a

demora na atualização dos valores, que dependem da rotação do motor e

velocidade do Baja.

45

• Caso se utilize o módulo captura, as interrupções podem acontecer durante

transmissões de dados e estes serem perdidos. Além disso, em caso de baixa

velocidade ou rotação do motor, é estourada a capacidade dos contadores, o

que gera outras interrupções.

A alternativa encontrada está descrita no item 2.6.

2.3. XBee - Canal

Neste item, serão abordados em conjunto os XBee’s e o Canal RF. Dessa forma,

além da configuração do XBee, através dos comandos AT, também será analisada a

comunicação entre os dois XBee do projeto, o que constitui o Canal.

2.3.1. Comunicação entre XBee’s

Praticamente todos os aspectos de comunicação entre XBee’s foi abordado no item

1.4. Resumidamente, existem duas possibilidades de protocolo, dependendo do modelo.

São os protocolos IEEE 802.15.4 e o ZigBee, que nada mais é do que uma evolução do

IEEE 802.15.4. Têm como característica positiva o baixo consumo, alcance relativamente

grande e alta imunidade a interferência.

2.3.1.1. Imunidade a Ruído

O XBee utiliza DSSS (Direct Sequence Spread Spectrum, seqüência direta de

espectro espalhado, em português) para modular a informação antes de ser enviada.

Basicamente, cada bit de informação a ser transmitido é modulado em 4 possíveis símbolos

46

(outro tipo de alfabeto binário), esse processo faz com que a informação total ocupe maior

largura de banda, mas usa menor densidade espectral de potência para cada sinal. [9]

A Figura 2.10 demonstra esse espalhamento.

Figura 2.10 - DSSS e ruído.

Isso causa menos interferência nas bandas de freqüência utilizadas e melhora a

SRN (relação sinal/ruído, Signal to Noise Ratio) no receptor pelo fato de ser mais fácil

identificar e decodificar a mensagem que está sendo transmitida pelo transmissor. [9]

Existem diferentes modulações DSSS, os XBee utilizam a O-QPSK (Offset-

Quadrature Phase Shift Keying), possibilitando taxas de transmissão de até 250 kb/s. [9]

2.3.1.2. Imunidade a Interferência

O protocolo 802.15.4 estabelece o uso de duas tecnologias para evitar que todos os

nós de uma rede emitam sinal ao mesmo tempo: CSMA-CA e GTS.

A mais comum é Carrier Sense Multiple Access-Collision Avoidance (CSMA-CA).

Neste método, cada módulo analisa os sinais na banda em que está configurado. Caso a

energia encontrada for maior que um nível estipulado, o módulo espera por um intervalo

definido, mais um acréscimo randômico, e tenta novamente. [9]

47

A segunda tecnologia é Guarantee Time Slots (GTS, garantir espaço de tempo).

Esse sistema utiliza um nó central (coordenador PAN) que determina espaços de tempo

para cada módulo, de maneira que todos módulos saibam quando devem transmitir.

Existem 16 possibilidades de tempo. Como primeiro passo, o módulo deve enviar ao

coordenador PAN uma mensagem requerendo GTS. Como resposta, o coordenador enviará

uma mensagem contendo o espaço alocado, e o número de espaços registrados. [9]

A maioria dos módulos utiliza CSMA-CA, de modo que não dependa de um

servidor central. Existem situações especiais, como pacotes ACK, que não necessitam

deste método para funcionar. [9]

Uma função implementada pelo 802.15.4 é a varredura de energia de canal (pedido

PLME-ED). A idéia é ser capaz de saber quanta energia (atividade/ruído/interferência) está

presente em um ou mais canais antes de usá-lo. Dessa maneira, é possível poupar energia

escolhendo um canal livre ao estabelecer uma rede. Há três comportamentos diferentes

relacionados à detecção de energia: [9]

Energia: varre os canais e reporta o nível de energia encontrado, independente

da fonte. Transmissão só ocorre quando o retorno for inferior a um limite pré-

definido.

Detecção de portadora (CCA): varre os canais procurando por transmissão

802.15.4. Só transmite quando o canal estiver livre.

CCA + Energia: verifica se existem transmissões 802.15.4 com nível de energia

acima do estabelecido. Só utiliza o canal caso retorno for negativo. [9]

2.3.1.3. Baixo Consumo

O XBee está preparado para trabalhar com baixo ciclo de trabalho. Isso significa

que o transceiver pode “dormir” a maior parte do tempo (até 99%) enquanto que tarefas de

transmissão e recepção podem ser definidas para usar pequena parte da energia do

dispositivo. Essa porcentagem depende do modelo de comunicação utilizado. [9]

No caso deste projeto, tal economia não ocorre devido às constantes transmissões.

Porém, mesmo assim o consumo é inferior a outras tecnologias, como Wi-Fi.

48

2.3.1.4. Potência de Transmissão e Sensibilidade de Recepção

IEEE 802.15.4 define a menor quantidade de energia necessária para transmissão

como -3dBm (0,5 mW), e a sensibilidade mínima no receptor como -92dBm (6,3E-10

mW). Os módulos XBee-PRO apresentam potência de saída de 20dBm (100mW),

enquanto o XBee padrão consegue no máximo 0 dBm (1 mW). Quanto à sensibilidade de

recepção, o XBee padrão consegue detectar sinais de no mínimo -92dBm, limite estipulado

pela 802.15.4. Já o XBee-PRO, é sensível a sinais de -100 dBm (1E-10 mW). [9]

2.3.2. Comandos AT, configurações

Para configurar o módulo XBee de acordo com a necessidade, é preciso utilizar os

comandos AT. Na seqüência, serão listados os valores de cada parâmetro de configuração,

com breve descrição. O módulo ligado ao Arduino será referido como XBee-Arduino e o

módulo em contato com o computador será chamado de XBee-PC. As Tabelas 2.1 e 2.2

demonstram os comandos cujos parâmetros serão diferentes dos valores padrão.

Tabela 2.1 - Configurações XBee-Arduino. ATBD7 Configura baud rate como 115200 bps

ATMY77 Configura o próprio endereço como 0x77

ATDL33 Configura o endereço de destino como 0x33

ATNI Arduino Configura ao próprio nome como Arduino

Tabela 2.2 - Configurações XBee-PC. ATBD7 Configura baud rate como 115200 bps

ATMY33 Configura o próprio endereço como 0x33

ATDL77 Configura o endereço de destino como 0x77

ATNI PC Configura ao próprio nome como PC

49

Após configurar os parâmetros, é necessário enviar o comando ATWR para

registrar os valores na memória não-volátil. Pode-se enviar ATCN para sair do modo de

comandos, ou esperar 10 segundos (este tempo pode ser alterado pelo comando ATCT)

para sair automaticamente.

2.4. Fonte de Alimentação

Todo o sistema, exceto a parte de recepção no notebook cuja alimentação é a

bateria do próprio notebook, é alimentado pela bateria do Baja. Assim como citado no item

2.2.3, o Arduino já possui reguladores de tensão para +5V e +3,3V. A capacidade de

corrente, no entanto, não seria suficiente para o XBee-PRO transmitir dados. O XBee-PRO

necessita 250mA e o regulador de 3,3V fornece no máximo 50mA. Para solucionar esse

problema, foi projetado o circuito da Figura 2.11. Os +12V são provenientes da bateria do

Baja, enquanto os reguladores de +5V e +3,3V estão em paralelo com os equivalentes do

Arduino.

Figura 2.11 – Fonte de alimentação.

50

R1 e D1 têm função de proteção. Enquanto D1 protege o restante do circuito de

tensão negativa, R1 tem por objetivo limitar a corrente máxima em pouco mais de 1A,

como demonstrado pela equação (7):

21 1( ) 1R RP I R= i (7)

Como a potência máxima do resistor é 1/4W, ou 0,25W, tem-se:

11 1

0,251,066

1 0,22R

MaxR MaxR

PI I A

R= ⇒ = = (8)

Pelo fato de o LM1117 ser de low dropout, não é aconselhável utilizar tensão de

entrada muito superior à de saída. Sendo assim, ele é alimentado por +5V.

Os capacitores de 100nF são para desacoplamento. Demais capacitores e seus

valores constituem recomendações dos fabricantes.

O 7805 fornece 1 A em 5V e o LM1117 fornece mais de 800 mA em 3,3V.

2.5. Intervalos de Tempo, Freqüências e Taxas

Sendo o objetivo do projeto leituras instantâneas, esses parâmetros têm grande

importância. Estabelecendo uma linha do tempo dos eventos necessários para a informação

chegar à equipe de box:

• Leitura das grandezas: tanto por A/D como por pulsos.

• Envio dos dados do Arduino para XBee.

• Envio dos dados do XBee-Arduino para o XBee-PC.

• Leitura dos dados pelo PC.

Não se pode desconsiderar, também, certo atraso relativo à rotina do µControlador.

As instruções para qualquer ação consomem tempo. Normalmente um tempo muito curto,

mas ainda assim está presente.

51

2.5.1. Conversão A/D

Segundo a Atmel, fabricante do ATmega168, cada conversão leva entre 13 e 260µs.

É necessário, além disso, considerar certo atraso devido à rotina de leitura. Logo,

considerando o pior caso, considera-se que cada conversão tomará 300 µs para ser

realizada.

Tomando por base a quantidade de 8 conversões A/D por ciclo de transmissão, tem-

se:

8 / 300 8 2,4A D s msµ×Τ = =i (9)

Levando em conta atrasos devido a mudanças de canal, tanto do multiplexador do

ATmega168 (interno) como do multiplexador 4053, considera-se o tempo de 8 conversões

como 3 ms.

2.5.2. Leitura por Pulsos

O tempo necessário para averiguar esse tipo de grandeza, assim como seu envio,

difere das leituras analógicas.

Pelo fato de sua mensuração ser mais lenta em relação às leituras analógicas, o

valor transmitido pode não mudar entre 2 ou mais ciclos. Isso ocorre única e

exclusivamente pelo fato de o intervalo de tempo entre 2 pulsos poder ser maior que o

tempo total de um ciclo de transmissão. Ou seja, todos os dados podem ter sido enviados

sem que tenha ocorrido o segundo pulso.

Mesmo assim, será estimado os possíveis intervalos de tempo entre 2 pulsos.

52

2.5.2.1. Rotações do Motor

O regulamento da categoria Baja SAE estabelece que a rotação máxima para

qualquer motor deve ser de 3800 rpm. Por outro lado, quando ligado, a rotação mínima não

deve baixar de 400 rpm.

Logo, convertendo a base de minuto para segundo:

4006,67 /

60MINRotação rotações ss

= = (10)

O que em termos de período, equivale a:

1150

6,67MAX

smsΤ = = (11)

Lembrando que a vela é acionada 1 vez a cada 2 rotações, tem-se o dobro do

período exposto na equação (11), ou seja: 300 ms.

Sendo a rotação máxima:

380063,33 /

60MAXRotação rotações ss

= = (12)

O que em termos de período, equivale a:

115,79

63,33MIN

smsΤ = = (13)

Sendo o intervalo entre 2 pulsos da vela igual a 31,58 ms.

Desse modo, estabelece-se que caso a rotação seja de 400 rpm e o tempo total de 1

ciclo de transmissão for inferior a 300 ms, existe a possibilidade dessa leitura não ser

atualizada.

53

2.5.2.2. Velocidade

Trata-se de um problema maior que o caso anterior (item 2.5.2.1), pois em várias

ocasiões a velocidade o Baja será realmente baixa, como por exemplo, na largada e em

toda curva fechada.

Sabendo-se que o perímetro do pneu tomado como base é de 45 cm, é possível

determinar a faixa de operação.

( ) 0,45[ / ]

( ) ( )

Circunferência m mVel m s Vel

Tempo de rotação s Tempo de rotação s= ⇒ =

(14)

Pela equação (14), é possível determinar o tempo de uma rotação, que equivale ao

tempo entre 2 pulsos. Por exemplo, 10 m/s de velocidade:

0, 450,045 45

10 /ROTAÇÂO

mT s ms

m s= = = (15)

2.5.3. Envio dos Dados para XBee-Arduino

A taxa de transferência entre XBee’s é de 250 kbps. Entretanto, a interface do XBee

aceita baud rate máxima de 115200 bps, valor que é utilizado neste projeto.

Assim, a taxa a ser considerada para os cálculos é de 115,2 kbps.

Conhecendo a resolução do A/D interno do Arduino, sabe-se que os valores obtidos

serão de 10 bits. Como os dados são transmitidos no formato hexadecimal, são necessários

3 caracteres para cada medida deste tipo, sendo que o primeiro e o último valor será

acrescido de um caractere indicador.

É preciso, também, levar em consideração que a cada caractere (8 bits, 1 byte)

enviado, são necessários 2 bits extras para determinar começo e fim do byte, resultando

que cada caractere constitua transmissão de 10 bits.

Então, têm-se os seguintes intervalos de tempo para dados provenientes do A/D:

54

3

º 30260

115200 115200n bits bytes

n de bits bitsT T s

bps bpsµ

= ⇒ = (16)

40347

115200bytes

bitsT s

bpsµ 4

= (17)

Já os dados relativo às medições por pulsos podem ser de diferentes tamanhos,

sendo o pior caso de 4 bytes, o qual esta considerado na equação (17).

2.5.4. Envio dos Dados do XBee-Arduino para o XBee-PC

Pelo fato de a taxa de transmissão ser 250kbps, superior aos 115,2 kbps do item

anterior, essa comunicação não influencia no tempo de um ciclo de transmissão. Porém,

representa um atraso, delay entre a medição e a visualização das grandezas.

º

115200 /delay

n de bitsT

bits s

= (18)

2.5.5. Envio dos Dados do XBee para PC

Assim como no item anterior, não influencia o tempo de um ciclo de transmissão,

somente interfere no delay entre aferição e visualização das grandezas. Este delay tem o

mesmo valor do atraso calculado no item 2.5.3.

2.5.6. Atrasos

Em todo sistema de comunicação existe atraso entre o envio e recepção dos dados.

Em um sistema de telemetria existem dois tipos distintos de atrasos. Um referente ao

55

tempo que leva para uma medição ser atualizada. E outro referente ao tempo que as

informações levam para chegar a seu destinatário.

A partir desse ponto, o primeiro caso será referido simplesmente como atraso,

enquanto o segundo caso será referido como delay.

2.5.6.1 Período de Um Ciclo de Transmissão

O período de um ciclo depende dos atrasos, os tempos necessários para que todas as

tarefas de um ciclo sejam completadas.

Pelo item 2.5.1, sabe-se que o tempo de 8 conversões A/D é de 3 ms.

As leituras referentes a velocidade e rpm não são atualizadas necessariamente a

cada ciclo, o que não implica em atraso.

Entretanto, a cada leitura A/D, é verificado se houve atualização de velocidade ou

rpm . Este ato de verificar causa um atraso. Testes indicam que este atraso não passa de

20us por verificação, mas por questões de segurança, será considerado que todas

verificações, somadas, causam atraso de 1 ms.

Além disso, é necessário considerar o atraso causado pela interface Arduino e

XBee, calculado para cada transmissão no item 2.5.3. Os atrasos desta interface

constituem:

• 8 leituras A/D de 10 bits : 4 de curso de suspensão, 3 do acelerômetro e 1 de

temperatura. Constituindo o envio de 3 bytes por 8 vezes.

• 2 leituras de freqüência com no máximo 14 bits: velocidade e rpm.

Resultando em envio de 4 bytes por 2 vezes.

3 8

º 308 8 2,08

115200 / 115200 /bytes vezes

n de bitsT ms

bits s bits s

= • = • (19)

4 2

º 402 2 694

115200 / 115200 /bytes vezes

n de bitsT s

bits s bits sµ

= • = • (20)

56

Não obstante a isso, é preciso considerar que cada uma das 10 transmissões deve

conter 2 bytes extras para identificação de começo e fim do pacote transmitido. Assim,

soma-se a envio de 2 bytes 10 vezes.

2 10

º 2010 10 1,736

115200 / 115200 /bytes vezes

n de bitsT ms

bits s bits s

= • = • (21)

Assim sendo, o período total de um ciclo de transmissão é aproximadamente:

8 / 4 2 3 8 2 10cicloTx xA D verificações bytes vezes bytes vezes bytes vezesT T T T T T= + + + + (22)

3 1 2,08 0,694 1,736 8,51cicloTxT ms ms ms ms ms ms= + + + + = (22)

Segundo a equação 22, a cada 8,51ms os dados serão atualizados, menos

velocidade e rpm que dependem de sua ocorrência.

Este valor teórico é bem inferior a 300ms, tomado como objetivo.

Percebe-se também, que uma taxa de dados tão elevada pode acarretar problemas

para armazenamento de todos os dados. Alterações podem ser feitas nesse sentido, no

futuro.

2.5.6.2 Delay geral do Ciclo de Transmissão

O delay geral pode ser considerado como o período de um ciclo, acrescido dos

elementos que não causam atraso no ciclo, mas causam delay.

Assim, é preciso considerar tanto o atraso do Arduino para oXBee como do outro

XBee para o PC. Além de considerar o delay referente à comunicação entre os XBee’s

1052 2,08

250 /delayXBee

bitsT ms

kbits s= • = (23)

Gerando um delay total de:

57

2,08 0,694 1,736 15,1delayTOTAL cicloTx delayXBeeT T ms ms ms T ms= + + + + = (24)

2.6. Firmware

Neste sub-capítulo, a solução ao problema descrito no item 2.2.4.

A solução encontrada foi utilizar o timer1 no modo captura, para contar o intervalo

de tempo entre pulsos referentes à freqüência de rotação da roda dianteira esquerda. Para

rpm, a solução encontrada foi utilizar interrupção externa, em conjunto com um timer, de

modo a determinar o intervalo de tempo em que a vela é acionada.

Entretanto, interrupções não foram habilitadas, para não interferir em conversões e

transmissões. O que foi feito são verificações para determinar se pulsos ou overflows

ocorreram.

Em ambos os casos, a informação é processada o mais breve possível após o pulso.

2.6.1. Velocidade

Configurado com prescaler de 1:1024. O que significa que o clock com que o

timer1 trabalha será dividido por 1024, gerando nesse caso uma freqüência efetiva de

15625 Hz.

164T s

fµ= = (25)

Segundo a equação (25), a cada 64 µs o valor do contador do timer1 (TCNT1)

incrementa em 1. Sabendo que este contador tem 16 bits (65536 contagens), determina-se

que a capacidade se esgota em:

64 65536 4,2MAXT s sµ= × (26)

58

Pode-se então, calcular qual a menor velocidade possível de se medir sem estourar

a capacidade do contador. Pela equação (14), se 1 rotação demorar 4,2 segundos, a

velocidade será de:

0,45 0, 450,107 / 3,6 0,386 /

4, 2 4,2MIN MIN

m mVel m s ou Vel km h

s s= = × = (27)

Valores realmente baixos, ou seja, não é necessário passar da capacidade padrão.

Já para a velocidade máxima, considera-se o menor intervalo de tempo detectável,

que segundo a equação (26) é de 64 µs.:

0, 45 0,457031,25 / 3,6 25312,5 /

64 64MAX MAX

m mVel m s ou Vel km h

s sµ µ= = = × = (28)

Por outro lado utilizar prescaler reduz a resolução. Para determinar a resolução,

considera-se a diferença entre a máxima e a mínima velocidade, levando em conta a

quantidade de níveis de diferenciação envolvidos. No caso, 65536. Assim, em termos de

velocidade, a resolução é de:

7031,25 0,1070,1073 / 0,3862 /

65536 65536MAX MINVel Vel

R m s R km h− −

= = ⇔ (29)

Conhecendo os limites estabelecidos pelo timer1, resta a verificação de flags. Como

demonstra o fluxograma da Figura 2.12:

59

Figura 2.12 – Fluxograma das verificações de velocidade.

2.6.1. RPM

Para aferição de rpm foi utilizada a interrupção externa INT0 configurada para

borda de descida. O timer0 foi utilizado com prescaler de 1:1024. Entretanto, o timer0 tem

somente 8 bits (256 contagens), sendo necessário contar o número de vezes que sua

capacidade estoura. A Figura 2.13 demonstra a lógica das verificações referentes a rpm.

60

Figura 2.13 – Fluxograma das verificações referentes a rpm.

2.7. Computador

O computador somente receberá os dados dos sensores, que são lidos pelo Arduino

e transmitidos do XBee-Arduino para o XBee-PC, o qual está ligado a entrada USB de um

notebook.

2.7.1. Conexão XBee - PC

A mobilidade é fator chave nesse projeto, logo, descarta-se o uso de um

computador desktop, e consequentemente, entrada serial padrão.

Para conexão entre XBee-PC e o notebook, será utilizada uma placa conversora

CON USBEE, ilustrada na Figura 2.14.

61

Figura 2.14 - Placa para conexão entre XBee-PC e notebook.

A placa adaptadora, além de converter o padrão do XBee para os níveis da USB,

apresenta algumas informações úteis ao usuário, expostas na Figura 2.15:

Figura 2.15 - informação CON USBEE

Três LEDs verdes sinalizam o nível do sinal: abaixo de 10dBm; entre 10 e 20 dBm;

e acima de 20 dBm. [5]

Os LEDs Tx e Rx sinalizam, respectivamente, os momentos em que transmite-se

informação ou recebe-se a informação. Enquanto que o outro diodo emissor de luz sinaliza

se este módulo está ou não associado a uma rede.

62

2.7.2. Software

Neste item está abordada a maneira que os dados chegam à COM do notebook. São

apenas descrições e sugestões para o software.

O sistema de telemetria envia constantemente dados para a porta COM do

computador. Esses dados devem estar sempre na mesma ordem.

Todos pacotes são enviados em formato hexadecimal convertidos para caractere

ASCII. Por exemplo, o número decimal 255 equivalente a 0xFF hexadecimal será enviado

como dois caracteres ‘f’.

Após o valor, sempre é enviado um carriage return e um new line, que devem ser

usados para separar os pacotes. Ao todo são 10 pacotes enviados a cada ciclo, sendo que o

primeiro e o último contém Tags de identificação.

Para o primeiro pacote, só é necessário verificar se seu valor (convertido para

decimal) é superior a 61000.

Para o último pacote, é necessário verificar se seu valor é superior a 53247 e

inferior a 55000.

É importante que o ciclo completo seja validado somente caso as condições do

primeiro e último pacote sejam verdadeiras.

A ordem dos pacotes é a seguinte:

Aceleração Eixo X

Aceleração Eixo Y

Aceleração Eixo Z

Temperatura do Motor

Velocidade

RPM

Suspensão, Dianteira Esquerda

Suspensão, Dianteira Direita

Suspensão, Traseira Esquerda

Suspensão, Traseira Direita

Sendo Aceleração Eixo X o primeiro pacote com tag e o curso de Suspensão, Traseira

Direita o último, assim como o primeiro, com tag.

63

Para interpretar os dados é necessário determinar a relação da conversão

analógico/digital. Sendo a referência 3,3V e o conversor de 10 bits:

3,33,22581

1023

VR mV= (30)

Sabendo disso, é possível definir os cálculos das grandezas convertidas pelo A/D.

Para os 3 eixos do acelerômetro, de acordo com a equação (1) tem-se:

, , [ ]300 / 3,22581 93X Y Z

DADO DADOForça G G

mV mV− = = (31)

Importante lembrar que o DADO referente ao eixo X deve ser subtraído de 0xF000

antes de aplicar a equação (31).

Para temperatura do motor, segundo a equação (2):

[ ]10 / 3, 22581 3,1

DADO DADOTemp C

mV mV= = ° (32)

Velocidade, segundo equação (14):

0,45 0, 45[ / ] 3,6[ / ]

64 64

m mVel m s ou Vel km h

DADO s DADO sµ µ= = ×

× × (33)

Rotações por minuto, de acordo com equações (5) e (25):

60

[ ]64

sRPM rpm

DADO sµ=

× (34)

Os campos referentes à medidas de curso de suspensão devem ficar desativados até

que seu funcionamento seja conhecido. Ainda assim, ao último pacote, Suspensão Traseira

Direita, deve ser subtraído 0xD000 antes de qualquer ação.

64

A idéia inicial era que o software fosse capaz de mostrar o valor de todas as

medidas ao mesmo tempo, atualizando seus valores assim que recebidos. Importante

também, armazenar todos os dados para melhor análise e mobilidade.

Além disso, caso possível, exibir esses valores em um gráfico em função do tempo.

65

CONSIDERAÇÕES FINAIS

Após o estudar o funcionamento, características e configurações dos elementos do

projeto, foi possível identificar o nível de complexidade do mesmo. Muitas aspectos

tiveram de ser levados em conta, decisões sobre qual modelo de XBee necessário,

configurações do mesmo para realizar transmissões de forma mais veloz possível e

adequação de níveis entre Arduino e XBee. Melhores métodos de adquirir informações

como velocidade e rpm, sem contar a decisão de quais grandezas medir e que sensores

utilizar. Também, o método de realizar contagem de pulsos sem interferir tanto nas

conversões A/D quanto nas transmissões foi um desafio.

Por outro lado, conhecer o potencial de componentes como XBee e Arduino abre

um novo leque de possibilidades.

Infelizmente, até a data de entrega deste, não foi possível implementar o projeto.

Uma série de pequenos fatores, indefinições e indecisões atentaram contra a montagem e

instalação do sistema. Pode-se citar a indefinição sobre qual acelerômetro utilizar, devido à

disponibilidade; o novo Baja-SAE estar em processo de montagem, inviabilizando testes; e

indecisão sobre como abordar velocidade e rpm através do Arduino, o que gerou atraso no

desenho da placa de circuito impresso.

Foram feitos testes com Arduino e XBee, utilizando a placa COM USBBee e todos

os itens se mostraram compatíveis.

Os resultados teóricos, entretanto, foram satisfatórios. Conseguiu-se projetar um

sistema com baixo tempo (estimado) de atualização dos dados, pouco menos de 9 ms,

quando o esperado era próximo de 300 ms. Foi possível projetar uma fonte de alimentação

capaz de fornecer energia suficiente para comunicação do XBee-PRO.

Mas, desde o princípio, a intenção foi instalar o Sistema de Telemetria Automotiva

no veículo Baja-SAE da UPF, o que será realizado mesmo após o encerramento da

disciplina.

66

REFERÊNCIAS BIBLIOGRÁFICAS

[1] BELLIS, Mary. Telemetry History of DNS.

Disponível em: <http://inventors.about.com >. Acesso em: 25 abril 2009.

[2] New World Encyclopedia contributors. Telemetry, New World Encyclopedia 2008.

Disponível em: <http://www.newworldencyclopedia.org/entry/Telemetry?oldid=683623>

Acesso em: 29 abril 2009.

[3] HP Formula One. Telemetry gathering at WilliamsF1.

Disponível em: <http://www.f1technical.net/features/685> . Acesso em: 29 abril 2009.

[4] MONTEIRO, Jânio;EY, Emanuel. ZigBee – uma abordagem prática. Universidade do

Algarve. 2008.

[5] MESSIAS, A. Rogério. Controle remoto e aquisição de dados via XBee/ZigBee IEEE

802.15.4 .Disponível em:< http://www.rogercom.com/ZigBee/ZigBee.htm>.

Acesso em: 15 abril 2009.

[6] Colaboradores do VIVASEMFIO.com. ZigBee.

Disponível em:< http://www.vivasemfio.com/blog/zigbee-homerf-modulos-xbee-802154-

xctu-maxstream/>. Acesso em: 20 abril 2009.

[7] ZigBee Alliance. ZigBee Specification, Feature Set.

Disponível em:<http://www.zigbee.org>. Acesso em: 20 março 2009.

[8] Arduino Project. Getting started, Reference, Hardware, FAQs.

Disponível em: <http://www.arduino.cc>. Acesso em: 14 março 2009.

67

[9] GASCÓN, David. 802.15.4 vs ZigBee. Disponível em:<http://www.sensor-

networks.org/index.php?page=0823123150> . Acesso em: 3 maio 2009.

[10] TORRES, Gabriel. Tecnologia da AMD nos Carros da Formula1 da Ferrari. Disponível em: <http://www.clubedohardware.com.br/artigos/1293>. Acesso em: 15 maio 2009.

[11] Colaboradores da WIKIPÉDIA. LVDT. Disponível em: <http://pt.wikipedia.org/wiki/LVDT> . Acesso em: 2 junho 2009.

Analog Devices. ADXL330 Datasheet. 2006. Disponível em: <www.analog.com>.

Alegro Microsystems. A3240 Datasheet. 2000. Disponível em: <www.alegromicro.com>.

Atmel Corporation. ATmega168 Datasheet. 2009. Disponível em: <www.atmel.com>.

Fairchild Semiconductor. KA78XX Datasheet. 2001. Disponível em:

<www.fairchildsemi.com>.

Unisonic Technologies. UTC 4053 Datasheet. Disponível em: <www.unisonic.com.tw>.

National Semiconductor. LM1117 Datasheet. 2006. Disponível em: <www.national.com>.

National Semiconductor. LM35 Datasheet. 2000. Disponível em: <www.national.com>.

MaxStream Inc. XBee OEM RF modules Product Manual. 2006. Disponível em:

<www.maxstream.net>.

ANEXO A – Esquema elétrico do Arduino Duemilanove

ANEXO B – Firmware utilizado no Arduino Duemilanove

• Rotina escrita para o ambiente de programação Arduino.

• Versão do compilador: Arduino – 0016.

Descrição de algumas funções do compilador:

pinMode(n,OUTPUT ou INPUT) – define se o pino n é entrada ou saída.

analogRead(n) – lê valor analógico do pino n.

Serial.println(dado,HEX) – envia dado pela serial em formato hexadecimal. Após o

dado é enviado uma Carriage Return (\r) e New Line (\n).

digitalWrite(n,nível lógico) – coloca pino n como nível lógico alto ou baixo.

int captura=8; // Velocidade

int xpin = 0; // x-axis

int ypin = 1; // y-axis

int zpin = 2; // z-axis

int xMux = 3; // Saida X do mux

int yMux = 4; // Saida Y do mux

int zMux = 5; // Saida Z do mux

int ext0 = 2; // Interrupção externa 0

int Tx = 1;

int Rx = 0;

int Ax = 5; //Seleção mux

int By = 6; //Seleção mux

int Cz = 7; //Seleção mux

unsigned int vel;

unsigned int rpm;

void setup()

Serial.begin(115200); //Inicia serial em 115200 bps

pinMode(captura, INPUT); //configura PB0 como entrada

pinMode(ext0, INPUT); //configura INT0 como entrada

pinMode(xpin, INPUT); //

pinMode(ypin, INPUT); //

pinMode(zpin, INPUT); //

pinMode(xMux, INPUT); //

70

pinMode(yMux, INPUT); //

pinMode(zMux, INPUT); //

pinMode(Tx, OUTPUT); //

pinMode(Rx, INPUT); //

pinMode(Ax, OUTPUT); //

pinMode(By, OUTPUT); //

pinMode(Cz, OUTPUT); //

TCCR1B=0x0E; //TOP do cont= OCR1A, limpa TCNT1 auto, pre-scaler 1024, borda de descida

OCR1A=0xFFFF;

EICRA=0x02; //Configura INT0 por borda de descida

EIMSK=0x00; //Sem Interrupções externas

TCCR0B=0x05;

digitalWrite(Ax,0); //Seleciona X0 como saída de X

GPIOR0=0x00; //Registrador de uso geral0. Valores aceitáveis: 0x00 a 0x1F

void loop()

//TAG 0xF000 para identificar o primeiro pacote de dados do ciclo Acelereção Eixo-X

Serial.println((analogRead(xpin)+0xF000),HEX);

verifica(); //Verifica por pulsos (ou overflows) referentes a velocidade e rpm

Serial.println(analogRead(ypin),HEX); // Acelereção Eixo-Y

verifica();

Serial.println(analogRead(zpin),HEX); // Acelereção Eixo-Z

verifica();

Serial.println(analogRead(xMux),HEX); //Entrada X0 do mux Temperatura do motor

verifica();

Serial.println(vel,HEX); // Velocidade

verifica();

Serial.println(rpm,HEX); // RPM do motor

digitalWrite(By,0); //Selecionando Y0 como saída de Y

digitalWrite(Cz,0); //Selecionando Z0 como saída de Z

verifica();

Serial.println(analogRead(yMux),HEX); // Curso da suspensão, Dianteira Esquerda

verifica();

Serial.println(analogRead(zMux),HEX); // Curso da suspensão, Dianteira Direita

verifica();

digitalWrite(By,1); //Selecionando Y1 como saída de Y

Serial.println(analogRead(yMux),HEX); // Curso da suspensão, Traseira Esquerda

verifica();

71

digitalWrite(Cz,1); //Selecionando Z1 como saída de Z

//TAG 0xD000 para identificar o último pacote de dados do ciclo - Curso da suspensão, Traseira Direita

Serial.println((analogRead(zpin)+0xD000),HEX);

verifica();

void verifica(void)

if(ICF1==1)

vel=ICR1; //+(cont1*65536); //Atualiza valor de vel conforme contagem

TIFR1=0x20; //limpa o flag ICF1

else if(TOV1==1)

vel=0; //Se não houver captura durante 4 segundos, considera velocidade = 0

TIFR1=0x01; //limpa o flag TOV1

if(INTF0==1)

//Atualiza valor de contagens considerando numero de overflows do timer0

rpm=TCNT0+(256*GPIOR0);

EIFR=0x01; //Limpa flag da INT0

TIFR0=0x01; //Limpa flag TOV0

GPIOR0=0; //Zera contagem de overflow do timer0

TCNT0=0x00;

else if(TOV0==1)

GPIOR0++; //Conta overflows do timer0

EIFR=0x01; //Limpa flag TOV0

//Caso não haja 1 rotação a cada meio segundo (menor que 120 rpm), considera como zero

if(GPIOR0>=30) rpm=0;

72

ANEXO C – Teste A/D do Arduino

Utilizando o esquema da Figura C.1, foi realizado um teste para verificar o

funcionamento das entradas analógicas.

Figura C.1 - Teste do conversor A/D

Primeiramente o potenciômetro seleciona 0V. Depois da primeira medição, um

valor intermediário e por fim 5V. A rotina e os resultados estão expressos na Figura C.2.

Figura C.2 - rotina e resultados.

Os valores das conversões são enviados ao Serial Monitor (fundo preto), que

representa o Hyperterminal. Os valores estão de acordo com o esperado.

73

ANEXO D – Teste Interrupção Externa do Arduino

Utilizando a chave de efeito Hall conectada ao pino referente à interrupção externa

0 (pino digital 2 do Arduino), como proposto no item 2.1.4. Obteve-se o resultado exposto

pela Figura D.1.

Figura D.1 - rotina e resultado.

Com a rotina da Figura D.1, o Arduino fica esperando uma interrupção externa por

borda de descida. Quando isso acontece (pólo sul de um imâ se aproxima da chave Hall), a

interrupção externa 0 é ativada. Então, a rotina de tratamento (show) envia a expressão:

Interrupt Externa 0 para a serial.

74

ANEXO E – Teste do Modo Captura do Arduino

Utilizando a chave de efeito Hall conectada ao pino referente ao modo Captura

(pino digital 8 do Arduino), como proposto no item 2.1.4. Obteve-se o resultado exposto

pela Figura E.1.

Figura E.1 - rotina e resultados.

Pela rotina da Figura E.1 o Arduino espera por uma borda de descida no pino

referente à Captura. Quando esse pulso ocorre, o valor de contagens do timer é copiado

para o registrador ICR1. Este valor, então, é enviado pela serial.