Post on 16-Oct-2018
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
DEPARTAMENTO ACADÊMICO DE ELETRÔNICA/INFORMATICA
CURSO DE ENGENHARIA DE COMPUTAÇÃO
MONOGRAFIA
ROBOFUT - PROJETO DE INICIAÇÃO DE UM ROBÔ PARA A
ROBOCUP
ARI MAGAGNIN JUNIOR
EDUARDO CABRAL RESENDE NEIVA
JOÃO HAMILTON CECATO SIMAS
CURITIBA
2011
ARI MAGAGNIN JUNIOR
EDUARDO CABRAL RESENDE NEIVA
JOÃO HAMILTON CECATO SIMAS
ROBOFUT - PROJETO DE INICIAÇÃO DE UM ROBÔ PARA A
ROBOCUP
Monografia apresentada como requisito para aprovação na disciplina de Oficina de Integração 3, ministrada pelos professores:
Prof. Dr. João Alberto Fabro
Prof. Dr. Heitor Silvério Lopes
CURITIBA
2011
iv
Resumo
Esta monografia destina-se a descrever o desenvolvimento de um sistema composto por um robô com 3 rodas, um sistema de comunicação sem fio e uma estação-base capaz de controlar vários robôs, bem como documentar e explicar as decisões de projeto tomadas. O objetivo do projeto é prover uma plataforma confiável que, comandada por uma inteligência artificial, seja capaz de participar de competições de futebol de robôs.
Palavras-chave
Futebol de Robôs, RoboCup, Comunicação Wireless.
v
Abstract
This monograph is intended to describe the development of a system composed of a robot with three wheels, a wireless communication system and a base station capable of controlling multiple robots, as well as to document and explain the design decisions taken. The project's goal is to provide a reliable platform that, led by an artificial intelligence, is able to participate in robot soccer competitions.
Key-words
Robot Soccer, RoboCup, Wireless Communication
vi
Sumário
1 INTRODUÇÃO ........................................................................................... 15
1.1 MOTIVAÇÃO .............................................................................................. 15
1.2 TRABALHOS CORRELATOS .................................................................... 15 1.2.1 Omni¹ ......................................................................................................... 15 1.2.2 Omni² ......................................................................................................... 17 1.2.3 RoboFEI ..................................................................................................... 17
1.3 OBJETIVOS ............................................................................................... 18
2 PLANEJAMENTO ..................................................................................... 20
2.1 DECLARAÇÃO DO ENCOPO EM ALTO-NÍVEL ....................................... 20
2.2 PREMISSAS E RESTRIÇÕES ................................................................... 20
2.3 DESIGNAÇÃO DO GERENTE E DA EQUIPE ........................................... 21
2.4 PLANEJAMENTO DE RISCOS .................................................................. 21
2.5 REQUISITOS ............................................................................................. 21
2.6 ALTERNTIVA TECNOLÓGICA .................................................................. 23
2.6.1 Estação base ............................................................................................. 23 2.6.2 Linguagem de programação ...................................................................... 23
2.6.2.1 JAVA ............................................................................................................ 23 2.6.2.2 C ................................................................................................................... 24
2.7 SISTEMA DE COMUNICAÇÃO ................................................................. 25
2.8 SISTEMA EMBARCADO ........................................................................... 26 2.8.1 Ponte-H ...................................................................................................... 27
2.8.1.1 Ponte-H utilizando componentes discretos................................................... 27
2.8.1.2 L298N ........................................................................................................... 27 2.8.1.3 Comparação e escolha da ponte-H ............................................................... 27
2.9 MICROCONTROLADOR ........................................................................... 28 2.9.1 Atmega328 ................................................................................................. 28
2.9.2 DSPIC30F3010 .......................................................................................... 29 2.9.3 Atmega 640 ................................................................................................ 29 2.9.4 Atmega2560 ............................................................................................... 30
2.9.5 C8051F340 ................................................................................................ 31
2.9.6 Comparação e escolha do microcontrolador .............................................. 31
2.10 ORÇAMENTO INICIAL DETALHADO PREVISTO .................................... 32
2.11 ORÇAMENTRO DETALHADO GASTO ..................................................... 35
2.12 CRONOGRAMA ......................................................................................... 36
2.13 ENTREGÁVEIS .......................................................................................... 39
2.14 AUXILIARES DE GERENCIAMENTO ....................................................... 39
3 EXECUÇÃO ............................................................................................... 41
vii
3.1 ARQUITETURA GERAL DO HARDWARE E SOFTWARE ........................ 41
3.2 ESTAÇÃO-BASE ....................................................................................... 42 3.2.1 Framework ................................................................................................. 42
3.2.1.1 Parser ............................................................................................................ 45
3.2.2 Interface Gráfica ......................................................................................... 47
3.3 SISTEMA DE COMUNICAÇÃO ................................................................. 48
3.3.1 Módulos de comunicação........................................................................... 48 3.3.2 Protocolo .................................................................................................... 49
3.3.2.1 Formato da mensagem .................................................................................. 49 3.3.2.2 Encapsulamento da mensagem ..................................................................... 50 3.3.2.3 Estrutura da Mensagem ................................................................................ 54 3.3.2.4 Tabela de comandos ..................................................................................... 61
3.3.3 Digramas de comunicação ......................................................................... 62 3.3.3.1 Transmissão .................................................................................................. 62
3.3.3.2 Recepção ....................................................................................................... 64
3.3.4 Casos de comunicação .............................................................................. 65 3.3.4.1 Iniciação do robô .......................................................................................... 65 3.3.4.2 Mensagem com requisição de resposta ........................................................ 67
3.3.4.3 Mensagem de atuação do robô ..................................................................... 67
3.4 SISTEMA EMBARCADO ........................................................................... 69
3.4.1 Software Embarcado .................................................................................. 69 3.4.2 Webbotlib 1.31 ........................................................................................... 69
3.4.3 Inicialização do programa .......................................................................... 70 3.4.4 Funcionamento normal – visão geral ......................................................... 72
3.4.4.1 Controle ........................................................................................................ 73
3.4.4.2 Início da comunicação .................................................................................. 74 3.4.4.3 Tratamento de mensagens pós-sincronização com estação base .................. 75
3.4.4.4 Controle da rampa ........................................................................................ 78
3.4.5 Componentes ............................................................................................. 79 3.4.5.1 Regulador de tensão 7805............................................................................. 79 3.4.5.2 Regulador de tensão LM317......................................................................... 79
3.4.5.3 Xbee .............................................................................................................. 81 3.4.5.4 DIP Switch 2 vias de 5 bits ........................................................................... 84 3.4.5.5 Encoders ....................................................................................................... 84 3.4.5.6 Schmitt Trigger 74LS14 ............................................................................... 86 3.4.5.7 Opto acopladores 4N35 ................................................................................ 87
3.4.5.8 Ponte-H L298 ............................................................................................... 89
3.4.5.9 Bateria ........................................................................................................... 91
3.4.6 Placa de circuito impressa ......................................................................... 92 3.4.6.1 Visão geral das conexões da Camada 1 da PCI ............................................ 92 3.4.6.2 Visão geral das conexões da Camada 2 da PCI ............................................ 95 3.4.6.3 Esquemático das camadas enviado para a prototipação ............................... 97
4 CONCLUSÕES ........................................................................................ 100
4.1 ANÁLISE DO DESENVOLVIMENTO ....................................................... 100 4.1.1 Riscos Relevantes ................................................................................... 100
4.1.1.1 Atraso no recebimento de componentes pelos fornecedores ...................... 100
4.1.1.2 Problemas com a comunicação sem fio ...................................................... 101
viii
4.1.1.3 Custo real muito acima do custo estimado para o projeto .......................... 101 4.1.1.4 Impossibilidade de algum membro da equipe terminar o projeto .............. 101
4.1.1.5 Falta de tempo para conclusão do projeto .................................................. 102
4.1.2 Considerações finais sobre o desenvolvimento ....................................... 102
4.2 INTEGRAÇÃO ......................................................................................... 102 4.2.1 Controle.................................................................................................... 103
4.2.2 Sistemas Microcontrolados ...................................................................... 103 4.2.3 Comunicação de dados ........................................................................... 103 4.2.4 Eletrônica 2 .............................................................................................. 104 4.2.5 Análise e projeto de sistemas e Engenharia de Software ........................ 104
4.3 TRABALHOS FUTUROS ......................................................................... 104
4.3.1 Driblador e chutador ................................................................................. 105
4.3.2 Adição de sensores .................................................................................. 105
4.3.3 Microcontrolador ...................................................................................... 105 4.3.4 Inteligência artificial .................................................................................. 106 4.3.5 Comunicação ........................................................................................... 106
5 REFERÊNCIAS ....................................................................................... 107
6 ANEXOS .................................................................................................. 109
6.1 PLANEJAMENTO DE RISCO .................................................................. 109
6.2 GANT DE CARGA FINAL ........................................................................ 118
6.2.1 Gant Individual ......................................................................................... 118
ix
Lista de ilustrações
Figura 1: Omni¹ Fonte: (Nishibe, et al. 2010) ............................................................ 16
Figura 2: RoboFEI Fonte: (Tavares 2007). ............................................................... 18
Figura 3: Proposta de interface com o usuário da estação base. Fonte: Autoria própria. ..................................................................................... 23
Figura 4: L298. Fonte: (STMicroelectronics 2000) .................................................... 27
Figura 5: Características necessárias do microcontrolador. Fonte: Autoria própria. ................................................................................................. 28
Figura 6: Atmega328. Fonte: (ATMega328 28 pin DIP with Bootloader s.d.) ........... 29
Figura 7: Atmega640. Fonte: ( Lista de microcontroladores AVR s.d.) ..................... 30
Figura 8: Atmega2560. Fonte: ( Lista de microcontroladores AVR s.d.) ................... 30
Figura 9: Comparação Microcontroladores. Fonte: (Axon Microcontroller Description s.d.) (Arduíno Mega 2560 s.d.) .......................................... 32
Figura 10: Microcontrolador Axon. Fonte: (Axon Microcontroller Description s.d.) ...................................................................................................... 32
Figura 11: Arquitetura geral do sistema Fonte: Autoria Própria................................. 41
Figura 12: Diagrama de classes da Estação-Base Fonte: Autoria Própria ................ 42
Figura 13: Diagrama de atividades do algoritmo do buffer. Fonte: Autoria Própria .................................................................................................. 45
Figura 14: Estrutura dos comandos do parser. Fonte: Autoria Própria ..................... 46
Figura 15: Layout da interface gráfica. Fonte: Autoria Própria .................................. 47
Figura 16: Módulo Xbee Series 1 Fonte: (Digi International n.d.) .............................. 49
Figura 17: Estrutura do Frame Fonte: (MaxStream USA). ....................................... 51
Figura 18: Data Frame e estrutura específica de cada API Fonte: (MaxStream USA) ................................................................................ 51
Figura 19: TX Packet ( 16 bit address ) Fonte: (MaxStream USA) .......................... 52
Figura 20: Frame do TX Status Fonte: (MaxStream USA) ........................................ 53
Figura 21: Máquina de estados da transmissão de dados Fonte: (Kurpiel, et al. 2010) (Modificado) ........................................................................... 63
Figura 22: Diagrama de tratamento dos dados recebidos Fonte: (Kurpiel, et al. 2010) (Modificado). .......................................................................... 64
Figura 23: Troca de mensagens entre estação-base e robô, visão geral Fonte: Autoria Própria. ......................................................................... 65
Figura 24: Diagrama de atividades para iniciação do robô visto pelo robô Fonte: Autoria Própria .......................................................................... 66
Figura 25: Diagrama exemplo de uma requisição da leitura dos níveis de bateria Fonte: Autoria própria ............................................................... 66
x
Figura 26: Diagrama de atividades da resposta do robô em relação a mensagens de requisição de leitura de sensores. Fonte: Autoria própria ...................................................................................... 67
Figura 27: Diagrama de atividades do robô para o recebimento de uma mensagem do tipo atuadora. Fonte: Autoria Própria ............................ 68
Figura 28: Exemplo de envio de mensagem do tipo atuadora Fonte: Autoria própria .................................................................................................. 68
Figura 29: Visão do software para testes em alto nível. ............................................ 69
Figura 30: Sequência de comandos para inicialização do Firmware Fonte: Autoria própria ...................................................................................... 71
Figura 31: Visão geral do firmware, uma abordagem de alto nível Fonte: Autoria própria ...................................................................................... 72
Figura 32: Diagrama de controle Fonte: Autoria própria ........................................... 74
Figura 33: Diagrama que mostra o cadastro do firmware na visão do robô Fonte: Autoria própria ........................................................................... 75
Figura 34: Diagrama de resposta do firmware para o fluxo de decodificação de uma mensagem de atuação nos motores Fonte: Autoria Própria .................................................................................................. 76
Figura 35: Diagrama de resposta do firmware para o fluxo de resposta a uma solicitação da estação base. Fonte: Autoria própria ............................. 77
Figura 36: Rampa de descida. .................................................................................. 78
Figura 37: Projeto do regulador 7805 presente no datasheet. Fonte: (Fairchild 2001) .................................................................................... 79
Figura 38: Esquemático do LM317. Fonte: (National Semicondutor 1996). ............. 80
Figura 39: Divisor de tensão. Autoria própria. ........................................................... 82
Figura 40: Pinos do Xbee. Fonte: (MaxStream USA). .............................................. 83
Figura 41: Projeto de ligação do Xbee na PCI final. Fonte: Autoria própria. ............. 83
Figura 42: Esquema da chave ótica H22A1. Fonte: (Fairchild 2001) ........................ 85
Figura 43: Esquema de ligação da chave ótica do encoder na PCI. Fonte: Autoria própria ...................................................................................... 86
Figura 44: Esquemático e pinos do Optoacoplador 4N35. Fonte: (Fairchild 2001) .................................................................................................... 88
Figura 45: Projeto dos optoacopladores na PCI. Fonte: Autoria própria. .................. 88
Figura 46: Esquema de ligação das duas pontes-H do L298. Fonte: (STMicroelectronics 2000) ................................................................... 90
Figura 47: Ponte-H L298. Fonte: (STMicroelectronics 2000) .................................... 91
Figura 48: PCI provisória. Fonte: Autoria própria ...................................................... 92
Figura 49: Ligações da Camada 1 da PCI final. Fonte: Autoria própria. ................... 94
Figura 50: Ligações da camada 2 da PCI final. Fonte: Autoria própria ..................... 96
xi
Figura 51: Esquemático da camada 2 da PCI final enviada para prototipação. Fonte: Autoria própria. .......................................................................... 97
Figura 52: Camada 2 da PCI final antes de soldar. Fonte: Autoria própria. .............. 98
Figura 53: Camadas 1 e camada 2 sobrepostas. Fonte: Autoria própria. ................. 98
Figura 54: Esquemático da camada 1 da PCI final enviada para prototipação. Fonte: Autoria própria. .......................................................................... 99
Figura 55: Camada 1 da PCI final antes de soldar. Fonte: Autoria própria. .............. 99
Figura 56:João ........................................................................................................ 118
Figura 57:Fábio ....................................................................................................... 118
Figura 58:Ari 119
Figura 59:Eduardo ................................................................................................... 119
xii
Lista de tabelas
Tabela 1: Requisitos do robô. Fonte: Autoria própria. ............................................... 21
Tabela 2: Requisitos do da comunicação. Fonte: Autoria própria. ............................ 22
Tabela 3: Requisitos da estação base. Fonte: Autoria própria. ................................. 22
Tabela 4: Tabela de comparação de alternativos de comunicação sem fio. Fonte: (Software technologies, group 2009) ........................................ 25
Tabela 5: Gastos com recursos humanos. Fonte: Autoria própria. ........................... 35
Tabela 6: Orçamento real. Fonte: Autoria própria. .................................................... 36
Tabela 7: Cronograma. Fonte: autoria própria. ......................................................... 38
Tabela 8: Entregáveis. Fonte: Autoria propria. .......................................................... 39
Tabela 9: Auxiliares de gerenciamento. Fonte: Autoria própria. ................................ 39
Tabela 10: Formato padrão de mensagem Fonte: Autoria própria ............................ 50
Tabela 11: Baud Rate para valores de BD Fonte: Autoria Própria ............................ 54
Tabela 12: Estrutura da mensagem Fonte: Autoria Própria ...................................... 55
Tabela 13: Estrutura de uma mensagem de andar para frente (0x26) Fonte: Autoria Própria ..................................................................................... 55
Tabela 14: Estrutura de uma mensagem de ir para frente (0x27) Fonte: Autoria Própria ..................................................................................... 56
Tabela 15: Estrutura de uma mensagem de girar no sentido horário (0x28) Fonte: Autoria Própria .......................................................................... 57
Tabela 16: Estrutura de uma mensagem de girar anti-horário (0x29) Fonte: Autoria Própria ..................................................................................... 57
Tabela 17: Estrutura da mensagem para o movimento em uma direção Fonte: Autoria Própria ..................................................................................... 58
Tabela 18: Estrutura de mensagem para ligar/desligar driblador Fonte: Autoria Própria ..................................................................................... 58
Tabela 19: Estrutura de mensagem para acionar o chutador Fonte: Autoria própria .................................................................................................. 59
Tabela 20: Estrutura de mensagem para solicitar leitura de sensores Fonte: Autoria Própria ..................................................................................... 59
Tabela 21: Estrutura de mensagem de resposta de leitura de sensores Fonte: Autoria própria ...................................................................................... 59
Tabela 22: Estrutura de mensagem para solicitação de cadastro na estação base Fonte: Autoria própria .................................................................. 60
Tabela 23: Estrutura de mensagem para inclusão de um robô em uma estação central. Fonte: Autoria Própria ................................................ 60
xiii
Tabela 24: Estrutura de mensagem para confirmação de dispositivo ativo Fonte: Autoria Própria .......................................................................... 61
Tabela 25: Estrutura de mensagem para um ACK Fonte: Autoria Própria ................ 61
Tabela 26: Tipos de comandos Fonte: Autoria própria .............................................. 62
Tabela 27: Controle PID básico. Fonte (Controle PID básico, UFSC s.d.). ............... 73
xiv
ABREVIATURAS
Sigla Significado
ACK
API
LED
LSB
MSB
NACK
PID
PCI
PWM
Acknowledge
Application Programming Interface
Light Emitting Diode
Least Significant Bit
Most Significant Bit
No Acknowledge
Proportional Integral Derivative
Placa de Circuito Impresso
Pulse Width Modulation
RF
RSSI
RX
SMD
TX`
UART
Radio Frequency
Received Signal Strength Indication
Receive
Surface Mount Device
Transmit
Universal Asynchronous Receiver Transmitter
UTFPR Universidade Tecnológica Federal do Paraná
USB
IR
I/O
Universal Serial Bus
Infrared rays
In/out
15
1 INTRODUÇÃO
O projeto consiste no desenvolvimento de um sistema capaz de controlar
robôs através do envio de comandos sem-fio por uma estação-base instalada em um
computador.
1.1 MOTIVAÇÃO
A escolha por esse projeto foi motivada inicialmente pelo desejo da
universidade em participar de competições de futebol de robôs com um projeto
completamente desenvolvido por alunos da própria universidade. No momento do
inicio do desenvolvimento do projeto, a universidade competia com robôs comprados
de uma empresa especializada e somente era responsável pela programação da
inteligência do robô. Visando eliminar essa dependência de tecnologia externa, foi
proposto que a equipe desenvolvesse um projeto que englobasse os aspectos de
hardware, comunicação e software dos robôs, projeto esse que seria acoplado à
atual mecânica dos robôs, em detrimento da tecnologia comprada anteriormente.
1.2 TRABALHOS CORRELATOS
O projeto proposto tem características muito similares à diversos outros
projetos desenvolvidos, inclusive dentro da própria UTFPR (Universidade
Tecnológica Federal do Paraná), e por esse motivo o estudo de trabalhos correlatos
é muito importante, pois pode poupar a equipe de fazer escolhas equivocadas.
1.2.1 Omni¹
O primeiro projeto analisado foi o robô Omni¹, cuja proposta foi muito similar a
nossa, sendo a principal diferença o tamanho dos robôs em questão. O projeto
Omni¹ consiste em uma plataforma mecânica com 3 rodas com motores dispostas
de maneira a conseguir movimento omnidirecional, um hardware embarcado capaz
de acionar os motores, receber informações dos sensores em cada roda e assegurar
que o sistema seria capaz de receber e interpretar comandos enviados de maneira
sem fio pela estação-base. (Nishibe, et al. 2010)
16
Figura 1: Omni¹ Fonte: (Nishibe, et al. 2010)
A equipe que desenvolveu o projeto Omni¹ optou por utilizar a linguagem Java
para desenvolver a estação-base, opção essa que também foi analisada pela
equipe. Uma vez que eles obtiveram sucesso utilizando Java, pode-se reforçar a
convicção de que utilizar a mesma tecnologia seria suficiente para atender aos
requisitos desse projeto também.
O grande aprendizado que pôde ser extraído do estudo de caso do Omni¹ foi
sem dúvida a questão da expansibilidade. O projeto atendeu aos requisitos aos
quais ele se propôs, no entanto o microprocessador escolhido para o sistema
embarcado deixava uma margem para expansões muito reduzida, de modo que boa
parte do trabalho desenvolvido se perdeu no desenvolvimento do projeto Omni², que
será detalhado a seguir. Tendo em vista esse erro de projeto cometido pela equipe
do robô Omni¹, foi considerado sempre nas decisões desse projeto a questão da
expansibilidade, de modo que uma equipe possa posteriormente dar continuidade ao
robô com o mínimo de “retrabalho” possível.
17
1.2.2 Omni²
O segundo trabalho correlato analisado foi justamente o projeto Omni², que
aprimorou o robô do projeto Omni¹ de modo a utilizar uma bússola e sensores de
distância, bem como aprimorar outros aspectos não abordados. O microcontrolador
teve que ser alterado devido à falta de capacidade de expansibilidade no primeiro
microcontrolador PIC utilizado. A equipe do robô Omni² optou por utilizar um
microcontrolador Arduino Mega, que tem capacidade de processamento mais do que
suficiente para atender aos requisitos, bem como grande capacidade de
interfaceamento com periféricos e ports de entrada e saída. O microcontrolador
escolhido pela equipe pertence à mesma família do Arduino Mega, sendo a única
diferença entre eles o acesso aos periféricos e a dimensão da placa em que o chip
está acomodado. Como a dimensão do robô a ser desenvolvido é inferior à
dimensão dos dois robôs Omni, optamos por um microcontrolador acomodado em
uma placa menor. (KURPIEL, NASCIMENTO, HIGASKINO, & COSTA, 2010).
1.2.3 RoboFEI
Por fim, o último artigo analisado foi resultado de um projeto de iniciação
científica desenvolvido pelo aluno Fernando Perez Tavares no Centro Universitário
da FEI. Esse projeto difere desse pelo fato de se basear em um robô omnidirecional
de 4 rodas, no entanto boa parte da pesquisa desenvolvida por esse artigo pode ser
aproveitada no desenvolvimento do robô proposto. Vale lembrar que esse artigo
trata do desenvolvimento de um robô omnidirecional incluindo toda a parte
mecânica, sendo que no caso desse projeto a base mecânica já está pronta e cabe
a equipe somente desenvolver o hardware e o software responsável por comandar o
robô.
18
Figura 2: RoboFEI Fonte: (Tavares 2007).
1.3 OBJETIVOS
O projeto proposto tem como objetivo desenvolver um sistema composto por
hardware e software para controlar um robô capaz de competir em campeonatos de
futebol de robôs.
O sistema pode ser dividido em 3 subsistemas, sendo eles o sistema
embarcado, o sistema de comunicação e o sistema da estação-base, cada qual com
seus objetivos e requisitos específicos.
A estação-base deve ser capaz de enviar comandos para o robô através de
uma interface gráfica e deve controlar quais robôs estão aptos a receber instruções.
Ela também deve possuir um framework de modo que uma inteligência artificial
possa executar acoplada a ela enviando os comandos aos robôs.
O sistema de comunicação deve ser capaz de enviar os comandos de modo
sem fio para os robôs e garantir que todos os robôs recebam seus respectivos
comandos, bem como garantir que não haja conflitos de comunicação.
19
O sistema embarcado deve ser capaz de interpretar os comandos recebidos e
acionar os componentes eletrônicos necessários para executar o comando enviado
pela base.
20
2 PLANEJAMENTO
2.1 DECLARAÇÃO DO ENCOPO EM ALTO-NÍVEL
O sistema embarcado conterá um microcontrolador o qual possuirá um
firmware para controle do robô, um sistema de comunicação sem fio com o
computador (estação base) que possuirá um software de controle de velocidade e
posição dos robôs, capaz de movimentar-los, para frente e para trás, além de
rotações no sentido horário e anti horário.
2.2 PREMISSAS E RESTRIÇÕES
Deixa-se claro que com o término do projeto ainda não será possível a
participação de nosso robô nos jogos de futebol de robôs, pois o “chutador” e o
“prendedor de bola” ou também chamado de “driblador” não serão implementados
no projeto, entretanto ele será construído de modo que futuramente outros projetos o
aprimorem incluindo novas funcionalidades.
Estará disponível a nossa equipe a base mecânica do robô que contém
motores, encoders, rodas, e baterias já instaladas além de um espaço físico dentro
do robô para a alocação do sistema a ser construído. Ela não será construída pois a
tempo que seria gasto na etapa de planejamento e construção da mesma seria
demasiadamente grande para prejudicar o decorrer do projeto. Considera-se que o
local onde o robô será utilizado não contenha imperfeições e seja adequado para a
roda utilizada além de que ele esteja dentro do alcance máximo do sistema de
comunicação e que exista um computador disponível para que o software da
estação base seja executado. Além desses aspectos do projeto considera-se que
não haja atraso de entrega de componentes quando estivermos no período de
implementação.
O microcontrolador deverá conter pinos de I/O sobrando afim de proporcionar
futuras implementações como o “driblador” e “chutador”. O protocolo deverá ter além
de comandos específicos do robô desse projeto que não é omnidirecioal deverá
possuir suporte para robôs omnidirecionais.
21
A opção tecnológica escolhida não deve ultrapassar o orçamento
preestabelecido, a não ser que seja realmente necessário. O tempo de execução do
projeto não pode exceder e para que não haja imprevistos durante o decorrer do
cronograma bem como imperfeições é necessário que o cronograma seja seguido
de modo mais fiel possível, pois não há tempo de folga entre os prazos.
2.3 DESIGNAÇÃO DO GERENTE E DA EQUIPE
Gerente: Ari Magagnin Junior
Colaboradores: Eduardo Cabral Resende Neiva, João Hamilton Cecato Simas
2.4 PLANEJAMENTO DE RISCOS
Os relatórios com os planos de resposta ao risco são apresentados em
anexo.
2.5 REQUISITOS
1. Requisitos do robô:
Requisitos – Robô Especificação – Robô
Se locomover com dois graus de liberdade em um plano.
Possuir três rodas com discos pequenos em torno da circunferência que são perpendiculares à direção de laminação para, acopladas em motores DC, que possam ser acionados nas duas direções através de um circuito de ponte-H.
Locomover-se com velocidade e aceleração controlada numa direção dada e por uma distância pré-determinada.
Os motores serão controlados por PWM com realimentação através dos encoders para o sistema de controle Proporcional-Integral derivativo.
Medir a distância percorrida. Calibrar os encoders de forma a conhecer a distância percorrida em determinada direção.
Ser alimentado com baterias. Alimentar os motores utilizando dois bancos de pilhas AA e o microcontrolador será alimentado por uma bateria separada de 9V para evitar interferência por indução dos motores.
Tabela 1: Requisitos do robô. Fonte: Autoria própria.
2. Requisitos da comunicação:
22
Requisitos - Comunicação Especificação – Comunicação
Comunicar-se com a base por meio de um sistema sem fio.
Utilizar um equipamento que permita comunicação bidirecional com um alcance mínimo de 20 metros.
Garantir a integridade dos pacotes recebidos pela base.
Especificar um protocolo que permita a detecção de erros e contemple reenvio de pacotes perdidos.
Baixo consumo de energia. A alimentação do sistema de comunicação deve ser inferior a 9V e deve consumir a menor energia possível de modo a garantir uma boa autonomia do robô.
O sistema de comunicação deve possuir uma taxa de transferência mínima para suportar o protocolo.
O sistema de comunicação deve ser capaz de transferir no mínimo 50kbps.
Tabela 2: Requisitos do da comunicação. Fonte: Autoria própria.
3. Requisitos da estação base:
Requisitos – Estação Base Especificação – Estação Base
A estação base deve ser capaz de controlar 5 robôs.
O sistema de comunicação e a interface devem ser capazes de controlar até cinco robôs e garantir a integridade de informação para todos eles.
A estação base deve ser capaz de enviar comandos de movimento e direção para os robôs
Cada comando enviado pela base para cada robô deve consistir em uma direção e uma distância a ser percorrida, de modo que o próprio robô faça uso de seu sistema de controle para executar o comando.
Tabela 3: Requisitos da estação base. Fonte: Autoria própria.
Existem ainda outros requisitos não funcionais, que proporcionam maior
flexibilidade ao desenvolvimento do projeto, bem como ao produto final:
1. Interface gráfica de fácil manuseio;
2. Multiplataforma;
3. Orientada a objetos;
4. Ferramentas de desenvolvimento de boa qualidade e sem custo.
23
2.6 ALTERNTIVA TECNOLÓGICA
2.6.1 Estação base
A estação base consiste em um computador com uma plataforma capaz de
executar a linguagem escolhida. A interface com o usuário proposta é mostrada na
Figura 3. A interface consiste em alguns campos, como o de “seleção” do robô que
executará o comando e um campo de informações do comando que será executado.
Ainda existe outro campo em que o usuário mandará uma linha de comando
preestabelecida para do robô.
Figura 3: Proposta de interface com o usuário da estação base. Fonte: Autoria própria.
2.6.2 Linguagem de programação
2.6.2.1 JAVA
A primeira linguagem de programação a ser estudada é a Java. Esta
linguagem tem suporte extensivo à comunicação serial através de bibliotecas,
ajudando a concluir um dos requisitos necessários. Ela também possibilita que seja
24
desenvolvido um framework com todas as sub-rotinas de comunicação com o robô,
de modo que um próximo projeto (por exemplo, construir a inteligência do robô)
bastaria apenas estudar a documentação do framework desenvolvido pelo grupo,
desenvolvendo seu trabalho em cima deste framework.
A plataforma Java possui um ambiente de desenvolvimento muito poderoso e
de custo zero, chamado Netbeans (NetBeans 2011). Ambiente este que também
possibilita o desenvolvimento de interfaces gráficas de maneira muito simples,
facilitando no processo de construção e demonstração do produto final. Outras
características importantes da plataforma Java são os fatos de ser totalmente
orientada a objetos e funcionar em diversos sistemas operacionais, como por
exemplo: Windows, Linux e Mac OS.
Dessa forma a linguagem Java foi escolhida uma vez que essa opção atende
ao requisito mais importante, e possui aspectos que permite um desenvolvimento
significativo da estação.
2.6.2.2 C
A linguagem de programação C atende aos requisitos primários do projeto,
que são comunicação serial e possibilidade de desenvolver framework. No entanto,
ela tem algumas limitações que podem dificultar o desenvolvimento do projeto e
prejudicar o produto final.
Essas limitações são principalmente os fatos de não ser orientada a objeto,
dificultando o desenvolvimento, organização e documentação dos códigos-fonte. Ela
também não é multiplataforma, ou seja, compilando o código em uma plataforma,
por exemplo, no Windows, resulta em um programa que não pode ser utilizado em
outras plataformas, como, por exemplo, no Linux. Com relação às ferramentas de
desenvolvimento, existem opções sem custos, mas com sérias limitações – como,
por exemplo, o Dev C++ - e opções com custo alto, que são excelentes ambientes
de desenvolvimento, por exemplo, Visual Studio.
25
2.7 SISTEMA DE COMUNICAÇÃO
O sistema de comunicação será responsável por conectar o computador a
vários robôs. Dentre os sistemas mais utilizados, é citado as principais
características de cada um na e compará-las com os requisitos necessários ao
projeto, eliminando as tecnologias não cabíveis.
ZigBee 802.11 ( Wi-Fi ) Bluetooth IR Wireless
Velocidade de
transmissão de
dados
20, 40 e 250
Kbits/s 11 e 54 Mbits/sec 1 Mbits/s
20-40 Kbits/s
115 Kbits/s
4 Mbits/s
Alcance 10 - 100 metros 50 - 100 metros 10 metros < 10 metros
(linha de visão)
Topologia de
rede
Ad-hoc, peer to
peer ou mesh Ponto até hub
Ad-hoc, redes
muito pequenas Ponto a Ponto
Complexidade Baixa Alta Alta Baixa
Consumo de Energia
Muito baixo Alto Médio Baixo
Tabela 4: Tabela de comparação de alternativos de comunicação sem fio. Fonte:
(Software technologies, group 2009)
Por se tratar de um sistema com fornecimento de energia limitada (uso de
baterias), utilizar uma tecnologia de comunicação de baixo consumo é uma boa
alternativa. Entre as tecnologias expostas acima temos ZigBee e IR (comunicação
através de raios infra-vermelho) como opções de baixo consumo. Enquanto as
demais alternativas também podem ser usadas, elas não são recomendadas devido
ao seu consumo de energia.
Considerando o alcance como um fator limitante, o alcance mínimo em uma
partida da Robocup F180 é de 4 metros, tornado todas as tecnologias viáveis.
Entretanto a IR Wireless exige que os sistemas que se comunicaram estejam em
sua linha de visão que ambos “enxergam”, o que nem sempre pode acontecer. Este
fator impossibilita a utilização do IR Wireless como tecnologia de transmissão.
26
Outro fator importante a ser tratado é o impacto da tecnologia no projeto, já
que quanto maior a complexidade, maior será o tempo gasto na comunicação, algo
que como já analisado pode prejudicar o desenvolvimento do projeto. Esse fator é o
que torna a comunicação Wi-Fi e Bluetooth opções pouco interessantes, ao contrário
do ZigBee, que é de baixa complexidade.
O ZigBee, então, é a escolha que mais se ajusta ao projeto, além disso já foi
usados em trabalho dos semestres anteriores e apresentou bons resultados.
2.8 SISTEMA EMBARCADO
O sistema eletrônico do robô possui uma variedade de componentes e
dispositivos a serem analisados, entretanto apenas foi feito um estudo dos
componentes mais críticos descritos nos itens que seguem.
27
2.8.1 Ponte-H
O papel da ponte H no sistema embarcado é possibilitar a movimentação dos
motores em ambos os sentidos, com controle de velocidade.
2.8.1.1 Ponte-H utilizando componentes discretos
Ao invés de utilizar um CI pronto, pode-se montar uma ponte-H com
componentes discretos. Para isto deve-se utilizar transistores que suportem corrente
de 2 [A] e tensão de 16 [V] e outros componentes passivos que suportam tais
requisitos que existem no mercado.
2.8.1.2 L298N
Componente eletrônico utilizado para controle de motores DC. Possui boa
disponibilidade no mercado local e seu preço gira em torno de R$13,00. Pode ser
utilizada alimentação de até 46 [V] (sendo que a bateria usada é de 16V) e com
corrente máxima de até 2 [A], o que está atende as determinações do projeto.
Figura 4: L298. Fonte: (STMicroelectronics 2000)
2.8.1.3 Comparação e escolha da ponte-H
A utilização do L298 atende os requisitos do projeto além de ocupar menos
espaço na PCI, alem disso possui um circuito de proteção de curto internamente. Já
a ponte-H com componentes discretos pode atender os requisitos se utilizado os
componentes adequados, além de ocupar tempo para a montagem do circuito e não
possuir proteção contra curto a não ser que se faça uma sofisticação no circuito.
28
Tais fatores foram preponderantes a ser considerado na escolha de uma tecnologia.
Dessa forma foi tornado como melhor opção tecnológica a ponte-H L298N.
2.9 MICROCONTROLADOR
Para controlar o robô, o microcontrolador deve possuir algumas
características:
Mínimo
Saídas PWM 5
Timers 3 (Liberados)
Pinos I/O livres 12
Suporte para expansibilidade UART, SPI ou I2C
Figura 5: Características necessárias do microcontrolador. Fonte: Autoria própria.
2.9.1 Atmega328
Microcontrolador conhecido utilizado no Arduino Uno. Esta plataforma possui
um conector USB que permite acesso a qualquer computador moderno. Sua
programação é feita a partir de uma linguagem própria, chamada Wiring, o que
facilita a gravação de programas. A equipe já possui um dispositivo desse, o que
reduz os custos.
Não atende aos requisitos do projeto, pois possui apenas 2 timers disponíveis
e não possui terminais suficientes de I/O.
29
Figura 6: Atmega328. Fonte: (ATMega328 28 pin DIP with Bootloader s.d.)
2.9.2 DSPIC30F3010
O dsPic30F30 é caracterizado por se um microcontrolador de arquitetura
RISC que possui algumas características de DSP. Possui 6 saídas PWM, interface
UART, três interrupções externas e multiplicação por hardware em um ciclo de clock
alem de interfaceamento serial. (Microchip, 2005)
Em um projeto passado, esse microcontrolador foi utilizado com sucesso.
Entretanto, pela falta de terminais de I/O acabou não possibilitando futuras
expansões.
Não atende aos requisitos do projeto pela falta de terminais, inviabilizando um
projeto onde a expansibilidade é um dos requisitos.
2.9.3 Atmega 640
O microcontrolador Atmega640 é um modelo da Atmel que é conhecido
por ser utilizado no Axon. Possui interfaceamento USB e a programação é feita por
meio do AVR Studio. Possui 6 timers, 55 terminais de entrada e saída e 64 kB de
memória interna.
30
Figura 7: Atmega640. Fonte: ( Lista de microcontroladores AVR s.d.)
2.9.4 Atmega2560
O microcontrolador Atmega2560 é o mais potente da categoria compatível
com o Arduino, sendo que possui 54 terminais - 14 com possibilidade de PWM, e
uma memória interna de 256KB. Sua programação também é feita em Wiring e
possui interfaceamento USB. Ao contrário do Atmega328, esse microcontrolador só
possui versão SMD.
Figura 8: Atmega2560. Fonte: ( Lista de microcontroladores AVR s.d.)
31
2.9.5 C8051F340
O microcontrolador da Silicon Labs possui 64 kB de flash, 4 kB de memória
interna e opera a 48 MHz, executando 48 MIPS. Possui também 40 portas de I/O e 4
Timers. Ele é baseado na arquitetura 8051, diferentemente dos outros
microcontroladores analisados, que são baseados na arquitetura AVR. A grande
desvantagem é a dimensão da placa, a qual é muito grande devido a extensa
quantidade de periféricos encontrados nesse microcontrolador. Assim, não é
possível acomodá-lo na estrutura do robô, inviabilizando a utilização deste
microcontrolador no projeto.
2.9.6 Comparação e escolha do microcontrolador
Descartando os microcontroladores que não possuem os requisitos
necessários sobram apenas dispositivos SMD. Isso acaba exigindo a compra de um
kit de desenvolvimento, pois a equipe não possui conhecimento suficiente para
soldar SMD e a aquisição de uma PCI com complexidade para SMD não é de fácil
acessibilidade ao grupo também.
É fato que ambos os kits de desenvolvimento possuem as características
necessárias para o desenvolvimento do projeto, sendo que as principais diferenças
consistem no Arduino Mega possuir quatro vezes mais memória que o Axon
(indiferente para o projeto) e o Axon ocupar uma área de superfície 21% menor. Foi
escolhido então o Axon por possuir todos os pinos de PWM disponíveis para uso –
problema enfrentado por projetos anteriores - e ser de tamanho reduzido, permitindo
um melhor aproveitamento do espaço interno do robô.
Arduino Mega Axon
Pinos I/O Digitais 54 55
PWM 14 9
Memória Interna 256 [KB] 64 [KB]
Pinos analógicos 16 16
Consumo 40mA 40mA
Timers 6 6
Velocidade do Clock 16Mhz 16Mhz
32
Figura 10: Microcontrolador Axon. Fonte: (Axon Microcontroller Description s.d.)
2.10 ORÇAMENTO INICIAL DETALHADO PREVISTO
Na primeira tabela encontram-se os custos de materiais necessários para que
haja início do projeto.
Dimensões 10,1cm*5,3cm*1,36cm 6,54cm*6,54cm*1,99cm
I2C 1 1
SRAM 8 [KB] 8 [KB]
EEPROM 4 [KB] 4 [KB]
UART 3 3
Familiaridade Alta Baixa
Custo U$65,00 U$95,00
Figura 9: Comparação Microcontroladores. Fonte: (Axon Microcontroller Description
s.d.) (Arduíno Mega 2560 s.d.)
33
Custo de material
Quantidade Material Preço por unidade Total
1 Axon 1 R$ 161,50 R$ 161,50
3 L298 R$ 10,88 R$ 32,64
2 Xbee chip antena R$ 39,02 R$ 78,03
1 Xbee Explorer R$ 42,42 R$ 42,42
3 Chave Ótica H22A1 R$ 4,50 R$ 13,50
5 Optoacopladores R$ 1,50 R$ 7,50
1 PCI de teste R$ 10,00 R$ 10,00
Custo dos fretes
1 Frete R$ 90,00 R$ 90,00
Total dos
Custos
R$ 435,59
Do orçamento inicial planejado a ser gasto com materiais, ainda sobra
R$201,41 para ser gastos nos componentes e na placa PCI a ser projetada.
O orçamento das atividades segue mostrado na Tabela 5: Gastos com
recursos humanos. Fonte: Autoria própria.Tabela 5 que refere-se as horas de
trabalhos dos envolvidos no projeto.
Gastos em recursos humanos Custo
Execução R$ 8.604,00
Estudo R$ 1.692,00
Microcontrolador R$ 1.260,00
Ponte H R$ 1.008,00
Encoders+motor R$ 1.152,00
Optoacoplador R$ 1.152,00
Xbee R$ 720,00
Compra dos componentes R$ 720,00
34
Compra Microcontrolador R$ 144,00
Compra Xbee R$ 144,00
Compra Optoacoplador R$ 144,00
Compra ponte H R$ 144,00
Compra Encoders reserva R$ 144,00
Compra PCI de teste R$ 144,00
Testes iniciais R$ 2.592,00
Encoder R$ 144,00
Documentação [Encoder] R$ 144,00
Ponte H R$ 144,00
Documentação [Ponte H] R$ 144,00
Motor DC R$ 144,00
Documentação [Motor DC] R$ 90,00
Xbee R$ 288,00
Documentação [xbee] R$ 144,00
Optoacoplador R$ 288,00
Documentação [Optoacoplador] R$ 90,00
Implementação R$ 6.192,00
Diagrama esquemático R$ 216,00
Ponte H + Controle R$ 936,00
Análise [Ponte H + Controle] R$ 288,00
Desenvolvimento [Ponte H + Controle] R$ 504,00
Documentação [Ponte H + Controle] R$ 144,00
Motor DC R$ 1.008,00
Análise [Motor DC] R$ 288,00
Desenvolvimento [Motor DC] R$ 576,00
Documentação [Motor DC] R$ 144,00
Encoder + Controle R$ 864,00
Análise [Encoder + Controle] R$ 144,00
Desenvolvimento [Encoder + Controle] R$ 576,00
Documentação [Encoder + Controle] R$ 144,00
Xbee R$ 2.016,00
Análise [Xbee] R$ 288,00
Desenvolvimento [Xbee] R$ 1.296,00
Documentação [Xbee] R$ 144,00
Optoacoplador R$ 864,00
Análise [Optoacoplador] R$ 144,00
Desenvolvimento [Optoacoplador] R$ 576,00
Documentação [Optoacoplador] R$ 144,00
Testes circuitos R$ 3.312,00
Teste sem Xbee R$ 288,00
Teste com Xbee R$ 144,00
Análise [Testes do circuito] R$ 198,00
Desenvolvimento [Testes do circuito] R$ 288,00
35
Documentação [Testes do circuito] R$ 144,00
Placa de circuito impresso [PCI] R$ 576,00
Análise [PCI] R$ 144,00
Desenvolvimento [PCI] R$ 288,00
Documentação [PCI] R$ 126,00
Programação R$ 4.752,00
Estação base R$ 864,00
Encoder R$ 432,00
Xbee R$ 1.008,00
Controle R$ 720,00
Integrar módulos R$ 1.008,00
Documentação Parcial [Software] R$ 576,00
Verificação e testes R$ 288,00
Teste comunicação+locomoção+base R$ 144,00
Ajustes finais R$ 144,00
Documentação R$ 11.448,00
Documentação Final [Software] R$ 3.663,36
Redigir monografia R$ 7.784,64
Criar apresentação R$ 72,00
Gerenciamento fase 1 R$ 1.584,00
Gerenciamento fase 2 R$ 1.440,00
Gerenciamento fase 3 R$ 1.584,00
Gerenciamento fase 4 R$ 1.872,00
TOTAL R$ 26.532,00
Tabela 5: Gastos com recursos humanos. Fonte: Autoria própria.
2.11 ORÇAMENTRO DETALHADO GASTO
O orçamento detalhado gasto no projeto encontra-se na Tabela 6.
Orçamento Quantidade Custo Custo Total
impressão monografia - previsão 1 R$ 30,00 R$ 30,00
impressão project charter 2 R$ 1,50 R$ 3,00
LN298 6 R$ 9,90 R$ 59,40
LM7805 4 R$ 1,52 R$ 6,08
LM7812 4 R$ 3,12 R$ 12,48
PCI padrão 1 R$ 14,10 R$ 14,10
Barras de pinos 6 R$ 2,20 R$ 13,20
2 Dip 5 vias 2 R$ 1,50 R$ 3,00
Dissipadores 6 R$ 1,50 R$ 9,00
Micas 1 R$ 2,10 R$ 2,10
36
Placa do Xbee xbeestore 1 R$ 17,89 R$ 17,89
Conectores KK 1 R$ 12,00 R$ 12,00
Cabos flat 1 R$ 20,40 R$ 20,40
74LS14 2 R$ 3,80 R$ 7,60
4N35 12 R$ 0,59 R$ 7,08
Socket 6 pinos 18 R$ 0,50 R$ 9,00
Socket 14 pinos 1 R$ 1,00 R$ 1,00
Solda - estanho 1 R$ 6,00 R$ 6,00
Resistores 1 R$ 5,00 R$ 5,00
Capacitores 1 R$ 2,00 R$ 2,00
Diodos 1 R$ 3,00 R$ 3,00
LED 4 R$ 0,20 R$ 0,80
Pilha 9v 1 R$ 9,00 R$ 9,00
Axon + frete + imposto 1 R$ 251,40 R$ 251,40
2 Xbee + Xbee Explorer + frete 1 R$ 163,20 R$ 163,20
PCI 1 R$ 180,00 R$ 180,00
Atmega 1 R$ 20,00 R$ 20,00
Total R$ 867,73
Tabela 6: Orçamento real. Fonte: Autoria própria.
2.12 CRONOGRAMA
Na Tabela 7 é mostrado o cronograma feito com a utilização do software
OpenProj indicado pelos professores da disciplina.
39
2.13 ENTREGÁVEIS
Data ENTREGÁVEL
28/04/11 1. Projeto do software que vai rodar na estação base (Interface usuário).
2. Teste com o encoder (Dados)
12/05/11 1. Demonstração da locomoção do robô rudimentar (apenas movimentos de rotação, na horizontal e vertical) com um cabo ligando o Robô a base (PC).
26/05/11 1. Demonstração básica da comunicação sem fio com o Xbee (Hello world).
2. Demonstração do Software da estação base.
09/06/11 1. Robô capaz de responder comandos mandados pela base (Comandos de direção e distância a se deslocar).
2. Demonstração do projeto da PCI da ponte-H.
Tabela 8: Entregáveis. Fonte: Autoria propria.
2.14 AUXILIARES DE GERENCIAMENTO
A cada fase de execução do projeto foi determinado um auxiliar de
gerenciamento (sub-gerentes) conforme determinado pelos professores da matéria
de Oficinas de Integração 3, esse auxiliar deve ser um membro da equipe do projeto.
A apresenta os nomes dos auxiliares a fase a qual ele vai auxiliar.
Fase Auxiliar de gerenciamento
1 Eduardo Cabral Resende Neiva
2 Fábio César Schuartz
3 João Hamilton Cecato Simas
4 Eduardo Cabral Resende Neiva
Tabela 9: Auxiliares de gerenciamento. Fonte: Autoria própria.
41
3 EXECUÇÃO
3.1 ARQUITETURA GERAL DO HARDWARE E SOFTWARE
A disposição geral dos componentes dentro do sistema bem como as
interligações entre eles estão delineadas no diagrama da Figura 11.
Figura 11: Arquitetura geral do sistema Fonte: Autoria Própria
Os comandos enviados pelo usuário do sistema, seja ele um ser humano ou
uma inteligência artificial, são interpretados pelo software da estação base,
formatados de acordo com o protocolo de comunicação, enviados para os módulos
Xbee remotos, desempacotados e interpretados pelo firmware para finalmente
atuarem no hardware do robô de modo a executar fisicamente o comando recebido.
42
3.2 ESTAÇÃO-BASE
O sistema da estação-base é aquele que é responsável por interfacear com
usuários humanos, através da interface gráfica, ou com uma inteligência artificial,
através do framework e do parser, e formatar os comandos recebidos para que eles
sejam enviados através do sistema de comunicação e o robô os execute com
sucesso. O software da estação-base foi desenvolvido conforme a modelagem da
Figura 12.
Figura 12: Diagrama de classes da Estação-Base Fonte: Autoria Própria
3.2.1 Framework
O Framework é a parte do software responsável por controlar a comunicação
com os diversos robôs conectados à base, bem como prover acesso padronizado às
43
funcionalidades do sistema para um usuário, seja ele uma inteligência artificial,
através do parser, ou um ser humano, através da interface gráfica.
Em uma primeira analise do diagrama de classes, pode-se ver um grande
pacote chamado framework, que contém as classes desenvolvidas para modelar o
problema proposto, e outro pacote chamado xbeeapi que contém as classes
pertencentes à biblioteca xbeeapi que são utilizadas pelo framework.
A classe Robô é aquela responsável por modelar os aspectos relevantes do
Robô do ponto de vista da estação-base. O atributo mais importante é o endereço
do Xbee acoplado ao robô, pois ele irá garantir que os comandos enviados pela
base sejam executados pelo robô correto. Esse atributo é modelado pela classe
XbeeAddress16 da própria biblioteca xbeeapi, que é basicamente um número de 16
bits que identifica cada módulo Xbee. Há também um atributo nome que possibilita
que cada robô seja identificado por uma String escolhida pelo usuário. Quanto aos
métodos disponibilizados por essa classe, temos 5 métodos que basicamente
enviam comandos de movimentação para o Robô em questão, sendo eles forward(),
backward(), rotateRight(), rotateLeft() e moveOmni(). O construtor da classe Robô
necessita dos 2 bytes de endereço e do nome específico desse Robô, no entanto
esses parâmetros podem ser alterados posteriormente através dos métodos
disponibilizados. Há também o método getData() que solicita ao Robô o envio de
informações, como por exemplo, carga da bateria.
A classe Payload representa um vetor de bytes a ser enviado para um Robô
remoto, incluindo já os bytes de controle como header e trailer e também com o
comando a ser enviado já codificado em bytes conforme definido pelo protocolo. O
método mais importante dessa classe é o getPayload(), que retorna um vetor de
bytes, com o comando já codificado, a ser enviado pelo método sendSynchronous()
da classe Xbee.
Para tratar o recebimento de pacotes do Robô, foi desenvolvida a classe
MyPacketListener que implementa a interface PacketListener. Um objeto dessa
classe é cadastrado como listener no Xbee da estação-base, de modo que toda vez
44
que um novo pacote é recebido na estação-base é disparado o método
processResponse() que irá tratar adequadamente o pacote recebido.
A classe mais importante do framework é sem dúvida a classe
CommunicationsHandler. Essa classe gerencia toda a parte de configuração do
Xbee, bem como a implementação do buffer de saída. Para enviar um pacote para
um Robô o método sendPayload() deve ser chamado. Esse método irá encapsular o
comando em um objeto TXRequest16 e posteriormente em um objeto BufferItem,
que é somente um TXRequest16 junto com uma contagem de tentativas de
transmissão malsucedidas, para que ele seja adicionado ao final da fila do buffer de
transmissão. O buffer da transmissão funciona conforme o seguinte algoritmo:
1) Tentativa de envio do primeiro BufferItem da fila de transmissão.
a) Em caso de sucesso.
i) Remove o item da fila de transmissão.
ii) Retorna ao passo número 1.
b) Em caso de timeout.
i) Incrementa o contador de tentativas de transmissão.
ii) Verifica se o número de tentativas máximas foi atingido.
(1) Caso sim remove o item da fila de transmissão e notifica o problema de
transmissão através do console.
(2) Caso não move o item para o final da fila de transmissão e retorna ao
primeiro passo do algoritmo.
O algoritmo também pode ser descrito através de um diagrama de atividades,
mostrado na Figura 13.
45
Figura 13: Diagrama de atividades do algoritmo do buffer. Fonte: Autoria Própria
O buffer de transmissão juntamente com o parser, que será detalhado a
seguir, possibilita que vários robôs sejam comandados com um único comando.
Esse comando será interpretado pelo parser que irá carregar individualmente o
comando de cada robô na fila do buffer, sendo esse responsável por transmitir o
comando de cada robô através de um algoritmo Round Robin modificado. Ele é
modificado no sentido de que se houverem problemas de comunicação com um dos
robôs da lista, o buffer irá mover o comando desse robô para o final da fila de
transmissão, possibilitando que os outros robôs recebam seus comandos mesmo
que haja um robô com problemas de comunicação na fila de transmissão.
3.2.1.1 Parser
O Parser é o componente do framework responsável por interpretar
comandos complexos que envolvem vários robôs e dividi-los em comandos
46
individuais para cada robô para que possam ser adicionados ao buffer de
comunicação. A estrutura do comando do parser é mostrada na Figura 14:
Figura 14: Estrutura dos comandos do parser. Fonte: Autoria Própria
A palavra chave que inicia um comando é “cmd”, qualquer palavra diferente
dessa invalida o comando e o parser irá notificar que não conseguiu interpretar o
comando. Logo após a palavra de inicio deve-se deixar um espaço em branco e
então inserir o primeiro comando a ser enviado.
Cada comando é estruturado conforme a segunda tabela da Figura 14. A
primeira String contém o endereço hexadecimal de 16 bits do robô que deve receber
o comando. Logo após deve ser inserido um delimitador “,” para que o parser saiba
que o endereço terminou. O próximo campo a ser inserido é o código da função a
ser enviada para o robô. Uma tabela com os códigos de funções pode ser
encontrada na seção 3.3.2.4 . Outro delimitador “,” deve ser inserido para então
iniciar a parte dos parâmetros do comando. Cada um dos 4 parâmetros do comando
deve ser inserido após um delimitador e caso algum parâmetro não seja utilizado,
deve ser inserido o valor “-1” no lugar do parâmetro. Após o quarto parâmetro o sub-
comando é finalizado e deve ser inserido ou um delimitador ”/”, para inserir outro
sub-comando, ou um “;” para indicar o fim do comando a ser passado para o parser.
Um exemplo de comando que pode ser enviado para o parser pode ser:
“cmd 0x1234,0x26,0xAB,0xFF, 0xFF, -1/0x5678,0x27,0,255, 10,-1;”
Esse comando ordena que o robô no endereço 0x1234 ande 0x0AFF (2815)
centímetros para frente e que o robô no endereço 0x5678 ande 255 centímetros
para trás. Pode-se observar nesse exemplo que os parâmetros das funções podem
ser passados como números decimais de 0 a 255 ou então como números
47
hexadecimais de 0x00 até 0xFF. Se a notação utilizada for hexadecimal é
necessário preceder o parâmetro com o identificador hexadecimal “0x”.
3.2.2 Interface Gráfica
A interface gráfica desenvolvida possibilita que um usuário humano tenha
acesso fácil às funções do framework e possa testar as funcionalidades do sistema
como um todo.
Figura 15: Layout da interface gráfica. Fonte: Autoria Própria
Pode-se observar claramente 3 painéis distintos na interface. O primeiro deles
fica no canto superior esquerdo do layout, e é responsável por listar todos os robôs
atualmente conectados à estação base. Essa lista é atualizada sempre que o
framework detecta um novo robô na rede ou quando um robô é desconectado por
timeout. Os robôs aparecem na lista com o nome que lhes foi atribuído e com o
endereço do Xbee remoto acoplado a eles dentro de parênteses. O segundo painel,
48
localizado no canto superior direito, é responsável por receber as entradas do
usuário e formatá-las em um comando que possa ser enviado pelo framework, bem
como impedir que o usuário envie comandos inválidos. Ele possibilita que o usuário
envie comandos individualmente para cada robô conectado na rede de maneira fácil
e intuitiva. O terceiro painel, localizado na metade inferior da janela, contém um
console que informa ao usuário todas as operações realizadas pela base, como por
exemplo, envio de comandos, alterações nos parâmetros de configuração da porta
serial e erros de comunicação, bem como o assistente de configuração da conexão
serial e um botão que limpa o console. Há também nesse painel um campo de onde
é possível enviar comandos diretamente ao parser, de modo que o usuário pode
montar comandos que afetem 1 ou mais robôs, conforme descrito na documentação
do parser.
3.3 SISTEMA DE COMUNICAÇÃO
A parte de sistema de comunicação envolve o protocolo de como será feito a
comunicação. Esse protocolo deve garantir que a transmissão de dados seja bem
sucedida e caso haja uma perda de comunicação com o robô o usuário seja
devidamente alertado.
3.3.1 Módulos de comunicação
Durante a etapa de planejamento do projeto foram feitos vários levantamentos
com o objetivo de determinar qual tecnologia de comunicação sem fio servia melhor
aos propósitos do projeto. Feita essa análise de opções tecnológicas, a equipe optou
por utilizar o protocolo ZigBee, pois ele oferece baixo consumo, taxas de
transferência suficientes e alcance satisfatório para os requisitos do projeto, aliados
ao custo relativamente baixo em relação às outras tecnologias avaliadas. A etapa
seguinte foi selecionar quais módulos utilizar para realizar essa comunicação.
Optou-se por utilizar os módulos Xbee serie 1, pois são mais utilizados e facilmente
encontrados além de possuírem um custo acessível. Esses módulos consistem de
pequenos circuitos integrados preparados para se comunicar com uma UART, de
modo que, tanto o microcontrolador, quanto a estação base podem enviar comandos
wireless da mesma maneira que enviariam comandos através de um cabo serial
49
comum. Logicamente há todo um formato de frame a ser respeitado bem como
outras características de transmissão que devem ser definidas, a serem discutidas
logo abaixo, no entanto esse modelo Black-box dos módulos facilita muito a
implementação da comunicação, pois não existe a preocupação com os níveis mais
baixos do processo de transmissão sem fio.
Figura 16: Módulo Xbee Series 1 Fonte: (Digi International n.d.)
3.3.2 Protocolo
Para realizar a comunicação, é necessário estabelecer um formato de
transmissão da informação, denominado protocolo de comunicação. Este protocolo
possui regras específicas que identificam a origem, o destino e a ação a ser
executada.
3.3.2.1 Formato da mensagem
Toda mensagem enviada pela estação-base ou pelos robôs segue um padrão
fixo definido que permite o processamento das informações transmitidas. O
50
conteúdo da mensagem terá no máximo 100 bytes. Conterá um identificador de
início (três bytes) e fim (três bytes) que podem ser visto na Tabela 10.
3 bytes 94 Bytes 3 bytes
Início Conteúdo da mensagem Fim
Tabela 10: Formato padrão de mensagem Fonte: Autoria própria
Como o tamanho máximo da mensagem é de 100 bytes (conforme definido
na API do Xbee), e que os identificadores de início e fim ocupam 3 bytes cada,
restam 94 bytes para inserir o conteúdo da mensagem.
3.3.2.2 Encapsulamento da mensagem
As mensagens são encapsuladas em frames dentro das operações do Xbee
no modo API. Entre as principais vantagens de utilizar o modo API, estão:
Permite o Xbee receber dados de um ou mais Xbee remotos;
Quando enviando um pacote, o transmissor recebe uma confirmação
(ACK) indicando que o pacote foi recebido com sucesso ou reenvia o
pacote caso contrário;
Os pacotes recebidos contém o endereço de origem do transmissor;
Obtém o RSSI (potência do sinal) de um pacote recebido;
Os pacotes já incluem um checksum para integridade dos dados;
Quando esse modo API está habilitado, o frame que encapsula a mensagem
segue a estrutura que pode ser vista na Figura 17: Estrutura do Frame.
51
Figura 17: Estrutura do Frame Fonte: (MaxStream USA).
Start Delimiter: Valor que indica o início de um pacote (0x7E)
Length: Comprimento da mensagem é calculado pelo tamanho da API-
specific structure, esse valor é dividido em MSB e LSB.
Checksum: Para calcular o checksum, é necessário somar todo o
conteúdo da mensagem original (excluindo o próprio checksum), após
isso, utilizando apenas os 8 bits menos significativos dessa soma, é
necessário retirar de 0xFF esse valor. Desse modo a verificação torna-
se mais simples, pois para verificar se a mensagem está integra, é
recalculado o checksum do conteúdo da mensagem e então somado
com o checksum da mensagem, caso tenha resultado em 0xFF, a
mensagem está integra.
3.3.2.2.1 Modos API
Dentro desse frame, a estrutura específica (API-specific Structure) segue o
padrão:
Figura 18: Data Frame e estrutura específica de cada API Fonte: (MaxStream USA)
O campo cmdID é responsável por armazenar que tipo de mensagem API
estará contida dentro do cmdData. Para cada cmdID, um tipo de operação será
52
executada pelo Xbee (i.e. 0x01 envio de uma mensagem com destino com endereço
de 16 bits).
3.3.2.2.2 Modos API Notáveis
3.3.2.2.2.1 TX: 16-bit address
É feito uma requisição para transmissão de uma mensagem usando um
endereço destino de 16 bits.
Valor identificador API (cmdID): 0x01
Figura 19: TX Packet ( 16 bit address ) Fonte: (MaxStream USA)
Dentro do cmdData tem-se:
Frame ID (byte 5): Identificador da mensagem. O valor 0x0 desabilitará
a resposta do frame.
Destination Address (bytes 6-7): Endereço de destino da mensagem.
0xFFFF para broadcast.
Options (byte 8): Opções extras de como a mensagem será tratada.
0x01 para desabilitar ACK ou 0x04 para enviar o pacote com o Pan ID
do broadcast (não utilizado).
RF Data (Byte(s) 9-n): Conteúdo da mensagem
3.3.2.2.2.2 TX Status
Necessário para verificar qual é o estado de um frame envaido.
Valor de identificador da API: 0x89
53
Figura 20: Frame do TX Status Fonte: (MaxStream USA)
Frame ID (Byte 5): Identificador de qual frame está sendo reportado.
Status (Byte 6): Define o status final do pacote enviado.
Valor Definição
0 Sucesso no envido a mensagem
1 Não recebeu ACK.
2 Erro CCA (Clear Channel Assessment)
3 Eliminado
3.3.2.2.3 Operações AT notáveis
Operações AT são necessárias para fazer mudanças de configuração do
Xbee. Elas são enviadas como comandos seriais através da UART para o Xbee.
Para realizar esse tipo de operação é necessário iniciar o modo de comandos
enviando o fluxo de chars “+++”.
3.3.2.2.3.1 DL – Destination Address Low
Configuram os 32 bits iniciais dos 64 bits disponíveis para endereçamento.
Para utilizar no modo de 16 bits, que foi utilizado no projeto, é necessário configurar
apenas os 16 bits iniciais utilizando a seguinte notação:
“+++” // inicia o modo de comando
54
“ATDL5678” // envia um comando AT com objetivo de trocar o DL para
0x5678.
3.3.2.2.3.2 FR
Reinicia o Xbee. (Tempo aproximado de reset = 100ms)
3.3.2.2.3.3 BD
Seleciona o baud rate a ser utilizada para a comunicação serial.
Valor (Hexadecimal) Baud Rate (bps)
0 1200
1 2400
2 4800
3 9600
4 19200
5 38400
6 57600
7 115200
Tabela 11: Baud Rate para valores de BD Fonte: Autoria Própria
Exemplo:
“+++” // Inicia o modo de configuração
“ATBD6” // Configura o baud rate em 57600bps
3.3.2.3 Estrutura da Mensagem
Dentro dos 94 bytes disponíveis para o conteúdo da mensagem, foram
utilizados apenas 5 bytes para caracterizar o conteúdo de uma mensagem. A opção
55
por utilizar um tamanho pequeno de mensagem contribui para reduzir a taxa de
erros e aumentar a taxa de pacotes enviados.
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5
Tipo Parâmetro 1 Parâmetro 2 Parâmetro 3 Parâmetro 4
Tabela 12: Estrutura da mensagem Fonte: Autoria Própria
O campo Tipo definirá que tipo de operação será utilizado. O campo permite a
inserção de até 255 tipos de comandos diferentes. Utilizando até 4 parâmetros.
3.3.2.3.1 Lista de Comandos
3.3.2.3.1.1 Comando de Andar em Frente
Esse comando é utilizado para mover um robô em linha reta para frente.
Utiliza parâmetros de distância e velocidade.
Código do comando: 0x26
Tipos dos parâmetros:
o Byte 1/2: Valor da distância em cm, MSB em byte 1 e LSB em
byte 2.
o Byte 3: Valor da velocidade em cm/s
o Byte 4: Não utilizado
Código Byte 1 Byte 2 Byte 3 Byte 4
0x26 MSB Distância LSB Distância Velocidade -
Tabela 13: Estrutura de uma mensagem de andar para frente (0x26) Fonte: Autoria
Própria
3.3.2.3.1.2 Comando de Andar para Trás
56
Este comando é utilizado para mover um robô em linha reta para trás. Utiliza
parâmetros de distância e velocidade.
Código do comando: 0x27
Tipos dos parâmetros:
o Byte 1/2: Valor da distância em cm, MSB em byte 1 e LSB em
byte 2.
o Byte 3: Valor da velocidade em cm/s
o Byte 4: Não utilizado
Código Byte 1 Byte 2 Byte 3 Byte 4
0x27 MSB Distância LSB Distância Velocidade -
Tabela 14: Estrutura de uma mensagem de ir para frente (0x27) Fonte: Autoria Própria
3.3.2.3.1.3 Comando de Girar em sentido horário
Este comando é utilizado para girar um robô no sentido horário. Utiliza
parâmetros de angulação e velocidade.
Código do comando: 0x28
Tipos dos parâmetros:
o Byte 1: Velocidade angular (rad/s)
o Byte 2: Ângulo
o Byte 3: Não utilizado
o Byte 4: Não utilizado
57
Código Byte 1 Byte 2 Byte 3 Byte 4
0x28 Vangular Ângulo - -
Tabela 15: Estrutura de uma mensagem de girar no sentido horário (0x28) Fonte:
Autoria Própria
3.3.2.3.1.4 Comando de Girar Anti-horário
Este comando é utilizado para girar no sentido anti-horário. Utiliza parâmetros
de angulação e velocidade.
Código do comando: 0x29
Tipos dos parâmetros:
o Byte 1: Velocidade angular (rad/s)
o Byte 2: Ângulo
o Byte 3: Não utilizado
o Byte 4: Não utilizado
Código Byte 1 Byte 2 Byte 3 Byte 4
0x29 Vangular Ângulo - -
Tabela 16: Estrutura de uma mensagem de girar anti-horário (0x29) Fonte: Autoria
Própria
3.3.2.3.1.5 Comando de andar em uma direção (x, y).
Este comando é utilizado enviar comandos de movimento omnidirecional.
Apenas funcional para um robô omnidirecional.
Código do comando: 0x30
58
Tipos dos parâmetros:
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: Não utilizado
Código Byte 1 Byte 2 Byte 3 Byte 4
0x30 Eixo X Eixo Y Velocidade -
Tabela 17: Estrutura da mensagem para o movimento em uma direção Fonte: Autoria
Própria
3.3.2.3.1.6 Comando de Ligar/Desligar Driblador
Este comando permite ativar ou desativar o driblador do robô – não disponível
atualmente o robô.
Código do comando: 0x60
Tipos de parâmetros: um parâmetro de 1 byte. O valor 0 (zero) desativa o
driblador, qualquer outro valor ativa o mesmo.
Código Byte 1 Byte 2 Byte 3 Byte 4
0x60 Tipo - - -
Tabela 18: Estrutura de mensagem para ligar/desligar driblador Fonte: Autoria Própria
3.3.2.3.1.7 Comando de acionar o chutador
Este comando permite ativar ou desativar o chutador – não disponível
atualmente no robô.
Código do comando: 0x61
59
Tipos de parâmetros: um parâmetro de 1 byte. O valor indica o porcentual de
força a ser aplicado no mecanismo de chute. Sendo que 0xFF seria com
potência máxima e 0x00 com potência mínima.
Código Byte 1 Byte 2 Byte 3 Byte 4
0x61 Intensidade - - -
Tabela 19: Estrutura de mensagem para acionar o chutador Fonte: Autoria própria
3.3.2.3.1.8 Comando de solicitar leitura de sensores
Este comando solicita ao robô que seja enviado a leitura atual de todos os
sensores.
Código do comando: 0x1A
Código Byte 1 Byte 2 Byte 3 Byte 4
0x1A - - - -
Tabela 20: Estrutura de mensagem para solicitar leitura de sensores Fonte: Autoria
Própria
3.3.2.3.1.9 Comando de resposta de leitura de sensores
Resposta que contém os valores dos sensores disponíveis no robô.
Código do comando: 0x1B
Tipos de parâmetros: Para cada byte será inserido o valor do sensor n do
robô.
Código Byte 1 Byte 2 ... Byte 96
0x1B Valor 1 Valor 2 ... Valor 96
Tabela 21: Estrutura de mensagem de resposta de leitura de sensores Fonte: Autoria
própria
3.3.2.3.1.10 Solicitar inclusão na rede
60
Este comando envia uma solicitação para inclusão do robô na rede,
cadastrando a unidade na estação-base.
Código do comando: 0x20
Tipos de parâmetros: este comando não possui parâmetros.
Código Byte 1 Byte 2 Byte 3 Byte 4
0x20 - - ... -
Tabela 22: Estrutura de mensagem para solicitação de cadastro na estação base Fonte:
Autoria própria
3.3.2.3.1.11 Comando de Confirmação de Inclusão na Rede
Este comando confirma que a solicitação de inclusão de um robô na rede foi
aceita e o robô agora está cadastrado na estação-base.
Código do comando: 0x21
Tipos de parâmetros: este comando não possui parâmetros.
Código Byte 1 Byte 2 Byte 3 Byte 4
0x21 --- --- --- ---
Tabela 23: Estrutura de mensagem para inclusão de um robô em uma estação central.
Fonte: Autoria Própria
3.3.2.3.1.12 Comando de Solicitar Confirmação de dispositivo ativo
Este comando solicita para uma unidade uma confirmação que a mesma
esteja operante.
Código do comando: 0x22
Tipos de parâmetros: este comando não possui parâmetros.
Código Byte 1 Byte 2 Byte 3 Byte 4
0x22 --- --- --- ---
61
Tabela 24: Estrutura de mensagem para confirmação de dispositivo ativo Fonte:
Autoria Própria
3.3.2.3.1.13 ACK
Este comando representa uma confirmação de mensagem bem sucedida.
Código do comando: 0x50
Tipos de parâmetros: este comando não possui parâmetros.
Código Byte 1 Byte 2 Byte 3 Byte 4
0x50 --- --- --- ---
Tabela 25: Estrutura de mensagem para um ACK Fonte: Autoria Própria
3.3.2.4 Tabela de comandos
Byte Função
0x20 Solicitação de cadastro
0x21 Confirmação de inclusão
0x22 Checar se dispositivo está online
0x50 ACK
0x1B Resposta de leitura dos sensores
0x1A Requisição de leitura dos sensores
0x60 Aciona o Driblador
0x61 Aciona o Chutador
0x26 Andar para frente
62
0x27 Andar para trás
0x28 Girar no sentido horário
0x29 Girar no sentido anti-horário
0x30 Comando Omnidirecional
Tabela 26: Tipos de comandos Fonte: Autoria própria
3.3.3 Digramas de comunicação
Para realizar a comunicação, foram utilizadas os seguintes diagramas como
base.
3.3.3.1 Transmissão
O envio de dados é feito de acordo com o digrama de máquinas de estado
que pode ser visto na Figura 21 Inicialmente quando é necessário enviar o pacote, o
programa passa pelo estado de preparar o frame para envido de mensagem, ver
3.3.2.2.2.1. Tendo o frame preparado, checa-se se o número de vezes que esse
pacote foi enviado é menor que o número de tentativas máximas – definido no
programa – caso essa condição seja falsa (foi enviado menos vezes que o número
de tentativas máximas), o pacote é enviado.
Depois que a mensagem for enviada o programa espera por uma confirmação
da mensagem, caso ela não receba essa confirmação até o tempo do timeout, a
transmissão é refeita caso não tenha ultrapassado o limite de tentativas. Caso esse
limite tenha sido transposto, no caso da estação-base, o usuário é alertado que
houve problemas de comunicação o robô, ver seção 47. Do ponto de vista do robô,
caso estoure o limite máximo de tentativas, ele descartará a mensagem.
64
3.3.3.2 Recepção
A parte da recepção da mensagem é feita de acordo com o seguinte
diagrama abaixo.
Figura 22: Diagrama de tratamento dos dados recebidos Fonte: (Kurpiel, et al. 2010)
(Modificado).
Quando uma mensagem é recebida, é feito uma verificação se esse pacote já
foi analisado. Caso esse pacote já tenha sido tratado a mensagem recebida é
descartada, caso não, a mensagem é verificada se o checksum está correto,
seguindo o caminho da mensagem correta, ou não, seguindo o caminho da
mensagem corrompida.
65
O fluxo de “mensagem já recebida” é para o caso de quando ocorre um
problema no envio de um ACK de alguma mensagem, e isso implicaria em uma
retransmissão do pacote. Ele seria executado novamente pelo destinatário caso não
houvesse o armazenamento do frameID dos últimos pacotes recebidos, esse fluxo
garante que uma mesma mensagem não seja executada mais de uma vez por
acidente.
3.3.4 Casos de comunicação
3.3.4.1 Iniciação do robô
Quando um robô é ligado, a mensagem de cadastro é enviada à sua
respectiva estação base como pode ser observado na Figura 24.
A estação base então responde com uma confirmação de cadastro. Caso
essa confirmação de castrado seja perdida, o cadastro é reiniciado.
Figura 23: Troca de mensagens entre estação-base e robô, visão geral Fonte: Autoria
Própria.
66
Figura 24: Diagrama de atividades para iniciação do robô visto pelo robô Fonte: Autoria
Própria
Figura 25: Diagrama exemplo de uma requisição da leitura dos níveis de bateria Fonte:
Autoria própria
67
3.3.4.2 Mensagem com requisição de resposta
Quando a estação faz uma requisição de leitura de sensores, no caso do
projeto apenas a leitura do nível da bateria, a estação base envia um comando com
tipo 0x1A – significando leitura de todos os sensores – e o robô envia a resposta
com o identificador 0x1B. Caso algum pacote seja perdido, o processo é reiniciado.
O processo pode ser visto no diagrama de atividades da Figura 26 e um exemplo do
processo em geral pode ser observado na Figura 25.
3.3.4.3 Mensagem de atuação do robô
Quando a estação base envia uma mensagem de atuação no robô, o modo
API do Xbee envia um ACK automaticamente, cuja condição pode ser checada
utilizando o TX Status (3.3.2.2.2.2). Na Figura 27: Diagrama de atividades do robô
para o recebimento de uma mensagem do tipo atuadora. Fonte: Autoria Própria
podemos ver o diagrama de atividades sobre o caso de uma mensagem de atuação
chegar ao robô.
Figura 26: Diagrama de atividades da resposta do robô em relação a mensagens de
requisição de leitura de sensores. Fonte: Autoria própria
68
Figura 27: Diagrama de atividades do robô para o recebimento de uma mensagem do
tipo atuadora. Fonte: Autoria Própria
Figura 28: Exemplo de envio de mensagem do tipo atuadora Fonte: Autoria própria
69
3.4 SISTEMA EMBARCADO
3.4.1 Software Embarcado
O software foi desenvolvido em blocos para tornar o desenvolvimento do
programa mais fácil. Esses blocos teriam que ser os mais independentes o possível
para tornar a fase de testes do programa mais simples e menos trabalhosa. Desse
modo é possível avançar a implementação do protocolo comunicação enquanto a
parte do controle ainda não está totalmente desenvolvida.
A parte de comunicação com fio foi incluída durante o desenvolvimento do
software para enviar parâmetros pela serial para a estação-base.
3.4.2 Webbotlib 1.31
A Webbotlib é uma biblioteca em C que auxilia o desenvolvimento de
sistemas embarcados para microcontroladores da ATMel que incluí: ATMega168,
Figura 29: Visão do software para testes em alto nível.
70
ATMega32, ATMega328P, ATMega640, ATMega644, ATMega1280, ATMega2560 e
ATMega2561.
Essa biblioteca tem a uma variedade de drivers prontos para serem utilizados,
dentre eles temos um gerenciador de envio/recebimento da UART, uma biblioteca
pronta para envio de palavras – strings – via UART, uma biblioteca de PID de fácil
acesso, um gerenciador de Timers simplificado, que torna o conhecimento específico
de cada microcontrolador menos necessário. Para projetos de microncontroladores
integrados (i.e. Axon) essa biblioteca renomeia os ports livres de maneira fácil e
intuitiva e os ports não disponíveis na placa são desabilitados para evitar o uso do
microcontrolador de maneira incorreta.
No projeto utilizamos a biblioteca de controle da UART, do PID, do PWM, dos
Timers, do envio de palavras via UART, e a biblioteca que renomeia o nome dos
pinos para os pinos disponíveis no Axon. Isso evitou um esforço na construção
dessas funções de baixo nível e possibilitou um foco maior no desenvolvimento de
nosso sistema.
3.4.3 Inicialização do programa
No início do programa é feito a inicialização dos módulos do firmware, a
comunicação com o XBee via UART2, inicialização dos módulos do PWM,
inicialização PID, configuração dos Timers e a definição de tarefas a serem
executadas (scheduler). A sequência de operação pode ser vista na Figura 30.
72
3.4.4 Funcionamento normal – visão geral
A partir do momento que todas as funções são inicializadas entra-se em
estado de funcionamento padrão, ou seja, no modo de receber mensagens, tratá-las
e executá-las.
O programa fica em espera por mensagens enquanto, a cada 200
milissegundos, entra no seu estado de controle – ver figura Figura 31 - que calcula
os novos níveis de PWM nos motores que serão utilizados no robô baseados na
última realimentação fornecida pelos opto-acopladores e no comando recebido pela
base.
Figura 31: Visão geral do firmware, uma abordagem de alto nível Fonte: Autoria própria
73
3.4.4.1 Controle
Foi implementado o controle PID (proporcional, integral e derivativo) no robô.
Esse controle possui algumas características bem definidas mostradas na tabela 3.
P – Correção proporcional ao erro A correção cresce na mesmo
proporção que cresce o erro da diferença
entre o valor real e valor desejado.
I – Correção proporcional ao produto
erro x tempo
Erros pequenos, mas que não foram
tratados há muito tempo requerem correção
mais intensa.
D – Correção proporcional a taxa de
variação do erro
Se o erro esta variando muito rápido
esta taxa de variação dever ser reduzida a
fim evitar oscilações.
Tabela 27: Controle PID básico. Fonte (Controle PID básico, UFSC s.d.).
O controle usa um sistema de malha fechada de realimentação, inicia-se com
a definição de um ponto objetivo – setPoint - esse objetivo é a velocidade alvo de
cada roda – em centímetros por segundo – e a realimentação é feita por meio dos
encoders, que são lidos a cada 200ms, que gera uma velocidade que é utilizada
para definir o ponto atual do PID. Esse modelo é interessante, permite a alteração
do setPoint enquanto o robô está em movimento sem que haja reinicio do PID.
74
3.4.4.2 Início da comunicação
Após o início do firmware é necessário que o robô entre em sincronia com sua
respectiva estação base. O programa inicia enviando uma mensagem para sua
estação base com o tipo 0x20 – mensagem do tipo de cadastro - que em um fluxo
em condições perfeitas, a base responderia imediatamente com uma mensagem
confirmando o cadastro com o ID 0x21, respostas do sistema para condições
adversas podem ser vista na Figura 33.
Figura 32: Diagrama de controle Fonte: Autoria própria
75
3.4.4.3 Tratamento de mensagens pós-sincronização com estação base
Após sincronização da do robô com a estação base, o robô entra no estado
de aguardar mensagens da estação base. Esse estado é demonstrado na Figura 34.
O exemplo da figura ilustra o fluxo caso a mensagem da estação base que chegar
for do tipo de movimento. Na Figura 35 é ilustrado a resposta do firmware para
solicitação de envio de mensagem com informações para estação base.
Figura 33: Diagrama que mostra o cadastro do firmware na visão do robô Fonte:
Autoria própria
76
Figura 34: Diagrama de resposta do firmware para o fluxo
de decodificação de uma mensagem de atuação nos motores
Fonte: Autoria Própria
77
Figura 35: Diagrama de resposta do firmware para o fluxo de
resposta a uma solicitação da estação base. Fonte: Autoria própria
78
3.4.4.4 Controle da rampa
O controle da rampa, para evitar derrapagem, é feito por meio de uma
verificação a cada 20ms que checa se a posição atual em relação a ponto de destino.
Se o ponto atual está a uma distância menor que 20% em relação ao ponto de
destino, o resultado do PID é reduzido em 2% do seu valor inicial (objetivo). A rampa
de subida é feita pelo próprio controlador quando inicia um movimento
Figura 36: Rampa de descida.
79
3.4.5 Componentes
3.4.5.1 Regulador de tensão 7805
Foram usados dois reguladores de tensão 7805 para alimentar alguns
componentes da PCI e o microcontrolador. Um dos reguladores foi usado para
alimentar o microcontrolador e os optoacopladores, para que seja possível caso
ocorra a necessidade de alimentar os diferentes circuitos com fontes diferentes.
Isolar o microcontrolador e os optoacopladores do restante do circuito a fim de evitar
os problemas de correntes transientes provocadas pelos motores DC que pode, por
exemplo, “resetar” o microcontrolador. O segundo regulador foi usado para alimentar
os demais circuitos eletrônicos que são: o DIP Switch de endereço, o nível lógico de
tensão das pontes-H, as chaves óticas e o Schmitt Trigger 74LS14.
O regulador foi projetado de acordo com a Figura 37, presente no datasheet
do componente. (Fairchild 2001)
Figura 37: Projeto do regulador 7805 presente no datasheet. Fonte: (Fairchild 2001)
Para verificar as ligações dos reguladores na PCI é necessário ver a Figura
50.
3.4.5.2 Regulador de tensão LM317
O regulador de tensão LM317 foi usado apenas para alimentar o Xbee em
nível lógico 3,3V já que ele pode ser usado como um regulador ajustável de tensão
de acordo com os resistores e mostrados na Figura 38 disponível no
80
datasheet. Para escolher esses resistores foi utilizada a equação ( 1 ) também
disponível no datasheet. (National Semicondutor, 1996)
Figura 38: Esquemático do LM317. Fonte: (National Semicondutor 1996).
( 1 )
O valor do resistor indicado pelo fabricante é de 240Ω. Como esse valor
não é um valor comercial foi utilizado dois resistores, um de 220Ω associado em
série com 22Ω, fornecendo um resistor de 242Ω. No circuito da PCI final esses
resistores receberam o nome de e respectivamente.
Tem-se que o valor típico de é de 100µA segundo o datasheet.
Substituindo por , por e por na equação ( 1 ), obtêm-se:
(2)
Isolando-se na equação (2), tem-se que . Para aproximar esse valor
a um valor comercial foram usados dois resistores associados em série de e
, o que equivale em uma resistência final de . Na PCI final foi dado o nome
de e para esses dois resistores respectivamente.
A disposição dos resistores e com o regulador LM317 e a disposição
dos mesmos na PCI podem ser vistas na Figura 50.
81
3.4.5.3 Xbee
Foi usado 5 pinos do Xbee no circuito da seguinte maneira:
O pino 1 foi usado para alimentar o Xbee com 3,3V proveniente do
regulador LM317 a partir o conector JP-3,3V. (ver Figura 41)
O pino 2 (UART Data Out) foi conectado em uma entrada do Schmitt
Trigger 74LS14 e como o mesmo é inversor, é necessário fazer o sinal
passar mais uma vez pelo mesmo componente para elevar a tensão
de 3,3V para 5V sem alterar sua natureza. A saída do componente foi
conectada no pino Rx da UART2 do microcontrolador. Essa foi a
solução escolhida, pois o componente já estava disposto na placa e
sobravam 3 pinos de I/O. O motivo de utilizar essa configuração e não
ligar diretamente o pino na UART2 do microcontrolador é pelo fato de
que a equipe já tinha conhecimento prévio de que alguns
microcontroladores Axon tinham problemas com o interfaceamento
direto com o Xbee.
O pino 3 (UART Data In) foi conectado na saída de um divisor de
tensão com resistor R25 e R31. A entrada do divisor de tensão foi
conectada no pino Tx da UART2 do microcontrolador. Essa
configuração foi usada a fim de diminuir o nível lógico de tensão de 5V
do pino Tx para 3,3V, que é o nível lógico de operação do Xbee. Como
, e supondo um valor de e seguindo o
esquema disposto na Figura 39, tem-se que:
( 3 )
( 4 )
Substituindo ( 3 ) em ( 4 ) com os valores de , , já definidos e
isolando-se tem-se que . Aproximando esse valor para um valor
comercial obtêm .
82
Figura 39: Divisor de tensão. Autoria própria.
O pino 6 foi ligado no LED1 que indica a potência do sinal e para
limitar a corrente nesse LED foi usado um resistor .
O pino 15 foi ligado no LED2 que indica uma recepção ou transmissão
de dados e para limitar a corrente nesse LED foi usado um resistor
.
O significado dos pinos é mostrado na Figura 40 e a disposição das ligações
do Xbee na PCI final é mostrada da Figura 41.
83
Figura 40: Pinos do Xbee. Fonte: (MaxStream USA).
Figura 41: Projeto de ligação do Xbee na PCI final. Fonte: Autoria própria.
84
3.4.5.4 DIP Switch 2 vias de 5 bits
O DIP Switch foi utilizá-lo como uma chave que está normalmente em nível
lógico alto ou nível lógico baixo, sendo assim utilizaram-se resistores de pull-up de
2200Ω. O máximo consumo de corrente ocorre quando o DIP está normalmente
fechado, o que equivale a uma dissipação de 11,36mW calculada através da
equação ( 5 ).
( 5 )
O DIP usado foi de 5 bits de vias. Desses 5 bits o bit 0 foi usado para escolher
para qual base o robô vai se comunicar, diferenciando o bit menos significativos do
endereço de 4 bytes do Xbee da base ao qual irá mandar e receber mensagens.
Seguindo esse conceito tem-se a possibilidade de escolher duas bases diferentes.
Os outros 4 bits restantes do DIP switch são usados como os 4 bits menos
significativos do endereço de 4 bytes do robô. Os demais bits são fixos. Com esses
4 bits consegue-se diferenciar 16 robôs. Sendo assim pode-se obter uma partida de
futebol com 16 robôs para cada time.
3.4.5.5 Encoders
São transdutores que converte movimentos seja ele linear ou angular em
sinais elétricos que carregam informações bem definidas. Nesse projeto chaves
ópticas são utilizados para determinar a rotação das rodas presente no robô. Dessa
forma quando usado em conjunto com o redutor do robô que consiste em uma
estrutura física de 32 “cortes” e uma chave ótica que altera o sinal do dispositivo
entre 0 e 1 (definidos pela tensão 0 e 5V, respectivamente), o que permite uma
precisão P de 11,25º através da equação ( 6 ).
( 6 )
Vale ressaltar que toda a estrutura dos encoders estava montada na estrutura
do robô. Havia apenas 3 terminais disponíveis para ligar na placa e para isso foi
necessário desmontar a estrutura para verificar cada um deles. O pino marrom
85
estava ligado no pino 2 e no pino 4, o terminal verde estava ligado no pino 3 e o
terminal azul estava ligado no pino 1. Para verificar esses pinos é preciso analisar a
Figura 42. Já para a ligação dessa chave ótica foi utilizado dois resistores de pull-up
ligados nos terminais verde (pino 3) e azul (pino 1) de 2,2KΩ e 440Ω,
respectivamente. Já o terminal marrom (pino 2 e pino 4) foi ligado na referência do
circuito.
A Figura 43 mostra o esquema de ligação da chave ótica na PCI.
Figura 42: Esquema da chave ótica H22A1. Fonte: (Fairchild 2001)
86
Figura 43: Esquema de ligação da chave ótica do encoder na PCI. Fonte: Autoria
própria
3.4.5.6 Schmitt Trigger 74LS14
O Schmitt Trigger atua da seguinte forma. Se o nível lógico de entrada está
acima do limiar (descrito no datasheet) a tensão de saída está em nível lógico alto,
mas se a tensão de entrada está abaixo de outro (também descrito no datasheet) a
tensão de saída fica em nível lógico baixo. Atuando dessa forma o Schmitt Trigger
evita oscilações do sinal mantendo ele em nível lógico alto ou baixo.
Sendo assim os seis Schmitt Triggers presentes no circuito integrado 74LS14
foram usados da seguinte maneira:
3 foram usados na saída das chaves óticas dos encoders.
2 foram usados na saída do pino 2 (UART Data Out) do Xbee.
O pino que restou foi inutilizado.
As ligações desse componente podem se vista na Figura 49.
87
3.4.5.7 Opto acopladores 4N35
O optoacoplador é um componente eletrônico baseado em um diodo emissor
de luz infravermelha e um fototransistor sensível a essa faixa de luz. A disposição
dos componentes dentro do encapsulamento é mostrada na Figura 44.
A função desse componente eletrônico nesse projeto é de isolar duas partes
distintas do circuito eletrônico, dessa forma ele evita que quaisquer perturbações ou
ruídos provenientes do motor sejam propagados para o microcontrolador através dos
pinos de controle.
O funcionamento desse componente na PCI é simples, quando há um nível
lógico alto (5V) atuando na entrada do optoacoplador, o diodo passa a emitir luz
infravermelha que incide diretamente na base do fototransistor, saturando o mesmo
e ocasionando um nível lógico baixo na saída. No caso de um nível lógico baixo
aplicado a entrada, o diodo para de emitir luz cortando o fototransistor e resultando
em nível lógico alto na saída do optoacoplador.
É necessário adicionar um resistor em série com o diodo de modo a limitar a
corrente sobre o mesmo. A corrente recomendada pelo datasheet é de 10mA. Para
calcular o resistor é utilizada a equação (7) obtendo-se um resistor de 500Ω e
aproximando-o para um resistor comercial obtém-se 560Ω.
( 7 )
Além desse resistor é necessário ligado no coletor do fototransistor atuando
como resistor de pull-up de 2,2KΩ. Como o optoacoplador tem por objetivo isolar
eletricamente duas partes do circuito, é necessário que se utilize duas fontes
distintas para alimentar a entrada e a saída do optoacoplador, de modo que não haja
nenhuma outra ligação entre os 2 circuitos, isolando-os completamente. Porém
foram utilizadas duas fontes ligadas em paralelo alimentando todo o circuito já que
não ocorreu nenhum problema no decorrer do projeto quando a isso, entretanto
como tal fato já foi previsto, foi disposto na PCI um conector (JP 7805-2) que
88
possibilita alimentar o microcontrolador e o optoacoplador de forma isolada do
restante do circuito. É importante analisar que o terminal entre o coletor e o resistor
de pull-up foi ligado nos pinos de controle das pontes-H.
Figura 44: Esquemático e pinos do Optoacoplador 4N35. Fonte: (Fairchild 2001)
Figura 45: Projeto dos optoacopladores na PCI. Fonte: Autoria própria.
89
3.4.5.8 Ponte-H L298
A ponte-H é o nome dado a o circuito eletrônico usado para fazer o
interfaceamento com motores DC nesse projeto. As aplicações que de motores
normalmente necessitam que eles rotacionem em dois sentidos, algo que pode ser
facilmente feito invertendo a polaridade dos cabos da alimentação dos motores. A
ponte-H é um circuito eletrônico que permite que essa troca de polaridade seja feita
sem desconectar nenhum cabo manualmente do motor. Alguns circuitos integrados
permitem que um microcontrolador possa comandar o sentido de rotação de um
motor DC apenas manipulando sinais lógicos presentes no mesmo. A ponte-H utiliza
4 transistores, que funcionam como chaves, dispostos em um formato similar a uma
letra “H”, daí o nome “ponte-H”, conforme mostrado na Figura 47.
O funcionamento dela requer que nunca dois transistores do mesmo lado
estejam saturados, pois isso ocasionaria um curto circuito na fonte. Quando dois
transistores diagonalmente opostos estão saturados e os outros 2 estão cortados
tem-se a rotação em um sentido. Quando os outros dois transistores diagonalmente
opostos estão saturados e os 2 primeiros voltam para o corte tem-se a rotação no
sentido oposto ao inicial.
O L298N já possui uma lógica interna que não permite que 2 transistores
adjacentes sejam ativados ao mesmo tempo causando o curto na fonte. O
funcionamento desse circuito integrado é baseado em 2 pinos de entrada (“In1” e
“In2” no caso da primeira ponte-H do CI L298 e “In3” e “In4” no caso da segunda
ponte-H) e um pino de enable “En” (EnA na primeira ponte-H e EnB da segunda
ponte-H). Os pinos de In1 e In2 controlam o sentido de rotação do motor conectado
aos pinos “Out1” e “Out2”, assim como o os pinos de In3 e In4 controlam o sentido
de rotação do motor conectado aos pinos “Out3” e “Out4” e o pino “En” habilita ou
não a Ponte-H como um todo.
O controle dos motores do robô foi feito por PWM através dos pinos de enable
das pontes-H e o controle de sentido de rotação através dos pinos input como já
descrito. Entretanto o datasheet indica que o a corrente de operação de cada uma
das pontes-H é de 2A, e para garantir tal fato foi usado as duas pontes-H do L298
90
em paralelo em cada motor da forma observada na Figura 46 presente no datasheet
do componente.
Figura 46: Esquema de ligação das duas pontes-H do L298. Fonte: (STMicroelectronics
2000)
91
Dessa maneira temos um controle de direção, pino “In1” e “In2” mutuamente
exclusivos, e um controle de velocidade, PWM no pino “En”, possibilitando que o
motor gire nos dois sentidos e com velocidade controlada pelo microcontrolador.
Figura 47: Ponte-H L298. Fonte: (STMicroelectronics 2000)
3.4.5.9 Bateria
O projeto utilizou duas baterias compostas por um banco de pilhas
recarregáveis, totalizando aproximadamente 16V em carga total cada uma delas.
Elas são ligadas em paralelo nos conectores JP-Bateria1 e JP-Bateria2 na PCI.
Como existe a possibilidade de usar fontes diferentes a fim de isolar, por
exemplo, o microcontrolador e os optoacopladores, do restante do circuito. Foram
colocados na PCI alguns pinos de forma que isso seja possível. Esses pinos são os
jumpers JP7805-2, JP7805-1, JP317 e os conectores JP-7805-2, JP-7805-1, JP-317
colocados na entrada dos reguladores que deseja-se alimentar separadamente. Os
diodos D13, D14 e D15 usados na entrada dos reguladores para evitar problemas
como o transiente de corrente e como proteção caso as baterias sejam ligadas em
polarização invertida na placa. Para verificar os conectores descritos no texto acima
basta ver a Figura 50.
92
3.4.6 Placa de circuito impressa
A placa de circuito impressa (PCI) foi construída em duas placas de forma a
acoplá-las. Na camada 1 estão presente os opto acopladores, Schmitt Trigger, chave
de endereço, Xbee e alguns resistores. Na camada 2 estão presentes as 3 pontes-H
e os 3 reguladores de tensão, assim como os diodos de proteção e alguns
capacitores.
Esse separação foi feita dessa forma a fim de melhor aproveitar o espaço
sobre o robô, uma vez que o robô tem limitações em suas dimensões. Ambas as
camadas da PCI foram feitas no software EAGLE (Easily Applicable Graphical
Layout Editor) versão 5.11.0 Professional Edition.
Todavia como se teve que fazer testes no robô em paralelo com a construção
da PCI final ocorreu a necessidade de montar uma PCI provisória com o mesmo
esquema da PCI final, porém em uma placa universal mostrada na Figura 48.
Figura 48: PCI provisória. Fonte: Autoria própria
3.4.6.1 Visão geral das conexões da Camada 1 da PCI
A camada 1 pode ser observada na Figura 49: Ligações da Camada 1 da PCI
final. Fonte: Autoria própria.. É possível observar os nove optoacopladores que
93
estão ligados em dois conectores, sendo que 9 dos 10 pinos do conector SV-IN-
OPTO são ligados diretamente no microcontrolador, o pino 10 não é ligado em nada,
apenas está presente por que esse conector é padrão. Já os pinos do conector SV-
OUT-OPTO são ligados na ponte-H da segunda camada no conector JP-PHS-IN,
onde os 3 primeiros pinos são de PWM e os outros 6 pinos são de INPUTS, sendo 1
PWM e 2 inputs para cada ponte-H. O Conector JP-5V-1 é o pino de alimentação de
5V proveniente da segunda camada pelo conector JP-7805-2-OUT para os encoders
e a chave IC1-CHAVE que possuí 5 resistores de pull-up, R26, R27, R28, R29, R30.
Os conectores JP-ENC1, JP-ENC2, JP-ENC3 são ligados nos 3 cabos dos encoders
do robô. Os 3 Schmitt Trigger's IC4A, IC4B, IC4C são usados nas saídas das chaves
ópticas presente nos encoders, sendo assim o conector JP-OUT-ENC é ligado ao
microcontrolador para leitura das bordas do chaveamento da chave-ótica. O
conector JP-3,3V é usado para a alimentação do Xbee proveniente do conector JP-
317-OUT da segunda camada. O conector JP23-UART é ligado na UART2 do
microcontrolador.
95
3.4.6.2 Visão geral das conexões da Camada 2 da PCI
A camada 2 pode ser observada na Figura 50. Os conectores JP-BATERIA1,
JP-BATERIA2 são pinos de alimentação das duas baterias presentes no robô e
ligadas em paralelo como visto na figura. JP317, JP7805-1, JP7805-2 funcionam
como jumpers para a alimentação com as duas baterias em paralelo (pinos JP-
BATERIA1, JP-BATERIA2), ou por alimentação de fontes diferentes em cada um
dos reguladores (pinos JP-317, JP-7805-1, JP-7805-2, são os pinos de alimentação
por fonte deferente caso os jumpers sejam retirados). O conector JP-317-OUT é
utilizado para alimentar o Xbee em 3,3V. O conector JP-7805-2-Axon é utilizado para
a alimentação na primeira camada do microcontrolador e dos optoacopladores já
descrito acima. Já o conector JP-78051-OUT é usado para alimentar os demais
circuitos integrados assim com a alimentação lógica das pontes-H. Os conectores
JP-MOTOR1, JP-MOTOR2, JP-MOTOR3 são conectados diretamente nos 3
motores DC. Os diodos desta placa são usados como proteção da indução elétrica
ocasionada quando há a inversão de rotação.
97
3.4.6.3 Esquemático das camadas enviado para a prototipação
O esquemático das camadas que foi enviado para a prototipação segue
mostrado nas Figura 54 e Figura 51. Esses esquemáticos foram criados
automaticamente após fazerem-se as ligações necessárias entre os componentes
no software EAGLE, porém a disposição dos componentes foi feita a “mão” assim
como grande parte das trilhas, as demais foram roteadas automaticamente. É
possível observar que há algumas trilhas da camada 2 com espessura maior já que
a corrente que fluirá nessas trilhas é relativamente maior que as demais. Após a
construção desses esquemáticos foi exportado arquivos em formato GERBER. Esse
formato é usado para a prototipação das PCIs e cada um deles possui um tipo de
informação como, por exemplo, mascara de solda, legenda, etc. Para a visualização
dos arquivos em formato GERBER foi utilizado o software ViewPlot. Nesse software
é possível analisar cada uma das camadas separadamente ou ainda sobrepor
quantas se desejar.
É possível observar como as placas vão ser sobrepostas na Figura 53.
Figura 51: Esquemático da camada 2 da PCI final enviada para prototipação. Fonte:
Autoria própria.
98
Figura 52: Camada 2 da PCI final antes de soldar. Fonte: Autoria própria.
Figura 53: Camadas 1 e camada 2 sobrepostas. Fonte: Autoria própria.
99
Figura 54: Esquemático da camada 1 da PCI final enviada para prototipação. Fonte:
Autoria própria.
Figura 55: Camada 1 da PCI final antes de soldar. Fonte: Autoria própria.
100
4 CONCLUSÕES
4.1 ANÁLISE DO DESENVOLVIMENTO
O desenvolvimento do projeto apresentou muitos problemas devido a
completa inexperiência da equipe no desenvolvimento de um projeto desse porte, no
entanto considera-se muito válida a experiência adquirida durante o processo, pois o
objetivo da disciplina de Oficina de Integração 3 é justamente proporcionar aos
alunos uma noção de como são todas as etapas do desenvolvimento de um projeto,
desde a especificação e planejamento, passando pelo gerenciamento do tempo e
dos recursos humanos e finalmente chegando à implementação das soluções
projetadas e teste do sistema final.
Durante a etapa de planejamento do projeto, foi feito uma análise de todos os
riscos aos quais o projeto estava sujeito, sendo também analisado a probabilidade
de ocorrência desses riscos e o impacto deles sobre o projeto. A seguir um breve
comentário sobre os riscos mais importantes.
4.1.1 Riscos Relevantes
A seguir será feita uma breve análise sobre os riscos previstos no plano de
projeto e quais deles realmente ocorreram no decorrer do desenvolvimento, bem
como o impacto para o artefato final.
4.1.1.1 Atraso no recebimento de componentes pelos fornecedores
Esse risco foi avaliado como sendo de impacto médio/alto e com
probabilidade média/baixa de acontecer, no entanto ele ocorreu. O microcontrolador
foi adquirido através de importação dos Estados Unidos, o que acarretou em um
atraso muito grande devido à restrições da alfândega brasileira, que demorou mais
de 40 dias para liberar a entrega do componente. O impacto desse risco foi
praticamente anulado através do empréstimo de um microcontrolador igual ao que
seria importado, de modo que a equipe pode fazer todo o desenvolvimento que
envolvia o microcontrolador com a unidade emprestada, sem prejuízo para o
cronograma do projeto.
101
4.1.1.2 Problemas com a comunicação sem fio
Desde a etapa de planejamento do projeto, sabia-se que a comunicação sem
fio era um ponto crítico do projeto, tanto pela dificuldade em implementar esse tipo
de comunicação quanto pelo papel fundamental do sistema de comunicação para o
funcionamento do sistema final. Devido a isso, na etapa de análise dos riscos, o
risco de ocorrer algum problema com a comunicação sem fio foi avaliado como
sendo de probabilidade média/alta e impacto alto. Durante o desenvolvimento do
projeto, o maior problema encontrado com a comunicação sem fio foi, sem dúvida o
fato de a equipe ter subestimado a complexidade do protocolo de comunicação
necessário para atender aos requisitos do sistema. Isso acabou resultando em um
gasto de tempo muito além do planejado para implementar a comunicação sem fio,
prejudicando o cronograma do projeto como um todo.
4.1.1.3 Custo real muito acima do custo estimado para o projeto
O custo final do projeto foi acima do custo planejado principalmente devido à
indisponibilidade de componentes críticos para o projeto no Brasil, como por
exemplo, os módulos Xbee e o microcontrolador Axon, de modo que foi necessário
importar esses componentes dos Estados Unidos. A importação acaba incorrendo
em elevados custos com frete e também no risco dos componentes importados
serem taxados pela alfândega brasileira, o que eleva o custo do componente em
60%, a atual alíquota de importação no Brasil.
4.1.1.4 Impossibilidade de algum membro da equipe terminar o projeto
O projeto foi inicialmente planejado para ser executado por uma equipe de 4
membros, no entanto no decorrer do desenvolvimento um dos membros não pode
continuar por falta de interesse. Esse fato havia sido previsto no plano de riscos do
projeto, como tendo uma probabilidade de acontecimento media/baixa e um impacto
médio/alto no projeto. O impacto desse risco para o desenvolvimento do projeto foi
sentido diretamente na carga de trabalho necessária dos membros restantes, pois foi
necessário dividir e absorver o trabalho do membro faltante.
102
4.1.1.5 Falta de tempo para conclusão do projeto
O cronograma inicial do projeto foi planejado para ser executado por 4
pessoas, no entanto boa parte do desenvolvimento foi feito com uma equipe de
somente 3 pessoas, o que acabou acarretando em atrasos no cronograma, aumento
da carga horária individual necessária para concluir o projeto e por fim falta de tempo
para concluir da maneira ideal todos os aspectos da execução e documentação do
projeto. Houve também problemas durante a etapa de planejamento do projeto no
sentido de subestimar o tempo necessário para desenvolver algumas etapas do
projeto, notadamente a comunicação sem fio como um todo. Essas tarefas
acabaram demandando mais tempo do que o planejado, pressionando o
cronograma como em direção a data de entrega e culminando na falta de tempo
para concluir o projeto de maneira adequada.
4.1.2 Considerações finais sobre o desenvolvimento
O desenvolvimento desse projeto proporcionou um ambiente de aprendizado
para todos os membros da equipe em diversos campos do conhecimento, até então
deficitários em nossa formação, como por exemplo, gerência de tempo, gerência de
recursos humanos, análise de riscos, planejamento de projetos, entre outros. Alguns
conhecimentos necessários ao projeto estavam sendo estudados de maneira
concorrente durante o semestre como, por exemplo, os conhecimentos de Controle
e Sistemas Microcontrolados, fato esse que ocasionou diversos problemas durante o
desenvolvimento, pois muitas vezes as decisões da equipe em relação ao projeto
tiveram que ser tomadas antes dos conteúdos necessários terem sido aprendidos.
Algumas dessas decisões foram equivocadas, resultando em um trabalho maior
necessário para corrigir esses problemas, trabalho esse que poderia ser evitado
caso essas disciplinas já tivessem sido cursadas anteriormente ao início do projeto.
4.2 INTEGRAÇÃO
O desenvolvimento desse projeto exigiu da equipe conhecimentos em
diversas outras disciplinas ministradas no curso de Engenharia de Computação,
sendo cada uma dessas disciplinas e sua aplicação no projeto detalhadas a seguir.
103
4.2.1 Controle
A disciplina de controle versa sobre como se pode controlar a saída de um
determinado sistema alterando sua entrada. Aplicado ao projeto em questão, os
conhecimentos de controle possibilitam que a velocidade com que o robô se
locomove seja controlada, independentemente de superfície ou de carga na bateria,
através da variação do PWM aplicado aos motores. Também é possível garantir que
o robô ande em linha reta e execute outros comandos com precisão, através de um
algoritmo de controle PID associado à realimentação do movimento das rodas,
provida por encoders presentes em cada roda.
4.2.2 Sistemas Microcontrolados
Em sistemas microcontrolados, aprendemos como estruturar o software do
sistema embarcado, bem como a utilização correta dos diversos periféricos de um
microcontrolador comum como, por exemplo, timers, interrupções, ports de entrada e
saída e UARTs(Universal Asynchronous Receiver/Transmitter). Estudamos também
como deve ser feito o interfaceamento com motores e outros dispositivos de
potência como, por exemplo, Pontes-H, esse conteúdo é de suma importância para
o desenvolvimento de projetos que envolvem robôs como esse. A comunicação
serial, padrão utilizado pelo Xbee, também foi um conteúdo crítico para o
desenvolvimento do projeto que foi estudado durante o desenvolvimento dessa
disciplina.
A disciplina de sistemas microcontrolados teve um papel fundamental para o
desenvolvimento do projeto, e avalia-se que se a disciplina já estivesse sido
concluída previamente em relação ao início do projeto, o aproveitamento e o
desempenho da equipe teria melhorias significativas.
4.2.3 Comunicação de dados
Os problemas relacionados a comunicação sem fio do projeto foram
solucionados com a ajuda dos conhecimentos aprendidos na disciplina de
comunicação de dados. Conceitos estudados como, por exemplo, acknowledge e
handshaking foram empregados no desenvolvimento do protocolo de comunicação,
104
de modo a garantir o nível de robustez e confiabilidade requerido na especificação
do projeto.
4.2.4 Eletrônica 2
A disciplina de eletrônica 2 foi especialmente importante no projeto dos filtros
analógicos, utilizados para filtrar ruídos indesejados na alimentação dos circuitos.
Essa disciplina também foi importante no dimensionamento e utilização dos
componentes de potência do circuito, notadamente as pontes-H que comandam os
motores.
4.2.5 Análise e projeto de sistemas e Engenharia de Software
Essas duas disciplinas tratam sobre metodologias de projeto de software,
buscando melhorar a qualidade e diminuir ao máximo o retrabalho necessário no
processo de desenvolvimento de software. Algumas dessas metodologias foram
aplicadas tanto no desenvolvimento do software da estação base como no firmware
do sistema embarcado, notadamente a elaboração de diversos diagramas que
descrevem o comportamento do sistema e a concordância com as melhores praticas
descritas pelo PMBOK(Project Management Body of Knowledge). Logicamente a
equipe teve dificuldades em aplicar todos os conceitos de engenharia de software e
gerência de projeto, pois eles envolvem uma grande componente de experiência
com projetos anteriores. Esse projeto foi o primeiro desse porte a ser desenvolvido
pela equipe com ênfase na gerência de projeto, fato esse que acabou apresentando
novos desafios à conclusão do projeto, de modo que sobreposto as preocupações
relativas à engenharia haviam também as preocupações relativas à gerência das
pessoas e distribuição igualitária da carga de trabalho.
4.3 TRABALHOS FUTUROS
Essa seção trata sobre os próximos passos a serem tomados no
desenvolvimento do projeto do ponto de vista da equipe. O objetivo é possibilitar que
uma outra equipe possa dar continuidade ao trabalho desenvolvido nesse projeto
105
com o mínimo de retrabalho possível, possibilitando a conclusão de objetivos cada
vez maiores.
4.3.1 Driblador e chutador
A adição de um driblador e um chutador ao projeto possibilitaria que os robôs
fossem utilizados em outra função que não a de goleiro. Os desafios envolvidos na
implementação dessas soluções são principalmente a adequação da parte mecânica
para receber esses novos componentes e a inserção de novos circuitos integrados
necessários na atual arquitetura, uma vez que as dimensões do robô são reduzidas.
Do ponto de vista da comunicação e do software, pequenos ajustes precisam ser
feitos para que essas novas funções sejam suportadas, pois ambos os sistemas já
foram desenvolvidos de modo a suportar expansões de capacidade.
4.3.2 Adição de sensores
A adição de diversos tipos de sensores poderia aprimorar alguns aspectos do
desempenho do robô. Por exemplo, uma bússola poderia contribuir para um controle
de rotações mais preciso e sensores de distância possibilitariam que o robô evitasse
colisões automaticamente. Outros tipos de sensores ainda poderiam ser adicionados
para o robô de modo que ele pudesse executar outra tarefa além de jogar futebol.
Os desafios ficam por conta de interfacear o sensor escolhido corretamente com o
microcontrolador e implementar a lógica responsável por enviar as leituras do sensor
para a estação base.
4.3.3 Microcontrolador
O microcontrolador utilizado no desenvolvimento do projeto, o Axon, atende a
todos os requisitos, no entanto sugere-se que uma equipe que venha a dar
continuidade ao projeto o substitua por um microcontrolador Axon II, pois ele
possibilita uma maior flexibilidade na adição de novos componentes e é totalmente
compatível com o firmware desenvolvido para o Axon.
106
4.3.4 Inteligência artificial
Uma inteligência artificial desenvolvida de modo a se comunicar com o
framework desenvolvido possibilitaria que o robô fosse utilizado para cumprir
diversas tarefas, entre elas participar de competições de futebol de robôs.
4.3.5 Comunicação
A comunicação pode ser melhorada em diversos aspectos, por exemplo, a
utilização de módulos Xbee com maior alcance e capacidade de transmissão.
Existem também pontos a ser melhorados no protocolo de comunicação, como por
exemplo detecção de força do sinal e tratamento de problemas diversos de
comunicação.
107
5 REFERÊNCIAS
" Lista de microcontroladores AVR." Digikey. n.d.
http://ca.digikey.com/1/4/indexe18.html.
"Arduíno Mega 2560." n.d. http://arduino.cc/en/Main/ArduinoBoardMega2560
(accessed Abril 30, 2011).
"ATMega328 28 pin DIP with Bootloader." n.d.
http://www.spikenzielabs.com/Catalog/index.php?main_page=index&manufact
urers_id=14 (accessed Abril 2011, 2011).
"Axon Microcontroller Description." Society of robots. n.d.
http://www.societyofrobots.com/axon/ (accessed Março 2, 2011).
"Controle PID básico, UFSC." DAS. n.d.
http://www.das.ufsc.br/~aarc/ensino/posgraduacao/DAS6613/PID_Novus.pdf
(accessed MAIO 2, 2011).
Digi International. Digi International. n.d. http://www.digi.com/.
Fairchild, semiconductor Corporation. Slotted optical switch H22A1. 2001.
Kurpiel, Francisco Delmar, Leandro Piekarski do Nascimento, Marcelo Massao
Kataoka Higaskino, and Ricardo Fantin da Costa. "Sistema de navegação do
robô omnidirecional." Curitiba, 2010.
MaxStream. Xbee/Xbee-PRO OEM RF Modules Manual. Lindon, UT, USA.
National Semicondutor. LM117/LM317A/LM317 3-Terminal Adjustable Regulator.
Março 1996.
NetBeans. Develop desktop, mobile and web applications with Java, PHP, C/C++
and more. Oracle Corporation, 2011.
108
Nishibe, Caio Arce, John Théo Sierpinski de Souza, Renato Girardi Gasoto, Thiago
Avelino da Silva, and Tui Alexandre Ono Baraniuk. "Desenvolvimento de
Sistema de Controle Sem Fio Para Robô Omnidirecional." Curitiba, 2010.
Software technologies, group. "How does ZigBee compare with other wireless
standards?" 2009. http://www.stg.com/wireless/ZigBee_comp.html.
STMicroelectronics. DUAL FULL-BRIDGE DRIVER. 2000.
Tavares, Fernando Perez. "RoboFEI." 2007.
109
6 ANEXOS
6.1 PLANEJAMENTO DE RISCO
Segue abaixo os planos para resposta ao risco.
Projeto: Robofut
1 Etapa:Identificação do Risco
Denominação do risco: Atraso no recebimento de componentes
pelos fornecedores.
N Identificação 01
Descrição do risco: Os componentes comprados podem sofrer atraso na entrega
por razões diversas.
2 Etapa:Avaliação do Risco
Impacto: 5(alto)4(média/alto)3(médio) 2(médio/baixo) 1(baixo) Explique: Sem os componentes solicitados, não é possível montar o artefato e realizar os
testes iniciais, atrasando todo o cronograma.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa)1 (baixa) Explique: A solicitação dos componentes aos fabricantes é feito com antecedência e folga
suficiente para comportar atrasos nas entregas.
3 Etapa:Desenvolvimento da Resposta ao Risco
AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO
Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Solicitar os componentes necessários aos fabricantes com antecedência suficiente para permitir atrasos nas entregas. Transferir: - Mitigar: Dedicar tempo maior na fase de montagem e testes do artefato para compensar o tempo perdido. Aceitar: -
Impacto reavaliado:3 Probabilidade reavaliada:2
Elaborado por: Ari Magagnin Junior,
Eduardo Cabral Resende Neiva, Fábio César
Schuartz, João Hamilton Cecato Simas
Data: 23/03/2011
Respostas incluídas na
WBS/Cronograma
Registros adicionais:
VERSO OU ANEXOS
Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille
110
1 Etapa:Identificação do Risco
Denominação do risco: Queima de componentes integrados com
longo prazo para aquisição.
N Identificação 02
Descriçãodo risco: Um componente essencial ao projeto pode queimar e o tempo
para sua reposição ser demorado.
2 Etapa:Avaliação do Risco
Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Não há como estender os prazos para a entrega do artefato, e o projeto ficará
paralisado sem os componentes para sua confecção.
Probabilidade: 5(alta) 4(média/alta) 3(média)2(média/baixa) 1 (baixa) Explique: Um componente pode queimar por diversas razões, desde o seu manuseio incorreto
até distrações durante sua soldagem.
3 Etapa:Desenvolvimento da Resposta ao Risco
AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO
Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: 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
Elaborado por: Ari Magagnin Junior,
Eduardo Cabral Resende Neiva, Fábio César
Schuartz, João Hamilton Cecato Simas
Data: 23/03/2011
Respostas incluídas na
WBS/Cronograma
Registros adicionais:
VERSO OU ANEXOS
Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille
111
1 Etapa:Identificação do Risco
Denominação do risco: Problemas com a comunicação sem fio.
N Identificação 04
Descrição do risco: Sem comunicação o robô não executará nenhum comando de
movimentação.
2 Etapa:Avaliação do Risco
Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Sem comunicação com o artefato, o mesmo não terá nenhuma funcionalidade
operante.
Probabilidade: 5(alta) 4(média/alta)3(média) 2(média/baixa) 1 (baixa) Explique: A comunicação sem fio é complexa e exige alto grau de conhecimento de
protocolos.
3 Etapa:Desenvolvimento da Resposta ao Risco
AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO
Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Estudar a fundo a tecnologia de transmissão sem fio e os protocolos necessários para a comunicação entre a base e o microcontrolador. Transferir: - Mitigar: Não havendo a comunicação sem fio conforme planejado, será necessário mudar a tecnologia de transmissão (Wi-Fi, RF, Bluetooth, etc). Aceitar: -
Impacto reavaliado: 5 Probabilidade reavaliada: 3
Elaborado por: Ari Magagnin Junior,
Eduardo Cabral Resende Neiva, Fábio César
Schuartz, João Hamilton Cecato Simas
Data: 23/03/2011
Respostas incluídas na
WBS/Cronograma
Registros adicionais:
VERSO OU ANEXOS
Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille
112
1 Etapa:Identificação do Risco
Denominação do risco: Falta de conhecimento suficiente para
completar o projeto, pelos membros da equipe.
N Identificação 05
Descrição do risco: Conhecimento insuficiente dos membros da equipe inviabilizará
terminar o projeto.
2 Etapa:Avaliação do Risco
Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Sem os conhecimentos necessários, o projeto não terminará e o artefato não poderá
ser construído.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa)1 (baixa) Explique: Os integrantes do grupo possuem uma base da tecnologia empregada e dos
conceitos envolvidos no projeto.
3 Etapa:Desenvolvimento da Resposta ao Risco
AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO
Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Procurar uma tecnologia que seja compatível com o nível de conhecimento para a construção do artefato, satisfazendo os requisitos e não superestimando os componentes (microcontrolador) a serem utilizados. Transferir: - Mitigar: Estender a carga de estudo em cima do projeto, procurar tecnologias mais simples, caso o grupo esteja no estágio inicial do projeto. Aceitar: -
Impacto reavaliado: 4 Probabilidade reavaliada: 2
Elaborado por: Ari Magagnin Junior,
Eduardo Cabral Resende Neiva, Fábio César
Schuartz, João Hamilton Cecato Simas
Data: 23/03/2011
Respostas incluídas na
WBS/Cronograma
Registros adicionais:
VERSO OU ANEXOS
Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille
113
1 Etapa:Identificação do Risco
Denominação do risco: Falta de tempo para a conclusão do
projeto.
N Identificação 06
Descrição do risco: Tempo não pode ser adquirido, portanto o prazo final não pode
ser estendido.
2 Etapa:Avaliação do Risco
Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Caso o tempo disponível não seja suficiente, o artefato não poderá ser completado,
invalidando todo o projeto.
Probabilidade: 5(alta) 4(média/alta) 3(média)2(média/baixa) 1 (baixa) Explique: è feito uma avaliação e planejamento prévios, mas imprevistos podem ocorrer
durante o tempo estimado para cada tarefa.
3 Etapa:Desenvolvimento da Resposta ao Risco
AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO
Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Durante o planejamento, estimar os prazos para cada tarefa e considerar folgas entre as mesmas, para que se algo imprevisto aconteça permita a equipe corrigir os problemas atrasados. Transferir: - Mitigar: Diminuir o escopo do trabalho e reduzir os requisitos finais do artefato. Aceitar: -
Impacto reavaliado: 5 Probabilidade reavaliada: 4
Elaborado por: Ari Magagnin Junior,
Eduardo Cabral Resende Neiva, Fábio César
Schuartz, João Hamilton Cecato Simas
Data: 23/03/2011
Respostas incluídas na
WBS/Cronograma
Registros adicionais:
VERSO OU ANEXOS
Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille
114
1 Etapa:Identificação do Risco
Denominação do risco: Problemas de saúde de membros da
equipe.
N Identificação 07
Descrição do risco: Um membro da equipe pode sofrer algum acidente ou ficar
doente.
2 Etapa:Avaliação do Risco
Impacto: 5(alto)4(média/alto) 3(médio)2(médio/baixo) 1(baixo) Explique: Caso algum membro da equipe fique doente, isso atrasará algum módulo do
projeto, podendo (ou não) atrasar o início de outras etapas, acumulando o atraso.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa) Explique: Resfriados e gripes são as formas mais comuns de doenças que podem ocorrer.
Outras doenças tem possibilidade de ocorrer baixa.
3 Etapa:Desenvolvimento da Resposta ao Risco
AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO
Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Cuidar da saúde, não se expor a fatores de risco à saúde desnecessariamente, agasalhar-se bem são algumas formas de prevenção de doenças. Transferir: - Mitigar: Procurar um médico ou especialista o quanto antes a fim que cura-se rapidamente e ter condições para prosseguir o trabalho. Caso seja um curto período de algum dos membros da equipe com algum tipo de problema de saúde, os demais membros compensam o tempo e esforço do colega ausente temporariamente. Aceitar: -
Impacto reavaliado: 3 Probabilidade reavaliada: 1
Elaborado por: Ari Magagnin Junior,
Eduardo Cabral Resende Neiva, Fábio César
Schuartz, João Hamilton Cecato Simas
Data: 23/03/2011
Respostas incluídas na
WBS/Cronograma
Registros adicionais:
VERSO OU ANEXOS
Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille
115
1 Etapa:Identificação do Risco
Denominação do risco: Custo real muito acima do custo
estimado, inviabilizando o término do projeto.
N Identificação 8
Descrição do risco: O custo dos materiais pode se tornar muito acima do previsto,
inviabilizando o projeto.
2 Etapa:Avaliação do Risco
Impacto: 5(alto)4(média/alto)3(médio) 2(médio/baixo) 1(baixo) Explique: Caso o custo do projeto seja muito alto, não haverá possibilidade de completar o
artefato.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa) Explique: Utilizar-se-á de componentes individuais com custo reduzido ao invés de circuitos
pré-montados.
3 Etapa:Desenvolvimento da Resposta ao Risco
AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO
Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Fazer um estudo detalhado dos componentes existentes no mercado, quais se adequam ao projeto e que sejam de baixo custo. Escolher componentes que não são superestimados. Transferir: - Mitigar: Reduzir as funcionalidades do artefato, procurar soluções alternativas em componentes mais baratos que possam realizar parte das especificações. Aceitar: -
Impacto reavaliado: 3 Probabilidade reavaliada: 2
Elaborado por: Ari Magagnin Junior,
Eduardo Cabral Resende Neiva, Fábio César
Schuartz, João Hamilton Cecato Simas
Data: 23/03/2011
Respostas incluídas na
WBS/Cronograma
Registros adicionais:
VERSO OU ANEXOS
Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille
116
1 Etapa:Identificação do Risco
Denominação do risco: Desistência de algum membro da equipe.
N Identificação 9
Descrição do risco: Um dos integrantes do grupo desiste do projeto e/ou da disciplina.
2 Etapa:Avaliação do Risco
Impacto: 5(alto)4(média/alto)3(médio) 2(médio/baixo) 1(baixo) Explique: Caso um membro da equipe desista da disciplina, os demais integrantes podem não
conseguir terminar o projeto dentro do tempo previsto.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
Explique: Os integrantes do grupo estão motivados a construírem o artefato.
3 Etapa:Desenvolvimento da Resposta ao Risco
AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO
Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Conversar semanalmente com cada integrante do grupo, definir metas alcançáveis, motivar os integrantes e manter a moral do grupo alta. Transferir: - Mitigar: Redistribuir o restante das tarefas entre os demais membros do grupo, absorvendo o impacto da melhor maneira possível. Aceitar: -
Impacto reavaliado: 4 Probabilidade reavaliada: 4
Elaborado por: Ari Magagnin Junior,
Eduardo Cabral Resende Neiva, Fábio César
Schuartz, João Hamilton Cecato Simas
Data: 23/03/2011
Respostas incluídas na
WBS/Cronograma
Registros adicionais:
VERSO OU ANEXOS
Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille
117
1 Etapa:Identificação do Risco
Denominação do risco: Perda ou roubo do artefato.
N Identificação 10
Descrição do risco: O artefato pode ser roubado ou perdido.
2 Etapa:Avaliação do Risco
Impacto: 5(alto)4(média/alto) 3(médio) 2(médio/baixo) 1(baixo) Explique: Sem o artefato não será possível concluir o projeto.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa) Explique: O artefato estará sempre no alcance de algum integrante da equipe.
3 Etapa:Desenvolvimento da Resposta ao Risco
AÇÕES, RESPONSÁVEIS E DATAS DE CONCLUSÃO
Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade): Prevenir: Sempre manter o artefato no campo de visão dos integrantes da equipe, verificar sempre duas vezes a posse do artefato antes de deixar um laboratório, nunca deixar o artefato sozinho por motivo algum. Transferir: - Mitigar: Procurar o quanto antes o local onde fora deixado o objeto e buscar informações para tentar encontra-lo a mais rápido possível. Aceitar: -
Impacto reavaliado: 5 Probabilidade reavaliada: 1
Elaborado por: Ari Magagnin Junior,
Eduardo Cabral Resende Neiva, Fábio César
Schuartz, João Hamilton Cecato Simas
Data: 23/03/2011
Respostas incluídas na
WBS/Cronograma
Registros adicionais:
VERSO OU ANEXOS
Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille