( PDF ) Desenvolvimento dos sistemas embarcados de um robô móvel para inspeção externa in situ de risers

Download PDF

ads:

INSTITUTO MILITAR DE ENGENHARIA

MAUR

ICIO DE OLIVEIRA BRITO

DESENVOLVIMENTO DOS SISTEMAS EMBARCADOS DE UM ROB

OVEL PARA INSPE ¸C

AO EXTERNA IN SITU DE RISERS

Disserta¸c˜ao de Mestrado apresentada ao Curso de

Mestrado em Engenharia Mecˆanica do Instituto Militar

de Engenharia como requisito parcial para obten¸c˜ao do

t´ıtulo de Mestre em Ciˆencias em Engenharia Mecˆanica.

Orientador:

Prof. Luciano Luporini Menegaldo, D.C.

Rio de Janeiro

2008

ads:

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

c2008

INSTITUTO MILITAR DE ENGENHARIA

Pra¸ca General Tib´urcio, 80 - Praia Vermelha

Rio de Janeiro-RJ CEP 22290-270

Este exemplar ´e de propriedade do Instituto Militar de Engenharia, que poder´a inclu´ı-lo

em base de dados, armazenar em computador, microﬁlmar ou adotar qualquer forma de

arquivamento.

E permitida a men¸c˜ao, reprodu¸c˜ao parcial ou integral e a transmiss˜ao entre bibliotecas

deste trabalho, sem modiﬁca¸c˜ao de seu texto, em qualquer meio que esteja ou venha a

ser ﬁxado, para pesquisa acadˆemica, coment´arios e cita¸c˜oes, desde que sem ﬁnalidade

comercial e que seja feita a referˆencia bibliogr´aﬁca completa.

Os conceitos expressos neste trabalho s˜ao de responsabilidade do(s) autor(es) e do(s)

orientador(es).

629.892 Brito,Maur´ıcio de Oliveira

Desenvolvimento dos sistemas embarcados de um robˆo m´ovel

para inspe¸c˜ao externa in situ de risers/ Maur´ıcio de Oliveira

Brito. - Rio de Janeiro: Instituto Militar de Engenharia, 2008.

90 f.: il.

Disserta¸c˜ao: (mestrado) - Instituto Militar de Engenharia-

Rio de Janeiro, 2008.

1. Risers. 2. Arquitetura Rob´otica. 3. Redes de Petri.

4. Sistemas Eletrˆonicos.

I. T´ıtulo. II. Instituto Militar de Engenharia

CDD 629.892

ads:

INSTITUTO MILITAR DE ENGENHARIA

MAUR

ICIO DE OLIVEIRA BRITO

DESENVOLVIMENTO DOS SISTEMAS EMBARCADOS DE UM ROB

OVEL PARA INSPE ¸C

AO EXTERNA IN SITU DE RISERS

Disserta¸c˜ao de Mestrado apresentada ao Curso de Mestrado em Engenharia Mecˆanica

do Instituto Militar de Engenharia como requisito parcial para obten¸c˜ao do t´ıtulo de

Mestre em Ciˆencias em Engenharia Mecˆanica.

Orientador: Prof. Luciano Luporini Menegaldo, D.C.

Aprovada em 12 de fevereiro de 2008 pela seguinte Banca Examinadora:

Luciano Luporini Menegaldo, D.C. - Presidente

Dib Karam Junior, D.C. Universidade de S˜ao Paulo

Marcos Pinotti Barbosa, D.C. Universidade Federal de Minas Gerais

Jorge Audrin Morgado de Gois, Dr. - Ing. Instituto Militar de Engenharia

Rio de Janeiro

2008

Ao meu ﬁlho Caio dos Santos Brito, e `a minha fam´ılia que me

apoiou nos momentos mais dif´ıceis.

AGRADECIMENTOS

Agradeço à CAPES pela bolsa de mestrado e à FINEP pelo programa de Auxílio à Pesquisa

que possibilitou a aquisição de recursos para aquisição de componentes eletrônicos e computa-

cionais utilizados na elaboração desta dissertação.

Agradeço aos meus pais, Atair Ferreira de Brito e Sônia Maria de O. Brito, cujo apoio, incentivo

e compreensão foram fundamentais para pavimentar os caminhos por onde ando.

Agradeço de forma especial ao prof. Luciano Menegaldo por ter conﬁado que eu poderia re-

alizar este trabalho, pela sua competência, paciência, bom senso e me fazendo descobrir novos

caminhos.

Agradeço aos professores Dib Karam, Marcos Pinotti e Audrin por terem aceitado o convite

para compor a banca; em especial ao prof. Audrin pela boa vontade que teve em me auxiliar

nas minhas dúvidas sobre Arquitetura Robótica e Redes de Petri.

Agradeço aos colegas de casa, Alexandre Pinafﬁ, Fernando Perreira do Santos, Tiago Bitarelli

e Lucas Soares por terem compartilhado seus conhecimentos em programação e pela grande

amizade aqui no Rio de Janeiro, tornando os momentos de diversão com as “Lendarias Histórias

de Pinafﬁ Gump” fonte de inspiração para semana de trabalho.

Agradeço aos colegas de mestrado do IME, em especial à Tálita Sono, Bianca Borem, Alexan-

dre Bach Travi, Achille Arantes, Geovanne Canela, Rodrigo Guerato e Gustavo USP por terem

acompanhado mais de perto o desenvolvimento deste trabalho.

SUMÁRIO

LISTA DE ILUSTRAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1 Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1.1 Riser em Catenária . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1.2 Movimentos dos Riser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.1.3 Riser Híbrido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Tipos de Falhas observadas em Risers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.4 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.5 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 PRINCÍPIOS TEÓRICOS RELATIVOS À ARQUITETURA DE ROBÔS

MÓVEIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1 Arquitetura Reativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Arquitetura Deliberativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Arquiteturas Híbridas (Reativa/Deliberativa) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 Considerações sobre a arquitetura aplicada no robô para inspeção externa de Riser. 22

3 APLICAÇÃO DE REDES DE PETRI NA IMPLEMENTAÇÃO DOS SIS-

TEMAS EMBARCADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Conceitos Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1 Execução das Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1.1 Pré-Sets e Pós-Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Característica e Funcionamento do Datalogger para Plataforma Inercial . . . . . . . . . 28

3.3 Modelagem do Datalogger por Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Rede de Petri Proposta com o Tratamento do Travamento (Deadlock). . . . . . . . . . . 35

3.3.2 Software HPSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4 Discusão sobre as Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 COMPUTAÇÃO EMBARCADA: IMPLEMENTAÇÃO E TESTES DOS SIS-

TEMAS ELETRÔNICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Implementação de Software e Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3 Comunicação Serial : Protocolo SPI para Microcontroladores ARM7 . . . . . . . . . . . 45

5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 REFERÊNCIAS BIBLIOGRÁFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A DIAGRAMA ELETRÔNICO MASTER/SLAVE . . . . . . . . . . . . . . . . . . . . . . . . 56

B CÓDIGO FONTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B.1 Conﬁguração do Datalogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B.1.1 Cálculo dos parâmetros M e P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B.1.2 Conﬁguração das UARTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

B.1.3 Código Fonte do Datalogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

B.2 Conﬁguração do Microcontrolador como Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

B.2.1 Código Fonte do LPC2138 - Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

B.3 Conﬁguração do Microcontrolador como Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

B.3.1 Código Fonte do LPC2148 - SLAVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

LISTA DE ILUSTRAÇÕES

FIG.1.1 Riser Rígido com revestimento. Fonte (PUC-Rio - Certiﬁcado Digital

nº. 0221059/CA - Sistemas de Produção em Águas Profundas). . . . . . . . . . . 12

FIG.1.2 Riser Flexível. Fonte (PUC-Rio - Certiﬁcado Digital nº. 0221059/CA -

Sistemas de Produção em Águas Profundas). . . . . . . . . . . . . . . . . . . . . . . . . . 13

FIG.1.3 Risers em Catenária. Fonte (PUC-Rio - Certiﬁcado Digital nº.

0221059/CA - Sistemas de Produção em Águas Profundas). . . . . . . . . . . . . . 14

FIG.1.4 Riser Híbrido Auto Sustentável. Fonte(2H Offshore - Risers para águas

profundas) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

FIG.1.5 Movimentos do tanque ﬂutuante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

FIG.1.6 PIG utilizado para intervenção interna em riser. Fonte (Norsk Elektro

Optikk AS - www.neo.no). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

FIG.1.7 Remotely Operated Vehicle (ROV), realizando a inspeção de um ri-

ser. Fonte(MCS - Advanced Engineering Solutions, Flexible Pipe In-

tegrity and Design - Current Issues-October 2005) . . . . . . . . . . . . . . . . . . . . . 17

FIG.1.8 Riser ﬂexível apresentando um rompimento da armadura de aço.

Fonte(MCS - Advanced Engineering Solutions, Flexible Pipe In-

tegrity and Design - Current Issues-October 2005) . . . . . . . . . . . . . . . . . . . . . 18

FIG.1.9 Riser ﬂexível com danos no revestimento de proteção. Fonte(MCS -

Advanced Engineering Solutions, Flexible Pipe Integrity and Design

- Current Issues-October 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

FIG.2.1 Arquitetura Reativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

FIG.2.2 Arquitetura Deliberativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

FIG.2.3 Arquitetura Híbrida proposta para robô SIRIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

FIG.3.1 Simbologia das Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

FIG.3.2 Pré-Sets e Pós-Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

FIG.3.3 Arquitetura Funcional do Datalogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

FIG.3.4 Fluxograma do Algoritmo Implementado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

FIG.3.5 Simulação do Datalogger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

FIG.3.6 Grafo de Alcançabilidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

FIG.3.7 Simulação do Datalogger sem travamento(deadlock). . . . . . . . . . . . . . . . . . . . . 35

FIG.3.8 Grafo de Alcançabilidade sem o Travamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

FIG.3.9 Fluxograma do algoritmo simulado em Rede de Petri. . . . . . . . . . . . . . . . . . . . . 37

FIG.4.1 Painel de controle implementado em LabView . . . . . . . . . . . . . . . . . . . . . . . . . . 42

FIG.4.2 Ângulos de Euler obtidos com o Datalogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

FIG.4.3 Ângulos de Euler adquiridos com o Software Microstrain . . . . . . . . . . . . . . . . . 43

FIG.4.4 Visualização das rotinas de testes de hardware das UARTs implemen-

tadas no microcontrolador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

FIG.4.5 Diagrama do Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

FIG.4.6 Fluxograma do algoritmo implementado no microcontrolador master. . . . . . . . 47

FIG.4.7 Primeiros resultados com protocolo SPI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

FIG.4.8 Fluxograma do algoritmo implementado no microcontrolador slave. . . . . . . . . 49

FIG.4.9 Comunicação SPI entre microcontroladores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

FIG.4.10 Fluxograma do algoritmo implementado no microcontrolador slave para

acionar o Datalogger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

FIG.4.11 Sistemas Eletrônicos implementado em Bancada. . . . . . . . . . . . . . . . . . . . . . . . . 51

FIG.4.12 Versão 1 do Hardware que será embarcado no robô SIRIS. . . . . . . . . . . . . . . . . 51

RESUMO

A exploração de Petróleo nos tempos atuais apresentou um grande crescimento, principal-

mente nas aplicações OffShore. Um dos elementos principais desta tecnologia são os Risers

de produção, que transportam o petróleo da cabeça do poço à Unidade de Produção. Tais

equipamentos devem passar por procedimentos de inspeção para garantir a sua integridade es-

trutural.Este trabalho está inserido dentro do Projeto SIRIS, que consiste em desenvolver o

projeto mecânico e construção de um robô móvel dedicado à inspeção externa de risers rígidos

e ﬂexíveis em catenária livre. No desenvolvimento do trabalho, deﬁne-se primeiramente uma

arquitetura robótica, a partir da qual foram especiﬁcados os Sistemas Eletrônicos Embarcados.

Dentro da arquitetura robótica apresentada foi implementado parte do módulo de percepção,

sendo que o Datalogger de alta capacidade para plataforma inercial é o elemento principal do

módulo de percepção. Para esta implementação foi utilizados microcontroladores ARM7 e um

módulo HDBS. O firmware implementado nos microcontroladores utilizaram conceitos de

Redes de Petri para veriﬁcação de falhas nos algoritmos.

ABSTRACT

The exploitation of oil in current times showed a large increase, mainly in OffShore ap-

plications. One of the main elements of this technology are Risers of production, carrying

oil from the well head to the Unit Production. Such equipment must go through procedures

of inspection to ensure its integrity structural.This work is inserted inside the SIRIS Project,

which is to develop the mechanical design and construction of a mobile robot dedicated to the

external inspection of rigid and ﬂexible risers in line free. In developing the work, is deﬁned pri-

marily an architecture robotics, from which were speciﬁed the Consumer Electronics Systems

Embeddeds. Within the robotics architecture has been implemented in the module of percep-

tion, and that Datalogger high capacity for inertial platform is the main module of perception.

This implementation was used ARM7 microcontrollers and a module HDBS. The firmware

implemented in microcontrollers used concepts of Networks Petri for veriﬁcation of fault in the

algorithms.

1. INTRODUÇÃO

1.1 CONSIDERAÇÕES INICIAIS

Nas ´ultimas d´ecadas, o Brasil vem investindo em tecnologia aplicada na explora¸c˜ao de

petr´oleo em lamina d’´aguas de 1500 metros `a 3000 metros, denominadas ´aguas profundas

e ultra profundas. Tais esfor¸cos mostraram-se recompensados com a obten¸c˜ao da auto-

suﬁciˆencia.

Um dos principais elementos utilizados na explora¸c˜ao de petr´oleo s˜ao os risers de

produ¸c˜ao, que s˜ao tubula¸c˜oes que interligam os po¸cos submarinos at´e as unidades de

produ¸c˜ao. Assim sendo, os risers podem ser considerados como uma das partes cr´ıticas

de um sistema de produ¸c˜ao (Oﬀshore), j´a que s˜ao estruturas sujeitas a a¸c˜oes dinˆamicas e

expostas a severas condi¸c˜oes ambientais.

Nos campos de produ¸c˜ao da Bacia de Campos existe um grande n´umero de plataformas

de produ¸c˜ao ancoradas em profundidades de at´e 2000 metros, nas quais est˜ao instalados

um grande n´umero de risers. Utiliza-se diversas alternativas de conﬁgura¸c˜ao para os

risers, sendo a conﬁgura¸c˜ao em caten´aria uma das mais utilizadas. Estes podem ser cons-

tru´ıdos em materiais comp´ositos, denominados risers ﬂex´ıveis, ou em a¸co, denominados

r´ıgidos (FRANCISS e FILHO, 2007). As Figuras (1.1) e (1.2) ilustram um riser r´ıgido e

riser ﬂex´ıvel.

FIG. 1.1: Riser Rígido com revestimento. Fonte (PUC-Rio - Certiﬁcado Digital nº.

0221059/CA - Sistemas de Produção em Águas Profundas).

FIG. 1.2: Riser Flexível. Fonte (PUC-Rio - Certiﬁcado Digital nº. 0221059/CA - Sistemas de

Produção em Águas Profundas).

Em algumas situa¸c˜oes a conﬁgura¸c˜ao dos risers em caten´aria ´e tecnicamente invi´avel,

devido aos movimentos da plataforma e outras particularidades. Uma solu¸c˜ao para este

tipo de problema s˜ao os risers h´ıbridos conhecidos por Riser H´ıbrido Auto Sustent´avel

(RHAS).

O conceito utilizado nos risers h´ıbridos, que combina tubos r´ıgidos (de a¸co) com tu-

