rede can para estimativa de orientação e posição de...

Daniel Diegues

Rede CAN para Estimativa de Orientação ePosição de Máquinas Agrícolas

São Carlos

2014

Daniel Diegues

Rede CAN para Estimativa de Orientação e Posição deMáquinas Agrícolas

Trabalho de Conclusão de Curso apresentadoao Departamento de Engenharia Elétrica daUniversidade Federal de São Carlos, comoparte dos requisitos para obtenção do grauem Engenharia Elétrica.

Universidade Federal de São Carlos – UFSCar

Departamento de Engenharia Elétrica

Graduação em Engenharia Elétrica

Orientador: Prof. Dr. Roberto Santos Inoue

São Carlos2014

Agradecimentos

Primeiramente a Deus e Maria que foram a forte rocha que me apoio em todos osmomentos da minha vida e durante toda a graduação.

De modo especial aos meus pais e irmão que sempre me ajudaram em todos osmomentos de minha vida. À minha noiva pela paciência, companheirismo e atenção, emespecial nos momentos em que o trabalho me afadigou.

Ao Professor Doutor Roberto Santos Inoue pelo tempo dedicado, por acreditar nomeu trabalho e dar as condições para a sua realização.

Ao Professor Doutor Arlindo Neto Montagnoli que me auxiliou muito no início daminha graduação e é parte fundamental da minha formação e inserção no mundo científico.

Aos membros da banca pela contribuição e tempo dedicados a esse trabalho.

Aos professores e técnicos do Departamento de Engenharia Elétrica por todo oapoio e aprendizado concedidos.

Aos amigos da turma pelos bons momentos vividos juntos, em especial PauloRoberto e Rafael Minutti que acompanharam mais de perto o desenvolvimento destetrabalho.

“Portanto, não se preocupe com o dia de amanhã,pois o dia de amanhã terá suas preocupações.

Basta a cada dia a própria dificuldade.”(Bíblia Sagrada, Mateus 6, 34)

ResumoCom o crescimento da agricultura de precisão, o emprego de sistemas de navegação com GPS(Global Positioning System) em veículos agrícolas tem se tornado cada vez mais necessário,com níveis elevados de exigências ligados à confiabilidade e exatidão.Acompanhando essecrescimento, vem o uso intensivo da eletrônica embarcada nas máquinas agrícolas. Comisso, surgem dois quadros, a necessidade de localização de sistemas móveis com elevadaprecisão e a integração dessa eletrônica embarcada de forma eficaz. Para o problemade localização, tem-se utilizado a fusão de sinais de uma IMU (Inertial MeasurementUnit) e de um receptor GPS para a estimativa de posição e orientação do veículo. E paraa integração da eletrônica embarcada tem-se utilizado redes de campo, sendo o CAN(Controller Area Network) o protocolo de baixo nível mais proeminente nessa área. Dessaforma, nesse trabalho de conclusão de curso é desenvolvido um protótipo de uma rede CANconectando três ECUs (Eletronic Central Unit). Duas ECUs realizam a aquisição dos dadosdos sensores e enviam para a ECU central que realiza o processamento e disponibiliza osdados para o computador. Com o desenvolvimento dessa rede foi possível avaliar os atrasoscausados na recepção dos dados pela ECU central, bem como levantar as vantagens edesvantagens de uma arquitetura modular descentralizada.

Palavras-chaves: Rede CAN, GPS, IMU, microcontrolador.

AbstractWith the growth of precision agriculture, the use of navigation systems with GPS (GlobalPositioning System) in agricultural vehicles has become increasingly necessary, withhigh levels of requirements associated with reliability and accuracy. With this growthcomes intensive use of embedded electronics in agricultural machines. Thus, there are twosituations, the need for location of mobile systems with high precision and integration ofelectronic circuitry of an efficient way. For the localization problem, has been used thefusion of a IMU (Inertial Measurement Unit) signal and a GPS receiver to estimate theposition and orientation of the vehicle. And for the integration of embedded electronics hasbeen used fieldbuses, and the CAN (Controller Area Network) the most prominent low-levelprotocol in this area. Thus, in this work is developed a prototype of a CAN networkconnecting three ECU (Electronic Central Unit). Two ECU perform data acquisition fromthe sensors and send to the central ECU that performs processing and provides the data tothe computer. With the development of this network it can evaluate the delays in receivingdata by the central ECU and indicate the advantages and disadvantages of a decentralizedmodular architecture.

Key-words: CAN bus, GPS, IMU, microcontroller.

Lista de ilustrações

Figura 1 – Cabine com instrumentos sem padrão (NISSEN, 2008 apud SUZUKI,2012) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figura 2 – Representação de uma arquitetura centralizada . . . . . . . . . . . . . 24Figura 3 – Representação de uma arquitetura distribuída . . . . . . . . . . . . . . 24Figura 4 – Camadas da rede CAN. Adaptado de: Bosch Gmbh (1991). . . . . . . . 27Figura 5 – Níveis dos Sinais Elétricos ISO 11898-2. Retirado de: Di Natale et al.

(2012) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 6 – Tempo de bit nominal. Adaptado de: Di Natale et al. (2012) . . . . . . 31Figura 7 – Quadro de dados Fonte: Sousa (2002). . . . . . . . . . . . . . . . . . . 33Figura 8 – Quadro remoto CAN 2.0b. Retirado de: Sousa (2002). . . . . . . . . . . 34Figura 9 – Estados de erros possíveis. Retirado de: Sousa (2002). . . . . . . . . . . 35Figura 10 – Exemplo do processo de arbitragem. Retirado de: Di Natale et al. (2012). 36Figura 11 – Ilustração do conceito de multicast. Retirado de: CiA (2002). . . . . . . 37Figura 12 – Máscara e filtro para mensagem CAN. Adaptado de: Di Natale et al.

(2012). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 13 – Topologia do protótipo da rede de testes. . . . . . . . . . . . . . . . . . 42Figura 14 – Topologias de ECU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figura 15 – Esquemático do circuito utilizado para as ECUs. . . . . . . . . . . . . 45Figura 16 – Placa do circuito utilizado para as ECUs. . . . . . . . . . . . . . . . . 46Figura 17 – Circuito do conversor de nível bidirecional. Retirado de: NXP Semicon-

