FInal Project Report - PT

Departamento de Engenharia Electrotécnica

S.A.M.I.S.H. Sistema de Aquisição e Monitorização de Informação

Sensorial de um Helicóptero

Diogo Sousa, nº 042165697 João Cardoso, nº 042165686

Projecto Final de Curso de

Licenciatura em Engenharia Electrotécnica e de Computadores

Orientadores:

Prof. Tito Amaral Prof. Filipe Cardoso

Fevereiro/2010

Curso: Licenciatura em Engenharia Electrotécnica e de Computadores

Título do Projecto: SAMISH - Sistema de Aquisição e Medição de Informação Sensorial de um

Helicóptero

Autores: Diogo Rodrigues de Sousa, nº 042165697 - Ramo de Electrónica e Computadores

João Vitor Ramalho Cardoso, nº 042165686 - Ramo de Electrónica e Telecomunicações

Orientador: Prof. Tito Gerardo Batoreo Amaral

Co-Orientador: Prof. Filipe Duarte dos Santos Cardoso

Projecto entregue em: Fevereiro de 2010

Sistema de Aquisição e Monitorização de Informação Sensorial de um Helicóptero

- i -

Agradecimentos A realização deste projecto final é o culminar de um longo percurso académico,

o qual não teria sido possível sem o apoio, ajuda e motivação dos meus pais e família,

que sempre estiveram presentes e sempre compreenderam os motivos que me levaram a

roubar-lhes tempo para a escola, para o trabalho e para este projecto.

Aos colegas e amigos deixo aqui expresso um grande obrigado, por todo o apoio

e ajuda, mas principalmente pelos bons momentos e recordações da vida académica.

Obrigado aos nossos orientadores, Prof. Tito Amaral e Prof. Filipe Cardoso, por

acreditarem em nós e pela vossa orientação e ajuda ao longo do projecto. Por último,

mas não menos importantes, obrigado aos encarregados de trabalhos João Silva e Rui

Pimenta, pela paciência e disponibilidade.

João Vitor Ramalho Cardoso

Antes de mais gostaria de expressar os meus sinceros agradecimentos a todas as

pessoas que, de alguma forma, contribuíram para a realização deste Projecto Final de

Curso e de forma mais específica:

Ao Prof. Tito Amaral e Prof. Filipe Cardoso, orientadores do projecto, pela sua

coordenação, acompanhamento e motivação.

Por fim um agradecimento muito especial para os meus pais, amigos e Marisa

pelo permanente apoio e compreensão em cada momento da elaboração deste projecto.

Diogo Rodrigues de Sousa


- ii -

Resumo Os veículos aéreos autónomos (UAV - Unmanned Aerial Vehicle) têm vindo a

ser utilizados na vigilância e reconhecimento aéreo, onde a intervenção directa do ser

Humano é impossível, dispendiosa ou perigosa. O helicóptero é o veículo de eleição

devido à sua versatilidade dinâmica. No entanto é necessária a correcta aquisição e

processamento da informação sensorial existente no helicóptero, sendo este o contexto

do projecto SAMISH (Sistema de Aquisição e Monitorização de Informação Sensorial

de um Helicóptero).

O projecto é constituído por duas partes: uma estação remota e uma estação

base. A estação remota é constituída por uma rede sensorial que é composta por um

GPS, dois sonares, um acelerómetro, um giroscópio e um controlador ligados entre si

através de uma rede CAN (Controller Area Network). Esta rede consiste num

barramento composto por um par de fios e dois terminadores, proporcionando uma

comunicação em série. Os dados são recolhidos pelo nó CAN controlador que processa,

e envia os dados sensoriais através de um módulo ZigBee para uma estação base.

A estação base consiste numa aplicação para PC, desenvolvida na linguagem C#,

que permite a monitorização dos dados sensoriais adquiridos remotamente. O PC,

recorrendo a um módulo ZigBee, recebe os dados enviados pela estação remota

permitindo a sua visualização e registo em base de dados.

As áreas de aplicação do projecto estendem-se, entre outras, à detecção de

incêndios, busca e salvamento e fotografia aérea, sendo para tal necessário adicionar à

rede CAN os sensores específicos para cada aplicação.

Palavras-chave: veículo autónomo aéreo, GPS, sonar, acelerómetro, giroscópio, CAN,

ZigBee, estação remota, estação base.


- iii -

Abstract Unmanned Aerial Vehicle (UAV) have seen their applications in surveillance

and aerial recognition in situations where the direct Human intervention is impossible,

expensive or dangerous. The helicopter is the vehicle of choice due it´s dynamic

characteristics. The first step for controlling an unmanned aerial vehicle is the correct

acquisition and signal processing of the sensorial network in the helicopter, being this

the context of the SAMISH project.

The project is structured in two parts, a remote station and a base station. The

remote station consists in a sensorial network composed by a GPS, sonar,

accelerometer, a gyroscope and a controller node connected by CAN (Controller Area

Network). This network consists in a bus with a pair of lines and two terminators in

each end of the bus. The data is acquired and processed by a master CAN node, which

transmits the sensorial information to a base station via an ZigBee module.

The base station consists on a software application, developed in C#, which

allows the monitoring of the acquired sensorial data. The software application receives

the telemetric data through an ZigBee RF module, connected to a serial port (RS232),

and displays the information on the computer screen.

This project can be applied in areas, such as fire detection, search and rescue,

aerial photograph and others, requiring adding the desired sensors to the CAN network

for each specific application.

Keywords: unmanned aerial vehicle, GPS, sonar, accelerometer, gyroscope, CAN,

ZigBee, base station, remote station.


- iv -

Índice Agradecimentos ................................................................................................................. i Resumo ............................................................................................................................. ii Abstract ............................................................................................................................ iii Índice ............................................................................................................................... iv

Lista de Figuras ............................................................................................................... vi Lista de Tabelas ............................................................................................................. viii Lista de Siglas e Acrónimos ............................................................................................ ix

1. Introdução ..................................................................................................................... 1

1.1. Contexto e Motivação ............................................................................................ 1

1.2. Descrição Global do Projecto ................................................................................ 2

1.3. Organização do Trabalho ....................................................................................... 3

2. Conceitos Teóricos ....................................................................................................... 4

2.1. Sistema de Posicionamento Global ........................................................................ 4

2.1.1. Contexto histórico ........................................................................................... 4

2.1.2. Conceitos básicos ............................................................................................ 5

2.1.3. Protocolo NMEA ............................................................................................. 9

2.2. O Ultra-Som ......................................................................................................... 12

2.3. Acelerómetro ....................................................................................................... 15

2.4. Giroscópio ............................................................................................................ 18

2.5. Controller Area Network (CAN) .......................................................................... 20

2.5.1. Características de uma rede CAN .................................................................. 20

2.5.2. Princípio de Funcionamento.......................................................................... 21

2.5.3. Sincronização ................................................................................................ 23

2.5.4. Tipos de Tramas numa Rede CAN ................................................................ 24

2.5.5. Detecção e Tratamento de Erros na Rede ..................................................... 26

3. Ferramentas de Desenvolvimento .............................................................................. 28

3.1. IDE MPLAB ......................................................................................................... 28

3.2. Programador PICKit2 .......................................................................................... 30

3.3. Programa X-CTU ................................................................................................. 31

3.4. Microsoft Framework .NET 3.5 ........................................................................... 33

3.4.1. Microsoft Visual C# Express ......................................................................... 33

3.4.2. Microsoft SQL Server Compact Edition........................................................ 34

4. Módulos XBee PRO 868 ............................................................................................. 36

5. Implementação da Estação Remota ............................................................................ 39

5.1. Funcionalidades dos Nós ..................................................................................... 40

5.2. Microcontrolador PIC18F2580 ........................................................................... 42

5.3. Nó GPS ................................................................................................................ 45

5.4. Nó Sonar .............................................................................................................. 50

5.5. Nó Acelerómetro .................................................................................................. 56

5.6. Nó Giroscópio ...................................................................................................... 64

5.7. Nó Controlador .................................................................................................... 70


- v -

6. Implementação da Estação Base ................................................................................ 74

6.1. Funcionalidades da aplicação SAMISH .............................................................. 74

6.2. Modularidade de sensores .................................................................................... 76

6.3. Tratamento e visualização de dados .................................................................... 79

7. Resultados Experimentais .......................................................................................... 85

7.1. Actualização de Dados no Nó Controlador ......................................................... 85

7.1.1. Nó Acelerómetro ........................................................................................... 85

7.1.2. Nó GPS .......................................................................................................... 86

7.1.3. Nó Giroscópio ............................................................................................... 87

7.1.4. Nó Sonar ........................................................................................................ 88

7.2. Sinais Processados no Nó Sonar .......................................................................... 89

7.3. Sinais Processados no Nó Giroscópio ................................................................. 91

7.4. Barramento CAN .................................................................................................. 92

7.5. Testes de Cobertura dos Módulos XBee .............................................................. 93

8. Conclusões e Desenvolvimentos Futuros ................................................................... 96

Bibliografia ..................................................................................................................... 97

Anexos ............................................................................................................................ 99

Anexo A - Esquemas eléctricos ............................................................................ 100

Anexo B - Placas de circuito impresso.................................................................. 106

Anexo C - Código em C implementado em cada PIC .......................................... 112

Anexo D - Código fonte em C# do software SAMISH......................................... 121


- vi -

Lista de Figuras Figura 1 - Diagrama de blocos geral do projecto SAMISH. .......................................... 2Figura 2 - Diagrama de blocos pormenorizado do projecto SAMISH. .......................... 2Figura 3 - Constelação dos vinte e quatro satélites do sistema GPS (extraído de [3]). .. 6Figura 4 - Cálculo da posição através da triangulação (extraído de [3]). ....................... 7Figura 5 - Caracterização das gamas de frequência (extraído de [7]). ......................... 12Figura 6 - Modelo mecânico de um acelerómetro (extraído de [12]). .......................... 16Figura 7 - Estrutura de um acelerómetro MEMS (extraído de [13]). ............................ 16Figura 8 - Representação dos três eixos de rotação. ..................................................... 18Figura 9 - Giroscópio mecânico (extraído de [14]). ..................................................... 19Figura 10 - Arquitectura de um nó CAN. ....................................................................... 21Figura 11 - Barramento CAN. ......................................................................................... 22Figura 12 - Segmentação de um bit (extraído de [15]). .................................................. 23Figura 13 - Ajuste do tempo Phase2 do bit (extraído de [17]). ...................................... 24Figura 14 - Ajuste do tempo Phase2 do bit (extraído de [17]). ...................................... 24Figura 15 - Transições de estados dos nós. .................................................................... 27Figura 16 - Janela do IDE MPLAB. ................................................................................ 28Figura 17 - Clone do PICkit2 (em cima) e PICkit2 (em baixo). .................................... 30Figura 18 - Aspecto da janela inicial do X-CTU. ........................................................... 31Figura 19 - Teste de cobertura no X-CTU. ..................................................................... 32Figura 20 - Lista dos parâmetros configuráveis do módulo XBee através do X-CTU. ... 32Figura 21 - Ambiente de desenvolvimento Visual C#. ................................................... 34Figura 22 - Aspecto de um módulo XBee PRO 868. ...................................................... 36Figura 23 - Ficha do tipo RPSMA. .................................................................................. 37Figura 24 - Antena do tipo dipolo simples articulada. ................................................... 38Figura 25 - Diagrama de radiação de um dipolo simples (extraído de [26]). ................. 38Figura 26 - Rede de aquisição de dados. ........................................................................ 39Figura 27 - Exemplo das ligações para a rede CAN. ...................................................... 40Figura 28 - Exemplo das ligações para o PICKit2. ........................................................ 41Figura 29 - Exemplo das ligações para o modo de debug. ............................................. 41Figura 30 - Tranceiver MCP2551 (extraído de [28]). .................................................... 43Figura 31 - Aspecto do receptor GPS U-Blox5 SAM-LS (extraído de [29]). .................. 45Figura 32 - Diagrama de blocos do U-Blox5 SAM-LS (extraído de [29]). ..................... 46Figura 33 - Diagrama de blocos do nó GPS. .................................................................. 47Figura 34 - Fluxogramas do programa do nó GPS. ........................................................ 48Figura 35 - Placa do circuito impresso do nó do GPS em pormenor. ............................ 49Figura 36 - Sonar SRF04 da Devantech (extraído de [30]). ........................................... 50Figura 37 - Ligações do sonar SRF04 (extraído de [30]). .............................................. 50Figura 38 - Diagrama temporal do funcionamento do sonar SRF04 (extraído de [30]). 51Figura 39 - Diagrama de radiação do sonar SFR04 (extraído de [30]). .......................... 52Figura 40 - Fluxograma do software utilizado no PIC do nó Sonar. .............................. 53Figura 41 - Diagrama de blocos do nó do sonar. ............................................................ 54


- vii -

Figura 42 - Placa do circuito impresso do nó Sonar. ...................................................... 55Figura 43 - Diagrama de blocos do MMA7270Q (extraído de [31]). ............................. 57Figura 44 - Diagrama de blocos do nó acelerómetro. ..................................................... 59Figura 45 - Intervalo de tempo entre aquisições do nó Acelerómetro. .......................... 60Figura 46 - Fluxogramas do nó acelerómetro. ................................................................ 61Figura 47 - Janela deslizante de três posições ................................................................ 62Figura 48 - Placa do circuito impresso do nó do Acelerómetro. .................................... 63Figura 49 - Giroscópio EK2-0704 da E-Sky. .................................................................. 64Figura 50 - Sinal de inicialização do giroscópio. ........................................................... 64Figura 51 - Diagrama de blocos do Nó Giroscópio ........................................................ 65Figura 52 - Sinal do giroscópio na posição de repouso (extraído de [33]). .................... 66Figura 53 - Fluxograma do programa no microcontrolador do nó Giroscópio. ............. 67Figura 54 - Placa do circuito impresso do nó Giroscópio. ............................................. 69Figura 55 - Fluxogramas do nó Controlador. ................................................................. 70Figura 56 - Placa do circuito impresso do nó Controlador. ............................................ 72Figura 57 - Placa do circuito impresso do emissor XBee. .............................................. 73Figura 58 - Aspecto da janela principal da aplicação SAMISH. .................................... 74Figura 59 - Aspecto da janela de configuração de sensores. .......................................... 76Figura 60 - Diagrama de classes da aplicação SAMISH. ............................................... 78Figura 61 - Sequência de processamento da aplicação SAMISH. ................................. 79Figura 62 - Exemplo de visualização de uma grandeza analógica. ................................ 81Figura 63 - Exemplo de visualização dos dados do GPS. .............................................. 82Figura 64 - Exemplo de evolução temporal da aceleração nos três eixos do sensor. ..... 83Figura 65 - Localização geográfica do receptor GPS no Google Maps ......................... 84Figura 66 - Taxa de actualização dos dados provenientes do nó Acelerómetro. ............ 85Figura 67 - Taxa de actualização dos dados provenientes do nó GPS. .......................... 86Figura 68 - Taxa de actualização dos dados provenientes do nó Giroscópio. ................ 87Figura 69 - Taxa de actualização dos dados provenientes do nó Sonar. ........................ 88Figura 70 - Eco do sonar (0,5 m). ................................................................................... 89Figura 71 - Eco do sonar (15 cm). .................................................................................. 90Figura 72 - Trigger do sonar. ......................................................................................... 90Figura 73 - Saída do sinal (a) e réplica (b) do sinal amostrado no microcontrolador. ... 91Figura 74 - Sinal transceiver/barramento (a) e PIC/transceiver (b). ............................. 92Figura 75 - Trama completa no barramento CAN (Nó Giroscópio). .............................. 92Figura 76 - Parâmetros configurados no X-CTU para o teste de cobertura. ................... 93Figura 77 - Detalhe da zona e percurso do teste de cobertura dos módulos XBee. ........ 94


- viii -

Lista de Tabelas Tabela 1 - Descrição de uma frase RMC. ..................................................................... 11Tabela 2 - Velocidade do som de acordo com o meio físico (baseado em [9]). ........... 14Tabela 3 - Camadas do modelo OSI (extraído de [16]). ............................................... 22Tabela 4 - Constituição das tramas de dados numa rede CAN (extraído de [15]). ....... 25Tabela 5 - Intensidade de corrente eléctrica dos módulos XBee (extraído de [21]). .... 37Tabela 6 - Numeração dos identificadores dos nós na rede CAN. ................................ 39Tabela 7 - Selecção da escala do acelerómetro (baseado em [31]). ............................. 57Tabela 8 - Valores de tensão do acelerómetro em repouso. ......................................... 58Tabela 9 - Trama construída no nó Controlador. .......................................................... 71Tabela 10 - Campos da tabela Sensores. ........................................................................ 76Tabela 11 - Posições da trama recebida. ........................................................................ 80Tabela 12 - Resultados do teste de cobertura dos módulos XBee. ................................. 95


- ix -

Lista de Siglas e Acrónimos ACK Acknowledge

ADC Analog-to-Digital Converter

ADO ActiveX Data Object

ANACOM Autoridade Nacional de Comunicações

API Application Programming Interface

ASIC Application-Specific Integrated Circuit

CAN Controller Area Network

CLR Common Language Runtime

CR Carriage Return

CRC Cyclic Redundancy Check

CSV Comma Separated Values

DOD Department of Defense

ECU Electronic Control Unit

ESG Electro Static Gyroscopes

FOG Fiber Optic Gyroscope

GPRMC GPS Recommended Minimum Data

GPS Global Positioning System

I/O Input/Output

IDE Integrated Development Environment

ISO International Organization for Standardization

LCC Logic Connection Control

LF Line Feed

LORAN Long Range Radio Aid to Navigation

MAC Media Access Control

MEMS Micro Electro-Mechanical Systems

MIPS Millions of Instructions Per Second

MIT Massachusetts Institute of Technology

MSDN Microsoft Software Developer Network

NMEA National Marine Electronics Association

NMR Nuclear Magnetic Resonance

OSI Open Systems Interconnection

http://encyclopedia.thefreedictionary.com/Acknowledge+Character

http://www.thefreedictionary.com/Analog-to-Digital+Converter

http://encyclopedia2.thefreedictionary.com/Application+Programming+Interface

http://encyclopedia2.thefreedictionary.com/Application-Specific+Integrated+Circuit

http://encyclopedia2.thefreedictionary.com/Controller+Area+Network

http://encyclopedia2.thefreedictionary.com/Common+Language+Runtime

http://www.thefreedictionary.com/Carriage+Return

http://encyclopedia2.thefreedictionary.com/Cyclical+Redundancy+Checking

http://encyclopedia.thefreedictionary.com/Electronic+Control+Unit

http://www.thefreedictionary.com/Global+Positioning+System

http://encyclopedia2.thefreedictionary.com/Input%2fOutput

http://encyclopedia2.thefreedictionary.com/Interactive+Development+Environment

http://www.thefreedictionary.com/Line+Feed

http://encyclopedia2.thefreedictionary.com/Media+Access+Control

http://encyclopedia2.thefreedictionary.com/Micro+Electro-Mechanical+Systems

http://www.thefreedictionary.com/Million+Instructions+Per+Second

http://www.thefreedictionary.com/Massachusetts+Institute+of+Technology

http://encyclopedia2.thefreedictionary.com/Open+Systems+Interconnection


- x -

PC Personal Computer

PIC Peripheral Interface Controller

PPS Precise Positioning Service

PRN Pseudo-Random Noise

PVT Position, Velocity, Time

QNAF Quadro Nacional de Atribuição de Frequências

RAM Random Access Memory

REC Received Error Counter

RF Rádio Frequência

RHCP Right-Hand Circular Polarization

RLG Ring Laser Gyroscope

RMC Recommended minimum specific GPS/Transit data

ROM Read Only Memory

RPSMA Reverse Polarity SubMiniature version A

RTCM Radio Technical Commission for Maritime Services

RTR Remote Transmission Request

RX Reception

SAMISH Sistema de Aquisição e Monitorização de Informação Sensorial de um

Helicóptero

SAW Surface Acoustic Wave

SONAR SOund Navigation and Ranging

SPS Standard Positioning System

SQL Structured Query Language

TEC Transmitted Error Counter

TX Transmission

UART Universal Asynchronous Receiver-Transmitter

UAV Unmanned Aerial Vehicle

UHF Ultra High Frequency

UML Unified Modeling Language

USID Ultrasound Identification

UTC Universal Time Coordinated

WGS World Geodetic System

http://encyclopedia.thefreedictionary.com/Peripheral+Interface+Controller

http://encyclopedia.thefreedictionary.com/Pseudo-Random+Noise

http://www.thefreedictionary.com/Reception

http://encyclopedia.thefreedictionary.com/Surface+Acoustic+Wave

http://encyclopedia2.thefreedictionary.com/Structured+Query+Language

http://www.thefreedictionary.com/Transmission

http://www.thefreedictionary.com/Unmanned+Aerial+Vehicle

http://encyclopedia2.thefreedictionary.com/Ultra+High+Frequency

http://encyclopedia2.thefreedictionary.com/Unified+Modeling+Language

http://www.thefreedictionary.com/Universal+Time+Coordinated

http://encyclopedia.thefreedictionary.com/World+Geodetic+System


- 1 -

1. Introdução 1.1. Contexto e Motivação

A proliferação de veículos aéreos autónomos (UAV – Unmanned Aerial Vehicle)

nos últimos anos tem crescido bastante, em grande parte, na sua vertente militar, mas

também na utilização civil. Este tipo de veículos é indispensável em aplicações onde a

intervenção humana é impossível, perigosa ou dispendiosa. As áreas de aplicação,

tipicamente relacionadas com a área militar, tendem a dispersar para campos tão distintos

como a vigilância da mancha florestal, busca e salvamento, fotografia aérea,

reconhecimento militar, investigação de fenómenos atmosféricos em grande altitude,

comunicação rádio, e mais recentemente na agricultura de precisão.

A crescente capacidade de automação e comunicação e a evolução dos materiais

disponíveis tem permitido a operação destas aeronaves a distâncias e altitudes cada vez

maiores, tornando o seu potencial igual, ou mesmo superior, a outras aeronaves que

necessitam de transportar a bordo os sistemas de apoio à tripulação.

Em todos os tipos de utilização destes veículos existe a necessidade de adquirir e

processar a informação sensorial necessária à navegação autónoma.

A motivação do desenvolvimento deste projecto baseia-se na necessidade e

utilidade real deste tipo de sistemas nos mais diversos campos de aplicação. Neste

contexto, desenvolveu-se um Sistema de Aquisição e Monitorização de Informação

Sensorial de um Helicóptero (SAMISH).


- 2 -

1.2. Descrição Global do Projecto O projecto encontra-se dividido em dois blocos funcionais distintos, constituídos

pela estação remota (hardware de aquisição) e pela estação base (software de

visualização), como ilustrado na Figura 1.

Figura 1 - Diagrama de blocos geral do projecto SAMISH.

Na Figura 2 está ilustrado o diagrama de blocos pormenorizado do projecto

SAMISH, onde a estação remota, localizada no helicóptero rádio-controlado, possui os

sensores necessários para a medição das grandezas físicas, que permitem caracterizar o

movimento e a posição do helicóptero. Este bloco integra um acelerómetro de três eixos,

dois sonares, um giroscópio, um receptor GPS e um emissor sem-fios (módulo ZigBee).

Cada sensor encontra-se ligado a um barramento CAN, utilizado para a comunicação com

um nó controlador. O nó controlador é responsável pela recepção de todas as grandezas

enviadas pelos sensores e a sua transmissão via RF (Rádio Frequência) para a estação base.

A estação base, constituída por um receptor sem-fios (módulo ZigBee) e um

computador pessoal (PC), encarrega-se da recepção dos dados sensoriais e da sua

visualização e representação gráfica.

Figura 2 - Diagrama de blocos pormenorizado do projecto SAMISH.


- 3 -

1.3. Organização do Trabalho Neste relatório descreve-se o detalhe funcional e técnico do projecto desenvolvido,

dividindo-se em oito capítulos.

No Capítulo 2 são apresentados os conceitos teóricos relacionados com o