bos ﬂex´ıveis, tem sido utilizado pela ind´ustria Oﬀshore desde a d´ecada de 80 (FILHO

e ROVERI, 2007). Esta conﬁgura¸c˜ao ´e conhecida internacionalmente como Single Line

Oﬀset Riser (SLOR). Os Risers, por sua vez, s˜ao respons´aveis por uma parte signiﬁcativa

dos custos de desenvolvimento de um campo de produ¸c˜ao de petr´oleo em ´aguas profun-

das (FRANCISS e FILHO, 2007).

1.1.1 RISER EM CATENÁRIA

A utiliza¸c˜ao de risers em caten´aria tem como caracter´ıstica a tra¸c˜ao relativamente

baixa no ponto de conex˜ao com a plataforma, uma vez que os risers verticais apresentam

tra¸c˜oes muito mais elevadas. No topo destas estruturas, se encontra uma junta ﬂex´ıvel,

presa ao recept´aculo da plataforma, cuja ﬁnalidade ´e absorver parte dos movimentos

da plataforma e evitar que se propaguem para o riser (FRANCISS e FILHO, 2007).

Desta forma a regi˜ao pr´oxima `a junta ﬂex´ıvel esta sujeita a tens˜oes dinˆamicas causadas

pelos movimentos dos risers. A Figura (1.3) mostra uma representa¸c˜ao de uma Floating

Production Storage and Oﬄoading (FPSO) na qual um riser em caten´aria est´a conectado.

A partir do ponto de conex˜ao do riser na plataforma, sua forma em caten´aria ´e respon-

s´avel por reduzir as tens˜oes. No ponto em que o riser toca o fundo do mar, ele adquire

uma curvatura acentuada. Este ponto, conhecido como Touch Down Point (TDP), ´e um

local cr´ıtico, devido ao ac´umulo de tens˜oes.

FIG. 1.3: Risers em Catenária. Fonte (PUC-Rio - Certiﬁcado Digital nº. 0221059/CA -

Sistemas de Produção em Águas Profundas).

Ap´os sua acomoda¸c˜ao no leito no mar, o riser ´e levado at´e um po¸co de produ¸c˜ao

e conectado em uma

Arvore de Natal Molhada

. O trecho de riser assentado no leito

marinho reduz os esfor¸cos que atuam sobre a

Arvore de Natal.

1.1.2 MOVIMENTOS DOS RISER

Os movimentos dos risers possuem trˆes causas distintas, dando origem a trˆes diferentes

padr˜oes (FRANCISS e FILHO, 2007) (FILHO e ROVERI, 2007):

• Movimentos de 1

ordem: movimentos causados diretamente sobre o riser por

ondas e correntes mar´ıtimas. S˜ao movimentos bastante vari´aveis, em fun¸c˜ao das

condi¸c˜oes do mar, mas que apresentam um per´ıodo de 5 a 20 segundos.

• Movimentos de 2

ordem: causados pelo movimento de corpo r´ıgido da

plataforma petrol´ıfera `a qual o riser est´a ancorado, cujo per´ıodo ´e da ordem de

centenas de segundos, devido `as grandes dimens˜oes da plataforma. Este movimento

causa um deslo camento de toda a extens˜ao do riser, levando `a varia¸c˜ao do TDP.

• Vibra¸c˜oes Induzidas por V´ortices (VIV): s˜ao vibra¸c˜oes de alta freq

uˆencia

(de 0,06 a 5 Hz) e variabilidade causadas pela corrente marinha passando transver-

salmente ao comprimento do riser, e que ocorrem tanto no plano da caten´aria quanto

Árvore de Natal é o nome dado ao conjunto de válvulas instalado em poços de exploração de petróleo

no plano perpendicular a esta. S˜ao vibra¸c˜oes com amplitude com ordem de grandeza

do diˆametro do riser. No caso da Bacia de Campos, a maior parte dos po¸cos est´a

localizada no talude da plataforma continental, agravando ainda mais o problema

da variabilidade das correntes. As vibra¸c˜oes induzidas por v´ortices po dem gerar

movimentos na estrutura do riser. Estes descrevem uma trajet´oria de “8”, devido

aos movimentos no plano da caten´aria e perpendicular a caten´aria. As vibra¸c˜oes

induzidas por v´ortices tˆem amplitude da ordem do diˆametro do riser, freq

uˆencias

entre 0,06 a 5 Hz, em dire¸c˜oes determinadas pelas dire¸c˜oes das correntes e com

amplitudes compat´ıveis com a excita¸c˜ao (FRANCISS e FILHO, 2007).

1.1.3 RISER HÍBRIDO

O riser h´ıbrido ´e composto p or um trecho vertical de riser r´ıgido, na qual sua esta-

bilidade ´e dada por um tanque de ﬂutua¸c˜ao que traciona o riser. O jumper ﬂex´ıvel ´e

conectado ao gooseneck no top assembly e `a plataforma (FILHO e ROVERI, 2007). A

Figura (1.4) ilustra a conﬁgura¸c˜ao de um riser h´ıbrido.

FIG. 1.4: Riser Híbrido Auto Sustentável. Fonte(2H Offshore - Risers para águas profundas)

O trecho vertical do riser h´ıbrido est´a fortemente sujeito `as excita¸c˜oes ambientais,

levando ao surgimento de vibra¸c˜oes induzidas por v´ortices (VIV), e depende das freq

uˆen-

cias naturais da estrutura. A natureza do fenˆomeno faz com os deslocamentos resul-

tantes sejam limitados, em geral, `a amplitude simples de um diˆametro do tub o (FILHO e

ROVERI, 2007).

O tanque de ﬂutua¸c˜ao que sustenta o riser na vertical pode dar origem aos Movimentos

Induzidos por V´ortices (VIM), tipicamente com caracter´ıstica peri´odicas. O tanque de

ﬂutua¸c˜ao desloca-se na dire¸c˜ao da corrente e na dire¸c˜ao perpendicular a ela, descrevendo

uma ﬁgura no formato do n´umero “8” (FILHO e ROVERI, 2007), como mostrado na

Figura (1.5).

FIG. 1.5: Movimentos do tanque ﬂutuante

Atualmente, as interven¸c˜oes em risers dividem-se em duas classes: interna e externa ao

riser. Desta forma, os Pipe Inspection Gauge (PIG) s˜ao respons´aveis pela inspe¸c˜ao interna,

sendo introduzidos no interior do riser por uma esta¸c˜ao de lan¸camento, deslocando-se ao

longo da linha de produ¸c˜ao impulsionado pelo pr´oprio ﬂu´ıdo. A Figura (1.6) mostra como

os PIGs s˜ao utilizados nas interven¸c˜oes.

Para a introdu¸c˜ao do instrumento, a produ¸c˜ao no ramal ´e reduzida ou at´e mesmo

paralisada, sendo o tempo de parada relacionado com tamanho do trecho de riser a ser

inspecionado e com a velocidade que o instrumento se desloca dentro do riser.

FIG. 1.6: PIG utilizado para intervenção interna em riser. Fonte (Norsk Elektro Optikk AS -

www.neo.no).

A interven¸c˜ao externa atualmente ´e feita utilizando os chamados Remotely Operated

Vehicle (ROV). As insp e¸c˜oes com ROVs aplicadas a risers ﬂex´ıveis podem revelar di-

versos defeitos no revestimento externo, bem como falhas na armadura de tra¸c˜ao que se

manifestam no revestimento de prote¸c˜ao.

Os risers r´ıgidos podem apresentar ainda enrugamento ou endenta¸c˜oes na sua camada

externa provocados pelo movimento relativo da plataforma. Danos na capa externa tam-

b´em podem ocorrer por abras˜ao, por queda de material da plataforma sobre a linha de

coleta de produ¸c˜ao e crescimento de vida marinha. A Figura (1.7) ilustra uma inspe¸c˜ao

feita por um ROV. Devido ao movimento relativo entre os risers e o ROV, tem-se nas

superf´ıcies pr´oximas `a plataforma condi¸c˜oes desfavor´aveis para visualiza¸c˜ao do risers.

FIG. 1.7: Remotely Operated Vehicle (ROV), realizando a inspeção de um riser. Fonte(MCS -

Advanced Engineering Solutions, Flexible Pipe Integrity and Design - Current Issues-October

2005)

1.2 TIPOS DE FALHAS OBSERVADAS EM RISERS

As Figuras (1.8) e (1.9) ilustram respectivamente danos ocorridos em risers ﬂex´ıveis,

sendo que a Figura (1.8) apresenta um riser ﬂex´ıvel com sua camada de blindagem rom-

pida, rompimento esse ocorrido devido a obstru¸c˜ao interna do riser e a Figura (1.9) apre-

senta danos na camada de revestimento externo.

FIG. 1.8: Riser ﬂexível apresentando um rompimento da armadura de aço. Fonte(MCS -

Advanced Engineering Solutions, Flexible Pipe Integrity and Design - Current Issues-October

2005)

FIG. 1.9: Riser ﬂexível com danos no revestimento de proteção. Fonte(MCS - Advanced

Engineering Solutions, Flexible Pipe Integrity and Design - Current Issues-October 2005)

1.3 MOTIVAÇÃO

O projeto SIRIS ´e um projeto de um Robˆo M´ovel para Inspe¸c˜ao In Situ de Risers,

ﬁnanciado pela FINEP - Financiadora de Estudos e Projetos. O projeto esta sendo

desenvolvido em parceria com IME - Instituto Militar de Engenharia e a empresa Insp ec-

tronics, que se encontra incubada no PIRF localizado no Forte S˜ao Jo˜ao na cidade do Rio

de Janeiro.

A motiva¸c˜ao em desenvolver este trabalho ´e projetar um robˆo capaz de fornecer in-

forma¸c˜oes de risers em caten´aria. Sendo que os risers est˜ao sujeito `a diversos tipos de

carregamentos e condi¸c˜oes ambientais que pode levar ao desgaste por fadiga. Desta forma,

com o desenvolvimento desse robˆo ser´a capaz de obter informa¸c˜oes ao longo de todo o

riser e fazer o monitoramento da integridade estrutural do riser.

1.4 OBJETIVO

Este trabalho tem como objetivo apresentar um estudo de arquiteturas rob´oticas, sendo

que a escolha da arquitetura est´a relacionada com a forma de opera¸c˜ao do robˆo. Com a

modelagem da arquitetura, o robˆo receber´a uma s´erie que procedimentos, na qual estar´a

em condi¸c˜oes de obter informa¸c˜oes do riser. Com a deﬁni¸c˜ao da arquitetura que melhor

caracterizar as funcionalidades do robˆo, ser´a implementado em bancada parte dos sistemas

eletrˆonicos que ser˜ao embarcados no robˆo. De tal forma, a constru¸c˜ao do prot´otipo e a

implementa¸c˜ao dos sistemas eletrˆonicos s˜ao os grandes desaﬁos do projeto.

1.5 ESTRUTURA DO TRABALHO

Este trabalho esta organizado da seguinte maneira: Neste Cap´ıtulo foram introduzi-

dos conceitos b´asicos do problema tecnol´ogico em que a pesquisa esta inserida e foram

apresentadas a motiva¸c˜ao e os objetivos deste trabalho. No Cap´ıtulo 2 s˜ao apresentados

alguns conceitos sobre robˆos m´oveis e suas arquiteturas. No Capitulo 3 ´e apresentado o

conceito de Redes de Petri, em particular discute-se formas de tratamento de travamentos

“Deadlocks” aplicado em “software” embarcado. No Cap´ıtulo 4 s˜ao apresentados alguns

resultados obtidos a partir da implementa¸c˜ao da arquitetura proposta. Finalmente, no

Cap´ıtulo 5 s˜ao apresentadas as conclus˜oes do trabalho, al´em de poss´ıveis extens˜oes e

trabalhos futuros.

2. PRINCÍPIOS TEÓRICOS RELATIVOS À ARQUITETURA DE ROBÔS MÓVEIS

2.1 ARQUITETURA REATIVA

Os sistemas de controle reativos s˜ao baseados simplesmente. No tratamento de infor-

ma¸c˜oes sensoriais, onde o tratamento dessas informa¸c˜oes n˜ao apresenta muitos recursos

computacionais. Posteriormente, o fechamento da malha de controle ´e feito enviando

comandos de controle para os atuadores. A Figura (2.1) ilustra um sistema reativo.

Um sistema reativo geralmente ´e implementado para realizar tarefas como: desviar

de obst´aculos (reage a presen¸ca de um obst´aculo), e seguir um objeto (acompanhar um

elemento guia) (JUNG et al., 2005).

FIG. 2.1: Arquitetura Reativa

2.2 ARQUITETURA DELIBERATIVA

O sistema de controle deliberativo consiste no planejamento das a¸c˜oes de controle em

malha aberta. Geralmente, esse tipo de controle estabelece a execu¸c˜ao de uma seq

uˆencia

de tarefas, onde o conhecimento sobre o ambiente e seus problemas leva o sistema de

controle a tomar decis˜oes planejadas, permitindo que a execu¸c˜ao das tarefas seja feitas

por um processo elab orado de tomada de decis˜ao.

O n´ıvel de detalhamento do ambiente em que robˆo atua, pode ser representado de

diferentes formas, sendo uma caracter´ıstica de cada tipo robˆo. A Figura (2.2) ilustra uma

arquitetura deliberativa. Geralmente as arquiteturas deliberativas apresentam melhores

caracter´ıstica quando aplicadas em ambientes est´aticos, devido ao planejamento pr´evio do

ambiente. Em ambientes dinˆamicos, a mudan¸ca das suas caracter´ısticas torna a arquite-

tura complexa devido `a necessidade de atualiza¸c˜oes constantes do modelo do ambiente.

FIG. 2.2: Arquitetura Deliberativa

2.3 ARQUITETURAS HÍBRIDAS (REATIVA/DELIBERATIVA)

As arquiteturas h´ıbridas combinam caracter´ısticas deliberativas e reativas. Estas com-

bina¸c˜oes est˜ao cada vez mais presentes nos robˆos atuais. Com a representa¸c˜ao do ambiente

na arquitetura deliberativa, podemos obter o planejamento pr´evio dos objetivos do robˆo.

No entanto, uma vez que as a¸c˜oes s˜ao planejadas, as execu¸c˜oes destas tarefas s˜ao feitas

pelo sistema reativo do robˆo.

A arquitetura h´ıbrida procura ser adequada para solu¸c˜ao de problemas atingindo ob-

jetivos de maneira ´otima e eﬁciente (utilizando delibera¸c˜ao) em ambientes dinˆamicos que

exigem rapidez na resposta (utilizando reatividade) (GRASSI, 2006).

A arquitetura h´ıbrida agrupa nos sistemas de controle rob´oticos, parte da arquitetura

deliberativa e parte da reativa. O conceito de h´ıbrido est´a na combina¸c˜ao de ambas as

arquiteturas, com maior ou menor parcela de uma ou de outra, aproveitando a sinergia

que possa haver entre ambas (FERASOLI, 1999).

2.4 CONSIDERAÇÕES SOBRE A ARQUITETURA APLICADA NO ROBÔ PARA INS-

PEÇÃO EXTERNA DE RISER.

Neste trabalho, prop˜oe-se uma arquitetura de tipo h´ıbrido (deliberativo/reativo) para

o robˆo SIRIS. A arquitetura h´ıbrida foi empregada com o prop´osito de permitir que robˆo

possa atuar de maneira semi-autˆonoma, onde alguns processos de controle de navega¸c˜ao,

sensoriamento e atua¸c˜ao possam ser efetuados por um operador humano, Ao passo que

outros processos sejam totalmente realizados autonomamente pelo pr´oprio robˆo.

A arquitetura de tipo h´ıbrido apresentada na Figura (2.3) ilustra a arquitetura em

