UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN DEPARTAMENTO ACADMICO DE ELETRNICA/INFORMATICA CURSO DE ENGENHARIA DE COMPUTAO

MONOGRAFIA

ROBOFUT - PROJETO DE INICIAO DE UM ROB PARA A ROBOCUP

ARI MAGAGNIN JUNIOR EDUARDO CABRAL RESENDE NEIVA JOO HAMILTON CECATO SIMAS

CURITIBA 2011

ARI MAGAGNIN JUNIOR EDUARDO CABRAL RESENDE NEIVA JOO HAMILTON CECATO SIMAS

ROBOFUT - PROJETO DE INICIAO DE UM ROB PARA A ROBOCUP

Monografia apresentada como requisito para aprovao na disciplina de Oficina de Integrao 3, ministrada pelos professores: Prof. Dr. Joo Alberto Fabro Prof. Dr. Heitor Silvrio 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 comunicao sem fio e uma estao-base capaz de controlar vrios robs, bem como documentar e explicar as decises de projeto tomadas. O objetivo do projeto prover uma plataforma confivel que, comandada por uma inteligncia artificial, seja capaz de participar de competies de futebol de robs. Palavras-chave Futebol de Robs, RoboCup, Comunicao Wireless.

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

Sumrio
1 1.1 1.2 1.2.1 1.2.2 1.2.3 1.3 2 2.1 2.2 2.3 2.4 2.5 2.6 2.6.1 2.6.2 INTRODUO ........................................................................................... 15 MOTIVAO.............................................................................................. 15 TRABALHOS CORRELATOS .................................................................... 15 Omni ......................................................................................................... 15 Omni ......................................................................................................... 17 RoboFEI ..................................................................................................... 17 OBJETIVOS ............................................................................................... 18 PLANEJAMENTO ..................................................................................... 20 DECLARAO DO ENCOPO EM ALTO-NVEL ....................................... 20 PREMISSAS E RESTRIES................................................................... 20 DESIGNAO DO GERENTE E DA EQUIPE ........................................... 21 PLANEJAMENTO DE RISCOS.................................................................. 21 REQUISITOS ............................................................................................. 21 ALTERNTIVA TECNOLGICA .................................................................. 23 Estao base ............................................................................................. 23 Linguagem de programao ...................................................................... 23 2.6.2.1 JAVA ............................................................................................................ 23 2.6.2.2 C ................................................................................................................... 24 SISTEMA DE COMUNICAO ................................................................. 25 SISTEMA EMBARCADO ........................................................................... 26 Ponte-H ...................................................................................................... 27 2.8.1.1 Ponte-H utilizando componentes discretos................................................... 27 2.8.1.2 L298N ........................................................................................................... 27 2.8.1.3 Comparao e escolha da ponte-H ............................................................... 27 MICROCONTROLADOR ........................................................................... 28 Atmega328 ................................................................................................. 28 DSPIC30F3010 .......................................................................................... 29 Atmega 640 ................................................................................................ 29 Atmega2560 ............................................................................................... 30 C8051F340 ................................................................................................ 31 Comparao e escolha do microcontrolador .............................................. 31 ORAMENTO INICIAL DETALHADO PREVISTO .................................... 32 ORAMENTRO DETALHADO GASTO ..................................................... 35 CRONOGRAMA ......................................................................................... 36 ENTREGVEIS .......................................................................................... 39 AUXILIARES DE GERENCIAMENTO ....................................................... 39 EXECUO ............................................................................................... 41

2.7 2.8 2.8.1

2.9 2.9.1 2.9.2 2.9.3 2.9.4 2.9.5 2.9.6 2.10 2.11 2.12 2.13 2.14 3

vii 3.1 3.2 3.2.1 ARQUITETURA GERAL DO HARDWARE E SOFTWARE........................ 41

ESTAO-BASE ....................................................................................... 42 Framework ................................................................................................. 42 3.2.1.1 Parser ............................................................................................................ 45 3.2.2 Interface Grfica ......................................................................................... 47 3.3 3.3.1 3.3.2 SISTEMA DE COMUNICAO ................................................................. 48 Mdulos de comunicao........................................................................... 48 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 comunicao ......................................................................... 62 3.3.3.1 Transmisso .................................................................................................. 62 3.3.3.2 Recepo ....................................................................................................... 64 3.3.4 Casos de comunicao .............................................................................. 65 3.3.4.1 Iniciao do rob .......................................................................................... 65 3.3.4.2 Mensagem com requisio de resposta ........................................................ 67 3.3.4.3 Mensagem de atuao do rob ..................................................................... 67 3.4 3.4.1 3.4.2 3.4.3 3.4.4 SISTEMA EMBARCADO ........................................................................... 69 Software Embarcado .................................................................................. 69 Webbotlib 1.31 ........................................................................................... 69 Inicializao do programa .......................................................................... 70 Funcionamento normal viso geral ......................................................... 72 3.4.4.1 Controle ........................................................................................................ 73 3.4.4.2 Incio da comunicao .................................................................................. 74 3.4.4.3 Tratamento de mensagens ps-sincronizao com estao base .................. 75 3.4.4.4 Controle da rampa ........................................................................................ 78 3.4.5 Componentes ............................................................................................. 79 3.4.5.1 Regulador de tenso 7805............................................................................. 79 3.4.5.2 Regulador de tenso 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 Viso geral das conexes da Camada 1 da PCI ............................................ 92 3.4.6.2 Viso geral das conexes da Camada 2 da PCI ............................................ 95 3.4.6.3 Esquemtico das camadas enviado para a prototipao ............................... 97 4 4.1 4.1.1 CONCLUSES ........................................................................................ 100 ANLISE DO DESENVOLVIMENTO ....................................................... 100 Riscos Relevantes ................................................................................... 100 4.1.1.1 Atraso no recebimento de componentes pelos fornecedores ...................... 100 4.1.1.2 Problemas com a comunicao 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 concluso do projeto .................................................. 102 4.1.2 Consideraes finais sobre o desenvolvimento ....................................... 102 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 5 6 6.1 6.2 6.2.1 INTEGRAO ......................................................................................... 102 Controle.................................................................................................... 103 Sistemas Microcontrolados ...................................................................... 103 Comunicao de dados ........................................................................... 103 Eletrnica 2 .............................................................................................. 104 Anlise e projeto de sistemas e Engenharia de Software ........................ 104 TRABALHOS FUTUROS ......................................................................... 104 Driblador e chutador ................................................................................. 105 Adio de sensores .................................................................................. 105 Microcontrolador ...................................................................................... 105 Inteligncia artificial .................................................................................. 106 Comunicao ........................................................................................... 106 REFERNCIAS ....................................................................................... 107 ANEXOS .................................................................................................. 109 PLANEJAMENTO DE RISCO .................................................................. 109 GANT DE CARGA FINAL ........................................................................ 118 Gant Individual ......................................................................................... 118

ix

Lista de ilustraes
Figura 1: Omni Fonte: (Nishibe, et al. 2010) ............................................................ 16 Figura 2: RoboFEI Fonte: (Tavares 2007). ............................................................... 18 Figura 3: Proposta de interface com o usurio da estao base. Fonte: Autoria prpria. ..................................................................................... 23 Figura 4: L298. Fonte: (STMicroelectronics 2000) .................................................... 27 Figura 5: Caractersticas necessrias do microcontrolador. Fonte: Autoria prpria. ................................................................................................. 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: Comparao Microcontroladores. Fonte: (Axon Microcontroller Description s.d.) (Arduno Mega 2560 s.d.) .......................................... 32 Figura 10: Microcontrolador Axon. Fonte: (Axon Microcontroller Description s.d.) ...................................................................................................... 32 Figura 11: Arquitetura geral do sistema Fonte: Autoria Prpria................................. 41 Figura 12: Diagrama de classes da Estao-Base Fonte: Autoria Prpria ................ 42 Figura 13: Diagrama de atividades do algoritmo do buffer. Fonte: Autoria Prpria.................................................................................................. 45 Figura 14: Estrutura dos comandos do parser. Fonte: Autoria Prpria ..................... 46 Figura 15: Layout da interface grfica. Fonte: Autoria Prpria .................................. 47 Figura 16: Mdulo Xbee Series 1 Fonte: (Digi International n.d.) .............................. 49 Figura 17: Estrutura do Frame Fonte: (MaxStream USA). ....................................... 51 Figura 18: Data Frame e estrutura especfica 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: Mquina de estados da transmisso 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 estao-base e rob, viso geral Fonte: Autoria Prpria. ......................................................................... 65 Figura 24: Diagrama de atividades para iniciao do rob visto pelo rob Fonte: Autoria Prpria .......................................................................... 66 Figura 25: Diagrama exemplo de uma requisio da leitura dos nveis de bateria Fonte: Autoria prpria ............................................................... 66

x Figura 26: Diagrama de atividades da resposta do rob em relao a mensagens de requisio de leitura de sensores. Fonte: Autoria prpria ...................................................................................... 67 Figura 27: Diagrama de atividades do rob para o recebimento de uma mensagem do tipo atuadora. Fonte: Autoria Prpria ............................ 68 Figura 28: Exemplo de envio de mensagem do tipo atuadora Fonte: Autoria prpria .................................................................................................. 68 Figura 29: Viso do software para testes em alto nvel. ............................................ 69 Figura 30: Sequncia de comandos para inicializao do Firmware Fonte: Autoria prpria ...................................................................................... 71 Figura 31: Viso geral do firmware, uma abordagem de alto nvel Fonte: Autoria prpria ...................................................................................... 72 Figura 32: Diagrama de controle Fonte: Autoria prpria ........................................... 74 Figura 33: Diagrama que mostra o cadastro do firmware na viso do rob Fonte: Autoria prpria........................................................................... 75 Figura 34: Diagrama de resposta do firmware para o fluxo de decodificao de uma mensagem de atuao nos motores Fonte: Autoria Prpria.................................................................................................. 76 Figura 35: Diagrama de resposta do firmware para o fluxo de resposta a uma solicitao da estao base. Fonte: Autoria prpria ............................. 77 Figura 36: Rampa de descida. .................................................................................. 78 Figura 37: Projeto do regulador 7805 presente no datasheet. Fonte: (Fairchild 2001) .................................................................................... 79 Figura 38: Esquemtico do LM317. Fonte: (National Semicondutor 1996). ............. 80 Figura 39: Divisor de tenso. Autoria prpria. ........................................................... 82 Figura 40: Pinos do Xbee. Fonte: (MaxStream USA). .............................................. 83 Figura 41: Projeto de ligao do Xbee na PCI final. Fonte: Autoria prpria. ............. 83 Figura 42: Esquema da chave tica H22A1. Fonte: (Fairchild 2001) ........................ 85 Figura 43: Esquema de ligao da chave tica do encoder na PCI. Fonte: Autoria prpria ...................................................................................... 86 Figura 44: Esquemtico e pinos do Optoacoplador 4N35. Fonte: (Fairchild 2001) .................................................................................................... 88 Figura 45: Projeto dos optoacopladores na PCI. Fonte: Autoria prpria. .................. 88 Figura 46: Esquema de ligao das duas pontes-H do L298. Fonte: (STMicroelectronics 2000) ................................................................... 90 Figura 47: Ponte-H L298. Fonte: (STMicroelectronics 2000) .................................... 91 Figura 48: PCI provisria. Fonte: Autoria prpria ...................................................... 92 Figura 49: Ligaes da Camada 1 da PCI final. Fonte: Autoria prpria. ................... 94 Figura 50: Ligaes da camada 2 da PCI final. Fonte: Autoria prpria ..................... 96

xi Figura 51: Esquemtico da camada 2 da PCI final enviada para prototipao. Fonte: Autoria prpria........................................................................... 97 Figura 52: Camada 2 da PCI final antes de soldar. Fonte: Autoria prpria. .............. 98 Figura 53: Camadas 1 e camada 2 sobrepostas. Fonte: Autoria prpria. ................. 98 Figura 54: Esquemtico da camada 1 da PCI final enviada para prototipao. Fonte: Autoria prpria........................................................................... 99 Figura 55: Camada 1 da PCI final antes de soldar. Fonte: Autoria prpria. .............. 99 Figura 56:Joo ........................................................................................................ 118 Figura 57:Fbio ....................................................................................................... 118 Figura 58:Ari 119 Figura 59:Eduardo ................................................................................................... 119

xii