desenvolvimento do projecto descrito neste relatório, tendo como objectivo dotar o leitor

do conhecimento base essencial.

No Capítulo 3 são apresentadas e explicadas de forma sucinta as ferramentas de

desenvolvimento, quer software quer de hardware, utilizadas para o desenvolvimento do

projecto exposto neste relatório.

No Capítulo 4 são apresentadas as características e os motivos que levaram a

escolher os módulos XBee PRO 868 para a comunicação sem fios.

No Capítulo 5, é apresentado em pormenor a implementação da estação base, mais

propriamente, as características de cada um dos sensores utilizados e dos nós sensoriais

desenvolvidos para integrarem na rede CAN implementada para as comunicações na

estação base.

No Capítulo 6 são apresentadas as características e funcionalidades da aplicação

desenvolvida em C# para a monitorização das informações sensoriais recebidas da estação

remota, implementada no helicóptero.

No Capítulo 7 são apresentados os resultados experimentais do conjunto de testes

realizados para verificar o funcionamento e desempenho do sistema de aquisição e

monitorização desenvolvido.

No Capítulo 8 apresentam-se as conclusões sobre o estado de maturidade do

projecto e a sua implementação em bases comerciais, apresentando-se sugestões para

evoluções futuras do mesmo, com base na experiência adquirida ao longo da sua

realização.


- 4 -

2. Conceitos Teóricos Apresenta-se neste capítulo os conceitos teóricos associados a cada sensor existente

na estação remota e ao funcionamento de uma rede CAN.

2.1. Sistema de Posicionamento Global O Sistema de Posicionamento Global, GPS (Global Positioning System), controlado

pelo Departamento de Defesa dos Estados Unidos da América, permite a localização, num

plano tridimensional do globo terrestre, de um receptor GPS. Uma constelação constituída

actualmente por trinta satélites em seis órbitas distintas, providencia o posicionamento

geoespacial, com cobertura a nível global, necessário ao funcionamento do GPS [1].

Os sinais rádio enviados pelos satélites permitem a um receptor GPS obter

informação sobre a sua localização, velocidade, direcção, referência de tempo e outras

informações de navegação. Estas informações são utilizadas nas mais diversas aplicações,

abrangendo desde a navegação automóvel a aplicações de uso militar [1].

2.1.1. Contexto histórico O desenvolvimento e utilização de sistemas de posicionamento utilizando sinais

rádio, remontam ao início da Segunda Guerra Mundial. Os primeiros sistemas

desenvolvidos utilizavam estações base com emissores de longo alcance em baixas

frequências. Sistemas como o LORAN (Long Range Radio Aid to Navigation), Omega e

Decca foram os predecessores terrestres do actual sistema de posicionamento global e

impulsionaram tecnologicamente o seu aparecimento.

Inicialmente, desenvolvido para usos estritamente militares pelo Departamento de

Defesa (DOD) Norte-Americano, Ivan Getting e o Massachusetts Institute of Technology

(MIT), o sistema GPS consistia numa constelação de onze satélites e ficou operacional no

ano 1978. A ideia de tal sistema surgiu vários anos antes, mais precisamente em 1957, após

o lançamento do satélite russo Sputnik, o primeiro satélite artificial lançado em 4 de

Outubro de 1957. Uma equipa de investigadores do MIT reparou que, devido ao Efeito de

Doppler, o sinal rádio emitido pelo Sputnik, aumentava a sua frequência à medida que se

aproximava da posição dos investigadores e diminuia quando se afastava. Assim, a equipa

conseguiu determinar a órbita exacta descrita pelo satélite artificial.


- 5 -

Em 1983, o GPS foi autorizado para utilização civil pelo Presidente Norte-

Americano Ronald Reagan, em resposta ao incidente envolvendo o abatimento de um

avião comercial de uma companhia aérea Sul-Coreana, após entrar erradamente em espaço

aéreo Soviético. Em 1990 com o início da primeira Guerra do Golfo, o uso civil do sistema

GPS foi interdito, só sendo restabelecido em 1993, bem como a decisão de utilização livre

de custos a nível global.

Em 1995 com a activação do último dos vinte e quatro satélites em órbita, o sistema

GPS ficou completamente activo. Desde então, têm sido realizadas diversas melhorias

tecnológicas, incluindo o lançamento de seis satélites adicionais, que aumentaram

substancialmente, a fiabilidade e precisão de todo o sistema. Inicialmente, a resolução do

GPS permitia a localização de um receptor com um erro máximo de cem metros, sendo

agora na ordem dos dez a quinze metros. Com a utilização adicional de referências

terrestres é possível chegar a resoluções da ordem das poucas dezenas de centímetros [2].

2.1.2. Conceitos básicos 2.1.2.1. Princípio de funcionamento e aplicações

O GPS é formado por dois segmentos principais: o espacial e o terrestre. O

segmento espacial é constituído por vinte e quatro satélites, posicionados em seis órbitas

diferentes, quatro em cada órbita, Figura 3. Cada satélite GPS percorre a sua órbita em

torno do globo em doze horas, a uma altitude de cerca de 20.000 km.

O segmento terrestre é dividido em dois subsegmentos: o segmento de controlo e o

segmento de utilizador. O segmento de controlo é assegurado pelo Departamento de

Defesa Norte-Americano a partir de uma base Master localizada no Colorado (E.U.A.).

Com o auxílio de outras cinco estações de monitorização espalhadas pelo solo terrestre, o

segmento de controlo é responsável por processar os dados enviados pelos satélites e

transmitir de volta sinais de controlo e correcção.

O segmento de utilizador é composto pelos utilizadores dos diversos receptores

GPS espalhados pela Terra, seja na forma civil (SPS – Standard Positioning System) ou na

forma militar (PPS – Precise Positioning System).

Os satélites GPS transmitem dois sinais de rádio de baixa potência, na banda L. Os

receptores GPS civis usam a frequência L1 de 1575,42 MHz em UHF (Ultra-High

Frequency). O sinal L2 de 1227,6 MHz, é encriptado e apenas disponível para

equipamento militar, permitindo maior precisão na localização geoespacial. As


- 6 -

informações que cada satélite transmite nas suas duas portadoras (L1 e L2) são: “código de

identidade” (um código pseudo-aleatório), dados de efeméride (posição de um objecto

astronómico no espaço) e dados de almanaque (informação sobre a órbita de cada satélite e

outras informações de estado). O código de identidade (PRN - Pseudo-Random Noise)

identifica qual o satélite que está a transmitir. Usa-se como referência dos satélites os seus

PRN, de um a trinta e dois. O código pseudo-aleatório permite que todos os satélites do

sistema partilhem a mesma frequência sem interferências [3].

Figura 3 - Constelação dos vinte e quatro satélites do sistema GPS (extraído de [3]).

As aplicações do GPS podem ser catalogadas em três grandes áreas: aérea,

marítima e terrestre. A história do GPS está intimamente ligada com a aviação.

Actualmente, o sistema é utilizado tanto na aviação militar, como na aviação civil, para

efeitos de navegação.

Quanto à utilização marítima do GPS este está tipicamente associado à navegação

de barcos de recreio, embarcações de pesca e transporte de cargas.

Nos últimos anos, uma das áreas onde se tem observado maiores desenvolvimentos e

crescente penetração no mercado é a utilização terrestre do GPS, mais concretamente na

navegação automóvel.

Contudo, existem outras aplicações terrestres do uso do GPS, como por exemplo, o

montanhismo, a caça e o ciclismo. Existem no entanto, utilizações do GPS que fazem uso


- 7 -

de funcionalidades não associadas à localização do receptor, como infra-estruturas de

telecomunicações, por exemplo, para efeitos de sincronização e medições astronómicas

que utilizam o relógio de alta precisão do GPS.

2.1.2.2. Cálculo da posição

Um receptor GPS necessita de adquirir o sinal de pelo menos três satélites para

calcular a sua posição num plano bidimensional. Isto é, dois para as coordenadas de

latitude e longitude e um terceiro para o sincronismo do relógio. Por analogia, para obter

um posicionamento num plano tridimensional são necessários os sinais de pelo menos

quatro satélites. Satélites adicionais podem ser utilizados para garantir a fiabilidade,

robustez do funcionamento do receptor e minimizar o erro.

Para determinar a sua posição, um receptor GPS determina a sua distância ao

satélite através da medição precisa do tempo que os sinais emitidos pelo satélite levam a

chegar ao próprio receptor. Como o sinal enviado por cada satélite fornece a sua posição e

o momento preciso em que o sinal foi enviado, é possível determinar a latitude, longitude e

elevação a partir dos sinais recebidos de quatro satélites, três para o posicionamento

(latitude, longitude e altitude) e um satélite adicional para o sincronismo de relógio.

A Figura 4 ilustra o cálculo da posição através da triangulação. Em teoria, a

distância R1 pode ser calculada multiplicando o tempo que o sinal demora a chegar pela

velocidade a que este viaja (a velocidade da luz) [3].

Figura 4 - Cálculo da posição através da triangulação (extraído de [3]).


- 8 -

Na prática, o cálculo da distância é determinado recorrendo a cálculos mais

sofisticados, de forma a corrigir/compensar as diversas fontes de erros no sistema GPS, tais

como:

• Atrasos na ionosfera e troposfera

Os atrasos estão relacionados com a velocidade de propagação nos diferentes

meios. No entanto, o sistema é capaz de calcular uma média do atraso para corrigir

parcialmente este tipo de erro;

• Sinal com caminhos múltiplos

Ocorre quando o sinal GPS é reflectido por objectos como prédios altos ou

montanhas, antes de alcançarem o receptor, provocando desvanecimento;

• Erros do relógio do receptor

O relógio interno do receptor não é tão preciso quanto o relógio atómico dos

satélites GPS, provocando erros na medição do tempo;

• Erros de órbita

Os erros de órbita, também conhecidos como erros de efeméride, representam erros

nas informações das posições dos satélites;

• Número de satélites visíveis

Quanto mais satélites um receptor GPS puder “observar” no céu, melhor será a

precisão. Prédios, terrenos, interferências electrónicas ou uma cobertura densa de

uma floresta, por exemplo, podem bloquear a recepção do sinal, causando erros de

posição ou possivelmente, nenhuma leitura de posição no receptor. Normalmente

os receptores GPS não funcionam no interior de casas ou outras coberturas, debaixo

de água ou da terra;


- 9 -

• Geometria do posicionamento dos satélites

Refere-se à posição relativa dos satélites em qualquer instante. A geometria ideal

de um satélite é alcançada quando o ângulo que o separa dos restantes é maior.

Uma geometria propícia a erros ocorre quando os satélites estão alinhados em linha

recta ou num grupo bastante próximo.

Em aplicações específicas, os receptores GPS disponibilizam ao utilizador mais do

que as coordenadas da sua localização. Estas restantes informações, como velocidade,

direcção e outros dados de navegação, são calculadas pelo próprio receptor, com base na

informação da localização em medições consecutivas [3].

2.1.3. Protocolo NMEA O protocolo NMEA 0183, normalmente designado apenas por NMEA (National

Marine Electronics Association), descreve um conjunto de mensagens de entrada e saída,

utilizadas na comunicação com um receptor GPS. Este protocolo tornou-se um standard da

indústria de receptores GPS [4]. Para além disso, existem alguns protocolos proprietários,

como por exemplo, o protocolo GARMIN, que permitem o acesso a funções específicas de

um determinado modelo.

Neste contexto desenvolve-se apenas a utilização do protocolo NMEA nos

receptores GPS apesar de este especificar, de forma genérica, a forma de comunicação

entre instrumentos electrónicos marítimos, como sonares, anemómetros, GPS ou piloto-

automático de navios.

Ao nível da camada física, a especificação NMEA recomenda a conformidade com

o standard EIA-422, apesar de a maioria dos receptores GPS disponibilizarem apenas uma

ou duas interfaces RS-232.

A camada de aplicação (dados) consiste num conjunto de frases onde são reunidas

informações específicas referentes ao tipo instrumento. No caso de um receptor GPS, as

frases NMEA disponibilizam dados de posição, número de satélites aos quais se encontra

ligado, entre outros.


- 10 -

2.1.3.1. Formato das mensagens de saída

Uma mensagem ou frase NMEA é composta por:

• Símbolo de dólar ($);

• Identificador da frase (command word);

• Dados separados por vírgula (data words);

• Símbolo asterisco (*);

• Checksum da frase.

Segue-se um exemplo da estrutura de uma frase NMEA: “$GP<dados>*<checksum>

De notar que todos os identificadores de frase no protocolo NMEA, relacionados

com equipamentos GPS começam com os caracteres “$GP” [4].

2.1.3.2. Informação mínima recomendada para navegação GPS (RMC)

A frase RMC (Recommended minimum specific GPS/Transit data) disponibiliza a

informação mínima necessária à navegação por GPS. Este conjunto mínimo de elementos é

normalmente constituído pela posição, velocidade e tempo, designado por PVT (Position,

Velocity, Time). Apresenta-se de seguida um exemplo de uma frase RMC:

$GPRMC,200203.00,A,3831.31320,N,00850.34572,W,0.213,170.79,270709,,,A*7C

Na Tabela 1 apresenta-se a composição em detalhe de cada elemento da frase RMC

do protocolo NMEA.


- 11 -

Tabela 1 - Descrição de uma frase RMC.

Nome Exemplo Descrição

Identificador $GPRMC Identificador da mensagem RMC

Hora UTC 200203.00 hhmmss.sss

Estado A A = dados válidos, V = dados inválidos

Latitude 3831.31 ddmm.mmmm

Indicador N/S N N = Norte, S = Sul

Longitude 850.35 dddmm.mmmm

Indicador E/W W E = Este, W = Oeste

Speed over ground [nós] 0.213

Course over ground [º] 170.79

Data 270709 Ddmmyy

Variação magnética n/a Não aplicável

Modo A A = Autónomo, D = GDPS, E = DR

Checksum *7C

<CR><LF> <CR><LF> Fim de mensagem

Os dados relativos à localização no protocolo NMEA (latitude e longitude) são

definidos utilizando o sistema de coordenadas WGS-84 (World Geodetic System 1984) [5].


- 12 -

2.2. O Ultra-Som O som consiste na propagação de uma frente de compressão mecânica em meios

materiais com massa e elasticidade, como o ar, a água, os gases, etc., com excepção do

vácuo. Um som puro monotónico caracteriza-se por ser um sinal sinusoidal com uma

frequência e uma amplitude constantes. Contudo, os sons são na sua maior parte

combinações de sinais [6].

A gama de frequências audíveis pelo Homem situa-se entre os 20 Hz e os 20 kHz,

estando acima e abaixo desta gama de frequências os ultra e os infra-sons respectivamente,

como se pode ver na Figura 5.

Figura 5 - Caracterização das gamas de frequência (extraído de [7]).

As ondas ultra-sónicas são geradas por transdutores ultra-sónicos. Um transdutor

tem como objectivo a transformação de um determinado tipo de energia num outro tipo de

energia, no caso dos ultra-sons é a transformação de energia eléctrica em energia mecânica

e vice-versa. Estes transdutores são feitos de materiais piezoeléctrico que apresentam um

fenómeno chamado efeito piezoeléctrico que foi descoberto por Pierre e Jacques Curie em

1880 [8]. Este fenómeno consiste na variação das dimensões físicas de certos materiais

quando sujeitos a campos eléctricos, bem como a criação de electricidade quando estes

materiais são sujeitos a variações de pressão provenientes, por exemplo, de uma onda

sonora. Esta característica permite a utilização do mesmo transdutor quer para a emissão

como para a recepção de sinais, sejam estes ultra-sónicos ou de outra natureza.

Como o ultra-som está fora da gama de frequências perceptíveis pelo ser humano,

podem ser aplicados em diversas situações com uma intensidade bastante elevada. As

aplicações do ultra-som de baixa potência têm como propósito a transmissão de energia

através de um determinado meio para obter informação sobre o mesmo. As aplicações dos


- 13 -

ultra-sons de alta potência têm como objectivo produzir alterações no meio através do qual

se propagam as ondas ultra-sónicas. Alguns exemplos de aplicações dos ultra-sons são [7]:

• Diagnóstico e tratamento na medicina

O diagnóstico baseia-se na reflexão das ondas ultra-sónicas para a criação de uma

imagem em tempo real da zona que está a ser analisada, fornecendo um meio de

diagnóstico mais seguro do que os meios de radiação ionizante por ser um método

não invasivo. O exemplo mais conhecido são as ecografias. As ondas ultra-sónicas

de alta potência têm aplicações no tratamento de algumas doenças, devido à sua

característica destrutiva do meio onde as ondas se propagam;

• Limpeza ultra sónica

Com ondas ultra-sónicas, geralmente na gama dos 20 kHz aos 40 kHz, é possível

proceder à limpeza de joalharia, lentes, instrumentos cirúrgicos, etc. Este tipo de

limpeza consiste na vibração das partículas de sujidade, quando sujeitas às ondas

ultra-sónicas, nas cavidade microscópicas do objecto a ser limpo, fazendo com que

estas se libertem do objecto;

• Identificação ultra-sónica

A identificação por ultra-sons (USID – Ultrasound Identification) baseia-se num

sistema de localização em tempo real, utilizado para monitorizar e identificar a

localização de diversos objectos, recorrendo a uma rede composta por vários nós

com identificadores embebidos nos objectos, que emitem ondas ultra-sónicas e

microfones para a detecção da localização dos mesmos;

• Química

Consiste na utilização das ondas ultra-sónicas para a separação de camadas que

constituem uma molécula, através da pressão ou temperatura gerada pela aplicação

das ondas ultra-sónicas à solução aquosa em que se encontram as moléculas. Este

tipo de aplicação baseia-se mais no comprimento de onda das ondas ultra-sónicas

do que propriamente na sua intensidade;


- 14 -

• Desintegração ultra-sónica

Recorrendo à combinação de intensidade e comprimento de onda de ondas ultra-

sónicas, consegue-se desintegrar um vasto número de meios, desde bactérias a

betão, bem como alterar o estado físico de certos materiais, passando-os do estado

sólido para o estado líquido.

No projecto descrito neste relatório a aplicação dos ultra-sons tem como objectivo a

detecção de distâncias. Este tipo de aplicação também é conhecido como SONAR (SOund

NAvigation and Ranging).

A utilização de ultra-sons como SONAR consiste na criação, por parte de

transdutores, de uma ou um conjunto de ondas ultra-sónicas numa direcção bem definida.

Quando um objecto é detectado na área em que foram transmitidas as ondas ultra-sónicas,

um eco é reflectido de volta para o emissor devido ao choque das ondas enviadas com o

objecto que se encontra no seu caminho. Medindo a diferença de tempo entre o momento

da transmissão das ondas ultra-sónicas e da recepção do eco é possível determinar a que

distancia se encontra o objecto do ponto de emissão. O tempo entre o envio e recepção está

condicionado pela temperatura e pelo meio físico em que se propagam as ondas ultra-

sónicas. A Tabela 2 mostra a relação entre a temperatura e a densidade do meio físico com

a velocidade do som para algumas substâncias.

Tabela 2 - Velocidade do som de acordo com o meio físico (baseado em [9]).

Meio Físico Substância Velocidade

Referência [m/s]

Coeficiente

Temperatura [m/s ºC]

Densidade

[g/cm3]

Gases

Ar 331.45 0.59 --

Oxigénio 316.00 0.56 --

Hidrogénio 1284.00 2.20 --

Líquidos

Água 1496.70 -2.40 --

Benzeno 1295.00 4.65 --

Éter Etílico 985.00 4.87 --

Sólidos

Prata 2680.00 -- 10.40

Ferro 5200.00 -- 7.85

Mármore 3810.00 -- 2.60


- 15 -

2.3. Acelerómetro Um acelerómetro é um dispositivo electromecânico que mede a aceleração a que

uma massa de prova é sujeita. Este tipo de dispositivos pode ser utilizados para medir a

intensidade da aceleração, bem como a sua direcção e orientação. Com aplicações no ramo

da engenharia, medicina, navegação, transportes e electrónica de consumo, os

acelerómetros tornaram-se um instrumento de medida bastante popular, graças aos avanços

tecnológicos no seu processo de fabrico [10].

Existem diversos tipos de acelerómetros divididos em dois grandes grupos:

mecânicos e de estado sólido. Os acelerómetros mecânicos, já bastante desenvolvidos

tornaram-se obsoletos em aplicações modernas, face às melhorias constantes no processo

de fabrico de dispositivos de estado sólido. Estes utilizam uma massa de prova acoplada a

um dinamómetro na mesma direcção da aceleração que se quer medir [10].

Os acelerómetros de estado sólido englobam componentes como os acelerómetros

piezoeléctricos, acelerómetros SAW (Surface Acoustic Wave) e mais recentemente os

acelerómetros embebidos no silício, através de técnicas MEMS (Micro Electro-Mechanical

Systems).

A tecnologia de fabrico MEMS consiste num processo de fabrico que junta

elementos mecânicos como membranas, molas e sistemas cantilever (tipo de construção

apoiado em um só ponto, como por exemplo a asa de um avião ou uma prancha de piscina)

à escala da micro-electrónica, sendo assim possível a sua integração no substrato de silício

de dispositivos de estado sólido. Tipicamente, os elementos micro-mecânicos são inferiores

a 100 µm e são construídos num processo de micro-fabricação, oposto ao processo de

maquinaria convencional.

Um acelerómetro MEMS é composto por uma massa de prova que se desloca em

relação à sua frame de referência, através de pratos com amortecimento. Na Figura 6

apresenta-se o diagrama mecânico simplificado de um acelerómetro. A Figura 7 ilustra o

desenvolvimento do acelerómetro utilizando a tecnologia MEMS [11].


- 16 -

Figura 6 - Modelo mecânico de um acelerómetro (extraído de [12]).

Figura 7 - Estrutura de um acelerómetro MEMS (extraído de [13]).


- 17 -

Os acelerómetros com tecnologia MEMS têm sido os impulsionadores da

proliferação dos acelerómetros na electrónica de consumo como portáteis, leitores de MP3

e telemóveis. A tecnologia MEMS revolucionou o uso de airbags na indústria automóvel

nos anos 90. Os acelerómetros micro-maquinados fornecem uma solução de baixo

consumo, compacta e robusta.

No contexto deste projecto, o acelerómetro de três eixos (x, y e z) é utilizado como

parte integrante de um sistema de navegação inercial, com vista a obter um plano de

referência estabilizado do helicóptero.


- 18 -

2.4. Giroscópio A principal função de um giroscópio é determinar a velocidade angular de um

corpo, ou seja, a quantidade de rotação produzida pelo corpo por unidade de tempo [14].

Esta rotação está tipicamente associada a um dos três eixos ilustrados na Figura 8,

que são o eixo da rotação da direcção sobre o plano horizontal, inclinação lateral sobre um

plano horizontal e inclinação frontal sobre um plano horizontal. Os giroscópios podem

também ser utilizados para medir o ângulo que um determinado corpo faz em relação a um

outro corpo, objecto ou superfície.

Figura 8 - Representação dos três eixos de rotação.

Os giroscópios são cada vez mais utilizados como sensores com a função de

cumprirem algumas tarefas em sistemas de navegação, de piloto automático e estabilização

de plataformas, tirando partido da sua capacidade de se oporem às forças exteriores a que

são sujeitos.

Os primeiros giroscópios faziam uso das propriedades inerciais de um rotor a rodar

a alta velocidade num eixo principal (giroscópios mecânicos), de tal modo que o eixo onde

se encontra o rotor continua a apontar sempre na mesma direcção, apesar dos círculos

articulados (Gimbals) em volta deste eixo movimentarem-se em oposição às forças

exteriores aplicadas ao giroscópio [14], Figura 9.


- 19 -

Figura 9 - Giroscópio mecânico (extraído de [14]).

Actualmente as técnicas de fabrico de giroscópios são em tudo semelhantes às

técnicas usadas no fabrico dos acelerómetros, destacando-se [14]:

• Transdutores com esferas de mercúrio;

• Sensores magneto-hidrodinâmicos;