desenvolvimento, modiﬁcada de (GRASSI, 2006), adequando-a aos sistemas de inspe¸c˜ao.

Esta arquitetura ´e comp osta pelos seguintes m´odulos: m´odulo de percep¸c˜ao e atua¸c˜ao,

m´odulo de localiza¸c˜ao, m´odulo planejador, m´odulo de monitoramento, comportamento

reativo e comportamento deliberativo, entrada de controle, e m´odulo seletor de compor-

tamentos.

FIG. 2.3: Arquitetura Híbrida proposta para robô SIRIS

O M´odulo de Percep¸c˜ao ´e um m´odulo onde ´e feito todo o processo de identiﬁca¸c˜ao dos

sensores, no qual os m´odulos de monitoramento e localiza¸c˜ao s˜ao respons´aveis por pela

conﬁabilidade das informa¸c˜oes geradas por esse m´odulo.

O M´odulo de Localiza¸c˜ao combina informa¸c˜oes sensoriais atualizando o mapa, obtendo

assim uma estimativa de como o robˆo esta desenvolvendo a miss˜ao. A fun¸c˜ao do m´odulo de

localiza¸c˜ao ´e obter a posi¸c˜ao do robˆo durante a navega¸c˜ao pelo riser, de qualquer maneira,

para efeitos de navega¸c˜ao, considera-se que o robˆo se movimenta em um ambiente est´atico,

sem risco de colis˜ao com objetos m´oveis.

Uma vez gerado o mapa em rela¸c˜ao ao um referencial ﬁxo, o planejador recebe essas

informa¸c˜oes tomando um plano para movimenta¸c˜ao autˆonoma do robˆo. Esta atividade

tem como fun¸c˜ao auxiliar o processo de navega¸c˜ao, seja de forma autˆonoma ou semi-

autˆonoma.

O M´odulo de Monitoramento permite que seja feita a an´alise de funcionamento dos

sensores, onde o planejador repassa essas informa¸c˜oes para o operador. O planejador

eventualmente poder´a fazer uso das informa¸c˜oes do m´odulo de monitoramento para obter

um melhor resultado para a navega¸c˜ao do robˆo.

O M´odulo Planejador ´e respons´avel por trabalhar as bases de informa¸c˜oes dos m´odulos

de Monitoramento e Localiza¸c˜ao. Na arquitetura proposta, o planejador ´e respons´avel

por controlar o M´odulo Seletor de Comportamento, que ´e composto pelo Comportamento

Deliberativo e Comportamento Reativo.

O Comportamento Deliberativo ´e respons´avel por auxiliar a navega¸c˜ao, executando os

planos de movimentos que foram gerados pelo Planejador. O processo de navega¸c˜ao do

robˆo SIRIS consiste em levar o robˆo at´e uma determinada posi¸c˜ao do riser, sendo conhecida

sua posi¸c˜ao inicial. Durante todo processo de navega¸c˜ao, o robˆo operar´a de forma solid´aria

ao riser, na qual o Comportamento Reativo trabalha na execu¸c˜ao do movimento ao robˆo.

O Comportamento Reativo ´e respons´avel pela execu¸c˜ao de eventos que n˜ao foram pr´e-

deﬁnidos. A execu¸c˜ao desses tip o de evento torna a arquitetura mais ﬂex´ıvel e robusta,

trabalhando com situa¸c˜oes que n˜ao foram deﬁnidas pelo sistema de planejamento. Desta

forma, podemos tomar como exemplo uma pequena mudan¸ca do ambiente, que seria

detectada pelo m´odulo de percep ¸c˜ao, ´e capaz de gerar uma a¸c˜ao imediata no sistema de

atuadores.

O M´odulo de Entradas de Controle trabalha com os dados dos comportamentos e

interage com o op erador. Desta maneira a qualquer momento o operador pode fazer

altera¸c˜oes no sistema de controle, como por exemplo a realiza¸c˜ao de uma parada em

determinada profundidade ou ainda controlando a velocidade com que o robˆo se desloca,

aumentando ou diminuindo a velocidade de rota¸c˜ao dos propulsores.

3. APLICAÇÃO DE REDES DE PETRI NA IMPLEMENTAÇÃO DOS SISTEMAS

EMBARCADOS

Nesta se¸c˜ao ´e descrita a parte da proposta que introduz o mecanismo para veriﬁca¸c˜ao

das falhas ocorridas no Datalogger. A ferramenta escolhida para modelar estas transi¸c˜oes

foi Redes de Petri. A Rede de Petri explorada nesta proposta ´e a representa¸c˜ao “Lugar/-

Transi¸c˜ao”que esta ferramenta possui, e que permitiu veriﬁcar a existˆencia de travamentos

(deadlo cks). Posteriormente, uma nova representa¸c˜ao “Lugar/Transi¸c˜ao” foi proposta, e

permitiu provar a inexistˆencia de travamentos (deadlocks), al´em de demonstrar a alcan¸ca-

bilidade dos estados desejados (atrav´es das marca¸c˜oes pretendidas) e a impossibilidade

de estados indesejados serem alcan¸cados, facilitando a organiza¸c˜ao e representa¸c˜ao desta

rede.

Carl A. Petri criou este m´etodo de estudo dos sistemas dinˆamicos a eventos discretos

em sua tese de doutorado dedicada `a comunica¸c˜ao de Autˆomatos (1962) (MORAES e

CASTRUCCI, 2007). Esta t´ecnica criada por Petri permite fazer uma representa¸c˜ao

gr´aﬁca de sistemas discretos. Desta maneira (MORAES e CASTRUCCI, 2007) apresenta

algumas qualidades que as redes de Petri proporcionam:

• s˜ao graﬁcamente expressivas;

• modelam conﬂitos e ﬁlas;

• apresentam base matem´atica bem fundamentada;

• apresentam varias extens˜oes;

• capturam as rela¸c˜oes de precedˆencia e os v´ınculos estruturais dos sistemas reais.

As primeiras aplica¸c˜oes de Redes de Petri aconteceram em 1968, no projeto norte-

americano Informaton System Theory, da A.D.R. (Applied Data Research, Inc). Este

projeto estimulou o desenvolvimento da nota¸c˜ao e da representa¸c˜ao de Redes de Petri.

Este trabalho estimulou aplica¸c˜oes na an´alise e na modelagem de sistemas com com-

ponentes concorrentes (MARRANGHELLO, 2005). No inicio da d´ecada de setenta, o

trabalho de Petri chamou a aten¸c˜ao do Grupo de Estruturas Computacionais do MIT

(Massachustts Institute of Technology). Este grupo, dirigido pelo Profº. Jack B. Dennis,

que forneceu importantes contribui¸c˜oes `a tecnica. As Redes de Petri que seguem as ca-

racter´ısticas proposta por Petri, s˜ao conhecidas como redes elementares, e classiﬁcam-se

como sendo uma rede de baixo n´ıvel. Em meados da d´ecada de oitenta surgiram as Redes

de Petri de alto n´ıvel, como uma extens˜ao das redes elementares.

• Redes de Baixo N´ıvel - est˜ao subdivididas em Redes Elementares e Redes

Lugar/Transi¸c˜ao.

– Redes Elementares - s˜ao aquelas que seguem a teoria proposta por Petri.

Apresentando caracter´ısticas de n˜ao modiﬁcarem suas “marcas

”, restringindo

o n´umero de marcasna modelagem dos sistemas. Desta forma a modelagem

de um sistema desenvolve-se apenas com manipula¸c˜ao de sua estrutura.

– Redes Lugar/Transi¸c˜ao - apresentam uma ﬂexibilidade maior em rela¸c˜ao `a pro-

posta de Petri, relaxando as restri¸c˜oes que relacionam a quantidade de marcas

durante a modelagem de sistemas, permitindo a utiliza¸c˜ao de v´arias marcas

para constru¸c˜ao de uma rede.

• Redes de Alto N´ıvel - s˜ao representadas por uma melhor caracteriza¸c˜ao das

“marcas”. Esta diferencia¸c˜ao que as marcas recebem pode ser por uma atribui¸c˜ao

de valores ou na forma de cores. Essas redes tamb´em podem ser expressas de uma

forma mais abstrata, que formalizam um grupo de extens˜oes `as redes, de maneira

que as extens˜oes passam a assumir aspectos temporais, hier´arquicos e estoc´asticos.

– extens˜oes temporais - adicionam aspectos temporais determin´ısticos ao sistema.

– extens˜oes hier´arquicas - permitem a representa¸c˜ao de sistemas complexos com

objetivo de obter uma forma simpliﬁcada.

– extens˜oes estoc´asticas - adicionam aspectos temporais n˜ao-determin´ısticos na

modelagem de sistemas.

as marcas ou tokens são representadas por pontos dentro dos lugares

3.1 CONCEITOS BÁSICOS

Uma Rede de Petri ´e um grafo orientado que possui dois tipos de n´os: Lugar e Tran-

si¸c˜ao. O meio de liga¸c˜ao entre o Lugar e Transi¸c˜ao ´e feito atrav´es dos arcos, que s˜ao

orientados de uma Transi¸c˜ao para um Lugar ou de um Lugar para uma Transi¸c˜ao. A

cada arco pode ser associado um peso, que pode ser um valor unit´ario ou n˜ao. Os Lu-

gares s˜ao preenchidos com marcas, na qual cada Lugar pode conter um n´umero inteiro de

marcas. Desta maneira, as marcas se deslocam na rede e se relacionam com os pesos de

cada arco. Podemos encontrar na literatura diversas deﬁni¸c˜oes para uma Rede de Petri.

Faremos uso da deﬁni¸c˜ao apresenta em (MORAES e CASTRUCCI, 2007) que diz: que

uma Rede de Petri ´e uma qu´ıntupla (L, T, A, W, m

) onde:

• L = (l

..........l

) ´e um conjunto ﬁnito de Lugares, n ´e o n´umero de Lugares da Rede

de Petri.

• T = (t

...........t

)´e um conjunto ﬁnito de Transi¸c˜oes, m ´e o n´umero de Transi¸c˜oes

da Rede de Petri.

• A - s˜ao os arcos de liga¸c˜ao e s˜ao representados por um conjunto, onde representa

conjunto de arcos orientados de l

para t

, ou (l

, t

) e representa conjunto de arcos

orientados de t

para l

, ou (t

, l

• W - representa uma fun¸c˜ao peso que ´e atribu´ıda a cada arco.

• m

- deﬁne o n´umero de marcas em um Lugar.

A Figura (3.1) ilustra `a Simbologia das Redes de Petri.

FIG. 3.1: Simbologia das Redes de Petri

3.1.1 EXECUÇÃO DAS REDES DE PETRI

Uma Rede de Petri em execu¸c˜ao apresenta a movimenta¸c˜ao das marcas de uma posi¸c˜ao

para outra por toda a rede. Em (MORAES e CASTRUCCI, 2007) ´e apresentado o conceito

de Pr´e-Set e P´os-Set e as regras para a execu¸c˜ao est˜ao divididas em duas fases: habilita¸c˜ao

da Transi¸c˜ao e disparo da Transi¸c˜ao.

3.1.1.1 PRÉ-SETS E PÓS-SETS

A deﬁni¸c˜ao dos conceitos de pr´e-sets e p´os-sets ´e fundamental para o entendimento da

forma de execu¸c˜ao da Rede de Petri. A Figura (3.2) ilustra os grafos de pr´e-set e p´os-set.

FIG. 3.2: Pré-Sets e Pós-Sets.

• Pr´e-set de t:

∗

t := ∀ l

∈ L/(l

, t) ∈ A, assim temos que pr´e-set de t ´e o conjunto

de Lugares em L, nas quais um arco esta orientado para a Transi¸c˜ao t.

• Pr´e-set de l:

∗

l := ∀ t

∈ T/(t

, l) ∈ A, assim temos que pr´e-set de l ´e o conjunto

de Transi¸c˜oes em T , nas quais um arco esta orientado para um Lugar l.

• P´os-set de t: t

∗

:= ∀ l

∈ P/(t, l

) ∈ A, assim temos que p´os-set de t ´e o conjunto

de Lugares em L, nas quais um arco esta orientado a partir de uma Transi¸c˜ao t.

• P´os-set de l: l

∗

:= ∀ t

∈ T/(l, t

) ∈ A, assim temos que p´os-set de l ´e o conjunto

de Transi¸c˜oes em T , nas quais um arco esta orientado a partir de um Lugar l.

A execu¸c˜ao da Rede de Petri ´e feita em duas etapas: habilita¸c˜ao da Transi¸c˜ao e disparo

da Transi¸c˜ao. Uma Transi¸c˜ao ´e dita habilitada quando uma marca¸c˜ao m ocupa um Lugar,

e o n´umero de marcas em l

deve ser maior ou igual ao peso do arco w, tornando verdadeira

a condi¸c˜ao. A cada disparo de transi¸c˜ao duas opera¸c˜oes s˜ao realizadas:

a) ´e feita a retirada das marcas dos Lugares de pr´e-set de t, onde o peso dos arcos w

indicam a quantidade de marcas a ser retirada.

b) as marcas s˜ao inseridas nos Lugares de p´os-set de t, onde o n´umero de marcas

inserido na posi¸c˜ao esta relacionado com peso de cada arco w.

A Rede de Petri durante sua execu¸c˜ao pode assumir uma varia¸c˜ao no n´umero de

marcas, devido aos pesos dos arcos e `a quantidade de marcas deﬁnidas nos Lugares.

Ocorrendo mais de uma Transi¸c˜ao habilitada ao mesmo tempo, esta situa¸c˜ao deve ser

tratada de maneira adequada, por se tratar de um “conﬂito confus˜ao”. A caracter´ıstica

do conﬂito confus˜ao ´e a habilita¸c˜ao simultˆanea de duas Transi¸c˜oes, o que altera o resultado

da execu¸c˜ao removendo a marcas do Lugar de entrada e desabilitando outra transi¸c˜ao.

Para tratar deste tipo de evento podemos tomar certas restri¸c˜oes no modelo que s˜ao:

• Organizar a estrutura do sistema de forma que os fenˆomenos temporais passem a

melhor caracterizar a ocorrˆencia dos eventos;

• Organizar o modelo do sistema real, inserindo na rede mais recursos (marcas/Lu-

gares).

3.2 CARACTERÍSTICA E FUNCIONAMENTO DO DATALOGGER PARA

PLATAFORMA INERCIAL

O Datalogger para plataforma inercial faz parte do sistema de percep¸c˜ao apresentado

na arquitetura h´ıbrida proposta no Cap´ıtulo 2. O Datalogger ´e composto por uma unidade

de medida inercial (IMU), modelo 3DM-GX1, fabricado pela MicroStrain,Inc. um m´odulo

de armazenamento de dados de baixo custo HDBS, fabricado pela Tato Equipamentos

Eletrˆonicos e um microcontrolador n ´ucleo Advanced Risc Machine (ARM7) LPC2138

fabricado pela NXP .A Figura (3.3) ilustra a arquitetura do Datalogger.

FIG. 3.3: Arquitetura Funcional do Datalogger

A IMU 3DM-GX1 MicroStrain possui interface de comunica¸c˜ao serial RS-232, que

´e conﬁgurada para operar na Universal Asynchronous serial Receiver and Transmitter

(UART) do microcontrolador LPC2138. O HDBS Tato possui comunica¸c˜ao UART e

est´a conﬁgurado para operar na UART1 do microcontrolador. Foram realizados alguns

ensaios com a IMU 3DM-GX1 MicroStrain e o HDBS para estruturar um algoritmo ca-

paz de realizar a aquisi¸c˜ao de dados. A Figura (3.4) ilustra o ﬂuxograma do algoritmo

implementado.

O ﬂuxograma esta dividido em trˆes etapas: Inicializa¸c˜ao das UARTs, Inicializa¸c˜ao do

HDBS e Loop de Aquisi¸c˜ao.

a) Inicializa¸c˜ao das UARTs - as UARTs s˜ao conﬁguradas inicialmente para os res-