ductors (2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 18 – Placa receptor de GPS. Retirado de: SparkFun Electronics Inc. (2002). 48Figura 19 – Esquemático da união na memória. . . . . . . . . . . . . . . . . . . . . 51Figura 20 – Placa da IMU. Retirado de: SparkFun Electronics Inc. (2002). . . . . . 51Figura 21 – Fluxograma da função principal da IMU. . . . . . . . . . . . . . . . . . 52Figura 22 – Sinais CAN L e CAN H obtidos da rede implementada. . . . . . . . . . 55Figura 23 – Medida de atraso da rede de testes. . . . . . . . . . . . . . . . . . . . . 56

Lista de tabelas

Tabela 1 – Características físicas da norma SAE J1939. Adaptado de: Di Natale etal. (2012). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Tabela 2 – Regras práticas da norma ISO 11898 para comprimento do barramentoem função da taxa de transmissão. Adaptado de: Ferreira e Fonseca(2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Tabela 3 – Dicionário de dados da rede. . . . . . . . . . . . . . . . . . . . . . . . . 42Tabela 4 – Descrição dos campos da mensagem NMEA 0183 GPGGA. Modificado

de: SKYTRAQ Technology Inc. (2008). . . . . . . . . . . . . . . . . . . 49Tabela 5 – Descrição dos campos da mensagem NMEA 0183 GPVTG. Modificado

de: SKYTRAQ Technology Inc. (2008). . . . . . . . . . . . . . . . . . . 49

Lista de abreviaturas e siglas

CAN Controller Area Network

GPS Global Position System

IMU Inertial Measurement Unit

INS Inertial Navegation System

ECU Electronic Control Unit

ISO International Starndards Organization

OSI Open Systems Interconnection

SAE Society of Automotive Engineers

TTCAN Time-Triggered CAN

FTT-CAN Flexible Time-Triggered CAN

NRZ Non Return to Zero

CSMA/NDBA Carrier Sense Multiple Acess/Collision Detection

SRR Substitute Remote Request

SOF Start of Frame

RTR Remote Transmission Request

DLC Data Length Code

CRC Cyclic Redundance Check

ACK Acknowledge

EOF End of Frame

IMO Inconsistent Message Omissions

IMD Inconsistent Message Duplicates

BER Bit Error Rate

UTC Universal Time Coordinated

USART Universal Synchronous Asynchronous Receiver Transmitter

TTL Transistor-Transistor Logic

LVTTL Low Voltage Transistor-Transistor Logic

USB Universial Serial Bus

NMEA National Marine Electronics Association

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 ARQUITETURA DA ELETRÔNICA EMBARCADA E CONCEITOSDE REDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1 Arquitetura centralizada . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2 Arquitetura distribuída . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3 Sistemas embarcado na agricultura de precisão . . . . . . . . . . . . 252.4 Conceitos básicos em redes de comunicação . . . . . . . . . . . . . . 26

3 A REDE CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1 Camada física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.1 Codificação dos bits e níveis de sinal . . . . . . . . . . . . . . . . . . . . . 303.1.2 Temporização dos bits e sincronização . . . . . . . . . . . . . . . . . . . . 313.2 Camada de enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.1 Tipo de quadros da mensagem CAN . . . . . . . . . . . . . . . . . . . . . 333.2.2 Detecção, controle e sinalização de erros . . . . . . . . . . . . . . . . . . . 353.2.3 Mecanismo de acesso ao meio . . . . . . . . . . . . . . . . . . . . . . . . 363.2.4 Filtro e aceitação de mensagens . . . . . . . . . . . . . . . . . . . . . . . 373.3 Limitações da CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.4 A CAN na agricultura . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 IMPLEMENTAÇÃO DA REDE DE TESTES . . . . . . . . . . . . . 414.1 Topologia geral da rede . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Arquitetura genérica das ECUs . . . . . . . . . . . . . . . . . . . . . . 434.2.1 Módulo ECAN do PIC18F2580 . . . . . . . . . . . . . . . . . . . . . . . . 444.2.2 Transceptor MCP2551 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.3 Conversor bidirecional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3 ECU do GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.4 ECU da IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.5 ECU computador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5 AVALIAÇÃO DA REDE E RESULTADOS . . . . . . . . . . . . . . . 555.1 Sinais elétricos da rede CAN . . . . . . . . . . . . . . . . . . . . . . . 555.2 Monitoramento de erros . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.3 Atraso nos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 576.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

APÊNDICES 61

APÊNDICE A – CÓDIGO MAIN ECU DO PC . . . . . . . . . . . 63

APÊNDICE B – CÓDIGO MAIN ECU DA IMU . . . . . . . . . . . 69

APÊNDICE C – CÓDIGO MAIN ECU DA GPS . . . . . . . . . . . 75

APÊNDICE D – CÓDIGOS BIBLIOTECA DA IMU . . . . . . . . . 79

APÊNDICE E – CÓDIGOS BIBLIOTECA DO GPS . . . . . . . . . 87

APÊNDICE F – CÓDIGOS BIBLIOTECA ECAN . . . . . . . . . . 97

19

1 Introdução

1.1 MotivaçãoA agricultura de precisão tem como objeto de estudo a lavoura com suas variabi-

lidades e fazendo uso de técnicas e métodos procura obter ganhos econômicos e menorimpacto ambiental. Hoje, especialmente no Brasil o foco tem sido principalmente nasaplicações a taxas variáveis de fertilizantes e corretivos, mas sem perder o foco na gestão(PEREIRA, 2008; INAMASU, 2013; MOLIN, 2013). Este conceito vem sendo utilizadocomo uma das respostas aos desafios enfrentados pelos produtores agrícolas brasileiros,que em uma economia cada vez mais globalizada, um ambiente de acirrada competição eum aumento contínuo da demanda por alimentos, se torna vital a aplicação de processosmais eficientes, com custos financeiros e ambientais cada vem menores. Além disso, osmercados consumidores tornam-se mais exigentes nas questões de rastreabilidade, segu-rança alimentar, sustentabilidade e energia renovável. É interessante notar que o Brasilsai na frente no que diz respeito à capacidade de responder ao crescimento na demanda,pois são poucos os países no mundo que possuem recursos naturais tão intensos quanto osbrasileiros (JUNTOLLI, 2013).

Porém a agricultura de precisão só pôde ser viável na prática com a aplicação daeletrônica embarcada nas máquinas agrícolas, como tratores, colhedoras e implementos.No entanto com o passar do tempo, essa utilização massiva da tecnologia embarcada setornou um amontoado de fios, telas e dispositivos eletrônicos na cabine do trator, tornandoa operação complicada e dificultando a difusão desses sistemas (INAMASU, 2013).

Figura 1 – Cabine com instrumentos sem padrão (NISSEN, 2008 apud SUZUKI, 2012)

A falta de padrão entre os fabricantes e uma arquitetura convencional da eletrônica

20 Capítulo 1. Introdução

embarcada, onde cada dispositivo, sensor ou atuador, possui sua própria interface com ousuário e meio de comunicação, se tornam fatores determinantes desse fenômeno ilustradona Figura 1, onde pode ser vista uma cabine com a eletrônica embarcada sem padronização(PEREIRA, 2008).

Diante desse panorama torna-se desejável encontrar novas formas de conceber essessistemas. Hoje vem sendo observada um tendencia de utilizar uma arquitetura distribuídaem conjunto com uma instrumentação inteligente. Esse conceito traz vantagens, comoo aumento da confiabilidade, com a detecção e correção automática de falhas, além deautocalibração, preprocessamento e controle distribuído (STRAUSS, 2001).

O protocolo de comunicação digital mais destacado para essa aplicação é o CAN(Controller Area Network), que é implementado nos automóveis desde a década de 80,quando passavam pelos mesmos problemas citados na área agrícola. Além disso, o CAN setornou uma opção lógica por atender aos requisitos de robustez, exigidos pelo ambiente deaplicação, velocidade, compactação e simplificação por ser um protocolo a dois fios e a suarastreabilidade possuir mecanismos de identificação unívocos dos dispositivos conectados.Como evidências fortes dessa escolha, pode-se observar o surgimento de normas como, aDIN 9684, a SAE J1939 e mais recentemente, com um apelo de padrão aberto buscandoaumentar a interoperabilidade dos sistemas, a ISO 11783, ainda segundo Sousa (2002),mesmo o CAN já sendo utilizado por muitos fabricantes e se mostrar uma tecnologiabastante promissora, existe uma necessidade de estudar as topologias, as prioridades decada sensor e atuador, além dos circuitos integrados e controladores que mais se adaptemà aplicação em agricultura de precisão.

Molin (2013) enfatiza que, o surgimento do sistema norte americano de posicio-namento global o GPS (Global Position System), foi que possibilitou e impulsionou aimplementação da agricultura de precisão, já que a criação de mapas, o conhecimentogeográfico de cada área e a localização das máquinas durante o as operações, são peçasfundamentais, tanto para a atuação, como para a gestão na lavoura. Nota-se também, quedesde o início da utilização foram impressos esforços no sentido de melhorar a precisão dalocalização e a confiabilidade do GPS. Como por exemplo, com a utilização de correçãodiferencial em tempo real, "barras de luz", que auxiliavam a aviação agrícola e outrastécnicas que exigiam receptores de GPS muito específicos, por vezes incompatíveis com oscontroladores utilizados. Portanto é possível inferir que o estudo na área de navegaçãocom estimativa de posição e orientação são muito importantes para esse setor, e uma dasformas estudadas atualmente é a fusão do receptor de GPS com os sinais dos sensoresinerciais de uma IMU (Inertial Measurement Unit), formando um sistema inercial deauxilo à navegação, INS (Inertial Navegation System) (INOUE, 2012; FARRELL, 2008).

Sendo o Brasil um país com grande potencial para se tornar um expoente naagricultura mundial, acrescido do grande uso da rede CAN em máquinas agrícolas e aliado

1.2. Objetivos 21

ao papel fundamental das informações sobre posicionamento e orientação de máquinasagrícolas em campo, esse projeto de conclusão de curso visa compartilhar os sinais de umreceptor GPS e de uma IMU em uma rede CAN para a estimativa de posição e orientaçãode um veículo agrícola. E vislumbrar possíveis aplicações na área de agricultura de precisão.

1.2 ObjetivosEste trabalho tem como objetivo principal o estudo do protocolo CAN e sua

aplicação nas máquinas agrícolas, bem como possibilitar ao aluno o contato com ossensores inerciais da IMU e do receptor de GPS, desenvolvendo o tratamento inicial dosdados brutos fornecidos por esses sensores diretamente no firmware das ECUs (ElectronicControl Unit) conectadas a rede.

De encontro com esse objetivo, procura-se desenvolver uma plataforma de testesde uma rede CAN onde esses sensores são conectados e realizam a comunicação comuma central conectada ao computador. Com esse desenvolvimento tem-se os objetivosde, estudar todos os requisitos de implementação de uma rede nesse protocolo, desde aespecificação dos circuitos integrados e a topologia da rede, passando pelo desenvolvimentodo software embarcado e as condições de funcionamento do protocolo, chegando até aoestudo da latência das mensagens, a melhor forma de realizar o tratamento dos dados e apriorização das mensagens.

23

2 Arquitetura da eletrônica embarcada e con-ceitos de rede

Eletrônica embarcada, de maneira geral, são chamados as formas de conexão eimplementação de diversos mecanismos de medição e controle em um determinado sistemaembarcado (GUIMARÃES, 2003). E considerando o crescimento da presença de sistemaseletrônicos, instrumentação inteligente e controle distribuído em automóveis, máquinasagrícolas, aeronaves, robôs, e sistemas embarcados de modo geral, torna-se importanteavaliar como esses diversos dispositivos são interconectados, quais são as ações necessáriaspara realizar a manutenção e atualização do sistema, e como os dados gerados por elessão armazenados, processados e protegidos de erros e ruídos. Portanto, nessa seção seráapresentado, o conceito de arquitetura centralizada e distribuída bem como suas vantagense desvantagens e por fim alguns conceitos básicos de rede que serão utilizados neste trabalhocomo o modelo de referência OSI, o conceito de fieldbus e protocolo de comunicação.

2.1 Arquitetura centralizada

O sistema convencional, que tem sido muito utilizado em diversas aplicações é aarquitetura centralizada, também chamado de não multiplexado (MARQUES, 2004), ondeuma única ECU central fica responsável pela leitura de todas as entradas, e o controlede todas as saídas. Neste tipo de sistema, os sinais gerados por cada um dos sensoresexistentes na aplicação é transmitido individualmente até a central, onde será processado.Assim como as saídas, que são todas acionadas diretamente pela única ECU existente nosistema.

O diagrama da Figura 2 apresenta um esquema típico da arquitetura centralizada,onde os dispositivos são ligados em uma estrutura ponto a ponto, indo de onde estãoinstalados fisicamente até a central. Por exemplo, no caso em que se deseja disponibilizaros dados de medida de velocidade de um encoder fixado na roda de um implemento, seránecessário ligar o encoder através de um conjunto de fios até a central de processamentolocalizada na cabine do trator.

Esta arquitetura possui as vantagens de um hardware mais simplificado, uma vez queapenas um elemento do sistema necessita de programação e os demais elementos, sensorese atuadores com seus respectivos cabeamentos, enviam ou recebem dados a todo momentoque o sensor disponibilizar ou a ECU central enviar comandos para os atuadores, sem anecessidade de lógicas de varredura ou latência de transmissão e recepção de dados. Poroutro lado, apresenta uma grande quantidade de cabeamento, com diferentes especificações

24 Capítulo 2. Arquitetura da eletrônica embarcada e conceitos de rede

Figura 2 – Representação de uma arquitetura centralizada

dependendo do tipo de sensor ou atuador e além disso apresenta uma limitação de expansão,já que a central é limitada em capacidade física e lógica (GUIMARÃES, 2003).

2.2 Arquitetura distribuída

Uma outra forma de se projetar um sistema com eletrônica embarcada é a chamadaarquitetura distribuída, ou sistema multiplexado (MARQUES, 2004), neste caso ECUsinteligentes estão distribuídas por toda a aplicação, sendo cada uma responsável porparte dos dados e do controle, normalmente, que estão fisicamente próximos a ela, ou quepertençam ao mesmo conjunto de informações, por exemplo, uma ECU responsável pelainstrumentação do motor, ou pelas luzes dianteiras do veículo.

Figura 3 – Representação de uma arquitetura distribuída

2.3. Sistemas embarcado na agricultura de precisão 25

Na Figura 3 é ilustrado um sistema com arquitetura descentralizada, onde podeser visto diversas ECUs, sendo que neste caso possui uma que desempenha um papel decentral, mas está ligada ao mesmo barramento das demais, e outras que possuem entradas esaídas ponto a ponto, mas que estariam próximas ao locais dos elementos a ela conectadas.

Como vantagens dessa arquitetura pode-se citar, o cabeamento reduzido, possibi-litado pela instalação da ECU próxima aos sensores e atuadores e com a comunicaçãoentre eles sendo realizada por um barramento reduzido, ampla capacidade de expansão dosistema, já que para inserir novos elementos basta configurá-los adequadamente e conectarao barramento, possibilita a utilização de protocolos inteligentes, que pode aumentar aconfiabilidade do sistema, "modularização"do projeto, que pode gerar interoperabilidadeentre os fabricantes, podendo facilitar a validação do sistema já que cada módulo pode servalidado de maneira independente, antes de ser integrado a rede (GUIMARÃES, 2003).

Porém, esta arquitetura exige um software de controle da rede, o que acarreta umincremento na complexidade do projeto, sendo o protocolo escolhido intimamente ligadoao quanto esse incremento será significativo, outro fator encarado como uma desvantagemdesse método, é a determinação da taxa de transmissão ideal para cada aplicação, já queesse dado influencia diretamente no desempenho do sistema, na escolha dos componentese no custo de implementação.

2.3 Sistemas embarcado na agricultura de precisão

Na agricultura de precisão a utilização de equipamentos para monitoramento econtrole, aliado a necessidade de dados rastreáveis, capazes de alimentar os sistemas degerenciamento da lavoura, são essenciais. Além disso é importante que os equipamentossejam de fácil manutenção, com interoperabilidade entre os fabricantes, para que o sistemanão se torne inoperante caso ocorra algum problema com um dos dispositivos ou fabricantes(GUIMARÃES, 2003).

É importante notar que no campo os sistemas estão instalados em veículos emmovimento, que trafegam sobre terrenos irregulares, com poeira, umidade e extremosde temperatura, além dessas condições, o implemento e o trator são frequentementedesconectados e reconectados em diversas configurações (STRAUSS, 2001).

Assim, torna-se uma grande questão a quantidade e complexidade dos cabosutilizados nas conexões dos diversos dispositivos embarcados. Segundo Strauss (2001), écomum encontrar sistemas que misturam sensores analógicos com informações digitaise conectores diferentes para cada tipo dispositivo. Resultando em um sistema de difícilmanutenção, com elevado risco de falhas e danos tanto mecânicos como de ruídos elétricos.

Com isso, nota-se que a utilização de uma arquitetura descentralizada com trans-

26 Capítulo 2. Arquitetura da eletrônica embarcada e conceitos de rede

missão digital de sinais, com protocolo de rede que possibilitem a detecção e correçãode falhas, bem como a diminuição desses problemas com cabeamento é extremamentenecessário e a CAN tem sido uma tendência (SOUSA, 2002; INAMASU, 2013).

2.4 Conceitos básicos em redes de comunicaçãoA definição de alguns termos e conceitos básicos sobre redes de comunicação se

tornam importantes para a discussão e correto entendimento dos itens que se seguirãoneste trabalho.

O modelo de referencia OSI (Open Systems Interconnection) é baseado na propostada ISO (International Starndards Organization), que busca direcionar os protocolos derede para uma padronização internacional. Este modelo trata da interconexão de sistemasabertos, ou seja, dos sistemas que de alguma forma realizam uma comunicação com outrossistemas . A grande característica do modelo OSI é a divisão e especificação de setecamadas de rede. É importante salientar que um determinado protocolo, não precisanecessariamente especificar todas as sete camadas. Essas camadas são denominadas porcamada física, de enlace dos dados, rede, transporte, sessão, apresentação e aplicação,começando pela especificação do barramento elétrico na rede, chegando até a mais abstratadelas (TANENBAUM, 2003).

O termo fieldbus é tradicionalmente utilizado para definir as redes digitais seriaismultiponto de conexão entre os dispositivos de campo, como sensores e atuadores, eos sistemas de controle, como computadores industriais, controladores programáveis eterminais de supervisão . Com o tempo, esse conceito se expandiu para outras áreasalém das indústrias e tem sido aplicado para todas as redes com controle distribuído etransdutores inteligentes (SOUSA, 2002).

Tanenbaum (2003) de maneira sucinta, apresenta outra definição importante a serrealizada largamente utilizada em redes de comunicação das mais diferentes naturezas. Oconceito de protocolo de comunicação, que entende-se pelo acordo entre as partes de comoserá dada a comunicação, definindo um conjunto de regras entre elas, destaca-se tambémque a violação do protocolo dificultará a comunicação ou até a tornará impossível.

27

3 A rede CAN

A rede CAN - Controller Area Network ou Rede de Área de Controle, pode sercategorizada como uma rede do tipo fieldbus, desenvolvida na década de oitenta por RobertBosch para interconexão entre dispositivos dos automóveis leves. Porém, em pouco tempoeste padrão foi levado para outras áreas de aplicação como caminhões, ônibus, barcos,satélites, máquinas agrícolas, de construção civil e militares, além de outros padrões nasáreas de automação industrial, robótica e instrumentação médica (SOUSA, 2002).

Figura 4 – Camadas da rede CAN. Adaptado de: Bosch Gmbh (1991).

Em Bosch Gmbh (1991) é apresentado o protocolo CAN divido em três camadas,física, objeto e transporte, como mostra a Figura 4. As camadas de objeto e de transferênciasão equivalentes a camada de enlace de dados do modelo OSI.

Com o surgimento de novas aplicações e a relativa limitação do protocolo básico,outros protocolos foram propostos para cada aplicação, contemplando as mais diversasáreas, definindo novos conceitos para as camadas existentes e implementando outrascamadas do modelo OSI. Exemplos importantes são, o DeviceNet para aplicações emautomação industrial,o ISO 11783 ou ISOBus para aplicações na área agrícola, o CANOpencomo uma proposta de protocolo aberto, além de outros protocolos com característicasespeciais de tempo e codificação, na tentativa de melhorar o desempenho da rede emtermos de velocidade e confiabilidade, podendo citar o TTCAN (Time-Triggered CAN) e

28 Capítulo 3. A rede CAN

o FTT-CAN (Flexible Time-Triggered CAN) (FERREIRA; FONSECA, 2011; Di Nataleet al., 2012)

O CAN é um padrão baseado no paradigma de orientação a mensagem (SOUSA,2002), o que significa que os dispositivos conectados a rede, denominados por nós, nãopossuem endereço, mas são as mensagens que possuem o seu próprio identificador específico,ou seja, considerando um nó de telemetria de um motor, ao invés desse nó possuir umidentificador, na verdade cada uma das informação geradas por ele é que possui umendereço, por exemplo, a temperatura tem o endereço 0x10, o nível de óleo tem endereço0x22 e assim por diante. Porém vale destacar, que cada protocolo, baseado no CAN, defineo endereço das mensagem de uma maneira diferente, sendo assim existem protocolos quedefinem um endereço para cada tipo de dispositivo ou grupo deles dentro de uma rede.

No documento das especificações básicas (Bosch Gmbh, 1991) da CAN a Boschenumera alguns características encontradas nesse protocolo.

• priorização de mensagens - cada mensagem possui um identificador e o valordeste determina a prioridade dessa mensagem sendo que quanto menor o valor maiora prioridade.

• garantia de latência máxima - sabendo o número máximo e um projeto adequadoda rede no que diz respeito a prioridades.

• configuração flexível - como apenas as mensagens possuem um identificador, enão o dispositivo, a remoção ou adição deste na rede é feita sem a necessidade dereconfiguração de nenhum outro dispositivo da rede.

• recepção multicast com sincronização pelos bits - na camada de enlace épossível que cada dispositivo filtre as mensagens recebidas aceitando apenas aquelascom identificador de seu interesse, assim a comunicação pode acontecer para um grupoespecífico dentro de uma mesma rede (conceito de multicast segundo Tanenbaum(2003)).

• sistema com alta consistência - o protocolo busca garantir que todos os nósrecebam as mensagens, ou nenhum nó recebe, caso essa mensagem contenha algumerro, isso é feito através das sinalizações de erro.

• multi-mestre - na CAN um mesmo nó pode ser mestre ou escravo dependendo desua prioridade e da estrutura de projeto da rede.

• detecção e sinalização de erro - mensagens e nós que apresentem alguns deter-minados erros são reconhecidos pelos dispositivos e o erro é sinalizado para todos osoutros nós (detalhes desse processo serão descritos na seção de erros).

3.1. Camada física 29

• retransmissão automática de mensagens corrompidas assim que o barra-mento esteja livre - assim que os erros são detectados existe um mecanismo pararetransmitir porém com limitação de tentativas.

• distinção entre erros temporários e permanentes com desconexão auto-mática dos nós defeituosos.

3.1 Camada física

De maneira geral, a camada física no modelo OSI é responsável por definir ascaracterísticas de bits na rede, como temporização, sinalização, níveis de sinal e a maneiraque esses bits vão ser transmitidos, como fios ou sem fio, conectores e todas as questõesligadas ao meio físico de transmissão. Na norma CAN da Bosch a descrição da camada físicafica limitada a definição da temporização, codificação e sincronização dos bits, sendo que asdemais características, como conectores e os níveis dos sinais, não são cobertas pela norma(Di Natale et al., 2012). Com isso surgiram outras normas que cobriam essas especificações,as principais são da própria ISO e da SAE (Society of Automotive Engineers), sendoimportante destacar, a ISO 11898-2 High Speed a mais utilizada com velocidade de até1Mbps e comprimento de 40m em teoria, a ISO 11897-3 Fault Tolerant com velocidade de125kbps com uso de no máximo 32 e comprimento dependendo da carga no barramento, aSAE J2411 Single Wire com a utilização de um único fio não blindado com velocidademáxima de 33.3kbps e a SAE J1939 com suas características físicas expressas na Tabela 1,essa norma além das especificações da camada física, também são definidas as outras seiscamadas do modelo OSI sendo assim considerado um protocolo de alto nível (Di Natale etal., 2012; FERREIRA; FONSECA, 2011). Esse protocolo foi concebido para aplicaçõesem veículos pesados como ônibus e caminhões e serve de base para o principal protocoloutilizado na agricultura.

Tabela 1 – Características físicas da norma SAE J1939. Adaptado de: Di Natale et al.(2012).

Item DefiniçãoBarramento Par Diferencial

Arbitragem de acesso a rede Aleatório, não destrutivo, bit dominanteVelocidade 250kbps

Máximo de nós 30Topologia Barramento linear

Comprimento do tronco 40mComprimento da derivação 1m

Terminação 2Cabo Par trançado blindado ligado ao terra

Conector 3 pinos não blindado


Apesar dessas limitações impostas pela norma J1939, a ISO 11898, muito difundidaentre os fabricantes de circuitos integrados voltados ao CAN, apresenta a Tabela 2, comregras práticas sobre o comprimento do barramento em função da taxa de transmissão.

Tabela 2 – Regras práticas da norma ISO 11898 para comprimento do barramento emfunção da taxa de transmissão. Adaptado de: Ferreira e Fonseca (2011).

Taxa de Transmissão Comprimento[m]1Mb/s 30800kb/s 50500kb/s 100250kb/s 250125kb/s 50062.5kb/s 100020kb/s 250010kb/s 5000

3.1.1 Codificação dos bits e níveis de sinal

No nível da camada de rede o protocolo CAN usa uma codificação de bit chamadade Non Return to Zero (NRZ), nesta codificação o sinal elétrico permanece constante portodo o período do bit, diferente de outro tipo de codificação como a Manchester, ondeo sinal inverte durante o período, sendo então reconhecida a borda. Além disso, o CANutiliza uma regra de violação de bits chamada Bit-Stuffing (CiA, 2002).

A técnica de bit-stuffing no caso da CAN, considera como erro de transmissãoquando mais de cinco bits consecutivos forem idênticos. Assim, a cada seis bits é possívelprever qual o valor esperado, além disso essa regra é importante para a ressincronizaçãodos nós.

No CAN os níveis dos sinais elétricos seguindo a norma ISO 11898-2 são repre-sentados por, recessivo (usualmente lógico 1) e dominante (usualmente lógico 0) . Assimquando os dois sinais são aplicados no barramento o sinal dominante é que permanece,isso é o que possibilita o mecanismo de acesso ao meio utilizado pela CAN discutido naSeção 3.2.3 Mecanismo de acesso ao meio (Di Natale et al., 2012; SOUSA, 2002).

Como ilustrado na Figura 5 são considerados duas linhas de transmissão (CAN L eCAN H), o nível de tensão elétrica especificado para o bit recessivo é de 2.5V, portanto comuma tensão diferencial próxima de zero, sendo tolerado um valor mínimo de 0.55V para asaída e máximo de 1.5V para a entrada. Já para o bit dominante a linha CAN L deve estarcom 1.5V e a linha CAN H com 3.5V, portanto uma tensão diferencial de 2V sendo toleradoum valor mínimo de 1.5V para a saída e máximo de 4.1V para a entrada. A utilizaçãode sinais diferenciais é chamada de linha balanceada e juntamente com o par trançadoaumenta a robustez da comunicação, minimizando as interferências eletromagnéticas, já

3.1. Camada física 31

Figura 5 – Níveis dos Sinais Elétricos ISO 11898-2. Retirado de: Di Natale et al. (2012)

que assim os ruídos que interferem igualmente nas duas linhas manterão a tensão diferencial(Di Natale et al., 2012).

3.1.2 Temporização dos bits e sincronização

Para garantir a integridade da comunicação com todos os nós lendo o mesmo valorno barramento, o primeiro fato é que o tempo de transmissão do bit deve ser grande osuficiente para que a propagação do sinal alcance ocorra do transmissor até o receptor evolte ao transmissor(CiA, 2002).

Figura 6 – Tempo de bit nominal. Adaptado de: Di Natale et al. (2012)

Para tanto, o tempo de bit é dividido quatro seguimentos (Bosch Gmbh, 1991; DiNatale et al., 2012):

• Segmento de Sincronização (SYNC SEG) - é uma referencia para a sincroni-zação, a borda marca esse seguimento;


• Segmento de Propagação (PROP SEG) - é utilizado para compensar o atrasode propagação físico no barramento;

• Segmento 1 e 2 de Buffer de Fase (PHASE SEG1 e PHASE SEG2) - sãoutilizados para compensar o erro de fase do bit podendo ressincronizar a posição dosegmento de sincronização.

Outra parte importante que pode ser visto na Figura 6 é o ponto de amostragem(SAMPLE POINT), é nesta seção que efetivamente o nível (dominante ou recessivo) é lidodo barramento.

Todos esses segmentos são múltiplos de uma unidade predefinida de tempo chamadade quantum que deriva diretamente no oscilador utilizado na aplicação depois de umprescale, assim no momento de configurar ou projetar uma aplicação de CAN é muitoimportante, para definir a taxa de transmissão, conhecer esse parâmetro.

Cada um dos segmentos possui um comprimento em função do quantum:

• SYNC SEG - 1 quantum;

• PROP SEG - programável de 1 a 8 quantum;

• PHASE SEG1 - programável de 1 a 8 quantum;

• PHASE SEG2 - é o máximo do PHASE SEG1 e o tempo de processamento.

O tempo de processamento é menor ou igual a 2 quantum e o número total de quantumno tempo de bit deve ser entre 8 e 25 (Bosch Gmbh, 1991).

3.2 Camada de enlaceLembrando que na especificação da Bosch essa camada do modelo OSI é definida

em função de duas outras camadas, a camada de transferência e a camada de objeto.Portanto é importante que neste momento se defina com mais clareza cada uma dessascamadas.

A camada de transferência segundo Bosch Gmbh (1991) representa o kernel(núcleo),do protocolo CAN. Essa camada é responsável por apresentar as mensagens recebidasda camada de objeto e enviar as mensagens para a camada de objeto. Também fica acargo desta camada a temporização de bit e sincronização, além de aplicar o quadro nasmensagens, arbitragem das prioridades, acknowledgement (confirmação e reconhecimento),detecção e sinalização de erros e confinamento das falhas. Fica então a cargo da camada deobjeto, filtrar as mensagens segundo seus identificadores, assim como determinar o estadodo nó e o tratamento das mensagens em transito.

3.2. Camada de enlace 33

Existem duas versões do protocolo CAN especificadas pela Bosch, o Padrão denotadopor CAN 2.0A e o Estendido denotado por CAN 2.0B. Estes diferem unicamente pelocomprimento do identificador das mensagens, no primeiro caso é composto por 11 bits eno segundo são adicionados mais 18 bits, totalizando um identificador de 29 bits (BoschGmbh, 1991).

3.2.1 Tipo de quadros da mensagem CAN

No CAN as mensagens são especificadas com quatro tipos diferentes de quadros,definidos de acordo com o conteúdo e a função de cada um (Di Natale et al., 2012).

1. Quadro de Dados - utilizado para fazer a transmissão de dados do nó de origempara o destino.

(a) CAN 2.0a.

(b) CAN 2.0b.

Figura 7 – Quadro de dados Fonte: Sousa (2002).

Nas duas versões do CAN o quadro de dados é capaz de transmitir de 0 a 8 bytes,o que diferencia é principalmente o tamanho do identificador, sendo que na versãopadrão (Figura 7a) este é formado por 11 bits e no estendido (Figura 7b) por 29bits, além disso na versão estendida o bit IDE faz parte do campo de arbitrageme é substituído por um bit reservado (r1) e nesse mesmo campo é adicionado o bitSRR (Substitute Remote Request que deve ser sempre recessivo para que o quadroestendido tenha prioridade mais baixa que o padrão. Os demais campos que podemser vistos na Figura 7 são (Di Natale et al., 2012; SOUSA, 2002; Bosch Gmbh, 1991):


a) SOF Field (Start of Frame Field Campo de Início do Quadro): sinaliza o iníciodo quadro, formado por um bit dominante.

b) Arbitration Field Campo de Arbitragem: este campo contém o identificador e obit RTR (Remote Transmission Request) que quando é igual a zero indica queo quadro é do tipo de dados e um quando é um quadro remoto.

c) Control Field (Campo de Controle): seis bits com o primeiro indicando seé o quadro é padrão ou estendido, o seguinte (r0) é um bit reservado paraampliações do CAN. E os quatro últimos (DLC Data Length Code) informam aquantidade de bytes do campo de dados.