• Giroscópios de efeito vibratório (que podem utilizar por exemplo materiais

piezoeléctricos);

• Giroscópios NMR (Nuclear Magnetic Resonance);

• Giroscópios Electrostáticos (ESG – ElectroStatic Gyroscopes);

• Sensores de efeito óptico que incluem os dispositivos RLG (Ring Laser Gyroscope) e o

FOG (Fiber Optic Gyroscope).


- 20 -

2.5. Controller Area Network (CAN) As redes CAN (Controller Area Network) foram desenvolvidas no seio da indústria

automóvel, para dar resposta à crescente complexidade dos sistemas electrónicos

conhecidos como ECU´s (Electronic Control Unit), existentes num veículo

automóvel [15]. As ECU´s mais não são que sistemas computacionais que têm sido

gradualmente incluídos nos automóveis, muitas vezes associadas a sensores, para gerirem

diversas funções do motor, facilitar a condução, aumentar a segurança, proporcionar mais

conforto aos ocupantes, etc. A necessidade de comunicação entre as várias ECU´s

incluídas no automóvel fez com que fosse utilizado cada vez um maior número de fios

neste, para a comunicação entre as diversas ECU´s.

De forma a simplificar as ligações entre as diversas ECU´s, a Bosch, em meados

dos anos 80, desenvolveu o protocolo de comunicação CAN. Este permitiu reduzir a

quantidade de fios utilizados, recorrendo a um barramento constituído somente por um par

de fios endereçados como uma linha de dados série.

Posteriormente o protocolo CAN tornou-se na norma internacional ISO 11898 [16]

(International Organization for Standardization) e o seu licenciamento para o

desenvolvimento e criação de microcontroladores e outros dispositivos compatíveis com a

norma, dando origem à actual vasta gama de dispositivos que incorporam esta tecnologia

como um meio de comunicação simples, modular e robusto, com velocidades até 1 Mbit/s.

As redes CAN são utilizadas nos dias de hoje em várias áreas de aplicação como a

indústria, automação, domótica, aviação, robótica, etc.

2.5.1. Características de uma rede CAN De entre as características principais de uma rede CAN, salientam-se as

seguintes [17]:

• Taxa de comunicação até 1 Mbit/s;

• Comunicação a dois fios;

• Custo e complexidade de implementação reduzidos;

• Possibilidade de comunicações ponto a ponto, multi-ponto ou difusão;

• Mecanismos de detecção e correcção de erros;

• Tolerância a falhas de hardware;

• Flexibilidade de adição ou remoção de nós na rede.


- 21 -

Os nós que compõem uma rede CAN seguem uma arquitectura que consiste num

processador, num controlador CAN e num transceiver, como ilustrado na Figura 10 [16].

Figura 10 - Arquitectura de um nó CAN.

2.5.2. Princípio de Funcionamento O protocolo CAN implementa as camadas 1 e 2, camada física e camada de ligação

de dados respectivamente, do modelo OSI (Open Systems Interconnection) [16],

apresentado na Tabela 3.


- 22 -

Tabela 3 - Camadas do modelo OSI (extraído de [16]).

Responsabilidade Camada Descrição

Sistema

7 – Aplicação Serviços relacionados com a aplicação

6 – Apresentação Formata a informação

5 – Sessão Mantém o diálogo entre os dispositivos em comunicação

4 – Transporte Transferência de mensagens

Rede

3 – Rede Estabelecimento, manutenção e corte das ligações de rede

2 – Ligação de dados Gestão do fluxo de informação num mesmo meio

1 – Físico Transmite a informação para o meio físico

Na camada de ligação de dados operam duas sub-camadas, a sub-camada de

Controlo Lógico de Ligação (LCC – Logic Connection Control) e a sub-camada de

Controlo de Acesso ao Meio (MAC – Media Access Control) [17]. A LCC é a responsável

pela recepção, filtragem e recuperação de dados enquanto a sub-camada MAC é

responsável pela detecção de falhas e pela sinalização e verificação de erros.

É na camada física que é feita a ligação propriamente dita com o barramento, onde

são definidas as características de transporte, tais como os níveis de tensão e impedância

das linhas de comunicação do barramento. A codificação e descodificação de bit também

são feitas nesta camada.

Na Figura 11 está representado um barramento CAN, que é composto por dois fios

de comunicação e dois terminadores, que mais não são que duas resistências com a mesma

impedância dos fios utilizados para as linhas de dados, de forma a garantir a adaptação de

impedância.

120Ω

120Ω

CANH

CANL Figura 11 - Barramento CAN.

O barramento pode assumir três estados [17]: o estado idle, o dominante e o

recessivo. No estado idle não existe nenhuma informação no barramento, enquanto o

estado dominante é o que se sobrepõe ao estado recessivo, caso se verifique um acesso

múltiplo por parte dos nós ao barramento. Esta característica pode também ser definida


- 23 -

como um processo de competição não destrutivo ao nível do bit, em que o acesso ao

barramento é concedido à mensagem mais prioritária, com a menor latência possível.

Quando um nó ganha o acesso ao barramento (dominante) e interrompe a transmissão de

um outro nó (recessivo), este retoma o acesso ao barramento assim que o nó dominante

termine a comunicação [17].

2.5.3. Sincronização No protocolo de comunicação CAN existem dois mecanismos de sincronização: a

sincronização forçada e a re-sicronização [15].

A sincronização forçada dá-se quando um nó se encontra no modo de recepção e é

detectada uma transição de estado recessivo para dominante no barramento [17].

A re-sicronização consiste na mudança automática dos parâmetros do tempo de bit

de acordo com o momento em que ocorre a transição de estado recessivo/dominante no

barramento [17]. O tempo de bit é composto por várias secções temporais, como ilustrado

na Figura 12.

Figura 12 - Segmentação de um bit (extraído de [15]).

Sync é a detecção de mudança de estado no barramento CAN, Prop é o tempo de

guarda para compensar os atrasos inerentes á propagação da informação no meio físico e

os campos Phase1 e Phase2 correspondem aos tempos ajustáveis automaticamente para a

re-sincronização, de forma a optimizar o ponto de amostragem (Sample Point), momento

em que o bit é interpretado [16]. Caso a re-sincronização se dê demasiado cedo, o tempo

Phase2 do bit é encurtado, como ilustrado na Figura 13, caso seja tarde demais o tempo

Phase1 do bit é alargado, como ilustrado Figura 14 [17].


- 24 -

Figura 13 - Ajuste do tempo Phase2 do bit (extraído de [17]).

Figura 14 - Ajuste do tempo Phase2 do bit (extraído de [17]).

2.5.4. Tipos de Tramas numa Rede CAN Existem quatro tipos de tramas numa rede CAN: dados, remota, de erro e de

sobrecarga [17].

As tramas de dados numa rede CAN podem ser a trama base (CAN 2.0A) e a trama

estendida (CAN 2.0B). A diferença entre estes dois tipos de tramas é o número de bits

utilizados no identificador, sendo de 11 bits no caso da trama base e de 29 bits no caso da

trama estendida, mais um bit reservado na trama estendida. A composição de cada trama

pode ser observada na Tabela 4.

A compatibilidade entre as tramas do tipo CAN2.0B e as CAN2.0A é garantida

através dos controladores utilizados para implementar a rede CAN, pois estes têm a

capacidade de ignorar o segundo identificador das tramas do tipo CAN2.0B [17].


- 25 -

Tabela 4 - Constituição das tramas de dados numa rede CAN (extraído de [15]).

Trama Base ou CAN 2.0A

Campo Tamanho

[bits] Descrição

Start of Frame (SOF) 1 Sinaliza o inicio da transmissão da trama

Identificador 11 Identificador único da trama

Remote Transmission

request (RTR) 1 Bit dominante

Identifier extension bit

(IDE) 1 Bit dominante

Reserved bit (R0) 1 Bit dominante ou recessivo

Data lenght code

(DLC) 4 Número de bytes a ser transmitido (0-8)

Dados 64 Dados a serem transmitidos, que podem variar de 0 a 8 bytes

Cyclic Redundancy

Check (CRC) 15 Controlo de erros

ACK 1 Sinalização de recepção da mensagem

ACK 2 1 Sinalização da recepção da mensagem, obrigatoriamente 1

End of Frame (EOF) 15 Obrigatoriamente recessivo

Trama Estendida ou CAN 2.0B

Campo Tamanho

[bits] Descrição

SOF 1 Sinaliza o inicio da transmissão da trama

Identificador A 11 Primeira parte do identificador único da trama

Subscrive Remote

Request (SRR) 1 Campo recessivo opcional

IDE 1 Bit recessivo

Identificador B 18 Segunda parte do identificador único da trama

RTR 1 Bit dominante

Reserver bits (R0, R1) 2 Bits reservados

DLC 4 Número de bytes a ser transmitido (0-8)

Dados 64 Dados a serem transmitidos, que podem variar de 0 a 8 bytes

CRC 15 Controlo de erros

CRC 2 1 Bit recessivo

ACK 1 Sinalização de recepção da mensagem

ACK 2 1 Sinalização da recepção da mensagem

EOF 7 Obrigatoriamente recessivo


- 26 -

A trama remota é utilizada para fazer o pedido de transmissão de dados ao invés do

envio de dados, em que o bit RTR (Remote Transmission Request) é recessivo. Na

eventualidade de existir a transmissão simultânea de uma trama de dados e uma trama

remota com o mesmo identificador, o acesso ao barramento é dado à trama de dados, pois

o bit RTR é dominante na trama de dados.

A trama de erro serve para sinalizar a existência de um erro e interromper a

mensagem que está a ser transmitida, de forma a garantir a coerência dos dados na rede.

A trama de sobrecarga é constituída por dois campos, o Overload Flag e Overload

Delimiter. Estas tramas são transmitidas caso seja necessário criar um atraso entre envios

de tramas de dados ou para a detecção de um bit dominante no barramento.

2.5.5. Detecção e Tratamento de Erros na Rede A detecção de erros tem por base a transmissão de uma mensagem de erro emitida

pelo nó receptor quando detecta um erro, pedindo a retransmissão da mensagem ao nó

emissor, ao mesmo tempo que os restantes nós ignoram a mensagem de erro. Numa rede

CAN existem cinco mecanismos de detecção de erros [17]:

• Teste de redundância cíclico;

• Testes de trama;

• Erro de confirmação;

• Erro de monitorização;

• Erro de bit stuffing.

Quando pelo menos um nó da rede CAN detecta um erro através dos mecanismos

em cima mencionados, a transmissão presente de dados é interrompida e sinalizado o erro,

para que a mensagem com o erro não chegue a mais nós receptores, mantendo a

consistência dos dados que circulam na rede. Assim que a transmissão de uma mensagem

com erro for parada, o nó emissor tenta retransmitir a mensagem. Contudo estes

mecanismos podem também levar a degradação da rede no caso se trate de um erro

permanente.

De forma a contornar esta situação, o protocolo trata estas situações recorrendo a

dois contadores que limitam os erros [17]. Existe então um contador de erros ocorridos na

transmissão (TEC – Transmitted Error Counter) e outro contador de erros ocorridos na

recepção (REC – Received Error Counter), os quais são incrementados a quando da


- 27 -

detecção de um erro nos respectivos casos e decrementados nos casos de sucesso de

recepção ou emissão. Mediante o valor destes contadores, cada nó pode operar nos

seguintes estados [17]:

• Error active

Estado em que os nós operam por defeito, funcionando em pleno e com valor dos

contadores menor que 127 unidades;

• Error passive

Também chamado de estado de alerta, situação em que o contador TEC ou o

contador REC igualam ou excedem as 127 unidades. Neste estado o nó CAN deixa

de sinalizar erros no barramento, de forma a não congestionar a rede com este tipo

de mensagens. Caso o erro tenha sido temporário e os contadores sejam

decrementados para valores inferiores às 127 unidades, o nó passa novamente para

o estado Error active;

• Bus off

O nó CAN entra neste estado quando o valor do contador TEC é igual ou superior

às 255 unidades. Neste estado o nó suspende por completo a sua actividade na rede,

só voltando a funcionar normalmente quando se fizer um reset ao nó.

A Figura 15 ilustra o grafo da transição de estados em que um nó CAN pode operar.

Figura 15 - Transições de estados dos nós.


- 28 -

3. Ferramentas de Desenvolvimento

3.1. IDE MPLAB O programa MPLAB, ilustrado na Figura 16, é um IDE (Integrated Development

Environment) gratuito da Microchip que oferece as ferramentas necessárias para o

desenvolvimento de projectos em torno dos microcontroladores PIC, como controladores

para os programadores da Microchip, funções de debug por software ou hardware,

integração de compiladores externos, etc.

Figura 16 - Janela do IDE MPLAB.

O MPLAB por si só apenas permite desenvolver programas em linguagem

assembly, sendo necessário recorrer a compiladores externos para se poder utilizar

linguagens de alto nível como o C, neste caso o CCS C Compiler da Custom Computer

Services.

Este oferece uma vasta colecção de bibliotecas para muitos dos microcontroladores

da Microchip, preparadas de tal forma que conferem à programação um bom nível de

abstracção recorrendo a um conjunto de métodos para configurar e controlar os diversos

periféricos fornecidos no PIC. Os métodos mais utilizados para o desenvolvimento deste

projecto foram:


- 29 -

• can_init()

Inicializa o controlador CAN embebido no microcontrolador;

• can_getd(rx_id, buffer, rx_len, rxstat)

Recupera uma mensagem de um dos buffers do CAN e guarda as informações nas

variáveis dos parâmetros da função. A variável rx_id é o identificador do nó a

que se destina a mensagem, buffer são os dados propriamente ditos, len é

número de buffers utilizados para a transmissão da mensagem e rxstat é uma

variável de controlo para erros;

• can_putd (rx_id,data,len,priority,ext,rtr)

Este método constrói um packet próprio para a transmissão da informação através

do protocolo CAN. Às variáveis já mencionadas na função can_getd

acrescentam-se a variável prioraty, que estabule-se as prioridades das

mensagens, ext, variável que define a utilização ou não de um ID extended e

finalmente a variável rtr, que é um bit de controlo do protocolo;

• rs232(baud, xmit, rcv)

Função que configura a porta série, em que a variável boud é o boud rate que se

pretende utilizar e as variares xmit e rcv utilizam-se para configurar os pinos de

envio e recepção respectivamente;

• setup_adc_ports(anX_to_anY_analog | vss_vref)

Configura as entradas do conversor analógico para digital do PIC, desde a entrada

X até à Y, bem como a utilização de uma tensão de referência diferente da que

alimenta o PIC;

• enable_interrupts(interrupts)

Função para configurar as interrupções que se pretendem utilizar. A variável

interrupt corresponde à interrupção que se pretende utilizar.


- 30 -

3.2. Programador PICKit2 O PICKit2 é dos programadores para os microcontroladores PIC mais versáteis da

Microchip, não só devido á compatibilidade deste com um vasto número de PIC mas

também por ser um projecto Open Source [18], quer isto dizer, desde o início a Microchip

deu acesso ao público a todos os detalhes, componentes, software e esquemáticos do

PICKit2, dando origem a um vasto número de clones e um rápido desenvolvimento e

despiste de problemas por parte duma comunidade de utilizadores on-line que contribui

para o desenvolvimento e melhoramento do PICKit2. Na Figura 17 apresenta-se um clone

do PICKit2 e o respectivo original.

Figura 17 - Clone do PICkit2 (em cima) e PICkit2 (em baixo).

Apesar de existir um software próprio para trabalhar com o PICKit2, optou-se por

utilizar as funções de controlo do PICKit2 embebidas no MPLAB.


- 31 -

3.3. Programa X-CTU O X-CTU, ilustrado na Figura 18, é um programa que permite aceder facilmente,

através do computador, às diversas funcionalidades e procedimentos de teste dos módulos

XBee [20].

Figura 18 - Aspecto da janela inicial do X-CTU.

Para aceder ao módulo XBee basta configurar a porta COM à qual este está ligado e

fazer um “Test/Query” para verificar se a ligação é bem sucedida. Como se pode observar

na Figura 18, é possível fazer testes de cobertura, aceder aos módulos XBee através de um

terminal de texto e configurar os diversos parâmetros do módulo. A Figura 19 ilustra o

aspecto de um teste de cobertura e na Figura 20 pode observar-se parte da lista dos

parâmetros configuráveis através do X-CTU.

A configuração do módulo XBee é a principal vantagem na utilização do X-CTU,

pois permite uma escolha rápida dos múltiplos parâmetros que se pretendem configurar, ao

invés da utilização dos comandos AT através de um terminal de texto, os quais somente


- 32 -

permitem configurar um parâmetro de cada vez e requerem também tempos de atraso entre

comandos para sincronização [21].

Figura 19 - Teste de cobertura no X-CTU.

Figura 20 - Lista dos parâmetros configuráveis do módulo XBee através do X-CTU.


- 33 -

3.4. Microsoft Framework .NET 3.5 A Framework .NET é uma plataforma de desenvolvimento e execução de

aplicações da Microsoft. À semelhança do Java, as aplicações .NET são desenvolvidas

centrando-se na plataforma em si e não no sistema onde irão ser executadas. Deste modo

qualquer aplicação .NET pode ser executada em qualquer dispositivo Windows que possua

tal plataforma (e em ambiente Linux através do projecto Mono).

As aplicações .NET são executadas sobre uma Common Language Runtime (CLR)

que utiliza uma biblioteca de classes, permitindo o desenvolvimento em mais de vinte

linguagens de programação diferentes, como por exemplo o Visual Basic .NET e o C# [22].

O software de monitorização do projecto SAMISH foi desenvolvido na linguagem

C#, da qual se destacam as seguintes características:

• Semelhança com a linguagem JAVA na sintaxe e no paradigma de Orientação a

Objectos;

• Documentação e integração com sistemas operativos Microsoft Windows;

• Desenvolvimento rápido de interfaces gráficas;

• Componentes nativos para comunicação série e integração de base de dados

SQL Server.

3.4.1. Microsoft Visual C# Express O Microsoft Visual C# Express é um ambiente de desenvolvimento integrado

(IDE – Integrated development environment) da linguagem C# para a plataforma .NET. A

versão utilizada para o desenvolvimento do projecto SAMISH é gratuita para todo o tipo

de aplicações (comerciais e não-comerciais).

O IDE fornece um conjunto de ferramentas essenciais ao desenvolvimento rápido

de aplicações com ou sem interface gráfica, como sejam corrector de sintaxe, compilador,

desenho de interface gráfica, funções de diagnóstico (debug) e criação de pacotes de

instalação. Adicionalmente, o Visual C# Express oferece uma integração completa com o

motor de base de dados SQL Server Compact Edition, permitindo de uma forma rápida

criar/editar tabelas, inserir e consultar dados [23].

Existem outros IDE para a programação na linguagem C#, como é o caso do

projecto open source SharpDevelop. A escolha incidiu neste IDE, em particular, pela


- 34 -

extensa documentação existente nas bibliotecas da Microsoft, habitualmente designada por

MSDN.

Figura 21 - Ambiente de desenvolvimento Visual C#.

3.4.2. Microsoft SQL Server Compact Edition O SQL Server Compact Edition é um sistema de base de dados relacional

compacto, desenvolvido pela Microsoft para os segmentos mobile e desktop. Esta versão

do SQL Server partilha a API (Application Programming Interface) com todas as versões

SQL Server, permitindo o uso da mesma sintaxe SQL das versões mais avançadas.

Por se tratar de um sistema de gestão de base de dados embebido, toda a base de

dados fica contida num único ficheiro, facilitando o seu manuseamento.

A gestão da base de dados é realizada directamente no IDE Visual C# através da

ferramenta Server Explorer, onde é possível editar graficamente a base de dados, criar

tabelas e inserir dados. O acesso aos dados é efectuado recorrendo aos componentes

ADO.NET, integrados na biblioteca .NET.


- 35 -

Como os componentes ADO.NET são de aplicação genérica, é possível rapidamente

mudar de um sistema de gestão de base de dados para outro, bastando para isso alterar a

ligação [24].


- 36 -

4. Módulos XBee PRO 868 A escolha dos módulos XBee PRO 868 para comunicação RF (Rádio Frequência)

tem por base a análise do QNAF (Quadro Nacional de Atribuição de Frequências),

publicado pela ANACOM (Autoridade Nacional de Comunicações), que regulamenta a

atribuição de frequências para comunicações sem fios. Esta análise foi imperativa para a

selecção dos módulos, para se conhecerem as frequências livres de licenciamento, limites

da potência de transmissão e tipo de aplicações permitidas.

Os módulos XBee PRO 868, Figura 22, funcionam na frequência dos 869.525 MHz

e têm uma potência máxima (configurável) de emissão de 300 mW [21], o que os torna

isentos de licenciamento e de “uso geral”, de acordo com QNAF [25].

Para além da utilização isenta de licenciamento, estes módulos possuem um

conjunto de características que os torna adequados para a aplicação em causa,

nomeadamente, a possibilidade de escolha de vários níveis de potência de emissão, ritmos

de transmissão adequado e a possibilidade de utilizar diferentes tipos de antenas para

adaptar a cobertura pretendida com o tipo de aplicação, como indicado na seguinte lista,

que evidencia várias características dos módulos [21]:

• Cobertura até 550 m em ambiente urbano e interiores;

• Cobertura até 40 km em linha de vista, com uma antena dipolo de 2.0 dBi;

• Interface UART de 3.3 V (também tolerante a 5 V);

• Interface UART configurável desde 1200 bps a 230.4 kbps;

• Ritmo de transmissão RF até 24 kbps;

• Potência de emissão regulável de 1 a 300 mW;

• 64 bits de endereçamento para identificação;

• Encriptação de 128 bits.

Figura 22 - Aspecto de um módulo XBee PRO 868.


- 37 -

Na Tabela 5 apresenta-se a intensidade de corrente eléctrica associado a cada um

dos níveis de potência de transmissão configuráveis no módulo XBee.

Tabela 5 - Intensidade de corrente eléctrica dos módulos XBee (extraído de [21]).

Potência de Emissão Intensidade de Corrente [mA] [mW] [dBm]

1 0 85 25 14 150

100 20 280 200 23 350 300 25 500

Ambos os módulos utilizados no projecto descrito neste relatório, um módulo para

a estação remota e outro para a estação base, vêm com uma ficha do tipo RPSMA (Reverse

Polarity SubMiniature version A), Figura 23.

Figura 23 - Ficha do tipo RPSMA.

As antenas utilizadas, semelhantes à da Figura 24, são dipolos simples articulados

com um ganho de 2.0 dBi. O nível de potência aparente radiada de acordo com a antena

utilizada e a potência de emissão configurada no módulo XBee, pode ser calculada

recorrendo à seguinte equação [21],

(1)

em que P é a potência aparente radiada expressa em dBm, PM é a potência de transmissão

configurada no módulo XBee, G é o ganho da antena utilizada em dBi e L é a atenuação em

dB causada pelo cabo, que liga o módulo à antena.


- 38 -

Figura 24 - Antena do tipo dipolo simples articulada.

O diagrama de radiação das antenas do tipo dipolo simples, encontra-se ilustrado na

Figura 25.

Figura 25 - Diagrama de radiação de um dipolo simples (extraído de [26]).


- 39 -

5. Implementação da Estação Remota O diagrama de blocos que caracteriza a rede CAN implementada na estação remota

encontra-se representado na Figura 26. Como se pode observar cada nó tem a arquitectura

de um nó CAN tal como descrito na secção “Controller Area Network (CAN)” deste

relatório. Este diagrama ilustra o tipo de comunicação utilizada por cada sensor, o

identificador utilizado na rede CAN para cada nó e a prioridade que cada nó tem

relativamente ao acesso ao barramento.

Nó ControladorBarramento CAN

AcelerómetroMMA7260QEixos XYZ

Analógico

ADC

PIC18F2580CAN

ID:20Prior.:1

MCP2551

GPS U-BloxSAM-LS

RS232

PIC18F2580CAN

ID:30Prior.:3

MCP2551

RS232

Sonar Ultra-Som

SRF04

Digital

PIC18F2580CAN

ID:10Prior.:1

MCP2551