pectivos “baud rates” dos perif´ericos.

b) Inicializa¸c˜ao do HDBS - o HDBS ´e inicializado enviando os seguintes comandos

ASCII pela UART1:

• HDRESET - reinicia o hardware do microcontrolador;

• HDINIT - inicializa o HDBS;

• FS - inicializa o sistema de arquivos;

• FOB - cria um arquivo com o nome desejado.

c) Loop de Aquisi¸c˜ao - o Loop de Aquisi¸c˜ao ´e respons´avel por enviar e receber

FIG. 3.4: Fluxograma do Algoritmo Implementado.

dados da IMU 3DM-GX1 MicroStrain e enviar os dados armazenados no buﬀer

para o HDBS. O n ´umero de amostras ´e deﬁnido pelo usu´ario.

Este algoritmo foi implementado para trabalhar no microcontrolaldor ARM7 LPC2138,

apresentando resultados satisfat´orios nos ensaios preliminares. Nos ensaios em que foram

utilizados um n´umero maior de amostras veriﬁcou-se a ocorrˆencia de travamentos, conhe-

cidos como deadlock. A modelagem do algoritmo implementado, em Redes de Petri, foi

utilizada para o tratamento dessas ocorrˆencia. Os resultados obtidos com o Datalogger

s˜ao apresentados no Cap´ıtulo 4.

3.3 MODELAGEM DO DATALOGGER POR REDES DE PETRI

O uso das Redes de Petri permitiu analisar o funcionamento do software embarcado

(ﬁrmware) e a existˆencia de travamentos. Conforme as aplica¸c˜oes embarcadas crescem

em complexidade, elas passam a usar um maior n´umero de componentes de sistema. Na

maioria das vezes esta complexidade est´a evidente na aplica¸c˜ao, especialmente quando ela

faz uso de v´arios componentes diretamente. Com isso, pode tornar-se impratic´avel para os

programadores a identiﬁca¸c˜ao desses travamentos que porventura possam ocorrer. Para

implementa¸c˜ao dos sistemas as funcionalidades de software e hardware devem oferecer

uma forma eﬁciente de opera¸c˜ao, tal que o sistema possa fazer uso de diferentes modos

de opera¸c˜ao. Realizando uma an´alise da Rede de Petri proposta ´e poss´ıvel veriﬁcar o

ponto em que ocorre o travamento e, a partir deste ponto, extrair um procedimento para

o algoritmo. O algoritmo que foi implementado no Datalogger ´e apresentado na Figura

(3.4). Mesmo sendo um algoritmo relativamente simples, ele apresenta algumas fontes

de travamento. A Figura (3.5) ilustra a modelagem do Datalogger em Redes de Petri

utilizando o software HPSIM.

FIG. 3.5: Simulação do Datalogger.

A simula¸c˜ao da Rede de Petri proposta para o Datalogger permite uma visualiza¸c˜ao

de todos os eventos que ocorrem dentro do algoritmo proposto na Figura (3.4). A Figura

(3.5) apresenta a simula¸c˜ao feita para veriﬁca¸c˜ao de poss´ıveis travamentos no algoritmo

implementado. Esta simula¸c˜ao por sua vez apresentou um travamento, localizado na

Transi¸c˜ao T9 que ´e respons´avel por fazer a duas habilita¸c˜oes: uma para o m´odulo HDBS

e a outra para retornar a aquisi¸c˜ao de dados da IMU. A an´alise por Redes de Petri permitiu

veriﬁcar algumas propriedades:

• Vivacidade: A an´alise da vivacidade permite determinar a existˆencia ou n˜ao de

travamentos (deadlocks). Para isso, ´e necess´ario que todas as Transi¸c˜oes da rede

em an´alise sejam quase-vivas. Uma Transi¸c˜ao ´e dita quase-viva quando existe

uma seq

uˆencia de disparo de Transi¸c˜oes a partir de uma marca¸c˜ao inicial que

conduzir´a a seu disparo. Neste caso, esta Rede de Petri pode ser considerada livre

de travamentos (deadlocks).

Para a Rede de Petri proposta sua inicializa¸c˜ao ´e feita utilizando uma marca¸c˜ao

inicial a partir do Lugar INICIALIZA¸C

AO UART0/UART1, e sua execu¸c˜ao perde

a vivacidade antes que a Transi¸c˜ao T9 seja disparada. A Transi¸c˜ao T9 ´e uma

Transi¸c˜ao temporizada, desta forma, uma Transi¸c˜ao n˜ao temporizada quando ´e

habilitada remove a marca do seu p´os-set. Esta remo¸c˜ao implica na perda de

vivacidade da rede. Atrav´es de um grafo de alcan¸cabilidade ´e poss´ıvel veriﬁcar a

execu¸c˜ao da rede e o ponto onde ocorre o travamento.

• Alcan¸cabilidade: A an´alise de alcan¸cabilidade permite identiﬁcar as marca¸c˜oes

que p odem ser atingidas a partir de uma marca¸c˜ao inicial. Esta an´alise ´e feita

atrav´es da montagem de um grafo de alcan¸cabilidade, que inclui todos os poss´ıveis

estados da rede. Para esta rede, a an´alise de alcan¸cabilidade resultou em um n´umero

inﬁnito de estados, o que est´a relacionado com o segundo loop que faz parte do pro-

cesso de aquisi¸c˜ao. Com a desativa¸c˜ao desse loop o n´umero de estados ´e ﬁnito,

resultando num grafo de alcan¸cabilidade completo. Assim, ´e poss´ıvel veriﬁcar que

alguns estados desejados foram alcan¸cados. No entanto, foi identiﬁcado um estado

indesejado fazendo que ocorra o travamento do Datalogger. Este travamento ´e in-

dicado no grafo de alcan¸cabilidade na Transi¸c˜ao T14, onde temos o Lugar L10 que

representa o HDBS, pronto para receber dados e o Lugar L6 que representa a IMU

3DM-GX1, que se encontra desativada. Esta desativa¸c˜ao do Lugar L6 implica no

travamento do Datalogger, na qual uma nova rede foi proposta visando eliminar este

estado indesejado que foi identiﬁcado. A Figura (3.6) ilustra o grafo de alcan¸cabili-

dade da Rede de Petri.

FIG. 3.6: Grafo de Alcançabilidade.

A Tabela (3.1) apresenta a descri¸c˜ao de cada evento da Rede de Petri.

TAB. 3.1: Eventos da Rede de Petri

Lugares

P0 Inicialização UART0/UART1

P1 UART1 - pronto para enviar comando

P2 HDBS

P3 Buffer

P4 CTR - controle da armadilha para desativar o Loop

P5 CTR - controle da armadilha para desativar o Loop

P6 UART0 - pronto para enviar comando

P7 IMU - 3DM-GX1

P8 UART1 - recebe os dados da Aquisição

P9 UART1 - veriﬁca se os dados foram gravados

P10 HDBS OK - pronto para receber dados

P11 Card SD - 2GB

P12 UART1 - veriﬁca se o arquivo foi fechado

P13 UART1 - abre um novo arquivo

P14 UART1 - veriﬁca se o arquivo foi aberto

P15 Continua à Aquisição de Dados

Transições

T0 Habilita à UART1

T1 Envia o comando para o HDBS

T2 Habilita o Buffer

T3 Habilita à UART1 - Transição Temporizada

T4 Desativação do Loop

T5 Habilita à UART0 e o HDBS

T6 Envia o Byte "0x0B" para a IMU 3DM - GX1

T7 Envia os Dados para UART1 - Transição Temporizada

T8 Caso 1 (com travamento) - Envia os Dados para o HDBS e Veriﬁcação

Caso 2 (sem travamento) - Envia os Dados para o HDBS, Veriﬁcação e Retorna à Aquisição

T9 Caso 1 (com travamento) - Habilita o HDBS e Retorna à Aquisição

Caso 2 (sem travamento) - Habilita o HDBS

T10 Fecha Arquivo

T11 Habilita abrir Arquivo

T12 Ok

T13 Ok

T14 Ok

3.3.1 REDE DE PETRI PROPOSTA COM O TRATAMENTO DO TRAVAMENTO (DEAD-

LOCK)

Para solucionar o problema de travamento do Datalogger foram realizadas varias alte-

ra¸c˜oes na rede proposta na Figura (3.5). A Figura (3.7) apresenta uma solu¸c˜ao adequada

para o problema do travamento.

FIG. 3.7: Simulação do Datalogger sem travamento(deadlock).

A altera¸c˜ao realizada foi no arco de liga¸c˜ao da Transi¸c˜ao T8 com o Lugar UART0,

a solu¸c˜ao adotada foi passar este arco para uma condi¸c˜ao est´avel. Desta maneira ´e pos-

s´ıvel visualizar que o novo arco de liga¸c˜ao sai da Transi¸c˜ao OK para o Lugar UART0.

As propriedades de vivacidade e alcan¸cabilidade foram veriﬁcadas, na qual a rede pas-

sou a ter sua vivacidade garantida, n˜ao ocorrendo mais o travamento. O novo grafo de

alcan¸cabilidade ´e apresentado na Figura (3.8).

FIG. 3.8: Grafo de Alcançabilidade sem o Travamento.

A partir do grafo de alcan¸cabilidade ´e poss´ıvel veriﬁcar como as marcas percorrem

a rede. Neste grafo, cada elipse cont´em todos os Lugares da rede e a habilita¸c˜ao da

Transi¸c˜ao permite representar a movimenta¸c˜ao das marcas. O grafo apresenta os processos

de Inicializa¸c˜ao do HDBS e a ocorrˆencia de cada comando enviado, a desativa¸c˜ao do

Loop de Inicializa¸c˜ao, “A” representa no sistema o in´ıcio da aquisi¸c˜ao, a Sequˆencia de

Eventos que ocorre dentro do Loop de Aquisi¸c˜ao e ﬁnalmente o fechamento do arquivo

e encerramento da aquisi¸c˜ao. A Tabela (3.1) representa os eventos da Rede de Petri.

Ap´os a simula¸c˜ao desta rede, um novo algoritmo foi implementado para veriﬁcar se o

travamento ainda estava ocorrendo. A Figura (3.9) ilustra o algoritmo alterado com base

nas simula¸c˜oes feitas com a Rede de Petri.

FIG. 3.9: Fluxograma do algoritmo simulado em Rede de Petri.

Este algoritmo foi implementado no microcontrolador ARM7 LPC2138, no qual o

travamento n˜ao ocorreu mais. A solu¸c˜ao apresentada possui o retorno `a aquisi¸c˜ao como

simulado na Rede de Petri. No entanto, foi necess´ario adicionar um pequeno atraso na

aquisi¸c˜ao para aguardar a grava¸c˜ao dos dados no HDBS. Este atraso conhecido com Time

Wait e permite que o Datalogger retorne `a aquisi¸c˜ao.

3.3.2 SOFTWARE HPSIM

O “HPSim” ´e um software para simula¸c˜ao de Redes de Petri que apresenta uma inter-

face intuitiva de f´acil utiliza¸c˜ao. Entre suas vantagens est´a a possibilidade de acompanhar

a evolu¸c˜ao do estado da rede de forma gr´aﬁca, o que auxilia no desenvolvimento do mo-

delo e na detec¸c˜ao de erros. Ele permite ainda a grava¸c˜ao do resultado da simula¸c˜ao e seu

posterior tratamento em softwares como o Microsoft Excel, uma caracter´ıstica essencial

para a an´alise do sistema modelado. Al´em do modelo b´asico de Redes de Petri (Petri

Lugar/Transi¸c˜ao), ele permite ainda a simula¸c˜ao de Redes de Petri Temporais e Redes de

Petri Estoc´asticas, bem como a utiliza¸c˜ao de arcos inibidores e habilitadores. A diferen¸ca

entre os trˆes tipos de Redes de Petri est´a nas transi¸c˜oes. Nas Redes de Petri Lugar/-

Transi¸c˜ao, as Transi¸c˜oes s˜ao instantˆaneas e s˜ao disparadas assim que s˜ao habilitadas, de

acordo com a pol´ıtica de disparo do “HPSim”. Nas Redes de Petri T-Temporais associa-se

um intervalo de tempo a cada Transi¸c˜ao. Uma vez que a Transi¸c˜ao est´a habilitada deve-se

aguardar este intervalo de tempo e em seguida ocorre o disparo. Se durante este intervalo

ocorrer um evento que desabilite a Transi¸c˜ao, ent˜ao o disparo n˜ao ocorre e, quando a

Transi¸c˜ao se tornar novamente habilitada, inicia-se uma nova contagem do tempo. Nas

Redes de Petri Estoc´asticas, o tempo associado a cada transi¸c˜ao n˜ao ´e ﬁxo, mas obedece

a uma distribui¸c˜ao estoc´astica. O simulador HPSim permite a utiliza¸c˜ao de dois tipos de

distribui¸c˜ao: exponencial e uniforme.

3.4 DISCUSÃO SOBRE AS REDES DE PETRI

Com o avan¸co da tecnologia novas ferramentas s˜ao utilizadas para veriﬁcar a conﬁa-

bilidade dos sistemas. Neste Cap´ıtulo foi apresentado uma dessas ferramentas, onde sua

aplica¸c˜ao foi veriﬁcar um travamento (deadlock) que estava ocorrendo no Datalogger para

plataforma inercial, que faz parte do sistema eletrˆonico que ser´a embarcado no Robˆo para

Inspe¸c˜ao de Riser.

A medida em que novos sistemas eletrˆonicos do Robˆo SIRIS forem