d) Data Field (Campo de Dados): possui 8 bytes (64bits) e sendo os primeiros bitsos mais significativos.

e) CRC Field (Cyclic Redundance Check Campo de Verificação de RedundânciaCíclica): utilizando os bits dos quatro primeiros campos é calculado com umpolinômio o código de 15 bits do CRC, com isso os receptores podem deduzirse houve erro na transmissão, esse campo possui ainda um décimo sexto bitrecessivo delimitador.

f) ACK Acknowledge Field (Campo de Confirmação): é enviado um bit recessivoque os receptores sobrescrevem com um dominante para indicar o recebimentoe um bit recessivo delimitador.

g) EOF Field (End of Frame Field Campo de Termino de Quadro): sinaliza o fimdo quadro e é composto por sete bis recessivos.

2. Quadro Remoto - utilizado para solicitar um quadro de dados com o mesmoidentificador enviado. A Figura 8 mostra o formato do quadro, este difere do quadrode dados apenas por não conter o campo de dados, sendo o bit RTR sempre recessivoe o campo DLC pode ser qualquer entre 0 e 8.

Figura 8 – Quadro remoto CAN 2.0b. Retirado de: Sousa (2002).

3. Quadro de Erro - enviado toda vez que é detectado um erro, porém este não éum quadro real com uma estrutura de bits dividida em campos, como os anteriores,


mas é um resultado da sinalização de erro quando detectada por um ou conjunto denós, detalhes sobre esse quadro serão tratados na Seção 3.2.2 Detecção, controle esinalização de erros.

4. Quadro de Sobrecarga - empregado no controle de fluxo, utilizado para solicitarmais tempo depois de um quadro de dados ou remoto, prevenindo que outra trans-missão se inicie. Esse quadro é composto por uma sequencia de seis bits dominantesiniciados durante o espaço entre os quadros, após esse envio, os demais nós da redeenviam sinalizadores de sobrecarga, indicando que receberam a solicitação.

3.2.2 Detecção, controle e sinalização de erros

Sendo a rede CAN uma rede de campo e que busca manter a integridade das suascomunicações, existem alguns mecanismos de detecção e controle de erros, com a finalidadede manter o correto funcionamento do barramento como um todo.

Todo o controle de erros em cada nó se baseia em dois contadores: o REC (ReceiverError Counter) e o TEC (Transmite Error Counter), o primeiro que acumula erros derecepção e o segundo os erros ocorridos na transmissão. O protocolo define cinco tipos deerros que causam incremento desses contadores são eles: Bit Error, o bit enviado pelo nó,é diferente do lido por ele na rede, não sendo considerado erro de arbitragem; Stuff Error,quando mais de cinco bits iguais são transmitidos, violando a regra de Bit-Stuffing; FormError, ocorre quando um bit de valor já definido tem seu valor diferente, CRC Error, ocálculo do CRC é diferente do recebido pelo nó, indicando erros na mensagem; ACK Error,ou erro de confirmação, quando um nó que transmitiu não recebe nenhuma confirmação.

Os contadores são incrementados de 1 a 8 dependendo da gravidade do erro, esão decrementados a cada transmissão sem erros. O valor desses contadores definem trêsestados de erro possíveis para o nó assumir, esses são mostrados na Figura 9 .

Figura 9 – Estados de erros possíveis. Retirado de: Sousa (2002).

No estado de Error Active, o nó envia seis bits dominantes, causando assim umaviolação do bit-stuffing da rede, assim todos os outros nós detectam essa violação, descartam


todos os dados recolhidos e transmitem um campo sinalizador de erro, porém um nóneste estado continua em funcionamento normal sem qualquer restrição. Quando um nódetecta que seus contadores estão acima de 127, ele entra no modo Error Passive, emitenovamente uma violação de bit-stuffing e começa a considerar que os erros na rede sãomuito provavelmente causados por ele, portanto continua possível enviar e receber dados.Porém todas as vezes que se detecta qualquer erro na rede, este nó causa uma violação debit-stuffing, considerando que este erro foi causado por ele. E por fim, quando o valor doTEC excede 255 esse nó passa para o estado de Bus-off e fica completamente desligado darede, voltando para o modo de operação somente depois da reinicialização do controladordo protocolo CAN do nó (SOUSA, 2002).

3.2.3 Mecanismo de acesso ao meio

Como a comunicação ocorre serialmente com compartilhamento do canal de co-municação, é necessário utilizar um mecanismo de acesso ao meio, caso da rede CAN,utiliza-se o CSMA/NDBA – Carrier Sense Multiple Access with Non-Destructive BitwiseArbitration (Acesso Múltiplo com Detecção de Portadora com Arbitragem Não Destrutivapor Operação Lógica Bit-a-Bit). Ambos trabalham monitorando e enviado dados bit abit, o CSMA defini que para um nó transmitir este precisa aguardar o barramento ficarlivre além de verificar bit a bit durante o envio do identificador, se outro nó não iniciou atransmissão ao mesmo tempo. Já o processo NDBA cuida para que não haja colisão dedados, assim através da lógica "E"no barramento, um dispositivo consegue discernir se ooutro nó que iniciou a transmissão ao mesmo tempo tem um identificador menor que oseu, se sim interrompe sua transmissão e passa a olhar a rede como um receptor.

Figura 10 – Exemplo do processo de arbitragem. Retirado de: Di Natale et al. (2012).

Assim com essa lógica define-se o processo de arbitragem do protocolo CAN. A


Figura 10 mostra um exemplo desse processo, onde três nós iniciam a transmissão, comseus respectivos identificadores (0x15A, 0x3D2 e 0X1F6). Ao enviar o primeiro bit referenteao seu identificador, todos os nós ainda tem condições de continuar a transmissão, a partirdo segundo bit o nó com identificador 0x3D2 se retira-se da transmissão e passa para acondição de receptor, o mesmo acontece com o nó de identificador igual a 0x1F6, por fim onó com menor identificador no caso igual a 0x15A recebe o direito de enviar a mensagem(Di Natale et al., 2012).

No nível de bits a sequencia acontece da seguinte maneira: quando o barramentoestá desocupado os nós podem iniciar a transmissão, todos que desejem enviar umamensagem enviam um bit dominante para sincronização e em seguida enviam o bit doseu identificador, ao mesmo tempo que monitoram o barramento, assim quando um nódetecta a presença de um bit dominante, tendo enviado um recessivo entra no modo derecepção e aguarda o próximo período de arbitragem (SOUSA, 2002; CiA, 2002).