I/O

Módulo RFXBee Pro

RS232

PIC18F2580CAN

ID:N/APrior.:N/A

MCP2551

RS232

GiroscópioE_sky

EK2-0704

Digital

PIC18F2580CAN

ID:15Prior.:1

MCP2551

I/O

Figura 26 - Rede de aquisição de dados.

A numeração dos identificadores dos nós CAN foi efectuada de modo a que as

diferentes interfaces de comunicação de cada sensor fiquem compreendidas numa mesma

gama de identificadores, Tabela 6.

Tabela 6 - Numeração dos identificadores dos nós na rede CAN.

Interface Identificadores Descrição Digital/Analógica 1-9 Canais reservados para testes e desenvolvimento.

Digital 10-19 Sensores ou comunicações com interface e processamento de sinal digital.

Analógica 20-29 Sensores ou comunicações com interface e processamento de sinal analógico.

RS232 30-39 Sensores ou comunicações com interface e processamento de sinal série RS232

Indefinido 40-112 Canais livres para futuros desenvolvimentos.


- 40 -

5.1. Funcionalidades dos Nós De forma a aumentar as funcionalidades de cada um dos nós CAN desenvolvidos,

foram implementadas as seguintes funcionalidades em cada um:

• Ligações ao barramento CAN adaptáveis

Cada placa tem dois sockets de quatro pinos, Figura 27, de forma a poder ligar cada

nó directamente ao barramento ou “fechar” o barramento directamente no nó, de

forma a proporcionar ligações ponto a ponto ou em estrela dos nós CAN;

• Ligações para o programador PICKit2

Foi incluído em cada nó um conjunto de cinco pinos, Figura 28, para tornar

possível a ligação do PICKit2 de forma a actualizar o software dos

microcontroladores de cada nó bem como para recorrer aos mecanismos de debug

oferecidos pelo MPLAB para a detecção e correcção de erros do software

programado no microcontrolador;

• Ligações para o modo de debug

O modo de debug permite ver num computador, através da porta RS232, uma cópia

dos dados que um nó está a enviar para o barramento CAN. As ligações para este

modo são as ilustradas na Figura 29, bastando ligar os pinos RX e TX a um

MAX233 (Driver RS232) e sinalizar o modo de debug com 5 V no pino sinal. Os

pinos +5V e GRD podem ser utilizados para alimentar o MAX233 ou a placa onde

este esteja inserido. Estas ligações podem também ser úteis quando se fazem novos

desenvolvimentos no programa do microcontrolador de um nó CAN.

Figura 27 - Exemplo das ligações para a rede CAN.


- 41 -

Figura 28 - Exemplo das ligações para o PICKit2.

Figura 29 - Exemplo das ligações para o modo de debug.


- 42 -

5.2. Microcontrolador PIC18F2580 Os microcontroladores PIC (Peripheral Interface Controller) tiveram a sua origem

na universidade de Harvard como um projecto para o Departamento da Defesa dos Estados

Unidos da América, com o objectivo de criar uma família de memórias simples e

confiáveis, em que a memória para o código e a memória para dados estão separadas

(Arquitectura de Harvard).

Contudo a tecnologia não foi aproveitada pelo Departamento da Defesa mas sim

pela General Instruments como meio de compensar o fraco barramento I/O dos

microcontroladores existentes na altura, dando origem ao nome PIC, Peripheral Interface

Controller.

Em 1985 foi criada uma empresa secundária à General Instruments, a Arizona

Microchip Technology, que tinha como principal produto e objectivo de desenvolvimento

os microcontroladores PIC, caracterizados pelo vasto número de registos e periféricos

embebidos no microcontrolador, tornando-o num produto com um barramento I/O bastante

completo e adaptável.

Actualmente os microcontroladores PIC utilizam memórias do tipo flash ROM para

armazenar o código de programa e memórias RAM para armazenar os dados. Este tipo de

arquitectura aumenta significativamente a velocidade de processamento dos PIC, a sua

versatilidade de programação e confere-lhes uma latência de atendimento a interrupções

constante (3 ciclos de instruções), tornando-os indicados para aplicações de tempo real.

Estão disponíveis microcontroladores de 8, 16 e 32 bit com tecnologias de alta eficiência

energética.

O PIC18F2580 foi o microcontrolador escolhido para a realização dos nós

sensoriais devido às suas características [27]:

• Alimentação de 2,0 V a 5,5 V;

• Elevado número de MIPS (Millions of Instructions Per Second);

• Arquitectura optimizada para compiladores C;

• Rápida programação e limpeza da memória de programa flash;

• Programação directa em circuito;

• Interface série RS232;

• Conversor analógico/digital de 10 bit com auto aquisição do sinal;

• Módulo de comunicação CAN.


- 43 -

A flexibilidade na alimentação proporciona uma economia no consumo de energia

na estação remota e facilita a ligação com os dispositivos que são alimentados

exclusivamente a 3,3 V, tais como o acelerómetro, o módulo GPS e os módulos de

comunicação XBee. A arquitectura de memória para o programa em flash, aliado à

programação em série directamente ligada ao circuito, facilita o desenvolvimento devido à

flexibilidade de apagar e reprogramar o PIC e à utilização de técnicas e ferramentas de

debug para o despiste de erros. Um aspecto importante na escolha deste microcontrolador

foi o módulo que possibilita a comunicação através do barramento CAN, que torna toda a

operação de comunicação no barramento transparente do ponto de vista do

desenvolvimento.

Para a ligação de cada nó do projecto ao barramento CAN, recorreu-se ao tranceiver

MCP2551, ilustrado na Figura 30. Este transceiver é o responsável pelas funções de

ligação física do modelo OSI, descrito anteriormente.

Figura 30 - Tranceiver MCP2551 (extraído de [28]).

Este transceiver permite a implementação de redes CAN até 1 Mbit/s e um máximo

de 112 nós por rede. Possui também protecção térmica, protecção contra curto-circuito nos

pinos de alimentação e protecção contra estados transitórios falsos devido a picos de tensão

no barramento. Através do pino RS, podem-se implementar três modos de funcionamento

[28]:

• Modo Stand-by

Activo quando o pino está no nível lógico 1, o que implica que o transceiver entre

em modo sleep para reduzir o consumo de energia;


- 44 -

• Modo de alta velocidade

Activo quando o pino está no nível lógico 0, modo utilizado para o projecto, em

que as velocidades praticadas são na ordem dos 1 Mbit/s;

• Modo Slope-Control

Consiste na ligação de uma resistência entre o pino e a massa, de forma a controlar

a velocidade que o nó opera no barramento, de acordo com o valor da resistência

utilizada.

No que respeita às ligações, os pinos TXD e RXD são os que fazem a interface com

o microcontrolador e os pinos CANH e CANL fazem a interface com o barramento CAN.


- 45 -

5.3. Nó GPS O módulo GPS U-Blox5 SAM-LS, é um receptor GPS all-in-one, que incluí o

módulo receptor GPS e uma patch antena integrada, Figura 31.

Figura 31 - Aspecto do receptor GPS U-Blox5 SAM-LS (extraído de [29]).

As características deste módulo GPS enquadram-se nos requisitos do projecto,

essencialmente devido à sua reduzida dimensão (31.5×47×9.5 mm), reduzido peso (23 g) e

tensões de alimentação entre os 2,7 e 3,3 V que resultam num consumo de 168 mW.

Apesar do protocolo NMEA definir que a frequência de envio de dados (frases NMEA) é no

máximo 1 Hz, o módulo GPS actualiza a sua posição a uma taxa de 4 Hz [29], isto é,

quatro vezes por segundo.

O SAM-LS suporta diferentes protocolos de dados série, disponibilizados em duas

portas UART (Universal Asynchronous Receiver-Transmitter). A selecção pode ser

realizada mediante comandos do protocolo UBX (u-Blox), proprietário do fabricante, que

permitem escolher entre o protocolo NMEA, UBX e RTCM (Radio Technical Commission

for Maritime Services).

A antena RHCP (Right-Hand Circular Polarization) do tipo patch tem um ganho

de +5 dBic na orientação vertical e -1 dBic com uma elevação de 10º.

A Figura 32 mostra o diagrama de blocos do módulo GPS utilizado, indicando os

principais sinais disponibilizados. Por defeito, o SAM-LS envia apenas mensagens de saída

NMEA na porta UART1 com um baud rate de 9600 bps, a uma frequência de 1 Hz [29].


- 46 -

Figura 32 - Diagrama de blocos do U-Blox5 SAM-LS (extraído de [29]).

A interface com o receptor GPS SAM-LS é realizada por intermédio de um

microcontrolador PIC18F2580.

A Figura 33 ilustra o diagrama de blocos do nó GPS, explicitando os elementos que

o compõem.


- 47 -

uC

Circuito oscilador

Malha de reset

GPSSAM-LS

RS232

TransceiverCAN

Bus CAN ……

Nó GPS

Figura 33 - Diagrama de blocos do nó GPS.

Pode descrever-se o funcionamento do nó GPS como um processo de aquisição dos

dados enviados pelo GPS SAM-LS e o envio dessa informação (GPRMC), através do

barramento CAN. Existem alguns procedimentos que devem ser tomados em consideração,

como a configuração da porta série do PIC e os processos inerentes ao envio de dados

através do barramento CAN.

O microcontrolador comunica com o módulo GPS através da sua UART a uma

velocidade de 9600 bps, com oito bits de dados, sem paridade e um stop bit.

O programa existente no microcontrolador do nó GPS começa por inicializar o

barramento CAN (definição do endereço e prioridade associada), bem como activar a

interrupção que irá atender os pedidos de comunicação através da porta série,

Figura 34 (a). Após a correcta inicialização destes elementos o programa inicia o seu ciclo

normal de funcionamento (ciclo infinito), isto é, processa as frases NMEA recebidas do

módulo GPS e trata do seu envio através do barramento CAN.

No ciclo principal de funcionamento, o microcontrolador aguarda a recepção de

uma frase RMC completa e após a sua correcta recepção, divide a frase recepcionada em

frases de oito bytes. Cada conjunto de oito bytes é enviado através do barramento CAN


- 48 -

para o nó Controlador. É gerado um atraso de 75 ms após cada envio para evitar o

congestionamento do barramento.

Sempre que são recepcionados novos dados na porta série o programa é

interrompido para atender o seu pedido de processamento, Figura 34 (b). Caso o programa

esteja a enviar os dados através do barramento CAN, todos os dados recepcionados são

descartados de forma a evitar o congestionamento do buffer de entrada (overflow).

No caso de não estar a ocorrer o envio de dados no barramento CAN, os dados

recebidos são filtrados de forma a garantir a correcta recepção da frase RMC. Cada byte

recebido é adicionado a uma frase, que após a recepção do caracter terminador

(caracter 13 – Carriage Return) terá uma frase RMC completa. Neste momento é

sinalizado o fim de recepção e inicia-se o envio da frase recebida através do barramento

CAN.

Início

Inicializar CAN

Activar atendimento da interrupção UART

Possui RMC completo?

Não

Encontrou terminador

RMC ?

Não

Sim

Sim

Limpa string RMC recebida

Gera atraso de 75 ms

Atendimento à interrupção UART

Sinaliza fim de transmissão CAN

Terminou envio CAN?

É o primeiro caracter e é ‘$’

É o terceiro caracter e é ‘R’

Filtra frase RMC

Incrementa índice do buffer

Fim

Não

Não

Sim

Sim

Sim

Não

Envia 8 bytes da string por CAN

Lê caracter presente no buffer da UART

Escreve no buffer final

Descarrega leitura para evitar overflow

(a) (b)

Figura 34 - Fluxogramas do programa do nó GPS.


- 49 -

A Figura 35 mostra em pormenor a placa de circuito impresso desenvolvida para o

nó do GPS onde se faz referência às ligações do programador PICKit2, da rede CAN, do

modo de debug e do receptor GPS. Como foi referido já anteriormente, a placa foi

desenhada a pensar na modularidade e futuros desenvolvimentos deste nó.

Figura 35 - Placa do circuito impresso do nó do GPS.


- 50 -

5.4. Nó Sonar O sonar utilizado é o SRF04, Figura 36, da Devantech, desenhado e inspirado nos

sonares da Polaroid, controlados por um trigger para o envio de uma trama ultra-sónica e

uma saída eco para sinalizar o eco das ondas ultra-sónicas enviadas [30].

Figura 36 - Sonar SRF04 da Devantech (extraído de [30]).

O sonar SRF04 é alimentado a 5 V e tem um consumo máximo de 50 mA. As

dimensões são de 43 mm de largura, 20 mm de altura e de 17 mm de espessura. As

ligações disponibilizadas pelo módulo sonar encontram-se ilustradas na Figura 37.

Figura 37 - Ligações do sonar SRF04 (extraído de [30]).


- 51 -

Para melhor perceber o funcionamento do sonar SRF04, pode-se observar o

diagrama temporal ilustrado na Figura 38. Como se pode observar todo o funcionamento

do sonar é despoletado pela aplicação de um sinal de, no mínimo, 10 µs no pino de trigger,

que dá origem ao envio de um trem de 8 pulsos ultra-sónicos à frequência de 40 kHz. Após

o envio deste trem de pulsos, a saída eco do sonar é colocada automaticamente no nível

lógico alto até que seja detectado o eco do trem ultra-sónico enviado. Assim que o eco seja

detectado a saída de eco do sonar é posta no nível lógico baixo, sendo o tempo que esteve

no nível lógico alto equivalente à distância a que se encontra o objecto, tendo em conta a

velocidade do som no meio em que as ondas ultra-sónicas se propagaram. Caso não seja

detectado nenhum objecto, a sinal da saída eco permanece no nível lógico alto durante

36 ms. Todo o funcionalmente descrito é feito de forma automática pelo sonar a partir do

momento que se dá o sinal de trigger, não sendo possível alterar nenhuma das

características de funcionamento nesta gama de sonares [30].

Figura 38 - Diagrama temporal do funcionamento do sonar SRF04 (extraído de [30]).

O diagrama de radiação do sonar encontra-se representado na Figura 39. Ao

contrário do disponibilizado em alguns sonares, no SRF04 não é possível alterar a forma

do diagrama de radiação para que seja possível medir maiores distâncias ou aumentar o

ângulo de detecção de objectos [30].


- 52 -

Figura 39 - Diagrama de radiação do sonar SFR04 (extraído de [30]).

O tempo que leva a ser reflectido o eco do envio de um trem de pulsos de ondas

ultra-sónicas depende da distância a que se encontra um objecto do sonar. Pode-se definir

esse tempo como tempo de voo, o qual depende do meio em que se propagam as ondas

ultra-sónicas. Considerando o ar como meio de propagação, então a velocidade de

propagação é dada por:

(2)

em que C é a velocidade do som em metros por segundo e T a temperatura em graus

celsius. A distância a que se encontra o objecto do sonar é dada por:

(3)

onde d representa a distância em metros, e t representa o tempo de voo em segundos que o

eco leva a chegar.

O fluxograma do software existente no PIC do nó Sonar, onde se encontram ligados

os dois sonares, é o apresentado na Figura 40. Como se pode observar, o programa calcula

os tempos de eco de cada sonar continuamente através da função Cálculo do tempo de eco


- 53 -

do sonar i, que segue a lógica de funcionamento do sonar SFR04. Recorre-se ao Timer 1

do microcontrolador para determinar o tempo que o sinal eco esteve no nível lógico alto.

Posteriormente os dados processados são enviados para o barramento CAN.

Na Figura 41 encontra-se ilustrado o diagrama de blocos do nó Sonar, constituído

por um microcontrolador, um tranceiver CAN e por dois sonares. Um dos sonares é

utilizado para a medição da distância ao solo e o outro sonar usado para a medição da

distância a que se encontram obstáculos da dianteira do helicóptero.

Início

Inicializar CAN

Cálculo do tempo de eco do sonar 1

Cálculo do tempo de eco do sonar 2

Cálculo do tempo de eco do sonar i

Limpa o timer 1

Pino de eco está no valor lógico baixo?

Inicia o timer 1

Pino de eco está no valor lógico alto?

Para o timer 1

SIM

NÃO

SIM

NÃO

Fim

Envio por CAN dos dados dos sonares

Pino trigger colocado no nível lógico alto

durante 10 µs

Retorna o valor do timer 1

Figura 40 - Fluxograma do software utilizado no PIC do nó Sonar.


- 54 -

uC

Circuito oscilador

Malha de reset

SonarSRF04

TransceiverCAN

Bus CAN ……

Nó Ultra-Som

I/O C0I/O C1I/O C2I/O C3

TriggerEcho

SonarSRF04

TriggerEcho

Figura 41 - Diagrama de blocos do nó do sonar.

Na Figura 42 pode-se ver em pormenor a placa de circuito impresso desenvolvida

para o nó Sonar. É feita referência às ligações dos sonares, do programador PICKit2, do

modo de debug e do CAN.


- 55 -

Figura 42 - Placa do circuito impresso do nó Sonar.


- 56 -

5.5. Nó Acelerómetro O acelerómetro é utilizado no contexto deste projecto para permitir determinar a

aceleração dinâmica e estática a que o helicóptero está sujeito em todas as direcções

(x, y e z).

O acelerómetro MMA7270Q da Freescale Semiconductor, é um acelerómetro

micro-maquinado (MEMS) de três eixos de baixo consumo, com saída em tensão

proporcional à aceleração a que está sujeito.

A aceleração estática é utilizada para medir a inclinação em qualquer um dos três

eixos do acelerómetro. No caso da medição da aceleração estática, assume-se que o corpo

(helicóptero) está estático e apenas sujeito à aceleração da gravidade.

A aceleração dinâmica, medida nos três eixos do acelerómetro, fornece informação

sobre as forças a que o helicóptero está sujeito num determinado instante. De entre as

características do acelerómetro destaca-se [31]:

• Selecção de sensibilidade (1.5 g, 2 g, 4 g e 6 g);

• Baixo consumo de corrente: 500 µA;

• Tensão de alimentação entre 2,2 V e 3,6 V;

• Acondicionamento de sinal interno com filtro passa-baixo;

• Compensação de temperatura no cálculo da aceleração.

O MMA7270Q é constituído por duas estruturas micro-maquinadas semelhantes à

da Figura 7 e por um circuito integrado de aplicação específica (ASIC – Application

Specific Integrated Circuit) responsável pelo acondicionamento de sinal.

Para medir a aceleração, o MMA7270Q faz uso da variação da distância entre os

pratos móveis da massa de prova e os pratos da estrutura, como já ilustrado na Figura 7.

Utilizando a técnica de condensadores comutados as capacidades C1 e C2 são medidas pelo

circuito ASIC, que irá converter a capacidade medida num valor de tensão proporcional à

aceleração.

A Figura 43 ilustra os elementos constituintes do acelerómetro utilizado. De notar

que o ASIC utiliza uma medição de temperatura para compensar o valor de saída de cada

um dos eixos do acelerómetro (Xout, Yout, Zout) [31].


- 57 -

Figura 43 - Diagrama de blocos do MMA7270Q (extraído de [31]).

Os pinos g-Select1 e g-Select2 permitem a selecção da escala do acelerómetro e

respectiva sensibilidade de saída, mediante a sua combinação binária, conforme descrito na

Tabela 7. A sensibilidade do acelerómetro foi configurada para 300 mV/g através da

ligação física descrita na Tabela 7.

O pino Sleep Mode permite activar o modo de adormecimento do acelerómetro.

Quando adormecido, o acelerómetro reduz o seu consumo para 3 µA [31]. Uma vez que a

amostragem dos sinais de cada eixo do acelerómetro é realizada em modo free-run optou-

se por não utilizar esta funcionalidade do acelerómetro.

Tabela 7 - Selecção da escala do acelerómetro (baseado em [31]).

g-Select1 g-Select2 Escala [g] Sensibilidade [mV/g] 0 0 ± 1.5 800 1 0 ± 2.0 600 0 1 ± 4.0 300 1 1 ± 6.0 200

Na Tabela 8 podem-se observar os valores Xout, Yout e Zout do acelerómetro quando

este se encontra sujeito somente à aceleração da gravidade (no eixo z). Realça-se a

diferença de tensão na saída Zout, relativamente às restantes, uma vez que no eixo z, em


- 58 -

repouso, o acelerómetro sofre -1 g de aceleração (devido à aceleração da gravidade). Os

testes foram realizados utilizando a escala de ±4 g (300 mV/g) do acelerómetro.

Tabela 8 - Valores de tensão do acelerómetro em repouso.

Saída Tensão [V]

Xout 1,96

Yout 1,96

Zout 2,32

Pode observar-se que a saída Zout relativamente a Xout possui uma diferença de

360 mV (ΔV = 2.32 – 1.96 = 0,36 V). A sensibilidade do acelerómetro foi configurada para

300 mV/g, como tal, seria espectável obter esse mesmo valor na diferença entre a saída do

eixo z e as saídas dos eixos x e y, uma vez que existe entre eles uma diferença de 1 g (em

repouso). A diferença de 60 mV entre o valor teórico e prático prende-se com as margens

de tolerância do fabricante para o nível de tensão de saída de cada eixo em repouso

(mínimo de 1,485 V e máximo de 1,815 V à temperatura de 25 ºC e VDD de 3,3 V) [31].

A interface com o acelerómetro MMA7270Q no projecto SAMISH é realizada por

intermédio de um microcontrolador PIC18F2580. A Figura 44 mostra o diagrama de

blocos do nó acelerómetro, explicitando os elementos que o compõem.


- 59 -

Figura 44 - Diagrama de blocos do nó acelerómetro.

O acelerómetro MMA7270Q disponibiliza três saídas analógicas (em tensão), que

são ligadas a três dos oito canais ADC (10 bits), disponibilizados pelo PIC18F2580. O nó

acelerómetro é responsável pela calibração do zero g de cada um dos eixos, pela conversão

analógico-digital, separação do valor em dois bytes) e pelo envio dos valores amostrados,

através do barramento CAN.

A amostragem dos canais ADC é realizada pelo PIC em free-run, permitindo assim

185 amostras por segundo, em cada canal, conforme ilustra a Figura 45 (a), em que o

processo de amostragem e registo do valor de cada eixo dura 20 µs.


- 60 -

(a)

(b)

Figura 45 - Intervalo de tempo entre aquisições do nó Acelerómetro.

Como forma de minimizar o ruído inerente à electrónica e às próprias

características do helicóptero, utilizaram-se filtros RC do tipo passa-baixo, aplicados

directamente às saídas do acelerómetro, para limitar a largura de banda do sinal do

acelerómetro aos 10 kHz e reduzir o ruído provocado pelo gerador de relógio interno [31].

Adicionalmente, implementou-se no microcontrolador um filtro de janela deslizante

de três posições para os valores amostrados, eliminando assim grande parte das variações


- 61 -

bruscas provocadas pelas vibrações do helicóptero, ilustrado pelo fluxograma da

Figura 46 (b).

A Figura 46 ilustra o funcionamento do nó acelerómetro através de um fluxograma

simplificado.

Início

Inicializar canais ADC 0..2

Inicializar CAN

Calibração

Rotação para esquerda da janela de

amostras i

Define canal ADC i

Amostra concluída? Não

Sim

Amostragem canal i

Fim

Amostragem canal 0 (x)

Amostragem canal 1 (y)

Amostragem canal 2 (z)

Calibração

Define canal ADC 0 (x)

Define canal ADC 1 (y)

Define canal ADC 2 (z)

Fim

Envia por CAN os valores amostrados dos 3 eixos

Escreve no array e realiza média

Lê canal i

Lê 3 amostras do canal ADC 0



(a) (b) (c)

Figura 46 - Fluxogramas do nó acelerómetro.

O programa executado pelo microcontrolador responsável pelo Nó Acelerómetro

começa por inicializar os canais ADC associados a cada eixo do acelerómetro. De seguida,

o microcontrolador inicializa a comunicação CAN e realiza a calibração do acelerómetro.

A calibração consiste em adquirir três amostras consecutivas para cada eixo e tomar

o valor médio obtido, como o valor de referência (zero) para as amostras seguintes (filtro


- 62 -

de média). Após a calibração o microcontrolador entra no ciclo principal de