sendo acrescentados, novas extens˜oes `a Rede de Petri devem ser implementadas, para

veriﬁca¸c˜ao e corretude dos softwares embarcados. No cap´ıtulo 4 apresenta os resultados

obtidos com o Datalogger.

4. COMPUTAÇÃO EMBARCADA: IMPLEMENTAÇÃO E TESTES DOS SISTEMAS

ELETRÔNICOS

4.1 INTRODUÇÃO

O projeto dos sistemas eletrˆonicos embarcados de um robˆo m´ovel requer, inicialmente,

a escolha de uma arquitetura rob´otica, a partir da qual os subsistemas ser˜ao especiﬁcados.

Como exposto no Cap´ıtulo 2, est´a sendo proposta uma arquitetura de tipo h´ıbrido. Cada

arquitetura espec´ıﬁca ´e deﬁnida pelas caracter´ısticas de funcionamento do sistema de

controle, que po dem ser classiﬁcados como sistemas reativos, sistemas deliberativos e

h´ıbridos.

Os sistemas de controle reativos s˜ao baseados apenas no tratamento de informa¸c˜oes

sensoriais, sem processamentos soﬁsticados da informa¸c˜ao. O sistema de controle deliber-

ativo consiste no planejamento das a¸c˜oes de controle em malha aberta. Geralmente, esse

tipo de controle estabelece a execu¸c˜ao de uma seq

uˆencia de tarefas, onde o conhecimento

sobre o ambiente e seus problemas leva o sistema de controle a tomar decis˜oes planejadas,

permitindo que a execu¸c˜ao destas tarefas seja feita por um processo de processamento de

informa¸c˜ao de alto n´ıvel.

As arquiteturas h´ıbridas combinam caracter´ısticas deliberativas e reativas, e seu em-

prego vem tomando corpo nos robˆos atuais. Com a representa¸c˜ao do ambiente na arquite-

tura deliberativa, pode-se obter o planejamento pr´evio dos objetivos do robˆo. No entanto,

uma vez que as a¸c˜oes s˜ao planejadas, as execu¸c˜oes destas tarefas s˜ao feitas pelo sistema

reativo do robˆo.

A Figura (2.3) apresentada no Cap´ıtulo 2 ilustra a arquitetura em desenvolvimento,

modiﬁcada de (GRASSI, 2006).

O Sistema de Percep¸c˜ao ´e respons´avel pela aquisi¸c˜ao de dados dos sensores e trata-

mento dessas informa¸c˜oes. Entretanto, outros m´odulos podem fazer uso das informa¸c˜oes

como: comportamentos reativos, localiza¸c˜ao e sistema de monitoramento. Inicialmente

para compor o m´odulo de percep¸c˜ao ser´a utilizada uma Unidade de Medidas Inerciais

(IMU) de baixo custo Microstrain 3DM-GX1, cujas especiﬁca¸c˜oes nominais encontram-se

no Apˆendice A. Outros sensores necess´arios para o sistema:

a) Sonar - (para utilizar sistema de controle sem cord˜ao umbilical).

b) Profund´ımetro.

c) Sensores de Temperatura.

d) Sensores de ensaios n˜ao destrutivos - NonDestructive Testing (NDT)

O Sistema de Atua¸c˜ao trabalha com um m´odulo de entrada de controle, que combina

as informa¸c˜oes fornecidas pelo operador com informa¸c˜oes dos comportamentos, enviando

comandos aos atuadores. A interface entre os sensores e atuadores, que far˜ao parte dos

m´odulos de percep¸c˜ao e de atua¸c˜ao, ´e feita atrav´es do sistema de controle com o hardware,

capaz de adquirir informa¸c˜oes e interagir sobre o ambiente. O grau de diﬁculdade da

implementa¸c˜ao desses m´odulos est´a nos tipos de sensores e atuadores dispon´ıveis para a

aplica¸c˜ao.

O Sistema de Percep¸c˜ao envia informa¸c˜oes para o sistema de monitoramento e m´odulo

de localiza¸c˜ao do robˆo. O M´odulo de Localiza¸c˜ao combina os dados sensoriais atualizando

o mapa, obtendo uma estimativa de como o robˆo esta desenvolvendo a miss˜ao. A fun¸c˜ao

do m´odulo de localiza¸c˜ao ´e obter a posi¸c˜ao do robˆo durante sua movimenta¸c˜ao pelo riser.

Uma vez gerado o mapa m´etrico em rela¸c˜ao ao um referencial ﬁxo, o planejador re-

cebe essas informa¸c˜oes tomando um plano para movimenta¸c˜ao autˆonoma do robˆo. Esta

atividade tem como fun¸c˜ao auxiliar o processo de navega¸c˜ao seja de forma autˆonoma ou

semi-autˆonoma.

O Sistema de Monitoramento permite que seja feita a an´alise do funcionamento dos

sensores, onde o planejador repassa essas informa¸c˜oes para o operador. O planejador

eventualmente poder´a fazer uso das informa¸c˜oes do Sistema de Monitoramento para obter

um melhor resultado para a navega¸c˜ao do robˆo.

O M´odulo Planejador ´e respons´avel por processar as bases de informa¸c˜ao dos Sis-

temas de Monitoramento e Localiza¸c˜ao. Na arquitetura proposta, o planejador controla

o M´odulo Seletor de Comportamento, que ´e composto por Comportamento Deliberativo

e Comportamento Reativo.

O Comportamento Deliberativo ´e o principal agente da navega¸c˜ao, executando os

planos de movimento que foram gerados pelo planejador. O processo de navega¸c˜ao do robˆo

SIRIS consiste em levar o robˆo at´e uma determinada posi¸c˜ao do riser, sendo conhecida sua

posi¸c˜ao de sa´ıda. Durante todo processo de navega¸c˜ao o robˆo estar´a operando de forma

solid´aria ao riser, na qual o comportamento reativo trabalha na execu¸c˜ao das tarefas

fornecendo movimento ao robˆo.

O Comportamento Reativo nesta aplica¸c˜ao torna a arquitetura mais ﬂex´ıvel e robusta,

trabalhando com situa¸c˜oes que n˜ao foram deﬁnidas pelo sistema de planejamento. Desta

forma, uma pequena mudan¸ca do ambiente seria detectada pelo sistema de sensoriamento

gerando uma a¸c˜ao imediata no sistema de atuadores.

O M´odulo de Entradas de Controle trabalha com os dados dos comp ortamentos e

interage com o op erador. Desta maneira a qualquer momento o operador pode fazer

altera¸c˜oes no sistema de controle, impondo uma parada em determinada profundidade ou

ainda controlando a velocidade com que o robˆo se desloca, aumentando ou diminuindo a

velocidade de rota¸c˜ao dos propulsores.

4.2 IMPLEMENTAÇÃO DE SOFTWARE E HARDWARE

O primeiro sistema desenvolvido neste trabalho foi um dispositivo de armazenamento

de dados Datalogger para uma plataforma inercial (IMU) Microstrain 3DM-GX1, respon-

s´avel pela localiza¸c˜ao do robˆo e medi¸c˜ao da VIV. O sistema ser´a embarcado em um cilindro

projetado para uma press˜ao hidrost´atica de 300Bar. Com isso, ´e altamente desej´avel que

o Datalogger seja de pequenas dimens˜oes, minimizando o peso das caixas estanques de

acondicionamento da eletrˆonica. O Datalogger, juntamente com a IMU, far´a parte do

Sistema de Percep ¸c˜ao deﬁnido na arquitetura h´ıbrida. A Figura (3.3) apresentada no

Cap´ıtulo 3 ilustra a arquitetura funcional do Datalogger.

Nesta arquitetura, est´a apresentado o sistema de aquisi¸c˜ao de dados e suas carac-

ter´ısticas, onde um microcontrolador ARM7 n´ucleo ARM7TDMI-S, com alto poder de

processamento, ´e respons´avel pela comunica¸c˜ao e controle dos dois perif´ericos apresenta-

dos. A plataforma inercial Microstrain 3DM-GX1 fornece os dados referentes `a matriz de

orienta¸c˜ao estabilizada, gravados no HDBS Card SD.

Para an´alise dos dados armazenados no cart˜ao de mem´oria SD foi implementado em

LabView um aplicativo que utiliza as bibliotecas fornecidas pelo fabricante da IMU. As

bibliotecas foram modiﬁcadas para realizar a leitura de um arquivo com extens˜ao “.txt”.

A Figura (4.1) ilustra o painel de controle ou interface gr´aﬁca onde os dados armazenados

s˜ao decodiﬁcados e reproduzidos para an´alise.

FIG. 4.1: Painel de controle implementado em LabView

A interface gr´aﬁca apresentada na Figura (4.1) ´e composta por trˆes mostradores que

indicam os ˆangulos de Euler, dois gr´aﬁcos com as acelera¸c˜oes e rota¸c˜oes respectivas de

cada eixo e um bloco que reproduz em Virtual Reality Modeling Language (VRML) os

movimentos efetuados com a IMU. Para an´alise dos resultados foi realizada uma s´erie de

ensaios para coleta de dados dos movimentos de arfagem (Pitch) e rolagem (Roll) e guinada

(Yaw) impostos `a IMU. Inicialmente, utiliza-se o software fornecido pela Microstrain para

posicionar a IMU em uma posi¸c˜ao neutra. Em seguida o data logger foi conectado a IMU

e acionado, adquirindo a matriz de estabilizada que ´e deﬁnida pelo comando “0x0B”. O

n´umero de amostras adotado foi de 1000 amostras e o tempo para realizar da aquisi¸c˜ao foi

de 100 segundos, o que representa uma taxa de amostragem 10Hz. A taxa de amostragem

obtida com o Datalogger encontra-se dentro da faixa para medi¸c˜ao da VIV. No entanto,

esta taxa amostragem ainda ´e relativamente baixa. A Figura (4.2) ilustra os ˆangulos de

Euler obtidos ap´os a decodiﬁca¸c˜ao no LabView.

FIG. 4.2: Ângulos de Euler obtidos com o Datalogger

Um novo ensaio foi realizado reproduzindo aproximadamente os mesmos movimentos

realizados com o Datalogger, mas a aquisi¸c˜ao dos dados feita atrav´es do software da

Microstrain, repetindo-se qualitativamente os mesmos movimentos. Na Figura (4.3) ilustra

os ˆangulos de Euler obtidos na aquisi¸c˜ao.

FIG. 4.3: Ângulos de Euler adquiridos com o Software Microstrain

Observando as Figura (4.2) e (4.3) pode veriﬁcar que os dados gravados no cart˜ao de

mem´oria reproduzem qualitativamente os movimentos de arfagem e rolagem, tendo como

base de compara¸c˜ao a aquisi¸c˜ao realizada como o software do fabricante.

Os resultados apresentados fazem parte de v´arios reﬁnamentos j´a realizados no sistema.

Dentre os quais, a conﬁgura¸c˜ao do microcontrolador ARM7 e o m´odulo de armazenamento

de dados HDBS Card SD, fabricado pela Tato Equipamentos Eletrˆonicos.

Foram desenvolvidas algumas rotinas para teste de hardware, que s˜ao aplicados no

microcontrolador para teste das UARTs. Neste teste o microcontrolador recebe um byte

que ´e enviado pelas UARTs. Com um oscilosc´opio ´e poss´ıvel visualizar a forma de onda

do byte enviado e ainda determinar a taxa de transmiss˜ao das UARTs.

Em sistemas ass´ıncronos, a informa¸c˜ao trafega por um canal ´unico. O transmissor e o

receptor devem ser conﬁgurados antecipadamente para que a comunica¸c˜ao se estabele¸ca.

Para o protocolo serial RS-232, os dados s˜ao enviados em pequenos pacotes de 10 ou 11

bits, dos quais 8 bits constituem a mensagem. Quando o canal est´a em repouso, o sinal

correspondente no canal tem um n´ıvel l´ogico “1”. Um pacote de dados sempre come¸ca com

um n´ıvel l´ogico“0” (“start bit”) para sinalizar ao receptor que uma transmiss˜ao foi iniciada.

Seguido do start bit, 8 bits de dados de mensagem s˜ao enviados na taxa de transmiss˜ao

especiﬁcada. O pacote ´e conclu´ıdo com os bits de paridade e de parada (“stop bit”). A

Figura (4.4) ilustra os testes de hardware, onde as duas UARTs do microcontrolador foram

conﬁguradas para uma taxa de transferˆencia de 38400 bauds (bits por segundo).

FIG. 4.4: Visualização das rotinas de testes de hardware das UARTs implementadas no

microcontrolador.

O per´ıodo T medido pelo oscilosc´opio para as duas UARTs foi de 26, 00µs, que corres-

ponde a uma taxa de transferˆencia de 38.460 bauds. Observando a Tabela (4.1) ´e poss´ıvel

visualizar o erro percentual do baud rate.

TAB. 4.1: Erro Percentual de baud rate

Baud Rate BAUD RATE CALCULADO BAUD RATE MEDIDO

38400 38435,7 38460

ERRO % 0,35 0,16

O resultado do baud rate medido apresentou erro percentual inferior ao baud rate

calculado, o que reduz de forma consider´avel o n´ıvel de erro nas transmiss˜oes para o

padr˜ao RS-232.

4.3 COMUNICAÇÃO SERIAL : PROTOCOLO SPI PARA MICROCONTROLADORES

ARM7

A tecnologia de comunica¸c˜ao Serial Peripheral Interface (SPI) foi desenvolvida pela

Motorola. O SPI ´e um protocolo s´ıncrono, que opera no modo full duplex e ´e composto

por 4 sinais. O protocolo SPI permite que a comunica¸c˜ao seja feita entre dois pontos,

n˜ao havendo um endere¸camento para o protocolo e tendo um microcontrolador operando

como Master e o outro Slave. A comunica¸c˜ao ´e feita atrav´es de trˆes vias e um sinal de

ChipSelect:

• Serial Clock - o sinal de clock ´e utilizado para sincronizar o pulso de disparo

durante a transferˆencia de dados do protocolo SPI. O sinal de clock ´e dirigido pelo

master e recebido pelo slave e o disparo pode ser programado para operar tando na

borda de subida ou descida.

• Master Output Slave Input (MOSI) - ´e um sinal unidirecional usado para

transferir dados do master ao slave.

• Master Input Slave Output (MISO) - ´e um sinal unidirecional usado para

transferir dados do slave ao master.

• Chip Select (CS) - ´e um sinal de sele¸c˜ao, que ´e aplicado no slave a receber as

informa¸c˜oes do master.

A Figura (4.5) apresenta um diagrama do hardware que est´a em fase de implementa¸c˜ao.

Est´a sendo utilizado um microcontrolador master e dois slave, o que requer o conhecimento

do protocolo SPI. Os primeiros ensaios realizados este protocolo apresentaram resultados

satisfat´orios.

No diagrama do hardware proposto, existe um microcontrolador ARM7 conﬁgurado

com master, e outros dois microcontroladores Arm7 conﬁgurados como slave. O master ´e

respons´avel por controlar as tarefas que ser˜ao executadas nos slaves. Observando a Figura

(4.5) existe um sonar conectado na UART0 do microcontrolador master, que permite a

comunica¸c˜ao com a eletrˆonica eliminando o cabo de comunica¸c˜ao.

O processo de controle ´e feito atrav´es de uma central onde o operador envia um co-

mando b´asico para sistema embarcado, dirigindo a execu¸c˜ao das tarefas diretamente aos

perif´ericos. Devido ao alto custo do sistema de comunica¸c˜ao por sonar, uma alterna-

tiva cl´assica ´e utilizar um cord˜ao umbilical. De qualquer modo, a mudan¸ca no meio de

comunica¸c˜ao implicaria em modiﬁcar a arquitetura por completo.

FIG. 4.5: Diagrama do Hardware

No hardware proposto, o primeiro microcontrolador slave tem como base a implemen-

ta¸c˜ao do Datalogger, mas agora sendo controlado pelo master. J´a o terceiro microcon-

trolador ser´a respons´avel pela aquisi¸c˜ao de dados de um sensor magn´etico Magnetic Flux

Leakage (MFL) e gravar em um cart˜ao de mem´oria SD.

O procedimento adotado para este tipo de ensaio requer certo cuidado, pois existir˜ao

dois microcontroladores executando programas diferentes. O primeiro passo tem como

base a elabora¸c˜ao de um algoritmo que controle os perif´ericos, na qual foi deﬁnido um “Set

de Comando”. A Figura (4.6) apresenta um ﬂuxograma do algoritmo foi implementado

microcontrolador master e seus primeiros resultados est˜ao ilustrados na Figura (4.7).

FIG. 4.6: Fluxograma do algoritmo implementado no microcontrolador master.

O processo de inicializa¸c˜ao do microcontrolador se d´a atrav´es da conﬁgura¸c˜ao dos per-

if´ericos a serem utilizados. Para esta aplica¸c˜ao o microcontrolador inicializa as UARTs e o

SPI. Os comandos s˜ao enviados pela serial do microcomputador para o microcontrolador

master, que veriﬁca o dado enviado e executa a tarefa deﬁnida para este comando.

• Set de Comando deﬁnido para testes iniciais

• “a”- min´usculo envia o dado “0xAA” pelo canal MOSI do master.

• “b” - min´usculo envia o dado “0xAB” pelo canal MOSI do master.

• “default” - um valor qualquer que seja enviado pela serial aciona o led1.

Para um melhor entendimento do resultado apresentado na Figura (4.7), os valores

hexadecimais s˜ao visualizados em bin´arios. A Tabela (4.2) apresenta a convers˜ao dos

valores apresentados em hexadecimais para bin´arios.

TAB. 4.2: Conversão hexadecimal para binário

Hexadecimal Binario

0xAA 10101010

0xAB 10101011

FIG. 4.7: Primeiros resultados com protocolo SPI.

O microcontrolador master ´e o respons´avel por gerar o clock que transfere o dado para

o slave. A freq

uˆencia do clock foi escolhida para operar em 1MHz, que corresponde a

freq

uˆencia de visualiza¸c˜ao no oscilosc´opio apresentado na Figura (4.7).

Observando a Figura (4.7) ´e poss´ıvel veriﬁcar que a cada pulso de clock um bit ser´a

enviado para o slave.

Para utilizar um componente como slave, seja outro microcontrolador ou um perif´erico

qualquer, temos que fazer o uso das interrup¸c˜oes que est˜ao dispon´ıveis no ARM7. O

microcontrolador ARM7 possui dois tipos de interrup¸c˜oes que s˜ao:

a) FIQ - Interrup¸c˜ao de alta prioridade Vetorada.

b) IRQ - Interrup¸c˜oes IRQ est˜ao dividas em Interrup¸c˜oes Vetoradas e N˜ao Vetoradas.

O ﬂuxograma do algoritmo apresentado na Figura (4.8) ilustra a utiliza¸c˜ao de uma

interrup¸c˜ao do tipo FIQ, onde se liga e desliga os leds com os comandos enviados pelo

master.

Os ensaios realizados com os dois microcontroladores apresentaram resultados satis-

fat´orios. Os procedimentos de conﬁgura¸c˜ao do master s˜ao os mesmos apresentado ante-

riormente. Entretanto, o segundo microcontrolador apenas muda o modo de trabalho de

master para slave. O sincronismo entre os microcontroladores ainda n˜ao se encontra na

sua forma mais robusta ainda. Novos algoritmos devem ser implementados no decorrer

do projeto.

A Figura (4.9) ilustra um ensaio realizado com os microcontroladores se comunicando

atrav´es do protocolo SPI.

FIG. 4.8: Fluxograma do algoritmo implementado no microcontrolador slave.

FIG. 4.9: Comunicação SPI entre microcontroladores.

Observando a Figura (4.9) ´e poss´ıvel veriﬁcar o momento em que o microcontrolador

master seleciona o slave levando o sinal de SSEL1 para n´ıvel l´ogico baixo, e envia os dados

de controle. Estes dados s˜ao interpretados pelo slave, executando assim a fun¸c˜ao ligar

leds, cujo momento do acionamento pode ser visualizado. O desacionamento dos leds ´e

feito da mesma forma, sendo que o byte para execu¸c˜ao da fun¸c˜ao desligar leds ´e outro.

O teste com o protocolo SPI apresentou resultados satisfat´orios, o que permite um

avan¸co na implementa¸c˜ao do hardware proposto para o robˆo SIRIS. Com este avan¸co

podemos criar um protocolo propriet´ario para o robˆo SIRIS, uma vez que os perif´ericos

que fazem parte do robˆo s˜ao conhecidos. Observando a Figura (4.5), foi implementada a

comunica¸c˜ao master/slaver e o acionamento do Datalogger. Para esta implementa¸c˜ao o

ﬂuxograma do algoritmo do microcontrolador slave foi modiﬁcado. A Figura (4.10) ilustra

o ﬂuxograma do microcontrolador slave que aciona o Datalogger.

FIG. 4.10: Fluxograma do algoritmo implementado no microcontrolador slave para acionar o

Datalogger.

A inicializa¸c˜ao do Datalogger ´e feita quando o microcontrolador slave recebe o dado

hexadecimal “0xAA”, dando in´ıcio ao pro cesso de aquisi¸c˜ao dos dados da IMU, gravados

no HDBS Card SD. Os dados gravados no cart˜ao de mem´oria SD s˜ao obtidos utilizando

a implementa¸c˜ao feita em Labview apresentada na Figura (4.1). A Figura (4.11) ilustra

os sistemas eletrˆonicos implementados em bancada.

Para os sistemas eletrˆonicos apresentados na Figura (4.11) foi implementada uma

primeira vers˜ao do hardware que ser´a embarcado no robˆo SIRIS. A Figura (4.12) ilus-

tra este hardware, no Apˆendice A s˜ao apresentados detalhes do projeto para a “vers˜ao 2”

desse hardware e no Apˆendice B encontram-se os c´odigos fontes das implementa¸c˜oes.

FIG. 4.11: Sistemas Eletrônicos implementado em Bancada.

FIG. 4.12: Versão 1 do Hardware que será embarcado no robô SIRIS.

O conversor DC/DC utilizado neste hardware foi o 7805, que transforma tens˜ao de

entrada de 12 VDC em 5 VDC. O conversor MAX 232 possui dois canais de convers˜ao

TTL/RS-232, assim sendo, o padr˜ao TTL corresponde para o n´ıvel l´ogico “1” `a uma