3.2.4 Filtro e aceitação de mensagens

Todas as mensagens enviadas em uma rede CAN chegam a todos os nós já que osidentificadores são apenas nas mensagens e não nos nós, porém mensagens são filtradaspelo hardware da CAN antes de serem processadas pela aplicação, passando apenas aquelasde interesse para o dispositivo em questão. Isso confere à rede uma vantagem de velocidadee eficiência de processamento. A Figura 11 mostra o exemplo de uma comunicação CANtípica onde o processo de multicast é aplicado. Nesse exemplo a estação 2 que produz osdados envia a todos as outras estações, porém somente as estações 1 e 4 tem os filtrosconfigurados para receberem a mensagem com esse determinado identificador (SOUSA,2002; CiA, 2002).

Figura 11 – Ilustração do conceito de multicast. Retirado de: CiA (2002).

O processo de aceitação das mensagens pelos nós da rede ocorre pela configuraçãode dois filtros, primeiro a máscara que define quais os bits do identificador da mensagemrecebida que serão analisados e passaram para o segundo o filtro de aceitação, quecontêm os valores dos bits que serão comparados com o identificador.


Figura 12 – Máscara e filtro para mensagem CAN. Adaptado de: Di Natale et al. (2012).

Nos controladores CAN existem um ou mais buffers de recepção, com isso pode-seter mais de uma máscara ou filtro de aceitação. No caso do exemplo da Figura 12 tem-sedois buffers de recepção, uma máscara e dois filtros de aceitação. Assim é possível perceberque a mesma máscara seleciona para os dois filtros quais bits serão observados, sendo queneste caso apenas o filtro 1 aceita a mensagem.

3.3 Limitações da CANApesar de todas as estrategias utilizadas pelo protocolo padrão do CAN e das demais

regras provenientes de outras normas, o CAN ainda apresenta algumas limitações. SegundoFerreira e Fonseca (2011) a julgar pela larga utilização desse protocolo os desenvolvedoresreconhecem muitas potencialidades nele, porém ainda são encontrados limitações.

Em princípio seguindo todos os procedimentos de sinalização e identificação deerros, qualquer quadro corrompido deve ser rejeitado por todos os nós da rede. Porém, emRuffino et al. (1998 apud FERREIRA; FONSECA, 2011) identificou alguns problemaschamados de IMO (Inconsistent Message Omissions) omissão inconsistente de mensagens,onde alguns nós recebiam mensagens corretas e outros não e de IMD (Inconsistent MessageDuplicates) duplicação inconsistente de mensagens, onde alguns nós recebiam a mesmamensagem várias vezes outros apenas uma. Esses problemas estão ligados principalmenteao atraso de propagação do sinal na rede e ao BER (Bit Error Rate) da CAN. Ruffino et al.(1998 apud FERREIRA; FONSECA, 2011) desenvolveu algumas pesquisas com diferentesvalores de BER para avaliar o seu efeito no índices de IMO e IMD.

3.4 A CAN na agriculturaO CAN na área agrícola, vem se desenvolvendo e tomando forma internacionalmente

através da ISO 11783, também conhecida com ISOBus. Equipes chamadas de força tarefa,vem sendo formadas e se reunindo periodicamente para desenvolver as diversas partes eem conjunto com fabricantes e outras instituições buscam criar equipamentos compatíveis

3.4. A CAN na agricultura 39

com a norma, buscando a interoperabilidade dos sistemas, além de promover um padrãorobusto e que atenda as necessidades do setor.

Segundo (GUIMARÃES, 2003) a norma vem como um facilitador para o controlee monitoramento futuro além de contribuir com o desenvolvimento da agricultura deprecisão.

41

4 Implementação da rede de testes

Para aplicação dos conceitos do protocolo CAN e possibilitar um contato inicial comos passos de projeto para um sistema com esse protocolo, foi proposto o desenvolvimentoe a construção de um protótipo de uma rede CAN para estimativa de orientação e posiçãoatravés de um sistema de navegação inercial auxiliado por um receptor GPS.

A proposta desse desenvolvimento considerou alguns requisitos, pode-se destacar:

• Ter ao menos três ECUs conectadas à rede;

• As ECUs deveriam ser: uma que enviaria mensagens de um receptor de GPS, umacom mensagens dos sensores da IMU e outra ligada ao computador para receber osdados;

• As ECUs com GPS e com IMU deveriam fazer o tratamento inicial dos dados brutosdos sensores antes de enviá-los pela rede, afim de diminuir o tráfego na rede;

• No tratamento dos dados a ECU deveria ser capaz de interpretar o padrão decomunicação do sensor e converter os dados para variáveis adequadas para cada tipode dado.

Com relação aos dados que devem ser enviados pela rede foram considerados aquelesimportantes para a navegação inercial e localização geográfica em unidades móveis. Assimforam definidos, para o GPS:

• Latitude, Longitude e Altitude com decimal completo disponível pelo receptor;

• Velocidade;

• UTC (Universal Time Coordinated) Tempo Universal Coordenado em segundos;

• Curso e número de satélites disponíveis.

E para a IMU todos os disponíveis sendo eles:

• Dados do acelerômetro nas três coordenadas (x,y e z);

• Dados do giroscópio nas três coordenadas;

• Dados do magnetômetro nas três coordenadas.

42 Capítulo 4. Implementação da rede de testes

4.1 Topologia geral da rede

Considerando os requisitos propostos para a rede foi desenvolvida uma topologiapara o protótipo da rede de testes como mostra a Figura 13.

Figura 13 – Topologia do protótipo da rede de testes.

Pode-se observar que o projeto de cada uma das ECU’s vai ter um hardwarebastante semelhante, já que as interfaces são basicamente as mesmas, passando de USART(Universal Synchronous Asynchronous Receiver Transmitter) (Transmissor Receptor Uni-versal Síncrono e Assíncrono) para CAN. A principal diferença está no código embarcado,que faz a leitura de padrões totalmente distintos de cada um dos sensores, realizando oparse dos dados separando os dados de interesse e reconstituindo-os na mensagem de enviopara o computador.

Outro ponto importante para o projeto e o correto funcionamento da rede foi odesenvolvimento de um dicionário de dados para as mensagens apresentado na Tabela 3.Este foi construído para a organização e sistematização das informações, sem utilizardiretamente uma padronização especificada em norma, porém foi utilizado como base odicionário apresentado em GUIMARÃES (2003).

Tabela 3 – Dicionário de dados da rede.

# Descrição da Mensagem Repetição ECUGPS

ECUIMU

ECUPC ID0 ID1

1 UTC 1Hz TX - RX 0x50 0x401 Posição - Latitude e Longitude 1Hz TX - RX 0x51 0x402 Velocidade e Altitude 1Hz TX - RX 0x52 0x403 # Satélites 1Hz TX - RX 0x53 0x404 Curso 1Hz TX - RX 0x54 0x405 Acelerômetro (Ax,Ay,Az) 17Hz - TX RX 0x60 0x806 Giroscópio (Gx,Gy,Gz) 17Hz - TX RX 0x61 0x807 Magnetômetro (Mx,My,Mz) 17Hz - TX RX 0x62 0x80

4.2. Arquitetura genérica das ECUs 43

Cada linha na Tabela 3 representa uma mensagem que será disponibilizada na rede,analisando essa tabela temos as seguinte informações:

• A frequência de repetição de cada mensagem é a mesma apresentada pelo própriosensor em questão, já que logo que este disponibiliza os dados, a ECU correspondentefaz o tratamento inicial dos dados e coloca na rede;

• O papel de cada ECU é especificado por mensagem, indicando se esta está enviandoa mensagem(TX), recebendo (RX) ou se a mensagem é indiferente para aquela ECU;

• O identificador de cada mensagem é especificado para garantir que a mensagem doGPS tenha prioridade maior que a da IMU devido a frequência de repetição de cadaum.

4.2 Arquitetura genérica das ECUsAs ECUs desse projeto foram implementadas por um projeto com o microcontrolador

PIC 18F2580 da Microchip R©, o código embarcado foi desenvolvido na linguagem Cutilizando o compilador XC8 e o ambiente de desenvolvimento MPLABX R©, escolhidosprincipalmente pela vasta bibliografia disponível em livros e online (IBRAHIM, 2014;PEREIRA, 2003; RAJBHARTI, 2001) bem como a experiencia do autor com as ferramentas.

Em termos de hardware a arquitetura de cada ECU em uma rede CAN pode serrealizada seguindo duas topologias diferentes como mostra Figura 14.

(a) Controlador CAN externo. (b) Controlador CAN interno.

Figura 14 – Topologias de ECU.

A arquitetura da Figura 14a utiliza um controlador CAN externo ao microcon-trolador onde o código principal da ECU está, exigindo uma comunicação entre estestipicamente com um protocolo serial, já na Figura 14b o controlador é um periférico


interno ao microcontrolador. Para a primeira implementação, observa-se uma vantagem decusto pois pode-se escolher um microcontrolador mais simples, porém com o controladorinterno o projeto da placa torna-se mais simples e um sistema mais compacto, reduzindofalhas com conexões importante para aplicações em ambientes extremos como o caso daagricultura. Obtêm-se também um ganho de velocidade e eficiência do código, já que nãosão necessárias rotinas extras para o envio dos dados ao buffer de transmissão nem para aleitura na recepção.

Apesar de cada ECU ter uma função distinta na rede e tratar com dados diferentes,buscou-se desenvolver um mesmo esquema elétrico para todas, afim de simplificar o desen-volvimento do sistema e padronizar o projeto, visando expansões futuras e substituições.

Cada ECU possui as seguintes especificações técnicas:

• Microcontrolador PIC18F2580 (MICROCHIP Technology Inc., 2009) que possui 28pinos, conversor analógico digital de 10 bits, canal de PWM e controlador CANinterno com suporte para CAN 2.0a e b (ECAN);

• Transceptor CAN MCP2551 (MICROCHIP Technology Inc., 2010) suporte paracomunicação até 1Mb/s;

• Cristal para o oscilador de 20MHz;

• Circuito conversor bidirecional de 3.3V para 5V, utilizado na adequação dos si-nais de comunicação serial realizada entre os sensores (GPS e IMU em 3.3V) e omicrocontrolador (5V) (NXP Semiconductors, 2007).

• Terminador de 120Ω com ligação opcional por jumper.

Na Figura 15 é apresentado o esquemático e na Figura 16 a placa do circuitoaplicados nas ECUs.

4.2.1 Módulo ECAN do PIC18F2580

O módulo ECAN é uma interface serial que implementa todo o procolo definidopela norma Bosch Gmbh (1991), suportando CAN2.0a e CAN 2.0b. Pode-se destacar asseguinte características (MICROCHIP Technology Inc., 2009):

• Quadro de bits padrão e estendido;

• Filtro de dados com suporte para DeviceNetTM;

• Taxa de transmissão configurável até 1MB/s;

• Seis modos são possíveis:


Figura 15 – Esquemático do circuito utilizado para as ECUs.

– Configuração;

– Desabilitado;

– Operação Normal, com três outras categorias, modo 0 padrão, modo 1 estendidocom DeviceNetTMe modo dois First In First Out com DeviceNetTM;

– Apenas Escuta, neste modo é possível receber mensagens com erros;

– Eco (Loop Back) com transmissão interna, sem necessidade de ligação física;

– Reconhecimento de Erro, diferente do modo de Apenas Escuta é possível enviarmensagens nesse modo.

• Suporte aos quadros, padrão e estendido de dados, remoto, de erro, sobrecarga eespaço em quadros automático;

• Buffers de transmissão e recepção configuráveis;

• Máscaras e filtros de aceitação configuráveis;

• Sinalização e detecção de erros automática.

Na folha de dados (MICROCHIP Technology Inc., 2009) é sugerida uma sequenciade configuração do módulo:

• Colocar o módulo em modo de configuração e confirmar;


Figura 16 – Placa do circuito utilizado para as ECUs.

• Selecionar qual o modo de operação desejado;

• Configurar os registradores da taxa de transmissão;

• Configurar as máscaras e os filtros de aceitação;

• Colocar o módulo no modo normal ou em outro modo desejado.

No caso do PIC18F2580 fisicamente o módulo utiliza os pinos 23 RB2/CANTX e24 RB3/CANRX.

O periférico conta ainda com 3 buffers dedicados a transmissão e 3 a transmissão enos modos de operação normal 1 e 2 apresentam outros buffers configuráveis.

4.2.2 Transceptor MCP2551

O dispositivo MCP2551 MICROCHIP R© é responsável por implementar a camadafísica, e realiza a interface entre a camada de controle de uma rede CAN e o meio físico.Este dispositivo trabalha como um transceptor compatível com a norma ISO-11898, na qualestão definidos os sinais elétricos presentes no barramento. O MCP2551 prove proteção eisolação dos dispositivos lógicos de controle de eventuais danos provenientes da rede CAN


como, transientes elétricos, descargas de energia estática ou interferências eletromagnéticas.Fica a cargo deste dispositivo, gerar na rede o modo recessivo ou dominante para seu nó.Existem também três modos de operação, selecionáveis através da corrente no pino 8 RS.

O modo High-Speed, selecionado quando o pino RS é ligado ao terra, executa atransição dos sinais de CANH e CANL com a maior velocidade possível para barramentosCAN de alta velocidade. Outro modo possível é o Slope-Control, onde é ligada em RSuma resistência ligada ao terra que limita a corrente neste pino, com isso controla-se otempo de transição dos sinais, reduzindo os efeitos de interferência eletromagnética domeio na comunicação, que é importante em ambientes muito ruidosos, ou em aplicaçõesmuito sensíveis. E por fim o modo Standy, determinado pela aplicação de sinal alto nopino de controle, este modo coloca o dispositivo em modo de baixo consumo, porém acamada de controle ainda é capaz de receber os dados do barramento, sendo possívelentão monitorar a rede e retornar o dispositivo para seu funcionamento normal caso sejanecessário. (MICROCHIP Technology Inc., 2010).

4.2.3 Conversor bidirecional