funcionamento, isto é, o processo de amostragem e envio dos dados.

Após a amostragem de cada canal ADC (eixo do acelerómetro) realizada de forma

sequencial, o valor obtido é colocado numa das três posições de um array. Este processo

de janela deslizante permite que, em cada momento, o valor enviado através do barramento

CAN seja uma média aritmética de três amostras. A amostra mais recente toma o lugar da

mais antiga e assim sucessivamente, Figura 47.

Figura 47 - Janela deslizante de três posições.

A Figura 48 ilustra o pormenor a placa do circuito impresso desenvolvida para o nó

do acelerómetro.


- 63 -

Figura 48 - Placa do circuito impresso do nó do Acelerómetro.


- 64 -

5.6. Nó Giroscópio O giroscópio é utilizado no contexto deste projecto para medir a velocidade angular

do helicóptero.

O giroscópio EK2-0704 da E-Sky, ilustrado na Figura 49, normalmente utilizado em

aplicações de aeromodelismo, é utilizado no contexto do projecto, descrito neste relatório,

para medir a velocidade angular em torno de um eixo. O EK2-0704 dispõe também de um

regulador de ganho da sensibilidade e inversão do sinal [32]. Os factores que levaram à sua

utilização neste projecto prendem-se essencialmente com o seu baixo custo face à

concorrência, reduzido peso (50 g) e reduzido consumo (aproximadamente 10 mA) [32].

Figura 49 - Giroscópio EK2-0704 da E-Sky.

O funcionamento do giroscópio começa pela recepção de um conjunto de pulsos,

ilustrados na Figura 50, de forma a estabilizar o seu funcionamento. Enquanto o giroscópio

não estiver estabilizado o led vermelho do giroscópio estará intermitente, ficando fixo logo

que o giroscópio estiver pronto a ser utilizado [32].

t

1.5ms 10ms

Figura 50 - Sinal de inicialização do giroscópio.


- 65 -

A interface com o giroscópio EK2-0704 no projecto SAMISH é realizada por

intermédio de um microcontrolador PIC18F2580. A Figura 51 mostra o diagrama de

blocos do nó giroscópio, explicitando os elementos que o compõem.

uC

Circuito oscilador

Malha de reset

Giroscópio EK2-0704

TransceiverCAN

Bus CAN ……

Nó Giroscópio

INT0C2

OutIn

Figura 51 - Diagrama de blocos do Nó Giroscópio.

Pode observar-se, na Figura 51, que a saída do giroscópio se encontra ligada à

interrupção externa do microcontrolador (INT0). A interrupção externa foi configurada

para responder a uma transição de 0 para 1, de forma sinalizar a recepção de um novo

pulso enviado pelo giroscópio.

O sinal de entrada do giroscópio encontra-se normalmente ligado a um receptor RF

de modelismo, que recebe os sinais de comando de controlo dos servos. Neste caso, a

entrada do giroscópio recebe um sinal de trigger enviado pelo microcontrolador que simula

o sinal gerado pelos módulos de controlo de modelismo, até que o funcionamento do

giroscópio estabilize [33]. Após a sequência inicial de triggers, o giroscópio inicia o seu

funcionamento, disponibilizando na sua saída um sinal periódico com um pulso com uma

largura proporcional à velocidade angular a que o giroscópio está sujeito, sendo a


- 66 -

referência de repouso (velocidade angular nula) um pulso de 1,5 ms, como ilustrado na

Figura 52.

Figura 52 - Sinal do giroscópio na posição de repouso (extraído de [33]).

Uma vez que o fabricante não disponibiliza, na sua ficha técnica, dados relevantes

ao desenvolvimento, recorreu-se à informação padrão sobre servos de corrente contínua

utilizados no aeromodelismo.

O padrão utilizado nos servos refere uma variação de 10 µs por grau. Este valor foi

utilizado como referência para o cálculo da velocidade angular.

Os fluxogramas da Figura 53 ilustram o funcionamento do programa no

microcontrolador do nó Giroscópio.


- 67 -

Início

Inicializar CAN

Envio do trigger para giroscópio

Envio do trigger para giroscópio

i = 0

PIN_C2 = 0

PIN_C2 = 1

Aguarda 1500us

PIN_C2 = 0

i = i + 1

Aguarda 10ms

i < 100

SIM

Fim

Não

Activa interrupção externa INT0

Calcula duração do impulso do giroscópio

Envia via CAN o resultado obtido

Rotina de atendimento à interrupção INT0

Limpa o registo do timer 0

Activa o timer 0

Desactiva o timer 0

NÃO

Regista o valor do timer 0

Fim

(a) (b) (c)

Pulso da saída do giroscópio

está a 1?

SIM

Figura 53 - Fluxograma do programa no microcontrolador do nó Giroscópio.

O programa começa por inicializar a comunicação CAN. De seguida, envia o sinal

de trigger para o giroscópio, garantindo assim a correcta inicialização do giroscópio,

durante o seu período de arranque. É activado o atendimento à interrupção externa 0

(INT0) e de seguida o programa entra no seu ciclo principal (infinito), onde se encarrega

de enviar a duração do impulso do giroscópio, através do barramento CAN.

O procedimento de envio do trigger consiste em enviar uma série de pulsos com

1,5 ms de largura para o giroscópio, até que este esteja correctamente inicializado,

momento em que o led do giroscópio passa de intermitente para fixo.


- 68 -

Quando o microcontrolador detecta um flanco ascendente no pino INT0, irá ser

chamada a rotina de atendimento à interrupção. A rotina encarrega-se de realizar a medição

da duração do pulso fornecido pelo giroscópio.

O tempo de pulso medido em repouso, no momento em que o giroscópio inicializa

o seu funcionamento, é o tomado como referência para as medições seguintes.

Este nó, ao contrário dos restantes, envia através do barramento CAN os dados já

nas suas grandezas físicas, de forma a demonstrar algumas características do programa

desenvolvido para a estação base. A equação utilizada para o cálculo da velocidade angular

foi a seguinte,

(4)

em que w é a velocidade angular em graus por segundo, Tref representa o tempo de

referência em microssegundos medido no momento da inicialização do giroscópio e Tpulso

corresponde ao tempo em microssegundos do sinal gerado pelo giroscópio.

Como referido anteriormente, o giroscópio disponibiliza na sua saída um sinal

periódico com um pulso com uma largura proporcional à velocidade angular, como tal, Tref

e Tpulso correspondem à variação temporal, equivalente à velocidade angular a que o

giroscópio está sujeito, tendo em consideração que uma diferença de 10 µs corresponde à

variação de 1º.

A Figura 54 mostra em pormenor a placa de circuito impresso desenvolvida para o

nó Giroscópio. De notar, que nesta placa, em relação às já apresentadas nas secções

anteriores deste relatório, foram adicionados dois pinos de prova, que permitem verificar

através de um osciloscópio, o funcionamento e processamento do sinal do giroscópio.


- 69 -

Figura 54 - Placa do circuito impresso do nó Giroscópio.


- 70 -

5.7. Nó Controlador É no nó Controlador que toda a informação proveniente dos nós sensoriais é

concentrada e preparada para ser enviada via RS232. O funcionamento do programa

implementado no microcontrolador do nó Controlador é o apresentado pelos fluxogramas

da Figura 55.

Início

Inicializar CAN

Configuração dos parâmetros RS232

Prepara dados para o envio de uma nova

trama

Nova trama de GPS

completa?

Desactiva as interrupções

Limpa variável de envio GPS na trama

Prepara novos dados GPS para a trama

Activa as interrupções

Envio da trama com todos os dados

sensoriais via RS232

Atraso 100mS

SIM

NÃO

Atendimente à interrupção CAN

Os dados são válidos?

SIM

NÃO

É o ID10 SIM

Recebe e copia para processamento os

dados do Nó Acelerómetro

É o ID20

NÃO

SIM

É o ID30

NÂO

SIM

FIM

Encontrou terminador da trama RMC ?

NÃO

Sinaliza uma nova trama GPS completa

SIM

É o ID15

NÃO

SIM

Recebe e copia para processamento os

dados do Nó Giroscópio

NÃO

Recebe e copia para processamento os dados do Nó Sonar

Recebe 8 bytes da string da trama RMC

do GPS por CAN

Figura 55 - Fluxogramas do nó Controlador.


- 71 -

Como se pode observar na Figura 55, no nó Controlador começa-se por inicializar e

configurar os periféricos do microcontrolador necessários. Neste caso, o CAN e a porta

UART para comunicação via RS232, que está configurada para transmitir à velocidade de

115.2 kbps.

Após esta configuração, começa a ser atendida a interrupção CAN, que é

despoletada cada vez que existem informações no barramento. No momento em que é feito

a atendimento à interrupção do barramento CAN, é feita uma verificação à informação

recebida para confirmar a integridade do packet recebido, caso seja um packet válido

recorre-se ao identificador deste para descobrir de qual dos nós sensoriais é proveniente a

informação, de acordo com os valores já referidos na Tabela 6. A informação é processada

e copiada para variáveis locais do programa implementado no microcontrolador, para

posteriormente ser enviada via RS232.

O nó Controlador serve somente de “ponte” entre os dados recebidos dos nós

sensoriais através do barramento CAN e o reenvio destes através de RS232 para outro

dispositivo, não existindo qualquer tipo de processamento ou conversão de grandezas no

nó Controlador, quer os dados sensoriais recebidos através da rede CAN estejam em

“bruto” ou já nas suas respectivas grandezas físicas.

A trama construída no nó Controlador segue a apresentada na Tabela 9, onde se

pode ver a posição dos dados de cada um dos sensores.

Tabela 9 - Trama construída no nó Controlador.

Trama utilizada no projecto SAMISH Nó Acelerómetro Nó Sonar Nó

Giroscópio Nó GPS Eixo X Eixo Y Eixo Z Sonar A Sonar B

A Figura 56 apresenta em pormenor a placa de circuito impresso desenvolvida para

o nó Controlador. Ao contrário dos restantes nós, o nó Controlador possui cinco ligações

para o barramento CAN e já tem incorporado os terminadores que “fecham” o barramento.


- 72 -

Figura 56 - Placa do circuito impresso do nó Controlador.

Existem também nesta placa dois circuitos de alimentação, um circuito

independente e um que alimenta directamente os componentes da placa. O circuito de

alimentação independente é constituído por três entradas, uma ficha de dois bornes, dois

pinos e um powerjack, enquanto o circuito que alimenta directamente os componentes da

placa é somente constituído por uma ficha de dois bornes. Pretende-se com estes dois

circuitos de alimentação proporcionar várias combinações para alimentar a placa do nó

Controlador ou para alimentar outras placas ou componentes a partir desta.

Foi também incluído nesta placa um conjunto de cinco pinos directamente ligados

ao porto A do microcontrolador PIC, que podem ser utilizados para verificar a taxa de

actualização dos dados no nó Controlador, provenientes dos nós sensoriais.

A ligação para o envio dos dados é feita através de uma ficha DB9 fêmea, que

permite ligar a placa directamente a um computador ou a qualquer outro dispositivo

preparado para este tipo de ligação, no caso do projecto descrito neste relatório, um

módulo XBee PRO 868.

O módulo XBee utilizado está configurado para trabalhar a uma velocidade de

comunicação de 115.2 kbps (tal como o nó Controlador) e a uma potência de emissão de


- 73 -

200 mW. Esta potência apesar de cumprir com o que é necessário para a aplicação em

causa, é também o máximo recomendado para se utilizar nas placas do kit de

desenvolvimento dos módulos XBee, facilitando assim alternar o módulo XBee entre a

placa emissora desenvolvida e a placa do kit de desenvolvimento. Na Figura 57 ilustra-se

em pormenor a placa de circuito impresso desenvolvida para incorporar o módulo XBee.

Figura 57 - Placa do circuito impresso do emissor XBee.

À semelhança do nó Controlador, a alimentação da placa de circuito impresso do

módulo emissor XBee pode ser feita através de uma ficha de dois bornes, dois pinos ou um

powerjack. A placa do emissor XBee liga directamente à placa do nó Controlador através

de uma ficha DB9 macho. Para alterar os parâmetros configurados no módulo XBee através

desta placa, é necessário utilizar um adaptador que altere a ficha DB9 macho para fêmea.


- 74 -

6. Implementação da Estação Base A aplicação SAMISH, existente na estação base, foi desenvolvida tendo em atenção

a modularidade do código de forma a permitir a integração, transparente, de novos

sensores remotos. O modelo seguido para o desenvolvimento do código faz uso do

paradigma de programação orientada a objectos para a definição de sensores, facilitando a

manutenção do código e sua expansão.

6.1. Funcionalidades da aplicação SAMISH A janela principal da aplicação fornece um meio gráfico de visualizar os dados de

telemetria recebidos da estação remota. As grandezas analógicas são mostradas sob a

forma numérica e num gráfico temporal. Os dados recebidos do módulo GPS são

mostrados de forma textual (estado, data/hora, latitude, longitude, velocidade e direcção) e

os dados de latitude e longitude são utilizados para visualização em mapa (posição GPS),

com base na utilização de uma API do Google Maps, Figura 58.

Figura 58 - Aspecto da janela principal da aplicação SAMISH.


- 75 -

A aplicação possui as seguintes funcionalidades:

• Apresentação dos valores amostrados sob a forma textual

Os valores são apresentados em campos de texto na janela principal da aplicação.

Cada valor possui um título que identifica a grandeza e a sua respectiva unidade;

• Apresentação das grandezas analógicas sob a forma de gráfico

Os valores analógicos da aceleração, velocidade e direcção são registados em

gráficos de evolução temporal. Os gráficos permitem a função zoom e a exportação

para ficheiro;

• Posição GPS mostrada em mapa do Google Maps

Os dados de latitude e longitude são utilizados para mostrar a localização no mapa

do Google Maps, utilizando a sua API;

• Configuração dos sensores na base de dados

Manipulação da base de dados de sensores com funções de adicionar, editar e

remover, através de uma janela específica;

• Configuração da ligação RS-232

Janela de configuração dos parâmetros da comunicação série com o módulo XBee

Pro;

• Registo de dados sensoriais

Gravação dos dados sensoriais para posterior análise.


- 76 -

6.2. Modularidade de sensores A existência de sensores associados à aplicação SAMISH é totalmente dinâmica,

através da configuração dos mesmos em base de dados, como ilustrado na Figura 59.

Assim, é possível adicionar novos sensores sem necessidade de se proceder à recompilação

do código-fonte da aplicação. A janela de configuração de sensores é acedida através do

menu “Ferramentas > Sensores”.

Figura 59 - Aspecto da janela de configuração de sensores.

As ferramentas disponibilizadas pela janela de configuração de sensores, permitem

manipular de forma directa a tabela de sensores, na base de dados.

Os campos que definem um sensor na base de dados encontram-se descritos na

Tabela 10 e são utilizados para processar a trama recebida por radiofrequência proveniente

da estação remota.

Tabela 10 - Campos da tabela Sensores.

Coluna Tipo de dados Tamanho [bytes] Name nvarchar 100 Model nvarchar 100 Manufacturer nvarchar 100 FramePos int 4 CANID int 4 Unit nvarchar 20 Expression nvarchar 100 FrameOffset int 4 Output nvarchar 100 Title nvarchar 100


- 77 -

Definiram-se dois tipos de sensor com base no seu tipo de saída:

• Analog

Sensores que disponibilizam na sua saída sinais analógicos, como é o caso do

acelerómetro, giroscópio e ultra-som, cujo valor é definido à custa de uma

expressão matemática;

• CSV (Comma Separated Values)

Sensores cuja informação de saída é fornecida sob a forma de cadeia de caracteres

separados por vírgula (string), como por exemplo a trama NMEA do módulo GPS.

Ambos os tipos de sensor partilham elementos comuns, como por exemplo o nome,

fabricante, modelo, identificação do nó CAN de proveniência dos dados e posição na trama

recebida.

Os sensores do tipo Analog possuem uma unidade de grandeza associada e a

expressão de cálculo do seu valor. O cálculo do valor é realizado directamente na aplicação

de software existente na estação base.

Os sensores que devolvem várias variáveis de grandezas diferentes, como o caso do

módulo GPS, que têm capacidade de processamento própria, disponibilizam a informação

recolhida através de um canal série sob a forma de string. O tipo de sensor CSV

implementa, de forma genérica, uma interface com o processamento da string associada a

um sensor. Assim, expandindo o diagrama de classes desenvolvido, é possível incluir, na

aplicação, novos elementos sensoriais.

O modelo de classes desenvolvido utilizando a linguagem de modelagem UML

(Unified Modeling Language), Figura 60, a par da configuração de sensores em base de

dados, permite a integração simplificada de novos sensores.

Criou-se uma classe abstracta Sensor que contém os elementos comuns a todos os

sensores. As classes que a implementam são AnalogSensor e CSVSensor, em que cada uma

destas classes descreve de forma particular um sensor. A Figura 60 mostra os elementos

que compõem cada uma das classes da aplicação SAMISH e as suas relações.

O diagrama de classes da Figura 60 mostra que todos os tipos de sensor derivam de

uma classe genérica abstracta Sensor. As classes AnalogSensor e CSVSensor são casos


- 78 -

particulares de sensores, com características únicas próprias e específicas ao tipo de sensor

em causa.

A classe CSVSensor é também uma classe abstracta, neste caso implementada pela

classe GPS que representa o caso específico de um objecto Sensor cuja saída de dados é

uma string composta por vários valores.

A classe AnalogSensor implementa do mesmo modo um caso particular de um

objecto Sensor em que o valor da saída é o resultado de um cálculo matemático.

Figura 60 - Diagrama de classes da aplicação SAMISH.


- 79 -

6.3. Tratamento e visualização de dados A Figura 61 mostra a sequência de processamento realizada pela aplicação

SAMISH. A informação recebida, pelo módulo RF XBee, é transportada para o PC por um

canal USB. O canal USB é transformado numa porta série virtual, através do driver do

fabricante FTDI. A velocidade de comunicação entre o módulo XBee e o PC é de

115.2 kbps, no canal série virtual. Foi utilizada a placa de desenvolvimento USB (do

fabricante) para a comunicação com o módulo XBee, que permite a ligação USB (porta

série virtual) com a aplicação.

PCUSB

Virtual COM Port (RS232)

Aplicação SAMISH

Módulo RF XBee

USB

Aquisição e Processamento

Classe Sensor

User Control

Display

Figura 61 - Sequência de processamento da aplicação SAMISH.

Os dados da trama recebida, provenientes do módulo XBee, são processados de

forma dinâmica. O algoritmo desenvolvido tem por base a informação da posição na trama

de um determinado sensor e o seu tipo para realizar o processamento específico que lhe

está associado. A informação contida na trama e as suas respectivas posições é apresentada

na Tabela 11.


- 80 -

Para cada sensor é criado um objecto (User Control) com a capacidade de mostrar

a(s) grandeza(s). Adicionalmente, para os sensores analógicos é mostrada a evolução

temporal dos valores sob a forma de um gráfico de linhas.

Tabela 11 - Posições da trama recebida.

Posição Origem Descrição Valor (ex.) Nº de bytes 1 STX Início de transmissão & 1

2

Nó

CA

N ID

20

(Ace

leró

met

ro) Eixo X 499 5*

3 Eixo Y 508 5*

4 Eixo Z 593 5*

5

Nó

CA

N ID

10

(Ultr

a-so

m) Distância ao solo (Sonar 1) 15484 5*

6 Detecção de objectos à frente do helicóptero (Sonar 2) 15484 5*

7 Nó CAN ID 15 (Giroscópio) Velocidade angular -15.20 8*

8

Nó

CA

N ID

30

(NM

EA R

MC

out

put) Message ID $GPRMC 6

9 UTC Time 200203.00 9 10 Status A 1 11 Latitude 3831.31320 10 12 N/S Indicator N 1 13 Longitude 00850.34572 11 14 E/W Indicator W 1 15 Speed Over Ground 0.213 5 16 Course Over Ground 170.79 6 17 Date 270709 6 18 Magnetic Variation 0 19 Mode 0 20 Checksum A*7C 4 21 ETX Fim de transmissão # 1

* Dados de tamanho variável. Os valores apresentados referem-se ao pior caso possível.

Como todos os dados são enviados no formato string, os dados de tamanho variável

são obtidos automaticamente pela aplicação, sem necessidade de recompilação do código-

fonte.

A aplicação SAMISH começa por obter informação sobre os diversos sensores

configurados na tabela Sensores, adicionando cada sensor a um ArrayList. Após a

sequência de arranque inicia-se o normal processamento da informação recebida.


- 81 -

A rotina de processamento da trama começa por realizar a separação da string pelo

token “,”. O ArrayList é então percorrido e para cada sensor encontrado é alimentado o seu

valor. O valor é obtido ou calculado mediante o seu tipo.

Os sensores do tipo analógico possuem uma expressão matemática para o cálculo

da sua grandeza numérica, obtida na classe AnalogSensor através do método getValue. O

valor obtido é então colocado no User Control uDisplayAnalog, Figura 62.

Figura 62 - Exemplo de visualização de uma grandeza analógica.

O cálculo das grandezas é realizado utilizando a biblioteca dotMath. Esta biblioteca

disponibiliza métodos que permitem a compilação dinâmica de expressões matemáticas. A

Equação 6 mostra o cálculo da aceleração, com base na resolução analógica do ADC do

microcontrolador (Equação 5). Utilizou-se a notação “@” para identificar as variáveis que

são substituídas dinamicamente pela aplicação, na biblioteca dotMath.

Acelerómetro:

(5)

(6)

Em que:

• , Aceleração no eixo x;

• , Resolução analógica do ADC;

• , Número de níveis de quantificação do ADC;

• , Tensão de referência do ADC;

• valor, Valor amostrado;

• , Referência zero da primeira amostragem.


- 82 -

A variável @ref contém o valor de referência, obtido na fase de calibração do

sensor. Dado o desvio de tensão na saída do acelerómetro, em repouso, notado em relação

à especificação do fabricante, torna-se necessário realizar a calibração a cada arranque do

sistema.

Sonar:

(7)

Em que:

• tvoo, intervalo de tempo entre envio e recepção (valor amostrado);

• tciclo, Tempo de cada ciclo do temporizador do microcontrolador [27];

• valor,Valor amostrado.

A divisão por 2 na Equação (7) é necessária pois o valor amostrado corresponde ao

tempo de ida e de volta do som. A multiplicação do valor medido pelo tempo de ciclo do

temporizador do microcontrolador, permite obter o tempo (em segundos) medido, uma vez

que @valor é o número de ciclos contados e tciclo o tempo de cada ciclo.

O sensor do tipo CSV é representado pela classe GPS que é responsável por

transferir o valor de cada posição da string NMEA, directamente para o User Control

desenvolvido para o efeito – uDisplayCSV, Figura 63.

Figura 63 - Exemplo de visualização dos dados do GPS.

O valor de cada sensor analógico é utilizado para a representação gráfica da sua

evolução ao longo do tempo. O gráfico da Figura 64, é apresentado no User Control


- 83 -

uDisplayGraph que adiciona as amostras recebidas às respectivas curvas do acelerómetro,

ultra-som e direcção de navegação.

As posições latitude e longitude fornecidas pelo GPS são utilizadas para a criação

do mapa com a localização geográfica do receptor GPS. O mapa ilustrado na Figura 65, é

gerado pela aplicação Web Google Maps utilizando como argumentos da API do Google os

valores de latitude e longitude.

Figura 64 - Exemplo de evolução temporal da aceleração nos três eixos do sensor.


- 84 -

Figura 65 - Localização geográfica do receptor GPS no Google Maps


- 85 -

7. Resultados Experimentais 7.1. Actualização de Dados no Nó Controlador

De forma a realizar a análise do tempo de actualização dos dados no nó

controlador, incluíram-se pinos de prova para cada nó sensorial. O estado lógico destes

pinos muda a cada nova recepção de informação, através do barramento CAN do nó

sensorial a que o pino corresponde. Assim, o intervalo de tempo entre transições de nível

