UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ …fabro/IF66J/Relatorios_Finais/2011_1/... · Fonte:...

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

DEPARTAMENTO ACADÊMICO DE ELETRÔNICA/INFORMATICA

CURSO DE ENGENHARIA DE COMPUTAÇÃO

MONOGRAFIA

ROBOFUT - PROJETO DE INICIAÇÃO DE UM ROBÔ PARA A

ROBOCUP

ARI MAGAGNIN JUNIOR

EDUARDO CABRAL RESENDE NEIVA

JOÃO HAMILTON CECATO SIMAS

CURITIBA

2011

ARI MAGAGNIN JUNIOR

EDUARDO CABRAL RESENDE NEIVA

JOÃO HAMILTON CECATO SIMAS

ROBOFUT - PROJETO DE INICIAÇÃO DE UM ROBÔ PARA A

ROBOCUP

Monografia apresentada como requisito para aprovação na disciplina de Oficina de Integração 3, ministrada pelos professores:

Prof. Dr. João Alberto Fabro

Prof. Dr. Heitor Silvério Lopes

CURITIBA

2011

iv

Resumo

Esta monografia destina-se a descrever o desenvolvimento de um sistema composto por um robô com 3 rodas, um sistema de comunicação sem fio e uma estação-base capaz de controlar vários robôs, bem como documentar e explicar as decisões de projeto tomadas. O objetivo do projeto é prover uma plataforma confiável que, comandada por uma inteligência artificial, seja capaz de participar de competições de futebol de robôs.

Palavras-chave

Futebol de Robôs, RoboCup, Comunicação Wireless.

v

Abstract

This monograph is intended to describe the development of a system composed of a robot with three wheels, a wireless communication system and a base station capable of controlling multiple robots, as well as to document and explain the design decisions taken. The project's goal is to provide a reliable platform that, led by an artificial intelligence, is able to participate in robot soccer competitions.

Key-words

Robot Soccer, RoboCup, Wireless Communication

vi

Sumário

1 INTRODUÇÃO ........................................................................................... 15

1.1 MOTIVAÇÃO .............................................................................................. 15

1.2 TRABALHOS CORRELATOS .................................................................... 15 1.2.1 Omni¹ ......................................................................................................... 15 1.2.2 Omni² ......................................................................................................... 17 1.2.3 RoboFEI ..................................................................................................... 17

1.3 OBJETIVOS ............................................................................................... 18

2 PLANEJAMENTO ..................................................................................... 20

2.1 DECLARAÇÃO DO ENCOPO EM ALTO-NÍVEL ....................................... 20

2.2 PREMISSAS E RESTRIÇÕES ................................................................... 20

2.3 DESIGNAÇÃO DO GERENTE E DA EQUIPE ........................................... 21

2.4 PLANEJAMENTO DE RISCOS .................................................................. 21

2.5 REQUISITOS ............................................................................................. 21

2.6 ALTERNTIVA TECNOLÓGICA .................................................................. 23

2.6.1 Estação base ............................................................................................. 23 2.6.2 Linguagem de programação ...................................................................... 23

2.6.2.1 JAVA ............................................................................................................ 23 2.6.2.2 C ................................................................................................................... 24

2.7 SISTEMA DE COMUNICAÇÃO ................................................................. 25

2.8 SISTEMA EMBARCADO ........................................................................... 26 2.8.1 Ponte-H ...................................................................................................... 27

2.8.1.1 Ponte-H utilizando componentes discretos................................................... 27

2.8.1.2 L298N ........................................................................................................... 27 2.8.1.3 Comparação e escolha da ponte-H ............................................................... 27

2.9 MICROCONTROLADOR ........................................................................... 28 2.9.1 Atmega328 ................................................................................................. 28

2.9.2 DSPIC30F3010 .......................................................................................... 29 2.9.3 Atmega 640 ................................................................................................ 29 2.9.4 Atmega2560 ............................................................................................... 30

2.9.5 C8051F340 ................................................................................................ 31

2.9.6 Comparação e escolha do microcontrolador .............................................. 31

2.10 ORÇAMENTO INICIAL DETALHADO PREVISTO .................................... 32

2.11 ORÇAMENTRO DETALHADO GASTO ..................................................... 35

2.12 CRONOGRAMA ......................................................................................... 36

2.13 ENTREGÁVEIS .......................................................................................... 39

2.14 AUXILIARES DE GERENCIAMENTO ....................................................... 39

3 EXECUÇÃO ............................................................................................... 41

vii

3.1 ARQUITETURA GERAL DO HARDWARE E SOFTWARE ........................ 41

3.2 ESTAÇÃO-BASE ....................................................................................... 42 3.2.1 Framework ................................................................................................. 42

3.2.1.1 Parser ............................................................................................................ 45

3.2.2 Interface Gráfica ......................................................................................... 47

3.3 SISTEMA DE COMUNICAÇÃO ................................................................. 48

3.3.1 Módulos de comunicação........................................................................... 48 3.3.2 Protocolo .................................................................................................... 49

3.3.2.1 Formato da mensagem .................................................................................. 49 3.3.2.2 Encapsulamento da mensagem ..................................................................... 50 3.3.2.3 Estrutura da Mensagem ................................................................................ 54 3.3.2.4 Tabela de comandos ..................................................................................... 61

3.3.3 Digramas de comunicação ......................................................................... 62 3.3.3.1 Transmissão .................................................................................................. 62

3.3.3.2 Recepção ....................................................................................................... 64

3.3.4 Casos de comunicação .............................................................................. 65 3.3.4.1 Iniciação do robô .......................................................................................... 65 3.3.4.2 Mensagem com requisição de resposta ........................................................ 67

3.3.4.3 Mensagem de atuação do robô ..................................................................... 67

3.4 SISTEMA EMBARCADO ........................................................................... 69

3.4.1 Software Embarcado .................................................................................. 69 3.4.2 Webbotlib 1.31 ........................................................................................... 69

3.4.3 Inicialização do programa .......................................................................... 70 3.4.4 Funcionamento normal – visão geral ......................................................... 72

3.4.4.1 Controle ........................................................................................................ 73

3.4.4.2 Início da comunicação .................................................................................. 74 3.4.4.3 Tratamento de mensagens pós-sincronização com estação base .................. 75

3.4.4.4 Controle da rampa ........................................................................................ 78

3.4.5 Componentes ............................................................................................. 79 3.4.5.1 Regulador de tensão 7805............................................................................. 79 3.4.5.2 Regulador de tensão LM317......................................................................... 79

3.4.5.3 Xbee .............................................................................................................. 81 3.4.5.4 DIP Switch 2 vias de 5 bits ........................................................................... 84 3.4.5.5 Encoders ....................................................................................................... 84 3.4.5.6 Schmitt Trigger 74LS14 ............................................................................... 86 3.4.5.7 Opto acopladores 4N35 ................................................................................ 87

3.4.5.8 Ponte-H L298 ............................................................................................... 89

3.4.5.9 Bateria ........................................................................................................... 91

3.4.6 Placa de circuito impressa ......................................................................... 92 3.4.6.1 Visão geral das conexões da Camada 1 da PCI ............................................ 92 3.4.6.2 Visão geral das conexões da Camada 2 da PCI ............................................ 95 3.4.6.3 Esquemático das camadas enviado para a prototipação ............................... 97

4 CONCLUSÕES ........................................................................................ 100

4.1 ANÁLISE DO DESENVOLVIMENTO ....................................................... 100 4.1.1 Riscos Relevantes ................................................................................... 100

4.1.1.1 Atraso no recebimento de componentes pelos fornecedores ...................... 100

4.1.1.2 Problemas com a comunicação sem fio ...................................................... 101

viii

4.1.1.3 Custo real muito acima do custo estimado para o projeto .......................... 101 4.1.1.4 Impossibilidade de algum membro da equipe terminar o projeto .............. 101

4.1.1.5 Falta de tempo para conclusão do projeto .................................................. 102

4.1.2 Considerações finais sobre o desenvolvimento ....................................... 102

4.2 INTEGRAÇÃO ......................................................................................... 102 4.2.1 Controle.................................................................................................... 103

4.2.2 Sistemas Microcontrolados ...................................................................... 103 4.2.3 Comunicação de dados ........................................................................... 103 4.2.4 Eletrônica 2 .............................................................................................. 104 4.2.5 Análise e projeto de sistemas e Engenharia de Software ........................ 104

4.3 TRABALHOS FUTUROS ......................................................................... 104

4.3.1 Driblador e chutador ................................................................................. 105

4.3.2 Adição de sensores .................................................................................. 105

4.3.3 Microcontrolador ...................................................................................... 105 4.3.4 Inteligência artificial .................................................................................. 106 4.3.5 Comunicação ........................................................................................... 106

5 REFERÊNCIAS ....................................................................................... 107

6 ANEXOS .................................................................................................. 109

6.1 PLANEJAMENTO DE RISCO .................................................................. 109

6.2 GANT DE CARGA FINAL ........................................................................ 118

6.2.1 Gant Individual ......................................................................................... 118

ix

Lista de ilustrações

Figura 1: Omni¹ Fonte: (Nishibe, et al. 2010) ............................................................ 16

Figura 2: RoboFEI Fonte: (Tavares 2007). ............................................................... 18

Figura 3: Proposta de interface com o usuário da estação base. Fonte: Autoria própria. ..................................................................................... 23

Figura 4: L298. Fonte: (STMicroelectronics 2000) .................................................... 27

Figura 5: Características necessárias do microcontrolador. Fonte: Autoria própria. ................................................................................................. 28

Figura 6: Atmega328. Fonte: (ATMega328 28 pin DIP with Bootloader s.d.) ........... 29

Figura 7: Atmega640. Fonte: ( Lista de microcontroladores AVR s.d.) ..................... 30

Figura 8: Atmega2560. Fonte: ( Lista de microcontroladores AVR s.d.) ................... 30

Figura 9: Comparação Microcontroladores. Fonte: (Axon Microcontroller Description s.d.) (Arduíno Mega 2560 s.d.) .......................................... 32

Figura 10: Microcontrolador Axon. Fonte: (Axon Microcontroller Description s.d.) ...................................................................................................... 32

Figura 11: Arquitetura geral do sistema Fonte: Autoria Própria................................. 41

Figura 12: Diagrama de classes da Estação-Base Fonte: Autoria Própria ................ 42

Figura 13: Diagrama de atividades do algoritmo do buffer. Fonte: Autoria Própria .................................................................................................. 45

Figura 14: Estrutura dos comandos do parser. Fonte: Autoria Própria ..................... 46

Figura 15: Layout da interface gráfica. Fonte: Autoria Própria .................................. 47

Figura 16: Módulo Xbee Series 1 Fonte: (Digi International n.d.) .............................. 49

Figura 17: Estrutura do Frame Fonte: (MaxStream USA). ....................................... 51

Figura 18: Data Frame e estrutura específica de cada API Fonte: (MaxStream USA) ................................................................................ 51

Figura 19: TX Packet ( 16 bit address ) Fonte: (MaxStream USA) .......................... 52

Figura 20: Frame do TX Status Fonte: (MaxStream USA) ........................................ 53

Figura 21: Máquina de estados da transmissão de dados Fonte: (Kurpiel, et al. 2010) (Modificado) ........................................................................... 63

Figura 22: Diagrama de tratamento dos dados recebidos Fonte: (Kurpiel, et al. 2010) (Modificado). .......................................................................... 64

Figura 23: Troca de mensagens entre estação-base e robô, visão geral Fonte: Autoria Própria. ......................................................................... 65

Figura 24: Diagrama de atividades para iniciação do robô visto pelo robô Fonte: Autoria Própria .......................................................................... 66

Figura 25: Diagrama exemplo de uma requisição da leitura dos níveis de bateria Fonte: Autoria própria ............................................................... 66

x

Figura 26: Diagrama de atividades da resposta do robô em relação a mensagens de requisição de leitura de sensores. Fonte: Autoria própria ...................................................................................... 67

Figura 27: Diagrama de atividades do robô para o recebimento de uma mensagem do tipo atuadora. Fonte: Autoria Própria ............................ 68

Figura 28: Exemplo de envio de mensagem do tipo atuadora Fonte: Autoria própria .................................................................................................. 68

Figura 29: Visão do software para testes em alto nível. ............................................ 69

Figura 30: Sequência de comandos para inicialização do Firmware Fonte: Autoria própria ...................................................................................... 71

Figura 31: Visão geral do firmware, uma abordagem de alto nível Fonte: Autoria própria ...................................................................................... 72

Figura 32: Diagrama de controle Fonte: Autoria própria ........................................... 74

Figura 33: Diagrama que mostra o cadastro do firmware na visão do robô Fonte: Autoria própria ........................................................................... 75

Figura 34: Diagrama de resposta do firmware para o fluxo de decodificação de uma mensagem de atuação nos motores Fonte: Autoria Própria .................................................................................................. 76

Figura 35: Diagrama de resposta do firmware para o fluxo de resposta a uma solicitação da estação base. Fonte: Autoria própria ............................. 77

Figura 36: Rampa de descida. .................................................................................. 78

Figura 37: Projeto do regulador 7805 presente no datasheet. Fonte: (Fairchild 2001) .................................................................................... 79

Figura 38: Esquemático do LM317. Fonte: (National Semicondutor 1996). ............. 80

Figura 39: Divisor de tensão. Autoria própria. ........................................................... 82

Figura 40: Pinos do Xbee. Fonte: (MaxStream USA). .............................................. 83

Figura 41: Projeto de ligação do Xbee na PCI final. Fonte: Autoria própria. ............. 83

Figura 42: Esquema da chave ótica H22A1. Fonte: (Fairchild 2001) ........................ 85

Figura 43: Esquema de ligação da chave ótica do encoder na PCI. Fonte: Autoria própria ...................................................................................... 86

Figura 44: Esquemático e pinos do Optoacoplador 4N35. Fonte: (Fairchild 2001) .................................................................................................... 88

Figura 45: Projeto dos optoacopladores na PCI. Fonte: Autoria própria. .................. 88

Figura 46: Esquema de ligação das duas pontes-H do L298. Fonte: (STMicroelectronics 2000) ................................................................... 90

Figura 47: Ponte-H L298. Fonte: (STMicroelectronics 2000) .................................... 91

Figura 48: PCI provisória. Fonte: Autoria própria ...................................................... 92

Figura 49: Ligações da Camada 1 da PCI final. Fonte: Autoria própria. ................... 94

Figura 50: Ligações da camada 2 da PCI final. Fonte: Autoria própria ..................... 96

xi

Figura 51: Esquemático da camada 2 da PCI final enviada para prototipação. Fonte: Autoria própria. .......................................................................... 97

Figura 52: Camada 2 da PCI final antes de soldar. Fonte: Autoria própria. .............. 98

Figura 53: Camadas 1 e camada 2 sobrepostas. Fonte: Autoria própria. ................. 98

Figura 54: Esquemático da camada 1 da PCI final enviada para prototipação. Fonte: Autoria própria. .......................................................................... 99

Figura 55: Camada 1 da PCI final antes de soldar. Fonte: Autoria própria. .............. 99

Figura 56:João ........................................................................................................ 118

Figura 57:Fábio ....................................................................................................... 118

Figura 58:Ari 119

Figura 59:Eduardo ................................................................................................... 119

xii

Lista de tabelas

Tabela 1: Requisitos do robô. Fonte: Autoria própria. ............................................... 21

Tabela 2: Requisitos do da comunicação. Fonte: Autoria própria. ............................ 22

Tabela 3: Requisitos da estação base. Fonte: Autoria própria. ................................. 22