Sendo o microcontrolador utilizado com saídas no padrão TTL (Transistor-TransistorLogic(0 a 5V) e os sensores utilizados com padrão LVTTL Low Voltage Transistor-TransistorLogic (0 a 3.3V) foi necessário a utilização de um sistema de conversão, para adequaçãodesses nível de sinal.

Seria necessário um sistema capaz converter os sinais com velocidade suficientepara uma comunicação serial USART e que pudesse fazer a conversão do nível mais altopara o mais baixo e vice-versa, mesmo que em linhas diferentes, no caso foi escolhida umatécnica utilizada em redes I2C, que operam com taxas de transmissão de até 400kbps,acima da maior taxa necessária nesse projeto dada pela IMU de 57.6kbps.

O projeto foi baseado nos conceitos apresentados em NXP Semiconductors (2007)que utiliza um mos-fet N e dois resistores por linha como mostra a Figura 17.

Esse circuito funciona da seguinte maneira, quando nenhum dos lados está colocandonível baixo na rede tanto o terminal de porta como de fonte do mosfet estão ligados ao3.3V, o primeiro diretamente e outro pelo resistor, nesta condição o mosfet não estaconduzindo mantendo então os dois lados em nível alto, com níveis de tensão diferentes.Quando o lado de 3.3V coloca a linha em nível baixo o terminal de fonte do mosfet vaipara nível baixo também e como a porta mantem-se em alto o mosfet passa a conduzir e olado de 5V passa ao nível baixo também. E por fim, quando o sinal do lado de 5V colocaa linha em nível baixo, faz o diodo formado pelo substrato do mosfet entrar em conduçãolevando o lado de 3.3V para o mesmo nível do outro lado (NXP Semiconductors, 2007).


Figura 17 – Circuito do conversor de nível bidirecional. Retirado de: NXP Semiconductors(2007).

4.3 ECU do GPSNo contexto de navegação e localização a utilização de receptores de GPS se torna

muito importante já que são capazes de fornecer informações sobre posição e velocidade.Em geral, essas informações são transmitidas usando protocolo padrão NMEA(NationalMarine Electronics Association) 0183, que apresenta diversos tipos de mensagens, contendodados de posicionamento, como latitude, longitude, altitude, número de satélites em vistapelo receptor, dentre outros. O receptor de GPS utilizado nesse trabalho é o SKYTRAQVenus638FLP, fornecido pela SparkFun Electronics Inc., que oferece uma taxa padrãode 1Hz e provê as mensagens GPGGA, GPGSA,GPGSV, GPRMC e GPVTG do padrãoNMEA 0183 (SKYTRAQ Technology Inc., 2008). A Figura 18 mostra uma foto da placade receptor utilizada.

Figura 18 – Placa receptor de GPS. Retirado de: SparkFun Electronics Inc. (2002).

A ECU do GPS utiliza estrutura genérica de rede proposta anteriormente, essaECU tem a função de receber os dados do receptor de GPS, reconhecer o padrão, filtrar osdados de interesse e disponibilizá-los na rede segundo o dicionário de dados estabelecido.

4.3. ECU do GPS 49

Foi desenvolvido um firmware capaz de reconhecer as diferentes mensagens dopadrão NMEA 0183, neste trabalho foram utilizadas as informações mensagens GPGGA,de onde foi retirado a latitude, longitude, UTC em segundos e número de satelites utilizadose GPVTG de onde foi retirada a velocidade. Abaixo são apresentados um exemplo dasmensagens:

• $GPGGA,111636.932,2447.0949,N,12100.5223,E,1,11,0.8,118.2,M„„0000*02

• $GPVTG, 000.0,T„M,000.0,N,0000.0,K,A*3D

As Tabelas 4 e 5 mostram a descrição de cada campo da mensagem NMEA 0183GPGGA e GPVTG.

Tabela 4 – Descrição dos campos da mensagem NMEA 0183 GPGGA. Modificado de:SKYTRAQ Technology Inc. (2008).

# Descrição Formato1 Tempo UTC hhmmss.sss2 Latitude ddmm.mmmm3 Indicador Norte/Sul N/S4 Longitude dddmm.mmmm5 Indicador Leste/Oeste E/W6 Qualidade do GPS (modos) 0-87 Satélites Utilizados 00-128 HDOP 00.0-99.99 Altitude acima do mar mmm.c10 Estação DGPS ID, distancias11 Checksum 02

Tabela 5 – Descrição dos campos da mensagem NMEA 0183 GPVTG. Modificado de:SKYTRAQ Technology Inc. (2008).

# Descrição Formato1 Curso (graus) 000.0 - 359.92 Velocidade do chão (nós) 000.0 - 999.93 Velocidade do chão (km/h) 0000.0 - 1800.04 Modo de Operação carácter5 Checksum 3D

Para o tratamento dessas mensagens foi desenvolvido um conjunto de estruturas efunções, o código e a documentação completa estão disponíveis no Anexo ??.

O processo geral que ocorre no processamento das mensagens e armazenamento noformato adequado para cada informação é da seguinte maneira:

1. Recebe um carácter do sensor via interrupção da USART;


2. A função getGPSmenssage trata cada mensagem, transfere os buffers temporá-rios para os definitivos de cada mensagem com o tipo carácter (char) e realiza aconfirmação da função;

3. Em seguida cada conjunto de informação possui uma função especifica que retira ainformação do buffer em carácter e converte para o tipo mais adequado para cadadado, por exemplo, a informação de tempo UTC utiliza a função getGPSutc, querecebe os dados armazenados nos buffers e retorna os valores inteiros de hora, minutoe segundo e o valor em double da soma dos minutos e segundos em segundos.

Outro exemplo de função de processamento desenvolvida semelhante à do UTCfoi a getGPSpos que recebe os mesmos dados e retorna os valores em double de latitude elongitude, já sinalizados dependendo da posição norte e sul, leste e oeste.

Após o processamento das mensagens e o armazenamento dos dados nas varáveisespecificas, esses devem ser disponibilizados na rede CAN. Porém mesmo que o protocoloCAN possibilite o envio de 8 bytes (64 bits) de uma só vez e o módulo do microcontroladorefetue essa operação, o que seria suficiente para enviar duas variáveis do tipo double emuma única transação, o microcontrolador utilizado é de 8 bits e portanto o barramentointerno só possibilita a passagem de um byte por vez.

Para evitar a criação de outra função para separar os dados, foi utilizada umaestrategia de criar uma união com três varáveis, um vetor com duas posições do tipo doublecom trinta e dois bits cada uma, um vetor com três posições do tipo inteiro com dezesseisbits cada um e um vetor com oito posições do tipo carácter com oito bits cada um. Assimquando se armazena uma variável do tipo double é possível ler como três do tipo inteiroou oito do tipo carácter.

Isso é possível pois ao armazenar uma união, o compilador reserva apenas umúnico espaço de memória com o tamanho da maior variável, no caso o vetor de double,que no microcontrolador utilizado é igual a oito espaços de memória de oito bits, e ao lercada carácter do vetor da união, esta na verdade lendo um pedaço de oito bits das váriasdouble e o mesmo acontece com o inteiro. A Figura 19 mostra um esquema de como ficaorganizado a memória e a divisão das variáveis descritos.

Utilizando essa estratégia, foi necessário apenas passar os dados já armazenadospara a estrutura e em seguida para cada um dos oito registradores do módulo ECAN domicrocontrolador.

4.4 ECU da IMUA IMU é composta pelo conjunto de 3 sensores: acelerômetro, giroscópio e mag-

netômetro. Com as medidas destes sensores é possível obter uma estimativa de atitude e

4.4. ECU da IMU 51

Figura 19 – Esquemático da união na memória.

orientação da plataforma, ou seja, os ângulos de rolagem, arfagem e guinada. Uma UMIcapaz de fornecer todos os dados necessários é a 9DOF RAZOR da SparkFun ElectronicsInc., composta por um acelerômetro digital de 3 eixos (ADXL345), um giroscópio de 3eixos (ITG-3200) e um magnetômetro de 3 eixos (HMC5883L), nesta placa além dessessensores existe um microcontrolador que se comunica com os sensores em seus protocolose formata uma mensagem para envia via USART. Com este dispositivo, é possível optarpela leitura dos dados brutos (sem filtragem) de cada um dos sensores na Figura 20,mostra uma foto da placa da IMU utilizada.

Figura 20 – Placa da IMU. Retirado de: SparkFun Electronics Inc. (2002).

Diferente do receptor de GPS utilizado, que logo ao ser ligado começa a enviar osdados, a IMU utilizada necessita de um processo de inicialização, que consiste em escolhero modo de operação, neste trabalho será utilizado apenas o modo chamado RAW Dataonde é enviado uma única mensagem com os valores de cada um dos sensores formatadosda seguinte maneira:

• Exemplo de mensagem enviada: $-7,0,234,25,-41,-27,-42,-133,102#

• Descrição dos campos: $ax,ay,az,gx,gy,gz,mx,my,mz#

– ax,ay,az: dados do acelerômetro nos três eixos;


– gx,gy,gz: dados do giroscópio nos três eixos;

– mx,my,mz: dados do magnetômetro nos três eixos.

Por ser uma única mensagem, comparando com o processo de recepção do GPSa IMU apenas utiliza a função getIMUmessage para receber cada carácter do sensor viaUSART salvar em um buffer temporário até o término da mensagem, salvar em um bufferdefinitivo e sinalizar a recepção.

Em seguida são utilizadas três funções (getIMUacel,getIMUgiro,getIMUmagn) pararetirar da mensagem salva no buffer cada uma das informações dos sensores e salvá-las emvariáveis do tipo inteiro.

Novamente para o envio na rede CAN é utilizada a união descrita na seção anterior,sendo assim o envio dos dados da IMU torna-se mais simples pois são enviados os trêseixos de cada sensor na mesma mensagem CAN.

A Figura 21 apresenta o fluxograma da ECU da IMU, onde a função e separar osdados da mensagem e a de enviar os dados para a CAN, tem seus códigos apresentadosnos apêndices. Juntamente com a função principal ocorre a interrupção de recepção decarácter da serial, que auxilia no controle de fluxo, como seu código também disponível naseção de apêndices.

INÍCIO

Configurações do PIC

Mensagem nova?

Separa os dados da mensagem

getIMUacel

Envia os dados na CAN

ECAN_Transmit

2

N

S

1

IMU em Reset?

2

Envia Configuração

da IMU

N

S

1

Figura 21 – Fluxograma da função principal da IMU.

4.5. ECU computador 53

4.5 ECU computadorA ECU do computador possui a estrutura de hardware semelhante a arquitetura

genérica descrita, a única diferença é que dispensa a utilização do conversor, pois nãoexiste sensor conectado a ela.

Essa tem na rede a função de receber os dados enviados pelos outros nós via CAN,filtrá-los e formatá-los para serem enviados ao computador através de um conversor deUSART/TTL para USB (Universial Serial Bus), onde serão monitorados por uma aplicaçãono software MatLab R©.

Portanto foi desenvolvido um firmware para essa ECU que possibilitasse essasfuncionalidades sendo capaz então de:

• Estabelecer comunicação com a rede CAN com a configuração do módulo ECAN domicrocontrolador;

• Reconhecer o dicionário de dados, para filtrar as mensagens recebidas da maneiracorreta;

• Enviar os dados recebidos pelo módulo USART;

• Reconhecer os erros sinalizados pelo módulo ECAN e apresentar no computador.

55

5 Avaliação da rede e resultados

Com o objetivo de avaliar o correto funcionamento da comunicação CAN entre asECUs, bem como o processamento dos dados dos sensores, foram realizados uma série detestes, físicos e de software, apresentados a seguir.

5.1 Sinais elétricos da rede CAN

Foi realizada a análise dos sinais CAN L e CAN H presentes na rede implementadavariando o comprimento do barramento.

Na Figura 22, são apresentados os sinais CAN obtidos com um osciloscópio, paraque fosse possível visualizar o efeito de cancelamento do ruído, o teste foi realizado comdois comprimentos do barramento diferentes, com 1,3 m é apresentado na Figura 22ae com 2,1 m na Figura 22b. O barramento mais longo foi ligado próximo a uma fontechaveada para que o nível de ruído fosse maior.

(a) Cabo com 1,3m. (b) Cabo com 2,1m.

Figura 22 – Sinais CAN L e CAN H obtidos da rede implementada.

Nas figuras foram destacados alguns pontos notáveis, como o sinal dominante, osinal recessivo e o barramento livre.

É interessante notar o nível de ruído presente na linha livre nos sinais. AnalisandoCAN L e do sinal CAN H e a tensão diferencial, observando o aumento do ruído nobarramento maior, porém no sinal diferencial não é observada nenhuma mudança.

56 Capítulo 5. Avaliação da rede e resultados

5.2 Monitoramento de errosUtilizando o registrador COMSTAT do módulo ECAN, foi implementada uma

leitura de erro na rede, foram então realizados três testes afim de simular erros:

1. Retirar um terminador: indicação de erro 131 error active;

2. Retirar os dois terminadores: indicação de falha na recepção 139 error passive;

3. Retirar o fio CAN L do barramento : Sem indicação de erro;

4. Retirar o fio CAN H do barramento : interrupção total da transmissão.

5.3 Atraso nos dadosFoi realizado um teste para medir o tempo de atraso que a rede insere na transmissão

de uma mensagem CAN com oito bytes em uma rede com apenas duas ECUs e apenasuma enviando mensagem.

Esse teste foi realizado enviando uma mensagem com dados de valor conhecido e aosolicitar o envio passar um pino digital do microcontrolador conectado a um osciloscópio,para o nível lógico um. Na ECU receptora ao receber os dados e confirmar que são osdados corretos, sinaliza da mesma forma o osciloscópio.

Figura 23 – Medida de atraso da rede de testes.

Assim medindo o tempo entre os dois sinais foi obtido o atraso de 200 microsegundos, como mostra a Figura 23 entre solicitar ao módulo ECAN o envio da mensagemna ECU de transmissão, até os dados estarem disponíveis na ECU de recepção.

57

6 Considerações finais

6.1 Trabalhos futuros

Com o desenvolvimento dessa plataforma de testes e o conhecimento adquirido épossível desenvolver, em um tempo menor, outras ECUs que executem diferentes funções,como por exemplo o desenvolvimento de ECUs com atuadores como motores e outrossensores como encoder. Podendo assim desenvolver uma plataforma de testes para o estudode controle distribuído em sistemas móveis, muito interessantes para aplicações comopiloto automático de máquinas agrícolas ou carros autônomos.

Outra melhoria que poderia ser realizada agora com uma plataforma inicial desen-volvida é a implementação de um procolo mais específico, como o J1939 ou o próprio ISO11783, que abrem para a rede muitas outras aplicações em sistemas mais complexos quenecessitem de abordagem com mais alto nível.

6.2 Conclusão

A utilização do protocolo CAN em máquinas agrícolas vem crescendo muito ese tornando mais popular com novos fabricantes e produtos disponíveis, isso deve-se aoprotocolo possuir características que vem de encontro com as necessidades da área agrícolano que diz respeito a sistemas móveis, pode-se citar algumas dessas características como,barramento reduzido, robustez à ruído e problemas de desconexão acidental de dispositivosou inserção de novos. Outro fator determinante para o crescimento dessa aplicação éa criação e fortalecimento de uma norma específica a ISO 11783, também conhecidacomo ISOBus, que com as diversas forças tarefas, pesquisadores, empresas e instituiçõesenvolvidas, vem contribuindo muito para aumentar a interoperabilidade entre fabricanteso que incentiva a utilização por parte dos agricultores de produtos compatíveis com anorma.

As pesquisas realizadas durante esse trabalho mostraram que a utilização do proto-colo CAN em qualquer aplicação deve ser estudada a luz de uma norma mais direcionadapara a aplicação em questão. Isso é importante pois a norma do CAN especificada pelaBosch, possui poucos detalhes de implementação principalmente das características ligadasa camada física e da organização dos dados em um nível mais alto.

Foi observado também que a implementação do processamento das mensagens doreceptor de GPS e da IMU foram facilitados pela utilização da arquitetura distribuída, jáque dessa forma foi possível fazer a leitura dos dois sensores utilizando a interface padrão

58 Capítulo 6. Considerações finais

dos mesmos, a USART, caso contrário seriam necessários dois canais USART ou realizar aleitura dos sensores de outra forma. Devido a alta taxa de transferência alcançada pelarede CAN, quando comparada a taxa de atualização dos sensores conclui-se que a CANmostra-se promissora na utilização de estimativa de orientação e posição com sistemasdistribuídos.

59

Referências

Bosch Gmbh, R. CAN Specification. [S.l.], 1991. 72 p. Citado 7 vezes nas páginas 11, 27,28, 31, 32, 33 e 44.

CiA. (CAN in Automation GmbH) - CAN Physical Layer and CAN Protocol.Commerzbank, Nuremberg (Germany): [s.n.], 2002. Virtual. Disponível em:www.can-cia.org. Acessado em: 11/2014. Citado 4 vezes nas páginas 11, 30, 31 e 37.

Di Natale, M. et al. Understanding and Using the Controller Area Network CommunicationProtocol. New York, NY: Springer New York, 2012. Citado 10 vezes nas páginas 11, 13,28, 29, 30, 31, 33, 36, 37 e 38.

FARRELL, J. Aided navigation: GPS with high rate sensors. [S.l.]: McGRaw-HillCompanies, 2008. 553 p. Citado na página 20.

FERREIRA, J.; FONSECA, J. A. Universidade de Averio - Portugal. Controller AreaNetwork. In: The Industrial Electronics Handbook - Industrial Communication Systems. 2.ed. Nova York: CRC Press, 2011. cap. 31, p. 413–426. Citado 5 vezes nas páginas 13, 28,29, 30 e 38.

GUIMARÃES, A. D. A. Análise da Norma ISO 11783 e sua Utilização na Implementaçãodo Barrramento do Implemento de um Monitor de Semeadora. Mestrado — EscolaPolitécnica da Universidade de São Paulo, 2003. Citado 5 vezes nas páginas 23, 24, 25, 39e 42.

IBRAHIM, D. PIC Microcontroller Projects in C: Basic to Advanced. Segunda. Londres:Elsevier, 2014. 550 – 574 p. Citado na página 43.

INAMASU, R. Y. Embrapa Instrumentação São Carlos. Padronização da EletrônicaEmbarcada em Máquinas Agrícolas. In: Boletim Técnico Agricultura de PrecisãoMinistério da Agricultura, Pecurária e Abastecimento. 3. ed. Brasília: Biblioteca Nacionalde Agricultura (BINAGRI), 2013. p. 26–34. Citado 2 vezes nas páginas 19 e 26.

INOUE, R. S. Controle Robusto Descentralizado de Movimentos Coordenados de RobôsHeterogênios. Doutorado — Escola de Engenharia de São Carlos Universidade de SãoPaulo, 2012. Citado na página 20.

JUNTOLLI, F. V. Secretaria de Desenvolvimento Agropecuário e Cooperativismo.Agricultura de Precisão no Brasil. In: Boletim Técnico Agricultura de Precisão Ministérioda Agricultura, Pecurária e Abastecimento. 3. ed. Brasília: Biblioteca Nacional deAgricultura (BINAGRI), 2013. p. 36–38. Citado na página 19.

MARQUES, M. A. CAN Automotivo Sistema de Monitoramento. 150 p. Mestrado —Universidade Federal de Itajubá, 2004. Citado 2 vezes nas páginas 23 e 24.

MICROCHIP Technology Inc. Data Sheet PIC18F2480/2580/4480/4580. [S.l.], 2009.Citado 2 vezes nas páginas 44 e 45.

MICROCHIP Technology Inc. High-Speed CAN Transceiver MCP2551. [S.l.], 2010. 24 p.Citado 2 vezes nas páginas 44 e 47.

60 Referências

MOLIN, J. P. U. d. S. a. P. E. S. d. A. L. d. Q. . Agricultura de Precisão. In: BoletimTécnico Agricultura de Precisão Ministério da Agricultura, Pecurária e Abastecimento.Brasília: [s.n.], 2013. p. 5–27. Citado 2 vezes nas páginas 19 e 20.

NISSEN, H. ISOBUS Status of Standardization and Implementation. Workshop ISOBusBrasil, 2008. Citado 2 vezes nas páginas 11 e 19.

NXP Semiconductors. Level Shifting Techniques in I2C-bus Design. 2007. Citado 4 vezesnas páginas 11, 44, 47 e 48.

PEREIRA, F. Microcontroladores PIC: Programação em C. Sexta. São Paulo: Érica, 2003.358 p. Citado na página 43.

PEREIRA, R. R. D. Protocolo ISO 11783: Procedimentos para comunicação serial dedados com o Controlador de Tarefas. 1–188 p. Mestre — Escola de Engenharia de SãoCarlosUniversidade de São Paulo, 2008. Citado 2 vezes nas páginas 19 e 20.

RAJBHARTI, N. (Technology, Microchip) - PIC18C CAN Routines in ‘C’. 2001. Citadona página 43.

RUFFINO, J. et al. Fault-tolerant broadcast in can. Munich, Germany, p. 150–159, 1998.Citado na página 38.

SKYTRAQ Technology Inc. Venus638FLPx GPS Receiver Data Sheet. [S.l.], 2008. Citado3 vezes nas páginas 13, 48 e 49.

SOUSA, R. de. CAN (Controller Area Network): uma abordagem para automação econtrole na área Agrícola. 83 p. Mestrado — Escola de Engenharia de São CarlosUniversidade de São Paulo, 2002. Citado 11 vezes nas páginas 11, 20, 26, 27, 28, 30, 33,34, 35, 36 e 37.

SparkFun Electronics Inc. Venus GPS Logger with SMA Connector. 2002. Virtual.Disponível em: www.sparkfun.com. Acessado em: 11/2014. Citado 3 vezes nas páginas 11,48 e 51.

STRAUSS, C. Implementação e avaliação de uma rede experimental baseada em CANpara aplicações agrícolas. 79 p. Mestrado — Escola Politécnica da Universidade de SãoPaulo, 2001. Citado 2 vezes nas páginas 20 e 25.

SUZUKI, R. Desenvolvimento de Inerface Padrão ISO11783 para Adequação de Sensoresa Sistema de Automação para Implemento Agrícola. Graduação — Escola de Engenhariade São Carlos Universidade de São Paulo, 2012. Citado 2 vezes nas páginas 11 e 19.

TANENBAUM, A. S. Redes de Computadores. 4. ed. [S.l.]: Editora Campus, 2003. 632 p.Citado 2 vezes nas páginas 26 e 28.

Apêndices

63

APÊNDICE A – Código main ECU do PC

#include <xc.h>

#include <stdio.h>

#include <stdarg.h>

#include <stdlib.h>

#include <string.h>

#include "ECAN.h"

#include <plib/usart.h>

//-----------------------------------------------------------------------------

#pragma config OSC = HS

#pragma config PWRT = ON

#pragma config WDT = OFF, WDTPS = 1

#pragma config LVP = OFF

#pragma config DEBUG = OFF

#pragma config MCLRE = ON

#pragma config CP0 = OFF,CP1 = OFF,CP2 = OFF,CP3 = OFF,CPB = OFF,CPD = OFF

#pragma config WRT0 = OFF,WRT1 = OFF,WRT2 = OFF,WRT3 = OFF,WRTB = OFF,

#pragma config WRTC = OFF,WRTD = OFF

#pragma config IESO = ON

//-----------------------------------------------------------------------------

// Definicoes

//-----------------------------------------------------------------------------

#define _XTAL_FREQ 20000000

#define BAUDRATE 57600

#define BRG_VAL ((_XTAL_FREQ/BAUDRATE)/16)-1

//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------

//GPS Receiving and Parse Variables

//-----------------------------------------------------------------------------

/**

* @brief Registrador dos valores da IMU recebidos da CAN

*

* Definicao do tipo IMU_CAN

*

*/

typedefstruct IMU_CAN

/**Campo para armazenar os valores do acelerometro*/

struct acel

volatile int Ax;

volatile int Ay;

volatile int Az;

acel;


struct giro

volatile int Gx;

volatile int Gy;

volatile int Gz;

giro;


struct mag

volatile int Mx;

volatile int My;

volatile int Mz;

mag;

IMUCAN;

IMUCAN imuCan; //criar a variável IMU CAN com todos os valores da IMU

/**

* @brief Registrador dos valores do GPS recebidos da CAN

*

* Definicao do tipo GPS_CAN

*

*/

typedefstruct GPS_CAN

/**Campo para armazenar os valores de UTC hora e tempo (minuto+segundos) em segundos*/

struct utc

volatile double hour;

volatile double ts;

utc;

/**Campo para armazenar os valores de posicao*/

struct pos

volatile double lat;

volatile double lon;

pos;

/**Campo para armazenar os valores de altitude e velocidade*/

struct mov

volatile double alt;

volatile double spd;

mov;

/**Campo para armazenar os valores de HDOP e Numero de Sat*/

struct aux

volatile double hdop;

volatile int numSat;

aux;

/**Campo para armazenar os valores de course*/

struct course

volatile double course;

course;

GPSCAN;

GPSCAN gpsCan;

char mensagem[220];

int rxID[2];

int rxDataLength;

int cnt =0;

int flagGPSnew = 0;

int imuErr =0;

// Protótipo da Funções (Cabeçalho)

void ConfigPIC(void);

void InitializeUSART(void);

void interrupt Interrupcao()

if (PIR1bits.RCIF) // check if receive interrupt has fired by USART

PIR1bits.RCIF = 0; // reset receive interrupt flag

if (INTCONbits.INT0IF)

INTCONbits.INT0IF = 0;

if (INTCONbits.TMR0IF == 1)

INTCONbits.TMR0IF = 0;

else if (INTCONbits.TMR0IF || INTCONbits.INT0IF)

INTCONbits.TMR0IF = 0; //Clear flag


//...

//-----------------------------------------------------------------------------

void main()

ConfigPIC();

InitializeUSART();

InitECAN();

while (1)

if(ECAN_Receive(&RxCANParse.dadosCAN,&rxID,rxDataLength))

if(rxID[1] == 0x40)// mensagem do GPS (0x40) com 3 dados em int

if(rxID[0] == 0x50) //utc (0x50)

gpsCan.utc.hour = RxCANParse.framed[0];

gpsCan.utc.ts = RxCANParse.framed[1];

if(rxID[0] == 0x51) //posicao (0x51)

gpsCan.pos.lat = RxCANParse.framed[0];

gpsCan.pos.lon = RxCANParse.framed[1];

flagGPSnew = 55;

if(rxID[0] == 0x52) //movimento (0x52)

gpsCan.mov.alt = RxCANParse.framed[0];

gpsCan.mov.spd = RxCANParse.framed[1];

if(rxID[0] == 0x53) //auxiliar (0x53)

gpsCan.aux.hdop = RxCANParse.framed[0];

gpsCan.aux.numSat = RxCANParse.framed[1];

if(rxID[0] == 0x54) //course (0x54)

gpsCan.course.course = RxCANParse.framed[0];

if(rxID[1] == 0x80)// mensagem da IMU (0x80) com 3 dados em int

if(rxID[0] == 0x60) //acelerometro (0x50)

PORTCbits.RC2 = !PORTCbits.RC2;

imuCan.acel.Ax = RxCANParse.framei[0];

imuCan.acel.Ay = RxCANParse.framei[1];

imuCan.acel.Az = RxCANParse.framei[2];

if(rxID[0] == 0x61) //giroscopio (0x51)

imuCan.giro.Gx = RxCANParse.framei[0];

imuCan.giro.Gy = RxCANParse.framei[1];

imuCan.giro.Gz = RxCANParse.framei[2];

if(rxID[0] == 0x62) //magnetometro (0x52)

imuCan.mag.Mx = RxCANParse.framei[0];

imuCan.mag.My = RxCANParse.framei[1];

imuCan.mag.Mz = RxCANParse.framei[2];

if(rxID[0] == 0x63) //magnetometro (0x52)

imuErr = RxCANParse.framei[0];

sprintf(mensagem,"$,Ax%d,Ay%d,Az%d,Gx%d,Gy%d,Gz%d,Mx%d,"

"My%d,Mz%d,Err%d,Hour%f,Ts%f,Lat%f,Lon%f,Spd%d,"

"HDOP%d,NSat%d,Cour%f,FGPS%d#",

imuCan.acel.Ax,imuCan.acel.Ay,imuCan.acel.Az,imuCan.giro.Gx,

imuCan.giro.Gy,imuCan.giro.Gz,imuCan.mag.Mx,imuCan.mag.My,

imuCan.mag.Mz,imuErr,gpsCan.utc.hour,gpsCan.utc.ts,

gpsCan.pos.lat,gpsCan.pos.lon,

gpsCan.mov.spd,gpsCan.aux.hdop,gpsCan.aux.numSat,

gpsCan.course.course,flagGPSnew);

putsUSART(mensagem);

if(flagGPSnew == 55)

flagGPSnew = 0;

//-----------------------------------------------------------------------------

void InitializeUSART(void)

OpenUSART(USART_TX_INT_OFF &

USART_RX_INT_ON &

USART_ASYNCH_MODE &

USART_EIGHT_BIT &

USART_CONT_RX &

USART_BRGH_HIGH, BRG_VAL);

//----------------------------------------------------------------------------

//-----------------------------------------------------------------------------

void ConfigPIC(void)

INTCONbits.GIEH = 1; // Habilita as interrupcoes de alta prioridade

INTCONbits.PEIE = 1; // enable peripheral interrupts.

INTCONbits.GIE = 1; // enable interrupts

OSCCONbits.IRCF = 0b111;

OSCTUNEbits.PLLEN = 0;

TRISCbits.RC2 = 0; //Saida medida de delay da rede

PORTCbits.RC2 = 0;

TRISCbits.RC3 = 0; //Saida medida de delay da rede

PORTCbits.RC3 = 0;

TRISCbits.RC6 = 0; //TX pin set as output

TRISCbits.RC7 = 1; //RX pin set as input

//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------

69

APÊNDICE B – Código main ECU da IMU

/*

* File: main.c

* Author: Daniel Diegues

* Descrição:

* TCC PIC 18F2580

*/

#include <xc.h>

#include <stdio.h>

#include <stdarg.h>

#include <stdlib.h>

#include <string.h>

#include "ECAN.h"

#include "imuclass.h"


//------------------------------------------------------------------------------








#pragma config WRT0 = OFF,WRT1 = OFF,WRT2 = OFF,WRT3 = OFF,WRTB = OFF,WRTC = OFF,WRTD = OFF


//------------------------------------------------------------------------------

// Definicoes

//------------------------------------------------------------------------------



#define BRG_VAL ((_XTAL_FREQ/BAUDRATE)/16)-1 // for high baud use 16 instaed 64

//------------------------------------------------------------------------------


//------------------------------------------------------------------------------

volatile unsigned char temp;

volatile unsigned char indexRx;

volatile unsigned char buffRx[70];

struct flag_Bits

int flagRxNew : 1;

int flagRxIni : 1;

int flagRxMat : 1;

flagBits;

int cont = 0;

IMUregister imuReg;




void USART_putc(unsigned char c)

while (!TXSTAbits.TRMT); // wait until transmit shift register is empty

TXREG = c; // write character to TXREG and start transmission



temp = RCREG; // read received character to buffer

if(temp =='?')

flagBits.flagRxIni = 1; //controle da IMU

if(temp == '$')

flagBits.flagRxIni = 0; //controle da IMU (enviar 4)

flagBits.flagRxMat = 1; //controle de inicio de mensagem combinando

if( flagBits.flagRxMat)

flagBits.flagRxNew = getIMUmessage(temp,&imuReg);

if(flagBits.flagRxNew)

flagBits.flagRxMat = 0;

PIR1bits.RCIF = 0;




//------------------------------------------------------------------------------

void main()

ConfigPIC();

InitializeUSART();

InitECAN();

initIMU(&imuReg);

while (1)


getIMUacel(&imuReg,&imuAcel);

getIMUgiro(&imuReg,&imuGiro);

getIMUmagn(&imuReg,&imuMagn);

imuECAN_Transmit(imuAcel.acel_x,imuAcel.acel_y,imuAcel.acel_z,8,0x60,0x80);

imuECAN_Transmit(imuGiro.giro_x,imuGiro.giro_y,imuGiro.giro_z,8,0x61,0x80);

imuECAN_Transmit(imuMagn.magn_x,imuMagn.magn_y,imuMagn.magn_z,8,0x62,0x80);

imuECAN_Transmit(COMSTAT,0,0,1,0x63,0x80);

flagBits.flagRxNew = 0;

if(flagBits.flagRxIni)

cont++;

if(cont > 0x1000)

USART_putc('4');

cont = 0;



USART_RX_INT_ON &

USART_ASYNCH_MODE &

USART_EIGHT_BIT &

USART_CONT_RX &

USART_BRGH_HIGH, BRG_VAL);