lógico (0 1 e 1 0) representa o tempo que a informação do sensor se manteve, até

uma nova recepção de informação. Os valores medidos no osciloscópio ilustram o pior

caso verificado.

Apresentam-se de seguida os valores obtidos para os diferentes nós: acelerómetro,

sonar, giroscópio e GPS.

7.1.1. Nó Acelerómetro O gráfico da Figura 66 mostra o intervalo de tempo decorrido entre cada recepção

de novos dados do nó acelerómetro, no nó controlador, através do barramento CAN.

Pode-se observar que o nó controlador recebe novos dados do acelerómetro a cada

6,4 ms.

Figura 66 - Taxa de actualização dos dados provenientes do nó Acelerómetro.

Novos dados


- 86 -

7.1.2. Nó GPS O gráfico da Figura 67 mostra o intervalo de tempo decorrido entre cada recepção

de novos dados do nó GPS, no nó controlador, através do barramento CAN.

Pode-se observar que o nó controlador recebe novos dados do GPS a cada 1,02 s.

Figura 67 - Taxa de actualização dos dados provenientes do nó GPS.

Novos dados


- 87 -

7.1.3. Nó Giroscópio O gráfico da Figura 68 mostra o intervalo de tempo decorrido entre cada recepção

de novos dados do nó giroscópio, no nó controlador, através do barramento CAN.

Pode-se observar que o nó controlador recebe novos dados do giroscópio a

cada 5,4 ms.

Figura 68 - Taxa de actualização dos dados provenientes do nó Giroscópio.

Novos dados


- 88 -

7.1.4. Nó Sonar O gráfico da Figura 69 mostra o intervalo de tempo decorrido entre cada recepção

de novos dados do nó sonar, no nó controlador, através do barramento CAN.

Pode-se observar que o nó controlador recebe novos dados dos sonares a cada 6 ms.

Figura 69 - Taxa de actualização dos dados provenientes do nó Sonar.

Novos dados


- 89 -

7.2. Sinais Processados no Nó Sonar O gráfico da Figura 70 mostra o sinal de eco do sonar, medindo uma distância de

0,5 m. A Equação (8) mostra o cálculo da distância baseado na medição da Figura 70.

Figura 70 - Eco do sonar (0,5 m).

(8)

O gráfico da Figura 71 mostra o sinal de eco do sonar, medindo uma distância de,

aproximadamente, 15 cm. A Equação (9) mostra o cálculo da distância baseado na

medição da Figura 71.

t = 0,00325 s


- 90 -

Figura 71 - Eco do sonar (15 cm).

(9)

Como se pode observar a largura do impulso eco varia, de acordo com a distância

medida, como foi descrito na secção 2.2 deste relatório.

O gráfico da Figura 72 mostra o sinal de trigger enviado para o sonar. Pode

observar-se que este tem uma duração de 10,47 µs.

Figura 72 - Trigger do sonar.

t = 0,00009 s


- 91 -

7.3. Sinais Processados no Nó Giroscópio Os gráficos da Figura 73 mostram a precisão da amostragem do sinal de saída do

giroscópio. A Figura 73 (a) mostra a saída medida directamente, no giroscópio e a

Figura 73 (b) mostra o tempo medido, pelo microcontrolador, do sinal do giroscópio.

Constata-se a alta precisão da medição do sinal de saída do giroscópio.

Para realizar a medição apresentada na Figura 73 (b), foi utilizado um pino do

microcontrolador que muda o seu estado com o flanco ascendente do pulso do giroscópio e

novamente com o seu flanco descendente.

Figura 73 - Saída do sinal (a) e réplica (b) do sinal amostrado no microcontrolador.


- 92 -

7.4. Barramento CAN Para a realização dos testes ao barramento CAN utilizou-se o nó giroscópio, de

forma a obter uma trama CAN com dimensão passível de ser mostrada correctamente.

Os gráficos da Figura 74 mostram a acção do transciever MCP2551, elevando os

níveis de tensão da informação enviada pelo microcontrolador PIC. A Figura 74 (a) mostra

também que os sinais nas linhas High e Low do barramento são invertidas entre si. A

Figura 74 (b) representa os dados enviados pelo microcontrolador para o transceiver do nó

Giroscópio.

Figura 74 - Sinal transceiver/barramento (a) e PIC/transceiver (b).

O gráfico da Figura 75 mostra a trama enviada pelo microcontrolador do nó

giroscópio, para o seu transceiver.

Figura 75 - Trama completa no barramento CAN (Nó Giroscópio).


- 93 -

7.5. Testes de Cobertura dos Módulos XBee Para testar a cobertura dos módulos XBee, utilizou-se o programa X-CTU para obter

uma relação percentual entre o número de comunicações bem sucedidas e comunicações

falhadas, de forma obter-se a taxa de sucesso das comunicações. A Figura 76 ilustra os

parâmetros configurados para a realização do teste de cobertura.

Figura 76 - Parâmetros configurados no X-CTU para o teste de cobertura.

Como no nó Controlador é construída uma trama de 105 bytes, no pior caso

possível, enviada via RS232 a uma velocidade de 115.2 kbps a cada 100 ms, configurou-se

o X-CTU para enviar uma trama de 105 bytes no mínimo a cada 100 ms e no máximo a

cada 150 ms. O tempo de guarda de 50 ms serve para compensar falhas momentâneas da

cobertura, reenvio da trama, atrasos no processamento dos dados sensoriais no

nó controlador, etc.

Como se pretende obter uma trama nova na estação base pelo no máximo a cada

250 ms, o tempo máximo configurado no X-CTU, para que uma comunicação seja


- 94 -

considerada válida, é de 300 ms. Novamente foi dado um tempo de guarda de 50 ms pelos

motivos já referidos anteriormente.

A potência de emissão configurada é de 200 mW, pois, para além de ser este o

máximo recomendado para as lacas do kit de desenvolvimento dos módulos XBee,

utilizadas para a realização deste teste, é também a potência de emissão configurada no

módulo XBee emissor da estação remota.

O local da realização do teste (zona ribeirinha do Montijo), é o apresentado na

Figura 77. A linha a azul representa o trajecto com cerca de 3,5 km, percorrido de

automóvel, onde cada um dos pontos a cor-de-laranja representa um ponto de medida, com

o automóvel parado, da taxa de sucesso das comunicações dos módulos XBee.

Na Figura 77 pode ver-se também onde foi posicionada a estação base, para a

realização deste teste.

Figura 77 - Detalhe da zona e percurso do teste de cobertura dos módulos XBee.

Na Tabela 12 apresenta-se o registo das comunicações bem sucedidas e as falhas de

comunicação em cada um dos pontos cor-de-laranja da Figura 77, bem como a taxa de


- 95 -

sucesso das comunicações dos módulos XBee, em cada um dos pontos. Os valores da

coluna “Distância à estação base” da Tabela 12, referem-se à distância em linha recta, entre

a estação base e o ponto em análise.

Tabela 12 - Resultados do teste de cobertura dos módulos XBee.

Ponto Distância à estação base [km]

Comunicações Taxa de sucesso [%] Bem sucedidas Falhadas

A 0,07 118 0 100,0 B 0,19 101 3 97,1 C 0,32 101 18 84,9 D 0,44 120 23 83,9 E 0,75 103 11 90,3 F 1,00 102 2 98,1 G 1,45 107 1 99,1 H 1,91 121 17 87,7 I 2,60 128 30 72,4 J 2,62 111 10 91,7

A taxa de sucesso nas comunicações entre os módulos XBee foi inferior a 90 % nos

pontos C, D, H e I, possivelmente devido à zona urbana existente entre a estação base e os

pontos C e D e aos armazéns existentes entre a estação base e os pontos H e I. Nos pontos

E e J a taxa de sucesso ficou somente na ordem dos 90 % devido à zona urbana, no caso do

ponto E, e à distância à estação base, no caso do ponto J. Nos restantes casos a taxa de

sucesso esteve sempre próxima dos 100 %, sendo mesmo de 100 % no ponto A, o mais

próximo da estação base.

Numa segunda fase deste teste, fez-se o percurso inverso, do ponto J para o

ponto A, sem parar em nenhum dos pontos assinalados, de forma a verificar o desempenho

dos módulos XBee quando a estação remota está em movimento. Fez-se o percurso a uma

velocidade média de 50 km/h, obtendo-se ao todo 1278 comunicações bem sucedidas e 133

comunicações falhadas, o que equivale a uma taxa de sucesso de 90,5 % nas comunicações

entre os módulos XBee.

Apesar de se poderem melhorar estes resultados, aumentando a potência de emissão

para os 300 mW, prova-se com este teste que os módulos cumprem com o necessário para

a aplicação em causa, pois superam a cobertura do módulo de comando RF do helicóptero

(cerca de 500 m em linha de vista), ao mesmo tempo que mantêm uma boa taxa de sucesso

nas comunicações, especialmente se considerarmos linha de vista a linha amarela da

Figura 77, entre a estação base e o ponto J, que equivale a uma distância de cerca de

2,62 km, ao mesmo tempo que se consegue uma taxa de sucesso de 91,7 % no ponto J.


- 96 -

8. Conclusões e Desenvolvimentos Futuros Este projecto consistiu na implementação de uma rede sensorial num helicóptero de

modelismo, estação remota, a qual transmitia via RF os dados sensoriais para uma estação

base, que consiste numa aplicação para a monitorização das grandezas amostradas na

estação remota.

Na estação remota cada um dos sensores associados aos nós da rede CAN possui

um tipo de saída de dados distinto, pelo que o estudo e desenvolvimento foram efectuados

caso a caso.

Na estação base atingiu-se o objectivo de criar uma aplicação de fácil utilização,

modular e expansível. O modelo de classes implementado na linguagem C# para o

software permitiu o rápido desenvolvimento e teste do código.

Os módulos XBee Pro 868 revelaram-se uma mais-valia no desenvolvimento do

projecto, em grande parte devido ao nível de abstracção em relação ao processamento da

transmissão de dados via RF, bastando configurar as correctas velocidades de comunicação

das respectivas UART. Conforme comprovado pelos testes realizados, o desempenho dos

módulos supera os requisitos necessários para o projecto descrito neste relatório.

Ao longo de todo o processo de desenvolvimento, foi tomada em consideração a

possibilidade de expansão do projecto, quer por adição de novos nós sensoriais na rede

CAN implementada na estação remota, quer pela actualização dos existentes. Também na

estação base este aspecto foi tido em atenção, recorrendo à adição dinâmica de novos

sensores.

Do ponto de vista comercial, este projecto encontra-se quase completo, mas sujeito

ainda a algumas melhorias, como a utilização de componentes SMD nas placas dos nós

sensoriais.

De notar também que apesar de este projecto ter sido desenvolvido em torno de um

helicóptero, é facilmente aplicado quer a outro veículo de modelismo ou até mesmo a um

veículo convencional, com aplicações na monitorização, por exemplo, de veículos em

provas desportiva, controlo de percursos de veículos comerciais, etc.

Como desenvolvimentos futuros, pode considerar-se a implementação de um

módulo de controlo do helicóptero recorrendo aos dados sensoriais obtidos por este

projecto. Poderia também adicionar-se um circuito de vídeo, de auxílio à monitorização.


- 97 -

Bibliografia [1] Global Positioning System, Wikipédia,

http://en.wikipedia.org/wiki/Global_Positioning_System, Novembro de 2009. [2] GPS History - How it all started,

http://www.maps-gps-info.com/gps-history.html, Novembro de 2009. [3] GPS, http://www.nara.org.br/servicos/ntp/gps/, Novembro de 2009. [4] NMEA 0183, Wikipédia: http://en.wikipedia.org/wiki/NMEA_0183, Novembro de

2009. [5] GPS, NMEA, WGS-84, GIS and VB.NET, Thomas Tingsted Mathiesen,

http://www.tma.dk/gps/, Novembro de 2009. [6] Som, Wikipédia, http://pt.wikipedia.org/wiki/Som, Novembro de 2009. [7] Ultrasound, Wikipédia, http://en.wikipedia.org/wiki/Ultrasound, Novembro de

2009. [8] Ultra-Som, Jesus Pécora e Danilo Guerisoli,

http://www.forp.usp.br/restauradora/us01.htm, Novembro de 2009. [9] Velocity of Sound in Various Media, Kirt Blattenberger,

http://www.rfcafe.com/references/general/velocity-sound-media.htm, Novembro de 2009.

[10] Accelerometer, Wikipédia, http://en.wikipedia.org/wiki/Accelerometer, Novembro

de 2009. [11] An Overview of MEMS Inertial Sensing Technology, Jonathan Bernstein,

http://www.sensorsmag.com/sensors/acceleration-vibration/an-overview-mems-inertial-sensing-technology-970, Novembro de 2009.

[12] Accelerometers and How they Work, JMP, Texas Instruments, 2008. [13] MEMS Accelerometers, Matej Andrejašiˇc, University of Ljubljana, Faculty for

mathematics and physics, 2008. [14] Gyroscope, Wikipédia, http://en.wikipedia.org/wiki/Gyroscope, Novembro de

2009. [15] Controller Area Network, Wikipédia,

http://en.wikipedia.org/wiki/Controller%E2%80%93area_network, Novembro de 2009.


- 98 -

[16] CAN (Controller Area Network): Um Padrão Internacional de Comunicação de Transdutores Inteligentes para Máquinas Agrícolas, Rafael Sousa, Ricardo Inamasu e André Neto, Ministério da Agricultura, Pecuária e Abastecimento, 2001.

[17] Medição de Atrasos em Redes CAN, Ricardo Gaspar e Pedro Dores, Trabalho Final

de Curso de Eng. Electrotécnica e Computadores, Escola Superior de Tecnologia de Setúbal, Departamento de Eng. Electrotécnica, 2008.

[18] PIC Microcontroller, Wikipédia, http://en.wikipedia.org/wiki/PIC_microcontroller,

Novembro de 2009. [19] PICkit2 Microcontroller Programmer User´s Guide, Microchip, 2005. [20] X-CTU Configuration & Test Utility Software, Digi, 2008. [21] XBee-PRO® 868 OEM RF Modules, Digi, 2008. [22] .NET Framework, Wikipédia, http://en.wikipedia.org/wiki/.NET_Framework,

Novembro de 2009. [23] Microsoft Visual Studio Express, Wikipédia,

http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express, Novembro de 2009.

[24] An introduction to SQL Server 2005 Compact Edition, Microsoft,

http://support.microsoft.com/kb/920700, Novembro de 2009. [25] Quadro Nacional de Atribuição de Frequências, ANACOM, 2009. [26] Electromagnetic Radiation, Antennas, and Waveguides, Dr. Hon Tat Hui,

Universidade Nacional da Singapura, 2009.

[27] PIC18F2480/2580/4480/4580 Data Sheet, Microchip, 2007. [28] MCP2551 Datasheet, Microchip, 2007. [29] u-Blox5 SAM-LS Datasheet, u-Blox, 2004. [30] SRF04 - Ultra-Sonic Ranger, http://www.robotelectronics.co.uk/htm/srf04tech.htm,

Novembro de 2009. [31] Freescale MMAQ7260Q Datasheet, Freescale, 2005. [32] Specification for EK2-0704, E_sky, 2009. [33] Whats a Servo?, Seattle Robotics Society, http://www.seattlerobotics.org/,

Novembro de 2009.


- 99 -

Anexos


- 100 -

Anexo A - Esquemas eléctricos

Circuito do nó do GPS


- 101 -

Circuito do nó dos ultra-sons


- 102 -

Circuito do nó do acelerómetro


- 103 -

Circuito do nó do giroscópio


- 104 -

Circuito do nó controlador


- 105 -

Circuito emissor XBee


- 106 -

Anexo B - Placas de circuito impresso Nó do GPS

6.48 cm

4.9 cm


- 107 -

Nó dos ultra-sons

5.67 cm

4.3 cm


- 108 -

Nó do acelerómetro

6.25 cm

9.2 cm


- 109 -

Nó do giroscópio

5.8 cm

4.01 cm


- 110 -

Nó do controlador

6.7 cm

6.35 cm


- 111 -

Emissor XBee

6.3 cm

4.1 cm


- 112 -

Anexo C - Código em C implementado em cada PIC Código do nó do GPS #include <18f2580.h> #include <can-18xxx8.c> #include <stdio.h> #include <string.h> #fuses HS,NOWDT,NOPROTECT,NOLVP #use delay(clock=20000000) #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) char buffer[500]; // buffer para receber a frase NMEA do módulo GPS int i = 0; int1 end = 0; // flag sinalizadora de recepção completa char mini_buffer[8]; // buffer de envio por CAN (máx. 8 bytes) // rotina de atendimento à interrupção da porta série #int_rda void serial_isr() char c; if (end == 0) // se ainda não recebeu trama completa c = getc(); // lê um caracter do buffer interno da UART // algoritmo que descarta a trama recebida se não for a frase $GPRMC // descarta se posição 0 <> '$' // descarta se posição 3 <> 'R' (não é RMC) if (((i == 0) && (c != '$')) || ((i == 3) && (c != 'R'))) goto salta; buffer[i] = c; // copia o caracter lido para o buffer if(buffer[i]== 10) // verifica se recebeu Line feed (LF), char 10 (ASCII) end = 1; // sinaliza fim de frase buffer[i] = '?'; // coloca marcador de fim na última posição else i++; else salta: getc(); // descarrega os caracteres presentes na porta série para não bloquear // rotina main void main () int idxTrama,j = 0; can_init(); // inicializa o barramento CAN clear_interrupt(INT_RDA); // limpa as flags de estado relativas à interrupção da UART enable_interrupts(INT_RDA); // activa o atendimento da interrupção da UART


- 113 -

enable_interrupts(GLOBAL); // activa o atendimento de interrupções // loop principal while(true) if ( input(PIN_C5) ) // verifica pino de debug printf("%s\r\n",buffer); // caso esteja no modo debug envia a frase NMEA recebida pela porta série if(end ==1) // verifica se recebeu trama completa idxTrama = 0; do for (j = 0; j < 8; j ++) // divide a trama em partes de 8 bytes mini_buffer[j] = buffer[idxTrama]; if (buffer[idxTrama] == '?') // se encontrou marcador de fim goto envia; idxTrama++; envia: can_putd(30,mini_buffer,8,3,1,0); // envia os dados (8 bytes) pelo barramento CAN delay_ms(75); // evitar erros de transmissão no barramento CAN while (buffer[idxTrama] != '?'); memset(mini_buffer,0,sizeof(mini_buffer)); // limpa o buffer de 8 bytes (envio) memset(buffer,0,sizeof(buffer)); // limpa o buffer de recepção end=0; // sinaliza para nova recepção i = 0;

Código do nó dos ultra-sons #include <18F2580.h> #include <can-18xxx8.c> #fuses HS,NOWDT,NOPROTECT,NOLVP #use delay(clock=20000000) #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) int8 buffer[4]; int16 timer,timer2; int16 calcTempo(void) setup_timer_1(T1_DISABLED); //garante que o timer está desligado set_timer1(0); //limpa o registo do timer output_low (PIN_C0); //força o pino B0 a 0 que está ligado ao trigger do Ultra-Som output_high(PIN_C0); //passa para 1 o pino B0 para activar o trigger no Ultra-Som delay_us(10); //espera os 10uS exigidos para o trigger output_low (PIN_C0); //volta a por o valor de trigger a 0 while (!input(PIN_C1)); //espera que a saida de eco esteja a 1


- 114 -

setup_timer_1(T1_INTERNAL|T1_DIV_BY_4); //configura e havilita o timer > (1/20MHz)*4*4 = 800ns por ciclo while(input(PIN_C1)); //espera que o valor do eco volte a zero setup_timer_1(T1_DISABLED); //desliga o timer return get_timer1(); //devolve o registo do timer que tem o tempo em que a saida de eco esteve a 1 int16 calcTempo2(void) setup_timer_1(T1_DISABLED); //garante que o timer está desligado set_timer1(0); //limpa o registo do timer output_low (PIN_C2); //força o pino B0 a 0 que está ligado ao trigger do Ultra-Som output_high(PIN_C2); //passa para 1 o pino B0 para activar o trigger no Ultra-Som delay_us(10); //espera os 10uS exigidos para o trigger output_low (PIN_C2); //volta a por o valor de trigger a 0 while (!input(PIN_C3)); //espera que a saida de eco esteja a 1 setup_timer_1(T1_INTERNAL|T1_DIV_BY_4); //configura e havilita o timer > (1/20MHz)*4*4 = 800ns por ciclo while(input(PIN_C3)); //espera que o valor do eco volte a zero setup_timer_1(T1_DISABLED); //desliga o timer return get_timer1(); //devolve o registo do timer que tem o tempo em que a saida de eco esteve a 1 void main() can_init(); //inicia o CAN while (TRUE) timer = calcTempo(); //inicia o processo de medida do tempo timer2 = calcTempo2(); //inicia o processo de medida do tempo buffer[0] = timer / 256; //divide o int16 em dois int8 buffer[1] = timer - (buffer[0] * 256); // para poderem ser enviados por CAN buffer[2] = timer2 / 256; //divide o int16 em dois int8 buffer[3] = timer2 - (buffer[2] * 256); // para poderem ser enviados por CAN can_putd(10,buffer,4,1,1,0); //envia os dados para o barramento CAN //can_putd(ID,DADOS,TAMANHO DOS DADOS,PRIORIDADE,1,0); if ( input(PIN_C5) ) // verifica pino DEBUG printf("%Lu,%Lu \r\n",timer,timer2); // caso esteja no modo debug envia pela porta série o valor dos timers delay_ms(5); //delay de 5ms para reiniciar todo o processo

Código do nó do acelerómetro


- 115 -

#include <18F2580.h> #device ADC=10 #fuses HS,NOWDT,NOPROTECT,NOLVP #use delay(clock=20000000) #include <can-18xxx8.c> //variaveis para registar os valores do ADC int16 x; int16 y; int16 z; // array para janelas de deslocamento de 3 posições int16 arrayX[3]; int16 arrayY[3]; int16 arrayZ[3]; //Variaveis para preparar os dados para serem enviados pelo CAN int8 xH; int8 xL; int8 yH; int8 yL; int8 zH; int8 zL; //Buffer a ser enviado pelo CAN int8 valorADC[6]; void main () int i = 0; x = 0; y = 0; z = 0; setup_adc_ports( AN0_TO_AN2 | VSS_VREF); //configura os canais ADC setup_adc(ADC_CLOCK_DIV_32); // definir a velocidade de clock do ADC can_init(); // inicializar o barramento CAN // inicialização das janelas deslizantes para os 3 eixos set_adc_channel(0); // activar o canal ADC 0 while(!adc_done()); arrayX[0] = read_adc(); arrayX[1] = read_adc(); arrayX[2] = read_adc(); set_adc_channel(1); // activar o canal ADC 1 while(!adc_done()); arrayY[0] = read_adc(); arrayY[1] = read_adc(); arrayY[2] = read_adc(); set_adc_channel(2); // activar o canal ADC 2 while(!adc_done()); arrayZ[0] = read_adc(); arrayZ[1] = read_adc(); arrayZ[2] = read_adc(); // loop principal while(true)


- 116 -