tens˜ao de 5 V e n´ıvel l´ogico “0” `a uma tens˜ao de 0V. Na interface RS232 o n´ıvel l´ogico ‘1’

corresponde `a uma tens˜ao entre -3V e -12V e o n´ıvel l´ogico “0” `a uma tens˜ao entre 3V e

12V.

5. CONCLUSÃO

Este trabalho abordou a aplica¸c˜ao de algumas t´ecnicas de modelagem de uma arquite-

tura rob´otica, gerenciamento das falhas dos softwares embarcados e implementa¸c˜ao em

bancada de alguns componentes do sistema eletrˆonico. De fato, os problemas de gerencia-

mento de falhas nas aplica¸c˜oes embarcadas necessitam de um tratamento especial. Assim

sendo, os estudos foram direcionados para o desenvolvimento de um sistema dedicado,

baseado em microcontroladores ARM7 de 32bits. O primeiro passo antes de adquirir mi-

crocontroladores e outros perif´ericos, foi enquadar a aplica¸c˜ao dentro de alguns requisitos;

a) Funcionalidade do Robˆo;

b) Composi¸c˜ao do Sistema de Comunica¸c˜ao e Controle;

c) Tipos de p erif´ericos.

Os fatores que foram considerados na escolha do microcontrolador:

a) Os sistemas embarcados devem apresentar dimens˜oes reduzidas;

b) O poder de processamento do microcontrolador;

c) Perif´ericos que os microcontroladores possuem;

d) Disponibilidade de bibliotecas para os perif´ericos;

e) Flexibilidade para operar em outros Sistemas Embarcados;

f) Flexibilidade para operar com um Sistema Operacional.

Esses foram alguns dos fatores analisados para a escolha desta arquitetura de micro-

controlador.

A deﬁni¸c˜ao da arquitetura rob´otica responde as duas primeiras perguntas, na qual

todas as caracter´ısticas do robˆo s˜ao deﬁnidas pela arquitetura. Entretanto, a deﬁni¸c˜ao

dos perif´ericos inﬂuencia na modelagem da arquitetura.

A arquitetura apresentada possui uma ﬂexibilidade maior, por se tratar de uma ar-

quitetura do tipo h´ıbrida. Nestes estudos foi proposto um hardware que caracteriza esta

arquitetura e implementado parte desta arquitetura em bancada.

Inicialmente foi feita a implementa¸c˜ao de um Datalogger, onde foram utilizado Redes

de Petri para modelagem de um travamento, apresentando os resultados posteriores satis-

fat´orios. Foram realizados alguns ensaios com microcontroladores se comunicando atrav´es

do protocolo SPI, esses ensaios apresentaram resultados satisfat´orio. No entanto, a comu-

nica¸c˜ao com o protocolo SPI se encontra em fase de implementa¸c˜ao, na qual se pretende

desenvolver em trabalhos futuros um protocolo de comunica¸c˜ao utilizando o protocolo

SPI, que seja capaz de obter informa¸c˜oes em tempo real de diversos perif´ericos.

O Datalogger implementado para plataforma inercial (IMU) possui uma taxa de amos-

tragem muito baixa, por utilizar o m´odulo HDBS que possuir uma taxa de transferˆencia

de dados baixa. Uma solu¸c˜ao para este problema ´e trabalhar na constru¸c˜ao de um novo

hardware, utilizando apenas o microcontrolador ARM7 LPC2138 para realizar a aquisi¸c˜ao

e grava¸c˜ao no cart˜ao de mem´oria. A comunica¸c˜ao com o cart˜ao de mem´oria ´e feita uti-

lizando o protocolo SPI, na qual foram realizados alguns testes com este protocolo.

A primeira etapa para melhorar o desempenho do Datalogger e trabalhar na gera¸c˜ao de

bibliotecas para as UARTs e SPI, dessa maneira, a taxa de amostragem deve aumentar

de forma consider´avel. Esse aumento levaria o Datalogger a obter resultados em uma

faixa mais ampla de amostragem. Novas implementa¸c˜oes devem ser feitas utilizando o

Datalogger e outros perif´ericos.

6. REFERÊNCIAS BIBLIOGRÁFICAS

FERASOLI, H. F. Um Robˆo com Alto Grau de Autonomia para Inspe¸c˜ao de

Tubula¸c˜oes. Tese de Doutorado, USP, 1999.

FILHO, R. Z. M. e ROVERI, F. E. Sistema de Monitora¸c˜ao de Movimentos de

Riser H´ıbrido Auto-Sustent´avel. V Simp´osio Brasileiro de Engenharia Inercial,

p´ags. 180–182, 2007.

FRANCISS, R. e FILHO, R. Z. M. Monitora¸c˜ao de Movimentos de Risers em

Caten´aria. V Simp´osio Brasileiro de Engenharia Inercial, p´ags. 186–189, 2007.

GRASSI, V. J. Arquitetura H´ıbrida pra Robˆos M´oveis Baseada em fun¸c˜oes

de Navega¸c˜ao com Intera¸c˜ao Humana. Tese de Doutorado, USP, S˜ao Paulo/SP,

2006.

JUNG, C. R., OS

ORIO, F. S., KELBER, C. R. e HEINEN, F. J. Computa¸c˜ao Embar-

cada: Projeto e Implementa¸c˜ao de Ve´ıculos Autˆonomos Inteligentes. XXV -

Congresso da Sociedade Brasileira de Computa¸c˜ao, 2005.

MARRANGHELLO, N. Redes de Petri: Conceitos e Aplica¸c˜oes. 2005.

MORAES, C. C. e CASTRUCCI, P. D. L. Engenharia de Automa¸c˜ao Industrial.

LTC - Livros T´ecnicos e Cient´ıﬁcos S.A, 2nd edition, 2007.

LPC213x User Manual. Philips Semiconductors, rev.01 edition, junho 2005.

SEERDEN, P. LPC2xxx SPI master code example. Technical report, janeiro 2006.

SOUSA, D. R. Microcontroladores ARM7, Philips-fam´ılia LPC213x, Teoria e

Pr´atica, volume I. Editora

Erica Ltda., 1nd edition, 2006.

APÊNDICES

A. DIAGRAMA ELETRÔNICO MASTER/SLAVE

O circuito proposto faz parte do sistema eletrˆonico que ser´a embarcado no robˆo, sendo

que algumas caracter´ısticas desse ciircuito devem ser levadas em considera¸c˜ao:

• A tens˜ao de alimenta¸c˜ao do circuito 15 volts

• O circuito foi projetado para realizar a grava¸c˜ao in-circuit dos microcontroladores.

Os jumper devem ser conﬁgurados da seguinte maneira:

– JP3 - inserir jumper para grava¸c˜ao in-circuit, retirar o jumper ap´os gravar.

– JP9 - grava¸c˜ao in-circuit inserir todos os jumper, ap´os a gravar manter apenas

o jumper nos pinos 3 e 4 e o jumper nos pinos 7 e 8.

– JP10 - inserir jumper nos pinos 1 e 3, grava¸c˜ao in-circuit do master e ap´os a

gravar inserir os jumper nos pinos 3 e 5.

- inserir jumper nos pinos 2 e 4, grava¸c˜ao in-circuit do slave e ap´os a gravar

inserir os jumper nos pinos 4 e 6.

– JP11 - inserir jumper nos pinos 1 e 2, grava¸c˜ao in-circuit do master, retirar o

jumper ap´os gravar.

- inserir jumper nos pinos 3 e 4, grava¸c˜ao in-circuit do slave, retirar o jumper

ap´os gravar.

• O circuito pode ser conﬁgurado para operar com quatro RS-232, conﬁgurando JP6.

– JP6 - jumper conectados nos pinos 1 e 11,e jumper nos pinos 2 e 12 temos uma

comunica¸c˜ao RS-232.

- jumper conectados nos pinos 3 e 13,e jumper nos pinos 4 e 14 temos uma

comunica¸c˜ao UART (RX, TX, nivel TTL).

- jumper conectados nos pinos 5 e 15,e jumper nos pinos 6 e 16 temos uma

comunica¸c˜ao RS-232.

- jumper conectados nos pinos 7 e 17,e jumper nos pinos 8 e 18 temos uma

comunica¸c˜ao UART (RX, TX, nivel TTL).

TAB. A.1: Diagrama Eletrônico

D D

C C

B B

A A

Title

Number RevisionSize

Date: 18/1/2008 Sheet of

File: L:\Projeto Data logger\Data logger.SCH Drawn By:

100nF

Fuse 1

RS232_0

100nF

RS232_1

C1+

VDD

C1-

C2+

C2-

VEE

T2OUT

R2IN

R2OUT

T2IN

T1IN

R1OUT

R1IN

T1OUT

GND

VCC

MAX232

JP2

Header 2

TXA0

RXA0

TXA1a

RXA1a

OUT

GND

L78M05CV

0.1uF

0.33uF

1 2

3 4

5 6

7 8

9 10

11 12

13 14

15 16

17 18

19 20

21 22

23 24

25 26

27 28

29 30

31 32

33 34

35 36

37 38

39 40

41 42

43 44

45 46

47 48

49 50

51 52

53 54

55 56

57 58

59 60

JP5

Header 30X2

TXB1RXB1

RXB0 TXB0

MOSI

SCK0

MISO

SSEL0

+5V+5V

+5V

GND

JP8

Header 5

+5V

GND

OUT

GND

L78M12CV

+5V

+12V

JP1

Header 2

Fuse 1

0.33uF

0.1uF

Plug

PWR_uC

PWR_IMU

1 2

3 4

5 6

7 8

9 10

11 12

13 14

15 16

17 18

19 20

21 22

23 24

25 26

27 28

29 30

31 32

33 34

35 36

37 38

39 40

41 42

43 44

45 46

47 48

49 50

51 52

53 54

55 56

57 58

59 60

JP4

Header 30X2

MISO MOSI

SCK0SSEL0

TXA1

TXA1a

TXA1b

RXA1

RXA1b

RXA1a

RXA1b

100nF

C11

100nF

C10

100nF

C18

RS232_0

100nF

RS232_1

C1+

VDD

C1-

C2+

C2-

VEE

T2OUT

R2IN

R2OUT

T2IN

T1IN

R1OUT

R1IN

T1OUT

GND

VCC

MAX232

TXB0

RXB0

TXB1c

RXB1c

+5V

TXA0RXA0

TXA1RXA1

JP7

Header 5

+5V

GND

TXB1d

RXB1d

TXB1 TXB1c

TXB1 TXB1d

RXB1

RXB1c

RXB1d

JP6

Header 10X2A

GNDGND

GND

GNDGND

+5V+5V

GND

01/01

IME-LR-MAU-576001

Projeto SIRIS - Placa de Controle

Maurício Brito

RTS_0

DTR_0

10K

R12

51R

R11

10K

D11N4148

D21N4148

BAT54A

JP3

BC548

DTR_0

RTS_0

DCD1A

VCC3V3ARTSA RTSB VCC3V3B

DCD1B

1 2

3 4

5 6

7 8

JP9

Header 4X2

1 2

3 4

5 6

JP10

Header 3X2H

10K

R10

1 2

3 4

JP11

Header 2X2

10K

R14

10K

R13

DCD1B

VCC3V3A

RSTA

RSTB

VCC3V3B

SW-PB

47K

22R

100nF

C17

Cap

VCC3V3BRSTBRSTA

SW-PB

47K

22R

100nF

C12

Cap

VCC3V3A

TAB. A.2: Layout da Placa de Controle

B. CÓDIGO FONTE

Neste apˆendice apresenta-se o c´odigo fonte dos diversos algoritmos desenvolvidos e

citados ao longo da disserta¸c˜ao. Os c´odigos foram gerados pelo IAR MakeApp para facili-

tar a programa¸c˜ao do LPC2138/48. O funcionamento do IAR MakeApp e do Compilador

C IAR Embedded Workbench encontra-se apresentado por (SOUSA, 2006) nos Cap´ıtulos

4 e 5. No Apˆendice B (SOUSA, 2006) apresenta a descri¸c˜ao das Fun¸c˜oes geradas de pelo

IAR Make App.

B.1 CONFIGURAÇÃO DO DATALOGGER

A conﬁgura¸c˜ao do microcontrolador ARM7 est´a dividida em trˆes etapas: conﬁgura¸c˜ao

do Phase locked Loop (PLL), conﬁgura¸c˜ao do barramento VLSI Peripheral Bus (VPB) e

conﬁgura¸c˜ao das UART0 e UART1.

O PLL ´e usado em conjunto com o cristal ligado externamente, cujo valor est´a entre

10MHz e 25MHz, e multiplicando essa frequˆencia pode-se obter uma sa´ıda de 10MHz a

60MHz. Ap´os o PLL existe o barramento VPB, onde est˜ao conectados os perif´ericos do

microcontrolador.

O controle do PLL ´e feito conﬁgurando os registradores PLLCFG, PLLCON, PLL-

STAT, de tal forma que no registrador PLLCFG deve-se ajustar os parˆametros M e P, onde

M ´e o multiplicador do PLL e P ´e o divisor do PLL. O registrador PLLCON tem como ﬁnal-

idade habilitar o m´odulo PLL. O PLLSTAT ´e um registrador de veriﬁca¸c˜ao. Em (SOUSA,

2006) (Phi, 2005) s˜ao apresentados detalhes de cada um dos registradores citados acima.

Desta forma, pode-se ajustar a frequˆencia de trabalho do n´ucleo ARM7TDMI-S aplicando

a seguinte f´ormula:

B.1.1 CÁLCULO DOS PARÂMETROS M E P

C´alculo de M:

M = CCLK/OSC

C´alculo de P:

156 < F CCO < 320 = CCLK ∗ 2 ∗ P

O c´alculo do parˆametro P deve estar na faixa de frequˆencia do Current Controlled

Oscillator (CCO), OSC ´e frequˆencia do cristal, em MHertz. O barramento VPB ´e con-

ﬁgurado atrav´es do registrador VPBDIV, onde pode-se utilizar como divisor 1, 2 ou 4.

Assim, o sinal de clock ser´a divido e aplicado aos perif´ericos.

B.1.2 CONFIGURAÇÃO DAS UARTS

Para o funcionamento das UARTs o microcontrolador possui internamente um “Ge-

rador de Baudrate” que utiliza o clock do barramento VBP dividido por 16 e dois reg-

istradores auxiliares UxDLL e UxDLM.

O baudrate ´e calculado seguinte f´ormula:

BaudRate = P CLK/(16 ∗ valordodivisor)

B.1.3 CÓDIGO FONTE DO DATALOGGER

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Projeto Sistemas Eletrônicos

* *

Implementação do Datalogger com a Placa McBoard ARM7 (LPC2138)

Sensor Inercial Microstrain − 3DGX1

* *

IME − INSTITUTO MILITAR DE ENGENHARIA

* *

DEPARTAMENTO DE ENGENHARIA MECÂNICA

LAB. DE ROBÓTICA

TEL: (0XX21) 2546−7278 SITE: WWW.IME.EB.BR

* *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

VERSÃO : 1.0

DATA : 28/08/2007

Gravar o Hex = datalogger.hex

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Descrição geral

** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

NESTE PROJETO UTILIZA A UART0 PARA ENVIAR E RECEBER INFORMAÇÕES

DO SENSOR INERCIAL E GRAVAR ESSAs INFORMAÇÕES NO MÓDULO HDBS

CONECTADO NA UART1.

− CONFIGURAÇÃO DO PLL

− CONFIGURAÇÃO DA UART0

− CONFIGURAÇÃO DA UART1

SET DE COMANDO DO HDBS−CARD_SD

− 0x0D − <ENTER>

− HDRESET − UTLIZADO PARA RESET DO MICROCONTROLADOR ATMEGA32.

− HDINIT − INICIALIZA À COMUNIÇÃO ENTRE AS UART'S.

− FS − INICIALIZA O SISTEMA DE ARQUIVOS.

− DISKSIZE − RETORNA O TAMANHO DO CARD EM BYTES.

− DISKFREE − RETORNA O ESPAÇO LIVRE DO CARD EM BYTES.

− FSINFO − RETORNA AS INFORMAÇÕES DOS SISTEMA DE ARQUIVOS.

− DIRINFO − RETORNA AS INFORMAÇÕES DO DIRETÓRIO.

− FATINFO − RETORNA AS INFORMAÇÕES DA FAT.

− COMANDO DE DIRETORIO

− DIR

−

=================================================================

1. Arquivos "INCLUDE.h" que gerados pelo IAR MakeApp

=================================================================

#include "usercode.h"

#include "ma_tgt.h"

#include "ma_sfr.h"

#include "iolpc2148.h"

#include <stdio.h>

#include <string.h>

#include "ma_scb.h"

#include "ma_pcb.h"

#include "ma_gpio.h"

#include "ma_uart0.h"

#include "ma_uart1.h"

#include "ma_rtc.h"

================================================================

2 Define Macros Interno

================================================================

3 Variáveis Globais

================================================================

4 Funções Internas − (Definidas na seção 7)

================================================================

void PLL_init(void);

================================================================

5 Variáveis Internas

================================================================

char FIRMWARE_INERCIAL[255];

char SERIAL_INERCIAL[255];

char TEMPERATURA[255];

char EULER[255];

char buffer_lcd[255];

char texto[255];

char texto2[255];

int x = 0;

int y = 0;

unsigned char rx_byte;

unsigned char rx_status;

unsigned char RX_UART;

unsigned char RX_UART_0_STATUS;

unsigned char RX_UART_1_STATUS;

================================================================

6 Funções Globais

================================================================

void delay_ms(unsigned int timer);

void main( void )

{

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Inicializa o Sistema

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

MA_Init_SCB();

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Inicializa os Periféricos que estão sendo utilizados

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

MA_Reset_PCB();

MA_Reset_GPIO();

MA_Reset_UART0();

MA_Reset_UART1();

−−−−−−−−−−−− Configura os Leds −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

IO0DIR |= (1<<10);

IO0DIR |= (1<<11);

IO0DIR |= (1<<12);

IO0DIR |= (1<<13);

IO0DIR |= (1<<14);

IO0DIR |= (1<<15);

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−−−−−−−−−−−−− Inicializa o PLL−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

PLL_init();

−−−−−−−−−− Ininializa o HDBS−CARD_SD −−−−−−−−−−−−−−−−−−−−−−−−

delay_ms(100);

MA_PutString_UART1("\r\n\r\n"); //ENVIA RESULTADO PARA A UART 1

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART); //RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(100);

MA_PutString_UART1("HDINIT \r\n\r\n");

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART); //RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(100);

MA_PutString_UART1("FS \r\n\r\n");

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART); //RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(100);

MA_PutString_UART1("FOB CARD_SD1.TXT, 1\r\n\r\n");

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART); //RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

IO0SET |= (1<<13);

IO0CLR |= (1<<12);

delay_ms(50);

−−−−−−−−−−− Inicializa o SENSOR INERCIAL−−−−−−−−−−−−−−−−−−−−−

Foram realizados testes para aquisição do Firmware, Serial Number

Temperatura, Ângulos de Euler, além da aquisição da Matriz de

de Orientação Estabilizada que será aplicada no algoritmo para

estimar a trajetória do Risers.

−−−−−−−−−−−−−−−−−− Firmware −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

MA_PutChar_UART0(0xF0);

y = 0;

do {

rx_status = MA_GetChar_UART1(&rx_byte);//RECEBE DADOS PELA UART 0

if(rx_status == MA_OK)

{

snprintf(&FIRMWARE_INERCIAL[y

2],3,"%.2x",rx_byte);

y++;

}

} while ((y < 5));

snprintf(texto,254,"%s%s%s","WL 1,",FIRMWARE_INERCIAL,"\r\n");

MA_PutString_UART1(texto);

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART); //RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(50);

−−−−−−−−−−−−−−−−−−−−−−−−−−−Serial Number −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

MA_PutChar_UART0(0xF1);

y = 0;

do {

rx_status = MA_GetChar_UART1(&rx_byte);//RECEBE DADOS PELA UART 0

if(rx_status == MA_OK)

{

snprintf(&SERIAL_INERCIAL[y

2],3,"%.2x",rx_byte);

y++;

}

} while ((y < 5));

snprintf(texto,254,"%s%s%s","WL 1,",SERIAL_INERCIAL,"\r\n");

MA_PutString_UART1(texto);

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART); //RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(50);

−−−−−−−−−−−−−−−−−−−−−−−−−−−Temperatura −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

MA_PutChar_UART0(0x07);

y = 0;

do {

rx_status = MA_GetChar_UART1(&rx_byte);//RECEBE DADOS PELA UART 0

if(rx_status == MA_OK)

{

snprintf(&TEMPERATURA[y

2],3,"%.2x",rx_byte);

y++;

}

} while ((y < 7));

IO0CLR |= (1<<13);

snprintf(texto,254,"%s%s%s","WL 1,",TEMPERATURA,"\r\n");

MA_PutString_UART1(texto);

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART); //RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(50);

−−−−−−−−−−−−−−−−−−−−−−− Ângulos de Euler −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

MA_PutChar_UART0(0x0E);

y = 0;

do {

rx_status = MA_GetChar_UART1(&rx_byte);//RECEBE DADOS PELA UART 0

if(rx_status == MA_OK)

{

snprintf(&EULER[y

2],3,"%.2x",rx_byte);

y++;

}

} while ((y < 11));

snprintf(texto,254,"%s%s%s","WL 1,",EULER,"\r\n");

MA_PutString_UART1(texto);

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART); //RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(50);

−−−−−−−−−−−−−−−−−−−−− Matriz Instantânea de Orientacão

−−−−−−−−−−−−−−−−−−

for (int x=0;x≤1000;x++) // número de amostra

{

IO0SET |= (1<<14);

MA_PutChar_UART0(0x0B);

y = 0;

IO0SET |= (1<<13);

do {

rx_status = MA_GetChar_UART0(&rx_byte);//RECEBE DADOS PELA UART 0

if(rx_status == MA_OK)

{

snprintf(&buffer_lcd[y

2],3,"%.2x",rx_byte);

y++;

}

} while ((y < 23));

snprintf(texto,254,"%s%s%s","WL 1,",buffer_lcd,"\r\n\r\n");

MA_PutString_UART1(texto);

IO0CLR |= (1<<13);

}

delay_ms(200);

MA_PutString_UART1("CLOSE 1\r\n");

IO0CLR |= (1<<14);

}

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

=====================================================================

7. Funções Internas

=====================================================================

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Função PLL −−−−−−−−−−−−−−−−−−−−−−−−−

=====================================================================

PLL_init()

Configura o LPC2138 para trabalhar com Cclk = 60MHz e Pclk = 60MHz

com a freqüência do cristal de 20MHz

======================================================================

void PLL_init(void)

{

PLLCFG = 0x00000042;//Configura M = 3 e P = 2,

PLLCON = 0x00000001;//Habilita PLL.

PLLFEED = 0x000000AA;

PLLFEED = 0x00000055;//Atualiza os registradores.

while(!(PLLSTAT & 0x00000400)); //Testa PLOCK.

PLLCON = 0x00000003;//Conecta ao PLL.

PLLFEED = 0x000000AA;

PLLFEED = 0x00000055;//Atualiza os registradores.

VPBDIV = 0x00000002;//Configura Pclk = 30MHz.

}

**********************************************************************

−−−−−−−−−−−−−−−−−−−−−−−−−−−Função delay_ms −−−−−−−−−−−−−−−−−−−−−−−−−

======================================================================

delay_ms()

Configura o LPC2138 para trabalhar com Cclk = 60MHz e Pclk = 30MHz

com a freqüência do cristal de 20MHz

======================================================================

void delay_ms(unsigned int timer)

{

unsigned int contador;

contador = 1

timer;

while(−−contador);

}

**********************************************************************

======================================================================

Fim

======================================================================

B.2 CONFIGURAÇÃO DO MICROCONTROLADOR COMO MASTER

Adotando a mesma conﬁgura¸c˜ao apresentada para o PLL e barramento VBP, deve-se

determinar a frequˆencia do clock do SPI, na qual o sinal de clo ck ´e gerado pelo master.

Esta frequˆencia ´e calculada pela seguinte f´ormula:

Frequˆencia do SPI = P CLK/S0SP CCR

Para esta aplica¸c˜ao foi adotado uma frequˆencia de 1MHz para o barramento, sendo

que o clock depois do PLL ´e de 30MHz, desta maneira o registador S0SPCCR deve ser

carregado com o valor calculado.

Descri¸c˜ao do Registradores

S0SPCR Conﬁgura o funcionamento do M´odulo SPI

S0SPSR Mostra o estado de um evento SPI

S0SPDR Envia e recebe dados

S0SPCCR Conﬁgura o Clock do SPI

S0SPINT Flag da Interrup¸c˜ao do SPI

B.2.1 CÓDIGO FONTE DO LPC2138 - MASTER

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Projeto Sistemas Eletrônicos

* *

Implementação do Master com a Placa McBoard ARM7 (LPC2138)

* *

IME − INSTITUTO MILITAR DE ENGENHARIA

* *

DEPARTAMENTO DE ENGENHARIA MECÂNICA

LAB. DE ROBÓTICA

TEL: (0XX21) 2546−7278 SITE: WWW.IME.EB.BR

* *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

VERSÃO : 1.0

DATA : 28/08/2007

Gravar o Hex = datalogger.hex

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Descrição geral

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Software Embarcado no microcontrolar Master(LPC2138).

=================================================================

1. Arquivos "INCLUDE.h" que gerados pelo IAR MakeApp

=================================================================

#include "usercode.h"

#include "ma_tgt.h"

#include "ma_sfr.h"

#include "iolpc2138.h"

#include "ma_scb.h"

#include "ma_pcb.h"

#include "ma_uart0.h"

#include "ma_uart1.h"

#include "ma_spi.h"

//#include "ma_gpio.h"

//#include "ma_vic.h"

//#include "ma_i2c.h"

//#include "ma_spi.h"

//#include "ma_tmr.h"

//#include "ma_pwm0.h"

//#include "ma_adc.h"

//#include "ma_rtc.h"

//#include "ma_wdt.h"

================================================================

2 Define Macros Interno

================================================================

#define SPIF (1<<7)

================================================================

3 Variáveis Globais

================================================================

#define DATA 0xC1

================================================================

4 Funções Internas − (Definidas na seção 7)

================================================================

void PLL_init(void);

================================================================

5 Variáveis Internas

================================================================

int y=0;

int i=0;

unsigned char contador_01;

unsigned char SPI_0;

unsigned char SPI_0_STATUS;

unsigned char rx_byte;

unsigned char rx_status;

unsigned char RX_UART;

unsigned char RX_UART_0_CONT;

unsigned char RX_UART_0_STATUS;

unsigned char RX_UART_1_STATUS;

================================================================

6 Funções Globais

================================================================

void delay_ms(unsigned int timer);

void liga_ilum(unsigned int num);

void desl_ilum(unsigned int num);

void main( void )

{

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Inicializa o Sistema

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

MA_Init_SCB();

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Inicializa os Periféricos que estão sendo utilizados

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−−−−−−−−−− Configura os Leds −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

IO0DIR |= (1<<7);

IO0DIR |= (1<<12);

IO0DIR |= (1<<13);

IO0DIR |= (1<<20);

IO0DIR |= (1<<23);

IO1DIR |= (1<<16);

IO1DIR |= (1<<17);

IO1DIR |= (1<<24);

PLL_init(); // Inicializa o PLL

MA_Init_PCB();

MA_Init_SPI(); // Inicializa Barramento SPI_0

MA_Init_UART0(); // Inicializa Uart0

MA_Init_UART1(); // Inicializa Uart1

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−− Controle de UARTs e SPI −−

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−− Relação de rotinas implementadas para às UARTs e SPI

rotina 1 − testa a UART0 e UARt1. Arquivo: uart0_uart1.hex

UARt0 − configurada para um baud rate de 38400, 8N1.

UART1 − Configurada para um baud rate de 38400, 8N1.

Dado definido dentro de "MA_PutChar_UART" deve ser visualizado

através de um osciloscopio ou pela Rs−232 de um PC.

rotina 2 − Rotina de controle do Microcontrolador LPC2148

Slave. Arquivo: spi_master.hex

rotina 3 − testa a SPI. Arquivo: teste_spi.hex

Dentro dessas rotinas foram implementadas duas funçôes

Para o acionamento e desacionamento do Sistema de ILuminação.

−−

−−−−−−−−−−−−−−−−−−−atualizado em: 19/12/2007−−−−−−−−−−−−−−−−−−

−−−−−−−−−−−−−−−−−−−−−− Rotina 1 −−−−−−−−−−−−−−−−−−−−−−−−−−−−

while(1)

{

MA_PutChar_UART0(0x13);

//MA_PutChar_UART1(0xC9);

//MA_PutChar_UART1(0x47);

//MA_PutChar_UART1(0x0F);

MA_PutChar_UART1(0x17);

}

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−−−−−−−−−−−−−−−−−−−−− Rotina 2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−

unsigned char dado = 0xAA;

unsigned char dado1 = 0xAB;

while(1)

{

RX_UART_0_STATUS = 0;

RX_UART = 0;

while ((RX_UART_0_STATUS!=MA_OK))

{

RX_UART_0_STATUS = MA_GetChar_UART0(&RX_UART);//RECEBE DADOS PELA UART 0

RX_UART_0_CONT = RX_UART;

}

RX_UART_0_STATUS = 0;

RX_UART = 0;

switch(RX_UART_0_CONT)

{

case 'a':

IO0SET |= (1<<7);

do {

IO0CLR |= (1<<7);

MA_PutChar_SPI0(dado); // Envia o dado pela SPI

delay_ms(1);

} while(MA_TestChar_SPI0()==MA_OK);

IO0SET |= (1<<7);

liga_ilum(1);

break;

case 'b':

IO0SET |= (1<<7);

do {

IO0CLR |= (1<<7);

MA_PutChar_SPI0(dado1);

delay_ms(1);

} while(MA_TestChar_SPI0()==MA_OK);

IO0SET |= (1<<7);

desl_ilum(1);

break;

case 'c':

liga_ilum(1);

IO0CLR |= (1<<23);

break;

case 'd':

desl_ilum(1);

break;

default:

IO0SET |= (1<<23);

break;

}

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−−−−−−−−−−−−−−−−−−−−− Rotina 3 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−

unsigned char dado = 0xAA;

unsigned char dado1 = 0xAB;

unsigned char tst01 = 0xff;

while(1)

{

RX_UART_0_STATUS = 0;

RX_UART = 0;

while ((RX_UART_0_STATUS!=MA_OK))

{

RX_UART_0_STATUS = MA_GetChar_UART0(&RX_UART); //RECEBE DADOS PELA UART 0

RX_UART_0_CONT = RX_UART;

}

RX_UART_0_STATUS = 0;

RX_UART = 0;

switch(RX_UART_0_CONT)

{

case 'a':

for (tst01=0; tst01<0x7f;tst01++)//Loop incrementa a variável tst01

{

MA_PutChar_SPI0(dado); Envia o Dado

delay_ms(100);

}

break;

case 'b':

for (tst01=0; tst01<0x7f;tst01++)//Loop incrementa a variável tst01

{

MA_PutChar_SPI0(dado1);Envia o Dado1

delay_ms(100);

}

break;

default:

IO0SET |= (1<<23);

break;

}

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

} /

main

======================================================================

7. Funções Internas

======================================================================

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Função PLL −−−−−−−−−−−−−−−−−−−−−−−−−−−

=====================================================================

PLL_init()

Configura o LPC2138 para trabalhar com Cclk = 60MHz e Pclk = 60MHz

com a freqüência do cristal de 20MHz

===================================================================

void PLL_init(void)

{

PLLCFG = 0x00000042;//Configura M = 3 e P = 2,

PLLCON = 0x00000001;//Habilita PLL.

PLLFEED = 0x000000AA;

PLLFEED = 0x00000055;//Atualiza os registradores.

while(!(PLLSTAT & 0x00000400)); //Testa PLOCK.

PLLCON = 0x00000003;//Conecta ao PLL.

PLLFEED = 0x000000AA;

PLLFEED = 0x00000055;//Atualiza os registradores.

VPBDIV = 0x00000002;//Configura Pclk = 30MHz.

}

************************************************************************

−−−−−−−−−−−−−−−−−−−−−−−−−−−Função delay_ms −−−−−−−−−−−−−−−−−−−−−−−−−−−

=======================================================================

delay_ms()

Configura o LPC2138 para trabalhar com Cclk = 60MHz e Pclk = 30MHz

com a freqüência do cristal de 20MHz

======================================================================

void delay_ms(unsigned int timer)

{

unsigned int contador;

contador = 1

timer;

while(−−contador);

}

***********************************************************************

−−−−−−−−−−−−−−−−−−−−−−−−−−−Função ILuminação −−−−−−−−−−−−−−−−−−−−−−−−

=======================================================================

liga_ilum(unsigned int num) − esta função coloca os pinos 12,13,20 em

nível lógico "ALTO"

desl_ilum(unsigned int num) − esta função coloca os pinos 12,13,20 em

nível lógico "Baixo"

=======================================================================

void liga_ilum(unsigned int num)

{

IO0SET |= (1<<12);

IO0SET |= (1<<13);

IO0SET |= (1<<20);

}

void desl_ilum(unsigned int num)

{

IO0CLR |= (1<<12);

IO0CLR |= (1<<13);

IO0CLR |= (1<<20);

}

************************************************************************

========================================================================

Fim

========================================================================

B.3 CONFIGURAÇÃO DO MICROCONTROLADOR COMO SLAVE

O microcontrolador deve ser conﬁgurado para operar com slave, esta conﬁgura¸c˜ao

´e feita atrav´es do registrador S0SPCR. A interrup¸c˜ao de SPI deve ser conﬁgurada no

registrador S0SPINT, em (SEERDEN, 2006) apresenta-se um aplicativo que pode ser

usado como base para novas implementa¸c˜oes.

B.3.1 CÓDIGO FONTE DO LPC2148 - SLAVE

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Projeto Sistemas Eletrônicos

* *

Implementação do Slave com a Placa eLPC2148 ARM7 (LPC2148)

* *

IME − INSTITUTO MILITAR DE ENGENHARIA

* *

DEPARTAMENTO DE ENGENHARIA MECÂNICA

LAB. DE ROBÓTICA

TEL: (0XX21) 2546−7278 SITE: WWW.IME.EB.BR

* *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

VERSÃO : 1.0

DATA : 24/12/2007

Gravar o Hex = slave_datalogger.hex

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Descrição geral

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Software Embarcado no microcontrolar Slave(LPC2148).

=================================================================

1. Arquivos "INCLUDE.h" que gerados pelo IAR MakeApp

=================================================================

#include "usercode.h"

#include "ma_tgt.h"

#include "ma_sfr.h"

#include "iolpc2138.h"

#include "stdio.h"

#include <string.h>

#include "ma_scb.h"

#include "ma_pcb.h"

#include "ma_uart0.h"

#include "ma_uart1.h"

#include "ma_spi.h"

#include "ma_vic.h"

#include <inarm.h>

================================================================

2 Define Macros Interno

================================================================

#define SPIF (1<<7)

================================================================

3 Variáveis Globais

================================================================

#define DATA 0xC1

================================================================

4 Funções Internas − (Definidas na seção 7)

================================================================

void PLL_init(void);

================================================================

5 Variáveis Internas

================================================================

int x=0;

int y=0;

int i=0;

char Buf[255];

char texto[255];

unsigned char contador_01;

unsigned char SPI_0;

unsigned char SPI_0_STATUS;

unsigned char rx_byte;

unsigned char rx_status;

unsigned char RX_UART;

unsigned char RX_UART_0_CONT;

unsigned char RX_UART_0_STATUS;

unsigned char RX_UART_1_STATUS;

unsigned char SlaveRcv;

unsigned char SlaveSnd;

================================================================

6 Funções Globais

================================================================

void delay_ms(unsigned int timer);

void liga_ilum(unsigned int num);

void desl_ilum(unsigned int num);

−−−−−−−−−−−−−−−−−−−−−Interrupção FIQPORAI−−−−−−−−−−−−−−−−−−−−−−−−

Esta Interrupção excuta a inicialização do HDBS e faz aquisição

de dados do Sensor Inercial, gravando os dados no Cartão SD

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

#pragma vector=0x1C

__fiq __arm void FIQPORAI_ISR_Handler (void)

{

if (S0SPSR) ; // Registrador de Status

SlaveRcv = S0SPDR; // Armazena o dado recebido pelo barramento SPI

switch (SlaveRcv)

{

case 0xAA:

−−−−−−−−−−−−−−−−Inicialização do Card_SD−−−−−−−−−−−−−−−−−−−−−−−−−−

liga_ilum(1);

delay_ms(100);

MA_PutString_UART1("\r\n\r\n"); //ENVIA RESULTADO PARA A UART 1

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART); //RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(100);

MA_PutString_UART1("HDINIT \r\n\r\n");//ENVIA RESULTADO PARA A UART 1

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART);//RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(100);

MA_PutString_UART1("FS \r\n\r\n");//ENVIA RESULTADO PARA A UART 1

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART);//RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

delay_ms(100);

MA_PutString_UART1("FOB CARD_SD.TXT, 1\r\n\r\n");//ENVIA RESULTADO PARA A UART 1

RX_UART_1_STATUS = 0;

RX_UART = 0;

while ((RX_UART_1_STATUS!=MA_OK)||(RX_UART!=0x3E))

{

RX_UART_1_STATUS = MA_GetChar_UART1(&RX_UART);//RECEBE DADOS PELA UART 1

}

RX_UART_1_STATUS= 0;

RX_UART = 0;

desl_ilum(1);

delay_ms(1);

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−

−−−−−− Matriz Instantânea de Orientacão−−−−−−−−−−−−−−−−−−−−−−−−−−

for (int x=0;x≤10000;x++)

{

IO0SET |= (1<<12);

MA_PutChar_UART0(0x0B);

delay_ms(100);

IO0CLR |= (1<<12);

y = 0;

do {

rx_status = MA_GetChar_UART0(&rx_byte);//RECEBE DADOS PELA UART 0

if(rx_status == MA_OK)

{

snprintf(&Buf[y

2],3,"%.2x",rx_byte);

y++;

}

} while ((y < 23));

snprintf(texto,254,

"%s%s%s","WL 1,",Buf,"\r\n\r\n");

//delay_ms(1);

IO0SET |= (1<<13);

MA_PutString_UART1(texto);

delay_ms(100);

IO0CLR |= (1<<13);

}

delay_ms(20);

MA_PutString_UART1("CLOSE 1\r\n");

IO0SET |= (1<<15);

break;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

case 0xAB:

liga_ilum(1);

desl_ilum(1);

break;

default:

desl_ilum(1);

IO0CLR |= (1<<15);

break;

}

//S0SPDR = SlaveSnd; // envia dado para o master

S0SPINT = 0x01; // Limpa o flag da interrupção

VICVectAddr = 0; // Limpa a VIC

}

void main( void )

{

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Inicializa o Sistema

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

MA_Init_SCB();

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Inicializa os Periféricos que estão sendo utilizados

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−−−−−−Configura os Leds −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

//IO0DIR |= (1<<8);

//IO0DIR |= (1<<9);

IO0DIR |= (1<<10);

//IO0DIR |= (1<<11);

IO0DIR |= (1<<12);

IO0DIR |= (1<<13);

//IO0DIR |= (1<<14);

IO0DIR |= (1<<15);

PLL_init(); // Inicializa o PLL

MA_Init_PCB();

MA_Init_SPI(); // Inicializa o Barramento SPI

MA_Init_UART0(); // Inicializa a UART0

MA_Init_UART1(); // Inicializa a Uart1

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Interrupção FIQ_SPI0−−−−−−−−−−−−−−−−−

Execução da Interrupção

__disable_interrupt(); // Interrupção desabilitada

VICIntSelect &= (1<<VIC_SPI); // Faz a seleção da Interrupção

VICIntEnable |= (1<<VIC_SPI);

__enable_interrupt(); // Interrupção habilitada

} /

main

======================================================================

7. Funções Internas

======================================================================

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Função PLL −−−−−−−−−−−−−−−−−−−−−−−−−−

======================================================================

PLL_init()

Configura o LPC2148 para trabalhar com Cclk = 48MHz e Pclk = 24MHz

com a freqüência do cristal de 16MHz

======================================================================

void PLL_init(void)

{

PLLCFG = 0x00000042; //Configura M = 3 e P = 2,

PLLCON = 0x00000001; //Habilita PLL

PLLFEED = 0x000000AA;

PLLFEED = 0x00000055; //Atualiza os registradores

while(!(PLLSTAT & 0x00000400)); //Testa PLOCK

PLLCON = 0x00000003; //Conecta ao PLL

PLLFEED = 0x000000AA;

PLLFEED = 0x00000055; //Atualiza os registradores

VPBDIV = 0x00000002; //Configura Pclk = 24MHz

}

−−−−−−−−−−−−− Função delay_ms −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

========================================================================

delay_ms()

========================================================================

void delay_ms(unsigned int timer)

{

unsigned int contador;

contador = 1

timer;

while(−−contador);

}

−−−−−−−−−−−−−−−−−−−−−−−−−−−Função ILuminação −−−−−−−−−−−−−−−−−−−−−−−−

=======================================================================

liga_ilum(unsigned int num) − esta função coloca os pinos 8,9,10 em

nível lógico "ALTO"

desl_ilum(unsigned int num) − esta função coloca os pinos 8,9,10 em

nível lógico "Baixo"

=======================================================================

void liga_ilum(unsigned int num)

{

//IO0SET |= (1<<8);

//IO0SET |= (1<<9);

IO0SET |= (1<<10);

}

void desl_ilum(unsigned int num)

{

//IO0CLR |= (1<<8);

//IO0CLR |= (1<<9);

IO0CLR |= (1<<10);

}

*****************************************************************************

===========================================================================

FIM

===========================================================================

Livros Grátis
( http://www.livrosgratis.com.br )
 
Milhares de Livros para Download:
 
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas

Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
 
 