//----------------------------------------------------------------------------







TRISB = 0x00;

TRISBbits.RB3 = 1;

// Initialize CAN module

TRISCbits.RC2 = 0;

PORTCbits.RC2 = 0;




//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

75

APÊNDICE C – Código main ECU da GPS

/*

* File: main.c

* Author: Daniel Diegues

* Descrição:

* TCC PIC 18F2580

*/

#include <xc.h>

#include <stdio.h>

#include <stdarg.h>

#include <stdlib.h>

#include <string.h>

#include "ECAN.h"

#include "gpsclass.h"


//------------------------------------------------------------------------------








#pragma config WRT0 = OFF,WRT1 = OFF,WRT2 = OFF,WRT3 = OFF,WRTB = OFF,WRTC = OFF,WRTD = OFF


//------------------------------------------------------------------------------

// Definicoes

//------------------------------------------------------------------------------



#define BRG_VAL ((_XTAL_FREQ/BAUDRATE)/64)-1

//------------------------------------------------------------------------------


//------------------------------------------------------------------------------

volatile unsigned char temp; //character RX

struct flag_Bits

int flagRxNew : 1;

int flagRxIni : 1;

flagBits;

GPSregister gpsReg;

GPSutc gpsUTC;

GPSpos gpsPos;

GPSaux gpsAux;