arrayX[0] = arrayX[1]; // descarta posição 0 arrayX[1] = arrayX[2]; // shift para esquerda set_adc_channel(0); // activa canal ADC 0 while(!adc_done()); // aguarda conclusão da conversão arrayX[2] = read_adc(); // coloca o valor amostrado na 2ª posição for(i = 0; i < 3; i++) // realiza média x = x + arrayX[i]; xH = (x / 3)/256; //divide a variavel de 16bit em duas de 8bit xL = x-(xH * 256); //para poderem ser enviadas por CAN valorADC[0] = xH; //preenchimento do buffer a ser envidado através do CAN valorADC[1] = xL; //com as variaveis que dizem respeito ao eixo X x = 0; // reset depois do envio arrayY[0] = arrayY[1]; // descarta posição 0 arrayY[1] = arrayY[2]; // shift para esquerda set_adc_channel(1); // activa canal ADC 1 while(!adc_done()); // aguarda conclusão da conversão arrayY[2] = read_adc(); // coloca o valor amostrado na 2ª posição for(i = 0; i < 3; i++) // realiza média y = y + arrayY[i]; yH = (y / 3)/256; //divide a variavel de 16bit em duas de 8bit yL = y-(yH * 256); //para poderem ser enviadas por CAN valorADC[2] = yH; //preenchimento do buffer a ser envidado através do CAN valorADC[3] = yL; //com as variaveis que dizem respeito ao eixo X y = 0; // reset depois do envio arrayZ[0] = arrayZ[1]; arrayZ[1] = arrayZ[2]; set_adc_channel(2); while(!adc_done()); arrayZ[2] = read_adc(); for(i = 0; i < 3; i++) z = z + arrayZ[i]; zH = (z / 3)/256; //divide a variavel de 16bit em duas de 8bit zL = z-(zH * 256); //para poderem ser enviadas por CAN valorADC[4] = zH; //preenchimento do buffer a ser envidado através do CAN valorADC[5] = zL; //com as variaveis que dizem respeito ao eixo X z = 0; // reset depois do envio can_putd(20, valorADC,6, 1, 1, 0); //envia os dados pelo CAN delay_ms(5); //atraso de 5mS para reiniciar todo o processo

Código do nó giroscópio #include <18F2580.h> #include <can-18xxx8.c> #fuses HS,NOWDT,NOPROTECT,NOLVP


- 117 -

#use delay(clock=20000000) #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) int16 tempo; int calibrado = 0; float output; float refTempo; char envioCAN[8]; // buffer de 8 bits para envio por CAN #INT_EXT void ext_isr() output_high(PIN_C4); set_timer1(0); //limpa o registo do timer setup_timer_1(T1_DISABLED); //garante que o timer está desligado setup_timer_1(T1_INTERNAL|T1_DIV_BY_4); //configura e habilita o timer > (1/20MHz)*4*4 = 800ns por ciclo while (input(PIN_B0)); setup_timer_1(T1_DISABLED); //desliga o timer if (calibrado <50) refTempo = get_timer1() * 0.0000008; calibrado++; tempo = get_timer1(); output_low(PIN_C4); void main() int i; int k; can_init(); //inicia o CAN // inicialização (trigger) para giroscópio // envia 100 impulsos de 1,5 ms de largura a cada 10 ms for (i = 0; i < 100; i++) output_low(PIN_C2); output_high(PIN_C2); delay_us(1500); output_low(PIN_C2); delay_ms(10); ext_int_edge(0,L_TO_H); // configura a interrupção externa 0 para as transições de flanco ascendente (0->1) enable_interrupts(INT_EXT);// activa o atendimento da interrupção externa enable_interrupts(GLOBAL); // activa o atendimento de interrupções // loop principal while (TRUE) output = tempo * 0.0000008; output = refTempo - output; output = output/0.00001; // dividir 10us = 1º sprintf(string,"%f",output); // converte float para string for (k=0; k<8; k++) // coloca a string no buffer de envio envioCAN[k] = string[k];


- 118 -

can_putd(15,envioCAN,8,1,1,0); // envia os dados pelo barramento CAN memset(string,0,sizeof(string)); // limpa a string memset(envioCAN,0,sizeof(envioCAN)); // limpa o buffer de envio

Código do nó controlador #include <18F2580.h> #include <can-18xxx8.c> #include <string.h> #fuses HS #use delay(clock=20000000) #use rs232(baud=57600, xmit=PIN_C6, rcv=PIN_C7) //variaveis para a recepção dos dados dos nós GPS, Ultra-som, Acelerómetro e Giroscópio pelo CAN struct rx_stat rxstat; int32 rx_id; int8 buffer[8]; int8 rx_len; //variaveis para lidar com os Ultra-Som int8 tUsomH = 0; int8 tUsomL = 0; int16 tUsom = 0; int8 tUsomH2 = 0; int8 tUsomL2 = 0; int16 tUsom2 = 0; //variaveis para lidar com o acelerometro int8 adcXH = 0; int8 adcXL = 0; int8 adcYH = 0; int8 adcYL = 0; int8 adcZH = 0; int8 adcZL = 0; int16 fGX; int16 fGY; int16 fGZ; //variaveis para lidar com o GPS char rxgps[150]; char rxgpsOK[150]; int16 idxGPS = 0; int1 gpsDone = 0; int cont = 0; char c[8]; // rotina de atendimento à interrupção da leitura no barramento CAN #int_CANRX0 void CANRX0_isr() int i,j;


- 119 -

if(can_getd(rx_id, buffer, rx_len, rxstat)) // realiza a leitura do barramento CAN if(rx_id==10) //recepção dos dados do Ultra-Som output_toggle(PIN_A1); tUsomH = buffer[0]; tUsomL = buffer[1]; tUsomH2 = buffer[2]; tUsomL2 = buffer[3]; if(rx_id==20) //recepção dos dados do acelerometro output_toggle(PIN_A2); adcXH = buffer[0]; adcXL = buffer[1]; adcYH = buffer[2]; adcYL = buffer[3]; adcZH = buffer[4]; adcZL = buffer[5]; if(rx_id==30) //recepção dos dados do GPS if (gpsDone == 0) // não lê trama caso processamento não esteja terminado if(buffer[0] == '$') // valida recepção do inicio da trama GPS ('$') idxGPS = 0; // reset ao indice da proxima posição a receber memset(rxgps,0,sizeof(rxgps)); // limpa a string de recepção for (i = 0; (i < 8) && (!gpsDone); i++) rxgps[idxGPS] = buffer[i]; // coloca a leitura na string rxgps // idxGPS++; // incrementa indice da proxima posição a receber if (rxgps[idxGPS] == 13) // detecta o fim da trama GPS através do caracter <CR> gpsDone = 1; // sinaliza fim da trama output_toggle(PIN_A0); //putc('*'); return; idxGPS++; void main (void)


- 120 -

output_low(PIN_A0); output_low(PIN_A1); output_low(PIN_A2); enable_interrupts(GLOBAL); // activa atendimento global de interrupções enable_interrupts(int_CANRX0); // activa atendimento da interrupção d recepção de dados no CAN can_init(); //inicialização do CAN strcpy(rxgpsOK,""); while(true) //reconversão das duas variaveis de 8bit numa unica de 16bit fGX = adcXL + (adcXH * 256); fGY = adcYL + (adcYH * 256); fGZ = adcZL + (adcZH * 256); tUsom = tUsomL + (tUsomH * 256); tUsom2 = tUsomL2 + (tUsomH2 * 256); //condição de controlo que so manda a trama //para o PC quando a do GPS foi recebida por completo if (gpsDone == 1) disable_interrupts(GLOBAL); gpsDone = 0; memset(rxgpsOK,0,sizeof(rxgpsOK)); strcpy(rxgpsOK,rxgps); memset(rxgps,0,sizeof(rxgps)); enable_interrupts(GLOBAL); printf("#,%Lu,%Lu,%Lu,%Lu,%Lu,%s,&\r\n",fGX,fGY,fGZ,tUsom,tUsom2,rxgpsOK); // envia a trama completa (GPS,acelX,acelY,acelZ,USom) pela UART (módulo XBee) delay_ms(100); // aguarda 100 ms para reenviar nova trama, evitando o bit stuffing


- 121 -

Anexo D - Código fonte em C# do software SAMISH Código da classe Sensor using System; using System.Collections.Generic; using System.Text; namespace SAMISH public abstract class Sensor public class Sensors public string name; public string model; public string manufacturer; public int framePos; public int canID; public string unit; public bool isOK; public string expression; public int rawValue; public int offset; public bool calibrar; public abstract string toString(); public abstract string getValue();

Código da classe AnalogSensor using System; using System.Collections.Generic; using System.Text; using dotMath; namespace SAMISH public class AnalogSensor : Sensor private int refZero = 512; private int numAmostras = 5; // número de amostras para calibração private int[] amostras; public AnalogSensor() public AnalogSensor(string _name, string _manufacturer, string _model, int _framePos, int _canId, string _unit, string _expression) name = _name;


- 122 -

manufacturer = _manufacturer; model = _model; framePos = _framePos; canID = _canId; unit = _unit; expression = _expression; amostras = new int[5]; public override string toString() return "Name = " + name + ", Value = " + getValue(); /// <summary> /// Utiliza uma expressão (string) definida na base de dados para calcular o valor na grandeza correcta /// </summary> /// <returns>valor analógico do sensor na unidade correcta</returns> public override string getValue() try // realiza a calibração nos sensores "acelerometro" com base em média de 5 amostras if (calibrar && numAmostras > 0) refZero = rawValue; if (name.Equals("AcelZ") || name.Equals("AcelZTilt")) refZero = rawValue - 96; // 96 = 1 g = sensibilidade/rA = 0.3/0.003222 amostras[numAmostras - 1] = refZero; numAmostras = numAmostras - 1; if (numAmostras == 0) for (int i = 0; i < amostras.Length - 1; i++) refZero += amostras[i]; refZero = refZero / 5; if (name.EndsWith("Tilt")) double tilt = (rawValue - refZero) / 93.0; tilt = Math.Asin(tilt); tilt = (180.0 * tilt )/ Math.PI; return String.Format("0:0.00", tilt); // formata resultado para #.## string sExpression = expression; sExpression = sExpression.Replace("@valor", Convert.ToString(rawValue)); //substitui a variavel @valor pelo valor em bruto recebido


- 123 -

sExpression = sExpression.Replace("@ref", Convert.ToString(refZero)); //substitui a variavel @valor pelo valor em bruto recebido EqCompiler oCompiler = new EqCompiler(sExpression, false); oCompiler.Compile(); // compila a expressao double dValue = oCompiler.Calculate(); // calcula a expressao return String.Format("0:0.00",dValue); // formata resultado para #.## catch (Exception) return "ERROR";

Código da classe CSVSensor using System; using System.Collections.Generic; using System.Text; using System.Collections; namespace SAMISH public abstract class CSVSensor : Sensor /// <summary> /// String separada por virgulas em bruto /// </summary> public string csvValue; public ArrayList valores = new ArrayList(); public CSVSensor() public CSVSensor(string _name, string _manufacturer, string _model, int _framePos, int _canId,int _offset) name = _name; manufacturer = _manufacturer; model = _model; framePos = _framePos; canID = _canId; offset = _offset; valores = new ArrayList(); public override string toString() string returned = ""; foreach (ValueHandler item in valores) returned += item.nome + "," + item.valor + "\r\n";


- 124 -

return returned; public override abstract string getValue();

Código da classe GPS using System; using System.Collections.Generic; using System.Collections; using System.Linq; using System.Text; namespace SAMISH class GPS : CSVSensor public string latitude, longitude; public double speed, course; public GPS() : base() public GPS(string _name, string _manufacturer, string _model, int _framePos, int _canId,int _offset) : base(_name, _manufacturer, _model, _framePos, _canId, _offset) /// <summary> /// Alimenta o arraylist com pares "nome,valor" processados directamente da trama do GPS /// </summary> /// <returns></returns> public override string getValue() try string[] splited = csvValue.Split(','); latitude = toDecimal(splited[3], splited[4]); longitude = toDecimal(splited[5], splited[6]); splited[7] = splited[7].Replace('.', ','); // substitui '.' por ',' para realizar conversão speed = Convert.ToDouble(splited[7]) * 0.5144; // converte nós em m/s --> 1 knot = 0,5144 m/s splited[8] = splited[8].Replace('.', ','); // substitui '.' por ',' para realizar conversão course = Convert.ToDouble(splited[8]); if (splited[2].Equals("A")) splited[2] = "Valid data"; else splited[2] = "Invalid data";


- 125 -

// primeira recepção de dados, enche arraylist com os dados if (valores.Count == 0) // valores.Add(new ValueHandler("ID", splited[0])); valores.Add(new ValueHandler("Status", splited[2])); valores.Add(new ValueHandler("Data", splited[9].Substring(0, 2) + "-" + splited[9].Substring(2, 2) + "-" + splited[9].Substring(4, 2))); valores.Add(new ValueHandler("UTC", splited[1].Substring(0, 2) + ":" + splited[1].Substring(2, 2) + ":" + splited[1].Substring(4, 2))); valores.Add(new ValueHandler("Lat.", toDecimal(splited[3], splited[4]) + " " + splited[4])); valores.Add(new ValueHandler("Long.", toDecimal(splited[5], splited[6]) + " " + splited[6])); valores.Add(new ValueHandler("Speed", String.Format("0:0.00", speed) + " m/s")); valores.Add(new ValueHandler("Course", splited[8] + " º")); // valores.Add(new ValueHandler("Magnetic", splited[10])); // valores.Add(new ValueHandler("Mode", splited[11])); // valores.Add(new ValueHandler("CS", splited[12])); else // não é 1ª recepção, actualiza os valores no arraylist setDado("Data", splited[9].Substring(0, 2) + "-" + splited[9].Substring(2, 2) + "-" + splited[9].Substring(4, 2)); setDado("UTC", splited[1].Substring(0, 2) + ":" + splited[1].Substring(2, 2) + ":" + splited[1].Substring(4, 2)); setDado("Status", splited[2]); setDado("Lat.", toDecimal(splited[3], splited[4]) + " " + splited[4]); setDado("Long.", toDecimal(splited[5], splited[6]) + " " + splited[6]); setDado("Speed", String.Format("0:0.00", speed) + " m/s"); setDado("Course", splited[8] + " º"); return ""; catch (Exception) return "ERRO"; /// <summary> /// getDado /// </summary> /// <param name="dado">Dado a obter</param> /// <returns>Valor associado ao dado</returns> public string getDado(string dado) foreach (ValueHandler item in valores)


- 126 -

if (item.nome == dado) return item.valor; return ""; /// <summary> /// setDado /// </summary> /// <param name="dado">Dado a alterar</param> /// <param name="valor">Novo valor</param> public void setDado(string dado, string valor) foreach (ValueHandler item in valores) if (item.nome == dado) item.valor = valor; /// <summary> /// Converte uma coordenada no formato WGS-84 para o formato decimal-degrees /// </summary> /// <param name="Pos">Coordenada no formato WGS-84 (NMEA)</param> /// <param name="CardinalReference">N, S, E, W</param> /// <returns>Coordenada no formato Decimal-degrees</returns> private string toDecimal(string Pos, string CardinalReference) Pos = Pos.Replace('.', ','); // substitui a ',' por '.' para realizar o cálculo double PosDb = Convert.ToDouble(Pos); double Deg = Math.Floor(PosDb / 100); double DecPos = Math.Round(Deg + ((PosDb - (Deg * 100)) / 60), 5); if (CardinalReference.Equals("S") || CardinalReference.Equals("W")) DecPos *= -1; string coordinate = Convert.ToString(DecPos).Replace(",", "."); return coordinate;

Código da classe ValueHandler


- 127 -

using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace SAMISH class ValueHandler public string nome, valor; public ValueHandler() public ValueHandler(string _nome, string _valor) nome = _nome; valor = _valor; public string toString() return nome + "," + valor;

Código da form fConfigCom using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; namespace SAMISH public partial class fConfigCOM : Form public fConfigCOM() InitializeComponent(); private void fConfigCOM_Load(object sender, EventArgs e) try // carrega as portas série disponiveis no sistema foreach (string s in System.IO.Ports.SerialPort.GetPortNames()) cbPorta.Items.Add(s); cbPorta.SelectedIndex = 0; catch (Exception ex) Utils.MsgErro("Falha na detecção de portas série do sistema.\r\n" + ex.Message);


- 128 -

try cbPorta.Text = DB.getSetting("Porta"); cbBaud.Text = DB.getSetting("BaudRate"); cbDataBits.Text = DB.getSetting("DataBits"); cbParidade.Text = DB.getSetting("Paridade"); cbStopBits.Text = DB.getSetting("StopBits"); catch (Exception ex) Utils.MsgErro("Falha ao obter configurações da porta série.\r\n" + ex.Message); private void btnOK_Click_1(object sender, EventArgs e) DB.setSetting("Porta", cbPorta.Text); DB.setSetting("BaudRate", cbBaud.Text); DB.setSetting("DataBits", cbDataBits.Text); DB.setSetting("Paridade", cbParidade.Text); DB.setSetting("StopBits", cbStopBits.Text);

Código da form fGraph using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using ZedGraph; namespace SAMISH public partial class fGraph : Form public String titulo = ""; public string unidade = ""; public string nome = ""; public RollingPointPairList listX = new RollingPointPairList(25); public RollingPointPairList listY = new RollingPointPairList(25); public RollingPointPairList listZ = new RollingPointPairList(25); public RollingPointPairList listSpeed = new RollingPointPairList(25); public RollingPointPairList listCourse = new RollingPointPairList(25); public fGraph()


- 129 -

InitializeComponent(); private void fGraph_Load(object sender, EventArgs e) lblTitle.Text = titulo; createChart(zedGraphControl1); // Call this method from the Form_Load method, passing your ZedGraphControl public void createChart(ZedGraphControl zgc) GraphPane myPane = zgc.GraphPane; // Set the titles and axis labels myPane.Title.Text = ""; myPane.XAxis.Title.Text = "Data/Hora"; myPane.XAxis.Type = AxisType.Date; myPane.YAxis.Title.Text = unidade; myPane.XAxis.MajorGrid.IsVisible = true; myPane.YAxis.MajorGrid.IsVisible = true; myPane.XAxis.MajorGrid.Color = Color.Gray; myPane.YAxis.MajorGrid.Color = Color.Gray; if (titulo.Equals("Acelerómetro")) myPane.AddCurve("Eixo X", listX, Color.Red, SymbolType.XCross); myPane.AddCurve("Eixo Y", listY, Color.Blue, SymbolType.XCross); myPane.AddCurve("Eixo Z", listZ, Color.Green, SymbolType.XCross); if (titulo.Equals("Velocidade e Direcção")) myPane.Y2Axis.IsVisible = true; myPane.YAxis.Scale.FontSpec.FontColor = Color.Red; myPane.YAxis.Title.FontSpec.FontColor = Color.Red; myPane.Y2Axis.Scale.FontSpec.FontColor = Color.Blue; myPane.Y2Axis.Title.FontSpec.FontColor = Color.Blue; LineItem velocidade = myPane.AddCurve("Velocidade", listSpeed, Color.Red, SymbolType.XCross); LineItem dir = myPane.AddCurve("Direcção", listCourse, Color.Blue, SymbolType.XCross); myPane.Y2Axis.Title.Text = "Graus [º]"; dir.IsY2Axis = true; // Hide the legend myPane.Legend.IsVisible = true; // Calculate the Axis Scale Ranges zgc.AxisChange(); // Refresh to paint the graph components Refresh();


- 130 -

public void addValues(double valor, string curva) GraphPane myPane = zedGraphControl1.GraphPane; XDate data = new XDate(DateTime.Now); Double dataDouble = data.XLDate; if (curva.Equals("AcelX")) listX.Add(dataDouble, valor); // myPane.AddCurve(curva, listX, Color.Red, SymbolType.XCross ); if (curva.Equals("AcelY")) listY.Add(dataDouble, valor); // myPane.AddCurve(curva, listY, Color.Blue, SymbolType.XCross); if (curva.Equals("AcelZ")) listZ.Add(dataDouble, valor); // myPane.AddCurve(curva, listZ, Color.Green, SymbolType.XCross); if (curva.Equals("Velocidade")) listSpeed.Add(dataDouble, valor); // myPane.AddCurve(curva, listZ, Color.Green, SymbolType.XCross); if (curva.Equals("Direcção")) listCourse.Add(dataDouble, valor); // myPane.AddCurve(curva, listZ, Color.Green, SymbolType.XCross); //LineItem curve = myPane.AddCurve("label", list, Color.Red, SymbolType.Circle); zedGraphControl1.AxisChange(); Refresh();

Código da form fLog using System; using System.Collections.Generic; using System.ComponentModel; using System.Data;


- 131 -

using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using ZedGraph; namespace SAMISH public partial class fLog : Form public PointPairList listX = new PointPairList(); public PointPairList listY = new PointPairList(); public PointPairList listZ = new PointPairList(); public fLog() InitializeComponent(); private void fLog_Load(object sender, EventArgs e) this.logDataTableAdapter.Fill(this.samishDBDataSet.LogData); createChart(zedGraphControl1); private void btnConsultar_Click(object sender, EventArgs e) this.logDataTableAdapter.Fill(this.samishDBDataSet.LogData); public void createChart(ZedGraphControl zgc) GraphPane myPane = zgc.GraphPane; myPane.Title.Text = ""; myPane.XAxis.Title.Text = "Data/Hora"; myPane.XAxis.Type = AxisType.Date; myPane.YAxis.Title.Text = "[g]"; myPane.XAxis.MajorGrid.IsVisible = true; myPane.YAxis.MajorGrid.IsVisible = true; myPane.XAxis.MajorGrid.Color = Color.Gray; myPane.YAxis.MajorGrid.Color = Color.Gray; myPane.AddCurve("Eixo X", listX, Color.Red, SymbolType.XCross); myPane.AddCurve("Eixo Y", listY, Color.Blue, SymbolType.XCross); myPane.AddCurve("Eixo Z", listZ, Color.Green, SymbolType.XCross); myPane.Legend.IsVisible = true; zgc.AxisChange(); Refresh(); public void addValue(double valor, string curva)


- 132 -

XDate data = new XDate(DateTime.Now); Double dataDouble = data.XLDate; if (curva.Equals("AcelX")) listX.Add(dataDouble, valor); if (curva.Equals("AcelY")) listY.Add(dataDouble, valor); if (curva.Equals("AcelZ")) listZ.Add(dataDouble, valor); zedGraphControl1.AxisChange(); Refresh(); private void btnPlotAll_Click(object sender, EventArgs e) listX.Clear(); listY.Clear(); listZ.Clear(); foreach (System.Data.DataRow dr in samishDBDataSet.Tables["LogData"].Rows) addValue(Convert.ToDouble(dr["AcelX"]), "AcelX"); addValue(Convert.ToDouble(dr["AxelY"]), "AelZ"); addValue(Convert.ToDouble(dr["AcelZ"]), "AcelZ");

Código da form fMain using System; using System.Collections.Generic; using System.Collections; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System.IO.Ports; namespace SAMISH public partial class fMain : Form public fMain() InitializeComponent();


- 133 -

#region Global Variables private bool SIMUL = false; private const string STX = "#"; private const string ETX = "&"; private const char TK = ','; private bool SHOW_SPLASH = false; private bool doLog = false; private string inBuffer = ""; // buffer de entrada temporario até receber toda a trama private int inSize = 20; // número de campos na trama (completa) public string rxFrame = ""; // frame recebida public int TTL = 0; public const int MAX_TTL = 50; private bool consola = false; // toggle mostrar consola de texto ArrayList sensors = new ArrayList(); fSupervisor fsupervisor; ArrayList analogDisplays = new ArrayList(); ArrayList graphDisplays = new ArrayList(); uDisplayCSV CSVDisplay; uDisplayMap mapDisplay; bool primeiraVez = true; public string rxTeste = "#,453,300,593,15484,15484,$GPRMC,200203.00,A,3831.31276,N,00850.34565,W,0.213,170.79,270709,,,A*7C,&"; #endregion #region Main Events /// <summary> /// Evento Load da janela principal /// - inicializa a porta série /// - carrega os sensores configurados na base de dados /// </summary> private void fMain_Load(object sender, EventArgs e) if (SHOW_SPLASH) this.Visible = false; fSplash fsplash = new fSplash(); fsplash.Show(); while (!fsplash.done) //holds for splash to close Application.DoEvents(); this.Visible = true; // abre a janela de "supervisão" fsupervisor = new fSupervisor(); fsupervisor.MdiParent = this; fsupervisor.Show(); initSerialPort(); // inicializa a porta série


- 134 -