Lista de tabelas
Tabela 1: Requisitos do rob. Fonte: Autoria prpria. ............................................... 21 Tabela 2: Requisitos do da comunicao. Fonte: Autoria prpria. ............................ 22 Tabela 3: Requisitos da estao base. Fonte: Autoria prpria. ................................. 22 Tabela 4: Tabela de comparao de alternativos de comunicao sem fio. Fonte: (Software technologies, group 2009) ........................................ 25 Tabela 5: Gastos com recursos humanos. Fonte: Autoria prpria. ........................... 35 Tabela 6: Oramento real. Fonte: Autoria prpria. .................................................... 36 Tabela 7: Cronograma. Fonte: autoria prpria. ......................................................... 38 Tabela 8: Entregveis. Fonte: Autoria propria. .......................................................... 39 Tabela 9: Auxiliares de gerenciamento. Fonte: Autoria prpria. ................................ 39 Tabela 10: Formato padro de mensagem Fonte: Autoria prpria ............................ 50 Tabela 11: Baud Rate para valores de BD Fonte: Autoria Prpria ............................ 54 Tabela 12: Estrutura da mensagem Fonte: Autoria Prpria ...................................... 55 Tabela 13: Estrutura de uma mensagem de andar para frente (0x26) Fonte: Autoria Prpria ..................................................................................... 55 Tabela 14: Estrutura de uma mensagem de ir para frente (0x27) Fonte: Autoria Prpria ..................................................................................... 56 Tabela 15: Estrutura de uma mensagem de girar no sentido horrio (0x28) Fonte: Autoria Prpria .......................................................................... 57 Tabela 16: Estrutura de uma mensagem de girar anti-horrio (0x29) Fonte: Autoria Prpria ..................................................................................... 57 Tabela 17: Estrutura da mensagem para o movimento em uma direo Fonte: Autoria Prpria ..................................................................................... 58 Tabela 18: Estrutura de mensagem para ligar/desligar driblador Fonte: Autoria Prpria ..................................................................................... 58 Tabela 19: Estrutura de mensagem para acionar o chutador Fonte: Autoria prpria .................................................................................................. 59 Tabela 20: Estrutura de mensagem para solicitar leitura de sensores Fonte: Autoria Prpria ..................................................................................... 59 Tabela 21: Estrutura de mensagem de resposta de leitura de sensores Fonte: Autoria prpria ...................................................................................... 59 Tabela 22: Estrutura de mensagem para solicitao de cadastro na estao base Fonte: Autoria prpria .................................................................. 60 Tabela 23: Estrutura de mensagem para incluso de um rob em uma estao central. Fonte: Autoria Prpria ................................................ 60

xiii Tabela 24: Estrutura de mensagem para confirmao de dispositivo ativo Fonte: Autoria Prpria .......................................................................... 61 Tabela 25: Estrutura de mensagem para um ACK Fonte: Autoria Prpria ................ 61 Tabela 26: Tipos de comandos Fonte: Autoria prpria .............................................. 62 Tabela 27: Controle PID bsico. Fonte (Controle PID bsico, UFSC s.d.). ............... 73

xiv

ABREVIATURAS