GPScour gpsCour;







temp = RCREG; // read received character to buffer

if(temp == '$')

flagBits.flagRxIni = 1;

if(flagBits.flagRxIni)

flagBits.flagRxNew = getGPSmessage(temp,&gpsReg);


flagBits.flagRxIni = 0;

PIR1bits.RCIF = 0; // reset receive interrupt flag




//------------------------------------------------------------------------------

void main()

ConfigPIC();

initGPS(&gpsReg);

InitializeUSART();

InitECAN();

while (1)


getGPSutc(&gpsReg,&gpsUTC,NULL);

getGPSpos(&gpsReg,&gpsPos,NULL);

getGPSaux(&gpsReg,&gpsAux,NULL);

getGPScour(&gpsReg,&gpsCour,NULL);

gpsECAN_Transmit(gpsUTC.utc_hour,gpsUTC.utc_ts,8,0x50,0x40);

gpsECAN_Transmit(gpsPos.pos_lat,gpsPos.pos_lon,8,0x51,0x40);

gpsECAN_Transmit(gpsPos.pos_lat,gpsPos.pos_lon,8,0x51,0x40);

gpsECAN_Transmit(gpsAux.aux_numsat,gpsAux.aux_numsat,8,0x53,0x40);

gpsECAN_Transmit(gpsCour.cour_cour,gpsCour.cour_cour,8,0x54,0x40);




USART_RX_INT_ON &

USART_ASYNCH_MODE &

USART_EIGHT_BIT &

USART_CONT_RX &

USART_BRGH_LOW, BRG_VAL);

//----------------------------------------------------------------------------







TRISB = 0x00;

TRISBbits.RB3 = 1;

// Initialize CAN module

TRISCbits.RC2 = 0;

PORTCbits.RC2 = 0;




//------------------------------------------------------------------------------

79

APÊNDICE D – Códigos biblioteca da IMU

/**

* @file gpsclass.h

* @brief Header da classe GPS para TCC

* @author Daniel Diegues

*

* @date 28 de Outubro de 2014

*/

/**

* @brief Registrador das mensagens da IMU com os campos de buffer temporarios

* para manter os dados sincronizados

*

* Definicao do tipo IMUregister

*

*/

typedefstruct reg_IMU

/**Campo para armazenar a sentenca temporaria da IMU*/

volatile unsigned char bufferIMUTemp[50];

/**Campo para armazenar a sentenca completa da IMU*/

volatile unsigned char bufferIMU[50];

/**Campo para armazenar o index de cada um dos caracteres recebidos da

* serial*/

unsigned int index;

IMUregister;

/**

* @brief Estrutura com os dados do Acelerometro (x,y,z)

* da funcao getIMUaccel

* Definicao do tipo IMUacel

*/

typedefstruct IMU_acel

/**Campo para armazenar o valor do acelerometro em x*/

volatile int acel_x;

/**Campo para armazenar o valor do acelerometro em y*/

volatile int acel_y;

/**Campo para armazenar o valor do acelerometro em z*/

volatile int acel_z;

IMUacel;

/**

* @brief Estrutura com os dados do Giroscopio (x,y,z)

* da funcao getIMUgiro

* Definicao do tipo IMUgiro

*/

typedefstruct IMU_giro

typedefstruct IMU_giro

/**Campo para armazenar o valor do giroscopio em x*/

volatile int giro_x;

/**Campo para armazenar o valor do giroscopio em y*/

volatile int giro_y;

/**Campo para armazenar o valor do giroscopio em z*/

volatile int giro_z;

IMUgiro;

/**

* @brief Estrutura com os dados do Magnetometro (x,y,z)

* da funcao getIMUmagn

* Definicao do tipo IMUmagn

*/

typedefstruct IMU_magn

/**Campo para armazenar o valor do magnetometro em x*/

volatile int magn_x;

/**Campo para armazenar o valor do magnetometro em y*/

volatile int magn_y;

/**Campo para armazenar o valor do magnetometro em z*/

volatile int magn_z;

IMUmagn;

/*

* @brief Funcao de Inicializacao das variavies da IMU

*/

void initIMU(IMUregister *imuReg);

/*

* @brief Funcao que grava cada character no buffer.

* Grava em um buffer temporario

* Atualiza todo o buffer permanente ao fim da sentenca

*/

int getIMUmessage(char charRx,IMUregister *imuReg);

/*

* @brief Funcao para obter os dados do acelerometro

*/

int getIMUacel(IMUregister *imuReg,IMUacel *imuAcel);

/*


*/

int getIMUgiro(IMUregister *imuReg,IMUgiro *imuGiro);

/*



*/

int getIMUmagn(IMUregister *imuReg,IMUmagn *imuMagn);

IMUregister imuReg;

IMUacel imuAcel;

IMUgiro imuGiro;

IMUmagn imuMagn;

#include <p18f2580.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <xc.h>

#include "imuclass.h"

/**

*

* @param imuReg variavel do tipo IMUregister deve ser criada antes de utilizar a biblioteca

*/

void initIMU(IMUregister *imuReg)

imuReg->index = 0;

/**

* @brief Funcao que grava cada character no buffer.

* Grava no buffer temporario .

* Atualiza todo o buffer permanente ao mesmo instante ao fim da sentenca. (!! MUDAR O RETURN !!)

* @param charRx caracter recebido pela serial

* @param imuReg variavel do tipo IMUregister deve ser criada antes de utilizar a biblioteca

* contem o buffer da sentenca alem de controles internos

* @return retorna '1' a cada nova mensagem recebida e gravada no buffer correto cada vez que recebe '#'.

*/

int getIMUmessage(char charRx,IMUregister *imuReg)

if(charRx!='#') //not final of the message

imuReg->bufferIMUTemp[imuReg->index] = charRx; //save Rx data initial of string

imuReg->index++;

return 0;

else

imuReg->bufferIMUTemp[imuReg->index] = charRx; //put terminator in the end of message

strncpy(imuReg->bufferIMU, imuReg->bufferIMUTemp,(imuReg->index+1));//

imuReg->index = 0;

return 1;

/**

* @brief Funcao que extrai os dados do acelerometro.

* @param IMUReg variavel do tipo IMUregister os valores sao carregados pela funcao

* getIMUmessage

* @param imuAcel variavel do tipo IMUacel onde serao carregados os valores de saida da funcao

* @return 0 - success

* -1 - buffer vazio

*/

int getIMUacel(IMUregister *imuReg,IMUacel *imuAcel)

int i;

char temp_str[4];

char *sentence;

sentence = imuReg->bufferIMU;

for(i = 0;i < 2;i++)

if(sentence == NULL)

return -1;

if(i == 0)

temp_str[3] = 0;

strncpy(temp_str,sentence + 1,4);

imuAcel->acel_x = atoi(temp_str);

sentence = strchr(sentence, ',');// pointer to the separator ','

sentence++;//first character in field

//pull out data

if(i == 0)

temp_str[3] = 0;

strncpy(temp_str, sentence, 4); //

imuAcel->acel_y = atoi(temp_str);

if(i == 1)

temp_str[3] = 0;


imuAcel->acel_z = atoi(temp_str);

return 0;

/**

* @brief Funcao que extrai os dados do giroscopio.


* getIMUmessage

* @param imuGiro variavel do tipo IMUgiro onde serao carregados os valores de saida da funcao


* -1 - buffer vazio

*/

int getIMUgiro(IMUregister *imuReg,IMUgiro *imuGiro)

int i;

char temp_str[4];

char *sentence;


for(i = 0;i < 5;i++)


return -1;



//pull out data

if(i == 2)

temp_str[3] = 0;


imuGiro->giro_x = atoi(temp_str);

if(i == 3)

if(i == 3)

temp_str[3] = 0;


imuGiro->giro_y = atoi(temp_str);

if(i == 4)

temp_str[3] = 0;


imuGiro->giro_z = atoi(temp_str);

return 0;

/**

* @brief Funcao que extrai os dados do magnetometro.


* getIMUmessage

* @param imuMagn variavel do tipo IMUmagn onde serao carregados os valores de saida da funcao


* -1 - buffer vazio

*/

int getIMUmagn(IMUregister *imuReg,IMUmagn *imuMagn)

int i;

char temp_str[4];

char *sentence;


for(i = 0;i < 8;i++)


return -1;



//pull out data

if(i == 5)

temp_str[3] = 0;


imuMagn->magn_x = atoi(temp_str);

if(i == 6)

temp_str[3] = 0;


imuMagn->magn_y = atoi(temp_str);

if(i == 7)

temp_str[3] = 0;


imuMagn->magn_z = atoi(temp_str);

return 0;

87

APÊNDICE E – Códigos biblioteca do GPS

/**

* @file gpsclass.h

* @brief Header da classe GPS para TCC


*

*/

/**

* @brief Registrador das mensagens NMEA do GPS com os campos de buffer temporarios

* para manter os dados sincronizados

*

* Definicao do tipo GPSregister

*

*/

typedefstruct reg_GPS

/**Campo para armazenar os dados temporarios de GPGGA*/

volatile unsigned char bufferGGATemp[72];

/**Campo para armazenar os dados de temporarios GPGSA*/

volatile unsigned char bufferGSATemp[70];

/**Campo para armazenar os dados de temporarios GPGSV*/

volatile unsigned char bufferGSVTemp[70];

/**Campo para armazenar os dados de temporarios GPRMC*/

volatile unsigned char bufferRMCTemp[70];

/**Campo para armazenar os dados de temporarios GPVTG*/

volatile unsigned char bufferVTGTemp[70];

/**Campo para armazenar os dados de GPGGA*/

volatile unsigned char bufferGGA[72];

/**Campo para armazenar os dados de GPGSA*/

volatile unsigned char bufferGSA[70];

/**Campo para armazenar os dados de GPGSV*/

volatile unsigned char bufferGSV[70];

/**Campo para armazenar os dados de GPRMC*/

volatile unsigned char bufferRMC[70];

/**Campo para armazenar os dados de GPVTG*/

volatile unsigned char bufferVTG[70];

/**Campo para armazenar os dados incompletos temporarios durante o processo

* de leitura da serial. Nao deve ser considerado dado valido*/

volatile unsigned char bufferRxTemp[70];

/**Campo para armazenar o index de cada um dos caracteres recebidos da

* serial*/

unsigned int index;

/**Campo para indicar que recebeu uma mensagem de GPS inteira nova*/

GPSregister;

/**

* @brief Estrutura com os dados UTC (hora, minuto, segundo e tempo em segundos)

* da funcao getUTC

* Definicao do tipo GPSutc

*/

typedefstruct GPS_utc

/**Campo para armazenar a hora*/

/**Campo para armazenar a hora*/

volatile unsigned int utc_hour;

/**Campo para armazenar os minutos*/

volatile unsigned int utc_min;

/**Campo para armazenar os segundos (sem decimal)*/

volatile unsigned int utc_sec;

/**Campo para armazenar tempo em segundos com decimal e minutos convertidos*/

volatile double utc_ts;

GPSutc;

/**

* @brief Estrutura com os dados de posicao

* Latitude, Longitude e altitude.

* da funcao getGPSpos

* Definicao do tipo GPSpos

*/

typedefstruct GPS_pos

/**Campo para armazenar a latitude em graus*/

volatile double pos_lat;

/**Campo para armazenar a longitude em graus*/

volatile double pos_lon;

/**Campo para armazenar altitude em metros*/

volatile double pos_alt;

GPSpos;

/**

* @brief Estrutura com os dados de mov

* Altitude e velocidade.

* da funcao getGPSmov

* Definicao do tipo GPSmov

*/

typedefstruct GPS_mov

/**Campo para armazenar altitude*/

volatile double mov_alt;

/**Campo para armazenar velocidade*/

volatile double mov_spd;

GPSmov;

/**

* @brief Estrutura com os dados de aux

* hdop e numSat.

* da funcao getGPSaux

* Definicao do tipo GPSaux

*/

typedefstruct GPS_aux


volatile double aux_hdop;