timerRead.Enabled = true; // activa o timer da comunicação loadSensors(); if (SIMUL) addLog("AVISO: Aplicação em modo de simulação.", true); /// <summary> /// Evento de fecho da janela principal /// - pede confirmação ao utilizador /// - fecha a porta série /// </summary> private void fMain_FormClosing(object sender, FormClosingEventArgs e) if (MessageBox.Show("Deseja encerrar a aplicação SAMISH?", "Encerrar", MessageBoxButtons.YesNo, MessageBoxIcon.Question) != DialogResult.Yes) e.Cancel = true; else serialPort1.Close(); /// <summary> /// Carrega os sensores presentes na base dados /// </summary> private void loadSensors() sensors = new ArrayList(); analogDisplays = new ArrayList(); graphDisplays = new ArrayList(); SamishDBDataSetTableAdapters.SensorsTableAdapter sensorsAdapter = new SamishDBDataSetTableAdapters.SensorsTableAdapter(); SamishDBDataSet.SensorsDataTable sData = sensorsAdapter.GetData(); foreach (DataRow row in sData.Rows) // percorre todas as linhas da tabela (sensores) // cria sensores do tipo "ANALOG" if ((string)row["Output"] == "ANALOG") String name = (string)row["Name"]; if (name.EndsWith("Tilt")) goto aqui; sensors.Add(new AnalogSensor((string)row["Name"], (string)row["Manufacturer"], (string)row["Model"], (int)row["FramePos"], (int)row["CANID"], (string)row["Unit"], (string)row["Expression"])); // adiciona o sensor à arraylist uDisplayAnalog display = new uDisplayAnalog(); display.setParameters((string)row["Name"], (string)row["Title"], (string)row["Unit"]); fsupervisor.panel.Controls.Add(display); analogDisplays.Add(display); aqui:


- 135 -

// cria sensor do tipo CSV (particularmente o GPS) if ((string)row["Output"] == "CSV" && (string)row["Name"] == "GPS") sensors.Add(new GPS((string)row["Name"], (string)row["Manufacturer"], (string)row["Model"], (int)row["FramePos"], (int)row["CANID"], (int)row["FrameOffset"])); // adiciona o sensor à arraylist uDisplayCSV display = new uDisplayCSV(); display.titulo = (string)row["Name"]; fsupervisor.panel.Controls.Add(display); uDisplayGraph displayGraphAcel = new uDisplayGraph("Acelerómetro"); displayGraphAcel.titulo = "Acelerómetro"; displayGraphAcel.unidade = "[g]"; displayGraphAcel.nome = "grafAcel"; fsupervisor.panel.Controls.Add(displayGraphAcel); graphDisplays.Add(displayGraphAcel); uDisplayGraph displayGraphSpeed = new uDisplayGraph("Velocidade e Direcção"); displayGraphSpeed.titulo = "Velocidade e Direcção"; displayGraphSpeed.unidade = "[m/s]"; displayGraphSpeed.nome = "grafSpeed"; fsupervisor.panel.Controls.Add(displayGraphSpeed); graphDisplays.Add(displayGraphSpeed); uDisplayMap displayMap = new uDisplayMap(); fsupervisor.panel.Controls.Add(displayMap); #endregion #region Menu Events //encerrar private void encerrarToolStripMenuItem_Click(object sender, EventArgs e) Application.Exit(); // configurar porta série private void portaSerieToolStripMenuItem_Click(object sender, EventArgs e) fConfigCOM fconfig = new fConfigCOM(); fconfig.ShowDialog(); // acerca private void acercaToolStripMenuItem_Click(object sender, EventArgs e) AboutBox fAcerca = new AboutBox(); fAcerca.ShowDialog();


- 136 -

// mostrar/esconder consola de texto private void consolaTextoToolStripMenuItem_Click(object sender, EventArgs e) tabControl1.Visible = consolaTextoToolStripMenuItem.Checked; #endregion #region Serial Port /// <summary> /// Rotina responsável pela leitura dos dados recebidos pela porta série (módulo XBee) /// </summary> private void timerRead_Tick(object sender, EventArgs e) if (SIMUL) rxFrame = rxTeste; decodeRX(rxFrame); return; if (serialPort1.IsOpen) try inBuffer += serialPort1.ReadExisting(); if (inBuffer.ToCharArray().Length > 0) if (!inBuffer.ToCharArray()[0].Equals('#')) inBuffer = ""; else if (!inBuffer.Contains(ETX) || !inBuffer.Contains(STX)) // não recebeu trama completa TTL += 1; else // recebeu trama completa rxFrame = inBuffer; // copia buffer temporario para buffer try rxFrame = rxFrame.Remove(rxFrame.IndexOf("\n")); catch (Exception) inBuffer = ""; //reset ao buffer temporario decodeRX(rxFrame); TTL = 0;


- 137 -

comStatus.Style = ProgressBarStyle.Marquee; comStatus.Value = 10; if (TTL >= MAX_TTL) // se excedeu "time to live" bloqueia animação comStatus.Style = ProgressBarStyle.Blocks; comStatus.Value = 0; catch (TimeoutException ) comStatus.Enabled = false; // se consola visivel, adiciona os dados recebidos if (tabControl1.Visible == true && consola) consolaTxt.Text += rxFrame; consolaTxt.Select(consolaTxt.Text.Length, 0); // posiciona na ultima linha adicionada consolaTxt.ScrollToCaret(); else // porta COM não está aberta comStatus.Style = ProgressBarStyle.Blocks; comStatus.Value = 0; /// <summary> /// Decodifica a trama recebida, atribui os valores aos objectos /// respectivos (sensores) e refresca o display dos dados /// </summary> /// <param name="frame">Trama a processar</param> /// <returns>False em caso de erro</returns> private bool decodeRX(string frame) double acelx = 0.0; double acely = 0.0; double acelz = 0.0; double usom = 0.0; String latitude = ""; String longitude = ""; try string[] decodedRX = rxFrame.Split(TK); // divide a trama recebida pelo token ',' if (decodedRX.Length != inSize) addLog("Frame incompleta => " + rxFrame, true); return false;


- 138 -

if (!decodedRX[0].Contains(STX)) // detecta STX inválido addLog("Frame incorrecta, STX inválido", true); return false; if (!decodedRX[0].Contains("\n")) decodedRX[0] = STX; // correcção para overlapping das tramas if (!decodedRX[decodedRX.Length - 1].Contains(ETX)) // detecta ETX inválido addLog("Frame incorrecta, ETX inválido.", true); return false; for (int i = 0; i < decodedRX.Length; i++) // percorre a trama recebida e atribui o valor lido ao respectivo sensor foreach (Sensor sensor in sensors) if (sensor.framePos == i) // processamento de sensores analógicos if (sensor.ToString().Equals("SAMISH.AnalogSensor")) if (sensor.name.StartsWith("Acel")) sensor.calibrar = true; sensor.rawValue = Convert.ToInt32(decodedRX[i]); // processamento do GPS if (sensor.ToString().Equals("SAMISH.GPS")) GPS gps = (GPS)sensor; gps.csvValue = ""; for (int j = gps.framePos; j < gps.framePos + gps.offset; j++) gps.csvValue += decodedRX[j] + ","; gps.csvValue = gps.csvValue.Remove(gps.csvValue.Length - 1); // retira a última virgula gps.getValue(); // processa trama GPS // procura display do GPS if (primeiraVez) // na primeira vez adiciona ao arraylist foreach (Object item in fsupervisor.panel.Controls) if (item.ToString().Equals("SAMISH.uDisplayCSV"))


- 139 -

CSVDisplay = (uDisplayCSV)item; CSVDisplay.panel.Controls.Clear(); foreach (ValueHandler valueHandler in gps.valores) CSVDisplay.panel.Controls.Add(new uDisplayValueHandler(valueHandler.nome, valueHandler.valor)); primeiraVez = false; else // actualiza no arraylist e display foreach (Object item in fsupervisor.panel.Controls) if (item.ToString().Equals("SAMISH.uDisplayCSV")) CSVDisplay = (uDisplayCSV)item; foreach (ValueHandler valueHandler in gps.valores) foreach (uDisplayValueHandler display in CSVDisplay.panel.Controls) if (display.name == valueHandler.nome) display.txtValue.Text = valueHandler.valor; foreach (Object item in fsupervisor.panel.Controls) if (item.ToString().Equals("SAMISH.uDisplayMap")) mapDisplay = (uDisplayMap)item; mapDisplay.latitude = gps.latitude; mapDisplay.longitude = gps.longitude; latitude = mapDisplay.latitude; longitude = mapDisplay.longitude;


- 140 -

// consolaTxt.Text = gps.toString(); //@degug // addLog(gps.csvValue,false); //@degug // Refresh dos valores analógicos nos displays foreach (Sensor item in sensors) // percorre todos os sensores if (!item.name.Equals("GPS")) foreach (uDisplayAnalog display in analogDisplays) if (display.name == item.name) // caso encontre o display do sensor display.setValue(item.getValue()); // define o novo valor do sensor if (item.name.Equals("AcelX") && doLog) acelx = Convert.ToDouble(item.getValue()); if (item.name.Equals("AcelY") && doLog) acely = Convert.ToDouble(item.getValue()); if (item.name.Equals("AcelZ") && doLog) acelz = Convert.ToDouble(item.getValue()); if (item.name.Equals("USom") && doLog) usom = Convert.ToDouble(item.getValue()); if (display.name.StartsWith("Acel")) foreach (Object objecto in fsupervisor.panel.Controls) if (objecto.ToString().Equals("SAMISH.uDisplayGraph")) uDisplayGraph uGraph = (uDisplayGraph)objecto; if (uGraph.nome == "grafAcel") double valor = 0; valor = Convert.ToDouble(item.getValue().Replace('.', ',')); uGraph.addValues(valor, item.name); if (item.name.Equals("GPS"))


- 141 -

foreach (Object objecto in fsupervisor.panel.Controls) if (objecto.ToString().Equals("SAMISH.uDisplayGraph")) uDisplayGraph uGraph = (uDisplayGraph)objecto; if (uGraph.nome == "grafSpeed") GPS gps = (GPS)item; uGraph.addValues(gps.speed, "Velocidade"); uGraph.addValues(gps.course, "Direcção"); if (doLog) SamishDBDataSetTableAdapters.LogDataTableAdapter logTA = new SAMISH.SamishDBDataSetTableAdapters.LogDataTableAdapter(); logTA.Insert(DateTime.Now, acelx, acely, acelz, usom,latitude,longitude); return true; catch (Exception ex) addLog("Erro ao descodificar trama de recepção.\r\n" + ex.Message,true); // timerRead.Enabled = false; return false; private bool initSerialPort() try serialPort1 = new SerialPort(DB.getSetting("Porta"), Convert.ToInt32(DB.getSetting("BaudRate"))); if (DB.getSetting("Paridade").Equals("None")) serialPort1.Parity = Parity.None; if (DB.getSetting("Paridade").Equals("Even")) serialPort1.Parity = Parity.Even; if (DB.getSetting("Paridade").Equals("Odd")) serialPort1.Parity = Parity.Odd; if (DB.getSetting("StopBits").Equals("1"))


- 142 -

serialPort1.StopBits = StopBits.One; if (DB.getSetting("StopBits").Equals("1.5")) serialPort1.StopBits = StopBits.OnePointFive; if (DB.getSetting("StopBits").Equals("2")) serialPort1.StopBits = StopBits.Two; serialPort1.DataBits = Convert.ToInt32(DB.getSetting("DataBits")); serialPort1.Handshake = Handshake.None; if (!(serialPort1.IsOpen)) serialPort1.Open(); return true; catch (Exception ex) Utils.MsgErro("Erro ao iniciar porta série.\r\n" + ex.Message); return false; #endregion #region Consola private void btnClear_Click_1(object sender, EventArgs e) consolaTxt.Text = ""; #endregion #region Util /// <summary> /// Adiciona uma mensagem ao log, com ou sem timestamp /// </summary> /// <param name="msg">Mensagem a adicionar</param> /// <param name="addTimeStamp">com ou sem timestamp</param> public void addLog(string msg, bool addTimeStamp) if (lbLog.Items.Count == 20) lbLog.Items.Clear(); if (addTimeStamp) lbLog.Items.Add(DateTime.Now.ToString() + " > " + msg); else lbLog.Items.Add(msg); lbLog.SelectedIndex = lbLog.Items.Count - 1;


- 143 -

/// <summary> /// Esconde um display analógico /// </summary> /// <param name="name">Nome do display a esconder</param> public void hideDisplay(string name) try foreach (uDisplayAnalog display in fsupervisor.panel.Controls) if (display.name == name) display.Dispose(); catch (Exception ex) Utils.MsgErro("Falha ao remover o display " + name + ".\r\n" + ex.Message); #endregion private void sensoresToolStripMenuItem_Click(object sender, EventArgs e) try fSensores fsensores = new fSensores(); fsensores.ShowDialog(); catch (Exception ex) Utils.MsgErro(ex.Message); private void buttonToggleConsola_Click(object sender, EventArgs e) consola = !consola; private void logToolStripMenuItem_Click(object sender, EventArgs e) fLog flog = new fLog(); flog.Show(); private void btnParar_Click(object sender, EventArgs e) doLog = false; btnGravar.Enabled = true;


- 144 -

btnParar.Enabled = false; private void toolStripButton1_Click(object sender, EventArgs e) if (!doLog) if (MessageBox.Show("Deseja iniciar a gravação de dados?", "Confirmação", MessageBoxButtons.YesNo, MessageBoxIcon.Question) == DialogResult.Yes) doLog = true; btnGravar.Enabled = false; btnParar.Enabled = true; private void visualizaçãoToolStripMenuItem_Click(object sender, EventArgs e) fViewSensors fView = new fViewSensors(); fView.analogDisplays = analogDisplays; fView.graphDisplays = graphDisplays; fView.CSVDisplay = CSVDisplay; fView.mapDisplay = mapDisplay; fView.ShowDialog();

Código da form fSensores using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; namespace SAMISH public partial class fSensores : Form public fSensores() InitializeComponent(); private void fSensores_Load(object sender, EventArgs e)


- 145 -

this.sensorsTableAdapter.Fill(samishDBDataSet.Sensors); private void guardarToolStripButton_Click(object sender, EventArgs e) this.sensorsTableAdapter.Update(samishDBDataSet.Sensors); private void fecharToolStripButton_Click(object sender, EventArgs e) if (MessageBox.Show("As alterações não guardadas ficarão sem efeito.\r\nDeseja fechar a janela?","Confirmação",MessageBoxButtons.YesNo,MessageBoxIcon.Question) == DialogResult.Yes) this.Close();

Código da form fSupervisor using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; namespace SAMISH public partial class fSupervisor : Form public fSupervisor() InitializeComponent(); private void fSupervisor_Load(object sender, EventArgs e) this.WindowState = FormWindowState.Maximized;

Código da form fViewSensors using System; using System.Collections.Generic; using System.Collections; using System.ComponentModel; using System.Data; using System.Drawing;


- 146 -

using System.Linq; using System.Text; using System.Windows.Forms; namespace SAMISH public partial class fViewSensors : Form public ArrayList analogDisplays = new ArrayList(); public ArrayList graphDisplays = new ArrayList(); public uDisplayCSV CSVDisplay; public uDisplayMap mapDisplay; public fViewSensors() InitializeComponent(); private void fViewSensors_Load(object sender, EventArgs e) foreach (uDisplayAnalog item in analogDisplays) checkedListBox1.Items.Add(item.name,item.Visible); foreach (uDisplayGraph item in graphDisplays) checkedListBox1.Items.Add(item.nome, item.Visible); checkedListBox1.Items.Add("GPS CSV",CSVDisplay.Visible); checkedListBox1.Items.Add("GPS Map", mapDisplay.Visible); private void btnOK_Click(object sender, EventArgs e) private void checkedListBox1_ItemCheck(object sender, ItemCheckEventArgs e) String objecto = checkedListBox1.GetItemText(checkedListBox1.SelectedItem); foreach (uDisplayAnalog item in analogDisplays) if (item.name.Equals(objecto)) item.Visible = !item.Visible; foreach (uDisplayGraph item in graphDisplays) if (item.nome.Equals(objecto)) item.Visible = !item.Visible; if (objecto.Equals("GPS CSV")) CSVDisplay.Visible = !CSVDisplay.Visible;


- 147 -

if (objecto.Equals("GPS Map")) mapDisplay.Visible = !mapDisplay.Visible;

Código do UserControl uDisplayAnalog using System; using System.Collections.Generic; using System.ComponentModel; using System.Drawing; using System.Data; using System.Linq; using System.Text; using System.Windows.Forms; namespace SAMISH public partial class uDisplayAnalog : UserControl public string name = ""; public string title = ""; public string value = ""; public string unit = ""; public uDisplayAnalog() InitializeComponent(); public void setParameters(string _name, string _title, string _unit) name = _name; title = _title; unit = _unit; public void setValue(string _value) value = _value; txtValue.Text = value; private void uDisplayAnalog_Load(object sender, EventArgs e) lblTitle.Text = title; lblUnit.Text = "[ " + unit + " ]"; txtValue.Text = value;


- 148 -

Código do UserControl uDisplayCSV using System; using System.Collections.Generic; using System.ComponentModel; using System.Drawing; using System.Data; using System.Linq; using System.Text; using System.Windows.Forms; namespace SAMISH public partial class uDisplayCSV : UserControl public string titulo; public uDisplayCSV() InitializeComponent(); private void uDisplayCSV_Load(object sender, EventArgs e) lblTitle.Text = titulo;

Código do UserControl uDisplayGraph using System; using System.Collections.Generic; using System.Collections; using System.ComponentModel; using System.Drawing; using System.Data; using System.Linq; using System.Text; using System.Windows.Forms; using ZedGraph; namespace SAMISH public partial class uDisplayGraph : UserControl public string titulo = ""; public string unidade = ""; public string nome = ""; public RollingPointPairList listX = new RollingPointPairList(25); public RollingPointPairList listY = new RollingPointPairList(25);


- 149 -

public RollingPointPairList listZ = new RollingPointPairList(25); public RollingPointPairList listSpeed = new RollingPointPairList(25); public RollingPointPairList listCourse = new RollingPointPairList(25); public fGraph fgraph; public uDisplayGraph() InitializeComponent(); public uDisplayGraph(string _titulo) InitializeComponent(); titulo = _titulo; lblTitle.Text = titulo; private void uDisplayGraph_Load(object sender, EventArgs e) createChart(zedGraphControl1); // Call this method from the Form_Load method, passing your ZedGraphControl public void createChart(ZedGraphControl zgc) GraphPane myPane = zgc.GraphPane; // Set the titles and axis labels myPane.Title.Text = ""; myPane.XAxis.Title.Text = "Data/Hora"; myPane.XAxis.Type = AxisType.Date; myPane.YAxis.Title.Text = unidade; myPane.XAxis.MajorGrid.IsVisible = true; myPane.YAxis.MajorGrid.IsVisible = true; myPane.XAxis.MajorGrid.Color = Color.Gray; myPane.YAxis.MajorGrid.Color = Color.Gray; if (titulo.Equals("Acelerómetro")) myPane.AddCurve("Eixo X", listX, Color.Red, SymbolType.XCross); myPane.AddCurve("Eixo Y", listY, Color.Blue, SymbolType.XCross); myPane.AddCurve("Eixo Z", listZ, Color.Green, SymbolType.XCross); if (titulo.Equals("Velocidade e Direcção")) myPane.Y2Axis.IsVisible = true; myPane.YAxis.Scale.FontSpec.FontColor = Color.Red; myPane.YAxis.Title.FontSpec.FontColor = Color.Red; myPane.Y2Axis.Scale.FontSpec.FontColor = Color.Blue; myPane.Y2Axis.Title.FontSpec.FontColor = Color.Blue; LineItem velocidade = myPane.AddCurve("Velocidade", listSpeed, Color.Red, SymbolType.XCross);


- 150 -

LineItem dir = myPane.AddCurve("Direcção", listCourse, Color.Blue, SymbolType.XCross); myPane.Y2Axis.Title.Text = "Graus [º]"; dir.IsY2Axis = true; // Hide the legend myPane.Legend.IsVisible = true; // Calculate the Axis Scale Ranges zgc.AxisChange(); // Refresh to paint the graph components Refresh(); public void addValues(double valor, string curva) GraphPane myPane = zedGraphControl1.GraphPane; XDate data = new XDate(DateTime.Now); Double dataDouble = data.XLDate; if (curva.Equals("AcelX")) listX.Add(dataDouble, valor); if (curva.Equals("AcelY")) listY.Add(dataDouble, valor); if (curva.Equals("AcelZ")) listZ.Add(dataDouble, valor); if (curva.Equals("Velocidade")) listSpeed.Add(dataDouble, valor); if (curva.Equals("Direcção")) listCourse.Add(dataDouble, valor); try if (fgraph.Visible) fgraph.addValues(valor, curva); catch (Exception) zedGraphControl1.AxisChange(); Refresh(); private void btnMaximize_Click(object sender, EventArgs e) fgraph = new fGraph(); fgraph.titulo = titulo;


- 151 -

fgraph.Show();

Código do UserControl uDisplayMap using System; using System.Collections.Generic; using System.ComponentModel; using System.Drawing; using System.Data; using System.Linq; using System.Text; using System.Windows.Forms; namespace SAMISH public partial class uDisplayMap : UserControl public uDisplayMap() InitializeComponent(); public string latitude = ""; public string longitude = ""; private void uDisplayMap_Load(object sender, EventArgs e) Uri baseUri = new Uri(Application.StartupPath + "\\gps_google_maps.html"); webBrowser1.Url = baseUri; webBrowser1.Refresh(); public void refresh() webBrowser1.Refresh(); private void trackBar1_ValueChanged(object sender, EventArgs e) lblValue.Text = Convert.ToString(trackBar1.Value) + " s"; timerRefresh.Interval = trackBar1.Value * 1000; private void chkRefresh_CheckedChanged(object sender, EventArgs e) timerRefresh.Enabled = chkRefresh.Checked; private void timerRefresh_Tick(object sender, EventArgs e) try string script = Utils.loadTextFile("GoogleMaps.txt");


- 152 -

script = script.Replace("@lat", latitude); script = script.Replace("@lon", longitude); System.IO.StreamWriter file = new System.IO.StreamWriter(Application.StartupPath + "\\gps_google_maps.html"); file.Write(script); file.Close(); catch webBrowser1.Refresh();

Código do UserControl uDisplayValueHandler using System; using System.Collections.Generic; using System.ComponentModel; using System.Drawing; using System.Data; using System.Linq; using System.Text; using System.Windows.Forms; namespace SAMISH public partial class uDisplayValueHandler : UserControl public uDisplayValueHandler() InitializeComponent(); public uDisplayValueHandler(string _name, string _value) InitializeComponent(); name = _name; value = _value; public string name = ""; public string value = ""; private void uDisplayValueHandler_Load(object sender, EventArgs e) lblName.Text = name; txtValue.Text = value;


- 153 -

Código da classe estática DB using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Data; namespace SAMISH static class DB public static string getSetting(string Chave) SamishDBDataSetTableAdapters.SettingsTableAdapter settingsAdapter = new SamishDBDataSetTableAdapters.SettingsTableAdapter(); return (string)settingsAdapter.SettingQuery(Chave); public static void setSetting(string Chave, string Valor) SamishDBDataSetTableAdapters.SettingsTableAdapter settingsAdapter = new SamishDBDataSetTableAdapters.SettingsTableAdapter(); settingsAdapter.UpdateSettingQuery(Valor,Chave);

Código da classe estática Utils using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Windows.Forms; using System.IO; using System.Reflection; namespace SAMISH static class Utils public static void MsgErro(string Mensagem) MessageBox.Show(Mensagem, "Erro", MessageBoxButtons.OK, MessageBoxIcon.Error); public static string loadTextFile(string fileName) try StreamReader _textStreamReader = new StreamReader(Application.StartupPath + "\\" + fileName,true); string texto = "";


- 154 -

texto = _textStreamReader.ReadToEnd(); return texto; catch (Exception ex) MsgErro("Erro ao aceder ao ficheiro " + fileName + "\r\n" + ex.Message); return ""; public static double RadianToDegree(double angle) return angle * (180.0 / Math.PI); public static bool formExists(ref fGraph thisForm) try bool result = !(thisForm == null); return result; catch (Exception) return false;

Documents

FInal Project Report - PT