Tabela 4: Tabela de comparação de alternativos de comunicação sem fio. Fonte: (Software technologies, group 2009) ........................................ 25

Tabela 5: Gastos com recursos humanos. Fonte: Autoria própria. ........................... 35

Tabela 6: Orçamento real. Fonte: Autoria própria. .................................................... 36

Tabela 7: Cronograma. Fonte: autoria própria. ......................................................... 38

Tabela 8: Entregáveis. Fonte: Autoria propria. .......................................................... 39

Tabela 9: Auxiliares de gerenciamento. Fonte: Autoria própria. ................................ 39

Tabela 10: Formato padrão de mensagem Fonte: Autoria própria ............................ 50

Tabela 11: Baud Rate para valores de BD Fonte: Autoria Própria ............................ 54

Tabela 12: Estrutura da mensagem Fonte: Autoria Própria ...................................... 55

Tabela 13: Estrutura de uma mensagem de andar para frente (0x26) Fonte: Autoria Própria ..................................................................................... 55

Tabela 14: Estrutura de uma mensagem de ir para frente (0x27) Fonte: Autoria Própria ..................................................................................... 56

Tabela 15: Estrutura de uma mensagem de girar no sentido horário (0x28) Fonte: Autoria Própria .......................................................................... 57

Tabela 16: Estrutura de uma mensagem de girar anti-horário (0x29) Fonte: Autoria Própria ..................................................................................... 57

Tabela 17: Estrutura da mensagem para o movimento em uma direção Fonte: Autoria Própria ..................................................................................... 58

Tabela 18: Estrutura de mensagem para ligar/desligar driblador Fonte: Autoria Própria ..................................................................................... 58

Tabela 19: Estrutura de mensagem para acionar o chutador Fonte: Autoria própria .................................................................................................. 59

Tabela 20: Estrutura de mensagem para solicitar leitura de sensores Fonte: Autoria Própria ..................................................................................... 59

Tabela 21: Estrutura de mensagem de resposta de leitura de sensores Fonte: Autoria própria ...................................................................................... 59

Tabela 22: Estrutura de mensagem para solicitação de cadastro na estação base Fonte: Autoria própria .................................................................. 60

Tabela 23: Estrutura de mensagem para inclusão de um robô em uma estação central. Fonte: Autoria Própria ................................................ 60

xiii

Tabela 24: Estrutura de mensagem para confirmação de dispositivo ativo Fonte: Autoria Própria .......................................................................... 61

Tabela 25: Estrutura de mensagem para um ACK Fonte: Autoria Própria ................ 61

Tabela 26: Tipos de comandos Fonte: Autoria própria .............................................. 62

Tabela 27: Controle PID básico. Fonte (Controle PID básico, UFSC s.d.). ............... 73

xiv

ABREVIATURAS

Sigla Significado

ACK

API

LED

LSB

MSB

NACK

PID

PCI

PWM

Acknowledge

Application Programming Interface

Light Emitting Diode

Least Significant Bit

Most Significant Bit

No Acknowledge

Proportional Integral Derivative

Placa de Circuito Impresso

Pulse Width Modulation

RF

RSSI

RX

SMD