/**Campo para armazenar velocidade*/

volatile double aux_numsat;

GPSaux;

/**

* @brief Estrutura com os dados de cour

* course.

* da funcao getGPScour

* Definicao do tipo GPScour

*/

typedefstruct GPS_cour


volatile double cour_cour;

GPScour;

/*

* @brief Funcao de Inicializacao das variavies do GPS

*/

void initGPS(GPSregister *gpsReg);

/*

* @brief Funcao que grava cada character no buffer do padrao especifico.

* Grava em um buffer temporario

* Atualiza todos os buffers permanentes ao mesmo instante, quando recebe o GPVTG

*/

int getGPSmessage(char charRx,GPSregister *gpsReg);

/*

* @brief Funcao para obter os dados de tempo (UTC) do padrao solicitado

*/

int getGPSutc(GPSregister *gpsReg,GPSutc *gpsUTC,char std);

/*

* @brief Funcao para obter os dados de posicao.

* Sendo latitude, longitude e altitude.

*/

int getGPSpos(GPSregister *gpsReg,GPSpos *gpsPos,char std);

/*

* @brief Funcao para obter os dados de mov.


*/

int getGPSmov(GPSregister *gpsReg,GPSmov *gpsMov,char std);

/*

* @brief Funcao para obter os dados de aux.


*/

int getGPSaux(GPSregister *gpsReg,GPSaux *gpsAux,char std);

/*

* @brief Funcao para obter os dados de cour.


*/

int getGPScour(GPSregister *gpsReg,GPScour *gpsCour,char std);


#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <xc.h>

#include "gpsclass.h"

/**

*

* @param gpsReg variavel do tipo GPSregister deve ser criada antes de utilizar a biblioteca

*/

void initGPS(GPSregister *gpsReg)

gpsReg->index = 0;

/**

* @brief Funcao que grava cada character no buffer do padrao especifico.

* Grava em um buffer temporario .

* Atualiza todos os buffers permanentes ao mesmo instante, quando recebe o GPVTG.

* @param charRx caracter recebido pela serial

* @param gpsReg variavel do tipo GPSregister deve ser criada antes de utilizar a biblioteca

* contem os buffers com os padroes GGA, GSA, GSV, RMC e VTG alem de controles internos

* @return retorna '1' a cada nova mensagem recebida e gravada no buffer correto cada vez que recebe '*'.

*/

int getGPSmessage(char charRx,GPSregister *gpsReg)

if(charRx!='*') //not final of the message

gpsReg->bufferRxTemp[gpsReg->index] = charRx; //save Rx data initial of string

gpsReg->index++;

return 0;

else

gpsReg->bufferRxTemp[gpsReg->index] = charRx; //put terminator in the end of message

if(!strncmp(gpsReg->bufferRxTemp,"$GPGGA",6))

strncpy(gpsReg->bufferGGATemp, gpsReg->bufferRxTemp,(gpsReg->index+1));

if(!strncmp(gpsReg->bufferRxTemp,"$GPGSA",6))

strncpy(gpsReg->bufferGSATemp, gpsReg->bufferRxTemp,(gpsReg->index+1));

if(!strncmp(gpsReg->bufferRxTemp,"$GPGSV",6))

strncpy(gpsReg->bufferGSVTemp, gpsReg->bufferRxTemp,(gpsReg->index+1));

if(!strncmp(gpsReg->bufferRxTemp,"$GPRMC",6))

strncpy(gpsReg->bufferRMCTemp, gpsReg->bufferRxTemp,(gpsReg->index+1));

if(!strncmp(gpsReg->bufferRxTemp,"$GPVTG",6))

strncpy(gpsReg->bufferVTG, gpsReg->bufferRxTemp,(gpsReg->index+1));

strncpy(gpsReg->bufferGGA, gpsReg->bufferGGATemp,72);

strncpy(gpsReg->bufferGSA, gpsReg->bufferGSATemp,70);

strncpy(gpsReg->bufferGSV, gpsReg->bufferGSVTemp,70);

strncpy(gpsReg->bufferRMC, gpsReg->bufferRMCTemp,70);

gpsReg->index = 0;

return 1;

/**

* @brief Funcao que extrai os dados de tempo (UTC) do padrao solicitado.

* @param gpsReg variavel do tipo GPSregister os valores sao carregados pela funcao

* getGPSmessage

* @param gpsUTC variavel do tipo GPSutc onde serao carregados os valores de saida da funcao

* @param std parametro com padrao de sentenca de onde deseja ser extraido o UTC

* (!! Atualmente so o GGA !!)


* -1 - parsing error

* -2 - sentence marked invalid

*/

int getGPSutc(GPSregister *gpsReg,GPSutc *gpsUTC,char std)

int i;

char temp_str[3];

char *sentence;

sentence = gpsReg->bufferGGA;

if(strncmp(sentence,"$GPGGA", 6) == 0)

for(i = 0;i < 1;i++)



return -1;


//pull out data

if(i == 0) //UTC

temp_str[2] = 0;

strncpy(temp_str, sentence, 2); // hour

gpsUTC->utc_hour = atoi(temp_str);

strncpy(temp_str, sentence + 2, 2);//minutes

gpsUTC->utc_min = atoi(temp_str);

strncpy(temp_str, sentence + 4, 2);//seconds

gpsUTC->utc_sec = atoi(temp_str);

temp_str[5] = 0;

strncpy(temp_str, sentence + 4, 6);//seconds and decimal

gpsUTC->utc_ts = ((gpsUTC->utc_min)*60) + atof(temp_str);//

return 0;

else

return -2;

/**

* @brief Funcao de auxilio para converter a latitude e longitude em graus

* @param coord entrada de dados da coordenada para ser convertida

* @param degrees saida de dados com a coordenada convertida em graus




*/

int GPStodegree(char *coord, double *degrees)

char *decimal_point;

char temp[2];

char temp[2];

char dummy[2];

double tempdegrees = 0;

decimal_point = strchr(coord, '.');

if(decimal_point == NULL)

return -1;

temp[2] = 0;

strncpy(temp, decimal_point - 4, 2);

*degrees = atof(temp)*10;

strncpy(temp, decimal_point - 2, 2);

*degrees += atof(temp)/6;

strncpy(temp, decimal_point + 1, 4);

tempdegrees = atof(temp)/100;

*degrees += tempdegrees/600;

return 0;

/**

* @brief Funcao que extrai os dados de posicao Latitude e Longitude em Graus

* e Altitude em metros.


* getGPSmessage

* @param gpsPos variavel do tipo GPSpos onde serao carregados os valores de saida da funcao

* @param std parametro com padrao de sentenca de onde deseja extrair a Pos





*/

int getGPSpos(GPSregister *gpsReg,GPSpos *gpsPos,char std)

int i;

char temp_str[3];

char *sentence;



for(i = 0; i < 11; i++)



return -1;


//pull out data

if(i == 1) //latitude

if(GPStodegree(sentence,&gpsPos->pos_lat))

return -1;

if(i == 2) //latitude direction

if(*sentence == 'S')

gpsPos->pos_lat = -gpsPos->pos_lat;

if(i == 3) //longitude

if(GPStodegree(sentence,&gpsPos->pos_lon))

if(GPStodegree(sentence,&gpsPos->pos_lon))

return -1;

if(i == 4) //longitude

if(*sentence == 'W')

gpsPos->pos_lon = -gpsPos->pos_lon;

else

return -2;

/**

* @brief Funcao que extrai os dados de posicao altitude e velocidade

* e Altitude em metros.


* getGPSmessage

* @param gpsSatCur variavel do tipo GPSpos onde serao carregados os valores de saida da funcao

* @param std parametro com padrao de sentenca de onde deseja extrair a Pos





*/

int getGPSmov(GPSregister *gpsReg,GPSmov *gpsMov,char std)

return -2;

int getGPSaux(GPSregister *gpsReg,GPSaux *gpsAux,char std)

int i;

char temp_str[3];

char *sentence;



for(i = 0; i < 11; i++)



return -1;


//pull out data

if(i == 6) //numSat

temp_str[2] = 0;

strncpy(temp_str, sentence, 2); // num satelites

gpsAux->aux_numsat = atof(temp_str);

return -1;

if(i == 7) //hdop

else

else

return -2;

int getGPScour(GPSregister *gpsReg,GPScour *gpsCour,char std)

int i;

char temp_str[3];

char *sentence;

sentence = gpsReg->bufferVTG;

if(strncmp(sentence,"$GPVTG", 6) == 0)

for(i = 0; i < 5; i++)



return -1;


//pull out data

if(i == 0) //course

temp_str[2] = 0;

strncpy(temp_str, sentence, 5); // course

gpsCour->cour_cour = atof(temp_str);

return -1;

else

return -2;

97

APÊNDICE F – Códigos biblioteca ECAN

/**

* @file ECAN.h

* @brief Header da classe Extended CAN


*/

#ifndef _ECAN_H

#define _ECAN_H

#define TRUE 1

#define FALSE 0

/*Campos*/

union parse_CANTX

int framei[3];

double framed[2];

unsigned char dadosCAN[8];

TxCANParse;

union parse_CANRX

double framed[2];

int framei[3];

unsigned char dadosCAN[8];

RxCANParse;

void InitECAN(void);

unsigned char ECAN_Receive(unsigned char *data,int *ptRxID, int RxDLC);

void gpsECAN_Transmit(double data0, double data1, int dLc, int sIDh0, int sIDl0 );

void imuECAN_Transmit(int data0,int data1,int data2, int dLc, int sIDh0, int sIDl0);

#endif


#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <xc.h>

#include "ECAN.h"

unsigned char temp_EIDH;

unsigned char temp_EIDL;

unsigned char temp_SIDH;

unsigned char temp_SIDL;

unsigned char temp_DLC;

unsigned char temp_D0;








void InitECAN(void)

CANCON = 0x00;

CANCON = 0x80;

while(!((CANSTATbits.OPMODE0==0) && (CANSTATbits.OPMODE1==0) && (CANSTATbits.OPMODE2==1)));

ECANCONbits.MDSEL0 = 0x00;

ECANCONbits.MDSEL1 = 0x00;

BRGCON1 = 0x81;

BRGCON2 = 0x90;

BRGCON3 = 0x00;

// Initialize Receive Masks

RXM0EIDH = 0x00;

RXM0EIDL = 0x00;

RXM0SIDH = 0xFF;

RXM0SIDL = 0xE0;

RXM1EIDH = 0x00;

RXM1EIDL = 0x00;

RXM1SIDH = 0xFF;

RXM1SIDL = 0xE0;

RXFCON0 = 0x00; //Disable all

RXFCON1 = 0x00; //Disable all

RXF0EIDH = 0x00;

RXF0EIDL = 0x00;

RXF0SIDH = 0x32;

RXF0SIDL = 0xC0;

RXF2EIDH = 0x00;

RXF2EIDH = 0x00;

RXF2EIDL = 0x00;

RXF2SIDH = 0x33;

RXF2SIDL = 0xC0;

CANCONbits.REQOP0 = 0;



while(!((CANSTATbits.OPMODE0==0) && (CANSTATbits.OPMODE1==0) && (CANSTATbits.OPMODE2==0) ) );

RXB0CON = 0x00;

RXB1CON = 0x00;

unsigned char ECAN_Receive(unsigned char *data,int *ptRxID, int RxDLC)

unsigned char RXMsgFlag;

RXMsgFlag = 0x00;

if (RXB0CONbits.RXFUL) //CheckRXB0

temp_EIDH = RXB0EIDH;

temp_EIDL = RXB0EIDL;

temp_SIDH = RXB0SIDH;

ptRxID[0] = RXB0SIDH;

temp_SIDL = RXB0SIDL;

ptRxID[1] = RXB0SIDL;

temp_DLC = RXB0DLC;

RxDLC = RXB0DLC;

temp_D0 = RXB0D0;

data[0] = RXB0D0;

temp_D1 = RXB0D1;

data[1] = RXB0D1;

temp_D2 = RXB0D2;

data[2] = RXB0D2;

temp_D3 = RXB0D3;

data[3] = RXB0D3;

temp_D4 = RXB0D4;

data[4] = RXB0D4;

temp_D5 = RXB0D5;

data[5] = RXB0D5;

temp_D6 = RXB0D6;

data[6] = RXB0D6;

temp_D7 = RXB0D7;

data[7] = RXB0D7;

RXB0D0 = 0;

RXB0D1 = 0;

RXB0D2 = 0;

RXB0D3 = 0;

RXB0D4 = 0;

RXB0D4 = 0;

RXB0D5 = 0;

RXB0D6 = 0;

RXB0D7 = 0;

RXB0CONbits.RXFUL = 0;

RXMsgFlag = 0x01;

else if (RXB1CONbits.RXFUL) //CheckRXB1

temp_EIDH = RXB1EIDH;

temp_EIDL = RXB1EIDL;

temp_SIDH = RXB1SIDH;

temp_SIDL = RXB1SIDL;

temp_DLC = RXB1DLC;

temp_D0 = RXB1D0;

temp_D1 = RXB1D1;

temp_D2 = RXB1D2;

temp_D3 = RXB1D3;

temp_D4 = RXB1D4;

temp_D5 = RXB1D5;

temp_D6 = RXB1D6;

temp_D7 = RXB1D7;

RXB1CONbits.RXFUL = 0;

RXMsgFlag = 0x01;

else if (B0CONbits.RXFUL) //CheckB0

temp_EIDH = B0EIDH;

temp_EIDL = B0EIDL;

temp_SIDH = B0SIDH;

temp_SIDL = B0SIDL;

temp_DLC = B0DLC;

temp_D0 = B0D0;

temp_D1 = B0D1;

temp_D2 = B0D2;

temp_D3 = B0D3;

temp_D4 = B0D4;

temp_D5 = B0D5;

temp_D6 = B0D6;

temp_D7 = B0D7;

B0CONbits.RXFUL = 0;

RXMsgFlag = 0x01;

if (RXMsgFlag == 0x01)

RXMsgFlag = 0x00;

PIR3bits.RXB1IF = 0; //A CAN Receive Buffer has received a new message

return TRUE;

else

return FALSE;

void gpsECAN_Transmit(double data0, double data1, int dLc, int sIDh0, int sIDl0 )

TxCANParse.framed[0] = data0;

TxCANParse.framed[1] = data1;

TXB0EIDH = 0x00;

TXB0EIDL = 0x00;

TXB0SIDH = sIDh0;

TXB0SIDL = sIDl0;

TXB0DLC = dLc;

TXB0D0 = TxCANParse.dadosCAN[0];








TXB0CONbits.TXREQ = 1; //Set the buffer to transmit

while(TXB0CONbits.TXREQ);

void imuECAN_Transmit(int data0,int data1,int data2, int dLc, int sIDh0, int sIDl0 )

TxCANParse.framei[0] = data0;



TXB0EIDH = 0x00;

TXB0EIDL = 0x00;

TXB0SIDH = sIDh0;

TXB0SIDL = sIDl0;

TXB0DLC = dLc;









TXB0CONbits.TXREQ = 1; //Set the buffer to transmit

while(TXB0CONbits.TXREQ);

rede can para estimativa de orientação e posição de...

Documents