Sigla ACK API LED LSB MSB NACK PID PCI PWM RF RSSI RX SMD TX` UART UTFPR USB IR I/O

Significado 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 Radio Frequency Received Signal Strength Indication Receive Surface Mount Device Transmit Universal Asynchronous Receiver Transmitter Universidade Tecnolgica Federal do Paran Universal Serial Bus Infrared rays In/out

15

1 INTRODUO
O projeto consiste no desenvolvimento de um sistema capaz de controlar robs atravs do envio de comandos sem-fio por uma estao-base instalada em um computador. 1.1 MOTIVAO A escolha por esse projeto foi motivada inicialmente pelo desejo da universidade em participar de competies de futebol de robs com um projeto completamente desenvolvido por alunos da prpria universidade. No momento do inicio do desenvolvimento do projeto, a universidade competia com robs comprados de uma empresa especializada e somente era responsvel pela programao da inteligncia do rob. Visando eliminar essa dependncia de tecnologia externa, foi proposto que a equipe desenvolvesse um projeto que englobasse os aspectos de hardware, comunicao e software dos robs, projeto esse que seria acoplado atual mecnica dos robs, em detrimento da tecnologia comprada anteriormente. 1.2 TRABALHOS CORRELATOS O projeto proposto tem caractersticas muito similares diversos outros projetos desenvolvidos, inclusive dentro da prpria UTFPR (Universidade

Tecnolgica 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 diferena o tamanho dos robs em questo. O projeto Omni consiste em uma plataforma mecnica com 3 rodas com motores dispostas de maneira a conseguir movimento omnidirecional, um hardware embarcado capaz de acionar os motores, receber informaes dos sensores em cada roda e assegurar que o sistema seria capaz de receber e interpretar comandos enviados de maneira sem fio pela estao-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 estao-base, opo essa que tambm foi analisada pela equipe. Uma vez que eles obtiveram sucesso utilizando Java, pode-se reforar a convico de que utilizar a mesma tecnologia seria suficiente para atender aos requisitos desse projeto tambm. O grande aprendizado que pde ser extrado do estudo de caso do Omni foi sem dvida a questo da expansibilidade. O projeto atendeu aos requisitos aos quais ele se props, no entanto o microprocessador escolhido para o sistema embarcado deixava uma margem para expanses 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 decises desse projeto a questo da expansibilidade, de modo que uma equipe possa posteriormente dar continuidade ao rob com o mnimo de retrabalho possvel.

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 bssola e sensores de distncia, bem como aprimorar outros aspectos no 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 perifricos e ports de entrada e sada. O microcontrolador escolhido pela equipe pertence mesma famlia do Arduino Mega, sendo a nica diferena entre eles o acesso aos perifricos e a dimenso da placa em que o chip est acomodado. Como a dimenso do rob a ser desenvolvido inferior dimenso dos dois robs 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 iniciao cientfica desenvolvido pelo aluno Fernando Perez Tavares no Centro Universitrio 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 mecnica, sendo que no caso desse projeto a base mecnica j est pronta e cabe a equipe somente desenvolver o hardware e o software responsvel 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 robs. O sistema pode ser dividido em 3 subsistemas, sendo eles o sistema embarcado, o sistema de comunicao e o sistema da estao-base, cada qual com seus objetivos e requisitos especficos. A estao-base deve ser capaz de enviar comandos para o rob atravs de uma interface grfica e deve controlar quais robs esto aptos a receber instrues. Ela tambm deve possuir um framework de modo que uma inteligncia artificial possa executar acoplada a ela enviando os comandos aos robs. O sistema de comunicao deve ser capaz de enviar os comandos de modo sem fio para os robs e garantir que todos os robs recebam seus respectivos comandos, bem como garantir que no haja conflitos de comunicao.

19

O sistema embarcado deve ser capaz de interpretar os comandos recebidos e acionar os componentes eletrnicos necessrios para executar o comando enviado pela base.

20

2 PLANEJAMENTO
2.1 DECLARAO DO ENCOPO EM ALTO-NVEL O sistema embarcado conter um microcontrolador o qual possuir um firmware para controle do rob, um sistema de comunicao sem fio com o computador (estao base) que possuir um software de controle de velocidade e posio dos robs, capaz de movimentar-los, para frente e para trs, alm de rotaes no sentido horrio e anti horrio. 2.2 PREMISSAS E RESTRIES Deixa-se claro que com o trmino do projeto ainda no ser possvel a participao de nosso rob nos jogos de futebol de robs, pois o chutador e o prendedor de bola ou tambm chamado de driblador no sero implementados no projeto, entretanto ele ser construdo de modo que futuramente outros projetos o aprimorem incluindo novas funcionalidades. Estar disponvel a nossa equipe a base mecnica do rob que contm motores, encoders, rodas, e baterias j instaladas alm de um espao fsico dentro do rob para a alocao do sistema a ser construdo. Ela no ser construda pois a tempo que seria gasto na etapa de planejamento e construo da mesma seria demasiadamente grande para prejudicar o decorrer do projeto. Considera-se que o local onde o rob ser utilizado no contenha imperfeies e seja adequado para a roda utilizada alm de que ele esteja dentro do alcance mximo do sistema de comunicao e que exista um computador disponvel para que o software da estao base seja executado. Alm desses aspectos do projeto considera-se que no haja atraso de entrega de componentes quando estivermos no perodo de implementao. O microcontrolador dever conter pinos de I/O sobrando afim de proporcionar futuras implementaes como o driblador e chutador. O protocolo dever ter alm de comandos especficos do rob desse projeto que no omnidirecioal dever possuir suporte para robs omnidirecionais.

21

opo

tecnolgica

escolhida

no

deve

ultrapassar

oramento

preestabelecido, a no ser que seja realmente necessrio. O tempo de execuo do projeto no pode exceder e para que no haja imprevistos durante o decorrer do cronograma bem como imperfeies necessrio que o cronograma seja seguido de modo mais fiel possvel, pois no h tempo de folga entre os prazos. 2.3 DESIGNAO DO GERENTE E DA EQUIPE Gerente: Ari Magagnin Junior Colaboradores: Eduardo Cabral Resende Neiva, Joo Hamilton Cecato Simas 2.4 PLANEJAMENTO DE RISCOS Os relatrios com os planos de resposta ao risco so apresentados em anexo. 2.5 REQUISITOS 1. Requisitos do rob:
Requisitos Rob Especificao Rob Possuir trs rodas com discos pequenos em torno da circunferncia que so perpendiculares direo de laminao para, acopladas em motores DC, que possam ser acionados nas duas direes atravs de um circuito de ponte-H.

Se locomover com dois graus de liberdade em um plano.

Locomover-se com velocidade e Os motores sero controlados por PWM com realimentao acelerao controlada numa direo atravs dos encoders para o sistema de controle Proporcionaldada e por uma distncia prIntegral derivativo. determinada. Medir a distncia percorrida. Calibrar os encoders de forma a conhecer a distncia percorrida em determinada direo. Alimentar os motores utilizando dois bancos de pilhas AA e o microcontrolador ser alimentado por uma bateria separada de 9V para evitar interferncia por induo dos motores.

Ser alimentado com baterias.

Tabela 1: Requisitos do rob. Fonte: Autoria prpria.

2. Requisitos da comunicao:

22

Requisitos - Comunicao

Especificao Comunicao

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

Utilizar um equipamento que permita comunicao bidirecional com um alcance mnimo de 20 metros.

Garantir a integridade dos pacotes recebidos pela base.

Especificar um protocolo que permita a deteco de erros e contemple reenvio de pacotes perdidos.

Baixo consumo de energia.

A alimentao do sistema de comunicao deve ser inferior a 9V e deve consumir a menor energia possvel de modo a garantir uma boa autonomia do rob.

O sistema de comunicao deve possuir uma taxa de transferncia mnima para suportar o protocolo.

O sistema de comunicao deve ser capaz de transferir no mnimo 50kbps.

Tabela 2: Requisitos do da comunicao. Fonte: Autoria prpria.

3. Requisitos da estao base:

Requisitos Estao Base A estao base deve ser capaz de controlar 5 robs. Especificao Estao Base O sistema de comunicao e a interface devem ser capazes de controlar at cinco robs e garantir a integridade de informao para todos eles.

A estao base deve ser capaz de enviar comandos de movimento e direo para os robs

Cada comando enviado pela base para cada rob deve consistir em uma direo e uma distncia a ser percorrida, de modo que o prprio rob faa uso de seu sistema de controle para executar o comando.

Tabela 3: Requisitos da estao base. Fonte: Autoria prpria.

Existem ainda outros requisitos no funcionais, que proporcionam maior flexibilidade ao desenvolvimento do projeto, bem como ao produto final: 1. Interface grfica de fcil manuseio; 2. Multiplataforma; 3. Orientada a objetos; 4. Ferramentas de desenvolvimento de boa qualidade e sem custo.

23

2.6

ALTERNTIVA TECNOLGICA

2.6.1 Estao base A estao base consiste em um computador com uma plataforma capaz de executar a linguagem escolhida. A interface com o usurio proposta mostrada na Figura 3. A interface consiste em alguns campos, como o de seleo do rob que executar o comando e um campo de informaes do comando que ser executado. Ainda existe outro campo em que o usurio mandar uma linha de comando preestabelecida para do rob.

Figura 3: Proposta de interface com o usurio da estao base. Fonte: Autoria prpria.

2.6.2 Linguagem de programao 2.6.2.1 JAVA A primeira linguagem de programao a ser estudada a Java. Esta linguagem tem suporte extensivo comunicao serial atravs de bibliotecas, ajudando a concluir um dos requisitos necessrios. Ela tambm possibilita que seja

24

desenvolvido um framework com todas as sub-rotinas de comunicao com o rob, de modo que um prximo projeto (por exemplo, construir a inteligncia do rob) bastaria apenas estudar a documentao 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 tambm possibilita o desenvolvimento de interfaces grficas de maneira muito simples, facilitando no processo de construo e demonstrao do produto final. Outras caractersticas importantes da plataforma Java so 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 opo atende ao requisito mais importante, e possui aspectos que permite um desenvolvimento significativo da estao.

2.6.2.2 C A linguagem de programao C atende aos requisitos primrios do projeto, que so comunicao serial e possibilidade de desenvolver framework. No entanto, ela tem algumas limitaes que podem dificultar o desenvolvimento do projeto e prejudicar o produto final. Essas limitaes so principalmente os fatos de no ser orientada a objeto, dificultando o desenvolvimento, organizao e documentao dos cdigos-fonte. Ela tambm no multiplataforma, ou seja, compilando o cdigo em uma plataforma, por exemplo, no Windows, resulta em um programa que no pode ser utilizado em outras plataformas, como, por exemplo, no Linux. Com relao s ferramentas de desenvolvimento, existem opes sem custos, mas com srias limitaes como, por exemplo, o Dev C++ - e opes com custo alto, que so excelentes ambientes de desenvolvimento, por exemplo, Visual Studio.

25

2.7

SISTEMA DE COMUNICAO O sistema de comunicao ser responsvel por conectar o computador a

vrios robs. Dentre os sistemas mais utilizados, citado as principais caractersticas de cada um na e compar-las com os requisitos necessrios ao projeto, eliminando as tecnologias no cabveis.
ZigBee 802.11 ( Wi-Fi ) Bluetooth IR Wireless 20-40 Kbits/s Velocidade de transmisso de dados 20, 40 e 250 Kbits/s 115 Kbits/s 11 e 54 Mbits/sec 1 Mbits/s 4 Mbits/s < 10 metros Alcance 10 - 100 metros 50 - 100 metros 10 metros (linha de viso)

Topologia de rede Complexidade Consumo de Energia

Ad-hoc, peer to peer ou mesh Baixa Muito baixo

Ponto at hub

Ad-hoc, redes muito pequenas Alta Mdio

Ponto a Ponto

Alta Alto

Baixa Baixo

Tabela 4: Tabela de comparao de alternativos de comunicao 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 comunicao de baixo consumo uma boa alternativa. Entre as tecnologias expostas acima temos ZigBee e IR (comunicao atravs de raios infra-vermelho) como opes de baixo consumo. Enquanto as demais alternativas tambm podem ser usadas, elas no so recomendadas devido ao seu consumo de energia. Considerando o alcance como um fator limitante, o alcance mnimo em uma partida da Robocup F180 de 4 metros, tornado todas as tecnologias viveis. Entretanto a IR Wireless exige que os sistemas que se comunicaram estejam em sua linha de viso que ambos enxergam, o que nem sempre pode acontecer. Este fator impossibilita a utilizao do IR Wireless como tecnologia de transmisso.

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 comunicao, algo que como j analisado pode prejudicar o desenvolvimento do projeto. Esse fator o que torna a comunicao Wi-Fi e Bluetooth opes pouco interessantes, ao contrrio do ZigBee, que de baixa complexidade. O ZigBee, ento, a escolha que mais se ajusta ao projeto, alm disso j foi usados em trabalho dos semestres anteriores e apresentou bons resultados.

2.8

SISTEMA EMBARCADO O sistema eletrnico do rob possui uma variedade de componentes e

dispositivos a serem analisados, entretanto apenas foi feito um estudo dos componentes mais crticos descritos nos itens que seguem.

27

2.8.1 Ponte-H O papel da ponte H no sistema embarcado possibilitar a movimentao dos motores em ambos os sentidos, com controle de velocidade. 2.8.1.1 Ponte-H utilizando componentes discretos Ao invs 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 tenso de 16 [V] e outros componentes passivos que suportam tais requisitos que existem no mercado. 2.8.1.2 L298N Componente eletrnico utilizado para controle de motores DC. Possui boa disponibilidade no mercado local e seu preo gira em torno de R$13,00. Pode ser utilizada alimentao de at 46 [V] (sendo que a bateria usada de 16V) e com corrente mxima de at 2 [A], o que est atende as determinaes do projeto.

Figura 4: L298. Fonte: (STMicroelectronics 2000)

2.8.1.3 Comparao e escolha da ponte-H A utilizao do L298 atende os requisitos do projeto alm de ocupar menos espao na PCI, alem disso possui um circuito de proteo de curto internamente. J a ponte-H com componentes discretos pode atender os requisitos se utilizado os componentes adequados, alm de ocupar tempo para a montagem do circuito e no possuir proteo contra curto a no ser que se faa uma sofisticao no circuito.

28

Tais fatores foram preponderantes a ser considerado na escolha de uma tecnologia. Dessa forma foi tornado como melhor opo tecnolgica a ponte-H L298N. 2.9 MICROCONTROLADOR Para controlar o rob, o microcontrolador deve possuir algumas caractersticas:
Mnimo Sadas PWM Timers Pinos I/O livres Suporte para expansibilidade 5 3 (Liberados) 12 UART, SPI ou I2C

Figura 5: Caractersticas necessrias do microcontrolador. Fonte: Autoria prpria.

2.9.1 Atmega328 Microcontrolador conhecido utilizado no Arduino Uno. Esta plataforma possui um conector USB que permite acesso a qualquer computador moderno. Sua programao feita a partir de uma linguagem prpria, chamada Wiring, o que facilita a gravao de programas. A equipe j possui um dispositivo desse, o que reduz os custos. No atende aos requisitos do projeto, pois possui apenas 2 timers disponveis e no 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 caractersticas de DSP. Possui 6 sadas PWM, interface UART, trs interrupes externas e multiplicao 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 no possibilitando futuras expanses. No 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 programao feita por meio do AVR Studio. Possui 6 timers, 55 terminais de entrada e sada e 64 kB de memria interna.

30

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

2.9.4 Atmega2560 O microcontrolador Atmega2560 o mais potente da categoria compatvel com o Arduino, sendo que possui 54 terminais - 14 com possibilidade de PWM, e uma memria interna de 256KB. Sua programao tambm feita em Wiring e possui interfaceamento USB. Ao contrrio do Atmega328, esse microcontrolador s possui verso 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 memria interna e opera a 48 MHz, executando 48 MIPS. Possui tambm 40 portas de I/O e 4 Timers. Ele baseado na arquitetura 8051, diferentemente dos outros

microcontroladores analisados, que so baseados na arquitetura AVR. A grande desvantagem a dimenso da placa, a qual muito grande devido a extensa quantidade de perifricos encontrados nesse microcontrolador. Assim, no possvel acomod-lo na estrutura do rob, inviabilizando a utilizao deste microcontrolador no projeto. 2.9.6 Comparao e escolha do microcontrolador Descartando os microcontroladores que no possuem os requisitos necessrios sobram apenas dispositivos SMD. Isso acaba exigindo a compra de um kit de desenvolvimento, pois a equipe no possui conhecimento suficiente para soldar SMD e a aquisio de uma PCI com complexidade para SMD no de fcil acessibilidade ao grupo tambm. fato que ambos os kits de desenvolvimento possuem as caractersticas necessrias para o desenvolvimento do projeto, sendo que as principais diferenas consistem no Arduino Mega possuir quatro vezes mais memria que o Axon (indiferente para o projeto) e o Axon ocupar uma rea de superfcie 21% menor. Foi escolhido ento o Axon por possuir todos os pinos de PWM disponveis para uso problema enfrentado por projetos anteriores - e ser de tamanho reduzido, permitindo um melhor aproveitamento do espao interno do rob.

Arduino Mega Pinos I/O Digitais PWM Memria Interna Pinos analgicos Consumo Timers Velocidade do Clock 54 14 256 [KB] 16 40mA 6 16Mhz

Axon 55 9 64 [KB] 16 40mA 6 16Mhz

32

Dimenses I2C SRAM EEPROM UART Familiaridade Custo

10,1cm*5,3cm*1,36cm 1 8 [KB] 4 [KB] 3 Alta U$65,00

6,54cm*6,54cm*1,99cm 1 8 [KB] 4 [KB] 3 Baixa U$95,00

Figura 9: Comparao Microcontroladores. Fonte: (Axon Microcontroller Description s.d.) (Arduno Mega 2560 s.d.)

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

2.10 ORAMENTO INICIAL DETALHADO PREVISTO Na primeira tabela encontram-se os custos de materiais necessrios para que haja incio do projeto.

33

Custo de material Quantidade 1 3 2 1 3 5 1 Material Axon 1 L298 Xbee chip antena Xbee Explorer Chave tica H22A1 Optoacopladores PCI de teste Preo por unidade R$ 161,50 R$ 10,88 R$ 39,02 R$ 42,42 R$ 4,50 R$ 1,50 R$ 10,00 Custo dos fretes 1 Frete R$ 90,00 R$ 90,00 Total R$ 161,50 R$ 32,64 R$ 78,03 R$ 42,42 R$ 13,50 R$ 7,50 R$ 10,00

Total dos Custos

R$ 435,59

Do oramento 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 oramento das atividades segue mostrado na Tabela 5: Gastos com recursos humanos. Fonte: Autoria prpria.Tabela 5 que refere-se as horas de trabalhos dos envolvidos no projeto.
Gastos em recursos humanos Execuo Estudo Microcontrolador Ponte H Encoders+motor Optoacoplador Xbee Compra dos componentes Custo R$ 8.604,00 R$ 1.692,00 R$ 1.260,00 R$ 1.008,00 R$ 1.152,00 R$ 1.152,00 R$ 720,00 R$ 720,00

34

Compra Microcontrolador Compra Xbee Compra Optoacoplador Compra ponte H Compra Encoders reserva Compra PCI de teste Testes iniciais Encoder Documentao [Encoder] Ponte H Documentao [Ponte H] Motor DC Documentao [Motor DC] Xbee Documentao [xbee] Optoacoplador Documentao [Optoacoplador] Implementao Diagrama esquemtico Ponte H + Controle Anlise [Ponte H + Controle] Desenvolvimento [Ponte H + Controle] Documentao [Ponte H + Controle] Motor DC Anlise [Motor DC] Desenvolvimento [Motor DC] Documentao [Motor DC] Encoder + Controle Anlise [Encoder + Controle] Desenvolvimento [Encoder + Controle] Documentao [Encoder + Controle] Xbee Anlise [Xbee] Desenvolvimento [Xbee] Documentao [Xbee] Optoacoplador Anlise [Optoacoplador] Desenvolvimento [Optoacoplador] Documentao [Optoacoplador] Testes circuitos Teste sem Xbee Teste com Xbee Anlise [Testes do circuito] Desenvolvimento [Testes do circuito]

R$ 144,00 R$ 144,00 R$ 144,00 R$ 144,00 R$ 144,00 R$ 144,00 R$ 2.592,00 R$ 144,00 R$ 144,00 R$ 144,00 R$ 144,00 R$ 144,00 R$ 90,00 R$ 288,00 R$ 144,00 R$ 288,00 R$ 90,00 R$ 6.192,00 R$ 216,00 R$ 936,00 R$ 288,00 R$ 504,00 R$ 144,00 R$ 1.008,00 R$ 288,00 R$ 576,00 R$ 144,00 R$ 864,00 R$ 144,00 R$ 576,00 R$ 144,00 R$ 2.016,00 R$ 288,00 R$ 1.296,00 R$ 144,00 R$ 864,00 R$ 144,00 R$ 576,00 R$ 144,00 R$ 3.312,00 R$ 288,00 R$ 144,00 R$ 198,00 R$ 288,00

35

Documentao [Testes do circuito] Placa de circuito impresso [PCI] Anlise [PCI] Desenvolvimento [PCI] Documentao [PCI] Programao Estao base Encoder Xbee Controle Integrar mdulos Documentao Parcial [Software] Verificao e testes Teste comunicao+locomoo+base Ajustes finais Documentao Documentao Final [Software] Redigir monografia Criar apresentao Gerenciamento fase 1 Gerenciamento fase 2 Gerenciamento fase 3 Gerenciamento fase 4 TOTAL

R$ 144,00 R$ 576,00 R$ 144,00 R$ 288,00 R$ 126,00 R$ 4.752,00 R$ 864,00 R$ 432,00 R$ 1.008,00 R$ 720,00 R$ 1.008,00 R$ 576,00 R$ 288,00 R$ 144,00 R$ 144,00 R$ 11.448,00 R$ 3.663,36 R$ 7.784,64 R$ 72,00 R$ 1.584,00 R$ 1.440,00 R$ 1.584,00 R$ 1.872,00 R$ 26.532,00

Tabela 5: Gastos com recursos humanos. Fonte: Autoria prpria.

2.11 ORAMENTRO DETALHADO GASTO O oramento detalhado gasto no projeto encontra-se na Tabela 6.
Oramento impresso monografia - previso impresso project charter LN298 LM7805 LM7812 PCI padro Barras de pinos 2 Dip 5 vias Dissipadores Micas Quantidade 1 2 6 4 4 1 6 2 6 1 Custo Custo Total R$ 30,00 R$ 30,00 R$ 1,50 R$ 3,00 R$ 9,90 R$ 59,40 R$ 1,52 R$ 6,08 R$ 3,12 R$ 12,48 R$ 14,10 R$ 14,10 R$ 2,20 R$ 13,20 R$ 1,50 R$ 3,00 R$ 1,50 R$ 9,00 R$ 2,10 R$ 2,10

36

Placa do Xbee xbeestore Conectores KK Cabos flat 74LS14 4N35 Socket 6 pinos Socket 14 pinos Solda - estanho Resistores Capacitores Diodos LED Pilha 9v Axon + frete + imposto 2 Xbee + Xbee Explorer + frete PCI Atmega Total

1 1 1 2 12 18 1 1 1 1 1 4 1 1 1 1 1

R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$

17,89 12,00 20,40 3,80 0,59 0,50 1,00 6,00 5,00 2,00 3,00 0,20 9,00 251,40 163,20 180,00 20,00

R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$ R$

17,89 12,00 20,40 7,60 7,08 9,00 1,00 6,00 5,00 2,00 3,00 0,80 9,00 251,40 163,20 180,00 20,00 867,73

Tabela 6: Oramento real. Fonte: Autoria prpria.

2.12

CRONOGRAMA Na Tabela 7 mostrado o cronograma feito com a utilizao do software

OpenProj indicado pelos professores da disciplina.

37

38

Tabela 7: Cronograma. Fonte: autoria prpria.

39

2.13 ENTREGVEIS
Data 28/04/11 ENTREGVEL 1. Projeto do software que vai rodar na estao base (Interface usurio). 2. Teste com o encoder (Dados) 12/05/11 1. Demonstrao da locomoo do rob rudimentar (apenas movimentos de rotao, na horizontal e vertical) com um cabo ligando o Rob a base (PC). 1. Demonstrao bsica da comunicao sem fio com o Xbee (Hello world). 2. Demonstrao do Software da estao base. 09/06/11 1. Rob capaz de responder comandos mandados pela base (Comandos de direo e distncia a se deslocar). 2. Demonstrao do projeto da PCI da ponte-H.

26/05/11

Tabela 8: Entregveis. Fonte: Autoria propria.

2.14

AUXILIARES DE GERENCIAMENTO A cada fase de execuo do projeto foi determinado um auxiliar de

gerenciamento (sub-gerentes) conforme determinado pelos professores da matria de Oficinas de Integrao 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 1 2 3 4 Auxiliar de gerenciamento Eduardo Cabral Resende Neiva Fbio Csar Schuartz Joo Hamilton Cecato Simas Eduardo Cabral Resende Neiva

Tabela 9: Auxiliares de gerenciamento. Fonte: Autoria prpria.

40

41

3 EXECUO
3.1 ARQUITETURA GERAL DO HARDWARE E SOFTWARE A disposio geral dos componentes dentro do sistema bem como as interligaes entre eles esto delineadas no diagrama da Figura 11.

Figura 11: Arquitetura geral do sistema Fonte: Autoria Prpria

Os comandos enviados pelo usurio do sistema, seja ele um ser humano ou uma inteligncia artificial, so interpretados pelo software da estao base, formatados de acordo com o protocolo de comunicao, enviados para os mdulos 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

ESTAO-BASE O sistema da estao-base aquele que responsvel por interfacear com

usurios humanos, atravs da interface grfica, ou com uma inteligncia artificial, atravs do framework e do parser, e formatar os comandos recebidos para que eles sejam enviados atravs do sistema de comunicao e o rob os execute com sucesso. O software da estao-base foi desenvolvido conforme a modelagem da Figura 12.

Figura 12: Diagrama de classes da Estao-Base Fonte: Autoria Prpria

3.2.1 Framework O Framework a parte do software responsvel por controlar a comunicao com os diversos robs conectados base, bem como prover acesso padronizado s

43

funcionalidades do sistema para um usurio, seja ele uma inteligncia artificial, atravs do parser, ou um ser humano, atravs da interface grfica. Em uma primeira analise do diagrama de classes, pode-se ver um grande pacote chamado framework, que contm as classes desenvolvidas para modelar o problema proposto, e outro pacote chamado xbeeapi que contm as classes pertencentes biblioteca xbeeapi que so utilizadas pelo framework. A classe Rob aquela responsvel por modelar os aspectos relevantes do Rob do ponto de vista da estao-base. O atributo mais importante o endereo 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 prpria biblioteca xbeeapi, que basicamente um nmero de 16 bits que identifica cada mdulo Xbee. H tambm um atributo nome que possibilita que cada rob seja identificado por uma String escolhida pelo usurio. Quanto aos mtodos disponibilizados por essa classe, temos 5 mtodos que basicamente enviam comandos de movimentao para o Rob em questo, sendo eles forward(), backward(), rotateRight(), rotateLeft() e moveOmni(). O construtor da classe Rob necessita dos 2 bytes de endereo e do nome especfico desse Rob, no entanto esses parmetros podem ser alterados posteriormente atravs dos mtodos disponibilizados. H tambm o mtodo getData() que solicita ao Rob o envio de informaes, 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 tambm com o comando a ser enviado j codificado em bytes conforme definido pelo protocolo. O mtodo mais importante dessa classe o getPayload(), que retorna um vetor de bytes, com o comando j codificado, a ser enviado pelo mtodo 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 estao-base, de modo que toda vez

44

que um novo pacote recebido na estao-base disparado o mtodo processResponse() que ir tratar adequadamente o pacote recebido. A classe mais importante do framework sem dvida a classe

CommunicationsHandler. Essa classe gerencia toda a parte de configurao do Xbee, bem como a implementao do buffer de sada. Para enviar um pacote para um Rob o mtodo sendPayload() deve ser chamado. Esse mtodo 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 transmisso malsucedidas, para que ele seja adicionado ao final da fila do buffer de transmisso. O buffer da transmisso funciona conforme o seguinte algoritmo: 1) Tentativa de envio do primeiro BufferItem da fila de transmisso. a) Em caso de sucesso. i) Remove o item da fila de transmisso. ii) Retorna ao passo nmero 1. b) Em caso de timeout. i) Incrementa o contador de tentativas de transmisso. ii) Verifica se o nmero de tentativas mximas foi atingido. (1) Caso sim remove o item da fila de transmisso e notifica o problema de transmisso atravs do console. (2) Caso no move o item para o final da fila de transmisso e retorna ao primeiro passo do algoritmo. O algoritmo tambm pode ser descrito atravs de um diagrama de atividades, mostrado na Figura 13.

45

Figura 13: Diagrama de atividades do algoritmo do buffer. Fonte: Autoria Prpria

O buffer de transmisso juntamente com o parser, que ser detalhado a seguir, possibilita que vrios robs 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 responsvel por transmitir o comando de cada rob atravs de um algoritmo Round Robin modificado. Ele modificado no sentido de que se houverem problemas de comunicao com um dos robs da lista, o buffer ir mover o comando desse rob para o final da fila de transmisso, possibilitando que os outros robs recebam seus comandos mesmo que haja um rob com problemas de comunicao na fila de transmisso. 3.2.1.1 Parser O Parser o componente do framework responsvel por interpretar comandos complexos que envolvem vrios robs e dividi-los em comandos

46

individuais para cada rob para que possam ser adicionados ao buffer de comunicao. A estrutura do comando do parser mostrada na Figura 14:

Figura 14: Estrutura dos comandos do parser. Fonte: Autoria Prpria

A palavra chave que inicia um comando cmd, qualquer palavra diferente dessa invalida o comando e o parser ir notificar que no conseguiu interpretar o comando. Logo aps a palavra de inicio deve-se deixar um espao em branco e ento inserir o primeiro comando a ser enviado. Cada comando estruturado conforme a segunda tabela da Figura 14. A primeira String contm o endereo hexadecimal de 16 bits do rob que deve receber o comando. Logo aps deve ser inserido um delimitador , para que o parser saiba que o endereo terminou. O prximo campo a ser inserido o cdigo da funo a ser enviada para o rob. Uma tabela com os cdigos de funes pode ser encontrada na seo 3.3.2.4 . Outro delimitador , deve ser inserido para ento iniciar a parte dos parmetros do comando. Cada um dos 4 parmetros do comando deve ser inserido aps um delimitador e caso algum parmetro no seja utilizado, deve ser inserido o valor -1 no lugar do parmetro. Aps o quarto parmetro o subcomando 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 endereo 0x1234 ande 0x0AFF (2815) centmetros para frente e que o rob no endereo 0x5678 ande 255 centmetros para trs. Pode-se observar nesse exemplo que os parmetros das funes podem ser passados como nmeros decimais de 0 a 255 ou ento como nmeros

47

hexadecimais de 0x00 at 0xFF. Se a notao utilizada for hexadecimal necessrio preceder o parmetro com o identificador hexadecimal 0x. 3.2.2 Interface Grfica A interface grfica desenvolvida possibilita que um usurio humano tenha acesso fcil s funes do framework e possa testar as funcionalidades do sistema como um todo.

Figura 15: Layout da interface grfica. Fonte: Autoria Prpria

Pode-se observar claramente 3 painis distintos na interface. O primeiro deles fica no canto superior esquerdo do layout, e responsvel por listar todos os robs atualmente conectados estao base. Essa lista atualizada sempre que o framework detecta um novo rob na rede ou quando um rob desconectado por timeout. Os robs aparecem na lista com o nome que lhes foi atribudo e com o endereo do Xbee remoto acoplado a eles dentro de parnteses. O segundo painel,

48

localizado no canto superior direito, responsvel por receber as entradas do usurio e format-las em um comando que possa ser enviado pelo framework, bem como impedir que o usurio envie comandos invlidos. Ele possibilita que o usurio envie comandos individualmente para cada rob conectado na rede de maneira fcil e intuitiva. O terceiro painel, localizado na metade inferior da janela, contm um console que informa ao usurio todas as operaes realizadas pela base, como por exemplo, envio de comandos, alteraes nos parmetros de configurao da porta serial e erros de comunicao, bem como o assistente de configurao da conexo serial e um boto que limpa o console. H tambm nesse painel um campo de onde possvel enviar comandos diretamente ao parser, de modo que o usurio pode montar comandos que afetem 1 ou mais robs, conforme descrito na documentao do parser. 3.3 SISTEMA DE COMUNICAO A parte de sistema de comunicao envolve o protocolo de como ser feito a comunicao. Esse protocolo deve garantir que a transmisso de dados seja bem sucedida e caso haja uma perda de comunicao com o rob o usurio seja devidamente alertado. 3.3.1 Mdulos de comunicao Durante a etapa de planejamento do projeto foram feitos vrios levantamentos com o objetivo de determinar qual tecnologia de comunicao sem fio servia melhor aos propsitos do projeto. Feita essa anlise de opes tecnolgicas, a equipe optou por utilizar o protocolo ZigBee, pois ele oferece baixo consumo, taxas de transferncia suficientes e alcance satisfatrio para os requisitos do projeto, aliados ao custo relativamente baixo em relao s outras tecnologias avaliadas. A etapa seguinte foi selecionar quais mdulos utilizar para realizar essa comunicao. Optou-se por utilizar os mdulos Xbee serie 1, pois so mais utilizados e facilmente encontrados alm de possurem um custo acessvel. Esses mdulos consistem de pequenos circuitos integrados preparados para se comunicar com uma UART, de modo que, tanto o microcontrolador, quanto a estao base podem enviar comandos wireless da mesma maneira que enviariam comandos atravs de um cabo serial

49

comum. Logicamente h todo um formato de frame a ser respeitado bem como outras caractersticas de transmisso que devem ser definidas, a serem discutidas logo abaixo, no entanto esse modelo Black-box dos mdulos facilita muito a implementao da comunicao, pois no existe a preocupao com os nveis mais baixos do processo de transmisso sem fio.

Figura 16: Mdulo Xbee Series 1 Fonte: (Digi International n.d.)

3.3.2 Protocolo Para realizar a comunicao, necessrio estabelecer um formato de transmisso da informao, denominado protocolo de comunicao. Este protocolo possui regras especficas que identificam a origem, o destino e a ao a ser executada. 3.3.2.1 Formato da mensagem Toda mensagem enviada pela estao-base ou pelos robs segue um padro fixo definido que permite o processamento das informaes transmitidas. O

50

contedo da mensagem ter no mximo 100 bytes. Conter um identificador de incio (trs bytes) e fim (trs bytes) que podem ser visto na Tabela 10. 3 bytes Incio 94 Bytes Contedo da mensagem 3 bytes Fim

Tabela 10: Formato padro de mensagem Fonte: Autoria prpria

Como o tamanho mximo da mensagem de 100 bytes (conforme definido na API do Xbee), e que os identificadores de incio e fim ocupam 3 bytes cada, restam 94 bytes para inserir o contedo da mensagem.

3.3.2.2 Encapsulamento da mensagem As mensagens so encapsuladas em frames dentro das operaes do Xbee no modo API. Entre as principais vantagens de utilizar o modo API, esto: Permite o Xbee receber dados de um ou mais Xbee remotos; Quando enviando um pacote, o transmissor recebe uma confirmao (ACK) indicando que o pacote foi recebido com sucesso ou reenvia o pacote caso contrrio; Os pacotes recebidos contm o endereo de origem do transmissor; Obtm o RSSI (potncia 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 incio de um pacote (0x7E) Length: Comprimento da mensagem calculado pelo tamanho da APIspecific structure, esse valor dividido em MSB e LSB.

Checksum: Para calcular o checksum, necessrio somar todo o contedo da mensagem original (excluindo o prprio checksum), aps isso, utilizando apenas os 8 bits menos significativos dessa soma, necessrio retirar de 0xFF esse valor. Desse modo a verificao tornase mais simples, pois para verificar se a mensagem est integra, recalculado o checksum do contedo da mensagem e ento 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 especfica (API-specific Structure) segue o padro:

Figura 18: Data Frame e estrutura especfica de cada API Fonte: (MaxStream USA)

O campo cmdID responsvel por armazenar que tipo de mensagem API estar contida dentro do cmdData. Para cada cmdID, um tipo de operao ser

52

executada pelo Xbee (i.e. 0x01 envio de uma mensagem com destino com endereo de 16 bits).

3.3.2.2.2

Modos API Notveis

3.3.2.2.2.1 TX: 16-bit address

feito uma requisio para transmisso de uma mensagem usando um endereo 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): Endereo de destino da mensagem. 0xFFFF para broadcast. Options (byte 8): Opes extras de como a mensagem ser tratada. 0x01 para desabilitar ACK ou 0x04 para enviar o pacote com o Pan ID do broadcast (no utilizado). RF Data (Byte(s) 9-n): Contedo da mensagem

3.3.2.2.2.2 TX Status

Necessrio 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 0 1 2 3 Definio Sucesso no envido a mensagem No recebeu ACK. Erro CCA (Clear Channel Assessment) Eliminado

3.3.2.2.3

Operaes AT notveis

Operaes AT so necessrias para fazer mudanas de configurao do Xbee. Elas so enviadas como comandos seriais atravs da UART para o Xbee. Para realizar esse tipo de operao necessrio 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 disponveis para endereamento. Para utilizar no modo de 16 bits, que foi utilizado no projeto, necessrio configurar apenas os 16 bits iniciais utilizando a seguinte notao: +++ // 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 comunicao serial. Valor (Hexadecimal) 0 1 2 3 4 5 6 7 Baud Rate (bps) 1200 2400 4800 9600 19200 38400 57600 115200

Tabela 11: Baud Rate para valores de BD Fonte: Autoria Prpria

Exemplo: +++ // Inicia o modo de configurao ATBD6 // Configura o baud rate em 57600bps 3.3.2.3 Estrutura da Mensagem Dentro dos 94 bytes disponveis para o contedo da mensagem, foram utilizados apenas 5 bytes para caracterizar o contedo de uma mensagem. A opo

55

por utilizar um tamanho pequeno de mensagem contribui para reduzir a taxa de erros e aumentar a taxa de pacotes enviados. Byte 1 Tipo Byte 2 Parmetro 1 Byte 3 Parmetro 2 Byte 4 Parmetro 3 Byte 5 Parmetro 4

Tabela 12: Estrutura da mensagem Fonte: Autoria Prpria

O campo Tipo definir que tipo de operao ser utilizado. O campo permite a insero de at 255 tipos de comandos diferentes. Utilizando at 4 parmetros.

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 parmetros de distncia e velocidade. Cdigo do comando: 0x26 Tipos dos parmetros: o Byte 1/2: Valor da distncia em cm, MSB em byte 1 e LSB em byte 2. o Byte 3: Valor da velocidade em cm/s o Byte 4: No utilizado Cdigo 0x26 Byte 1 MSB Distncia Byte 2 LSB Distncia Byte 3 Velocidade Byte 4 -

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

3.3.2.3.1.2 Comando de Andar para Trs

56

Este comando utilizado para mover um rob em linha reta para trs. Utiliza parmetros de distncia e velocidade. Cdigo do comando: 0x27 Tipos dos parmetros: o Byte 1/2: Valor da distncia em cm, MSB em byte 1 e LSB em byte 2. o Byte 3: Valor da velocidade em cm/s o Byte 4: No utilizado

Cdigo 0x27

Byte 1 MSB Distncia

Byte 2 LSB Distncia

Byte 3 Velocidade

Byte 4 -

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

3.3.2.3.1.3 Comando de Girar em sentido horrio

Este comando utilizado para girar um rob no sentido horrio. Utiliza parmetros de angulao e velocidade. Cdigo do comando: 0x28 Tipos dos parmetros: o Byte 1: Velocidade angular (rad/s) o Byte 2: ngulo o Byte 3: No utilizado o Byte 4: No utilizado

57

Cdigo 0x28

Byte 1 Vangular

Byte 2 ngulo

Byte 3 -

Byte 4 -

Tabela 15: Estrutura de uma mensagem de girar no sentido horrio (0x28) Fonte: Autoria Prpria

3.3.2.3.1.4 Comando de Girar Anti-horrio

Este comando utilizado para girar no sentido anti-horrio. Utiliza parmetros de angulao e velocidade. Cdigo do comando: 0x29 Tipos dos parmetros: o Byte 1: Velocidade angular (rad/s) o Byte 2: ngulo o Byte 3: No utilizado o Byte 4: No utilizado

Cdigo 0x29

Byte 1 Vangular

Byte 2 ngulo

Byte 3 -

Byte 4 -

Tabela 16: Estrutura de uma mensagem de girar anti-horrio (0x29) Fonte: Autoria Prpria

3.3.2.3.1.5 Comando de andar em uma direo (x, y).

Este comando utilizado enviar comandos de movimento omnidirecional. Apenas funcional para um rob omnidirecional. Cdigo do comando: 0x30

58

Tipos dos parmetros: 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) o Byte 4: No utilizado

Cdigo 0x30

Byte 1 Eixo X

Byte 2 Eixo Y

Byte 3 Velocidade

Byte 4 -

Tabela 17: Estrutura da mensagem para o movimento em uma direo Fonte: Autoria Prpria

3.3.2.3.1.6 Comando de Ligar/Desligar Driblador

Este comando permite ativar ou desativar o driblador do rob no disponvel atualmente o rob. Cdigo do comando: 0x60 Tipos de parmetros: um parmetro de 1 byte. O valor 0 (zero) desativa o driblador, qualquer outro valor ativa o mesmo. Cdigo 0x60 Byte 1 Tipo Byte 2 Byte 3 Byte 4 -

Tabela 18: Estrutura de mensagem para ligar/desligar driblador Fonte: Autoria Prpria

3.3.2.3.1.7 Comando de acionar o chutador

Este comando permite ativar ou desativar o chutador no disponvel atualmente no rob. Cdigo do comando: 0x61

59

Tipos de parmetros: um parmetro de 1 byte. O valor indica o porcentual de fora a ser aplicado no mecanismo de chute. Sendo que 0xFF seria com potncia mxima e 0x00 com potncia mnima.

Cdigo 0x61

Byte 1 Intensidade

Byte 2 -

Byte 3 -

Byte 4 -

Tabela 19: Estrutura de mensagem para acionar o chutador Fonte: Autoria prpria

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. Cdigo 0x1A Cdigo do comando: 0x1A Byte 1 Byte 2 Byte 3 Byte 4 -

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

3.3.2.3.1.9 Comando de resposta de leitura de sensores

Resposta que contm os valores dos sensores disponveis no rob. Cdigo do comando: 0x1B Tipos de parmetros: Para cada byte ser inserido o valor do sensor n do rob. Cdigo 0x1B Byte 1 Valor 1 Byte 2 Valor 2 ... ... Byte 96 Valor 96

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

3.3.2.3.1.10 Solicitar incluso na rede

60

Este comando envia uma solicitao para incluso do rob na rede, cadastrando a unidade na estao-base. Cdigo do comando: 0x20 Tipos de parmetros: este comando no possui parmetros. Byte 1 Byte 2 Byte 3 ... Byte 4 -

Cdigo 0x20

Tabela 22: Estrutura de mensagem para solicitao de cadastro na estao base Fonte: Autoria prpria

3.3.2.3.1.11 Comando de Confirmao de Incluso na Rede

Este comando confirma que a solicitao de incluso de um rob na rede foi aceita e o rob agora est cadastrado na estao-base. Cdigo do comando: 0x21 Tipos de parmetros: este comando no possui parmetros. Cdigo 0x21 Byte 1 --Byte 2 --Byte 3 --Byte 4 ---

Tabela 23: Estrutura de mensagem para incluso de um rob em uma estao central. Fonte: Autoria Prpria

3.3.2.3.1.12 Comando de Solicitar Confirmao de dispositivo ativo

Este comando solicita para uma unidade uma confirmao que a mesma esteja operante. Cdigo do comando: 0x22 Tipos de parmetros: este comando no possui parmetros.

Cdigo 0x22

Byte 1 ---

Byte 2 ---

Byte 3 ---

Byte 4 ---

61

Tabela 24: Estrutura de mensagem para confirmao de dispositivo ativo Fonte: Autoria Prpria

3.3.2.3.1.13 ACK

Este comando representa uma confirmao de mensagem bem sucedida. Cdigo do comando: 0x50 Tipos de parmetros: este comando no possui parmetros.

Cdigo 0x50

Byte 1 ---

Byte 2 ---

Byte 3 ---

Byte 4 ---

Tabela 25: Estrutura de mensagem para um ACK Fonte: Autoria Prpria

3.3.2.4 Tabela de comandos Byte 0x20 0x21 0x22 0x50 0x1B 0x1A 0x60 0x61 0x26 Funo Solicitao de cadastro Confirmao de incluso Checar se dispositivo est online ACK Resposta de leitura dos sensores Requisio de leitura dos sensores Aciona o Driblador Aciona o Chutador Andar para frente

62

0x27 0x28 0x29 0x30

Andar para trs Girar no sentido horrio Girar no sentido anti-horrio Comando Omnidirecional

Tabela 26: Tipos de comandos Fonte: Autoria prpria

3.3.3 Digramas de comunicao Para realizar a comunicao, foram utilizadas os seguintes diagramas como base. 3.3.3.1 Transmisso O envio de dados feito de acordo com o digrama de mquinas de estado que pode ser visto na Figura 21 Inicialmente quando necessrio 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 nmero de vezes que esse pacote foi enviado menor que o nmero de tentativas mximas definido no programa caso essa condio seja falsa (foi enviado menos vezes que o nmero de tentativas mximas), o pacote enviado. Depois que a mensagem for enviada o programa espera por uma confirmao da mensagem, caso ela no receba essa confirmao at o tempo do timeout, a transmisso refeita caso no tenha ultrapassado o limite de tentativas. Caso esse limite tenha sido transposto, no caso da estao-base, o usurio alertado que houve problemas de comunicao o rob, ver seo 47. Do ponto de vista do rob, caso estoure o limite mximo de tentativas, ele descartar a mensagem.

63

Figura 21: Mquina de estados da transmisso de dados Fonte: (Kurpiel, et al. 2010) (Modificado)

64

3.3.3.2 Recepo A parte da recepo 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 verificao se esse pacote j foi analisado. Caso esse pacote j tenha sido tratado a mensagem recebida descartada, caso no, a mensagem verificada se o checksum est correto, seguindo o caminho da mensagem correta, ou no, 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 retransmisso do pacote. Ele seria executado novamente pelo destinatrio caso no houvesse o armazenamento do frameID dos ltimos pacotes recebidos, esse fluxo garante que uma mesma mensagem no seja executada mais de uma vez por acidente. 3.3.4 Casos de comunicao 3.3.4.1 Iniciao do rob

Figura 23: Troca de mensagens entre estao-base e rob, viso geral Fonte: Autoria Prpria.

Quando um rob ligado, a mensagem de cadastro enviada sua respectiva estao base como pode ser observado na Figura 24. A estao base ento responde com uma confirmao de cadastro. Caso essa confirmao de castrado seja perdida, o cadastro reiniciado.

66

Figura 24: Diagrama de atividades para iniciao do rob visto pelo rob Fonte: Autoria Prpria

Figura 25: Diagrama exemplo de uma requisio da leitura dos nveis de bateria Fonte: Autoria prpria

67

3.3.4.2 Mensagem com requisio de resposta Quando a estao faz uma requisio de leitura de sensores, no caso do projeto apenas a leitura do nvel da bateria, a estao 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.

Figura 26: Diagrama de atividades da resposta do rob em relao a mensagens de requisio de leitura de sensores. Fonte: Autoria prpria

3.3.4.3 Mensagem de atuao do rob Quando a estao base envia uma mensagem de atuao no rob, o modo API do Xbee envia um ACK automaticamente, cuja condio 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 Prpria podemos ver o diagrama de atividades sobre o caso de uma mensagem de atuao chegar ao rob.

68

Figura 27: Diagrama de atividades do rob para o recebimento de uma mensagem do tipo atuadora. Fonte: Autoria Prpria

Figura 28: Exemplo de envio de mensagem do tipo atuadora Fonte: Autoria prpria

69

3.4

SISTEMA EMBARCADO

3.4.1 Software Embarcado O software foi desenvolvido em blocos para tornar o desenvolvimento do programa mais fcil. Esses blocos teriam que ser os mais independentes o possvel para tornar a fase de testes do programa mais simples e menos trabalhosa. Desse modo possvel avanar a implementao do protocolo comunicao enquanto a parte do controle ainda no est totalmente desenvolvida.

Figura 29: Viso do software para testes em alto nvel.

A parte de comunicao com fio foi includa durante o desenvolvimento do software para enviar parmetros pela serial para a estao-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,

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 fcil acesso, um gerenciador de Timers simplificado, que torna o conhecimento especfico de cada microcontrolador menos necessrio. Para projetos de microncontroladores integrados (i.e. Axon) essa biblioteca renomeia os ports livres de maneira fcil e intuitiva e os ports no disponveis na placa so 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 disponveis no Axon. Isso evitou um esforo na construo dessas funes de baixo nvel e possibilitou um foco maior no desenvolvimento de nosso sistema. 3.4.3 Inicializao do programa No incio do programa feito a inicializao dos mdulos do firmware, a comunicao com o XBee via UART2, inicializao dos mdulos do PWM, inicializao PID, configurao dos Timers e a definio de tarefas a serem executadas (scheduler). A sequncia de operao pode ser vista na Figura 30.

71

Figura 30: Sequncia de comandos para inicializao do Firmware Fonte: Autoria prpria

72

3.4.4 Funcionamento normal viso geral A partir do momento que todas as funes so inicializadas entra-se em estado de funcionamento padro, 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 nveis de PWM nos motores que sero utilizados no rob baseados na ltima realimentao fornecida pelos opto-acopladores e no comando recebido pela base.

Figura 31: Viso geral do firmware, uma abordagem de alto nvel Fonte: Autoria prpria

73

3.4.4.1 Controle Foi implementado o controle PID (proporcional, integral e derivativo) no rob. Esse controle possui algumas caractersticas bem definidas mostradas na tabela 3.
P Correo proporcional ao erro A correo cresce na mesmo

proporo que cresce o erro da diferena entre o valor real e valor desejado. I Correo proporcional ao produto erro x tempo Erros pequenos, mas que no foram tratados h muito tempo requerem correo mais intensa. D Correo proporcional a taxa de variao do erro Se o erro esta variando muito rpido esta taxa de variao dever ser reduzida a fim evitar oscilaes.
Tabela 27: Controle PID bsico. Fonte (Controle PID bsico, UFSC s.d.).

O controle usa um sistema de malha fechada de realimentao, inicia-se com a definio de um ponto objetivo setPoint - esse objetivo a velocidade alvo de cada roda em centmetros por segundo e a realimentao feita por meio dos encoders, que so lidos a cada 200ms, que gera uma velocidade que utilizada para definir o ponto atual do PID. Esse modelo interessante, permite a alterao do setPoint enquanto o rob est em movimento sem que haja reinicio do PID.

74

Figura 32: Diagrama de controle Fonte: Autoria prpria

3.4.4.2 Incio da comunicao Aps o incio do firmware necessrio que o rob entre em sincronia com sua respectiva estao base. O programa inicia enviando uma mensagem para sua estao base com o tipo 0x20 mensagem do tipo de cadastro - que em um fluxo em condies perfeitas, a base responderia imediatamente com uma mensagem confirmando o cadastro com o ID 0x21, respostas do sistema para condies adversas podem ser vista na Figura 33.

75

Figura 33: Diagrama que mostra o cadastro do firmware na viso do rob Fonte: Autoria prpria

3.4.4.3 Tratamento de mensagens ps-sincronizao com estao base Aps sincronizao da do rob com a estao base, o rob entra no estado de aguardar mensagens da estao base. Esse estado demonstrado na Figura 34. O exemplo da figura ilustra o fluxo caso a mensagem da estao base que chegar for do tipo de movimento. Na Figura 35 ilustrado a resposta do firmware para solicitao de envio de mensagem com informaes para estao base.

76

Figura 34: Diagrama de resposta do firmware para o fluxo de decodificao de uma mensagem de atuao nos motores Fonte: Autoria Prpria

77

Figura 35: Diagrama de resposta do firmware para o fluxo de resposta a uma solicitao da estao base. Fonte: Autoria prpria

78

3.4.4.4 Controle da rampa O controle da rampa, para evitar derrapagem, feito por meio de uma verificao a cada 20ms que checa se a posio atual em relao a ponto de destino. Se o ponto atual est a uma distncia menor que 20% em relao ao ponto de destino, o resultado do PID reduzido em 2% do seu valor inicial (objetivo). A rampa de subida feita pelo prprio controlador quando inicia um movimento

Figura 36: Rampa de descida.

79

3.4.5 Componentes 3.4.5.1 Regulador de tenso 7805 Foram usados dois reguladores de tenso 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 possvel 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 eletrnicos que so: o DIP Switch de endereo, o nvel lgico de tenso 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 ligaes dos reguladores na PCI necessrio ver a Figura 50. 3.4.5.2 Regulador de tenso LM317 O regulador de tenso LM317 foi usado apenas para alimentar o Xbee em nvel lgico 3,3V j que ele pode ser usado como um regulador ajustvel de tenso de acordo com os resistores e mostrados na Figura 38 disponvel no

80

datasheet. Para escolher esses resistores foi utilizada a equao ( 1 ) tambm disponvel no datasheet. (National Semicondutor, 1996)

Figura 38: Esquemtico do LM317. Fonte: (National Semicondutor 1996). (1)

O valor do resistor

indicado pelo fabricante de 240. Como esse valor

no um valor comercial foi utilizado dois resistores, um de 220 associado em srie com 22, fornecendo um resistor de 242. No circuito da PCI final esses resistores receberam o nome de e respectivamente. de 100A segundo o datasheet. por na equao ( 1 ), obtm-se: (2)

Tem-se que o valor tpico de Substituindo por , por e

Isolando-se

na equao (2), tem-se que

. Para aproximar esse valor e

a um valor comercial foram usados dois resistores associados em srie de , o que equivale em uma resistncia final de de e

. Na PCI final foi dado o nome

para esses dois resistores respectivamente. e com o regulador LM317 e a disposio

A disposio dos resistores

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, necessrio fazer o sinal passar mais uma vez pelo mesmo componente para elevar a tenso de 3,3V para 5V sem alterar sua natureza. A sada do componente foi conectada no pino Rx da UART2 do microcontrolador. Essa foi a soluo escolhida, pois o componente j estava disposto na placa e sobravam 3 pinos de I/O. O motivo de utilizar essa configurao e no ligar diretamente o pino na UART2 do microcontrolador pelo fato de que a equipe j tinha conhecimento prvio de que alguns microcontroladores Axon tinham problemas com o interfaceamento direto com o Xbee. O pino 3 (UART Data In) foi conectado na sada de um divisor de tenso com resistor R25 e R31. A entrada do divisor de tenso foi conectada no pino Tx da UART2 do microcontrolador. Essa configurao foi usada a fim de diminuir o nvel lgico de tenso de 5V do pino Tx para 3,3V, que o nvel lgico de operao 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 isolando-se tem-se que .

j definidos e

. Aproximando esse valor para um valor

comercial obtm

82

Figura 39: Divisor de tenso. Autoria prpria.

O pino 6 foi ligado no LED1 que indica a potncia do sinal e para limitar a corrente nesse LED foi usado um resistor .

O pino 15 foi ligado no LED2 que indica uma recepo ou transmisso de dados e para limitar a corrente nesse LED foi usado um resistor .

O significado dos pinos mostrado na Figura 40 e a disposio das ligaes do Xbee na PCI final mostrada da Figura 41.

83

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

Figura 41: Projeto de ligao do Xbee na PCI final. Fonte: Autoria prpria.

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 nvel lgico alto ou nvel lgico baixo, sendo assim utilizaram-se resistores de pull-up de 2200. O mximo consumo de corrente ocorre quando o DIP est normalmente fechado, o que equivale a uma dissipao de 11,36mW calculada atravs da equao ( 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 endereo 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 so usados como os 4 bits menos significativos do endereo de 4 bytes do rob. Os demais bits so fixos. Com esses 4 bits consegue-se diferenciar 16 robs. Sendo assim pode-se obter uma partida de futebol com 16 robs para cada time. 3.4.5.5 Encoders So transdutores que converte movimentos seja ele linear ou angular em sinais eltricos que carregam informaes bem definidas. Nesse projeto chaves pticas so utilizados para determinar a rotao das rodas presente no rob. Dessa forma quando usado em conjunto com o redutor do rob que consiste em uma estrutura fsica de 32 cortes e uma chave tica que altera o sinal do dispositivo entre 0 e 1 (definidos pela tenso 0 e 5V, respectivamente), o que permite uma preciso P de 11,25 atravs da equao ( 6 ). (6)

Vale ressaltar que toda a estrutura dos encoders estava montada na estrutura do rob. Havia apenas 3 terminais disponveis para ligar na placa e para isso foi necessrio 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 ligao 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 referncia do circuito. A Figura 43 mostra o esquema de ligao da chave tica na PCI.

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

86

Figura 43: Esquema de ligao da chave tica do encoder na PCI. Fonte: Autoria prpria

3.4.5.6 Schmitt Trigger 74LS14 O Schmitt Trigger atua da seguinte forma. Se o nvel lgico de entrada est acima do limiar (descrito no datasheet) a tenso de sada est em nvel lgico alto, mas se a tenso de entrada est abaixo de outro (tambm descrito no datasheet) a tenso de sada fica em nvel lgico baixo. Atuando dessa forma o Schmitt Trigger evita oscilaes do sinal mantendo ele em nvel lgico alto ou baixo. Sendo assim os seis Schmitt Triggers presentes no circuito integrado 74LS14 foram usados da seguinte maneira: 3 foram usados na sada das chaves ticas dos encoders. 2 foram usados na sada do pino 2 (UART Data Out) do Xbee. O pino que restou foi inutilizado.

As ligaes desse componente podem se vista na Figura 49.

87

3.4.5.7 Opto acopladores 4N35 O optoacoplador um componente eletrnico baseado em um diodo emissor de luz infravermelha e um fototransistor sensvel a essa faixa de luz. A disposio dos componentes dentro do encapsulamento mostrada na Figura 44. A funo desse componente eletrnico nesse projeto de isolar duas partes distintas do circuito eletrnico, dessa forma ele evita que quaisquer perturbaes ou rudos provenientes do motor sejam propagados para o microcontrolador atravs dos pinos de controle. O funcionamento desse componente na PCI simples, quando h um nvel lgico 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 nvel lgico baixo na sada. No caso de um nvel lgico baixo aplicado a entrada, o diodo para de emitir luz cortando o fototransistor e resultando em nvel lgico alto na sada do optoacoplador. necessrio adicionar um resistor em srie 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 equao (7) obtendo-se um resistor de 500 e aproximando-o para um resistor comercial obtm-se 560.
(7)

Alm desse resistor necessrio 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, necessrio que se utilize duas fontes distintas para alimentar a entrada e a sada do optoacoplador, de modo que no haja nenhuma outra ligao entre os 2 circuitos, isolando-os completamente. Porm foram utilizadas duas fontes ligadas em paralelo alimentando todo o circuito j que no 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: Esquemtico e pinos do Optoacoplador 4N35. Fonte: (Fairchild 2001)

Figura 45: Projeto dos optoacopladores na PCI. Fonte: Autoria prpria.

89

3.4.5.8 Ponte-H L298 A ponte-H o nome dado a o circuito eletrnico usado para fazer o interfaceamento com motores DC nesse projeto. As aplicaes que de motores normalmente necessitam que eles rotacionem em dois sentidos, algo que pode ser facilmente feito invertendo a polaridade dos cabos da alimentao dos motores. A ponte-H um circuito eletrnico 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 rotao de um motor DC apenas manipulando sinais lgicos 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 esto saturados e os outros 2 esto cortados tem-se a rotao em um sentido. Quando os outros dois transistores diagonalmente opostos esto saturados e os 2 primeiros voltam para o corte tem-se a rotao no sentido oposto ao inicial. O L298N j possui uma lgica interna que no 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 rotao do motor conectado aos pinos Out1 e Out2, assim como o os pinos de In3 e In4 controlam o sentido de rotao do motor conectado aos pinos Out3 e Out4 e o pino En habilita ou no a Ponte-H como um todo. O controle dos motores do rob foi feito por PWM atravs dos pinos de enable das pontes-H e o controle de sentido de rotao atravs dos pinos input como j descrito. Entretanto o datasheet indica que o a corrente de operao 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 ligao das duas pontes-H do L298. Fonte: (STMicroelectronics 2000)

91

Dessa maneira temos um controle de direo, 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 recarregveis, totalizando aproximadamente 16V em carga total cada uma delas. Elas so 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 possvel. Esses pinos so 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 proteo caso as baterias sejam ligadas em polarizao 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 construda em duas placas de forma a acopl-las. Na camada 1 esto presente os opto acopladores, Schmitt Trigger, chave de endereo, Xbee e alguns resistores. Na camada 2 esto presentes as 3 pontes-H e os 3 reguladores de tenso, assim como os diodos de proteo e alguns capacitores. Esse separao foi feita dessa forma a fim de melhor aproveitar o espao sobre o rob, uma vez que o rob tem limitaes em suas dimenses. Ambas as camadas da PCI foram feitas no software EAGLE (Easily Applicable Graphical Layout Editor) verso 5.11.0 Professional Edition. Todavia como se teve que fazer testes no rob em paralelo com a construo da PCI final ocorreu a necessidade de montar uma PCI provisria com o mesmo esquema da PCI final, porm em uma placa universal mostrada na Figura 48.

Figura 48: PCI provisria. Fonte: Autoria prpria

3.4.6.1 Viso geral das conexes da Camada 1 da PCI A camada 1 pode ser observada na Figura 49: Ligaes da Camada 1 da PCI final. Fonte: Autoria prpria.. possvel observar os nove optoacopladores que

93

esto ligados em dois conectores, sendo que 9 dos 10 pinos do conector SV-INOPTO so ligados diretamente no microcontrolador, o pino 10 no ligado em nada, apenas est presente por que esse conector padro. J os pinos do conector SVOUT-OPTO so ligados na ponte-H da segunda camada no conector JP-PHS-IN, onde os 3 primeiros pinos so de PWM e os outros 6 pinos so de INPUTS, sendo 1 PWM e 2 inputs para cada ponte-H. O Conector JP-5V-1 o pino de alimentao 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 so ligados nos 3 cabos dos encoders do rob. Os 3 Schmitt Trigger's IC4A, IC4B, IC4C so usados nas sadas 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 alimentao do Xbee proveniente do conector JP317-OUT da segunda camada. O conector JP23-UART ligado na UART2 do microcontrolador.

94

Figura 49: Ligaes da Camada 1 da PCI final. Fonte: Autoria prpria.

95

3.4.6.2 Viso geral das conexes da Camada 2 da PCI A camada 2 pode ser observada na Figura 50. Os conectores JP-BATERIA1, JP-BATERIA2 so pinos de alimentao das duas baterias presentes no rob e ligadas em paralelo como visto na figura. JP317, JP7805-1, JP7805-2 funcionam como jumpers para a alimentao com as duas baterias em paralelo (pinos JPBATERIA1, JP-BATERIA2), ou por alimentao de fontes diferentes em cada um dos reguladores (pinos JP-317, JP-7805-1, JP-7805-2, so os pinos de alimentao 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 alimentao 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 alimentao lgica das pontes-H. Os conectores JP-MOTOR1, JP-MOTOR2, JP-MOTOR3 so conectados diretamente nos 3 motores DC. Os diodos desta placa so usados como proteo da induo eltrica ocasionada quando h a inverso de rotao.

96

Figura 50: Ligaes da camada 2 da PCI final. Fonte: Autoria prpria

97

3.4.6.3 Esquemtico das camadas enviado para a prototipao O esquemtico das camadas que foi enviado para a prototipao segue mostrado nas Figura 54 e Figura 51. Esses esquemticos foram criados automaticamente aps fazerem-se as ligaes necessrias entre os componentes no software EAGLE, porm a disposio dos componentes foi feita a mo assim como grande parte das trilhas, as demais foram roteadas automaticamente. possvel observar que h algumas trilhas da camada 2 com espessura maior j que a corrente que fluir nessas trilhas relativamente maior que as demais. Aps a construo desses esquemticos foi exportado arquivos em formato GERBER. Esse formato usado para a prototipao das PCIs e cada um deles possui um tipo de informao como, por exemplo, mascara de solda, legenda, etc. Para a visualizao dos arquivos em formato GERBER foi utilizado o software ViewPlot. Nesse software possvel analisar cada uma das camadas separadamente ou ainda sobrepor quantas se desejar. possvel observar como as placas vo ser sobrepostas na Figura 53.

Figura 51: Esquemtico da camada 2 da PCI final enviada para prototipao. Fonte: Autoria prpria.

98

Figura 52: Camada 2 da PCI final antes de soldar. Fonte: Autoria prpria.

Figura 53: Camadas 1 e camada 2 sobrepostas. Fonte: Autoria prpria.

99

Figura 54: Esquemtico da camada 1 da PCI final enviada para prototipao. Fonte: Autoria prpria.

Figura 55: Camada 1 da PCI final antes de soldar. Fonte: Autoria prpria.

100

4 CONCLUSES
4.1 ANLISE DO DESENVOLVIMENTO O desenvolvimento do projeto apresentou muitos problemas devido a completa inexperincia da equipe no desenvolvimento de um projeto desse porte, no entanto considera-se muito vlida a experincia adquirida durante o processo, pois o objetivo da disciplina de Oficina de Integrao 3 justamente proporcionar aos alunos uma noo de como so todas as etapas do desenvolvimento de um projeto, desde a especificao e planejamento, passando pelo gerenciamento do tempo e dos recursos humanos e finalmente chegando implementao das solues projetadas e teste do sistema final. Durante a etapa de planejamento do projeto, foi feito uma anlise de todos os riscos aos quais o projeto estava sujeito, sendo tambm analisado a probabilidade de ocorrncia desses riscos e o impacto deles sobre o projeto. A seguir um breve comentrio sobre os riscos mais importantes. 4.1.1 Riscos Relevantes A seguir ser feita uma breve anlise 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 mdio/alto e com probabilidade mdia/baixa de acontecer, no entanto ele ocorreu. O microcontrolador foi adquirido atravs de importao dos Estados Unidos, o que acarretou em um atraso muito grande devido restries da alfndega brasileira, que demorou mais de 40 dias para liberar a entrega do componente. O impacto desse risco foi praticamente anulado atravs do emprstimo 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 prejuzo para o cronograma do projeto.

101

4.1.1.2 Problemas com a comunicao sem fio Desde a etapa de planejamento do projeto, sabia-se que a comunicao sem fio era um ponto crtico do projeto, tanto pela dificuldade em implementar esse tipo de comunicao quanto pelo papel fundamental do sistema de comunicao para o funcionamento do sistema final. Devido a isso, na etapa de anlise dos riscos, o risco de ocorrer algum problema com a comunicao sem fio foi avaliado como sendo de probabilidade mdia/alta e impacto alto. Durante o desenvolvimento do projeto, o maior problema encontrado com a comunicao sem fio foi, sem dvida o fato de a equipe ter subestimado a complexidade do protocolo de comunicao necessrio para atender aos requisitos do sistema. Isso acabou resultando em um gasto de tempo muito alm do planejado para implementar a comunicao 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 crticos para o projeto no Brasil, como por exemplo, os mdulos Xbee e o microcontrolador Axon, de modo que foi necessrio importar esses componentes dos Estados Unidos. A importao acaba incorrendo em elevados custos com frete e tambm no risco dos componentes importados serem taxados pela alfndega brasileira, o que eleva o custo do componente em 60%, a atual alquota de importao 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 no 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 mdio/alto no projeto. O impacto desse risco para o desenvolvimento do projeto foi sentido diretamente na carga de trabalho necessria dos membros restantes, pois foi necessrio dividir e absorver o trabalho do membro faltante.

102

4.1.1.5 Falta de tempo para concluso 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 horria individual necessria para concluir o projeto e por fim falta de tempo para concluir da maneira ideal todos os aspectos da execuo e documentao do projeto. Houve tambm problemas durante a etapa de planejamento do projeto no sentido de subestimar o tempo necessrio para desenvolver algumas etapas do projeto, notadamente a comunicao sem fio como um todo. Essas tarefas acabaram demandando mais tempo do que o planejado, pressionando o cronograma como em direo a data de entrega e culminando na falta de tempo para concluir o projeto de maneira adequada. 4.1.2 Consideraes 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 ento deficitrios em nossa formao, como por exemplo, gerncia de tempo, gerncia de recursos humanos, anlise de riscos, planejamento de projetos, entre outros. Alguns conhecimentos necessrios 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 decises da equipe em relao ao projeto tiveram que ser tomadas antes dos contedos necessrios terem sido aprendidos. Algumas dessas decises foram equivocadas, resultando em um trabalho maior necessrio para corrigir esses problemas, trabalho esse que poderia ser evitado caso essas disciplinas j tivessem sido cursadas anteriormente ao incio do projeto. 4.2 INTEGRAO O desenvolvimento desse projeto exigiu da equipe conhecimentos em diversas outras disciplinas ministradas no curso de Engenharia de Computao, sendo cada uma dessas disciplinas e sua aplicao no projeto detalhadas a seguir.

103

4.2.1 Controle A disciplina de controle versa sobre como se pode controlar a sada de um determinado sistema alterando sua entrada. Aplicado ao projeto em questo, os conhecimentos de controle possibilitam que a velocidade com que o rob se locomove seja controlada, independentemente de superfcie ou de carga na bateria, atravs da variao do PWM aplicado aos motores. Tambm possvel garantir que o rob ande em linha reta e execute outros comandos com preciso, atravs de um algoritmo de controle PID associado realimentao 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 utilizao correta dos diversos perifricos de um microcontrolador comum como, por exemplo, timers, interrupes, ports de entrada e sada e UARTs(Universal Asynchronous Receiver/Transmitter). Estudamos tambm como deve ser feito o interfaceamento com motores e outros dispositivos de potncia como, por exemplo, Pontes-H, esse contedo de suma importncia para o desenvolvimento de projetos que envolvem robs como esse. A comunicao serial, padro utilizado pelo Xbee, tambm foi um contedo crtico 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 concluda previamente em relao ao incio do projeto, o aproveitamento e o desempenho da equipe teria melhorias significativas. 4.2.3 Comunicao de dados Os problemas relacionados a comunicao sem fio do projeto foram solucionados com a ajuda dos conhecimentos aprendidos na disciplina de comunicao de dados. Conceitos estudados como, por exemplo, acknowledge e handshaking foram empregados no desenvolvimento do protocolo de comunicao,

104

de modo a garantir o nvel de robustez e confiabilidade requerido na especificao do projeto. 4.2.4 Eletrnica 2 A disciplina de eletrnica 2 foi especialmente importante no projeto dos filtros analgicos, utilizados para filtrar rudos indesejados na alimentao dos circuitos. Essa disciplina tambm foi importante no dimensionamento e utilizao dos componentes de potncia do circuito, notadamente as pontes-H que comandam os motores. 4.2.5 Anlise 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 mximo o retrabalho necessrio no processo de desenvolvimento de software. Algumas dessas metodologias foram aplicadas tanto no desenvolvimento do software da estao base como no firmware do sistema embarcado, notadamente a elaborao de diversos diagramas que descrevem o comportamento do sistema e a concordncia 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 gerncia de projeto, pois eles envolvem uma grande componente de experincia com projetos anteriores. Esse projeto foi o primeiro desse porte a ser desenvolvido pela equipe com nfase na gerncia de projeto, fato esse que acabou apresentando novos desafios concluso do projeto, de modo que sobreposto as preocupaes relativas engenharia haviam tambm as preocupaes relativas gerncia das pessoas e distribuio igualitria da carga de trabalho. 4.3 TRABALHOS FUTUROS Essa seo trata sobre os prximos 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 mnimo de retrabalho possvel, possibilitando a concluso de objetivos cada vez maiores. 4.3.1 Driblador e chutador A adio de um driblador e um chutador ao projeto possibilitaria que os robs fossem utilizados em outra funo que no a de goleiro. Os desafios envolvidos na implementao dessas solues so principalmente a adequao da parte mecnica para receber esses novos componentes e a insero de novos circuitos integrados necessrios na atual arquitetura, uma vez que as dimenses do rob so reduzidas. Do ponto de vista da comunicao e do software, pequenos ajustes precisam ser feitos para que essas novas funes sejam suportadas, pois ambos os sistemas j foram desenvolvidos de modo a suportar expanses de capacidade. 4.3.2 Adio de sensores A adio de diversos tipos de sensores poderia aprimorar alguns aspectos do desempenho do rob. Por exemplo, uma bssola poderia contribuir para um controle de rotaes mais preciso e sensores de distncia possibilitariam que o rob evitasse colises automaticamente. Outros tipos de sensores ainda poderiam ser adicionados para o rob de modo que ele pudesse executar outra tarefa alm de jogar futebol. Os desafios ficam por conta de interfacear o sensor escolhido corretamente com o microcontrolador e implementar a lgica responsvel por enviar as leituras do sensor para a estao 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 adio de novos componentes e totalmente compatvel com o firmware desenvolvido para o Axon.

106

4.3.4 Inteligncia artificial Uma inteligncia 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 competies de futebol de robs. 4.3.5 Comunicao A comunicao pode ser melhorada em diversos aspectos, por exemplo, a utilizao de mdulos Xbee com maior alcance e capacidade de transmisso. Existem tambm pontos a ser melhorados no protocolo de comunicao, como por exemplo deteco de fora do sinal e tratamento de problemas diversos de comunicao.

107

5 REFERNCIAS
" Lista de microcontroladores AVR." Digikey. n.d.

http://ca.digikey.com/1/4/indexe18.html. "Arduno 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 Maro 2, 2011). "Controle PID bsico, 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 navegao 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. Maro 1996. NetBeans. Develop desktop, mobile and web applications with Java, PHP, C/C++ and more. Oracle Corporation, 2011.

108

Nishibe, Caio Arce, John Tho 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:Identificao do Risco Denominao do risco: Atraso no recebimento de componentes

pelos fornecedores.

N Identificao 01

Descrio do risco: Os componentes comprados podem sofrer atraso na entrega

por razes diversas. 2 Etapa:Avaliao do Risco Impacto: 5(alto)4(mdia/alto)3(mdio) 2(mdio/baixo) 1(baixo) Explique: Sem os componentes solicitados, no possvel montar o artefato e realizar os testes iniciais, atrasando todo o cronograma.

Probabilidade: 5(alta) 4(mdia/alta) 3(mdia) 2(mdia/baixa)1 (baixa)

Explique: A solicitao dos componentes aos fabricantes feito com antecedncia e folga suficiente para comportar atrasos nas entregas. 3 Etapa:Desenvolvimento da Resposta ao Risco AES, RESPONSVEIS E DATAS DE CONCLUSO

Estratgias e Aes para eliminar ou reduzir este risco (minimizar impacto e/ou
probabilidade):
Prevenir: Solicitar os componentes necessrios aos fabricantes com antecedncia 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: Data: Respostas Registros adicionais: includas na Ari Magagnin Junior, 23/03/2011 WBS/Cronograma Eduardo Cabral Resende VERSO OU Neiva, Fbio Csar ANEXOS Schuartz, Joo Hamilton Cecato Simas Formulrio sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

110

1 Etapa:Identificao do Risco Denominao do risco: Queima de componentes integrados com longo prazo para aquisio.

N Identificao 02

Descriodo risco: Um componente essencial ao projeto pode queimar e o tempo

para sua reposio ser demorado. 2 Etapa:Avaliao do Risco Impacto: 5(alto)4(mdia/alto) 3(mdio) 2(mdio/baixo) 1(baixo) Explique: No h como estender os prazos para a entrega do artefato, e o projeto ficar paralisado sem os componentes para sua confeco.

Probabilidade: 5(alta) 4(mdia/alta) 3(mdia)2(mdia/baixa) 1 (baixa)

Explique: Um componente pode queimar por diversas razes, desde o seu manuseio incorreto at distraes durante sua soldagem. 3 Etapa:Desenvolvimento da Resposta ao Risco AES, RESPONSVEIS E DATAS DE CONCLUSO

Estratgias e Aes 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 Respostas includas na WBS/Cronograma Registros adicionais: VERSO OU ANEXOS Elaborado por: Data: Ari Magagnin Junior, 23/03/2011 Eduardo Cabral Resende Neiva, Fbio Csar Schuartz, Joo Hamilton Cecato Simas

Formulrio sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

111

1 Etapa:Identificao do Risco Denominao do risco: Problemas com a comunicao sem fio.

N Identificao 04 Descrio do risco: Sem comunicao o rob no executar nenhum comando de movimentao. 2 Etapa:Avaliao do Risco Impacto: 5(alto)4(mdia/alto) 3(mdio) 2(mdio/baixo) 1(baixo) Explique: Sem comunicao com o artefato, o mesmo no ter nenhuma funcionalidade operante.

Probabilidade: 5(alta) 4(mdia/alta)3(mdia) 2(mdia/baixa) 1 (baixa)

Explique: A comunicao sem fio complexa e exige alto grau de conhecimento de protocolos. 3 Etapa:Desenvolvimento da Resposta ao Risco AES, RESPONSVEIS E DATAS DE CONCLUSO

Estratgias e Aes para eliminar ou reduzir este risco (minimizar impacto e/ou
probabilidade):
Prevenir: Estudar a fundo a tecnologia de transmisso sem fio e os protocolos necessrios para a comunicao entre a base e o microcontrolador. Transferir: Mitigar: No havendo a comunicao sem fio conforme planejado, ser necessrio mudar a tecnologia de transmisso (Wi-Fi, RF, Bluetooth, etc). Aceitar: Impacto reavaliado: 5 Probabilidade reavaliada: 3 Respostas includas na WBS/Cronograma Registros adicionais: VERSO OU ANEXOS

Elaborado por: Data: Ari Magagnin Junior, 23/03/2011 Eduardo Cabral Resende Neiva, Fbio Csar Schuartz, Joo Hamilton Cecato Simas

Formulrio sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

112

1 Etapa:Identificao do Risco Denominao do risco: Falta de conhecimento suficiente para completar o projeto, pelos membros da equipe.

N Identificao 05

Descrio do risco: Conhecimento insuficiente dos membros da equipe inviabilizar

terminar o projeto. 2 Etapa:Avaliao do Risco Impacto: 5(alto)4(mdia/alto) 3(mdio) 2(mdio/baixo) 1(baixo) Explique: Sem os conhecimentos necessrios, o projeto no terminar e o artefato no poder ser construdo.

Probabilidade: 5(alta) 4(mdia/alta) 3(mdia) 2(mdia/baixa)1 (baixa)

Explique: Os integrantes do grupo possuem uma base da tecnologia empregada e dos conceitos envolvidos no projeto. 3 Etapa:Desenvolvimento da Resposta ao Risco AES, RESPONSVEIS E DATAS DE CONCLUSO

Estratgias e Aes para eliminar ou reduzir este risco (minimizar impacto e/ou
probabilidade):
Prevenir: Procurar uma tecnologia que seja compatvel com o nvel de conhecimento para a construo do artefato, satisfazendo os requisitos e no 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 estgio inicial do projeto. Aceitar: Impacto reavaliado: 4 Probabilidade reavaliada: 2 Respostas includas na WBS/Cronograma Registros adicionais: VERSO OU ANEXOS Elaborado por: Data: Ari Magagnin Junior, 23/03/2011 Eduardo Cabral Resende Neiva, Fbio Csar Schuartz, Joo Hamilton Cecato Simas

Formulrio sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

113

1 Etapa:Identificao do Risco Denominao do risco: Falta de tempo para a concluso do projeto.

N Identificao 06

Descrio do risco: Tempo no pode ser adquirido, portanto o prazo final no pode
ser estendido. 2 Etapa:Avaliao do Risco Impacto: 5(alto)4(mdia/alto) 3(mdio) 2(mdio/baixo) 1(baixo) Explique: Caso o tempo disponvel no seja suficiente, o artefato no poder ser completado, invalidando todo o projeto.

Probabilidade: 5(alta) 4(mdia/alta) 3(mdia)2(mdia/baixa) 1 (baixa)

Explique: feito uma avaliao e planejamento prvios, mas imprevistos podem ocorrer durante o tempo estimado para cada tarefa. 3 Etapa:Desenvolvimento da Resposta ao Risco AES, RESPONSVEIS E DATAS DE CONCLUSO

Estratgias e Aes 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 acontea permita a equipe corrigir os problemas atrasados. Transferir: Mitigar: Diminuir o escopo do trabalho e reduzir os requisitos finais do artefato. Aceitar: -

Impacto reavaliado: 5

Probabilidade reavaliada: 4 Respostas includas na WBS/Cronograma Registros adicionais: VERSO OU ANEXOS

Elaborado por: Data: Ari Magagnin Junior, 23/03/2011 Eduardo Cabral Resende Neiva, Fbio Csar Schuartz, Joo Hamilton Cecato Simas

Formulrio sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

114

1 Etapa:Identificao do Risco Denominao do risco: Problemas de sade de membros da equipe.

N Identificao 07

Descrio do risco: Um membro da equipe pode sofrer algum acidente ou ficar

doente. 2 Etapa:Avaliao do Risco Impacto: 5(alto)4(mdia/alto) 3(mdio)2(mdio/baixo) 1(baixo) Explique: Caso algum membro da equipe fique doente, isso atrasar algum mdulo do projeto, podendo (ou no) atrasar o incio de outras etapas, acumulando o atraso.

Probabilidade: 5(alta) 4(mdia/alta) 3(mdia) 2(mdia/baixa) 1 (baixa)

Explique: Resfriados e gripes so as formas mais comuns de doenas que podem ocorrer. Outras doenas tem possibilidade de ocorrer baixa. 3 Etapa:Desenvolvimento da Resposta ao Risco AES, RESPONSVEIS E DATAS DE CONCLUSO

Estratgias e Aes para eliminar ou reduzir este risco (minimizar impacto e/ou
probabilidade):
Prevenir: Cuidar da sade, no se expor a fatores de risco sade desnecessariamente, agasalhar-se bem so algumas formas de preveno de doenas. Transferir: Mitigar: Procurar um mdico ou especialista o quanto antes a fim que cura-se rapidamente e ter condies para prosseguir o trabalho. Caso seja um curto perodo de algum dos membros da equipe com algum tipo de problema de sade, os demais membros compensam o tempo e esforo do colega ausente temporariamente. Aceitar: Impacto reavaliado: 3 Probabilidade reavaliada: 1 Respostas includas na WBS/Cronograma Registros adicionais: VERSO OU ANEXOS

Elaborado por: Data: Ari Magagnin Junior, 23/03/2011 Eduardo Cabral Resende Neiva, Fbio Csar Schuartz, Joo Hamilton Cecato Simas

Formulrio sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

115

1 Etapa:Identificao do Risco Denominao do risco: Custo real muito acima do custo estimado, inviabilizando o trmino do projeto.

N Identificao 8

Descrio do risco: O custo dos materiais pode se tornar muito acima do previsto,
inviabilizando o projeto. 2 Etapa:Avaliao do Risco Impacto: 5(alto)4(mdia/alto)3(mdio) 2(mdio/baixo) 1(baixo) Explique: Caso o custo do projeto seja muito alto, no haver possibilidade de completar o artefato.

Probabilidade: 5(alta) 4(mdia/alta) 3(mdia) 2(mdia/baixa) 1 (baixa)

Explique: Utilizar-se- de componentes individuais com custo reduzido ao invs de circuitos pr-montados. 3 Etapa:Desenvolvimento da Resposta ao Risco AES, RESPONSVEIS E DATAS DE CONCLUSO

Estratgias e Aes 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 no so superestimados. Transferir: Mitigar: Reduzir as funcionalidades do artefato, procurar solues alternativas em componentes mais baratos que possam realizar parte das especificaes. Aceitar: Impacto reavaliado: 3 Probabilidade reavaliada: 2 Respostas includas na WBS/Cronograma Registros adicionais: VERSO OU ANEXOS

Elaborado por: Data: Ari Magagnin Junior, 23/03/2011 Eduardo Cabral Resende Neiva, Fbio Csar Schuartz, Joo Hamilton Cecato Simas

Formulrio sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

116

1 Etapa:Identificao do Risco Denominao do risco: Desistncia de algum membro da equipe.

N Identificao 9

Descrio do risco: Um dos integrantes do grupo desiste do projeto e/ou da disciplina.

2 Etapa:Avaliao do Risco Impacto: 5(alto)4(mdia/alto)3(mdio) 2(mdio/baixo) 1(baixo) Explique: Caso um membro da equipe desista da disciplina, os demais integrantes podem no conseguir terminar o projeto dentro do tempo previsto.

Probabilidade: 5(alta) 4(mdia/alta) 3(mdia) 2(mdia/baixa) 1 (baixa)

Explique: Os integrantes do grupo esto motivados a construrem o artefato. 3 Etapa:Desenvolvimento da Resposta ao Risco AES, RESPONSVEIS E DATAS DE CONCLUSO

Estratgias e Aes para eliminar ou reduzir este risco (minimizar impacto e/ou
probabilidade):
Prevenir: Conversar semanalmente com cada integrante do grupo, definir metas alcanveis, 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 possvel. Aceitar: Impacto reavaliado: 4 Probabilidade reavaliada: 4 Respostas includas na WBS/Cronograma Registros adicionais: VERSO OU ANEXOS

Elaborado por: Data: Ari Magagnin Junior, 23/03/2011 Eduardo Cabral Resende Neiva, Fbio Csar Schuartz, Joo Hamilton Cecato Simas

Formulrio sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

117

1 Etapa:Identificao do Risco Denominao do risco: Perda ou roubo do artefato.

N Identificao 10

Descrio do risco: O artefato pode ser roubado ou perdido.

2 Etapa:Avaliao do Risco Impacto: 5(alto)4(mdia/alto) 3(mdio) 2(mdio/baixo) 1(baixo) Explique: Sem o artefato no ser possvel concluir o projeto.

Probabilidade: 5(alta) 4(mdia/alta) 3(mdia) 2(mdia/baixa) 1 (baixa)

Explique: O artefato estar sempre no alcance de algum integrante da equipe. 3 Etapa:Desenvolvimento da Resposta ao Risco AES, RESPONSVEIS E DATAS DE CONCLUSO

Estratgias e Aes para eliminar ou reduzir este risco (minimizar impacto e/ou
probabilidade):
Prevenir: Sempre manter o artefato no campo de viso dos integrantes da equipe, verificar sempre duas vezes a posse do artefato antes de deixar um laboratrio, nunca deixar o artefato sozinho por motivo algum. Transferir: Mitigar: Procurar o quanto antes o local onde fora deixado o objeto e buscar informaes para tentar encontra-lo a mais rpido possvel. Aceitar: Impacto reavaliado: 5 Probabilidade reavaliada: 1 Respostas includas na WBS/Cronograma Registros adicionais: VERSO OU ANEXOS

Elaborado por: Data: Ari Magagnin Junior, 23/03/2011 Eduardo Cabral Resende Neiva, Fbio Csar Schuartz, Joo Hamilton Cecato Simas

Formulrio sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

118

6.2

GANT DE CARGA FINAL

6.2.1 Gant Individual

Figura 57:Fbio

Figura 56:Joo

119

Figura 59:Eduardo Figura 58:Ari

120

121