TX`

UART

Radio Frequency

Received Signal Strength Indication

Receive

Surface Mount Device

Transmit

Universal Asynchronous Receiver Transmitter

UTFPR Universidade Tecnológica Federal do Paraná

USB

IR

I/O

Universal Serial Bus

Infrared rays

In/out

15

1 INTRODUÇÃO

O projeto consiste no desenvolvimento de um sistema capaz de controlar

robôs através do envio de comandos sem-fio por uma estação-base instalada em um

computador.

1.1 MOTIVAÇÃO

A escolha por esse projeto foi motivada inicialmente pelo desejo da

universidade em participar de competições de futebol de robôs com um projeto

completamente desenvolvido por alunos da própria universidade. No momento do

inicio do desenvolvimento do projeto, a universidade competia com robôs comprados

de uma empresa especializada e somente era responsável pela programação da

inteligência do robô. Visando eliminar essa dependência de tecnologia externa, foi

proposto que a equipe desenvolvesse um projeto que englobasse os aspectos de

hardware, comunicação e software dos robôs, projeto esse que seria acoplado à

atual mecânica dos robôs, em detrimento da tecnologia comprada anteriormente.

1.2 TRABALHOS CORRELATOS

O projeto proposto tem características muito similares à diversos outros

projetos desenvolvidos, inclusive dentro da própria UTFPR (Universidade

Tecnológica Federal do Paraná), e por esse motivo o estudo de trabalhos correlatos

é muito importante, pois pode poupar a equipe de fazer escolhas equivocadas.

1.2.1 Omni¹

O primeiro projeto analisado foi o robô Omni¹, cuja proposta foi muito similar a

nossa, sendo a principal diferença o tamanho dos robôs em questão. O projeto

Omni¹ consiste em uma plataforma mecânica com 3 rodas com motores dispostas

de maneira a conseguir movimento omnidirecional, um hardware embarcado capaz

de acionar os motores, receber informações dos sensores em cada roda e assegurar

que o sistema seria capaz de receber e interpretar comandos enviados de maneira

sem fio pela estação-base. (Nishibe, et al. 2010)

16

Figura 1: Omni¹ Fonte: (Nishibe, et al. 2010)

A equipe que desenvolveu o projeto Omni¹ optou por utilizar a linguagem Java

para desenvolver a estação-base, opção essa que também foi analisada pela

equipe. Uma vez que eles obtiveram sucesso utilizando Java, pode-se reforçar a

convicção de que utilizar a mesma tecnologia seria suficiente para atender aos

requisitos desse projeto também.

O grande aprendizado que pôde ser extraído do estudo de caso do Omni¹ foi

sem dúvida a questão da expansibilidade. O projeto atendeu aos requisitos aos

quais ele se propôs, no entanto o microprocessador escolhido para o sistema

embarcado deixava uma margem para expansões muito reduzida, de modo que boa

parte do trabalho desenvolvido se perdeu no desenvolvimento do projeto Omni², que

será detalhado a seguir. Tendo em vista esse erro de projeto cometido pela equipe

do robô Omni¹, foi considerado sempre nas decisões desse projeto a questão da

expansibilidade, de modo que uma equipe possa posteriormente dar continuidade ao

robô com o mínimo de “retrabalho” possível.

17

1.2.2 Omni²

O segundo trabalho correlato analisado foi justamente o projeto Omni², que

aprimorou o robô do projeto Omni¹ de modo a utilizar uma bússola e sensores de

distância, bem como aprimorar outros aspectos não abordados. O microcontrolador

teve que ser alterado devido à falta de capacidade de expansibilidade no primeiro

microcontrolador PIC utilizado. A equipe do robô Omni² optou por utilizar um

microcontrolador Arduino Mega, que tem capacidade de processamento mais do que

suficiente para atender aos requisitos, bem como grande capacidade de

interfaceamento com periféricos e ports de entrada e saída. O microcontrolador

escolhido pela equipe pertence à mesma família do Arduino Mega, sendo a única

diferença entre eles o acesso aos periféricos e a dimensão da placa em que o chip

está acomodado. Como a dimensão do robô a ser desenvolvido é inferior à

dimensão dos dois robôs Omni, optamos por um microcontrolador acomodado em

uma placa menor. (KURPIEL, NASCIMENTO, HIGASKINO, & COSTA, 2010).

1.2.3 RoboFEI

Por fim, o último artigo analisado foi resultado de um projeto de iniciação

científica desenvolvido pelo aluno Fernando Perez Tavares no Centro Universitário

da FEI. Esse projeto difere desse pelo fato de se basear em um robô omnidirecional

de 4 rodas, no entanto boa parte da pesquisa desenvolvida por esse artigo pode ser

aproveitada no desenvolvimento do robô proposto. Vale lembrar que esse artigo

trata do desenvolvimento de um robô omnidirecional incluindo toda a parte

mecânica, sendo que no caso desse projeto a base mecânica já está pronta e cabe

a equipe somente desenvolver o hardware e o software responsável por comandar o

robô.

18

Figura 2: RoboFEI Fonte: (Tavares 2007).

1.3 OBJETIVOS

O projeto proposto tem como objetivo desenvolver um sistema composto por

hardware e software para controlar um robô capaz de competir em campeonatos de

futebol de robôs.

O sistema pode ser dividido em 3 subsistemas, sendo eles o sistema

embarcado, o sistema de comunicação e o sistema da estação-base, cada qual com

seus objetivos e requisitos específicos.

A estação-base deve ser capaz de enviar comandos para o robô através de

uma interface gráfica e deve controlar quais robôs estão aptos a receber instruções.

Ela também deve possuir um framework de modo que uma inteligência artificial

possa executar acoplada a ela enviando os comandos aos robôs.

O sistema de comunicação deve ser capaz de enviar os comandos de modo

sem fio para os robôs e garantir que todos os robôs recebam seus respectivos

comandos, bem como garantir que não haja conflitos de comunicação.

19

O sistema embarcado deve ser capaz de interpretar os comandos recebidos e

acionar os componentes eletrônicos necessários para executar o comando enviado

pela base.

20

2 PLANEJAMENTO

2.1 DECLARAÇÃO DO ENCOPO EM ALTO-NÍVEL

O sistema embarcado conterá um microcontrolador o qual possuirá um

firmware para controle do robô, um sistema de comunicação sem fio com o

computador (estação base) que possuirá um software de controle de velocidade e

posição dos robôs, capaz de movimentar-los, para frente e para trás, além de

rotações no sentido horário e anti horário.

2.2 PREMISSAS E RESTRIÇÕES

Deixa-se claro que com o término do projeto ainda não será possível a

participação de nosso robô nos jogos de futebol de robôs, pois o “chutador” e o

“prendedor de bola” ou também chamado de “driblador” não serão implementados

no projeto, entretanto ele será construído de modo que futuramente outros projetos o

aprimorem incluindo novas funcionalidades.

Estará disponível a nossa equipe a base mecânica do robô que contém

motores, encoders, rodas, e baterias já instaladas além de um espaço físico dentro

do robô para a alocação do sistema a ser construído. Ela não será construída pois a

tempo que seria gasto na etapa de planejamento e construção da mesma seria

demasiadamente grande para prejudicar o decorrer do projeto. Considera-se que o

local onde o robô será utilizado não contenha imperfeições e seja adequado para a

roda utilizada além de que ele esteja dentro do alcance máximo do sistema de

comunicação e que exista um computador disponível para que o software da

estação base seja executado. Além desses aspectos do projeto considera-se que

não haja atraso de entrega de componentes quando estivermos no período de

implementação.

O microcontrolador deverá conter pinos de I/O sobrando afim de proporcionar

futuras implementações como o “driblador” e “chutador”. O protocolo deverá ter além

de comandos específicos do robô desse projeto que não é omnidirecioal deverá

possuir suporte para robôs omnidirecionais.

21

A opção tecnológica escolhida não deve ultrapassar o orçamento

preestabelecido, a não ser que seja realmente necessário. O tempo de execução do

projeto não pode exceder e para que não haja imprevistos durante o decorrer do

cronograma bem como imperfeições é necessário que o cronograma seja seguido

de modo mais fiel possível, pois não há tempo de folga entre os prazos.

2.3 DESIGNAÇÃO DO GERENTE E DA EQUIPE

Gerente: Ari Magagnin Junior

Colaboradores: Eduardo Cabral Resende Neiva, João Hamilton Cecato Simas

2.4 PLANEJAMENTO DE RISCOS

Os relatórios com os planos de resposta ao risco são apresentados em

anexo.

2.5 REQUISITOS

1. Requisitos do robô:

Requisitos – Robô Especificação – Robô

Se locomover com dois graus de liberdade em um plano.

Possuir três rodas com discos pequenos em torno da circunferência que são perpendiculares à direção de laminação para, acopladas em motores DC, que possam ser acionados nas duas direções através de um circuito de ponte-H.

Locomover-se com velocidade e aceleração controlada numa direção dada e por uma distância pré-determinada.

Os motores serão controlados por PWM com realimentação através dos encoders para o sistema de controle Proporcional-Integral derivativo.

Medir a distância percorrida. Calibrar os encoders de forma a conhecer a distância percorrida em determinada direção.

Ser alimentado com baterias. Alimentar os motores utilizando dois bancos de pilhas AA e o microcontrolador será alimentado por uma bateria separada de 9V para evitar interferência por indução dos motores.

Tabela 1: Requisitos do robô. Fonte: Autoria própria.

2. Requisitos da comunicação:

22

Requisitos - Comunicação Especificação – Comunicação

Comunicar-se com a base por meio de um sistema sem fio.

Utilizar um equipamento que permita comunicação bidirecional com um alcance mínimo de 20 metros.

Garantir a integridade dos pacotes recebidos pela base.

Especificar um protocolo que permita a detecção de erros e contemple reenvio de pacotes perdidos.

Baixo consumo de energia. A alimentação do sistema de comunicação deve ser inferior a 9V e deve consumir a menor energia possível de modo a garantir uma boa autonomia do robô.

O sistema de comunicação deve possuir uma taxa de transferência mínima para suportar o protocolo.

O sistema de comunicação deve ser capaz de transferir no mínimo 50kbps.

Tabela 2: Requisitos do da comunicação. Fonte: Autoria própria.

3. Requisitos da estação base:

Requisitos – Estação Base Especificação – Estação Base

A estação base deve ser capaz de controlar 5 robôs.

O sistema de comunicação e a interface devem ser capazes de controlar até cinco robôs e garantir a integridade de informação para todos eles.

A estação base deve ser capaz de enviar comandos de movimento e direção para os robôs

Cada comando enviado pela base para cada robô deve consistir em uma direção e uma distância a ser percorrida, de modo que o próprio robô faça uso de seu sistema de controle para executar o comando.

Tabela 3: Requisitos da estação base. Fonte: Autoria própria.

Existem ainda outros requisitos não funcionais, que proporcionam maior

flexibilidade ao desenvolvimento do projeto, bem como ao produto final:

1. Interface gráfica de fácil manuseio;

2. Multiplataforma;

3. Orientada a objetos;

4. Ferramentas de desenvolvimento de boa qualidade e sem custo.

23

2.6 ALTERNTIVA TECNOLÓGICA

2.6.1 Estação base

A estação base consiste em um computador com uma plataforma capaz de

executar a linguagem escolhida. A interface com o usuário proposta é mostrada na

Figura 3. A interface consiste em alguns campos, como o de “seleção” do robô que

executará o comando e um campo de informações do comando que será executado.

Ainda existe outro campo em que o usuário mandará uma linha de comando

preestabelecida para do robô.

Figura 3: Proposta de interface com o usuário da estação base. Fonte: Autoria própria.

2.6.2 Linguagem de programação

2.6.2.1 JAVA

A primeira linguagem de programação a ser estudada é a Java. Esta

linguagem tem suporte extensivo à comunicação serial através de bibliotecas,

ajudando a concluir um dos requisitos necessários. Ela também possibilita que seja

24

desenvolvido um framework com todas as sub-rotinas de comunicação com o robô,

de modo que um próximo projeto (por exemplo, construir a inteligência do robô)

bastaria apenas estudar a documentação do framework desenvolvido pelo grupo,

desenvolvendo seu trabalho em cima deste framework.

A plataforma Java possui um ambiente de desenvolvimento muito poderoso e

de custo zero, chamado Netbeans (NetBeans 2011). Ambiente este que também

possibilita o desenvolvimento de interfaces gráficas de maneira muito simples,

facilitando no processo de construção e demonstração do produto final. Outras

características importantes da plataforma Java são os fatos de ser totalmente

orientada a objetos e funcionar em diversos sistemas operacionais, como por

exemplo: Windows, Linux e Mac OS.

Dessa forma a linguagem Java foi escolhida uma vez que essa opção atende

ao requisito mais importante, e possui aspectos que permite um desenvolvimento

significativo da estação.

2.6.2.2 C

A linguagem de programação C atende aos requisitos primários do projeto,

que são comunicação serial e possibilidade de desenvolver framework. No entanto,

ela tem algumas limitações que podem dificultar o desenvolvimento do projeto e

prejudicar o produto final.

Essas limitações são principalmente os fatos de não ser orientada a objeto,

dificultando o desenvolvimento, organização e documentação dos códigos-fonte. Ela

também não é multiplataforma, ou seja, compilando o código em uma plataforma,

por exemplo, no Windows, resulta em um programa que não pode ser utilizado em

outras plataformas, como, por exemplo, no Linux. Com relação às ferramentas de

desenvolvimento, existem opções sem custos, mas com sérias limitações – como,

por exemplo, o Dev C++ - e opções com custo alto, que são excelentes ambientes

de desenvolvimento, por exemplo, Visual Studio.

25

2.7 SISTEMA DE COMUNICAÇÃO

O sistema de comunicação será responsável por conectar o computador a

vários robôs. Dentre os sistemas mais utilizados, é citado as principais

características de cada um na e compará-las com os requisitos necessários ao

projeto, eliminando as tecnologias não cabíveis.

ZigBee 802.11 ( Wi-Fi ) Bluetooth IR Wireless

Velocidade de

transmissão de

dados

20, 40 e 250

Kbits/s 11 e 54 Mbits/sec 1 Mbits/s

20-40 Kbits/s

115 Kbits/s

4 Mbits/s

Alcance 10 - 100 metros 50 - 100 metros 10 metros < 10 metros

(linha de visão)

Topologia de

rede

Ad-hoc, peer to

peer ou mesh Ponto até hub

Ad-hoc, redes

muito pequenas Ponto a Ponto

Complexidade Baixa Alta Alta Baixa

Consumo de Energia

Muito baixo Alto Médio Baixo

Tabela 4: Tabela de comparação de alternativos de comunicação sem fio. Fonte:

(Software technologies, group 2009)

Por se tratar de um sistema com fornecimento de energia limitada (uso de

baterias), utilizar uma tecnologia de comunicação de baixo consumo é uma boa

alternativa. Entre as tecnologias expostas acima temos ZigBee e IR (comunicação

através de raios infra-vermelho) como opções de baixo consumo. Enquanto as

demais alternativas também podem ser usadas, elas não são recomendadas devido

ao seu consumo de energia.

Considerando o alcance como um fator limitante, o alcance mínimo em uma

partida da Robocup F180 é de 4 metros, tornado todas as tecnologias viáveis.

Entretanto a IR Wireless exige que os sistemas que se comunicaram estejam em

sua linha de visão que ambos “enxergam”, o que nem sempre pode acontecer. Este

fator impossibilita a utilização do IR Wireless como tecnologia de transmissão.

26

Outro fator importante a ser tratado é o impacto da tecnologia no projeto, já

que quanto maior a complexidade, maior será o tempo gasto na comunicação, algo

que como já analisado pode prejudicar o desenvolvimento do projeto. Esse fator é o

que torna a comunicação Wi-Fi e Bluetooth opções pouco interessantes, ao contrário

do ZigBee, que é de baixa complexidade.

O ZigBee, então, é a escolha que mais se ajusta ao projeto, além disso já foi

usados em trabalho dos semestres anteriores e apresentou bons resultados.

2.8 SISTEMA EMBARCADO

O sistema eletrônico do robô possui uma variedade de componentes e

dispositivos a serem analisados, entretanto apenas foi feito um estudo dos

componentes mais críticos descritos nos itens que seguem.

27

2.8.1 Ponte-H

O papel da ponte H no sistema embarcado é possibilitar a movimentação dos

motores em ambos os sentidos, com controle de velocidade.

2.8.1.1 Ponte-H utilizando componentes discretos

Ao invés de utilizar um CI pronto, pode-se montar uma ponte-H com

componentes discretos. Para isto deve-se utilizar transistores que suportem corrente

de 2 [A] e tensão de 16 [V] e outros componentes passivos que suportam tais

requisitos que existem no mercado.

2.8.1.2 L298N

Componente eletrônico utilizado para controle de motores DC. Possui boa

disponibilidade no mercado local e seu preço gira em torno de R$13,00. Pode ser

utilizada alimentação de até 46 [V] (sendo que a bateria usada é de 16V) e com

corrente máxima de até 2 [A], o que está atende as determinações do projeto.

Figura 4: L298. Fonte: (STMicroelectronics 2000)

2.8.1.3 Comparação e escolha da ponte-H

A utilização do L298 atende os requisitos do projeto além de ocupar menos

espaço na PCI, alem disso possui um circuito de proteção de curto internamente. Já

a ponte-H com componentes discretos pode atender os requisitos se utilizado os

componentes adequados, além de ocupar tempo para a montagem do circuito e não

possuir proteção contra curto a não ser que se faça uma sofisticação no circuito.

28

Tais fatores foram preponderantes a ser considerado na escolha de uma tecnologia.

Dessa forma foi tornado como melhor opção tecnológica a ponte-H L298N.

2.9 MICROCONTROLADOR

Para controlar o robô, o microcontrolador deve possuir algumas

características:

Mínimo

Saídas PWM 5

Timers 3 (Liberados)

Pinos I/O livres 12

Suporte para expansibilidade UART, SPI ou I2C

Figura 5: Características necessárias do microcontrolador. Fonte: Autoria própria.

2.9.1 Atmega328

Microcontrolador conhecido utilizado no Arduino Uno. Esta plataforma possui

um conector USB que permite acesso a qualquer computador moderno. Sua

programação é feita a partir de uma linguagem própria, chamada Wiring, o que

facilita a gravação de programas. A equipe já possui um dispositivo desse, o que

reduz os custos.

Não atende aos requisitos do projeto, pois possui apenas 2 timers disponíveis

e não possui terminais suficientes de I/O.

29

Figura 6: Atmega328. Fonte: (ATMega328 28 pin DIP with Bootloader s.d.)

2.9.2 DSPIC30F3010

O dsPic30F30 é caracterizado por se um microcontrolador de arquitetura

RISC que possui algumas características de DSP. Possui 6 saídas PWM, interface

UART, três interrupções externas e multiplicação por hardware em um ciclo de clock

alem de interfaceamento serial. (Microchip, 2005)

Em um projeto passado, esse microcontrolador foi utilizado com sucesso.

Entretanto, pela falta de terminais de I/O acabou não possibilitando futuras

expansões.

Não atende aos requisitos do projeto pela falta de terminais, inviabilizando um

projeto onde a expansibilidade é um dos requisitos.

2.9.3 Atmega 640

O microcontrolador Atmega640 é um modelo da Atmel que é conhecido

por ser utilizado no Axon. Possui interfaceamento USB e a programação é feita por

meio do AVR Studio. Possui 6 timers, 55 terminais de entrada e saída e 64 kB de

memória interna.

30

Figura 7: Atmega640. Fonte: ( Lista de microcontroladores AVR s.d.)

2.9.4 Atmega2560

O microcontrolador Atmega2560 é o mais potente da categoria compatível

com o Arduino, sendo que possui 54 terminais - 14 com possibilidade de PWM, e

uma memória interna de 256KB. Sua programação também é feita em Wiring e

possui interfaceamento USB. Ao contrário do Atmega328, esse microcontrolador só

possui versão SMD.

Figura 8: Atmega2560. Fonte: ( Lista de microcontroladores AVR s.d.)

31

2.9.5 C8051F340

O microcontrolador da Silicon Labs possui 64 kB de flash, 4 kB de memória

interna e opera a 48 MHz, executando 48 MIPS. Possui também 40 portas de I/O e 4

Timers. Ele é baseado na arquitetura 8051, diferentemente dos outros

microcontroladores analisados, que são baseados na arquitetura AVR. A grande

desvantagem é a dimensão da placa, a qual é muito grande devido a extensa

quantidade de periféricos encontrados nesse microcontrolador. Assim, não é

possível acomodá-lo na estrutura do robô, inviabilizando a utilização deste

microcontrolador no projeto.

2.9.6 Comparação e escolha do microcontrolador

Descartando os microcontroladores que não possuem os requisitos

necessários sobram apenas dispositivos SMD. Isso acaba exigindo a compra de um

kit de desenvolvimento, pois a equipe não possui conhecimento suficiente para

soldar SMD e a aquisição de uma PCI com complexidade para SMD não é de fácil

acessibilidade ao grupo também.

É fato que ambos os kits de desenvolvimento possuem as características

necessárias para o desenvolvimento do projeto, sendo que as principais diferenças

consistem no Arduino Mega possuir quatro vezes mais memória que o Axon

(indiferente para o projeto) e o Axon ocupar uma área de superfície 21% menor. Foi

escolhido então o Axon por possuir todos os pinos de PWM disponíveis para uso –

problema enfrentado por projetos anteriores - e ser de tamanho reduzido, permitindo

um melhor aproveitamento do espaço interno do robô.

Arduino Mega Axon

Pinos I/O Digitais 54 55

PWM 14 9

Memória Interna 256 [KB] 64 [KB]

Pinos analógicos 16 16

Consumo 40mA 40mA

Timers 6 6

Velocidade do Clock 16Mhz 16Mhz

32

Figura 10: Microcontrolador Axon. Fonte: (Axon Microcontroller Description s.d.)

2.10 ORÇAMENTO INICIAL DETALHADO PREVISTO

Na primeira tabela encontram-se os custos de materiais necessários para que

haja início do projeto.

Dimensões 10,1cm*5,3cm*1,36cm 6,54cm*6,54cm*1,99cm

I2C 1 1

SRAM 8 [KB] 8 [KB]

EEPROM 4 [KB] 4 [KB]

UART 3 3

Familiaridade Alta Baixa

Custo U$65,00 U$95,00

Figura 9: Comparação Microcontroladores. Fonte: (Axon Microcontroller Description

s.d.) (Arduíno Mega 2560 s.d.)

33

Custo de material

Quantidade Material Preço por unidade Total

1 Axon 1 R$ 161,50 R$ 161,50

3 L298 R$ 10,88 R$ 32,64

2 Xbee chip antena R$ 39,02 R$ 78,03

1 Xbee Explorer R$ 42,42 R$ 42,42

3 Chave Ótica H22A1 R$ 4,50 R$ 13,50

5 Optoacopladores R$ 1,50 R$ 7,50

1 PCI de teste R$ 10,00 R$ 10,00

Custo dos fretes

1 Frete R$ 90,00 R$ 90,00

Total dos

Custos

R$ 435,59

Do orçamento inicial planejado a ser gasto com materiais, ainda sobra

R$201,41 para ser gastos nos componentes e na placa PCI a ser projetada.

O orçamento das atividades segue mostrado na Tabela 5: Gastos com

recursos humanos. Fonte: Autoria própria.Tabela 5 que refere-se as horas de

trabalhos dos envolvidos no projeto.

Gastos em recursos humanos Custo

Execução R$ 8.604,00

Estudo R$ 1.692,00

Microcontrolador R$ 1.260,00

Ponte H R$ 1.008,00

Encoders+motor R$ 1.152,00

Optoacoplador R$ 1.152,00

Xbee R$ 720,00

Compra dos componentes R$ 720,00

34

Compra Microcontrolador R$ 144,00

Compra Xbee R$ 144,00

Compra Optoacoplador R$ 144,00

Compra ponte H R$ 144,00

Compra Encoders reserva R$ 144,00

Compra PCI de teste R$ 144,00

Testes iniciais R$ 2.592,00

Encoder R$ 144,00

Documentação [Encoder] R$ 144,00

Ponte H R$ 144,00

Documentação [Ponte H] R$ 144,00

Motor DC R$ 144,00

Documentação [Motor DC] R$ 90,00

Xbee R$ 288,00

Documentação [xbee] R$ 144,00

Optoacoplador R$ 288,00

Documentação [Optoacoplador] R$ 90,00

Implementação R$ 6.192,00

Diagrama esquemático R$ 216,00

Ponte H + Controle R$ 936,00

Análise [Ponte H + Controle] R$ 288,00

Desenvolvimento [Ponte H + Controle] R$ 504,00

Documentação [Ponte H + Controle] R$ 144,00

Motor DC R$ 1.008,00

Análise [Motor DC] R$ 288,00

Desenvolvimento [Motor DC] R$ 576,00

Documentação [Motor DC] R$ 144,00

Encoder + Controle R$ 864,00

Análise [Encoder + Controle] R$ 144,00

Desenvolvimento [Encoder + Controle] R$ 576,00

Documentação [Encoder + Controle] R$ 144,00

Xbee R$ 2.016,00

Análise [Xbee] R$ 288,00

Desenvolvimento [Xbee] R$ 1.296,00

Documentação [Xbee] R$ 144,00

Optoacoplador R$ 864,00

Análise [Optoacoplador] R$ 144,00

Desenvolvimento [Optoacoplador] R$ 576,00

Documentação [Optoacoplador] R$ 144,00

Testes circuitos R$ 3.312,00

Teste sem Xbee R$ 288,00

Teste com Xbee R$ 144,00

Análise [Testes do circuito] R$ 198,00

Desenvolvimento [Testes do circuito] R$ 288,00

35

Documentação [Testes do circuito] R$ 144,00

Placa de circuito impresso [PCI] R$ 576,00

Análise [PCI] R$ 144,00

Desenvolvimento [PCI] R$ 288,00

Documentação [PCI] R$ 126,00

Programação R$ 4.752,00

Estação base R$ 864,00

Encoder R$ 432,00

Xbee R$ 1.008,00

Controle R$ 720,00

Integrar módulos R$ 1.008,00

Documentação Parcial [Software] R$ 576,00

Verificação e testes R$ 288,00

Teste comunicação+locomoção+base R$ 144,00

Ajustes finais R$ 144,00

Documentação R$ 11.448,00

Documentação Final [Software] R$ 3.663,36

Redigir monografia R$ 7.784,64

Criar apresentação R$ 72,00

Gerenciamento fase 1 R$ 1.584,00




TOTAL R$ 26.532,00

Tabela 5: Gastos com recursos humanos. Fonte: Autoria própria.

2.11 ORÇAMENTRO DETALHADO GASTO

O orçamento detalhado gasto no projeto encontra-se na Tabela 6.

Orçamento Quantidade Custo Custo Total

impressão monografia - previsão 1 R$ 30,00 R$ 30,00

impressão project charter 2 R$ 1,50 R$ 3,00

LN298 6 R$ 9,90 R$ 59,40

LM7805 4 R$ 1,52 R$ 6,08

LM7812 4 R$ 3,12 R$ 12,48

PCI padrão 1 R$ 14,10 R$ 14,10

Barras de pinos 6 R$ 2,20 R$ 13,20

2 Dip 5 vias 2 R$ 1,50 R$ 3,00

Dissipadores 6 R$ 1,50 R$ 9,00

Micas 1 R$ 2,10 R$ 2,10

36

Placa do Xbee xbeestore 1 R$ 17,89 R$ 17,89

Conectores KK 1 R$ 12,00 R$ 12,00

Cabos flat 1 R$ 20,40 R$ 20,40

74LS14 2 R$ 3,80 R$ 7,60

4N35 12 R$ 0,59 R$ 7,08

Socket 6 pinos 18 R$ 0,50 R$ 9,00

Socket 14 pinos 1 R$ 1,00 R$ 1,00

Solda - estanho 1 R$ 6,00 R$ 6,00

Resistores 1 R$ 5,00 R$ 5,00

Capacitores 1 R$ 2,00 R$ 2,00

Diodos 1 R$ 3,00 R$ 3,00

LED 4 R$ 0,20 R$ 0,80

Pilha 9v 1 R$ 9,00 R$ 9,00

Axon + frete + imposto 1 R$ 251,40 R$ 251,40

2 Xbee + Xbee Explorer + frete 1 R$ 163,20 R$ 163,20

PCI 1 R$ 180,00 R$ 180,00

Atmega 1 R$ 20,00 R$ 20,00

Total R$ 867,73

Tabela 6: Orçamento real. Fonte: Autoria própria.

2.12 CRONOGRAMA

Na Tabela 7 é mostrado o cronograma feito com a utilização do software

OpenProj indicado pelos professores da disciplina.

38

Tabela 7: Cronograma. Fonte: autoria própria.

39

2.13 ENTREGÁVEIS

Data ENTREGÁVEL

28/04/11 1. Projeto do software que vai rodar na estação base (Interface usuário).

2. Teste com o encoder (Dados)

12/05/11 1. Demonstração da locomoção do robô rudimentar (apenas movimentos de rotação, na horizontal e vertical) com um cabo ligando o Robô a base (PC).

26/05/11 1. Demonstração básica da comunicação sem fio com o Xbee (Hello world).

2. Demonstração do Software da estação base.

09/06/11 1. Robô capaz de responder comandos mandados pela base (Comandos de direção e distância a se deslocar).

2. Demonstração do projeto da PCI da ponte-H.

Tabela 8: Entregáveis. Fonte: Autoria propria.

2.14 AUXILIARES DE GERENCIAMENTO

A cada fase de execução do projeto foi determinado um auxiliar de

gerenciamento (sub-gerentes) conforme determinado pelos professores da matéria

de Oficinas de Integração 3, esse auxiliar deve ser um membro da equipe do projeto.

A apresenta os nomes dos auxiliares a fase a qual ele vai auxiliar.

Fase Auxiliar de gerenciamento

1 Eduardo Cabral Resende Neiva

2 Fábio César Schuartz

3 João Hamilton Cecato Simas

4 Eduardo Cabral Resende Neiva

Tabela 9: Auxiliares de gerenciamento. Fonte: Autoria própria.

41

3 EXECUÇÃO

3.1 ARQUITETURA GERAL DO HARDWARE E SOFTWARE

A disposição geral dos componentes dentro do sistema bem como as

interligações entre eles estão delineadas no diagrama da Figura 11.

Figura 11: Arquitetura geral do sistema Fonte: Autoria Própria

Os comandos enviados pelo usuário do sistema, seja ele um ser humano ou

uma inteligência artificial, são interpretados pelo software da estação base,

formatados de acordo com o protocolo de comunicação, enviados para os módulos

Xbee remotos, desempacotados e interpretados pelo firmware para finalmente

atuarem no hardware do robô de modo a executar fisicamente o comando recebido.

42

3.2 ESTAÇÃO-BASE

O sistema da estação-base é aquele que é responsável por interfacear com

usuários humanos, através da interface gráfica, ou com uma inteligência artificial,

através do framework e do parser, e formatar os comandos recebidos para que eles

sejam enviados através do sistema de comunicação e o robô os execute com

sucesso. O software da estação-base foi desenvolvido conforme a modelagem da

Figura 12.

Figura 12: Diagrama de classes da Estação-Base Fonte: Autoria Própria

3.2.1 Framework

O Framework é a parte do software responsável por controlar a comunicação

com os diversos robôs conectados à base, bem como prover acesso padronizado às

43

funcionalidades do sistema para um usuário, seja ele uma inteligência artificial,

através do parser, ou um ser humano, através da interface gráfica.

Em uma primeira analise do diagrama de classes, pode-se ver um grande

pacote chamado framework, que contém as classes desenvolvidas para modelar o

problema proposto, e outro pacote chamado xbeeapi que contém as classes

pertencentes à biblioteca xbeeapi que são utilizadas pelo framework.

A classe Robô é aquela responsável por modelar os aspectos relevantes do

Robô do ponto de vista da estação-base. O atributo mais importante é o endereço

do Xbee acoplado ao robô, pois ele irá garantir que os comandos enviados pela

base sejam executados pelo robô correto. Esse atributo é modelado pela classe

XbeeAddress16 da própria biblioteca xbeeapi, que é basicamente um número de 16

bits que identifica cada módulo Xbee. Há também um atributo nome que possibilita

que cada robô seja identificado por uma String escolhida pelo usuário. Quanto aos

métodos disponibilizados por essa classe, temos 5 métodos que basicamente

enviam comandos de movimentação para o Robô em questão, sendo eles forward(),

backward(), rotateRight(), rotateLeft() e moveOmni(). O construtor da classe Robô

necessita dos 2 bytes de endereço e do nome específico desse Robô, no entanto

esses parâmetros podem ser alterados posteriormente através dos métodos

disponibilizados. Há também o método getData() que solicita ao Robô o envio de

informações, como por exemplo, carga da bateria.

A classe Payload representa um vetor de bytes a ser enviado para um Robô

remoto, incluindo já os bytes de controle como header e trailer e também com o

comando a ser enviado já codificado em bytes conforme definido pelo protocolo. O

método mais importante dessa classe é o getPayload(), que retorna um vetor de

bytes, com o comando já codificado, a ser enviado pelo método sendSynchronous()

da classe Xbee.

Para tratar o recebimento de pacotes do Robô, foi desenvolvida a classe

MyPacketListener que implementa a interface PacketListener. Um objeto dessa

classe é cadastrado como listener no Xbee da estação-base, de modo que toda vez

44

que um novo pacote é recebido na estação-base é disparado o método

processResponse() que irá tratar adequadamente o pacote recebido.

A classe mais importante do framework é sem dúvida a classe

CommunicationsHandler. Essa classe gerencia toda a parte de configuração do

Xbee, bem como a implementação do buffer de saída. Para enviar um pacote para

um Robô o método sendPayload() deve ser chamado. Esse método irá encapsular o

comando em um objeto TXRequest16 e posteriormente em um objeto BufferItem,

que é somente um TXRequest16 junto com uma contagem de tentativas de

transmissão malsucedidas, para que ele seja adicionado ao final da fila do buffer de

transmissão. O buffer da transmissão funciona conforme o seguinte algoritmo:

1) Tentativa de envio do primeiro BufferItem da fila de transmissão.

a) Em caso de sucesso.

i) Remove o item da fila de transmissão.

ii) Retorna ao passo número 1.

b) Em caso de timeout.

i) Incrementa o contador de tentativas de transmissão.

ii) Verifica se o número de tentativas máximas foi atingido.

(1) Caso sim remove o item da fila de transmissão e notifica o problema de

transmissão através do console.

(2) Caso não move o item para o final da fila de transmissão e retorna ao

primeiro passo do algoritmo.

O algoritmo também pode ser descrito através de um diagrama de atividades,

mostrado na Figura 13.

45

Figura 13: Diagrama de atividades do algoritmo do buffer. Fonte: Autoria Própria

O buffer de transmissão juntamente com o parser, que será detalhado a

seguir, possibilita que vários robôs sejam comandados com um único comando.

Esse comando será interpretado pelo parser que irá carregar individualmente o

comando de cada robô na fila do buffer, sendo esse responsável por transmitir o

comando de cada robô através de um algoritmo Round Robin modificado. Ele é

modificado no sentido de que se houverem problemas de comunicação com um dos

robôs da lista, o buffer irá mover o comando desse robô para o final da fila de

transmissão, possibilitando que os outros robôs recebam seus comandos mesmo

que haja um robô com problemas de comunicação na fila de transmissão.

3.2.1.1 Parser

O Parser é o componente do framework responsável por interpretar

comandos complexos que envolvem vários robôs e dividi-los em comandos

46

individuais para cada robô para que possam ser adicionados ao buffer de

comunicação. A estrutura do comando do parser é mostrada na Figura 14:

Figura 14: Estrutura dos comandos do parser. Fonte: Autoria Própria

A palavra chave que inicia um comando é “cmd”, qualquer palavra diferente

dessa invalida o comando e o parser irá notificar que não conseguiu interpretar o

comando. Logo após a palavra de inicio deve-se deixar um espaço em branco e

então inserir o primeiro comando a ser enviado.

Cada comando é estruturado conforme a segunda tabela da Figura 14. A

primeira String contém o endereço hexadecimal de 16 bits do robô que deve receber

o comando. Logo após deve ser inserido um delimitador “,” para que o parser saiba

que o endereço terminou. O próximo campo a ser inserido é o código da função a

ser enviada para o robô. Uma tabela com os códigos de funções pode ser

encontrada na seção 3.3.2.4 . Outro delimitador “,” deve ser inserido para então

iniciar a parte dos parâmetros do comando. Cada um dos 4 parâmetros do comando

deve ser inserido após um delimitador e caso algum parâmetro não seja utilizado,

deve ser inserido o valor “-1” no lugar do parâmetro. Após o quarto parâmetro o sub-

comando é finalizado e deve ser inserido ou um delimitador ”/”, para inserir outro

sub-comando, ou um “;” para indicar o fim do comando a ser passado para o parser.

Um exemplo de comando que pode ser enviado para o parser pode ser:

“cmd 0x1234,0x26,0xAB,0xFF, 0xFF, -1/0x5678,0x27,0,255, 10,-1;”

Esse comando ordena que o robô no endereço 0x1234 ande 0x0AFF (2815)

centímetros para frente e que o robô no endereço 0x5678 ande 255 centímetros

para trás. Pode-se observar nesse exemplo que os parâmetros das funções podem

ser passados como números decimais de 0 a 255 ou então como números

47

hexadecimais de 0x00 até 0xFF. Se a notação utilizada for hexadecimal é

necessário preceder o parâmetro com o identificador hexadecimal “0x”.

3.2.2 Interface Gráfica

A interface gráfica desenvolvida possibilita que um usuário humano tenha

acesso fácil às funções do framework e possa testar as funcionalidades do sistema

como um todo.

Figura 15: Layout da interface gráfica. Fonte: Autoria Própria

Pode-se observar claramente 3 painéis distintos na interface. O primeiro deles

fica no canto superior esquerdo do layout, e é responsável por listar todos os robôs

atualmente conectados à estação base. Essa lista é atualizada sempre que o

framework detecta um novo robô na rede ou quando um robô é desconectado por

timeout. Os robôs aparecem na lista com o nome que lhes foi atribuído e com o

endereço do Xbee remoto acoplado a eles dentro de parênteses. O segundo painel,

48

localizado no canto superior direito, é responsável por receber as entradas do

usuário e formatá-las em um comando que possa ser enviado pelo framework, bem

como impedir que o usuário envie comandos inválidos. Ele possibilita que o usuário

envie comandos individualmente para cada robô conectado na rede de maneira fácil

e intuitiva. O terceiro painel, localizado na metade inferior da janela, contém um

console que informa ao usuário todas as operações realizadas pela base, como por

exemplo, envio de comandos, alterações nos parâmetros de configuração da porta

serial e erros de comunicação, bem como o assistente de configuração da conexão

serial e um botão que limpa o console. Há também nesse painel um campo de onde

é possível enviar comandos diretamente ao parser, de modo que o usuário pode

montar comandos que afetem 1 ou mais robôs, conforme descrito na documentação

do parser.

3.3 SISTEMA DE COMUNICAÇÃO

A parte de sistema de comunicação envolve o protocolo de como será feito a

comunicação. Esse protocolo deve garantir que a transmissão de dados seja bem

sucedida e caso haja uma perda de comunicação com o robô o usuário seja

devidamente alertado.

3.3.1 Módulos de comunicação

Durante a etapa de planejamento do projeto foram feitos vários levantamentos

com o objetivo de determinar qual tecnologia de comunicação sem fio servia melhor

aos propósitos do projeto. Feita essa análise de opções tecnológicas, a equipe optou

por utilizar o protocolo ZigBee, pois ele oferece baixo consumo, taxas de

transferência suficientes e alcance satisfatório para os requisitos do projeto, aliados

ao custo relativamente baixo em relação às outras tecnologias avaliadas. A etapa

seguinte foi selecionar quais módulos utilizar para realizar essa comunicação.

Optou-se por utilizar os módulos Xbee serie 1, pois são mais utilizados e facilmente

encontrados além de possuírem um custo acessível. Esses módulos consistem de

pequenos circuitos integrados preparados para se comunicar com uma UART, de

modo que, tanto o microcontrolador, quanto a estação base podem enviar comandos

wireless da mesma maneira que enviariam comandos através de um cabo serial

49

comum. Logicamente há todo um formato de frame a ser respeitado bem como

outras características de transmissão que devem ser definidas, a serem discutidas

logo abaixo, no entanto esse modelo Black-box dos módulos facilita muito a

implementação da comunicação, pois não existe a preocupação com os níveis mais

baixos do processo de transmissão sem fio.

Figura 16: Módulo Xbee Series 1 Fonte: (Digi International n.d.)

3.3.2 Protocolo

Para realizar a comunicação, é necessário estabelecer um formato de

transmissão da informação, denominado protocolo de comunicação. Este protocolo

possui regras específicas que identificam a origem, o destino e a ação a ser

executada.

3.3.2.1 Formato da mensagem

Toda mensagem enviada pela estação-base ou pelos robôs segue um padrão

fixo definido que permite o processamento das informações transmitidas. O

50

conteúdo da mensagem terá no máximo 100 bytes. Conterá um identificador de

início (três bytes) e fim (três bytes) que podem ser visto na Tabela 10.

3 bytes 94 Bytes 3 bytes

Início Conteúdo da mensagem Fim

Tabela 10: Formato padrão de mensagem Fonte: Autoria própria

Como o tamanho máximo da mensagem é de 100 bytes (conforme definido

na API do Xbee), e que os identificadores de início e fim ocupam 3 bytes cada,

restam 94 bytes para inserir o conteúdo da mensagem.

3.3.2.2 Encapsulamento da mensagem

As mensagens são encapsuladas em frames dentro das operações do Xbee

no modo API. Entre as principais vantagens de utilizar o modo API, estão:

Permite o Xbee receber dados de um ou mais Xbee remotos;

Quando enviando um pacote, o transmissor recebe uma confirmação

(ACK) indicando que o pacote foi recebido com sucesso ou reenvia o

pacote caso contrário;

Os pacotes recebidos contém o endereço de origem do transmissor;

Obtém o RSSI (potência do sinal) de um pacote recebido;

Os pacotes já incluem um checksum para integridade dos dados;

Quando esse modo API está habilitado, o frame que encapsula a mensagem

segue a estrutura que pode ser vista na Figura 17: Estrutura do Frame.

51

Figura 17: Estrutura do Frame Fonte: (MaxStream USA).

Start Delimiter: Valor que indica o início de um pacote (0x7E)

Length: Comprimento da mensagem é calculado pelo tamanho da API-

specific structure, esse valor é dividido em MSB e LSB.

Checksum: Para calcular o checksum, é necessário somar todo o

conteúdo da mensagem original (excluindo o próprio checksum), após

isso, utilizando apenas os 8 bits menos significativos dessa soma, é

necessário retirar de 0xFF esse valor. Desse modo a verificação torna-

se mais simples, pois para verificar se a mensagem está integra, é

recalculado o checksum do conteúdo da mensagem e então somado

com o checksum da mensagem, caso tenha resultado em 0xFF, a

mensagem está integra.

3.3.2.2.1 Modos API

Dentro desse frame, a estrutura específica (API-specific Structure) segue o

padrão:

Figura 18: Data Frame e estrutura específica de cada API Fonte: (MaxStream USA)

O campo cmdID é responsável por armazenar que tipo de mensagem API

estará contida dentro do cmdData. Para cada cmdID, um tipo de operação será

52

executada pelo Xbee (i.e. 0x01 envio de uma mensagem com destino com endereço

de 16 bits).

3.3.2.2.2 Modos API Notáveis

3.3.2.2.2.1 TX: 16-bit address

É feito uma requisição para transmissão de uma mensagem usando um

endereço destino de 16 bits.

Valor identificador API (cmdID): 0x01

Figura 19: TX Packet ( 16 bit address ) Fonte: (MaxStream USA)

Dentro do cmdData tem-se:

Frame ID (byte 5): Identificador da mensagem. O valor 0x0 desabilitará

a resposta do frame.

Destination Address (bytes 6-7): Endereço de destino da mensagem.

0xFFFF para broadcast.

Options (byte 8): Opções extras de como a mensagem será tratada.

0x01 para desabilitar ACK ou 0x04 para enviar o pacote com o Pan ID

do broadcast (não utilizado).

RF Data (Byte(s) 9-n): Conteúdo da mensagem

3.3.2.2.2.2 TX Status

Necessário para verificar qual é o estado de um frame envaido.

Valor de identificador da API: 0x89

53

Figura 20: Frame do TX Status Fonte: (MaxStream USA)

Frame ID (Byte 5): Identificador de qual frame está sendo reportado.

Status (Byte 6): Define o status final do pacote enviado.

Valor Definição

0 Sucesso no envido a mensagem

1 Não recebeu ACK.

2 Erro CCA (Clear Channel Assessment)

3 Eliminado

3.3.2.2.3 Operações AT notáveis

Operações AT são necessárias para fazer mudanças de configuração do

Xbee. Elas são enviadas como comandos seriais através da UART para o Xbee.

Para realizar esse tipo de operação é necessário iniciar o modo de comandos

enviando o fluxo de chars “+++”.

3.3.2.2.3.1 DL – Destination Address Low

Configuram os 32 bits iniciais dos 64 bits disponíveis para endereçamento.

Para utilizar no modo de 16 bits, que foi utilizado no projeto, é necessário configurar

apenas os 16 bits iniciais utilizando a seguinte notação:

“+++” // inicia o modo de comando

54

“ATDL5678” // envia um comando AT com objetivo de trocar o DL para

0x5678.

3.3.2.2.3.2 FR

Reinicia o Xbee. (Tempo aproximado de reset = 100ms)

3.3.2.2.3.3 BD

Seleciona o baud rate a ser utilizada para a comunicação serial.

Valor (Hexadecimal) Baud Rate (bps)

0 1200

1 2400

2 4800

3 9600

4 19200

5 38400

6 57600

7 115200

Tabela 11: Baud Rate para valores de BD Fonte: Autoria Própria

Exemplo:

“+++” // Inicia o modo de configuração

“ATBD6” // Configura o baud rate em 57600bps

3.3.2.3 Estrutura da Mensagem

Dentro dos 94 bytes disponíveis para o conteúdo da mensagem, foram

utilizados apenas 5 bytes para caracterizar o conteúdo de uma mensagem. A opção

55

por utilizar um tamanho pequeno de mensagem contribui para reduzir a taxa de

erros e aumentar a taxa de pacotes enviados.

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5

Tipo Parâmetro 1 Parâmetro 2 Parâmetro 3 Parâmetro 4

Tabela 12: Estrutura da mensagem Fonte: Autoria Própria

O campo Tipo definirá que tipo de operação será utilizado. O campo permite a

inserção de até 255 tipos de comandos diferentes. Utilizando até 4 parâmetros.

3.3.2.3.1 Lista de Comandos

3.3.2.3.1.1 Comando de Andar em Frente

Esse comando é utilizado para mover um robô em linha reta para frente.

Utiliza parâmetros de distância e velocidade.

Código do comando: 0x26

Tipos dos parâmetros:

o Byte 1/2: Valor da distância em cm, MSB em byte 1 e LSB em

byte 2.

o Byte 3: Valor da velocidade em cm/s

o Byte 4: Não utilizado

Código Byte 1 Byte 2 Byte 3 Byte 4

0x26 MSB Distância LSB Distância Velocidade -

Tabela 13: Estrutura de uma mensagem de andar para frente (0x26) Fonte: Autoria

Própria

3.3.2.3.1.2 Comando de Andar para Trás

56

Este comando é utilizado para mover um robô em linha reta para trás. Utiliza

parâmetros de distância e velocidade.



o Byte 1/2: Valor da distância em cm, MSB em byte 1 e LSB em

byte 2.

o Byte 3: Valor da velocidade em cm/s



0x27 MSB Distância LSB Distância Velocidade -

Tabela 14: Estrutura de uma mensagem de ir para frente (0x27) Fonte: Autoria Própria

3.3.2.3.1.3 Comando de Girar em sentido horário

Este comando é utilizado para girar um robô no sentido horário. Utiliza

parâmetros de angulação e velocidade.



o Byte 1: Velocidade angular (rad/s)

o Byte 2: Ângulo



57


0x28 Vangular Ângulo - -

Tabela 15: Estrutura de uma mensagem de girar no sentido horário (0x28) Fonte:

Autoria Própria

3.3.2.3.1.4 Comando de Girar Anti-horário

Este comando é utilizado para girar no sentido anti-horário. Utiliza parâmetros

de angulação e velocidade.



o Byte 1: Velocidade angular (rad/s)

o Byte 2: Ângulo




0x29 Vangular Ângulo - -

Tabela 16: Estrutura de uma mensagem de girar anti-horário (0x29) Fonte: Autoria

Própria

3.3.2.3.1.5 Comando de andar em uma direção (x, y).

Este comando é utilizado enviar comandos de movimento omnidirecional.

Apenas funcional para um robô omnidirecional.


58


o Byte 1: Deslocamento no eixo perpendicular do robô (cm)

o Byte 2: Deslocamento no eixo vertical do robô (cm)

o Byte 3: Velocidade (cm/s)



0x30 Eixo X Eixo Y Velocidade -

Tabela 17: Estrutura da mensagem para o movimento em uma direção Fonte: Autoria

Própria

3.3.2.3.1.6 Comando de Ligar/Desligar Driblador

Este comando permite ativar ou desativar o driblador do robô – não disponível

atualmente o robô.


Tipos de parâmetros: um parâmetro de 1 byte. O valor 0 (zero) desativa o

driblador, qualquer outro valor ativa o mesmo.


0x60 Tipo - - -

Tabela 18: Estrutura de mensagem para ligar/desligar driblador Fonte: Autoria Própria

3.3.2.3.1.7 Comando de acionar o chutador

Este comando permite ativar ou desativar o chutador – não disponível

atualmente no robô.


59

Tipos de parâmetros: um parâmetro de 1 byte. O valor indica o porcentual de

força a ser aplicado no mecanismo de chute. Sendo que 0xFF seria com

potência máxima e 0x00 com potência mínima.


0x61 Intensidade - - -

Tabela 19: Estrutura de mensagem para acionar o chutador Fonte: Autoria própria

3.3.2.3.1.8 Comando de solicitar leitura de sensores

Este comando solicita ao robô que seja enviado a leitura atual de todos os

sensores.

Código do comando: 0x1A


0x1A - - - -

Tabela 20: Estrutura de mensagem para solicitar leitura de sensores Fonte: Autoria

Própria

3.3.2.3.1.9 Comando de resposta de leitura de sensores

Resposta que contém os valores dos sensores disponíveis no robô.

Código do comando: 0x1B

Tipos de parâmetros: Para cada byte será inserido o valor do sensor n do

robô.

Código Byte 1 Byte 2 ... Byte 96

0x1B Valor 1 Valor 2 ... Valor 96

Tabela 21: Estrutura de mensagem de resposta de leitura de sensores Fonte: Autoria

própria

3.3.2.3.1.10 Solicitar inclusão na rede

60

Este comando envia uma solicitação para inclusão do robô na rede,

cadastrando a unidade na estação-base.


Tipos de parâmetros: este comando não possui parâmetros.


0x20 - - ... -

Tabela 22: Estrutura de mensagem para solicitação de cadastro na estação base Fonte:

Autoria própria

3.3.2.3.1.11 Comando de Confirmação de Inclusão na Rede

Este comando confirma que a solicitação de inclusão de um robô na rede foi

aceita e o robô agora está cadastrado na estação-base.




0x21 --- --- --- ---

Tabela 23: Estrutura de mensagem para inclusão de um robô em uma estação central.

Fonte: Autoria Própria

3.3.2.3.1.12 Comando de Solicitar Confirmação de dispositivo ativo

Este comando solicita para uma unidade uma confirmação que a mesma

esteja operante.




0x22 --- --- --- ---

61

Tabela 24: Estrutura de mensagem para confirmação de dispositivo ativo Fonte:

Autoria Própria

3.3.2.3.1.13 ACK

Este comando representa uma confirmação de mensagem bem sucedida.




0x50 --- --- --- ---

Tabela 25: Estrutura de mensagem para um ACK Fonte: Autoria Própria

3.3.2.4 Tabela de comandos

Byte Função

0x20 Solicitação de cadastro

0x21 Confirmação de inclusão

0x22 Checar se dispositivo está online

0x50 ACK

0x1B Resposta de leitura dos sensores

0x1A Requisição de leitura dos sensores

0x60 Aciona o Driblador

0x61 Aciona o Chutador

0x26 Andar para frente

62

0x27 Andar para trás

0x28 Girar no sentido horário

0x29 Girar no sentido anti-horário

0x30 Comando Omnidirecional

Tabela 26: Tipos de comandos Fonte: Autoria própria

3.3.3 Digramas de comunicação

Para realizar a comunicação, foram utilizadas os seguintes diagramas como

base.

3.3.3.1 Transmissão

O envio de dados é feito de acordo com o digrama de máquinas de estado

que pode ser visto na Figura 21 Inicialmente quando é necessário enviar o pacote, o

programa passa pelo estado de preparar o frame para envido de mensagem, ver

3.3.2.2.2.1. Tendo o frame preparado, checa-se se o número de vezes que esse

pacote foi enviado é menor que o número de tentativas máximas – definido no

programa – caso essa condição seja falsa (foi enviado menos vezes que o número

de tentativas máximas), o pacote é enviado.

Depois que a mensagem for enviada o programa espera por uma confirmação

da mensagem, caso ela não receba essa confirmação até o tempo do timeout, a

transmissão é refeita caso não tenha ultrapassado o limite de tentativas. Caso esse

limite tenha sido transposto, no caso da estação-base, o usuário é alertado que

houve problemas de comunicação o robô, ver seção 47. Do ponto de vista do robô,

caso estoure o limite máximo de tentativas, ele descartará a mensagem.

63

Figura 21: Máquina de estados da transmissão de dados Fonte: (Kurpiel, et al. 2010)

(Modificado)

64

3.3.3.2 Recepção

A parte da recepção da mensagem é feita de acordo com o seguinte

diagrama abaixo.

Figura 22: Diagrama de tratamento dos dados recebidos Fonte: (Kurpiel, et al. 2010)

(Modificado).

Quando uma mensagem é recebida, é feito uma verificação se esse pacote já

foi analisado. Caso esse pacote já tenha sido tratado a mensagem recebida é

descartada, caso não, a mensagem é verificada se o checksum está correto,

seguindo o caminho da mensagem correta, ou não, seguindo o caminho da

mensagem corrompida.

65

O fluxo de “mensagem já recebida” é para o caso de quando ocorre um

problema no envio de um ACK de alguma mensagem, e isso implicaria em uma

retransmissão do pacote. Ele seria executado novamente pelo destinatário caso não

houvesse o armazenamento do frameID dos últimos pacotes recebidos, esse fluxo

garante que uma mesma mensagem não seja executada mais de uma vez por

acidente.

3.3.4 Casos de comunicação

3.3.4.1 Iniciação do robô

Quando um robô é ligado, a mensagem de cadastro é enviada à sua

respectiva estação base como pode ser observado na Figura 24.

A estação base então responde com uma confirmação de cadastro. Caso

essa confirmação de castrado seja perdida, o cadastro é reiniciado.

Figura 23: Troca de mensagens entre estação-base e robô, visão geral Fonte: Autoria

Própria.

66

Figura 24: Diagrama de atividades para iniciação do robô visto pelo robô Fonte: Autoria

Própria

Figura 25: Diagrama exemplo de uma requisição da leitura dos níveis de bateria Fonte:

Autoria própria

67

3.3.4.2 Mensagem com requisição de resposta

Quando a estação faz uma requisição de leitura de sensores, no caso do

projeto apenas a leitura do nível da bateria, a estação base envia um comando com

tipo 0x1A – significando leitura de todos os sensores – e o robô envia a resposta

com o identificador 0x1B. Caso algum pacote seja perdido, o processo é reiniciado.

O processo pode ser visto no diagrama de atividades da Figura 26 e um exemplo do

processo em geral pode ser observado na Figura 25.

3.3.4.3 Mensagem de atuação do robô

Quando a estação base envia uma mensagem de atuação no robô, o modo

API do Xbee envia um ACK automaticamente, cuja condição pode ser checada

utilizando o TX Status (3.3.2.2.2.2). Na Figura 27: Diagrama de atividades do robô

para o recebimento de uma mensagem do tipo atuadora. Fonte: Autoria Própria

podemos ver o diagrama de atividades sobre o caso de uma mensagem de atuação

chegar ao robô.

Figura 26: Diagrama de atividades da resposta do robô em relação a mensagens de

requisição de leitura de sensores. Fonte: Autoria própria

68

Figura 27: Diagrama de atividades do robô para o recebimento de uma mensagem do

tipo atuadora. Fonte: Autoria Própria

Figura 28: Exemplo de envio de mensagem do tipo atuadora Fonte: Autoria própria

69

3.4 SISTEMA EMBARCADO

3.4.1 Software Embarcado

O software foi desenvolvido em blocos para tornar o desenvolvimento do

programa mais fácil. Esses blocos teriam que ser os mais independentes o possível

para tornar a fase de testes do programa mais simples e menos trabalhosa. Desse

modo é possível avançar a implementação do protocolo comunicação enquanto a

parte do controle ainda não está totalmente desenvolvida.

A parte de comunicação com fio foi incluída durante o desenvolvimento do

software para enviar parâmetros pela serial para a estação-base.

3.4.2 Webbotlib 1.31

A Webbotlib é uma biblioteca em C que auxilia o desenvolvimento de

sistemas embarcados para microcontroladores da ATMel que incluí: ATMega168,

Figura 29: Visão do software para testes em alto nível.

70

ATMega32, ATMega328P, ATMega640, ATMega644, ATMega1280, ATMega2560 e

ATMega2561.

Essa biblioteca tem a uma variedade de drivers prontos para serem utilizados,

dentre eles temos um gerenciador de envio/recebimento da UART, uma biblioteca

pronta para envio de palavras – strings – via UART, uma biblioteca de PID de fácil

acesso, um gerenciador de Timers simplificado, que torna o conhecimento específico

de cada microcontrolador menos necessário. Para projetos de microncontroladores

integrados (i.e. Axon) essa biblioteca renomeia os ports livres de maneira fácil e

intuitiva e os ports não disponíveis na placa são desabilitados para evitar o uso do

microcontrolador de maneira incorreta.

No projeto utilizamos a biblioteca de controle da UART, do PID, do PWM, dos

Timers, do envio de palavras via UART, e a biblioteca que renomeia o nome dos

pinos para os pinos disponíveis no Axon. Isso evitou um esforço na construção

dessas funções de baixo nível e possibilitou um foco maior no desenvolvimento de

nosso sistema.

3.4.3 Inicialização do programa

No início do programa é feito a inicialização dos módulos do firmware, a

comunicação com o XBee via UART2, inicialização dos módulos do PWM,

inicialização PID, configuração dos Timers e a definição de tarefas a serem

executadas (scheduler). A sequência de operação pode ser vista na Figura 30.

71

Figura 30: Sequência de comandos para inicialização do Firmware Fonte: Autoria

própria

72

3.4.4 Funcionamento normal – visão geral

A partir do momento que todas as funções são inicializadas entra-se em

estado de funcionamento padrão, ou seja, no modo de receber mensagens, tratá-las

e executá-las.

O programa fica em espera por mensagens enquanto, a cada 200

milissegundos, entra no seu estado de controle – ver figura Figura 31 - que calcula

os novos níveis de PWM nos motores que serão utilizados no robô baseados na

última realimentação fornecida pelos opto-acopladores e no comando recebido pela

base.

Figura 31: Visão geral do firmware, uma abordagem de alto nível Fonte: Autoria própria

73

3.4.4.1 Controle

Foi implementado o controle PID (proporcional, integral e derivativo) no robô.

Esse controle possui algumas características bem definidas mostradas na tabela 3.

P – Correção proporcional ao erro A correção cresce na mesmo

proporção que cresce o erro da diferença

entre o valor real e valor desejado.

I – Correção proporcional ao produto

erro x tempo

Erros pequenos, mas que não foram

tratados há muito tempo requerem correção

mais intensa.

D – Correção proporcional a taxa de

variação do erro

Se o erro esta variando muito rápido

esta taxa de variação dever ser reduzida a

fim evitar oscilações.

Tabela 27: Controle PID básico. Fonte (Controle PID básico, UFSC s.d.).

O controle usa um sistema de malha fechada de realimentação, inicia-se com

a definição de um ponto objetivo – setPoint - esse objetivo é a velocidade alvo de

cada roda – em centímetros por segundo – e a realimentação é feita por meio dos

encoders, que são lidos a cada 200ms, que gera uma velocidade que é utilizada

para definir o ponto atual do PID. Esse modelo é interessante, permite a alteração

do setPoint enquanto o robô está em movimento sem que haja reinicio do PID.

74

3.4.4.2 Início da comunicação

Após o início do firmware é necessário que o robô entre em sincronia com sua

respectiva estação base. O programa inicia enviando uma mensagem para sua

estação base com o tipo 0x20 – mensagem do tipo de cadastro - que em um fluxo

em condições perfeitas, a base responderia imediatamente com uma mensagem

confirmando o cadastro com o ID 0x21, respostas do sistema para condições

adversas podem ser vista na Figura 33.

Figura 32: Diagrama de controle Fonte: Autoria própria

75

3.4.4.3 Tratamento de mensagens pós-sincronização com estação base

Após sincronização da do robô com a estação base, o robô entra no estado

de aguardar mensagens da estação base. Esse estado é demonstrado na Figura 34.

O exemplo da figura ilustra o fluxo caso a mensagem da estação base que chegar

for do tipo de movimento. Na Figura 35 é ilustrado a resposta do firmware para

solicitação de envio de mensagem com informações para estação base.

Figura 33: Diagrama que mostra o cadastro do firmware na visão do robô Fonte:

Autoria própria

76

Figura 34: Diagrama de resposta do firmware para o fluxo

de decodificação de uma mensagem de atuação nos motores

Fonte: Autoria Própria

77

Figura 35: Diagrama de resposta do firmware para o fluxo de

resposta a uma solicitação da estação base. Fonte: Autoria própria

78

3.4.4.4 Controle da rampa

O controle da rampa, para evitar derrapagem, é feito por meio de uma

verificação a cada 20ms que checa se a posição atual em relação a ponto de destino.

Se o ponto atual está a uma distância menor que 20% em relação ao ponto de

destino, o resultado do PID é reduzido em 2% do seu valor inicial (objetivo). A rampa

de subida é feita pelo próprio controlador quando inicia um movimento

Figura 36: Rampa de descida.

79

3.4.5 Componentes

3.4.5.1 Regulador de tensão 7805

Foram usados dois reguladores de tensão 7805 para alimentar alguns

componentes da PCI e o microcontrolador. Um dos reguladores foi usado para

alimentar o microcontrolador e os optoacopladores, para que seja possível caso

ocorra a necessidade de alimentar os diferentes circuitos com fontes diferentes.

Isolar o microcontrolador e os optoacopladores do restante do circuito a fim de evitar

os problemas de correntes transientes provocadas pelos motores DC que pode, por

exemplo, “resetar” o microcontrolador. O segundo regulador foi usado para alimentar

os demais circuitos eletrônicos que são: o DIP Switch de endereço, o nível lógico de

tensão das pontes-H, as chaves óticas e o Schmitt Trigger 74LS14.

O regulador foi projetado de acordo com a Figura 37, presente no datasheet

do componente. (Fairchild 2001)

Figura 37: Projeto do regulador 7805 presente no datasheet. Fonte: (Fairchild 2001)

Para verificar as ligações dos reguladores na PCI é necessário ver a Figura

50.

3.4.5.2 Regulador de tensão LM317

O regulador de tensão LM317 foi usado apenas para alimentar o Xbee em

nível lógico 3,3V já que ele pode ser usado como um regulador ajustável de tensão

de acordo com os resistores e mostrados na Figura 38 disponível no

80

datasheet. Para escolher esses resistores foi utilizada a equação ( 1 ) também

disponível no datasheet. (National Semicondutor, 1996)

Figura 38: Esquemático do LM317. Fonte: (National Semicondutor 1996).

( 1 )

O valor do resistor indicado pelo fabricante é de 240Ω. Como esse valor

não é um valor comercial foi utilizado dois resistores, um de 220Ω associado em

série com 22Ω, fornecendo um resistor de 242Ω. No circuito da PCI final esses

resistores receberam o nome de e respectivamente.

Tem-se que o valor típico de é de 100µA segundo o datasheet.

Substituindo por , por e por na equação ( 1 ), obtêm-se:

(2)

Isolando-se na equação (2), tem-se que . Para aproximar esse valor

a um valor comercial foram usados dois resistores associados em série de e

, o que equivale em uma resistência final de . Na PCI final foi dado o nome

de e para esses dois resistores respectivamente.

A disposição dos resistores e com o regulador LM317 e a disposição

dos mesmos na PCI podem ser vistas na Figura 50.

81

3.4.5.3 Xbee

Foi usado 5 pinos do Xbee no circuito da seguinte maneira:

O pino 1 foi usado para alimentar o Xbee com 3,3V proveniente do

regulador LM317 a partir o conector JP-3,3V. (ver Figura 41)

O pino 2 (UART Data Out) foi conectado em uma entrada do Schmitt

Trigger 74LS14 e como o mesmo é inversor, é necessário fazer o sinal

passar mais uma vez pelo mesmo componente para elevar a tensão

de 3,3V para 5V sem alterar sua natureza. A saída do componente foi

conectada no pino Rx da UART2 do microcontrolador. Essa foi a

solução escolhida, pois o componente já estava disposto na placa e

sobravam 3 pinos de I/O. O motivo de utilizar essa configuração e não

ligar diretamente o pino na UART2 do microcontrolador é pelo fato de

que a equipe já tinha conhecimento prévio de que alguns

microcontroladores Axon tinham problemas com o interfaceamento

direto com o Xbee.

O pino 3 (UART Data In) foi conectado na saída de um divisor de

tensão com resistor R25 e R31. A entrada do divisor de tensão foi

conectada no pino Tx da UART2 do microcontrolador. Essa

configuração foi usada a fim de diminuir o nível lógico de tensão de 5V

do pino Tx para 3,3V, que é o nível lógico de operação do Xbee. Como

, e supondo um valor de e seguindo o

esquema disposto na Figura 39, tem-se que:

( 3 )

( 4 )

Substituindo ( 3 ) em ( 4 ) com os valores de , , já definidos e

isolando-se tem-se que . Aproximando esse valor para um valor

comercial obtêm .

82

Figura 39: Divisor de tensão. Autoria própria.

O pino 6 foi ligado no LED1 que indica a potência do sinal e para

limitar a corrente nesse LED foi usado um resistor .

O pino 15 foi ligado no LED2 que indica uma recepção ou transmissão

de dados e para limitar a corrente nesse LED foi usado um resistor

.

O significado dos pinos é mostrado na Figura 40 e a disposição das ligações

do Xbee na PCI final é mostrada da Figura 41.

83

Figura 40: Pinos do Xbee. Fonte: (MaxStream USA).

Figura 41: Projeto de ligação do Xbee na PCI final. Fonte: Autoria própria.

84

3.4.5.4 DIP Switch 2 vias de 5 bits

O DIP Switch foi utilizá-lo como uma chave que está normalmente em nível

lógico alto ou nível lógico baixo, sendo assim utilizaram-se resistores de pull-up de

2200Ω. O máximo consumo de corrente ocorre quando o DIP está normalmente

fechado, o que equivale a uma dissipação de 11,36mW calculada através da

equação ( 5 ).

( 5 )

O DIP usado foi de 5 bits de vias. Desses 5 bits o bit 0 foi usado para escolher

para qual base o robô vai se comunicar, diferenciando o bit menos significativos do

endereço de 4 bytes do Xbee da base ao qual irá mandar e receber mensagens.

Seguindo esse conceito tem-se a possibilidade de escolher duas bases diferentes.

Os outros 4 bits restantes do DIP switch são usados como os 4 bits menos

significativos do endereço de 4 bytes do robô. Os demais bits são fixos. Com esses

4 bits consegue-se diferenciar 16 robôs. Sendo assim pode-se obter uma partida de

futebol com 16 robôs para cada time.

3.4.5.5 Encoders

São transdutores que converte movimentos seja ele linear ou angular em

sinais elétricos que carregam informações bem definidas. Nesse projeto chaves

ópticas são utilizados para determinar a rotação das rodas presente no robô. Dessa

forma quando usado em conjunto com o redutor do robô que consiste em uma

estrutura física de 32 “cortes” e uma chave ótica que altera o sinal do dispositivo

entre 0 e 1 (definidos pela tensão 0 e 5V, respectivamente), o que permite uma

precisão P de 11,25º através da equação ( 6 ).

( 6 )

Vale ressaltar que toda a estrutura dos encoders estava montada na estrutura

do robô. Havia apenas 3 terminais disponíveis para ligar na placa e para isso foi

necessário desmontar a estrutura para verificar cada um deles. O pino marrom

85

estava ligado no pino 2 e no pino 4, o terminal verde estava ligado no pino 3 e o

terminal azul estava ligado no pino 1. Para verificar esses pinos é preciso analisar a

Figura 42. Já para a ligação dessa chave ótica foi utilizado dois resistores de pull-up

ligados nos terminais verde (pino 3) e azul (pino 1) de 2,2KΩ e 440Ω,

respectivamente. Já o terminal marrom (pino 2 e pino 4) foi ligado na referência do

circuito.

A Figura 43 mostra o esquema de ligação da chave ótica na PCI.

Figura 42: Esquema da chave ótica H22A1. Fonte: (Fairchild 2001)

86

Figura 43: Esquema de ligação da chave ótica do encoder na PCI. Fonte: Autoria

própria

3.4.5.6 Schmitt Trigger 74LS14

O Schmitt Trigger atua da seguinte forma. Se o nível lógico de entrada está

acima do limiar (descrito no datasheet) a tensão de saída está em nível lógico alto,

mas se a tensão de entrada está abaixo de outro (também descrito no datasheet) a

tensão de saída fica em nível lógico baixo. Atuando dessa forma o Schmitt Trigger

evita oscilações do sinal mantendo ele em nível lógico alto ou baixo.

Sendo assim os seis Schmitt Triggers presentes no circuito integrado 74LS14

foram usados da seguinte maneira:

3 foram usados na saída das chaves óticas dos encoders.

2 foram usados na saída do pino 2 (UART Data Out) do Xbee.

O pino que restou foi inutilizado.

As ligações desse componente podem se vista na Figura 49.

87

3.4.5.7 Opto acopladores 4N35

O optoacoplador é um componente eletrônico baseado em um diodo emissor

de luz infravermelha e um fototransistor sensível a essa faixa de luz. A disposição

dos componentes dentro do encapsulamento é mostrada na Figura 44.

A função desse componente eletrônico nesse projeto é de isolar duas partes

distintas do circuito eletrônico, dessa forma ele evita que quaisquer perturbações ou

ruídos provenientes do motor sejam propagados para o microcontrolador através dos

pinos de controle.

O funcionamento desse componente na PCI é simples, quando há um nível

lógico alto (5V) atuando na entrada do optoacoplador, o diodo passa a emitir luz

infravermelha que incide diretamente na base do fototransistor, saturando o mesmo

e ocasionando um nível lógico baixo na saída. No caso de um nível lógico baixo

aplicado a entrada, o diodo para de emitir luz cortando o fototransistor e resultando

em nível lógico alto na saída do optoacoplador.

É necessário adicionar um resistor em série com o diodo de modo a limitar a

corrente sobre o mesmo. A corrente recomendada pelo datasheet é de 10mA. Para

calcular o resistor é utilizada a equação (7) obtendo-se um resistor de 500Ω e

aproximando-o para um resistor comercial obtém-se 560Ω.

( 7 )

Além desse resistor é necessário ligado no coletor do fototransistor atuando

como resistor de pull-up de 2,2KΩ. Como o optoacoplador tem por objetivo isolar

eletricamente duas partes do circuito, é necessário que se utilize duas fontes

distintas para alimentar a entrada e a saída do optoacoplador, de modo que não haja

nenhuma outra ligação entre os 2 circuitos, isolando-os completamente. Porém

foram utilizadas duas fontes ligadas em paralelo alimentando todo o circuito já que

não ocorreu nenhum problema no decorrer do projeto quando a isso, entretanto

como tal fato já foi previsto, foi disposto na PCI um conector (JP 7805-2) que

88

possibilita alimentar o microcontrolador e o optoacoplador de forma isolada do

restante do circuito. É importante analisar que o terminal entre o coletor e o resistor

de pull-up foi ligado nos pinos de controle das pontes-H.

Figura 44: Esquemático e pinos do Optoacoplador 4N35. Fonte: (Fairchild 2001)

Figura 45: Projeto dos optoacopladores na PCI. Fonte: Autoria própria.

89

3.4.5.8 Ponte-H L298

A ponte-H é o nome dado a o circuito eletrônico usado para fazer o

interfaceamento com motores DC nesse projeto. As aplicações que de motores

normalmente necessitam que eles rotacionem em dois sentidos, algo que pode ser

facilmente feito invertendo a polaridade dos cabos da alimentação dos motores. A

ponte-H é um circuito eletrônico que permite que essa troca de polaridade seja feita

sem desconectar nenhum cabo manualmente do motor. Alguns circuitos integrados

permitem que um microcontrolador possa comandar o sentido de rotação de um

motor DC apenas manipulando sinais lógicos presentes no mesmo. A ponte-H utiliza

4 transistores, que funcionam como chaves, dispostos em um formato similar a uma

letra “H”, daí o nome “ponte-H”, conforme mostrado na Figura 47.

O funcionamento dela requer que nunca dois transistores do mesmo lado

estejam saturados, pois isso ocasionaria um curto circuito na fonte. Quando dois

transistores diagonalmente opostos estão saturados e os outros 2 estão cortados

tem-se a rotação em um sentido. Quando os outros dois transistores diagonalmente

opostos estão saturados e os 2 primeiros voltam para o corte tem-se a rotação no

sentido oposto ao inicial.

O L298N já possui uma lógica interna que não permite que 2 transistores

adjacentes sejam ativados ao mesmo tempo causando o curto na fonte. O

funcionamento desse circuito integrado é baseado em 2 pinos de entrada (“In1” e

“In2” no caso da primeira ponte-H do CI L298 e “In3” e “In4” no caso da segunda

ponte-H) e um pino de enable “En” (EnA na primeira ponte-H e EnB da segunda

ponte-H). Os pinos de In1 e In2 controlam o sentido de rotação do motor conectado

aos pinos “Out1” e “Out2”, assim como o os pinos de In3 e In4 controlam o sentido

de rotação do motor conectado aos pinos “Out3” e “Out4” e o pino “En” habilita ou

não a Ponte-H como um todo.

O controle dos motores do robô foi feito por PWM através dos pinos de enable

das pontes-H e o controle de sentido de rotação através dos pinos input como já

descrito. Entretanto o datasheet indica que o a corrente de operação de cada uma

das pontes-H é de 2A, e para garantir tal fato foi usado as duas pontes-H do L298

90

em paralelo em cada motor da forma observada na Figura 46 presente no datasheet

do componente.

Figura 46: Esquema de ligação das duas pontes-H do L298. Fonte: (STMicroelectronics

2000)

91

Dessa maneira temos um controle de direção, pino “In1” e “In2” mutuamente

exclusivos, e um controle de velocidade, PWM no pino “En”, possibilitando que o

motor gire nos dois sentidos e com velocidade controlada pelo microcontrolador.

Figura 47: Ponte-H L298. Fonte: (STMicroelectronics 2000)

3.4.5.9 Bateria

O projeto utilizou duas baterias compostas por um banco de pilhas

recarregáveis, totalizando aproximadamente 16V em carga total cada uma delas.

Elas são ligadas em paralelo nos conectores JP-Bateria1 e JP-Bateria2 na PCI.

Como existe a possibilidade de usar fontes diferentes a fim de isolar, por

exemplo, o microcontrolador e os optoacopladores, do restante do circuito. Foram

colocados na PCI alguns pinos de forma que isso seja possível. Esses pinos são os

jumpers JP7805-2, JP7805-1, JP317 e os conectores JP-7805-2, JP-7805-1, JP-317

colocados na entrada dos reguladores que deseja-se alimentar separadamente. Os

diodos D13, D14 e D15 usados na entrada dos reguladores para evitar problemas

como o transiente de corrente e como proteção caso as baterias sejam ligadas em

polarização invertida na placa. Para verificar os conectores descritos no texto acima

basta ver a Figura 50.

92

3.4.6 Placa de circuito impressa

A placa de circuito impressa (PCI) foi construída em duas placas de forma a

acoplá-las. Na camada 1 estão presente os opto acopladores, Schmitt Trigger, chave

de endereço, Xbee e alguns resistores. Na camada 2 estão presentes as 3 pontes-H

e os 3 reguladores de tensão, assim como os diodos de proteção e alguns

capacitores.

Esse separação foi feita dessa forma a fim de melhor aproveitar o espaço

sobre o robô, uma vez que o robô tem limitações em suas dimensões. Ambas as

camadas da PCI foram feitas no software EAGLE (Easily Applicable Graphical

Layout Editor) versão 5.11.0 Professional Edition.

Todavia como se teve que fazer testes no robô em paralelo com a construção

da PCI final ocorreu a necessidade de montar uma PCI provisória com o mesmo

esquema da PCI final, porém em uma placa universal mostrada na Figura 48.

Figura 48: PCI provisória. Fonte: Autoria própria

3.4.6.1 Visão geral das conexões da Camada 1 da PCI

A camada 1 pode ser observada na Figura 49: Ligações da Camada 1 da PCI

final. Fonte: Autoria própria.. É possível observar os nove optoacopladores que

93

estão ligados em dois conectores, sendo que 9 dos 10 pinos do conector SV-IN-

OPTO são ligados diretamente no microcontrolador, o pino 10 não é ligado em nada,

apenas está presente por que esse conector é padrão. Já os pinos do conector SV-

OUT-OPTO são ligados na ponte-H da segunda camada no conector JP-PHS-IN,

onde os 3 primeiros pinos são de PWM e os outros 6 pinos são de INPUTS, sendo 1

PWM e 2 inputs para cada ponte-H. O Conector JP-5V-1 é o pino de alimentação de

5V proveniente da segunda camada pelo conector JP-7805-2-OUT para os encoders

e a chave IC1-CHAVE que possuí 5 resistores de pull-up, R26, R27, R28, R29, R30.

Os conectores JP-ENC1, JP-ENC2, JP-ENC3 são ligados nos 3 cabos dos encoders

do robô. Os 3 Schmitt Trigger's IC4A, IC4B, IC4C são usados nas saídas das chaves

ópticas presente nos encoders, sendo assim o conector JP-OUT-ENC é ligado ao

microcontrolador para leitura das bordas do chaveamento da chave-ótica. O

conector JP-3,3V é usado para a alimentação do Xbee proveniente do conector JP-

317-OUT da segunda camada. O conector JP23-UART é ligado na UART2 do

microcontrolador.

94

Figura 49: Ligações da Camada 1 da PCI final. Fonte: Autoria própria.

95

3.4.6.2 Visão geral das conexões da Camada 2 da PCI

A camada 2 pode ser observada na Figura 50. Os conectores JP-BATERIA1,

JP-BATERIA2 são pinos de alimentação das duas baterias presentes no robô e

ligadas em paralelo como visto na figura. JP317, JP7805-1, JP7805-2 funcionam

como jumpers para a alimentação com as duas baterias em paralelo (pinos JP-

BATERIA1, JP-BATERIA2), ou por alimentação de fontes diferentes em cada um

dos reguladores (pinos JP-317, JP-7805-1, JP-7805-2, são os pinos de alimentação

por fonte deferente caso os jumpers sejam retirados). O conector JP-317-OUT é

utilizado para alimentar o Xbee em 3,3V. O conector JP-7805-2-Axon é utilizado para

a alimentação na primeira camada do microcontrolador e dos optoacopladores já

descrito acima. Já o conector JP-78051-OUT é usado para alimentar os demais

circuitos integrados assim com a alimentação lógica das pontes-H. Os conectores

JP-MOTOR1, JP-MOTOR2, JP-MOTOR3 são conectados diretamente nos 3

motores DC. Os diodos desta placa são usados como proteção da indução elétrica

ocasionada quando há a inversão de rotação.

96

Figura 50: Ligações da camada 2 da PCI final. Fonte: Autoria própria

97

3.4.6.3 Esquemático das camadas enviado para a prototipação

O esquemático das camadas que foi enviado para a prototipação segue

mostrado nas Figura 54 e Figura 51. Esses esquemáticos foram criados

automaticamente após fazerem-se as ligações necessárias entre os componentes

no software EAGLE, porém a disposição dos componentes foi feita a “mão” assim

como grande parte das trilhas, as demais foram roteadas automaticamente. É

possível observar que há algumas trilhas da camada 2 com espessura maior já que

a corrente que fluirá nessas trilhas é relativamente maior que as demais. Após a

construção desses esquemáticos foi exportado arquivos em formato GERBER. Esse

formato é usado para a prototipação das PCIs e cada um deles possui um tipo de

informação como, por exemplo, mascara de solda, legenda, etc. Para a visualização

dos arquivos em formato GERBER foi utilizado o software ViewPlot. Nesse software

é possível analisar cada uma das camadas separadamente ou ainda sobrepor

quantas se desejar.

É possível observar como as placas vão ser sobrepostas na Figura 53.

Figura 51: Esquemático da camada 2 da PCI final enviada para prototipação. Fonte:

Autoria própria.

98

Figura 52: Camada 2 da PCI final antes de soldar. Fonte: Autoria própria.

Figura 53: Camadas 1 e camada 2 sobrepostas. Fonte: Autoria própria.

99

Figura 54: Esquemático da camada 1 da PCI final enviada para prototipação. Fonte:

Autoria própria.

Figura 55: Camada 1 da PCI final antes de soldar. Fonte: Autoria própria.

100

4 CONCLUSÕES

4.1 ANÁLISE DO DESENVOLVIMENTO

O desenvolvimento do projeto apresentou muitos problemas devido a

completa inexperiência da equipe no desenvolvimento de um projeto desse porte, no

entanto considera-se muito válida a experiência adquirida durante o processo, pois o

objetivo da disciplina de Oficina de Integração 3 é justamente proporcionar aos

alunos uma noção de como são todas as etapas do desenvolvimento de um projeto,

desde a especificação e planejamento, passando pelo gerenciamento do tempo e

dos recursos humanos e finalmente chegando à implementação das soluções

projetadas e teste do sistema final.

Durante a etapa de planejamento do projeto, foi feito uma análise de todos os

riscos aos quais o projeto estava sujeito, sendo também analisado a probabilidade

de ocorrência desses riscos e o impacto deles sobre o projeto. A seguir um breve

comentário sobre os riscos mais importantes.

4.1.1 Riscos Relevantes

A seguir será feita uma breve análise sobre os riscos previstos no plano de

projeto e quais deles realmente ocorreram no decorrer do desenvolvimento, bem

como o impacto para o artefato final.

4.1.1.1 Atraso no recebimento de componentes pelos fornecedores

Esse risco foi avaliado como sendo de impacto médio/alto e com

probabilidade média/baixa de acontecer, no entanto ele ocorreu. O microcontrolador

foi adquirido através de importação dos Estados Unidos, o que acarretou em um

atraso muito grande devido à restrições da alfândega brasileira, que demorou mais

de 40 dias para liberar a entrega do componente. O impacto desse risco foi

praticamente anulado através do empréstimo de um microcontrolador igual ao que

seria importado, de modo que a equipe pode fazer todo o desenvolvimento que

envolvia o microcontrolador com a unidade emprestada, sem prejuízo para o

cronograma do projeto.

101

4.1.1.2 Problemas com a comunicação sem fio

Desde a etapa de planejamento do projeto, sabia-se que a comunicação sem

fio era um ponto crítico do projeto, tanto pela dificuldade em implementar esse tipo

de comunicação quanto pelo papel fundamental do sistema de comunicação para o

funcionamento do sistema final. Devido a isso, na etapa de análise dos riscos, o

risco de ocorrer algum problema com a comunicação sem fio foi avaliado como

sendo de probabilidade média/alta e impacto alto. Durante o desenvolvimento do

projeto, o maior problema encontrado com a comunicação sem fio foi, sem dúvida o

fato de a equipe ter subestimado a complexidade do protocolo de comunicação

necessário para atender aos requisitos do sistema. Isso acabou resultando em um

gasto de tempo muito além do planejado para implementar a comunicação sem fio,

prejudicando o cronograma do projeto como um todo.

4.1.1.3 Custo real muito acima do custo estimado para o projeto

O custo final do projeto foi acima do custo planejado principalmente devido à

indisponibilidade de componentes críticos para o projeto no Brasil, como por

exemplo, os módulos Xbee e o microcontrolador Axon, de modo que foi necessário

importar esses componentes dos Estados Unidos. A importação acaba incorrendo

em elevados custos com frete e também no risco dos componentes importados

serem taxados pela alfândega brasileira, o que eleva o custo do componente em

60%, a atual alíquota de importação no Brasil.

4.1.1.4 Impossibilidade de algum membro da equipe terminar o projeto

O projeto foi inicialmente planejado para ser executado por uma equipe de 4

membros, no entanto no decorrer do desenvolvimento um dos membros não pode

continuar por falta de interesse. Esse fato havia sido previsto no plano de riscos do

projeto, como tendo uma probabilidade de acontecimento media/baixa e um impacto

médio/alto no projeto. O impacto desse risco para o desenvolvimento do projeto foi

sentido diretamente na carga de trabalho necessária dos membros restantes, pois foi

necessário dividir e absorver o trabalho do membro faltante.

102

4.1.1.5 Falta de tempo para conclusão do projeto

O cronograma inicial do projeto foi planejado para ser executado por 4

pessoas, no entanto boa parte do desenvolvimento foi feito com uma equipe de

somente 3 pessoas, o que acabou acarretando em atrasos no cronograma, aumento

da carga horária individual necessária para concluir o projeto e por fim falta de tempo

para concluir da maneira ideal todos os aspectos da execução e documentação do

projeto. Houve também problemas durante a etapa de planejamento do projeto no

sentido de subestimar o tempo necessário para desenvolver algumas etapas do

projeto, notadamente a comunicação sem fio como um todo. Essas tarefas

acabaram demandando mais tempo do que o planejado, pressionando o

cronograma como em direção a data de entrega e culminando na falta de tempo

para concluir o projeto de maneira adequada.

4.1.2 Considerações finais sobre o desenvolvimento

O desenvolvimento desse projeto proporcionou um ambiente de aprendizado

para todos os membros da equipe em diversos campos do conhecimento, até então

deficitários em nossa formação, como por exemplo, gerência de tempo, gerência de

recursos humanos, análise de riscos, planejamento de projetos, entre outros. Alguns

conhecimentos necessários ao projeto estavam sendo estudados de maneira

concorrente durante o semestre como, por exemplo, os conhecimentos de Controle

e Sistemas Microcontrolados, fato esse que ocasionou diversos problemas durante o

desenvolvimento, pois muitas vezes as decisões da equipe em relação ao projeto

tiveram que ser tomadas antes dos conteúdos necessários terem sido aprendidos.

Algumas dessas decisões foram equivocadas, resultando em um trabalho maior

necessário para corrigir esses problemas, trabalho esse que poderia ser evitado

caso essas disciplinas já tivessem sido cursadas anteriormente ao início do projeto.

4.2 INTEGRAÇÃO

O desenvolvimento desse projeto exigiu da equipe conhecimentos em

diversas outras disciplinas ministradas no curso de Engenharia de Computação,

sendo cada uma dessas disciplinas e sua aplicação no projeto detalhadas a seguir.

103

4.2.1 Controle

A disciplina de controle versa sobre como se pode controlar a saída de um

determinado sistema alterando sua entrada. Aplicado ao projeto em questão, os

conhecimentos de controle possibilitam que a velocidade com que o robô se

locomove seja controlada, independentemente de superfície ou de carga na bateria,

através da variação do PWM aplicado aos motores. Também é possível garantir que

o robô ande em linha reta e execute outros comandos com precisão, através de um

algoritmo de controle PID associado à realimentação do movimento das rodas,

provida por encoders presentes em cada roda.

4.2.2 Sistemas Microcontrolados

Em sistemas microcontrolados, aprendemos como estruturar o software do

sistema embarcado, bem como a utilização correta dos diversos periféricos de um

microcontrolador comum como, por exemplo, timers, interrupções, ports de entrada e

saída e UARTs(Universal Asynchronous Receiver/Transmitter). Estudamos também

como deve ser feito o interfaceamento com motores e outros dispositivos de

potência como, por exemplo, Pontes-H, esse conteúdo é de suma importância para

o desenvolvimento de projetos que envolvem robôs como esse. A comunicação

serial, padrão utilizado pelo Xbee, também foi um conteúdo crítico para o

desenvolvimento do projeto que foi estudado durante o desenvolvimento dessa

disciplina.

A disciplina de sistemas microcontrolados teve um papel fundamental para o

desenvolvimento do projeto, e avalia-se que se a disciplina já estivesse sido

concluída previamente em relação ao início do projeto, o aproveitamento e o

desempenho da equipe teria melhorias significativas.

4.2.3 Comunicação de dados

Os problemas relacionados a comunicação sem fio do projeto foram

solucionados com a ajuda dos conhecimentos aprendidos na disciplina de

comunicação de dados. Conceitos estudados como, por exemplo, acknowledge e

handshaking foram empregados no desenvolvimento do protocolo de comunicação,

104

de modo a garantir o nível de robustez e confiabilidade requerido na especificação

do projeto.

4.2.4 Eletrônica 2

A disciplina de eletrônica 2 foi especialmente importante no projeto dos filtros

analógicos, utilizados para filtrar ruídos indesejados na alimentação dos circuitos.

Essa disciplina também foi importante no dimensionamento e utilização dos

componentes de potência do circuito, notadamente as pontes-H que comandam os

motores.

4.2.5 Análise e projeto de sistemas e Engenharia de Software

Essas duas disciplinas tratam sobre metodologias de projeto de software,

buscando melhorar a qualidade e diminuir ao máximo o retrabalho necessário no

processo de desenvolvimento de software. Algumas dessas metodologias foram

aplicadas tanto no desenvolvimento do software da estação base como no firmware

do sistema embarcado, notadamente a elaboração de diversos diagramas que

descrevem o comportamento do sistema e a concordância com as melhores praticas

descritas pelo PMBOK(Project Management Body of Knowledge). Logicamente a

equipe teve dificuldades em aplicar todos os conceitos de engenharia de software e

gerência de projeto, pois eles envolvem uma grande componente de experiência

com projetos anteriores. Esse projeto foi o primeiro desse porte a ser desenvolvido

pela equipe com ênfase na gerência de projeto, fato esse que acabou apresentando

novos desafios à conclusão do projeto, de modo que sobreposto as preocupações

relativas à engenharia haviam também as preocupações relativas à gerência das

pessoas e distribuição igualitária da carga de trabalho.

4.3 TRABALHOS FUTUROS

Essa seção trata sobre os próximos passos a serem tomados no

desenvolvimento do projeto do ponto de vista da equipe. O objetivo é possibilitar que

uma outra equipe possa dar continuidade ao trabalho desenvolvido nesse projeto

105

com o mínimo de retrabalho possível, possibilitando a conclusão de objetivos cada

vez maiores.

4.3.1 Driblador e chutador

A adição de um driblador e um chutador ao projeto possibilitaria que os robôs

fossem utilizados em outra função que não a de goleiro. Os desafios envolvidos na

implementação dessas soluções são principalmente a adequação da parte mecânica

para receber esses novos componentes e a inserção de novos circuitos integrados

necessários na atual arquitetura, uma vez que as dimensões do robô são reduzidas.

Do ponto de vista da comunicação e do software, pequenos ajustes precisam ser

feitos para que essas novas funções sejam suportadas, pois ambos os sistemas já

foram desenvolvidos de modo a suportar expansões de capacidade.

4.3.2 Adição de sensores

A adição de diversos tipos de sensores poderia aprimorar alguns aspectos do

desempenho do robô. Por exemplo, uma bússola poderia contribuir para um controle

de rotações mais preciso e sensores de distância possibilitariam que o robô evitasse

colisões automaticamente. Outros tipos de sensores ainda poderiam ser adicionados

para o robô de modo que ele pudesse executar outra tarefa além de jogar futebol.

Os desafios ficam por conta de interfacear o sensor escolhido corretamente com o

microcontrolador e implementar a lógica responsável por enviar as leituras do sensor

para a estação base.

4.3.3 Microcontrolador

O microcontrolador utilizado no desenvolvimento do projeto, o Axon, atende a

todos os requisitos, no entanto sugere-se que uma equipe que venha a dar

continuidade ao projeto o substitua por um microcontrolador Axon II, pois ele

possibilita uma maior flexibilidade na adição de novos componentes e é totalmente

compatível com o firmware desenvolvido para o Axon.

106

4.3.4 Inteligência artificial

Uma inteligência artificial desenvolvida de modo a se comunicar com o

framework desenvolvido possibilitaria que o robô fosse utilizado para cumprir

diversas tarefas, entre elas participar de competições de futebol de robôs.

4.3.5 Comunicação

A comunicação pode ser melhorada em diversos aspectos, por exemplo, a

utilização de módulos Xbee com maior alcance e capacidade de transmissão.

Existem também pontos a ser melhorados no protocolo de comunicação, como por

exemplo detecção de força do sinal e tratamento de problemas diversos de

comunicação.

107

5 REFERÊNCIAS

" Lista de microcontroladores AVR." Digikey. n.d.

http://ca.digikey.com/1/4/indexe18.html.

"Arduíno Mega 2560." n.d. http://arduino.cc/en/Main/ArduinoBoardMega2560

(accessed Abril 30, 2011).

"ATMega328 28 pin DIP with Bootloader." n.d.

http://www.spikenzielabs.com/Catalog/index.php?main_page=index&manufact

urers_id=14 (accessed Abril 2011, 2011).

"Axon Microcontroller Description." Society of robots. n.d.

http://www.societyofrobots.com/axon/ (accessed Março 2, 2011).

"Controle PID básico, UFSC." DAS. n.d.

http://www.das.ufsc.br/~aarc/ensino/posgraduacao/DAS6613/PID_Novus.pdf

(accessed MAIO 2, 2011).

Digi International. Digi International. n.d. http://www.digi.com/.

Fairchild, semiconductor Corporation. Slotted optical switch H22A1. 2001.

Kurpiel, Francisco Delmar, Leandro Piekarski do Nascimento, Marcelo Massao

Kataoka Higaskino, and Ricardo Fantin da Costa. "Sistema de navegação do

robô omnidirecional." Curitiba, 2010.

MaxStream. Xbee/Xbee-PRO OEM RF Modules Manual. Lindon, UT, USA.

National Semicondutor. LM117/LM317A/LM317 3-Terminal Adjustable Regulator.

Março 1996.

NetBeans. Develop desktop, mobile and web applications with Java, PHP, C/C++

and more. Oracle Corporation, 2011.

108

Nishibe, Caio Arce, John Théo Sierpinski de Souza, Renato Girardi Gasoto, Thiago

Avelino da Silva, and Tui Alexandre Ono Baraniuk. "Desenvolvimento de

Sistema de Controle Sem Fio Para Robô Omnidirecional." Curitiba, 2010.

Software technologies, group. "How does ZigBee compare with other wireless

standards?" 2009. http://www.stg.com/wireless/ZigBee_comp.html.

STMicroelectronics. DUAL FULL-BRIDGE DRIVER. 2000.

Tavares, Fernando Perez. "RoboFEI." 2007.

109

6 ANEXOS

6.1 PLANEJAMENTO DE RISCO

Segue abaixo os planos para resposta ao risco.

Projeto: Robofut

1 Etapa:Identificação do Risco

Denominação do risco: Atraso no recebimento de componentes

pelos fornecedores.

N Identificação 01

Descrição do risco: Os componentes comprados podem sofrer atraso na entrega

por razões diversas.

2 Etapa:Avaliação do Risco

Impacto: 5(alto)4(média/alto)3(médio) 2(médio/baixo) 1(baixo) Explique: Sem os componentes solicitados, não é possível montar o artefato e realizar os

testes iniciais, atrasando todo o cronograma.

Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa)1 (baixa) Explique: A solicitação dos componentes aos fabricantes é feito com antecedência e folga

suficiente para comportar atrasos nas entregas.

3 Etapa:Desenvolvimento da Resposta ao Risco

AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO

Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Solicitar os componentes necessários aos fabricantes com antecedência suficiente para permitir atrasos nas entregas. Transferir: - Mitigar: Dedicar tempo maior na fase de montagem e testes do artefato para compensar o tempo perdido. Aceitar: -

Impacto reavaliado:3 Probabilidade reavaliada:2

Elaborado por: Ari Magagnin Junior,

Eduardo Cabral Resende Neiva, Fábio César

Schuartz, João Hamilton Cecato Simas

Data: 23/03/2011

Respostas incluídas na

WBS/Cronograma

Registros adicionais:

VERSO OU ANEXOS

Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

110


Denominação do risco: Queima de componentes integrados com

longo prazo para aquisição.


Descriçãodo risco: Um componente essencial ao projeto pode queimar e o tempo

para sua reposição ser demorado.


Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Não há como estender os prazos para a entrega do artefato, e o projeto ficará

paralisado sem os componentes para sua confecção.

Probabilidade: 5(alta) 4(média/alta) 3(média)2(média/baixa) 1 (baixa) Explique: Um componente pode queimar por diversas razões, desde o seu manuseio incorreto

até distrações durante sua soldagem.



Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Realizar a compra de componentes de reserva, caso seja um componente vital e seu prazo de entrega muito grande. Sempre verificar a montagem dos componentes no circuito por outro membro do grupo. Transferir: - Mitigar: Procurar por um componente substituto ou outro fornecedor que possa entregar o componente em um prazo menor, mesmo a um custo maior. Aceitar: -

Impacto reavaliado: 4 Probabilidade reavaliada: 2




Data: 23/03/2011


WBS/Cronograma


VERSO OU ANEXOS


111


Denominação do risco: Problemas com a comunicação sem fio.


Descrição do risco: Sem comunicação o robô não executará nenhum comando de

movimentação.


Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Sem comunicação com o artefato, o mesmo não terá nenhuma funcionalidade

operante.

Probabilidade: 5(alta) 4(média/alta)3(média) 2(média/baixa) 1 (baixa) Explique: A comunicação sem fio é complexa e exige alto grau de conhecimento de

protocolos.



Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Estudar a fundo a tecnologia de transmissão sem fio e os protocolos necessários para a comunicação entre a base e o microcontrolador. Transferir: - Mitigar: Não havendo a comunicação sem fio conforme planejado, será necessário mudar a tecnologia de transmissão (Wi-Fi, RF, Bluetooth, etc). Aceitar: -





Data: 23/03/2011


WBS/Cronograma


VERSO OU ANEXOS


112


Denominação do risco: Falta de conhecimento suficiente para

completar o projeto, pelos membros da equipe.


Descrição do risco: Conhecimento insuficiente dos membros da equipe inviabilizará

terminar o projeto.


Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Sem os conhecimentos necessários, o projeto não terminará e o artefato não poderá

ser construído.

Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa)1 (baixa) Explique: Os integrantes do grupo possuem uma base da tecnologia empregada e dos

conceitos envolvidos no projeto.



Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Procurar uma tecnologia que seja compatível com o nível de conhecimento para a construção do artefato, satisfazendo os requisitos e não superestimando os componentes (microcontrolador) a serem utilizados. Transferir: - Mitigar: Estender a carga de estudo em cima do projeto, procurar tecnologias mais simples, caso o grupo esteja no estágio inicial do projeto. Aceitar: -





Data: 23/03/2011


WBS/Cronograma


VERSO OU ANEXOS


113


Denominação do risco: Falta de tempo para a conclusão do

projeto.


Descrição do risco: Tempo não pode ser adquirido, portanto o prazo final não pode

ser estendido.


Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Caso o tempo disponível não seja suficiente, o artefato não poderá ser completado,

invalidando todo o projeto.

Probabilidade: 5(alta) 4(média/alta) 3(média)2(média/baixa) 1 (baixa) Explique: è feito uma avaliação e planejamento prévios, mas imprevistos podem ocorrer

durante o tempo estimado para cada tarefa.



Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Durante o planejamento, estimar os prazos para cada tarefa e considerar folgas entre as mesmas, para que se algo imprevisto aconteça permita a equipe corrigir os problemas atrasados. Transferir: - Mitigar: Diminuir o escopo do trabalho e reduzir os requisitos finais do artefato. Aceitar: -





Data: 23/03/2011


WBS/Cronograma


VERSO OU ANEXOS


114


Denominação do risco: Problemas de saúde de membros da

equipe.


Descrição do risco: Um membro da equipe pode sofrer algum acidente ou ficar

doente.


Impacto: 5(alto)4(média/alto) 3(médio)2(médio/baixo) 1(baixo) Explique: Caso algum membro da equipe fique doente, isso atrasará algum módulo do

projeto, podendo (ou não) atrasar o início de outras etapas, acumulando o atraso.

Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa) Explique: Resfriados e gripes são as formas mais comuns de doenças que podem ocorrer.

Outras doenças tem possibilidade de ocorrer baixa.



Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Cuidar da saúde, não se expor a fatores de risco à saúde desnecessariamente, agasalhar-se bem são algumas formas de prevenção de doenças. Transferir: - Mitigar: Procurar um médico ou especialista o quanto antes a fim que cura-se rapidamente e ter condições para prosseguir o trabalho. Caso seja um curto período de algum dos membros da equipe com algum tipo de problema de saúde, os demais membros compensam o tempo e esforço do colega ausente temporariamente. Aceitar: -





Data: 23/03/2011


WBS/Cronograma


VERSO OU ANEXOS


115


Denominação do risco: Custo real muito acima do custo

estimado, inviabilizando o término do projeto.

N Identificação 8

Descrição do risco: O custo dos materiais pode se tornar muito acima do previsto,

inviabilizando o projeto.


Impacto: 5(alto)4(média/alto)3(médio) 2(médio/baixo) 1(baixo) Explique: Caso o custo do projeto seja muito alto, não haverá possibilidade de completar o

artefato.

Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa) Explique: Utilizar-se-á de componentes individuais com custo reduzido ao invés de circuitos

pré-montados.



Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Fazer um estudo detalhado dos componentes existentes no mercado, quais se adequam ao projeto e que sejam de baixo custo. Escolher componentes que não são superestimados. Transferir: - Mitigar: Reduzir as funcionalidades do artefato, procurar soluções alternativas em componentes mais baratos que possam realizar parte das especificações. Aceitar: -





Data: 23/03/2011


WBS/Cronograma


VERSO OU ANEXOS


116


Denominação do risco: Desistência de algum membro da equipe.

N Identificação 9

Descrição do risco: Um dos integrantes do grupo desiste do projeto e/ou da disciplina.


Impacto: 5(alto)4(média/alto)3(médio) 2(médio/baixo) 1(baixo) Explique: Caso um membro da equipe desista da disciplina, os demais integrantes podem não

conseguir terminar o projeto dentro do tempo previsto.

Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)

Explique: Os integrantes do grupo estão motivados a construírem o artefato.



Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Conversar semanalmente com cada integrante do grupo, definir metas alcançáveis, motivar os integrantes e manter a moral do grupo alta. Transferir: - Mitigar: Redistribuir o restante das tarefas entre os demais membros do grupo, absorvendo o impacto da melhor maneira possível. Aceitar: -





Data: 23/03/2011


WBS/Cronograma


VERSO OU ANEXOS


117


Denominação do risco: Perda ou roubo do artefato.


Descrição do risco: O artefato pode ser roubado ou perdido.


Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Sem o artefato não será possível concluir o projeto.

Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa) Explique: O artefato estará sempre no alcance de algum integrante da equipe.



Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Sempre manter o artefato no campo de visão dos integrantes da equipe, verificar sempre duas vezes a posse do artefato antes de deixar um laboratório, nunca deixar o artefato sozinho por motivo algum. Transferir: - Mitigar: Procurar o quanto antes o local onde fora deixado o objeto e buscar informações para tentar encontra-lo a mais rápido possível. Aceitar: -





Data: 23/03/2011


WBS/Cronograma


VERSO OU ANEXOS


118

6.2 GANT DE CARGA FINAL

6.2.1 Gant Individual

Figura 57:Fábio Figura 56:João

119

Figura 59:Eduardo

Figura 58:Ari

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ …fabro/IF66J/Relatorios_Finais/2011_1/... · Fonte:...

Documents

Transcript of UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ …fabro/IF66J/Relatorios_Finais/2011_1/... · Fonte:...