Robo Hexapode Controlado Por Fpga

UNVERSDADE TECNOLGCA FEDERAL DO PARAN
DEPARTAMENTO ACADMCO DE ELETRNCA

DEPARTAMENTO ACADMCO DE NFORMTCA
CURSO DE ENGENHARA DE COMPUTAO
FELPE MCHELS FONTOURA
LEANDRO PEKARSK DO NASCMENTO
LUCAS LONGEN GOPPO
ROB HEXPODE CONTROLADO POR FPGA
TRABALHO DE CONCLUSO DE CURSO
CURTBA
2013
LUCAS LONGEN GOPPO
Trabalho de Concluso do Curso de graduao,
apresentado disciplina de Trabalho de
Concluso de Curso do Curso Superior em
Engenharia de Computao dos Departamentos
Acadmicos de Eletrnica e nformtica da
Universidade Tecnolgica Federal do Paran,
apresentado como requisito parcial para
obteno do ttulo de Engenheiro de
Computao.
Orientador: Prof. Dr. Carlos Raimundo Erig Lima
CURTBA
2013
LUCAS LONGEN GOPPO
Este trabalho de concluso de curso foi julgado e aprovado como requisito parcial para
obteno do ttulo de Engenheiro de Computao pela Universidade Tecnolgica Federal
do Paran.
Curitiba, 14 de maio de 2013.
_______________________________
Prof. Dr. Hugo Vieira Neto
Coordenador de Curso
Departamento Acadmico de Eletrnica
_______________________________
Prof. Dr. Dario Eduardo Amaral Dergint
Responsvel pela Disciplina de Trabalho de Concluso de Curso
Departamento Acadmico de Eletrnica
BANCA EXAMINADORA
_______________________________
Prof. Dr. Carlos Raimundo Erig Lima
Orientador
_______________________________
Prof. Dr. Douglas Paulo Bertrand Renaux
_______________________________
Prof. Dr. Dario Eduardo Amaral Dergint
Lets start with the three fundamental Rules of Robotics.... We have:
one, a robot may not injure a human being, or, through inaction, allow a
human being to come to harm. Two, a robot must obey the orders given
it by human beings excet where such orders would conflict with the
!irst Law. "nd three, a robot must rotect its own existence as long as
such rotection does not conflict with the !irst or #econd Laws.
(ASMOV, saac, 1942)
Vamos comear com as trs Leis Fundamentais da Robtica... ns
temos: um, Um rob no pode causar dano a um ser humano nem, por
omisso, permitir que um ser humano seja ferido. Dois, um rob deve
obedecer s ordens dadas por seres humanos, exceto quando essas
ordens entrarem em conflito com a Primeira Lei. E trs, um rob deve
proteger sua prpria existncia, desde que essa proteo no entre em
conflito com a Primeira nem com a Segunda Lei. (ASMOV, saac, 1942)
RESUMO
FONTOURA, Felipe Michels; GOPPO, Lucas Longen; DO NASCMENTO, Leandro
Piekarski. Rob Hexpode Con!o"#do po! FPGA$ 2013. Monografia (Graduao)
Curso de Engenharia de Computao, UTFPR, Curitiba, Brasil.
Robs hexpodes so comumente utilizados como ferramenta de estudo de
robtica, logo de interesse acadmico a elaborao de um rob hexpode com
especificao aberta. O objetivo geral do projeto descrito desenvolver um rob
hexpode controlado por uma FPGA, recebendo comandos de um computador. O
desenvolvimento segue o processo de desenvolvimento em espiral, em trs etapas:
projeto, construo e testes. Foram necessrios diversos estudos para sua concretizao,
especialmente o da cinemtica inversa. O projeto constitui-se de seis partes: mecnica do
rob, eletrnica dos motores, hardware de controle rob, firmware, driver de comunicao
e software de interface grfica. A estrutura mecnica a MSR-H01, desenvolvida pela
Micromagic Systems, com trs motores por pata. Utilizaram-se seis motores Corona
DS329MG nos ombros, e doze BMS-620MG nas demais articulaes, todos alimentados
por uma fonte ATX (140W em regime na linha de 5V), isolada do restante do hardware por
acoplamento tico. O hardware de controle do rob engloba a FPGA e seus perifricos: os
optoacopladores dos motores, o magnetmetro (HMC5883), o acelermetro (ADXL345) e
o mdulo XBee. A FPGA gera os sinais de controle para os motores e para os demais
dispositivos e embarca um processador NOS , com arquitetura RSC de 32 bits de at
250 DMPS. O firmware, desenvolvido em linguagem C++, responsvel pela leitura dos
sensores, por enviar sinais de controle para os motores e por comunicar-se com o driver,
desenvolvido em Java, atravs do mdulo XBee. O software de interface grfica permite
ao usurio enviar comandos de movimentao para o rob atravs do driver e apresenta
leituras dos sensores. O resultado final foi um rob capaz de movimentar-se usando
cinemtica e diversas tecnologias acopladas. Tecnologicamente, o projeto se destaca pela
extensibilidade, pois a FPGA permite reprogramao do hardware e o software modular.
Socioeconmicamente, a flexibilidade do rob permite utilizao em atividades de ensino
e pesquisa. Alm disso, sua documentao e sua especificao so abertas, de forma
que possvel replic-lo sem grande esforo.
P#"#%!#&'()#%e* Rob Hexpode. Servomotor. Lgica Reconfigurvel. Orientado a
objetos. Desenvolvimento em Espiral.
ABSTRACT
FONTOURA, Felipe Michels; GOPPO, Lucas Longen; DO NASCMENTO, Leandro
Piekarski. Rob Hexpode Con!o"#do po! FPGA +Hex#pod Robo Con!o""ed b,
FPGA-$ 2013. Monograph (Undergraduate) Computer Engineering Course, UTFPR,
Curitiba, Brazil.
Hexapod robots are commonly used as platform for studies on robotics, hence it is
of academic interest to develop such kind of robot with open specifications. The main goal
ot this project is the development of a hexapod robot controlled by FPGA, receiving high-
level commands from a computer. The development follows a spiral model in three stages:
project, development and tests. Many studies were necessary in order to make the project
possible, especially those regarding inverse kinematics. The project itself is divided in six
parts: robot mechanics, motor electronics, robot control hardware, firmware, driver and
user interface software. The robot is based on a MSR-H01 mechanical structure
developed by Micromagic Systems which requires three motors per leg. There are six
Corona DS329MG motors on the shoulders, and twelve BMS-620MG on other joints, all
supplied by an ATX power source (140W at 5V) and optically isolated from remaining
hardware. The robot control hardware includes the FPGA and its peripherals such as
optocouplers, magnetometer (HMC5883), accelerometer (ADXL345) and the XBee device.
The FPGA generates the control signals for the servos and other devices while embedding
a NOS processor with 32-bit RSC architecture, capable of performances up to 250
DMPS. The firmware was developed in C++ and is responsible for reading the sensors,
sending control signals to the servos and connecting to the driver, developed in Java,
through the XBee channel. The user interface software allows the user to send commands
to the robot through the driver and displays readings from the sensors. The result was a
robot capable of moving using a combination of inverse kinematics and other technologies.
Technologically, the project has the quality of being extensible, as the FPGA allows
hardware reprogramming and the software is split into individual modules.
Socioeconomically, the flexibility of the robot allows using it for both teaching and
research. t is also remarkable that its specification is open and so more robots like this
one can be made with little effort.
.e,/o!d&* Hexapod Robot. Servomotor, Reconfigurable Logic. Object-Oriented. Spiral
Method.
LISTA DE FIGURAS
Figura 1: Diagrama de blocos simplificado do projeto. .......................................................17
Figura 2: Diagrama de blocos do projeto.............................................................................26
Figura 3: "The Different Parts of an FPGA".........................................................................27
Figura 4: Kit DE0-Nano........................................................................................................28
Figura 5: Arquitetura macro do NOS ...............................................................................29
Figura 6: Mdulo XBee S1...................................................................................................30
Figura 7: MSR-H01 Hexapod Kit.........................................................................................32
Figura 8: Servo BMS-620MG...............................................................................................33
Figura 9: Servo Corona DS329MG......................................................................................34
Figura 10: Exemplo de sistemas de coordenadas em robs..............................................36
Figura 11: Transformao de um vetor posio P do sistema A para o sistema B, usando
matriz de transformao......................................................................................................36
Figura 12: Conveno de numerao das patas.................................................................38
Figura 13: Esquemas de movimentao.............................................................................39
Figura 14: Diagrama do sistema de controle do servomotor prprio..................................40
Figura 15: "Sample 2C mplementation."............................................................................41
Figura 16: "2C Communication Protocol"...........................................................................41
Figura 17: Diagrama de blocos do hardware embarcado e perifricos..............................48
Figura 18: Opes de processador Nios disponveis no SOPC..........................................49
Figura 19: Configuraes da controladora SDRAM, pgina 1............................................50
Figura 20: Configuraes da controladora SDRAM, pgina 2............................................51
Figura 21: Configurao da PLL da SDRAM.......................................................................51
Figura 22: Configurao da UART.......................................................................................52
Figura 23: Sistema SOPC completo....................................................................................53
Figura 24: Geometria de uma pata em detalhe...................................................................54
Figura 25: Screenshot durante simulao de trajetria.......................................................55
Figura 26: Bloco de clculo da cinemtica inversa.............................................................56
Figura 27: Bloco de converso ngulo largura de pulso..................................................57
Figura 28: Sinal PWM..........................................................................................................58
Figura 29: Bloco gerador de sinal PWM..............................................................................58
Figura 30: Bloco gerenciador de sinais...............................................................................59
Figura 31: "nternal structure 2C Master Core"...................................................................60
Figura 32: Servo desmontado..............................................................................................63
Figura 33: Configuraes de LM555...................................................................................64
Figura 34: Esquemtico do circuito da PC da FPGA.........................................................66
Figura 35: Pinos de /O da FPGA (GPO-0 e GPO-1)........................................................67
Figura 36: Pinos da MU......................................................................................................68
Figura 37: Pinos do Mdulo XBee.......................................................................................70
Figura 38: Diagrama da PC da FPGA................................................................................71
Figura 39: PC da FPGA com todos os componentes soldados.........................................71
Figura 40: PC da FPGA ligada com o Xbee, a FPGA e a MU...........................................72
Figura 41: Esquemtico do circuito da PC dos servos.......................................................73
Figura 42: Diagrama da PC dos servos..............................................................................75
Figura 43: PC dos servos sem os componentes soldados................................................76
Figura 44: Verso final da PC dos servos parafusada ao hexpode.................................76
Figura 45: Conector Molex de 20 pinos...............................................................................77
Figura 46: Peas do MSR-H01 com alguns servos encaixados.........................................81
Figura 47: Kit MSR-H01 montado com todos os servos encaixados..................................82
Figura 48: Hexpode com as PCs e com a FPGA mas sem a PC superior ter sido
soldada.................................................................................................................................83
Figura 49: Circuito com as resistncias geradas pelo "cordo umbilical"...........................84
Figura 50: Hexpode completo............................................................................................85
Figura 51: Formato de uma mensagem do protocolo de baixo nvel..................................87
Figura 52: Formato geral de mensagens do protocolo entre o rob e o driver...................89
Figura 53: Formato da mensagem de definir movimento para o rob................................90
Figura 54: Formato da mensagem de ler sensor para o rob.............................................90
Figura 55: Formato da mensagem de movimento terminado com sucesso.......................90
Figura 56: Formato da mensagem de movimento abortado...............................................90
Figura 57: Formato da mensagem de enumerar portas do cliente.....................................91
Figura 58: Formato da mensagem de abrir porta do cliente...............................................92
Figura 59: Formato da mensagem de movimentar do cliente.............................................92
Figura 60: Formato da mensagem de ler sensor do cliente................................................92
Figura 61: Formato da mensagem de movimento terminado com sucesso.......................93
Figura 62: Formato da mensagem de movimento abortado...............................................93
Figura 63: Diagrama de casos de uso.................................................................................94
Figura 64: Diagrama de classes de baixo nvel...................................................................99
Figura 65: Diagrama de classes de protocolo...................................................................101
Figura 66: Diagrama de classes do firmware....................................................................102
Figura 67: Statechart do firmware.....................................................................................103
Figura 68: Diagrama de classes do driver.........................................................................105
Figura 69: Statechart do driver...........................................................................................106
Figura 70: Diagrama de classes da biblioteca de cliente..................................................107
Figura 71: Statechart da biblioteca de cliente...................................................................108
Figura 72: Tela inicial do software de interface grfica......................................................109
Figura 73: Tela de conexo com rob do software de interface grfica............................109
Figura 74: Tela de execuo de movimentos e leitura de sensores do software de interface
grfica.................................................................................................................................110
Figura 75: Tela de movimento em andamento...................................................................111
Figura 76: Diagrama de Gantt do cronograma preliminar.................................................128
LISTA DE TABELAS
Tabela 1: Preos de componentes......................................................................................25
Tabela 2: Comparao entre servos HS-645MG e BMS-620MG........................................33
Tabela 3: Comparao entre servos HS-225MG e Corona DS329MG...............................33
Tabela 4: Configurao dos pinos do conector BOARD-C0................................................67
Tabela 5: Configurao dos pinos do conector BOARD-C1................................................68
Tabela 6: Configurao dos pinos da MU...........................................................................69
Tabela 7: Configurao dos pinos do Mdulo XBee na PC...............................................70
Tabela 8: Configurao dos pinos da Fonte ATX utilizados na PC dos Servomotores......74
Tabela 9: Pinos de sada do conector de 20 pinos da fonte ATX........................................79
Tabela 10: Tabela de gastos do projeto.............................................................................126
Tabela 11: Tabela resumida de atividades do projeto........................................................130
LISTA DE SIGLAS
AC Alternating Current (Corrente Alternada)
CA Corrente Alternada
CC Corrente Contnua
C Circuito ntegrado
CPU Central Processing Unit (Unidade Central de Processamento)
DC Direct Current (Corrente Contnua)
FPGA Field-programmable Gate Array
GU Graphical User nterface (nterface Grfica com o Usurio)
/O nput/Output (Entrada/Sada)
OO Orientao a Objetos
PC Placa de Circuito mpresso
RAM Random Access Memory
ROM Read-only Memory
RTOS Real-time Operating System (Sistema Operacional de Tempo Real)
SUMRIO
1 ntroduo.........................................................................................................................15
1.1 Motivao e justificativa.............................................................................................16
1.2 Objetivos e escopo....................................................................................................16
1.2.1 Objetivo geral.....................................................................................................16
1.2.2 Objetivos especficos.........................................................................................16
1.3 Requisitos do sistema................................................................................................18
1.3.1.1 Requisitos funcionais..................................................................................18
1.3.1.2 Requisitos no-funcionais...........................................................................18
1.4 Metodologia...............................................................................................................19
1.4.1 Fundamentos......................................................................................................19
1.4.2 Tecnologias.........................................................................................................19
1.5 Estrutura do trabalho.................................................................................................20
1.5.1 Hardware............................................................................................................20
1.5.2 Software.............................................................................................................21
2 Estudos.............................................................................................................................23
2.1 Produtos similares.....................................................................................................23
2.2 Viabilidade.................................................................................................................24
2.2.1 Viabilidade financeira.........................................................................................24
2.2.2 Viabilidade tcnica..............................................................................................25
2.3 Dispositivos................................................................................................................25
2.3.1 Diagrama de Blocos...........................................................................................25
2.3.2 FPGA Kit DE0-Nano........................................................................................26
2.3.3 Processador embarcado Nios ......................................................................28
2.3.4 RTOS MicroC (C/OS-).................................................................................29
2.3.5 ZigBee Xbee S1..............................................................................................30
2.3.6 Acelermetro ADXL345...................................................................................31
2.3.7 Magnetmetro HMC5883................................................................................31
2.3.8 Estrutura mecnica MSR-H01........................................................................31
2.3.9 Servomotores BMS-620MG & Corona DS329MG..........................................32
2.3.10 Fonte de alimentao dos servos Fonte ATX 450W.....................................34
2.3.11 Estao Base....................................................................................................35
2.4 Parte terica...............................................................................................................35
2.4.1 Cinemtica inversa.............................................................................................35
2.4.2 "Gait...................................................................................................................37
2.4.3 Desenvolvimento de um servomotor prprio.....................................................39
2.4.4 2C......................................................................................................................41
2.4.5 Alocao dinmica, alocao esttica e object pooling.....................................42
2.4.6 Garbage collection e reference counting...........................................................43
2.5 Convenes de programao...................................................................................44
2.5.1 Regras de nomeao.........................................................................................45
2.5.2 Regras de codificao........................................................................................46
2.5.3 Regras de estilo..................................................................................................46
2.6 Consideraes...........................................................................................................47
3 Desenvolvimento...............................................................................................................48
3.1 Hardware na FPGA...................................................................................................48
3.1.1 NOS Microcontrolador Embarcado................................................................48
3.1.2 Cinemtica inversa.............................................................................................53
3.1.3 Conversor entre ngulo e largura de pulso........................................................57
3.1.4 Gerador de sinal PWM.......................................................................................57
3.1.5 Gerenciador de sinais para os servomotores....................................................58
3.1.6 Comunicao 2C...............................................................................................60
3.1.6.1 Software de interfaceamento......................................................................61
3.2 Hardware externo......................................................................................................62
3.2.1 Desenvolvimento dos servomotores prprios....................................................62
3.2.2 Placas de Circuito mpresso...............................................................................65
3.2.2.1 PC da FPGA..............................................................................................65
3.2.2.2 PC dos Servos...........................................................................................72
3.2.3 Fonte de alimentao.........................................................................................77
3.3 Montagem do hexpode............................................................................................80
3.4 Protocolos de comunicao......................................................................................85
3.4.1 Protocolo de baixo nvel.....................................................................................86
3.4.1.1 Mensagens..................................................................................................86
3.4.1.2 Controle de fluxo.........................................................................................87
3.4.2 Protocolos de alto nvel......................................................................................88
3.4.2.1 Protocolo entre rob e driver......................................................................89
3.4.2.2 Protocolo entre cliente e driver...................................................................91
3.5 Software.....................................................................................................................93
3.5.1 Projeto de software de interface grfica.............................................................93
3.5.1.1 Requisitos funcionais..................................................................................93
3.5.1.2 Requisitos no-funcionais...........................................................................94
3.5.1.3 Casos de uso..............................................................................................94
3.5.1.3.1 Enviar comandos ao rob....................................................................94
3.5.1.3.2 Obter leituras dos sensores.................................................................96
3.5.2 Detalhes da implementao em C++.................................................................97
3.5.2.1 Alocao de memria..................................................................................97
3.5.2.2 Gerncia de memria..................................................................................97
3.5.3 Cdigo de baixo nvel.........................................................................................98
3.5.4 Cdigo de alto nvel..........................................................................................100
3.5.4.1 Protocolo...................................................................................................100
3.5.4.2 Firmware...................................................................................................101
3.5.4.3 Driver.........................................................................................................104
3.5.4.4 Cliente.......................................................................................................107
3.5.4.5 nterface grfica........................................................................................108
3.6 Movimentos..............................................................................................................111
3.6.1 Movimentos bsicos.........................................................................................112
3.6.2 Movimentos com magnetmetro......................................................................113
3.6.3 Movimentos demonstrativos.............................................................................115
3.7 Consideraes.........................................................................................................116
4 Plano de testes................................................................................................................119
4.1 Caso de teste : Conexo com o driver...................................................................119
4.2 .Caso de teste : Conexo com o rob...................................................................119
4.3 Caso de teste : Posio de repouso do rob.......................................................120
4.4 .Caso de teste V: Movimentao do rob..............................................................120
4.5 Caso de teste V: Leitura de sensores do rob........................................................121
4.6 Consideraes.........................................................................................................121
5 Gesto.............................................................................................................................122
5.1 Escopo.....................................................................................................................122
5.2 Custos e Cronograma..............................................................................................124
5.3 Anlise de Riscos....................................................................................................131
5.4 Consideraes.........................................................................................................133
6 Trabalhos futuros............................................................................................................134
7 Consideraes finais.......................................................................................................136
Apndice A: Movimentos suportados pelo rob................................................................147
Apndice B: Sensores suportados pelo rob....................................................................148
Apndice C: Mensagens do protocolo entre rob e driver................................................149
Apndice D: Mensagens do protocolo entre cliente e driver.............................................151
Apndice E: Tabela completa de atividades realizadas....................................................153
Apndice F: Riscos identificados.......................................................................................156
Captulo 1 ntroduo 15
0 In!od123o
A roda est indubitavelmente entre as invenes mais brilhantes do ser humano.
H um vasto repertrio de artefatos mveis que se utilizam de rodas para realizar seus
objetivos de deslocamento, como o caso de diversos tipo de robs. H desde robs
mais simples, com duas rodas, at os omnidirecionais, como os utilizados em
competies de futebol de robs
1
. Apesar de amplamente utilizados, eles compartilham de
dificuldades de locomoo em superfcies que no sejam lisas ou pouco rugosas
2
. Como
eles no funcionam bem em certos ambientes, h um incentivo para elaborar robs que
utilizem outro meio de locomoo, como patas por exemplo. Tais robs poderiam ser
utilizados para acesso a lugares inspitos, como um territrio devastado por terremoto ou
afetado por radiao
3
.
uma tendncia atual que o movimento de robs com patas (que so, em sua
maioria, bpedes, quadrpedes e hexpodes) seja biologicamente inspirado, isto ,
baseado no movimento de seres vivos
2
, em especial insetos. H tambm robs que tm
seu modelo em outros tipos de animais, como o rob BigDog, desenvolvido pela empresa
Boston Dynamics, que tem por base o movimento de ces
4
.
O problema mais estudado no que diz respeito a robs "multipodes consiste em
determinar a melhor sequncia de levantar, deslocar e baixar as patas que resulte em
uma locomoo mais rpida ou com menor gasto de energia. Existem tambm estudos
que buscam determinar qual o melhor formato corporal desses robs, confrontando
corpos hexagonais e retangulares
5
. Para descrever e coordenar o modo de andar e de se
locomover de robs hexpodes, vrias estratgias podem ser adotadas, entre elas
sistemas no-lineares
6
e algoritmos genticos
7
. H ainda trabalhos bastante completos
sobre o desenvolvimento de hexpodes controlados por cabos. Tais trabalhos so
completos ao ponto de descrever propriedades dinmicas e de performance
8
.
No ano de 1949 j existia a ideia de robs hexpodes, mas apenas em torno do
ano de 1997 foi possvel realizar esses robs em termos de custos computacionais
9
. Os
hexpodes so os robs paralelos mais utilizados da indstria, principalmente para
simulao de movimentos (ex: simuladores de voo). De poucos anos para c h inteno
de utiliz-los em linhas de montagem de aeronaves devido a preciso que possuem
10
.
1.1 Motivao e justificativa
Uma motivao para o projeto a elaborao de um rob com documentao
totalmente aberta, de forma que possa ser utilizado futuramente como plataforma de
estudo de robtica ou mesmo como base para um hexpode comercial. Alm disso, todos
os integrantes da equipe j tem experincia prvia com robs que fazem uso de rodas e
tem interesse em estudar um tipo diferente de estrutura mecnica, de eletrnica e
sobretudo de forma de locomoo.
H ainda o interesse de estudar e implementar um projeto utilizando uma
plataforma de hardware completamente distinta das utilizadas anteriormente pelos
integrantes, mais especificamente uma FPGA (field$rogrammable gate array). A principal
ideia, neste sentido, explorar as capacidades da lgica reconfigurvel, utilizando
recursos que um microcontrolador comum no possui.
1.2 Objetivos e escopo
0$4$0 Ob5e6%o 7e!#"
O objetivo geral do projeto o desenvolvimento e a montagem de um rob
hexpode. Tal rob deve ser controlado por um dispositivo de lgica reconfigurvel, e ser
capaz de receber comandos a partir de algum dispositivo externo. Dentro do possvel a
arquitetura do rob deve ser extensvel, no sentido de permitir a adio de novos recursos
e/ou funcionalidades sem necessidade de alterar significativamente o design de software
e hardware. dealmente, deve ser possvel adicionar funcionalidades de hardware sem
alterar (ou alterando minimamente) a forma que os dispositivos j presentes no rob esto
conectados FPGA. De forma semelhante, o software existente deve requerer pouca ou
nenhuma alterao para incluir novas funcionalidades.
0$4$4 Ob5e6%o& e&pe(896(o&
O projeto envolve diversas reas da engenharia de computao, sendo
efetivamente uma aplicao da maioria dos conhecimentos adquiridos durante o curso. O
objetivo primrio do projeto , portanto, a aprendizagem e aplicao das tcnicas
necessrias para a confeco do rob.
O rob deve comunicar-se com uma estao-base atravs de comunicao
wireless. Ele deve locomover-se ao receber comandos vindos de um driver na estao-
base. O software de interface com o usurio deve comunicar-se com este driver utilizando
uma biblioteca orientada a objetos a ser desenvolvida. O rob deve ao menos ser capaz
de andar em uma direo em particular, saber em que direo est orientado, e girar sua
estrutura para uma certa direo. Na figura 1 apresentado um diagrama de blocos
simplificado do sistema.
wireless
rob
estao-base
estao remota
!igura %: &iagrama de blocos simlificado do rojeto.
!onte: "utoria r'ria
Uma vez efetivado, o projeto poderia ser estendido para mais funcionalidades e ter
outras aplicaes. Portanto um dos objetivos criar um projeto que de alguma forma seja
expansvel futuramente podendo ser integrveis outros dispositivos como garras,
sensores trmicos, cmeras, microfones, dentre outros. Este um dos incentivos para o
uso de uma FPGA pois com ela possvel ampliar o hardware de maneira mais fcil.
Na FPGA, h uma grande quantidade de conectores livres, e possvel alterar o
circuito digital que ela implementa, adicionando novos blocos. Portanto, para adicionar
novos dispositivos, no deve ser necessrio alterar os que j esto conectados ao rob. O
nico elemento de hardware que requer grande mudana neste caso a placa de circuito
impresso.
tido como objetivo tambm explorar os limites do hardware disponvel. Certos
movimentos do rob podem ser inspirados nos de algum animal, como, por exemplo, uma
aranha ou uma formiga.
1.3 Requisitos do sistema
1.3.1.1 Requisitos funcionais
RF1 . O rob deve manter suas patas em uma posio estvel enquanto no estiver
em movimento.
RF2 . O rob deve ser capaz de movimentar suas patas.
RF3 . O rob deve ser capaz de se comunicar com um software de driver na estao
base.
RF4 . O rob deve movimentar-se apenas quando receber comandos de
movimentao a partir do driver.
RF5 . O rob deve abortar o movimento em andamento quando receber comandos de
parada a partir do driver.
RF6 . O rob deve enviar para o driver as leituras de seus sensores quando receber
comandos de leitura de sensor a partir do driver.
RF7 . O driver de comunicao com o rob deve receber conexes de uma biblioteca
de comunicao.
RF8 . A biblioteca de comunicao deve permitir a comunicao com o driver.
RF9 . O software de interface com o usurio deve conectar-se ao driver usando a
biblioteca de comunicao.
1.3.1.2 Requisitos no-funcion#6&
RNF1. O hardware do rob deve ser realizado em um dispositivo de lgica
reconfigurvel.
RNF2. O rob deve ter seis patas.
RNF3. O rob deve ter sensores.
RNF4. O rob deve ter trs motores por pata.
RNF5. O rob deve ser alimentado por cabo.
RNF6. A comunicao entre o rob e a estao base com o driver deve ser sem fio
(wireless).
RNF7. A comunicao entre o driver e a biblioteca de comunicao deve ocorrer por
soc(ets TCP.
0$: Meodo"o76#
0$:$0 F1nd#;eno&
O projeto do rob hexpode envolve, entre outros, a aplicao de conhecimentos
na rea de controle, que so aplicado para movimentao das patas, lgica
reconfigurvel, para toda a integrao das partes e controle de cada parte do rob, e
sistemas embarcados, para a elaborao do sistema embarcado. Alm dessas reas,
espera-se que haja uma quantidade razovel de modelagem matemtica para a
movimentao do rob, especialmente para o movimento das patas. O projeto do circuito
do rob ainda explora conhecimento de linguagens de modelagem de circuitos,
conhecimento de circuitos digitais e analgicos, conhecimento de filtros, processamento
digital de sinais e arquitetura de computadores.
No projeto do software so utilizados conhecimentos de fundamentos de
programao (para a programao do sistema de maneira geral), estrutura de dados
(para organizao dos dados recebidos) e comunicao de dados (para que seja
realizada uma comunicao confivel entre a estao base e o rob). Tambm sero
abordados conceitos de anlise e projetos de sistemas e engenharia de software para
realizar a documentao, planejamento e organizao do software.
0$:$4 Te(no"o76#&
As principais tecnologias que devero ser utilizadas no projeto so: FPGA,
servomotores, meios de comunicao wireless, linguagem C++ e linguagem Java.
Para fazer o controle do rob foi utilizada uma FPGA que coordena os
servomotores e realiza leitura dos sensores. O firmware na FPGA ainda comunica-se com
um software na estao base, no caso um computador.
Os servomotores sero utilizados para controlar o movimento de cada articulao
das pernas do hexpode. Cada perna dever possuir trs servomotores para que ele
possa realizar movimentos diversos, com trs graus de liberdade. Entre os movimentos
possveis encontram-se: deslocamento horizontal das patas para que ele possa se
locomover para frente, deslocamento vertical da perna para que seja possvel ergu-la e
um terceiro para deslocamento angular, para rotacionar a perna em torno do joelho. Essa
terceira articulao funciona como uma espcie de joelho, capaz de movimentos mais
complexos como deslocamentos laterais.
Para que no seja necessria a utilizao de um cabo conectando a FPGA ao
computador, foi utilizado ZigBee, uma tecnologia de rdio frequncia
11
. O ZigBee funciona
de forma similar a um cabo serial, se utilizado no modo transparente.
Na estao base h um driver de comunicao que envia comandos ao rob. O
driver de baixo nvel capaz de comunicar-se com uma biblioteca, que serve de interface
entre o driver e o software de interface grfica. O driver, a biblioteca de comunicao e o
software de interface grfica foram desenvolvidos em linguagem Java, em ambiente
Eclipse
12
.
Para a modelagem dos "circuitos de controle que devero ser carregados na FPGA
ser utilizada a linguagem de construo de circuitos VHDL. A ferramenta escolhida para
elaborao do cdigo VHDL foi o software Quartus .
0$< E&!11!# do !#b#")o
O projeto a ser desenvolvido, como lida com robtica, envolver ferramentas e
recursos de hardware e software. Essa seo fornece uma descrio preliminar das
ferramentas e recursos a serem utilizados.
0$<$0 H#!d/#!e
Para o desenvolvimento das pernas do hexpode, foram usados servomotores,
como comum em robs desse tipo. Cada pata do rob possui trs motores, permitindo
uma maior mobilidade, este um nmero bastante utilizado em robs similares
5
. Dentro
do possvel, evitou-se fazer peas sob medida, priorizando o uso de peas disponveis
comercialmente, com o objetivo de reduzir os custos. Considerou-se anteriormente a
possibilidade de construir os prprios servomotores a partir de motores DC simples, para
obter maior preciso com menor custo. Essa ltima ideia foi abandonada no estgio inicial
do projeto, como descrito na seo de desenvolvimento, devido ao fato de demandar
muito tempo sem diminuir significativamente o custo ou aumentar consideravelmente a
preciso dos motores.
O controle de cada pata, bem como do rob como um todo, foi construdo em uma
FPGA , que um dispositivo de lgica reprogramvel. A opo por uma FPGA em lugar
de um microcontrolador se deve sua capacidade de lidar com vrios dispositivos
interagindo em paralelo
13
, como acontece em um rob hexpode.
Duas placas de circuito impresso foram desenvolvidas para fazer toda a conexo
de potncia e alimentao do rob. Elas so responsveis tanto por distribuir a energia do
rob, quanto por organizar outros dispositivos perifricos como acelermetro, giroscpio e
motores.
O grupo optou por utilizar um kit de desenvolvimento DE0-Nano, produzido pela
Terasic, que utiliza uma FPGA Cyclone V 4C22
14
da Altera. Sua escolha devido as
pequenas dimenses e por ele possuir algumas funcionalidades muito teis para o
projeto: um acelermetro com 13 bits de preciso, 66 pinos genricos de /O, conexo
USB, dentre outras.
Originalmente, imaginava-se que o rob poderia receber alimentao de uma
bateria, de forma a poder deslocar-se com maior liberdade do que alimentado por cabo.
Chegou-se concluso que seria invivel alimentar o rob por bateria (maior preo, maior
peso, menor vida til), portanto foi utilizado um cabo de alimentao.
Para a comunicao com a estao base, de onde o rob receber instrues, foi
utilizado um dispositivo ZigBee. A opo pelo ZigBee em lugar de outros meios deve-se
relativa simplicidade de uso, a seu preo relativamente baixo e pela qualidade da
tecnologia
11
. Funciona bem para as distncias de comunicao desejadas para o projeto
(at 10 metros de distncia) e tratada de forma similar a um dispositivo de interface
serial.
O computador da estao base, com o driver de comunicao, deve ter, ao menos,
uma porta USB, sistema operacional Windows XP (ou superior), mouse, teclado e
monitor. Para o desenvolvimento computadores com especificao semelhante devem ser
utilizados, preferencialmente com capacidades de processamento suficientes para o uso
das ferramentas de software citadas a seguir.
0$<$4 So9/#!e
O rob deve receber comandos de um driver na estao base, o qual foi
desenvolvido em linguagem Java. Originalmente a linguagem utilizada para seu
desenvolvimento seria C++, mas esta ideia foi abandonada ao longo do projeto devido
maior facilidade de desenvolver, manter e testar cdigo em uma linguagem que apresente
gerenciamento automtico de memria. A linguagem Java um exemplo de linguagem
com tal caracterstica
15
, com a qual os membros da equipe j tm prtica. A biblioteca de
comunicao com o rob e a interface grfica tambm so feitas em linguagem Java, de
forma que h aproveitamento de parte do cdigo do driver e menos linhas de
desenvolvimento paralelas no projeto. Para que haja comunicao ZigBee deve haver
uma forma de receber/enviar comandos tanto no PC como no sistema embarcado, ou
seja, um protocolo nico implementado em duas linguagens distintas, em plataformas
distintas.
Para o desenvolvimento do sistema de lgica reconfigurvel foi utilizado o software
proprietrio Quartus 12.0
16
. Esta opo se deve experincia de todos os membros da
equipe na utilizao desse software e ao fato da FPGA utilizada ser da empresa Altera.
Para o desenvolvimento do software embarcado, do driver, da biblioteca e do
software de interface grfica foi utilizada a DE Eclipse
12
. Tal escolha se deve
experincia que os membros da equipe tm com esta ferramenta e tambm por ser
gratuita e extensvel, permitindo programao em mais de uma linguagem.
Na elaborao das PCs foi utilizado o software Eagle
17
. Esse software em
particular foi escolhido dada a experincia de um dos membros da equipe com o mesmo.
Todos os recursos software a serem utilizados nesse trabalho j foram previamente
utilizados inmeras vezes em outras oportunidades durante o curso de Engenharia de
Computao. Portanto, os membros da equipe j possuem uma certa experincia com
todos eles.
Captulo 2 Estudos 23
4 E&1do&
2.1 Produtos similares
Existe uma ampla variedade de robs hexpodes, sejam de projetos acadmicos
ou comerciais, os quais diferem tanto em caracterstica mecnicas quanto eletrnicas.
Pesquisaram-se alguns robs hexpodes de destaque, cujas caractersticas so
apresentadas a seguir.
O rob hexpode mais barato encontrado o Stiquito, desenvolvido originalmente
por Jonathan Mills, da universidade de ndiana (Estados Unidos da Amrica). O Stiquito
diferente da maioria dos robs hexpodes por no utilizar motores, mas sim nitinol, uma
liga metlica capaz de contrair-se e dilatar-se, de forma semelhante a um msculo. Ele
tambm no conta com qualquer sistema microcontrolado, sendo normalmente controlado
pela porta paralela do computador. Suas aplicaes so geralmente educativas, devido
sua simplicidade: ele tem apenas um grau de liberdade (mas possvel comprar um kit
para adicionar mais um grau de liberdade). Na loja oficial, um Stiquito pode ser comprado
por US$ 22, ou US$ 24 para compradores internacionais (dados de 22 de janeiro de
2013), mais o preo do frete e impostos
18
.
Outro rob de destaque o RHex. Foi desenvolvido originalmente como um projeto
multidisciplinar patrocinado pela DARPA (Defense Advanced Research Projects Agency,
"Agncia de Projetos de Pesquisa Avanada em Defesa", agncia do governo dos
Estados Unidos da Amrica). O rob construdo com motores Maxon RE118751 (motor
de corrente contnua com escovas), cujo controle feito por software (controle PD digital,
amostrado a 1 kHz), usando um processador ntel 486
19
. O Rhex capaz de andar em
terrenos bastante acidentados, tem uma estrutura mecnica prova d'gua, pode ser
controlado distncia de at 700 metros e apresenta cmeras e faris na parte frontal e
na parte traseira
20
.
A empresa LynxMotion produz solues comerciais completas de robs hexpodes,
incluindo chassis, motores, eletrnica e at software de exemplo. H diversos modelos de
robs disponveis, a saber: AH3-R, BH3-R, CH3-R, A-Pod, T-Hex, Phoenix, BH3, AH3,
MH2, MAH3-R. Os robs podem acompanhar dois tipos de placas de microcontroladores,
a BotBoard , que utiliza controladores Basic Atom ou Basic Atom Pro de 24 ou 28 pinos,
ou a BotBoarduino, que semelhante a um Arduino Duemilanove. Dependendo do
modelo do rob, so utilizados servos HS-422, HS-475, HS-485, HS-645 e/ou HS-755. O
controle dos servos realizado com auxlio de um controlador SSC-32, que, entre outras
funcionalidades, ajuda a suavizar os movimentos. Os preos dos robs, na loja oficial,
variam entre US$ 459,43 e US$ 1337,00, mais frete e impostos (dados de 18 de janeiro
de 2013)
21
.
Outro rob hexpode comercial o Hexy. Ele um rob de baixo custo, com
estrutura mecnica de acrlico e servomotores Tower Pro SG92R (sem engrenagens
metlicas). O microcontrolador utilizado um Servotor32, baseado no Arduino Leonardo,
e o rob acompanha um software que permite a programao dos seus movimentos
utilizando arquivos de texto. O preo de um kit de montagem do Hexy, na loja oficial, de
US$ 250,00, mais frete e impostos (dados de 22 de janeiro de 2013)
22
.
H ainda o rob que inspirou o projeto descrito neste documento, o "Rob
Hexpode Orientado para Aplicaes Pedaggicas. Tal rob tem uma estrutura mecnica
personalizada, desenvolvida sob medida, feita de alumnio e utiliza servo-motores da
marca TowerPro de torque 10,5 kgf. Na descrio do projeto em questo, no foi
informado seu preo
23
.
2.2 iabilidade
4$4$0 =6#b6"6d#de 96n#n(e6!#
O controle de uma perna robtica foi realizado como projeto final dos trs
integrantes da equipe na disciplina de Lgica Reconfigurvel, no primeiro semestre de
2011. O sistema projetado foi utilizado como ponto de partida, do rob hexpode.
O projeto teve como custos principais a compra da FPGA, dos servomotores, da
estrutura mecnica, das PCs e dos mdulos ZigBee. Alm disso, foi comprado um
adaptador USB-serial para usar e configurar os mdulos ZigBee no PC. A estimativa de
gasto com somente essas peas, que constituem a maior parte dos gastos, pode ser vista
na tabela 1.
Tabela %: )re*os de comonentes.
!onte: "utoria r'ria.
>1#n6d#de M#e!6#" P!e2o po! 1n6d#de
?
1 FPGA DE0-Nano R$: 380,00
1 Mdulo Xbee-Pro ZB R$ 170,00
1
Placa CON-USBBEE Rogercom com
mdulo Xbee-Pro ZB
R$ 270,00
9 Driver de motor L298N R$ 9,00
36 Optointerruptor PHCT103 R$ 3,00
18 Motor D/C simples ou servomotor
??
USS$ 6,00 = R$ 25,00
1 PC personalizada R$ 250,00
1 Mecnica do rob R$ 250,00
1 Bateria Li-Pol 14.8V 3Ah (potncia) R$ 152,00
1
Bateria Li-Pol 11.1V 1.5Ah (eletrnica de
controle)
R$ 110,00
1 Bssola HMC6352 USS$ 35,00 = R$ 54,60
24
1 Troca de peas danificadas 20% total = R$ 403,28
To#" R$: 2000,00 = R$2450,00
4$4$4 =6#b6"6d#de @(n6(#
Os membros da equipe j tem prtica em programao em linguagens Java e C++,
em elaborao de circuitos em VHDL, em uso de interfaces de comunicao UART, em
uso de tecnologia ZigBee e em uso de motores
11,25
. Os maiores riscos do trabalho
encontraram-se na falta de experincia de toda a equipe em questes mecnicas e de
eletrnica de potncia.
2.3 !ispositivos
4$A$0 D6#7!#;# de B"o(o&
Na figura 2, apresenta-se o diagrama de blocos do sistema de hardware idealizado.
Basicamente, representa-se o sistema embarcado, com as PCs, os 18 servos, a estrutura
* desconsiderando custos de importao, impostos e frete.
** caso sejam comprados servomotores no sero utilizados optointerruptores
mecnica e a FPGA, o driver da estao base, cuja conexo se d por conexo wireless
usando mdulos ZigBee e a biblioteca de cliente ligada a um software de interface grfica.
O software de interface grfica comunica-se com o driver atravs da biblioteca de cliente
utilizando soc(ets.
driver
biblioteca
embarcado
x18
mecnica
servos
sensores
ZigBee
software de interface grfica
s
o
c
k
e
t
s
PC (x2)
FPGA
fonte ATX
fonte DC
!igura +: &iagrama de blocos do rojeto.
4$A$4 FPGA B .6 DEC'N#no
A FPGA um dispositivo semicondutor que pode ser programado depois de
fabricado
26
. Graas a essa capacidade, de maneira geral, qualquer circuito que pode ser
construdo por funes lgicas implementvel em uma FPGA. Atualmente os kits
incluem tambm vrios outros dispositivos como memrias RAM/Flash e transceivers de
alta velocidade.
A FPGA oferece paralelismo real, ou seja, possui sees do hardware destinadas
especificamente a cada finalidade sendo executadas de forma independentes
27
. Dessa
forma, no h competio entre diversas tarefas por recursos compartilhados de
hardware. Sem mencionar os perifricos de um kit, o chip da FPGA composto por trs
unidades bsicas, indicadas na figura 3. As interconexes programveis so utilizadas
para implementar um circuito digital composto de blocos lgicos, que se comunicam com
dispositivos externos atravs de blocos de /O.
!igura ,: -The &ifferent )arts of an !)."-.
!onte: /htt:00www.ni.com0cms0images0dev1one0tut0swvvifh23343%.jg5
A escolha por uma FPGA como unidade central se fez pelo paralelismo exigido pelo
projeto. Por exemplo, so controlados 18 motores simultaneamente e feita a
leitura/interpretao de sensores e comunicao com a estao base. O kit escolhido
para ser utilizado o DE0-Nano
14
, projetado e produzido pela empresa Terasic e que faz
uso do chip FPGA Cyclone V, da Altera. Os fatores que levaram a escolha desse kit foram
o tamanho compacto, bastante adequado a um rob; o modelo de FPGA com nmero
suficiente de elementos lgicos; o acelermetro e ADC includos no kit e a grande
quantidade de pinos de /O. A familiaridade com o software Quartus
16
tambm pendeu a
favor da escolha de um kit que fizesse uso de tecnologia da Altera. A figura 4 mostra o kit
utilizado. Fica evidente a pequena dimenso do mesmo.
!igura 6: 7it &89$:ano.
!onte: /htt:00www.altera.com0education0univ0images0boards0de9;nano.jg5
4$A$A P!o(e&&#do! e;b#!(#do B N6o& II
Um sistema NOS um microcontrolador embarcado, pois possui um
processador, conjunto de perifricos e memria todos no mesmo chip. Nesse sistema est
includo um dos 3 possveis cores NOS (economy, standard ou fast), perifricos
selecionados de uma vasta gama de opes (que inclui, por exemplo, comunicao serial,
processamento de sinais e interfaces como memrias de diferentes tipos, alm de possuir
um set de instruo prprio). O processador em si possui arquitetura RSC com word de
32 bits, instrues de ponto flutuante, entre outras capacidades. Pode ser programado
utilizando o NOS SBT, baseado em Eclipse, nas linguagens C ou C++. O desempenho
elevado e pode chegar a 250 DMPS
28
.
A grande vantagem do NOS ser um processador softcore (embarcado). Sua
arquitetura disponibilizada pela Altera e ele pode ser montado de inmeras maneiras
dentro do prprio design da FPGA, completamente integrado ao resto do circuito
desenvolvido. Na figura 5 possvel ter uma viso macro do processador e suas
caractersticas. Vale ressaltar a possibilidade de debug via JTAG, que facilita e muito o
desenvolvimento.
!igura 3: "r2uitetura macro do :<=# <<.
!onte: /htt:00www.altera.com0devices0rocessor0nios+0images0nios$ii$features.gif5
4$A$: RTOS B M6(!oC +DCEOS'II-
Um RTOS ("real$time oerating system, sistema operacional de tempo real) um
tipo de sistema operacional especializado em operaes de tempo real. A principal
caracterstica de um RTOS seu determinismo, ou seja, a previsibilidade de durao das
tarefas que so executadas. Apesar de esta ser a caracterstica determinante, tambm
desejvel que seja eficiente e tenha pequeno footprint, tanto em termos de memria de
programa quanto em termos de RAM
29
. Sistemas deste tipo so bastante utilizados em
aplicaes embarcadas, como o caso do rob hexpode.
O RTOS utilizado o C/OS-, da empresa Micrium. A empresa caracteriza o
C/OS- como "real$time deterministic multitas(ing (ernel for microrocessors,
microcontrollers and &#)s (kernel de tempo real determinstico multi-tarefa para
microprocessadores, microcontroladores e processadores digitais de sinais)
30
. O
desenvolvimento do sistema operacional foi feito completamente em ANS-C e inclui muito
do que se pode esperar de um RTOS, como semforos, flags de eventos, filas,
gerenciamento de tarefas e tempo.
A existncia de temlates prontos para iniciar o desenvolvimento de firmware com
C/OS- na DE de programao do Nios
31
pesou bastante a favor no momento da
escolha de RTOS. A DE utilizada para programao do firmware uma verso
modificada do Eclipse.
4$A$< F67Bee B Xbee S0
A tecnologia ZigBee descrita como a "internet das coisas, segundo a ZigBee
Alliance. ZigBee combina baixo custo, baixo consumo de energia e capacidade de
controlar redes
32
.
Existem muitas implementaes diferentes da tecnologia variando de empresa para
empresa, mas em comum h a operao na frequncia de 2,4 GHz (global, mas variando
em alguns continentes) e o padro de rdio EEE 802.15.4. Na frequncia padro, a taxa
de transmisso pode chegar a 250kbps e o alcance pode chegar a 1600m dependendo da
potncia dos mdulos e das condies do ambiente.
Os mdulos utilizados no trabalho so da empresa Digi, cuja implementao da
tecnologia ZigBee se chama Xbee
33
. O modelo de mdulo utilizado o Xbee 802.15.4 S1,
similar ao da figura 6, que opera na frequncia de 2,4GHz, transmisso de 250kbps e
alcance de at 90m.
!igura >: ?'dulo @Aee #%.
!onte: /htt:00www.seeedstudio.com0deot0bm1;cache0>0
>dbfcfc9++db34a,+e>B9C%+a9,9C3f>.image.,99x++3.jg5
Alm dos mdulos, so utilizadas uma Xbee USB Adapter Board
34
e uma Xbee
Adapter Board
35
, ambas da Parallax. A primeira auxilia na configurao dos mdulos via
PC atravs do software X-CTU, tambm da Digi
36
. A segunda tem como objetivo adaptar a
pinagem dos mdulos para que seja possvel conect-los a placas com espaamento DP,
incluindo rotoboards, durante o processo de testes.
4$A$G A(e"e!;e!o B ADXLA:<
Acelermetros como o prprio nome sugere, so utilizados para medir acelerao.
O acelermetro como sensor pode ser utilizado tanto para medir acelerao esttica,
como a da gravidade, bem como pra medir aceleraes dinmicas, quando h
movimentao do dispositivo
37
. No caso do projeto podem ser teis em diversas frentes,
como na obteno da altura do corpo do rob e na deteco de inclinaes indesejveis
do mesmo, bem como as aceleraes ocorridas durante a movimentao.
O acelermetro utilizado um ADXL345, da Analog Devices. Aceleraes nos 3
eixos so medidas com esse dispositivo, com resoluo de at 13 bits. Os dados
adquiridos so transmitidos de forma digital utilizando interface SP ou 2C
38
. Vale
ressaltar que o kit de FPGA utilizado j possui um sensor desses em seu PCB, facilitando
bastante sua utilizao. O design do kit, contudo, restringe a comunicao a ser somente
SP.
4$A$H M#7ne;e!o B HMC<IIA
Magnetmetros so instrumentos utilizados para medir a fora e algumas vezes a
direo de um campo magntico, em muitos casos sendo esse campo o prprio campo
magntico da terra
39
. Uma aplicao possvel, como no caso do projeto, utilizar o
magnetmetro como uma bssola de baixo custo.
O magnetmetro utilizado um HMC5883, da Honeywell. Foras magnticas so
medidas nos 3 eixos e digitalizadas por um ADC de 12 bits. A comunicao com o sensor
feita somente por 2C
40
. Para o funcionamento adequado necessrio calibrar o sensor
em escala e offset. Quanto a escala, o prprio sensor j fornece a possibilidade de gerar
um campo magntico arbitrrio para coletar as diferenas entre os 3 eixos e normaliz-
las. J quanto a offset, necessrio verificar as respostas do sensor e corrigi-las
manualmente.
4$A$I E&!11!# ;e(Jn6(# B MSR'HC0
Devido a inexperincia da equipe na rea de mecnica, mudou-se a ideia inicial de
desenvolver a estrutura mecnica do rob. No princpio havia se pensado em fazer um
esboo e repass-lo a um engenheiro mecnico, devidamente capacitado a oficializar o
projeto mecnico. Com o projeto em mos, seria necessrio contratar os servios de uma
oficina para cortar as peas nos tamanhos adequados, bem como adquirir quantidade de
material suficiente para essa finalidade. Apenas o corte de peas personalizadas, sem
considerar o custo do projeto mecnico e da matria prima, custa cerca de R$ 400,00. A
partir do momento que se percebeu que essa soluo no era muito vantajosa
financeiramente, no tempo necessrio para concluso e acima de tudo no conhecimento
agregado, decidiu-se por adquirir uma estrutura pronta.
Dentre vrias opes, a escolhida foi o MSR-H01 da Micromagic Systems, que
custa 139.99 (dados de 22 de janeiro de 2013)
41
, similar figura 7. A empresa
Micromagic Systems desenvolve chassis de robs hexpodes, junto s especificaes
dos motores que devem ser utilizados. O kit contm 26 componentes de alumnio (patas e
corpo), alm de todos os parafusos necessrios para montagem.
!igura B: ?#R$D9% Dexaod 7it.
!onte: /htt:00www.hexaodrobot.com0?#RL;image.asE
!ileFimages0?#R$D9%0?#R$D9%;wa(e;<#=;s5
4$A$K Se!%o;oo!e& B BMS'G4CMG L Co!on# DSA4KMG
Existia a possibilidade de comprar o rob hexpode completo na loja da Micromagic
Systems, e tambm de comprar um pacote incluindo os servos, baterias e eletrnica de
controle. Excetuando-se a compra conjunta dos servos, os outros produtos foram
prontamente descartados, pois um dos focos do projeto desenvolver a prpria parte
eletrnica.
Os servos recomendados pela loja para esse rob so os Hitec HS-225MG e HS-
645MG
41
, sendo o primeiro para a junta da coxa e o segundo para as juntas do fmur e da
tbia. Esses motores foram considerados caros e optou-se por procurar alternativas de
caractersticas semelhantes e preo inferior. Para substituir o HS-225MG foi escolhido o
servo Corona DS329MG e para substituir o HS-645MG escolheu-se o BMS-620MG. As
tabelas 2 e 3 mostram as diferenas entre os servos. Na figura 8 pode ser visto o BMS-
620MG e na figura 9 pode ser visto o Corona DS329MG.
Tabela +: Gomara*Ho entre servos D#$>63?. e A?#$>+9?.
HS'G:<MG BMS'G4CMG
Peso (g) 55,2 50
Dimenses (mm) 40.6x19.8x37.8 40.5x20x42
Torque (kgf.cm) @ 4.8V 7,7 9,1
Torque (kgf.cm) @ 6V 9,6 10,6
Tabela ,: Gomara*Ho entre servos D#$++3?. e Gorona &#,+C?.
HS'44<MG Co!on# DSA4KMG
Peso (g) 31 32
32.3x16.8x31 32.5x17x34.5
3.9 3.8
4.8 4.5
Dimenses (mm)
Torque (kgf.cm) @ 4.8V
Torque (kgf.cm) @ 6V
!igura 4: #ervo A?#$>+9?..
!onte: /htt:00www.hobby(ing.com0hobby(ing0store0;;4BB>;;
bms;>+9mg;high;tor2ue;servo;metal;gear;C;%(g;%3sec;39g.html 5
!igura C: #ervo Gorona &#,+C?.
!onte: /htt:00www.hobby(ing.com0hobby(ing0store0;;%CC34;;;
Gorona;&#,+C?.;&igital;?etal;.ear;#ervo;,;4(g;,+g;9;%%s.html 5
De acordo com [42], virtualmente todo equipamento eletrnico requer uma fonte de
alimentao de corrente contnua, seja ela uma bateria ou fonte comum. Servos no
fogem a regra e tambm necessitam de uma fonte desse tipo.
Segundo as especificaes dos servos em [43] e [44], as correntes de operao do
BMS-620MG e do DS329MG so respectivamente 740mA e 400mA em 6V. A tenso de
6V comum em baterias para hobbystas, mas incomum para a maioria das fontes. Em 5V
(pouco acima dos 4,8V das especificaes) os servos j fornecem bom torque e portanto
escolheu-se 5V como a tenso de alimentao.
4$A$0C Fone de #"6;en#23o do& &e!%o& B Fone ATX :<CM
Cada uma das 6 patas possui 2xBMS-620MG e 1xDS329MG, o que d uma
estimativa de 1880mA em operao para cada pata e um total de 11,28A considerando-se
as 6 patas. Especificou-se no projeto que a alimentao poderia ser feita por cabo, o que
viabiliza a escolha de uma fonte comum em detrimento de uma bateria com capacidade
suficiente e que necessitaria um estudo mais apurado. Pelo fato de j se possuir o
componente, escolheu-se uma fonte ATX de 450W, em pico, para alimentar a parte de
potncia. A fonte escolhida fornece at 22A na linha 5V, o que d uma margem bastante
segura de operao considerando as estimativas prvias.
4$A$00 E&#23o B#&e
A estao base qualquer computador que possua os seguintes requisitos: ao
menos uma porta USB, funcione no sistema operacional Windows XP (ou superior),
consiga executar uma mquina virtual Java e possua um mouse, um teclado e monitor.
O computador da estao base, atravs de um software que implemente um
protocolo simples a ser desenvolvido, deve enviar comandos ao rob atravs do mdulo
ZigBee ligado porta USB. O mdulo ZigBee realizar a comunicao com a FPGA, que
deve, atravs do mesmo protocolo, interpretar os comandos e executar a ao
correspondente ao comando enviando sinais para os motores ou enviando uma leitura
para o computador.
2." Parte te#rica
4$:$0 C6ne;6(# 6n%e!&#
Segundo Craig
45
, cinemtica a cincia do movimento que ignora as foras que
causam o movimento. Dentro da cincia da cinemtica, estuda-se posio, velocidade,
acelerao e as derivaes das variveis de posio. No campo da robtica, a descrio
cinemtica de um manipulador consiste em saber a posio da ferramenta a partir de um
sistema de coordenadas base, como pode ser visto na figura 10.
Cada junta do rob tem um sistema de coordenadas correspondente. Os sistemas
de coordenadas so mapeados de forma relativa ao anterior. A partir do momento que se
tem todos os sistemas de coordenadas do rob possvel obter o posicionamento de um
sistema com relao a qualquer outro. Matematicamente a definio de um sistema de
coordenadas a partir de outro feita atravs de uma matriz de transformao linear, como
a da figura 11. Essa matriz, homognea, engloba um rotacional, para representar as
diferenas de ngulo entre os eixos de cada sistema, e um vetor posio, que vai da
origem de um sistema a origem do outro. A matriz serve como operador para transformar
vetores de um sistema em outro.
!igura %9: 8xemlo de sistemas de coordenadas em robIs.
!onte: <magem retirada de J63K.
!igura %%: Transforma*Ho de um vetor osi*Ho ) do sistema " ara o sistema A, usando
matri1 de transforma*Ho.
!onte: <magem retirada de J63K
Ter conhecimento das posies relativas de sistemas de coordenadas uma
ferramenta importante, mas por si s no resolve o problema. Distncias entre eixos, por
exemplo, so constantes pois podem ser medidas, mas a angulao de cada junta
sempre uma incgnita no sistema ao calcular a posio e a rotao da ferramenta. Para
resolver essa questo existem duas abordagens distintas, utilizando a cinemtica direta
ou cinemtica inversa. Com a cinemtica direta calculam-se a posio e orientao da
ferramenta a partir dos ngulos das juntas do manipulador. J com a cinemtica inversa
calculam-se os ngulos das juntas do manipulador a partir da posio e da orientao da
ferramenta.
Segundo Buss
46
na introduo de seu artigo, a cinemtica inversa comumente
utilizada quando se trata de movimentao de braos robticos ou animao de
esqueletos virtuais. A opo por essa abordagem se torna clara por ser muito mais
simples fornecer a posio final desejada do que os ngulos de juntas que levam a essa
posio. O professor Max Fischer
47
cita em seu material trs possibilidades de soluo da
cinemtica inversa. O problema pode ser resolvido de forma incremental, analtica ou
geomtrica.
A soluo incremental relativamente simples de ser obtida. Partindo-se da
equao (1) onde "J o jacobiano, "x o vetor posio da ferramenta e "q um vetor
contendo os ngulos de cada junta. A partir dessa frmula possvel obter equao (2).
Partindo-se de uma posio inicial para a qual tanto "x e "q so conhecidos, possvel
chegar as coordenadas desejadas somando pequenos incrementos "dq e "dx. No caso
da soluo analtica, a soluo obtida manipulando-se algebricamente as matrizes de
transformao de sistemas de coordenadas. A soluo geomtrica necessita de uma
anlise grfica do rob para encontrar relaes entre os ngulos e a posio desejada.
J (q)=
dq
dx
L%M
dx=J
1
( q)dq L+M
Todas as solues so vlidas, tm suas vantagens e desvantagens. Deve-se
analisar qual o tipo de rob que se est construindo, qual a complexidade e, a partir
disso, definir qual mtodo o mais adequado.
4$:$4 NG#6O
De acordo com o dicionrio, gait refere-se ao modo de andar. No caso de um
hexpode, existe a possibilidade de utilizar 4 tipos distintos de gait
48
. Para facilitar a
visualizao dos movimentos, adota-se a conveno apresentada na figura 12.
!igura %+: Gonven*Ho de numera*Ho das atas.
!onte: /htt:00hexaodrobots.weebly.com0uloads04030,06043,63340%,%>,6%6+3.jg5
Dentre as possveis, possvel utilizar uma combinao 4+2, tambm conhecida
como "quadruped gait. Nessa combinao alternam-se 2 patas movendo-se para frente
pelo ar, enquanto as outras 4 deslocam-se no cho em sentido contrrio. Ao todo so
necessrias trs etapas para completar um ciclo de movimentao, j que so 3 pares de
patas. possvel utilizar tambm 5+1, ou "one by one gait. Nessa combinao uma pata
move-se pelo ar, enquanto as outras 5 deslocam-se no cho em sentido contrrio.
A terceira possibilidade usar uma combinao 3+3, o "tripod gait, em que se
alternam 3 patas no ar e 3 patas no cho. Essa a situao mais estvel do ponto de
vista esttico e dinmico, alm de ser a mais conhecida quando se trata de modos de
andar de hexpodes
49
.
Uma ltima opo possvel o "free gait. Nesse caso, o mais complexo, no h
gait definido. Baseado no que o rob tem de percepo do ambiente, principalmente
quanto ao tipo de terreno, o rob escolhe qual o gait mais adequado para transpor a
situao.
A figura 13 permite uma visualizao simplificada do mecanismo de movimentao.
Nela so mostradas as situaes de pata para pata ao longo do tempo, representadas
com 1 se esto no ar e 0 se esto no cho.
!igura %,: 8s2uemas de movimenta*Ho.
!onte: /htt:00www.oricomtech.com0rojects0cynthia+.gif5
4$:$A De&en%o"%6;eno de 1; &e!%o;oo! p!Pp!6o
Uma das ideias inicias do projeto era desenvolver um servomotor prprio a partir de
um motor DC comum. Como descrito na pgina do 2 de [50], algumas etapas necessrias
para essa realizao, alm da escolha de um motor DC adequado, seriam projetar um
sistema de controle, calibrar a malha de controle com realimentao, projetar e construir a
mecnica de reduo, sem deixar de mencionar o uso de uma eletrnica de potncia.
Com o objetivo de evitar boa parte das tarefas que no so da competncia da rea
de computao e simultaneamente acatando sugesto do orientador, fez-se a opo por
utilizar um servomecanismo j pronto e reprojetar sua eletrnica, o que inclui refazer a
malha de controle e ter de adicionar uma eletrnica de potncia para conduzir o motor. As
questes de cunho mecnico puderam ser ignoradas dessa forma. A figura 14 contm um
diagrama macro do servomotor prprio.
c
o
n
t
r
o
l
e
PWM
(t )
v
pwm
(t )
motor
p
o
t
e
n
c
i
m
e
t
r
o
(t )
555
v
pot
(t )
m
e
d
i
d
o
r
l
a
r
g
u
r
a

d
e

p
u
l
s
o
K
T (t )
m
(t )
des
(t )
FPGA
Motor
Outros
d
r
i
v
e
r
!igura %6: &iagrama do sistema de controle do servomotor r'rio.
!onte: "utoria r'ria
Onde:

des : ngulo desejado

m : ngulo medido

: ngulo real
v
pwm
: tenso (mdia) do PWM
v
pot
: tenso de sada do potencimetro
T
: largura do pulso gerado pelo timer 555
As conexes mecnicas e caixa de reduo ficam implcitas no bloco do motor. Os
componentes externos necessrios so um driver para o motor, j que a sada da FPGA
no fornece corrente e tenses suficientes, e um timer, no caso o comum LM555. Seriam
necessrios ao todo 18 motores semelhantes a esse e o kit de FPGA selecionado possui
um ADC com 8 canais, insuficiente para realizar a leitura de todos os potencimetros.
Para contornar esse problema foi utilizado um temporizador para cada motor gerando um
sinal digital de frequncia fixa e com largura de pulso varivel dependendo da resistncia
do potencimetro. Dessa maneira faz-se uma verso simplificada de um ADC.
4$:$: I4C
O barramento 2C foi projetado pela Philips no comeo dos anos 80 para permitir
comunicao simples entre componentes de uma mesma placa. A partir de 2006 a diviso
de semicondutores da Philips faz parte da NXP
51
. As velocidades suportadas vo desde o
padro inicial standard de 100kbps at high seed de 3.4Mbps
52
. A comunicao
realizada por somente 2 pinos, SDA e SCL, correspondentes respectivamente s linhas
de Serial Data e Serial Clock. Na figura 15 possvel um exemplo de implementao 2C.
!igura %3: -#amle <+G <mlementation.-
!onte: /htt:00www.totalhase.com0image0articles0i+c$diagram.ng5
Um barramento 2C contm sempre no mnimo um master, responsvel por iniciar
as trocas de dados, e at 127 slaves, cada qual com seu endereo de 7 ou 10 bits. Os
slaves no podem por si s enviar dados no barramento e portanto, sempre esperam pela
iniciativa de um master para que haja comunicao
53
. O fato de utilizar apenas 2 fios para
comunicar-se com inmeros dispositivos a maior vantagem desse tipo de comunicao.
No entanto, isso causa um grande overhead ao ter de escrever o endereo do slave no
barramento toda vez que se referir a ele e aguardar por ACKs, que confirmam o
recebimento de mensagens. Esse problema pode ser visualizado no exemplo a seguir e
na figura 16 a ele referente.
!igura %>: -<+G Gommunication )rotocol-.
!onte: /htt:00www.totalhase.com0image0articles0i+c$rotocol.ng5
A comunicao se d pela seguinte sequncia de eventos, como na seo "Theory
of Operation de [52]:
1. ?aster coloca o barramento em #tart. A partir desse momento todos os slaves
aguardam.
2. Em seguida um dos slaves endereado, seguido por uma flag de escrita ou
leitura.
3. O slave endereado envia um ACK ao master confirmando a comunicao.
4. A comunicao procede alternando 1 byte enviado pelo master e 1 bit de ACK
enviado pelo slave.
5. Quando o master achar conveniente, envia 1 bit de #to e encerra a comunicao.
4$:$< A"o(#23o d6nJ;6(#Q #"o(#23o e&6(# e object poolin$
A alocao dinmica de memria um elemento fundamental em sistemas
computacionais desde a dcada de 1960
54
. comum empregar alocao dinmica
quando se utilizam estruturas de dados complexas, pois ela d ao programador grande
poder expressivo
55.
Atravs dela possvel criar objetos quando necessrio e elimin-los
quando deixam de ser utilizados, ento especialmente adequada quando certas
entidades (objetos) tm um tempo de vida til menor que a aplicao.
Apesar de amplamente utilizada, a alocao dinmica pode ter comportamento
no-determinista, e seu mau uso pode levar a vazamentos de memria, inconsistncia de
dados e exausto de memria
56
. Certos autores consideram a alocao dinmica um
problema insolvel
54
. Ainda assim, linguagens de alto nvel amplamente utilizadas como
C#, VB.Net e Java empregam alocao quase integralmente dinmica
15,57
.
O oposto de alocao dinmica a alocao esttica, na qual a criao dos objetos
ocorre em tempo de compilao (a inicializao ocorre em tempo de execuo). Com
alocao esttica, no so criados ou apagados objetos na hea durante a execuo
58
,
mas possvel criar objetos de escopo local na pilha. Este paradigma muito utilizado em
sistemas de tempo real. Nele, todos os objetos tm um escopo e um tempo de vida bem
conhecidos, evitando o no-determinismo e o overhead da alocao dinmica
59
. Por outro
lado, preciso criar explicitamente todos os objetos antes de utiliz-los e no medida
que so necessrios
58
, o que a torna menos adequada para implementar estruturas de
dados mais complexas
55
.
Para combinar as vantagens de alocao dinmica e alocao esttica, existe o
paradigma de "object pooling. Tal paradigma utilizado amplamente (especialmente em
jogos) com a finalidade de otimizar cdigo
60
. Ele envolve a utilizao de ools (piscinas)
de objetos pr-alocados, das quais so obtidos objetos quando normalmente seriam
alocados novos, e qual eles so devolvidos quando normalmente seriam apagados
61
.
)ools de objetos podem ser implementadas utilizando alocao dinmica ou alocao
esttica.
Em ools de objetos implementadas utilizando alocao dinmica, os objetos so
criados na prpria hea, ento ainda podem ser criados novos objetos e apagados os
antigos, se for necessrio. Seu uso minimiza, mas no evita os problemas decorrentes de
usar alocao dinmica, j que a hea continua sendo utilizada. Em linguagens como
Java e C#, somente este mtodo pode ser utilizado para implementar ools de objetos.
Como continua havendo alocao na hea, ele continua no sendo adequado para
sistemas embarcados.
J em ools de objetos implementadas por alocao esttica, os objetos so todos
declarados estaticamente e de alguma forma marcados como "utilizados e "livres
medida que so obtidos ou devolvidos pool. Seu emprego tem uma desvantagem em
relao alocao dinmica convencional: todos os objetos ocupam espao da memria
mesmo quando no so utilizados. Em contrapartida, o custo computacional de criao de
objetos consideravelmente reduzido. Em resumo, o emprego das ools implementadas
por alocao esttica tem a vantagem de preservar a semntica da alocao dinmica,
em que h controle sobre o tempo de vida dos objetos sem perder as vantagens (e as
desvantagens) da alocao esttica.
4$:$G G#!b#7e (o""e(6on e !e9e!en(e (o1n6n7
Programas desenvolvidos em linguagens no-gerenciadas podem conter erros em
relao alocao dinmica de memria
62
, que podem causar dois tipos distintos de
problemas: vazamentos de memria (memory lea(s) e ponteiros soltos (dangling
ointers). Um vazamento de memria ocorre quando um bloco de memria no
apagado quando deixa de ser utilizado, de forma que o bloco nunca liberado. &angling
ointers so ponteiros no-inicializados ou de objetos que j foram apagados, de forma
que apontam para regies invlidas de memria
63
.
Para evitar estes problemas, costumeiro empregar convenes rgidas quanto
ordem de alocao e apagamento de objetos, ou utilizar algum sistema para
gerenciamento automtico de memria. Sistemas mais avanados podem acompanhar
garbage collectors, que so ferramentas responsveis por analisar a memria e
determinar quais objetos no so mais utilizados e podem ser apagados. O programa
deve parar de ser executado parcialmente ou totalmente (dependendo da implementao)
enquanto um garbage collector estiver analisando a memria, do contrrio a anlise pode
ficar inconsistente. As mquinas virtuais Java (JVMs) utilizam-se de garbage collection
para gerenciamento da memria. Existem garbage collectors para as linguagens C e C++,
mas so bastante limitados, e seu emprego requer que algumas normas de programao
sejam seguidas.
Uma alternativa mais rudimentar e leve aos garbage collectors o mecanismo de
contagem de referncias. Como o nome sugere, este mecanismo envolve manter um
contador indicando em quantos lugares cada objeto referenciado. O contador atingir
valor zero uma indicao de que o objeto no mais referenciado, e ento pode ser
apagado. A contagem de referncias no funciona bem quando h referncias circulares,
pois j que o contador de alguns objetos no atinge zero, eles nunca so apagados. O
problema das referncias circulares pode ser resolvido atravs de referncias fracas nos
lugares certos do cdigo. Uma referncia fraca ignorada pelo contador de referncias,
mas diferente de um ponteiro convencional. Um ponteiro convencional se tornaria um
dangling ointer caso o objeto fosse apagado, enquanto as referncias fracas passam a
apontar para nulo quando isto ocorre.
2.% &onven'es de pro$ramao
A utilizao de uma conveno consistente de programao melhora o processo de
desenvolvimento e manuteno de cdigo
64
, pois facilita seu entendimento
65
e ajuda a
evitar alguns erros comuns de programao
66
. Os quatro artefatos de software do projeto
incluem cdigos em linguagem Java, C++ e alguns trechos em linguagem C. Devido
complexidade do projeto, criou-se e adotou-se uma srie de convenes de programao.
J existem diversas convenes para as trs linguagens, as quais diferem
grandemente de uma linguagem para a outra. Para facilitar o desenvolvimento, dentro do
razovel, buscou-se a utilizao de uma conveno consistente de programao nas trs
linguagens. A conveno adotada de autoria prpria, mas incorpora caractersticas
encontradas nas Java Coding Conventions
65
, nos GNU Coding Standards
67
e no Google
C++ Style Guide
68
.
As regras so divididas em trs grupos. O primeiro grupo contm regras de
nomeao de funes, classes, entre outros. O segundo grupo contm regras gerais
referentes codificao em si. Finalmente, o terceiro grupo determina como o cdigo
deve ser formatado em termos de espaamento, identao, entre outros.
4$<$0 Re7!#& de no;e#23o
1. Pacotes em Java e namespaces em C++ devem ser escritos inteiramente com
letras minsculas. Se os nomes forem compostos de mais de uma palavra, cada
palavra subsequente deve iniciar com letra maiscula, com as demais letras
minsculas (camelCase).
2. Classes em Java e C++, estruturas em C e C++, interfaces em Java e
enumeraes em Java, C e C++ devem comear com letras maisculas, com as
demais letras minsculas. Se os nomes forem compostos de mais de uma palavra,
cada palavra subsequente tambm deve iniciar com letra maiscula, com as
demais letras minsculas (PascalCase).
3. Valores de enumerao em Java, C++ e C devem comear com letras maisculas,
com as demais letras minsculas Se os nomes forem compostos de mais de uma
palavra, cada palavra subsequente tambm deve iniciar com letra maiscula, com
as demais letras minsculas (PascalCase).
4. Constantes em Java, C e C++ devem ser escritas inteiramente com letras
maisculas. Se os nomes forem compostos de mais de uma palavra, cada palavra
subsequente ser precedida por um "underline e tambm deve ser escrita
inteiramente com letras maisculas (GNU standard).
5. Mtodos em Java e C++ e funes em C++ devem ser escritos inteiramente com
letras minsculas. Se os nomes forem compostos de mais de uma palavra, cada
palavra subsequente deve iniciar com letra maiscula, com as demais letras
minsculas (camelCase).
6. Funes em C devem ser escritas inteiramente com letras minsculas. Se os
nomes forem compostos de mais de uma palavra, cada palavra subsequente ser
precedida por um "underline e tambm deve ser escrita inteiramente com letras
minsculas (GNU standard).
7. Variveis e parmetros em Java e C++ devem ser escritos inteiramente com letras
minsculas. Se os nomes forem compostos de mais de uma palavra, cada palavra
subsequente deve iniciar com letra maiscula, com as demais letras minsculas
(camelCase).
8. Variveis e parmetros em C devem ser escritas inteiramente com letras
minsculas. Se os nomes forem compostos de mais de uma palavra, cada palavra
subsequente ser precedida por um "underline e tambm deve ser escrita
inteiramente com letras minsculas (GNU standard).
9. Atributos de classes e objetos em Java e C++ devem utilizar a mesma conveno
para nomenclatura de variveis, mas precedidos de "m_ ("meu).
4$<$4 Re7!#& de (od696(#23o
1. Todos os blocos (funes, laos, condicionais, etc) devem ser envolvidos por
chaves, mesmo que sejam de uma nica linha.
2. Todas as invocaes de mtodos de instncia da prpria classe devem ser
empregar explicitamente a palavra-chave "this para diferenciar da invocao de
funes livres e mtodos estticos.
3. Todas as invocaes de mtodos estticos da prpria classe devem empregar
explicitamente o nome da classe para diferenciar da invocao de funes livres e
mtodos de instncia.
4. Em C e C++, as incluses de arquivos de cabealho devem ser sempre em relao
ao diretrio raiz do projeto. Caminhos relativos so mais passveis de erros e
dificultam a localizao dos arquivos.
5. Em Java, C++ e C deve-se evitar a chamada de mtodos especficos da
arquitetura a partir do cdigo de alto nvel, de forma ao cdigo ser portvel.
4$<$A Re7!#& de e&6"o
1. Em C e C++, o colchete de abertura de bloco deve estar sempre na linha seguinte
da declarao do bloco.
2. Em Java, o colchete de abertura de bloco deve estar sempre na mesma linha da
declarao do bloco.
3. O contedo de todo bloco deve sofrer identao. Essa regra inclui os namesaces
em C++.
2.( &onsidera'es
H diversos robs hexpodes disponveis no mercado, mas no foi encontrado
nenhum que combine projetos de software, hardware e mecnica abertos ou bem
documentados e alto grau de sofisticao. Dessa forma, o hexpode descrito neste
projeto representa um grande avano no sentido de um rob hexpode aberto.
Alm disso, o projeto representa uma boa plataforma de aplicao dos
conhecimentos adquiridos no curso de engenharia de computao. Desde conhecimentos
de matemtica, geometria e fsica, aplicados na cinemtica inversa at conhecimentos de
eletrnica e programao aplicados na FPGA, o rob envolve diversas reas da
engenharia.
A De&en%o"%6;eno
3.1 )ard*are na +P,-
A figura 48 apresenta um diagrama de blocos resumido, o qual contm o hardware
que se encontra na FPGA e os perifricos com os quais esses elementos de hardware se
comunicam.
SDRAM
D
a
t
a

b
u
s
S
P

b
u
s
2
C

b
u
s
UART bus
ZigBee
Acelermetro MU
Cinemtica inversa
Gerenciador de sinais
18x Geradores de PWM
Hardware embarcado
Avalon /O bus
!igura %B: &iagrama de blocos do hardware embarcado e erifNricos.
A$0$0 NIOS B M6(!o(on!o"#do! E;b#!(#do
O bloco Nios inclui o processador, o qual roda os mdulos descritos na seo
firmware, e outros perifricos de integrao. Todo o sistema montado com auxlio da
ferramenta SOPC Builder
69
, a comear pela incluso de um processador Nios . Das 3
opes disponveis na tela de incluso 18, escolheu-se a opo Nios /e. o mais
Captulo 3 Desenvolvimento 49
simples dos trs, mas o que requer menos unidades lgicas. Os clculos mais pesados,
como a cinemtica inversa, foram implementados como blocos de hardware avulsos e
dessa forma no h necessidade de alto poder de processamento do Nios.
!igura %4: =*Oes de rocessador :ios disonPveis no #=)G.
!onte: /htt:00fga6u.efl.ch0images0b0be0:ios<<s.jg5
Alm da escolha do processador na figura 18, deve-se mencionar a escolha das
memrias que sero utilizadas pelo processador. No exemplo dado utilizada memria
onchi, composta por unidades lgicas da prpria FPGA, o que altamente benfico do
ponto de vista desempenho, mas tambm bastante limitado quando se fala em
capacidade
70
. Somando-se o firmware desenvolvido para o Nios acompanhado de um
RTOS e lgica desenvolvida em VHDL, necessrio mais memria. Seguindo sugestes
da prpria Altera e do recurso oferecido pelo kit FPGA utilizado, fez-se uso da SDRAM de
32MB disponvel. Embora seja mais lenta e necessite de uma controladora dedicada para
oper-la, oferece espao mais do que suficiente para as rotinas necessrias no projeto.
A controladora de SDRAM tem algumas peculiaridades na configurao. No existe
configurao padro do SOPC para o modelo de SDRAM. Para que funcione
corretamente, deve-se criar uma configurao customizada e utilizar os parmetros
fornecidos no tutorial
71
. As duas telas de configurao da controladora ficam como as
figuras 19 e 20. Alm de configurar a controladora, a SDRAM precisa de um sinal de clock
deslocado no tempo para que os dados estejam estveis. A gerao desse sinal
possvel utilizando uma PLL para o clock, com sinal de sada de formato igual ao da
entrada deslocado -3ns para um clock de 50MHz. Como o clock utilizado de 100MHz,
utilizou-se o equivalente em graus para o deslocamento, cujo valor -54 e independe da
frequncia. A tela de configurao da PLL pode ser vista na figura 21.
!igura %C: Gonfigura*Oes da controladora #&R"?, Qgina %.
!igura +9: Gonfigura*Oes da controladora #&R"?, Qgina +.
!igura +%: Gonfigura*Ho da )LL da #&R"?.
O mdulo Xbee conectado a FPGA tratado como um dispositivo UART comum.
Para estabelecer a comunicao com dispositivos desse tipo, possvel adicionar uma
controladora UART que j faz parte do SOPC Builder. As configuraes da controladora
s precisam ser similares s configuraes dos mdulos Xbee para que tudo funcione
corretamente. Como pode ser visto na figura 22, os nicos cuidados a serem tomados so
no usar paridade e usar 8 bits de dados acompanhado de um sto bit. O baud rate
utilizado de 57600 bits por segundo. Embora o mximo seja 115200 bits, essa opo se
tornou invivel devido a alta taxa de erros apresentada. Alm dessa UART, utilizada
uma JTAG UART para estabelecer comunicao entre o Nios e o PC para auxiliar no
processo de debug durante o desenvolvimento.
!igura ++: Gonfigura*Ho da R"RT.
A comunicao entre Nios e sensores feita pela controladora 2C descrita na
seo 3.1.6. Ela no faz parte da biblioteca padro do SOPC e deve ser adicionada. O
pacote disponvel em [72] j foi adaptado a interface Avalon e completamente funcional
aps ser adicionado, sem que haja necessidade de configuraes adicionais.
Os componentes restantes so dispositivos de /O paralelo, utilizados para
interfacear o Nios com o resto do sistema desenvolvido. A figura 23 mostra as
controladoras utilizadas, todas com o prefixo "pio_bot por interfacearem com o bloco
responsvel pela movimentao do rob. As trs primeiras (pio_bot_x, pio_bot_y e
pio_bot_z) possuem 16 bits cada e so responsveis pela escrita de coordenadas
cartesianas sinalizadas. Os 3 bits de "pio_bot_legselect selecionam a qual pata as
coordenadas correspondem e o bit "pio_bot_wrcoord indica que os dados devem ser
escritos. O bit "pio_bot_reset utilizado para garantir que o clculo da cinemtica inversa
s seja efetuado quando o Nios garantir que as trs coordenadas cartesianas so vlidas
e "pio_bot_endcalc indica que o clculo foi finalizado. Atravs do bit "pio_bot_updateflag
indica-se que as sadas, que so os sinais PWM direcionados aos servos, devem ser
atualizadas.
!igura +,: #istema #=)G comleto.
A$0$4 C6ne;6(# 6n%e!&#
Dentre as opes de cinemtica inversa apresentadas anteriormente, optou-se por
utilizar a soluo geomtrica. Tratando-se cada pata do rob como um sistema
independente, fica relativamente simples resolver de maneira geomtrica porque existem
3 juntas e 2 delas esto posicionadas no mesmo lugar, sem que haja um eixo entre elas.
A figura 24 facilita a anlise.
!igura +6: .eometria de uma ata em detalhe.
As incgnitas so os trs ngulos 01, 02 e 03. 01 est situado somente no plano xy
e pode ser calculado atravs do arco tangente, como mostra a equao (3).
1=arctan( y/ x) L,M
02 necessita de uma decomposio para ser calculado mais facilmente.
Destacando-se o tringulo de arestas z, d e r, o ngulo entre as arestas z e d o primeiro
ngulo parcial de 02 (d), onde d e r so definidos pelas equaes ( 4) e (5). Destacando-
se o tringulo de arestas L1, L2 e d, o ngulo entre as arestas L1 e d o segundo ngulo
parcial que compe 02 (). O primeiro ngulo parcial definido pela equao (6), por
arco-tangente, e o segundo pela equao (7), por lei dos cossenos. 02 ento definido
pela soma de d e , equao (8).
r= x
2
+ y
2
L6M
d =r
2
+ z
2
L3M
=arctan(r/ z) L>M
=arccos(
L1
2
L2
2
+ d
2
2 L1d
) LBM
2=+ (8)
O ltimo ngulo 03, pode ser calculado tambm utilizando lei dos cossenos.
Tomando-se o tringulo formado pelas arestas L1, L2 e d como base se tem a equao
(9).
3=arccos(
L1
2
+L2
2
d
2
2 L1 L2
) (9)
Definidas as equaes dos ngulos das juntas, torna-se simples calcular quais os
ngulos necessrios para qualquer posio desejada para a extremidade da pata.
Com a finalidade de validar as equaes encontradas antes da implementao
prtica do rob, utilizou-se o software MATLAB acompanhado do Robotics Toolbox
73
. O
toolbox est sendo desenvolvido e melhorado h 15 anos, o que faz com que ele seja
uma ferramenta bastante madura para auxiliar na simulao de robs. Para o teste,
primeiramente a pata robtica do hexpode teve de ser representada por uma estrutura
robtica de operao similar de acordo com as possibilidades oferecidas pelo toolbox. As
conexes e juntas foram descritas usando parmetros segundo a notao Denavit-
Hartenberg
74
. Em seguida foram definidas 3 localizaes, as quais foram interpoladas
linearmente para simular uma trajetria de uso. O comportamento observado, em
imagens como a 25, era o esperado.
!igura +3: #creenshot durante simula*Ho de trajet'ria.
Aps ter a simulao funcionando de forma satisfatria, o passo seguinte foi
implementar a cinemtica inversa de forma a ser utilizvel no rob. Para que esse objetivo
fosse completado, era possvel tanto implementar a cinemtica inversa em lgica
reconfigurvel diretamente ou em C, fazendo uso do Nios. Pelo foco do projeto ser o uso
da FPGA, a primeira opo foi escolhida. Alm da justificativa do foco, a matemtica no
ficou complexa a ponto de inviabilizar a implementao em VHDL. A operao de raiz
quadrada foi retirada de
75
e apenas modificada para receber e retornar dados do tipo
integer. No caso das operaes de arco tangente e arco cosseno optou-se por utilizar
valores tabelados, armazenados em memrias ROM. O bloco externamente similar ao
apresentado na figura 26.
!igura +>: Aloco de cQlculo da cinemQtica inversa.
Pode-se notar que existem barramentos de dados e endereo redundantes. Uma
ROM sncrona fornecida pela Altera necessita de 2 clocks para que haja uma leitura
segura do dado desejado (1 clock para escrever o endereo, 1 clock para ler o
barramento de dados). No sistema projetado h sobra de memria, ento conveniente
ter memrias redundantes e diminuir o nmero de ciclos do clculo. Vale ressaltar
tambm que todos os dados so inteiros, sem ponto flutuante. Trabalhando-se com uma
faixa de 180 graus de liberdade tolervel ter +-1 grau de erro para diminuir
consideravelmente a complexidade.
A$0$A Con%e!&o! en!e Jn71"o e "#!71!# de p1"&o
O clculo da cinemtica inversa, como apresentado anteriormente, recebe
coordenadas cartesianas como parmetros e fornece ngulos de juntas como sada. Para
que um servo fique em uma determinada posio contudo, necessita-se de um sinal com
frequncia constante e largura de pulso varivel.
Nessa etapa primeiramente deve-se encontrar a faixa de operao dos servos em
termos de largura de pulso. Aps vrias informaes equivocadas encontradas, o melhor
resultado encontrado foi utilizando a faixa padro dos servos de equipamentos de controle
remoto, ou seja, entre 1 e 2ms. O servo fica centralizado com 1,5ms e atinge
aproximadamente -40 e +40 graus nos dois extremos.
Como entrada, o bloco de converso recebe um ngulo entre 0 e 180 graus. A faixa
segura de operao dos servos apenas metade disso, ento imposta uma limitao no
hardware embarcado para que o ngulo utilizado na converso seja no mnimo
equivalente a -40 e no ultrapasse +40. Limitado o ngulo, basta estabelecer uma
relao linear de transformao entre as duas faixas. A relao fica ento simples, como
na equao (10), onde y a largura do pulso e x o ngulo.
y=1000+(100x)/ 18 L%9M
A aparncia final do bloco pode ser vista na figura 27.
!igura +B: Aloco de conversHo Sngulo T largura de ulso.
A$0$: Ge!#do! de &6n#" PMM
Os servos, como j dito anteriormente, tm sua posio controlada por um sinal
PWM. Em portugus a sigla significa modulao por largura de pulso, e as propriedades
bsicas desse tipo de sinal podem ser adquiridas em [76]. A partir dos conceitos bsicos,
percebe-se que os parmetros de um sinal PWM so frequncia e largura de pulso. A
figura 28 mostra como esses parmetros so interpretados no sinal e a figura 29, a
aparncia externa do bloco gerador de sinal.
perodo
largura
!igura +4: #inal )W?.
!igura +C: Aloco gerador de sinal )W?.
A entrada "Clockn do bloco recebe um clock, no caso o geral do sistema, cuja
finalidade servir de referncia para os clculos de largura e perodo do sinal. No bloco
acima o clock de entrada de 100MHz e o perodo 2 milhes de clocks, o que resulta
em 20ms ou frequncia de 50Hz. O BMS-620MG como servo analgico usa sinais PWM
com frequncia de 50Hz. O DS329MG, por sua vez, digital e usa sinais com 200Hz de
frequncia.
A outra entrada, "PulseWidthn, recebe a largura de pulso propriamente desejada.
Vale ressaltar que o clock a referncia, logo a largura deve ser dada em nmero de
clocks.
A$0$< Ge!en(6#do! de &6n#6& p#!# o& &e!%o;oo!e&
Cada uma das 6 patas possui 3 servos para serem controlados, cada um com um
ngulo objetivo definido segundo o processo de cinemtica inversa. Em uma situao
ideal cada uma das patas teria seu prprio bloco de cinemtica inversa e o clculo seria
executado em paralelo de maneira simultnea para todas elas. No entanto, isso no
possvel pela falta de capacidade da FPGA utilizada. Fazendo uso de todos os blocos foi
ultrapassado o limite de aproximadamente 22 mil elementos lgicos.
Com o objetivo de resolver esse problema, reduziu-se o nmero de blocos de
cinemtica inversa para apenas um e foi desenvolvido um bloco para armazenar os
ngulos calculados e envi-los s sadas de maneira sincronizada. A aparncia externa do
bloco pode ser vista na figura 30.
!igura ,9: Aloco gerenciador de sinais
Na parte esquerda do bloco angle1, angle2 e angle3 so entradas e recebem os
ngulos dos servos de uma pata calculados pelo bloco de cinemtica inversa. Os bits
sel[2..0] so utilizados para selecionar uma das 6 patas, para qual se deseja armazenar
os ngulos calculados. Para escrever as coordenadas a uma das patas alm dos bits
sel[2..0], deve-se manter o bit wr;coord para que a escrita seja devidamente realizada.
Quando todas as escritas foram devidamente realizadas e as 6 patas possuem
coordenadas relativas a um mesmo instante de tempo, o bit udate;flag setado para
que as sadas angle);# sejam atualizadas, onde P se refere a uma pata e S a um servo.
Aps a atualizao de todas as sadas, o bit re2uest;new;coord setado e indica o
requerimento de novas coordenadas.
A$0$G Co;1n6(#23o I4C
Como apresentado anteriormente, todos os sensores utilizados usam comunicao
por 2C e se comportam como slaves. Embora bastante completa, a biblioteca de
componentes do SOPC Builder
77
no possui bloco de hardware como master 2C para ser
integrado ao NOS e realizar a comunicao com os sensores. Em situaes como essa
conveniente buscar uma soluo em sites como o OpenCores
78
, que so comunidades de
desenvolvimento de Ps (propriedade intelectual) disponibilizadas como cdigo aberto
(oen source). A opo escolhida foi o <+G controller core
BC
, desenvolvido em Verilog por
Richard Herveille. A figura 31 mostra a arquitetura interna do bloco.
!igura ,%: -<nternal structure <+G ?aster Gore-.
!onte: /htt:00oencores.org0roject,i+cEdoFsvngetUrojectFi+cUfileFV+!trun(V+!doc
V+!i+c;secs.df5
Do ponto de vista do usurio do bloco, somente os registradores podem ser
acessados. Atravs do "Prescale Register determina-se o clock que ser utilizado na
linha SCL. Com o "Command Register determinam-se os prximos passos das SCL e
SDA, como gerar sinais de #tart, #to, Read, Write e envio de ACK/NACK ao slave. O
"Status Register fornece informaes das transmisses, como recebimento de ACK do
slave, canal 2C ocupado ou transmisso em andamento. Os ltimos dois registradores
"Transmit Register e "Receive Register contm respectivamente o prximo byte que se
deseja enviar e o ltimo byte vlido recebido. Vale ressaltar que toda a comunicao com
o bloco feita atravs de bytes, sendo somente o "Prescale Register dividido em 2
registradores de 1 byte.
O bloco 2C escolhido possui todos os recursos necessrios, mas utiliza a interface
open source Wishbone
80
para ser integrado ao resto do sistema. Um sistema SOPC com
NOS, no entanto, usa a interface proprietria Avalon
81
da Altera, incompatvel diretamente
com Wishbone. Para contornar esse problema necessrio um wraer que seja
conectado ao Avalon e repasse os dados recebidos na interface de forma compatvel com
a interface Wishbone, bem como o caminho inverso. Um wraer com essa finalidade j
foi desenvolvido e pode ser encontrado em [72].
3.1.(.1 .oft*are de interfaceamento
Com o bloco 2C devidamente integrado ao resto do sistema SOPC e ao NOS em
termos de hardware, deve-se ento estabelecer o contato entre eles do ponto de vista do
firmware. Baseado nos exemplos da documentao fornecida, foram desenvolvidas
funes simples para realizar algumas atividades necessrias quando se trata de
comunicao 2C
82
. As funes tem o objetivo de reajustar o cloc(, enviar dados a um
slave, escrever um registrador de um slave e ler o registrador de um slave. So elas:
i2c_set_clock(system_clock, desired_scl)
Recebe como parmetros o cloc( geral do sistema e o cloc( desejado na linha
SCL. A partir dos parmetros calcula-se o valor necessrio de rescale. O byte
mais alto do valor calculado e o mais baixo so escritos respectivamente nos
registradores PRERhi e PRERlo.
i2c_write_data(slave_address, data)
Escreve no TXR (Transmit Register) o endereo slave;address e envia ao
slave, setando os bits STA (#tart) e WR (write) do CR (Gommand Register).
Aguarda pelo fim da transmisso e confirmao de recebimento pelo slave,
enviando em seguida o parmetro data pelo mesmo processo mas com o bit
STO (#to) em vez de STA. Ao enviar um STO o master requisita o fim da
comunicao com slave. O master espera pelo fim da transmisso e
confirmao de recebimento do dado pelo slave.
i2c_write_register(slave_address, register_address, data)
Similar a funo anterior, mas envia o dado para ser gravado em um dos
registradores do slave. A nica diferena que h mais uma rodada de
comunicao, depois do envio do slave;address e antes do envio de data.
Nessa etapa adicional os bits STA e STO no so setados.
i2c_read_register(slave_address, register_address)
Envia um endereo slave;address e um registrador de maneira similar ao
processo de escrita, mas em vez de enviar um dado, envia novamente o
endereo com os bits STA e WR setados. Nesse caso, setar o bit STA uma
requisio de reinicio. Na quarta rodada apenas so setados os bits RD ( Read),
ACK e STO do CR. Dessa forma o master libera o barramento para ser escrito
pelo slave e aps o fim da transmisso pede o fim da comunicao.
3.2 )ard*are e/terno
A$4$0 De&en%o"%6;eno do& &e!%o;oo!e& p!Pp!6o&
Para a construo de um servomotor prprio utilizou-se de base um servo
Motortech
83
. O servo foi aberto e desmontado, de forma a remover toda a eletrnica
responsvel pelo controle e amplificao dos sinais, como mostrado na figura 32.
Restaram somente as engrenagens, o motor DC e o potencimetro que serve como
mecanismo de realimentao da posio.
!igura ,+: #ervo desmontado.
Dos componentes restantes, utilizam-se os terminais do potencimetro em um
circuito similar ao descrito na seo da parte terica. A conexo do potencimetro ao
LM555 pode ser visualizada na figura 33, configurao ( (astvel). Os terminais do
potencimetro ficam conectados ao LM555 de forma que Ra uma das parcelas do
potencimetro e Rb a resistncia restante. A frequncia do sinal produzido constante e
a largura varivel. Esse sinal de sada produzido pelo LM555 ento conectado a
FPGA, que, com base na largura do pulso, determina a posio (ngulo) do servo.
!igura ,,: Gonfigura*Oes de L?333.
!onte: /htt:00www.doctronics.co.u(0df;files0333an.df5
necessrio encontrar uma relao entre ngulo e largura do pulso produzido para
realizar a devida interpretao na FPGA. Para realizar essa tarefa foram utilizados os
instrumentos osciloscpio e transferidor. Manipulando-se o eixo do servo manualmente e
verificando o sinal produzido com o osciloscpio chegou-se a uma relao linear,
explicitada na equao 11, onde x um pulso com valor entre 0 e 1000, e y um ngulo
entre 0 e 180 graus.
y=( x60)/ 2.11 (11)
Aps a interpretao do sinal, a FPGA gera um sinal PWM calculado por um
controlador proporcional da forma descrita na equao 12, onde P uma constante pr-
definida e error a diferena entre ngulo desejado e ngulo real. O sinal PWM
invertido pois ligado eletrnica de potncia atravs de opto acopladores em modo
emissor comum. Finalmente o sinal de sada do opto acoplador passa pelo L298, que o
amplifica, para ento controlar o motor DC. O melhor resultado encontrado nos testes,
com o objetivo de minimizar o overshoot e maximizar a velocidade de resposta foi com P
= 2.
P
out
=Perror ;
(12)
A$4$4 P"#(#& de C6!(16o I;p!e&&o
As Placas de Circuito mpresso (PC) produzidas para o projeto tem como principais
objetivos distribuir a energia e realizar a conexo entre os dispositivos (XBee, servos e
sensores) e a FPGA. A ideia original era produzir apenas uma PC contendo todos esses
elementos, entretanto, aps uma anlise e um projeto inicial verificou-se que no seria
possvel produzir uma nica placa com tamanho adequado para ser encaixada a estrutura
mecnica do Hexpode.
Por isso foram elaboradas 2 placas, uma responsvel por distribuir as conexes
dos servomotores, intitulada PC dos servos. E outra contendo todas as conexes da
FPGA, dos sensores e do XBee chamada de PC da FPGA. Quanto a alimentao do
circuito foram utilizadas duas fontes independentes, sendo uma responsvel por alimentar
a PC dos servos e a outra para alimentar a PC da FPGA. Mais detalhes so explicados
na seo Fonte de alimentao.
Apesar de serem duas placas isoladas elas se conectam, atravs de barras de
pinos paralelas, para passar os sinais do FPGA para os motores formando uma PC de 2
nveis. Essa abordagem foi adotada para evitar a utilizao de conectores com cabos e
transformar o projeto eletrnico em partes modulares para facilitar a montagem e a
manuteno do circuito. Alm disso a FPGA encaixada na sua PC da mesma maneira,
facilitando a sua remoo e tambm evitando possveis problemas de mal contato por
conta de cabos. A seguir sero explicados os projetos da duas placas de maneira isolada,
analisando primeiramente o esquemtico do circuito e depois o projeto da placa.
3.2.2.1 P&0 da +P,-
O projeto da PC da FPGA sofreu poucas alteraes depois da sua concepo
inicial e possu um projeto relativamente simples. Para facilitar o entendimento do circuito
completo, que pode ser visto na figura 34, o esquemtico ser explicado em 4 partes
distintas.
!igura ,6: 8s2uemQtico do circuito da )G< da !).".
A primeira parte realiza a conexo entre a FPGA e a placa dos servomotores.
Essas conexes so responsveis por passar os sinais de PWM da FPGA para os
motores. A figura 35 apresenta a configurao dos pinos de sada da FPGA e so
idnticos aos conectores GPO-0 e GPO-1 apresentados na figura 34. Na configurao
do projeto o GPO-0 configurado como canal de sada para os pinos GPO_00 a
GPO_33 e possui os pinos GPO_0_N0 e GPO_0_N1 como pinos de entrada. A tabela
4 e a tabela 5 apresentam as configuraes dos pinos utilizados para conectar as duas
PCs, todos os pinos no relacionados nas tabelas no possuem nenhuma conexo.
GPO - 0 GPO - 1
GPO_032
GPO_031
GPO_07
GPO_012
GPO_0_N1
GPO_0_N0
GPO_011
GPO_016
GPO_014
GPO_020
GPO_019
GPO_010
GPO_022
GPO_026
GPO_030
GPO_017
GPO_015
GPO_06
GPO_00
GPO_024
GPO_013
GPO_09
GPO_021
GPO_033
GPO_029
GPO_025
GPO_023
GPO_02
GPO_018
GPO_028
GPO_08
GPO_05 GPO_04
GPO_027
GPO_03
GPO_132
GPO_131
GPO_17
GPO_112
GPO_1_N1
GPO_1_N0
GPO_111
GPO_116
GPO_114
GPO_120
GPO_119
GPO_110
GPO_122
GPO_126
GPO_130
GPO_117
GPO_115
GPO_16
GPO_10
GPO_124
GPO_113
GPO_19
GPO_121
GPO_133
GPO_129
GPO_125
GPO_123
GPO_12
GPO_118
GPO_128
GPO_18
GPO_15 GPO_14
GPO_127
GPO_13
GPO_01 GPO_11
VCC_SYS
VCC3P3
VCC_SYS
VCC3P3
JP2
1
1
2
2
3
3
4
4
5
5
6
6
7
7
8
8
9
9
10
10
11
11
12
12
13
13
14
14
15
15
16
16
17
17
18
18
19
19
20
20
21
21
22
22
23
23
24
24
25
25
26
26
27
27
28
28
29
29
30
30
31
31
32
32
33
33
34
34
35
35
36
36
37
37
38
38
39
39
40
40
JP1
1
1
2
2
3
3
4
4
5
5
6
6
7
7
8
8
9
9
10
10
11
11
12
12
13
13
14
14
15
15
16
16
17
17
18
18
19
19
20
20
21
21
22
22
23
23
24
24
25
25
26
26
27
27
28
28
29
29
30
30
31
31
32
32
33
33
34
34
35
35
36
36
37
37
38
38
39
39
40
40
!igura ,3: )inos de <0= da !)." L.)<=$9 e .)<=$%M
!onte: Retirado de J%6K
Tabela 6: Gonfigura*Ho dos inos do conector A="R&$G9
Board - C0 [Pin] GPIO - 0 [Pin] FPGA [Pin] Funo
2 5 GPIO_02 Sinal de PWM para o Servo 1
20 - - GN
Tabela 3: Gonfigura*Ho dos inos do conector A="R&$G%
Board - C1 [Pin] GPIO - 0 [Pin] FPGA [Pin] Funo
19 - - GN
A outra parte da placa a que conecta a FPGA com o mdulo contendo os
sensores (acelermetro, giroscpio e magnetmetro) utilizados no hexpode, chamado de
MU. A MU conectada ao barramento GPO1 e alimentada com uma tenso de 3.3V. A
figura 36 apresenta os pinos da MU e a tabela 6 as configuraes dos pinos utilizados.
Novamente, os pinos no apresentados no so utilizados.
!igura ,>: )inos da <?R.
Tabela >: Gonfigura*Ho dos inos da <?R
IMU [Pin] GPIO - 1 [Pin] FPGA [Pin] Funo
!-2 - - "!! 3#3"
!-3 - - GN
!-4 7 GPIO_14 S!$ %&lo&'( do I2!
!-5 5 GPIO_12 S) %dado*( do I2!
A conexo com o XBee a terceira parte da PC da FPGA. Ela consiste
basicamente da conexo dos pinos de RX e TX do XBee com o GPO-0 da FPGA. Alm
disso existe um circuito simples com dois transistores e dois LEDS para indicar o envio e
recebimento de dados atravs do RX e TX, e um LED indicador de funcionamento do
XBee. A figura 37 apresenta a placa para adaptar o mdulo XBee com a configurao DP.
Os barramentos J3 e J4 apresentados so os mesmos que aparecem no esquemtico do
circuito da PC da FPGA da figura 34. A tabela 7 apresenta a configurao dos pinos do
mdulo XBee utilizados na PC, aqueles no apresentados no foram utilizados.
Por fim, a ltima parte dessa PC referente ao circuito de alimentao onde o C1
e C2 da figura 34 representam respectivamente um regulador de tenso de 5V e 3.3V
cujas sadas esto conectadas a 2 LEDs indicando o funcionamento dos reguladores.
A FPGA alimentada com 5V e o XBee e a MU com 3.3V e possuem um capacitor
de desacoplamento para filtrar os possveis rudos na alimentao. Por fim existe uma
chave para ligar e desligar o conector de energia (S1) e um jumer (J1) para permitir que
a FPGA seja conectada e alimentada diretamente pelo computador atravs da USB,
facilitando etapas de testes.
Aps terminado o circuito foi realizado o projeto da PC no Eagle para distribuir
corretamente todos os elementos na placa. As maiores dificuldades encontradas nessa
etapa foram ajustar corretamente todos os elementos em uma placa com tamanho
adequado para encaixar corretamente na estrutura mecnica do hexpode e ajustar os
espaamentos para encaixar a FPGA na PC. Durante a distribuio dos componentes
tambm foi necessrio afastar a placa dos sensores da linha de alimentao para evitar
uma possvel interferncia. Como a placa no necessita de trilhas com uma corrente
eltrica superior a 1.5A, foi possvel utilizar sem nenhum problema as configuraes
padres utilizadas no Eagle e fazer o roteamento manual das trilhas. O Diagrama da PC
pode ser visto abaixo na figura 38. As figuras 39 e 40 apresentam o resultado final da PC
da FPGA.
!igura ,B: )inos do ?'dulo @Aee.
!onte: Retirada de J,3K
Tabela B: Gonfigura*Ho dos inos do ?'dulo @Aee na )G<
XBee [Pin] GPIO - 0 [Pin] FPGA [Pin] Funo
+3-1 - - GN
+3-2 - - "!! 3#3"
+3-3 3 GPIO_0_IN1 ,- do -.ee
+3-4 7 GPIO_04 /- do -.ee
+3-11 - - GN
+4-6 - - Indi&ador de 01n&iona2en3o do -4ee
!igura ,4: &iagrama da )G< da !).".
!igura ,C: )G< da !)." com todos os comonentes soldados.
!igura 69: )G< da !)." ligada com o @bee, a !)." e a <?R.
3.2.2.2 P&0 dos .ervos
O circuito da PC dos servos, apesar de maior, mais simples do que o circuito da
PC anterior. Ele pode ser dividido em 2 partes, uma responsvel por enviar os sinais de
PWM provenientes da PC da FPGA para os motores e outra por fornecer a alimentao
para todos eles. O esquemtico completo pode ser visto na figura 41.
Os conectores BOARD-C0 e BOARD-C1 so exatamente os mesmos utilizados na
PC da FPGA, pois so os responsveis por conectar as duas placas e a configurao
dos seus pinos pode ser vista nas tabelas 4 e 5. Cada um dos sinais de PWM, um por
servo, enviado para um opto acoplador que tem como funo isolar a alimentao das
duas placas e mudar o nvel do PWM de 3.3V gerado pela FPGA para os 5.0V utilizados
pelos motores. O sinal de sada dos opto acopladores, alimentados na sada por uma das
linhas de 5V da fonte ATX que alimenta os motores, enviado para cada um dos 18
servos utilizados no hexpode.
!igura 6%: 8s2uemQtico do circuito da )G< dos servos.
Para reduzir a corrente das trilhas nessa placa de circuito foram utilizadas as quatro
conexes de 5.0V e as sete GND provenientes da fonte ATX. Na tabela 8 so
apresentados como foram distribudos os canais de alimentao para os motores e opto
acopladores utilizados na PC. Por fim, o circuito possui um LED ligado na pino Power Ok
indicando se a fonte est ligada e uma chave conectando o GND ao Power Supply On
para ligar a alimentao da fonte diretamente da PC dos servomotores.
Tabela 4: Gonfigura*Ho dos inos da !onte "T@ utili1ados na )G< dos #ervomotores
Alimentao [Pin] Funo
POW5/-3 GN do* Servo* 01 a 03
POW5/-4 5#0" do* Servo* 01 a 06
POW5/-6 5#0" 13li6ado no* Op3oa&opladore*
POW5/-8 Po7er O' &one&3ado ao $5 indi&ador da ali2en3a89o
POW5/-13 GN 13ili6ado no* Op3oa&opladore* e Po7er S1ppl: On
POW5/-14 Po7er S1ppl: On da ;on3e ),-
POW5/-19 5#0" do* Servo* 07 a 12
POW5/-20 5#0" do* Servo* 13 a 18
Apesar do circuito ser mais simples do que o utilizado na placa da FPGA, o
diagrama da placa foi bem mais trabalhoso pois foi necessrio realizar algum estudo
prvio e ajustar algumas configuraes da PC para suportar trilhas com corrente prxima
a 5.5A. O diagrama final do projeto da PC dos servos pode ser visto na figura 42. A placa
precisou ser projetada para encaixar na PC da FPGA sem gerar problema com os
conectores utilizados nos servomotores, atravs dos conectores no centro da placa. Outra
coisa que gerou um trabalho adicional foi o fato dessa placa necessitar de 4 furos para ser
encaixada na estrutura mecnica do hexpode.
Todos os componentes da placa precisaram ser ajustados para poder permitir as
trilhas largas (90mil) utilizadas na alimentao dos 5V, para fornecer energia para cada
par de patas (6 servos). Trilhas um pouco mais finas (40mil) foram utilizadas para as
linhas de terra (uma trilha para cada pata). Alm disso, a placa exigiu uma camada de
cobre mais densa (1.4oz) para suportar toda a corrente dos motores sem aquecer muito o
circuito. Para calcular a espessura e largura das trilhas para suportar a corrente de
operao foram utilizadas as ferramentas e as frmulas presentes em [84]. A figura 43
apresenta a PC dos servomotores antes de terem sido soldados os componentes e a
figura 44 a verso final da PC com todos os componentes e parafusada a estrutura
mecnica do hexpode.
!igura 6+: &iagrama da )G< dos servos.
!igura 6,: )G< dos servos sem os comonentes soldados.
!igura 66: WersHo final da )G< dos servos arafusada ao hexQode.
A$4$A Fone de #"6;en#23o
A fonte de alimentao escolhida para ser utilizada como alimentao dos
servomotores no projeto foi uma fonte genrica de computador do tipo ATX com potncia
mxima, em pico, de 450W. Como os dois tipos de servos utilizados no projeto, BMS-
620MG e Corona DS329, trabalham entre 4.8V e 6.0V
43,44
foi utilizado o canal de 5V da
fonte para fornecer a energia a eles.
Uma fonte do tipo ATX possu diversos tipos de conectores para alimentar os
diferentes dispositivos existentes dentro de um computador: placa-me, HD, leitor de
DVD, placa de vdeo, ventiladores, dentre outros. Entretanto, somente o conector
principal, que fornece a energia para a placa-me, foi utilizado no projeto, figura 45.
Existem 2 variaes desse tipo de conector: uma um conector Molex de 20 pinos e a
outra um conector Molex de 24 pinos. A principal diferena entre eles a simples adio
de algumas linhas adicionais de alimentao, entretanto, eles mantm uma
compatibilidade entre seus 20 pinos comuns, cuja configurao pode ser vista na tabela 9.
!igura 63: Gonector ?olex de +9 inos.
Por ser o conector com o maior nmero de linhas de 5V e GND, esse foi o conector
utilizado para fornecer a energia da fonte para o hexpode. Porm, como a extenso do
cabo que sai da fonte pequena, foi necessrio construir um cabo extensor para lig-lo
ao rob. Foi utilizado no projeto a linha de 5V (pinos 4, 6, 19 e 20), a linha do GND (pinos
3, 5, 7, 13, 15, 16, 17), o Power Ok (pino 8) e o Power Supply On (pino 14).
Os pinos de GND e 5V foram utilizados para alimentar os motores e os opto
acopladores, aos quais foram conectados os pinos de 5V em conjunto com um ou mais
pinos de GND (terra), de maneira a isolar a alimentao dentro da PC dos motores e
reduzir a corrente atuante em cada trilha da placa. Vale ressaltar que apesar das
diferentes linhas de GND e de 5V estarem isoladas na placa de alimentao, elas esto
conectadas dentro da fonte ATX. As conexes podem ser vistas com mais detalhes na
sesso da PC dos motores.
Alm das linhas de alimentao padro utilizadas nos motores foram utilizados os
pinos de Power Ok e Power Supply On. O primeiro serviu apenas para alimentar um LED
da placa dos motores para indicar que a fonte est ligada. O outro foi conectado a uma
chave para ligar ou desligar a alimentao da fonte, acionada quando o Power Supply On
est em nvel lgico baixo (0 V)
85
.
A alimentao da FPGA e dos sensores provem de uma outra fonte de
alimentao, que pode ser qualquer fonte DC com tenso entre 6V e 12V que consiga
fornecer ao menos 1A de corrente.
Tabela C: )inos de saPda do conector de +9 inos da fonte "T@.
!onte: Retirada de J43K
Pin No Name Colour Description
1 3.3V Orange +3.3 VDC
3 COMMON Black Gron!
" #V $e! +# VDC
# COMMON Black Gron!
6 #V $e! +# VDC
% COMMON Black Gron!
8 &'r(Ok Gra) &o'er Ok (+# VDC '*en +o'er ,s Ok)
9 +#V-B &r+le +# VDC -tan!.) Voltage
10 12V /ello' +12 VDC
12 012V Ble 012 VDC
1" &'r(ON Green &o'er -++l) On (act,1e lo')
1# COMMON Black Gron!
1% COMMON Black Gron!
18 0#V 2*,te 0# VDC
19 #V $e! +# VDC
20 #V $e! +# VDC
3.3 Monta$em do 1e/2pode
O processo de montagem do hexpode consistiu basicamente em integrar a
estrutura mecnica do rob (MSR-H01) aos motores, encaixar as PCs na parte superior e
fazer um cabo extensor para alimentao da fonte. Apesar do processo ser simples, ele
foi um pouco mais trabalhoso do que o esperado e alguns ajustes foram necessrios para
que tudo funcionasse de maneira adequada.
A primeira etapa desenvolvida foi a montagem da estrutura mecnica com os
motores utilizados seguindo o guia de montagem [86], fornecido pelo fabricante, da parte
mecnica do hexpode. Foram seguidos praticamente todos os passos descritos no guia,
exceto aqueles que envolviam o encaixe da placa de controle e bateria pois esses itens
no foram comprados e utilizados no projeto. Entretanto, apesar de possuir medidas
semelhantes ao Hitec HS-645MG utilizado no guia, foi necessrio limar cerca de um
milmetro as laterais das extremidades do BMS-620MG para que fosse possvel encaix-
lo entre as peas de nmero MSR-H01-ASSY01 e MSR-H01-ASSY02 conforme as etapas
3 e 4 descritas no guia. Alm disso foi necessrio perfurar a parte de plstico para
encaixar corretamente os motores na pea MSR-H01-FEMUR apresentada na etapa 6. O
motor Corona DS329MG no apresentou nenhuma dificuldade durante a montagem por
substituir o HS-225MG. A figura 46 apresenta as peas do Kit MSR-H01 aps realizado o
encaixe dos motores.
!igura 6>: )e*as do ?#R$D9% com alguns servos encaixados
Uma das etapas mais importantes durante a montagem do hexpode consiste em
centralizar todos os motores e encaix-los de modo que eles fiquem o mais alinhado
possvel e preferencialmente com o mesmo grau de liberdade dos dois lados. Entretanto
difcil garantir que todos os motores iro se manter na mesma posio durante o encaixe
das peas, por isso foi necessria uma calibragem individual dos motores aps o
processo de montagem. Para realizar este ajuste foi enviado um comando para centralizar
os motores e ajustado um offset na faixa de operao do bloco de PWM de cada um
deles. Com isso foi possvel garantir que, na posio central dos motores, a variao das
medidas entre eles fosse prxima a um milmetro no pior caso. A figura 47 mostra o kit
MSR-H01 aps a montagem completa das peas.
!igura 6B: 7it ?#R$D9% montado com todos os servos encaixados
Aps a montagem da estrutura mecnica as PCs foram soldadas e a placa dos
servos foi parafusada na parte superior do hexpode. Para isso foram aproveitadas as
peas MSR-P002 da etapa 9 do guia de montagem
86
, mas ao invs de parafusar na parte
de baixo elas foram encaixadas na parte superior do rob, pois as placas utilizadas no
projeto tinham dimenses que impossibilitaram coloc-las na parte de baixo. A placa de
alta potncia, utilizada para alimentar os servos, foi parafusada diretamente na estrutura e
a placa de controle contendo a FPGA foi encaixada nela. A MU com os sensores, o XBee
e a FPGA ento foram encaixados por cima da placa de controle concluindo a montagem
do hexpode. A figura 48 apresenta o hexpode aps terem sido encaixadas as duas
PCs, entretanto a PC com o Xbee e os sensores no tinha sido finalizada.
!igura 64: DexQode com as )G<s e com a !)." mas sem a )G< suerior ter sido
soldada.
O cabo de alimentao, cordo umbilical, do rob com comprimento igual a um
metro e meio foi elaborado tambm durante a etapa de montagem. Ao trabalhar com
baixa corrente e com um sinal de 5V, geralmente, no preciso se preocupar muito com a
resistncia e consequentemente com a queda de tenso gerada por fios com poucos
metros de comprimento. Entretanto, em um circuito com cabos de 1,5m onde podem
passar at 5A de corrente preciso se preocupar com a espessura dos cabos para evitar
uma queda de tenso indesejada. Para verificar a resistncia gerada de acordo com a
espessura dos cabos foi utilizada a tabela de condutores em [87].
Com isso foram utilizados cabos de 18 AWG para os sinais de terra e cabos duplos
de 18 AWG para a linha de 5V da fonte de alimentao. Como os motores trabalham de
4.8V a 6V e foram medidos 5.07V na sada da fonte, a queda de tenso no deve
ultrapassar 0.22V para manter um faixa de segurana de pelo menos 0.05V. Como cada
par de patas utiliza uma linha de 5V e cada pata uma linha de GND, conforme explicado
na seo "Fonte de alimentao", preciso calcular apenas a queda de tenso provocada
para um par de patas. O circuito resultante da resistncia dos fios do "cordo umbilical
em srie com as patas pode ser visto abaixo na figura 49.
!igura 6C: Gircuito com as resistXncias geradas elo -cordHo umbilical-.
Para calcular a tenso resultante em cada fio basta utilizar a Lei de Ohm e
substituir os valores pela resistncia gerada por cada cabo. A corrente mxima no cabo
utilizado na entrada de um par de pata de 5A e na sada de cada pata 2.5A. Portanto a
queda de tenso provocada por conta dos cabos de aproximadamente 0.16V,
subtraindo esse valor dos 5.07V fornecidos pela fonte possvel encontrar a tenso final,
de 4.9V, aplicada nos motores.
O cordo umbilical encerrou a etapa de montagem do Hexpode, processo que
acabou no apresentando nenhum tipo de problema grave apesar das modificaes
necessrias. Uma viso da verso final do hexpode pode ser vista na figura 50.
!igura 39: DexQode comleto.
3." Protocolos de comunicao
Os mecanismos de comunicao entre o rob e o driver de estao base e
comunicao entre o driver e o cliente de comando so baseados na troca de
mensagens, como comumente utilizado em sistemas distribudos
88
. Denomina-se de
"protocolo de baixo nvel o sistema de troca de mensagens construdo sobre os canais de
comunicao.
A comunicao entre o rob e a estao base ocorre atravs de um canal serial
ZigBee, enquanto a comunicao entre a estao base e o cliente de comando do rob
ocorre atravs de soc(ets TCP. O sistema de troca de mensagens foi projetado e
implementado sobre um fluxo de dados genrico, que pode representar tanto um canal de
UART quanto um soc(et. A vantagem dessa implementao genrica que o mesmo
cdigo pode ser utilizado em ambos os casos, reduzindo a complexidade total do
software. Outro lado positivo de tal design que, em verso futuras do sistema, o mesmo
protocolo poderia ser utilizado sobre canais diferentes de comunicao como, por
exemplo, soc(ets UDP.
Os protocolos de alto nvel so construdos sobre o protocolo de baixo nvel. Cada
um dos protocolos de alto nvel suporta alguns tipos de mensagens. H um protocolo
entre o rob e o driver e outro entre o driver e o cliente de comando. Em ambos os casos,
eles foram elaborados para incluir trs tipos fundamentais de mensagens: instruir o rob a
realizar um certo movimento, obter as leituras dos sensores do rob e notificar que um
movimento foi terminado.
A$:$0 P!oo(o"o de b#6xo n8%e"
O protocolo de baixo nvel baseado no conceito de mensagens, que so pacotes
indivisveis de dados que transmitem algum tipo de informao
88
. Cada mensagem tem
um tipo, um identificador nico e um corpo. O tipo de uma mensagem define que tipo de
informao carregada em seu corpo e de que forma ela est representada, enquanto o
identificador um nmero que identifica unicamente a mensagem. necessrio que
ambos os lados da comunicao utilizem intervalos distintos para gerao de seus
identificadores, de forma a evitar colises.
3.".1.1 Mensa$ens
Apesar de ambos os canais utilizados (ZigBee e TCP) terem mecanismos prprios
de verificao e validao dos dados, que so transparentes para o programador
89,90
,
experimentos mostraram que h perda ocasional de bytes no canal ZigBee. Assim sendo,
foi necessrio adotar um mecanismo prprio de verificao e validao dos dados, de
forma que uma mensagem incompleta seja identificada como invlida e descartada. A
opo adotada foi empregar dois chec(sums simples e um terceiro valor para verificar
consistncia, todos enviados como parte da mensagem. Um dos chec(sums envolve a
soma de todos os bytes do cabealho, enquanto o outro envolve a soma de todos os
bytes do corpo da mensagem. O terceiro valor o resultado de uma operao de ou-
exclusivo entre os dois chec(sums, para garantir que o cabealho esteja consistente.
O formato de cada mensagem apresentado na figura 51. A magic word tem quatro
bytes e usada para identificar o comeo de uma mensagem. Segue o cabealho, que
apresenta o tipo da mensagem, seu identificador, seu tamanho e os trs campos de
verificao (chec(sums e o campo de ou-exclusivo), todos com dois bytes de tamanho.
Aps todo o cabealho, enviado o corpo da mensagem, que tem o nmero de bytes
indicado no tamanho. O corpo da mensagem a parte que carrega de fato a informao.
A "magic word configurvel, e definida na especificao de cada protocolo de alto
nvel.
!igura 3%: !ormato de uma mensagem do rotocolo de baixo nPvel.
O envio de bytes pelo fluxo de dados feito de forma bloqueante, mas o
recebimento feito de forma bloqueante com timeout. Desta forma, evitam-se problemas
decorrentes de perda de bytes ou desligamento inesperado de um dos entes
comunicantes, tornando o sistema mais tolerante a falhas e, portanto, mais robusto.
3.".1.2 &ontrole de flu/o
Junto ao sistema de envio de mensagens construdo um sistema de controle de
fluxo que gerencia requisies e respostas. Para cada mensagem de requisio enviada,
espera-se receber uma resposta, que confirma o recebimento pelo outro lado da
comunicao. O sistema de controle de fluxo assncrono, envolvendo o disparo de
eventos ao recebimento de requisies e respostas, ou quando a resposta a uma
mensagem no recebida dentro do tempo esperado.
Estabeleceu-se uma conveno para o controle de fluxo: cada mensagem de
resposta deve ter o mesmo identificador da requisio correspondente, mas um tipo
diferente. Ainda convencionou-se que mensagens cujos tipos so nmeros pares so de
requisio e mensagens cujos tipos so nmeros mpares so de resposta.
Quando perdido um byte na comunicao possvel que o prprio cabealho da
mensagem tenha sido corrompido, ento preciso descartar a mensagem inteira. Como o
cabealho pode ter sido corrompido, o tamanho da mensagem desconhecido, j que tal
informao carregada no cabealho. Ainda assim, preciso garantir que sejam
descartados apenas os bytes daquela mensagem, recebendo com sucesso a mensagem
seguinte. S possvel estabelecer tal compromisso se forem utilizadas temporizaes
consistentes tanto para os tempos limite de transmisso de bytes quanto para os de
0 3 4 5 6 7 8 9 10 11
Magic word Tipo D Tamanho
Checksum
Cabealho
12 13 14 15 16 16 + tamanho
Checksum
XOR
Checksum
Corpo
Corpo
espera por respostas. Tais temporizaes so condicionadas latncia e velocidade do
meio de transmisso sobre o qual o protocolo for utilizado, ento cada protocolo de alto
nvel define temporizaes prprias.
A$:$4 P!oo(o"o& de #"o n8%e"
Em ambos os protocolos de alto nvel, as principais funes das mensagens so
enviar comandos para o rob, ler seus sensores e notificar fim de movimento. A maneira
que so feitos o envio de comandos e a leitura de sensores foi concebida de forma a
permitir a incluso de novas aes e sensores a uma futura verso do rob, sem
necessitar uma alterao no protocolo. Ento, em ambos os casos, as respostas s
requisies podem indicar que a operao foi realizada com sucesso ou que o
comando/sensor requisitado no suportado.
As aes que o rob capaz de realizar so denominadas "movimentos. Cada
movimento tem um tipo e deve receber um certo nmero de parmetros, que caracterizam
como ele ser realizado. O tipo um nmero inteiro de 2 bytes (16 bits), de forma que o
rob pode suportar pouco mais de 65 mil movimentos distintos. Existe ainda um campo do
movimento que definido no alto nvel, o "identificador da ao. Esse identificador no
tem utilidade nenhuma para o rob em si, e no deve afetar de forma alguma o
movimento. Sua nica funo facilitar a identificao de qual ao foi terminada quando
uma notificao recebida. O identificador um nmero inteiro de 4 bytes (32 bits),
podendo assumir mais de 4 bilhes de valores possveis. A lista de movimentos que o
rob pode realizar e seus respectivos parmetros pode ser encontrada no apndice A.
Cada movimento tem um "tamanho e um "valor, responsvel por indicar quanto do
movimento j foi realizado. O tamanho do movimento geralmente determinado pelos
parmetros que ele recebe. Por exemplo, em um movimento de andar em frente o
tamanho o nmero total de passos e o valor o nmero de passos andados at certo
instante. O comportamento esperado que o valor seja inicialmente zero e que se
aproxime do tamanho medida que o movimento vai sendo realizado. Quando o
movimento terminar com sucesso, espera-se que seu valor seja igual ao seu tamanho.
Cada sensor ligado ao rob tem um identificador, denominado "tipo. O tipo de
sensor um nmero inteiro de 16 bits, de forma que o protocolo permite a leitura de at
65 mil tipos diferentes de sensores. A lista de sensores suportados pelo rob e o formato
das respectivas leituras pode ser encontrada no apndice B.
3.".2.1 Protocolo entre rob3 e driver
Como ocasional a perda de bytes no canal de comunicao entre o rob e o
driver, o protocolo de alto nvel utilizado neste meio foi elaborado de forma a evitar
resultados indesejados em caso de mensagens serem retransmitidas. As mensagens
deste protocolo de alto nvel foram concebidas para realizarem operaes simples.
Escolheu-se 0x000FF0FF (1044735 em decimal) como magic word deste protocolo, cujas
mensagens devem seguir o formato apresentado na figura 52.
0 3 4 5 6 7 8 9 10 11
M#76( /o!d
0x000FF0FF
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
Tipo Tamanho
16 16 + tamanho
Corpo
!igura 3+: !ormato geral de mensagens do rotocolo entre o robI e o driver.
As caractersticas do canal serial entre o rob e o driver so: baud rate de 57600,
um sto bit e sem paridade. O tempo limite para recebimento de cada byte de uma
mensagem foi definido em 4 milissegundos, e o limite para recebimento da resposta a
uma requisio, em 128 milissegundos. Para evitar que atrasos no tratamento das
mensagens dificultem a comunicao, esses valores foram definidos bastante acima do
valor limite - idealmente, a transmisso pode atingir mais de 5 kB/s a 57600 bauds/s.
Nesta seo, apresenta-se uma viso geral do protocolo, enquanto a documentao
detalhada de todas as mensagens deste protocolo e seus respectivos parmetros pode
ser encontrada no apndice C.
Neste protocolo, a operao de comandar o rob a realizar alguma ao dividida
em duas etapas. Primeiramente, define-se qual o movimento seguinte e em seguida,
determina-se que o rob deve comear a execut-lo. Quando o movimento do rob
iniciado o campo interno que armazena a ao seguinte limpo. Esta forma foi escolhida,
em detrimento de usar uma nica mensagem de "movimentar, por garantir que o mesmo
movimento no iniciado duas vezes em caso de retransmisso, pois a mensagem de
iniciar movimento no tem efeito quando no h ao seguinte.
A mensagem de definir movimento tem tipo 0x0022, e seu corpo inclui o tipo de
ao, seu identificador e seus parmetros. Seu formato pode ser visualizado na figura 53.
Se o movimento for suportado, a mensagem de resposta tem tipo 0x0023, do contrrio,
tem tipo 0x0021. O corpo da resposta vazio em ambos os casos. A mensagem de iniciar
movimento tem tipo 0x0024 e no recebe parmetros.
0 3 4 5 6 7 8 9 10 11
M#76( /o!d
0x000FF0FF
T6po
0x0022
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
18 21
dentificador
de movimento
16 17
Tipo de
movimento
22 16 + tamanho
Par:metros do
movimento
Tamanho
!igura 3,: !ormato da mensagem de definir movimento ara o robI.
A mensagem de leitura dos sensores recebe como parmetro um cdigo
identificador do sensor. Caso o sensor no seja suportado, a resposta a essa mensagem
vazia. Do contrrio, os dados lidos do sensor so enviados no corpo da mensagem de
resposta. A requisio de leitura de sensores tem tipo 0x0040 e segue o formato
apresentado na figura 54. A leitura do sensor retornada na mensagem de resposta no
necessariamente realizada no momento em que a resposta foi enviada, ela pode ter
ocorrido em at um segundo antes.
0 3 4 5 6 7 8 9 10 11
M#76( /o!d
0x000FF0FF
T6po
0x0040
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
16 17
Tipo de
sensor
T#;#n)o
0x0002
!igura 36: !ormato da mensagem de ler sensor ara o robI.
O rob pode enviar para o driver mensagens de notificao, indicando que um
movimento foi terminado com sucesso ou que foi abortado. O movimento abortado
quando uma mensagem de parada enviada para o rob enquanto ele estiver realizando
um movimento. A notificao de movimento terminado retorna, tambm, o tamanho do
movimento. A notificao de movimento abortado indica o valor do movimento no instante
em que foi interrompido. O formato dessas mensagens de notificao apresentado nas
figuras 55 e 56.
0 3 4 5 6 7 8 9 10 11
M#76( /o!d
0x000FF0FF
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
16 19
T6po
0x0102
dentificador
de movimento
20 23
Nmero total de iteraes
do movimento
T#;#n)o
0x0008
!igura 33: !ormato da mensagem de movimento terminado com sucesso.
0 3 4 5 6 7 8 9 10 11
M#76( /o!d
0x000FF0FF
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
16 19
T6po
0x0104
dentificador
de movimento
20 23
Nmero de iteraes
do movimento
T#;#n)o
0x000C
24 27
do movimento
!igura 3>: !ormato da mensagem de movimento abortado.
3.".2.2 Protocolo entre cliente e driver
Como o canal TCP garante a transmisso de todos os dados de uma ponta a outra,
o protocolo de alto nvel entre o cliente e o driver no requer o mesmo cuidado com a
perda de bytes, mas, em contrapartida, requer um cuidado maior com latncia na
transmisso. Dessa forma, os tempos limite de recebimento de bytes e de respostas
neste protocolo so maiores do que os tempos limite no protocolo entre o driver o rob. O
tempo limite para recebimento de um byte de 500 ms e o tempo limite de recebimento
de respostas a mensagens varia entre 1,5 a 5 segundos, dependendo do tipo de
mensagem. Essas temporizaes so possivelmente exageradas, j que a latncia em
redes locais (LANs) geralmente no passa de 10 ms e em rede pblica (internet) oscilam
entre 100 ms e 500 ms
91
. A porta na qual o driver espera por conexes 0xEDDA (60890
em decimal).
A magic word do protocolo entre cliente e driver 0x00BA0BAA (12192682 em
decimal). Nesta seo, apresenta-se uma viso geral do protocolo, enquanto a
documentao detalhada de todas as mensagens deste protocolo e seus respectivos
parmetros pode ser encontrada no anexo D.
O driver inicialmente no est conectado ao rob, ento preciso enviar-lhe um
comando para conecta-lo. Existem duas mensagens associadas a esta operao, uma
cuja funo retornar a lista de portas (seriais) disponveis no computador no qual o
driver executado, e outra cuja funo comandar o estabelecimento da conexo com o
rob atravs de alguma porta. A mensagem de enumerar a portas tem cdigo 0x8000,
com o corpo vazio. A resposta a esta mensagem tem o formato apresentado na figura 57.
Seu corpo a lista de nomes das portas, separadas por carcter "newline (0x0a), e
codificadas usando charset ASC. A mensagem de abrir conexo com o rob atravs de
uma porta tem cdigo 0x8002 e seu formato apresentado na figura 58. O corpo da
resposta a esta mensagem um byte com um cdigo indicando o resultado da operao
de abertura.
0 3 4 5 6 7 8 9 10 11
M#76( /o!d
0x00BA0BAA
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
T6po
0x8001
Tamanho
16 16 + tamanho
Lista de portas
separadas por `\n`
!igura 3B: !ormato da mensagem de enumerar ortas do cliente.
0 3 4 5 6 7 8 9 10 11
M#76( /o!d
0x00BA0BAA
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
T6po
0x8002
Tamanho
16 16 + tamanho
Nome da porta
!igura 34: !ormato da mensagem de abrir orta do cliente.
Uma vez que a conexo com o rob esteja aberta passa a ser possvel enviar
comandos para o rob. No possvel fechar a conexo com o rob sem fechar a
conexo com o driver. A operao de comandar o rob a realizar alguma ao,
diferentemente do que acontece no protocolo entre o driver e o rob, no dividida em
duas etapas. O driver recebe o comando de movimentar em uma nica etapa, e faz a
negociao em duas etapas com o rob. O formato da mensagem associada a essa
operao o mesmo da requisio de definir movimento no protocolo entre o driver e o
rob, mas tem cdigo 0x8080, tal qual apresentado na figura 59. A resposta desta
requisio tem cdigo 0x8081 e seu corpo contm um cdigo indicando o resultado da
operao.
0 3 4 5 6 7 8 9 10 11
M#76( /o!d
0x00BA0BAA
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
T6po
0x8080
Tamanho
18 21
dentificador
de movimento
16 17
Tipo de
movimento
22 16 + tamanho
Par:metros do
movimento
!igura 3C: !ormato da mensagem de movimentar do cliente.
Da mesma forma, a mensagem de leitura de sensores tambm tem formato
semelhante utilizada no protocolo entre o rob e o driver, mas com cdigo 0x80C0. A
resposta, ao contrrio do que acontece no outro protocolo, inclui um cdigo indicando o
resultado da operao. O formato da mensagem de requisio apresentado na figura
60.
0 3 4 5 6 7 8 9 10 11
T6po
0x80C0
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
16 17
Tipo de
sensor
T#;#n)o
0x0002
M#76( /o!d
0x00BA0BAA
!igura >9: !ormato da mensagem de ler sensor do cliente.
As notificaes enviadas pelo driver ao cliente tambm seguem um formato
semelhante s utilizadas no protocolo entre o rob e o driver, mudando apenas seus
identificadores. Ambas esto representadas nas figuras 61 e 62.
0 3 4 5 6 7 8 9 10 11
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
16 19
T6po
0xC102
dentificador
de movimento
20 23
do movimento
T#;#n)o
0x0008
M#76( /o!d
0x00BA0BAA
!igura >%: !ormato da mensagem de movimento terminado com sucesso.
0 3 4 5 6 7 8 9 10 11
D
Checksum
Cabealho
12 13 14 15
Checksum
XOR
Checksum
Corpo
16 19
T6po
0xC104
dentificador
de movimento
20 23
Nmero de iteraes
do movimento
T#;#n)o
0x000C
24 27
do movimento
M#76( /o!d
0x00BA0BAA
!igura >+: !ormato da mensagem de movimento abortado.
3.% .oft*are
H trs artefatos de software principais do projeto: o firmware, isto , o software
embarcado, o software do driver de comunicao com o rob e a biblioteca de
comunicao com o driver. Alm disso, foi criado um quarto software com uma interface
grfica de exemplo, que utiliza a biblioteca de comunicao. Todo o cdigo foi
desenvolvido utilizando orientao a objetos e de forma modular, para reduzir o esforo
necessrio se futuramente houver o interesse de incluir novas funcionalidades. O
firmware foi desenvolvido em linguagem C++, enquanto o driver de comunicao com o
rob, a biblioteca e o software de interface grfica foram desenvolvidos em linguagem
Java, verso 6 ou superior.
A$<$0 P!o5eo de &o9/#!e de 6ne!9#(e 7!96(#
3.%.1.1 Requisitos funcionais
SWRF1. O software dever comunicar-se com o rob atravs da biblioteca de
comunicao.
SWRF2. O software devera permitir que o usurio transmita comandos de locomoo
ao rob.
SWRF3. O software dever exibir, quando possvel, informaes dos sensores do
rob.
3.%.1.2 Requisitos no-funcionais
SWRNF1. O software dever ser utilizado atravs de mouse e teclado
SWRNF2. O software dever ter partes de seu cdigo-fonte, quando cabvel,
distribudas sob licena BSD.
SWRNF3. O software da interface grfica dever ser executado em computadores
com no mnimo sistema operacional Windows XP.
SWRNF4. O software no precisa contemplar todos os comandos que o rob pode
executar.
3.%.1.3 &asos de uso
O software de interface grfica inclui dois atores: o prprio software e o usurio. O
rob no foi incluso pois no interage diretamente com nenhum dos demais atores. H
apenas dois casos de uso do software de interface, referentes s aes de enviar um
comando para o rob e ler seus sensores. O diagrama de casos de uso apresentado na
figura 63.
U&1!6o So9/#!e
Obe! "e61!#&
do& &en&o!e&
En%6#! (o;#ndo& #o !ob
!igura >,: &iagrama de casos de uso.
A$<$0$A$0 En%6#! (o;#ndo& #o !ob
O caso de uso "enviar comandos ao rob referente transmisso de comandos
ao rob, atravs do software. O caso de uso inclui a espera pelo trmino do movimento ou
sua parada precoce pelo usurio.
Atores:
Usurio.
Software.
Fluxo de eventos:
Fluxo bsico:
1. Usurio seleciona uma aba na tela principal, associada ao comando.
2. Usurio digita, se necessrio, parmetros do comando.
3. Usurio pressiona o boto de iniciar movimento.
4. O software tenta enviar o comando atravs da biblioteca, se os parmetros
forem vlidos,
5. O software exibe uma mensagem indicando que o movimento iniciou, se a
biblioteca responder indicando com sucesso.
6. O software retorna tela principal, assim que a biblioteca enviar notificao
de movimento terminado.
Fluxo alternativo:
forem vlidos,
5. O software exibe uma mensagem indicando que o movimento iniciou, se a
biblioteca responder indicando com sucesso.
6. Usurio pressiona o boto de parar movimento.
7. O software retorna tela principal, assim que a biblioteca enviar notificao
de movimento abortado.
Fluxo alternativo
4. O software no faz nada, se os parmetros forem invlidos.
Fluxo alternativo
forem vlidos,
5. O software exibe uma mensagem indicando que o movimento no iniciou, se
a biblioteca responder indicando falha.
Pr-condies:
O software est em execuo.
A biblioteca de comunicao do software est conectada a um driver, que j
abriu a conexo com um rob.
Ps-condies
Rob executa a ao desejada, ou a ao no executada por algum motivo.
A$<$0$A$4 Obe! "e61!#& do& &en&o!e&
O caso de uso "obter leituras dos sensores referente obteno das leituras de
um ou mais sensores do rob, atravs do software.
Atores:
Usurio.
Software.
Fluxo de eventos:
Fluxo bsico
1. Usurio pressiona o boto de atualizar leitura de um dos sensores, na tela
principal.
2. Os dados exibidos so atualizados, se a biblioteca responder indicando
sucesso..
Fluxo alternativo:
1. Usurio pressiona o boto de atualizar leitura de um dos sensores, na tela
principal.
2. Os dados exibidos no so atualizados, se a biblioteca responder indicando
falha..
Pr condies
O software est em execuo.
A biblioteca de comunicao do software est conectada a um driver, que j
abriu a conexo com um rob.
Ps condies
Os dados sobre o sensor na tela so atualizados.
A$<$4 De#")e& d# 6;p"e;en#23o e; CRR
3.%.2.1 -locao de mem#ria
Os artefatos de software desenvolvidos em linguagens C++ e Java foram
elaborados de forma a preservarem grande grau de similaridade mtua. Assim sendo, o
cdigo em linguagem C++ naturalmente empregaria alocao dinmica de memria,
como ocorre no software desenvolvido em Java. Entretanto o software em C++
embarcado e em sistemas deste tipo evita-se utilizar alocao dinmica
56
. Entretanto,
para preservar a consistncia entre as duas implementaes do software, adotou-se o
paradigma de "object pooling.
O sistema de object pooling utilizado no software em C++ de autoria prpria.
Nele, as pools de objetos so implementadas como listas encadeadas. De forma ao
object pooling ser totalmente transparente para o programador, considerou-se a
possibilidade de sobrescrever os operadores "new e "delete, mas esta opo foi
descartada pois pode gerar uma srie de complicaes
92
. Assim, adotou-se uma
conveno prpria para diferenciar a obteno e insero de objetos em uma pool da
criao e do apagamento de objetos. A conveno envolve o emprego de um mtodo
esttico denominado "create em cada classe, para obter instncias a partir da pool, e
outro mtodo denominado "finalize para devolv-las pool. A conveno de empregar
um mtodo esttico denominado "create em lugar do construtor foi utilizado tambm no
software Java, para preservar a similaridade entre as duas partes do software. As pools
de objetos, no cdigo C++, esto implementadas na classe genrica
"ObjectPool<Count,Type> (na qual "Count o total de objetos e "Type a classe dos
objetos) .
3.%.2.2 ,er4ncia de mem#ria
A linguagem C++ no-gerenciada e permite emprego de alocao dinmica de
memria, ento programas desenvolvidos nela podem apresentar problemas quanto a
vazamentos de memria e dangling ointers. Para evitar tais problemas, e preservar a
similaridade com o software desenvolvido em Java, empregou-se no software em C++ um
sistema automtico de gerenciamento de memria.
No software desenvolvido em C++ optou-se por empregar contagem de referncias.
Nele, h duas classes: "StrongReference<T> e "WeakReference<T> (utilizadas atravs
das macros "_strong(T) e "_weak(T)), que implementam, respectivamente, referncias
fortes e fracas a objetos. H ainda uma classe denominada "ControlBlock, que
representa o "bloco de controle de um objeto, que contm seu contador de referncias.
Como se utilizou um mecanismo automtico de gerncia de memria, nenhum objeto
apagado diretamente a partir do cdigo de alto nvel, o que acaba por ser mais um ponto
de similaridade entre o software em C++ e o em Java.
Para evitar referncias circulares, em alguns locais do cdigo C++ utilizaram-se
referncias fracas. Para preservar a similaridade entre as implementaes, os trechos de
cdigo que empregam referncias fracas em C++ tambm o fazem em Java. Nota-se,
entretanto, que no realmente necessrio utilizar referncias fracas para essa finalidade
no cdigo em Java, pois o garbage collector da JVM capaz de detectar e tratar
referncias circulares.
A$<$A CPd67o de b#6xo n8%e"
O cdigo de alto nvel responsvel pelo controle do rob, comunicao, entre
outros. Como h quatro artefatos de software, em mais de uma plataforma, buscou-se
desenvolver o cdigo de alto nvel de forma independente da arquitetura. Como
consequncia, diversas partes do cdigo foram programadas uma nica vez, mas
utilizadas em mais de uma verso do software. De forma a tornar este procedimento
possvel, foi preciso que houvesse uma forma portvel de realizar operaes de baixo
nvel, como criao de threads, operaes com semforos, entre outras. Com esta
finalidade, foi criada uma biblioteca de baixo nvel orientada a objetos. Apesar de tal
biblioteca ter uma implementao diferente em cada plataforma, sua especificao
nica.
Na biblioteca de baixo nvel, por possuir chamadas bloqueantes, contribui para que
ocorram situaes de deadloc( ou de espera indeterminada. Para evitar tais problemas,
as chamadas da biblioteca de baixo nvel, quando conveniente, so no-bloqueantes ou
bloqueantes com timeout. Um diagrama completo com todas as classes de baixo nvel
apresentado na figura 64.
+ clear() : void
Me#SRe9e!en(e
+ down(miliseconds : int) : boolean
+ down() : boolean
+ up() : void
+ getCount() : int
+ getMaximum() : int
+ create(count : int, maximum : int) : Semaphore
Se;#p)o!e
+ enqueue(job : ThreadBody) : void
+ create() : JobQueue
Tob>1e1e
Y writeLbuffer : byteJK, offset : int, length : intM : int
Y readLbuffer : byteJK, offset : int, length : intM : int
Y getTimeoutsLtimeouts : TimeoutsM : void
Y setTimeoutsLtimeouts : TimeoutsM : bool
Y is=enLM : bool
Y closeLM : bool
Y oenLM : bool
.tream
+ close() : void
+ accept(milliseconds : long) : TCPSocketStream
+ accept() : TCPSocketStream
+ create(port : int) : TCPServerSocket
TCPSe!%e!So(Se
+ write(buffer : byte[], offset : int, length : int) : int
+ read(buffer : byte[], offset : int, length : int) : int
+ getTimeouts(timeouts : Timeouts) : void
+ setTimeouts(timeouts : Timeouts) : bool
+ isOpen() : bool
+ close() : bool
+ open() : bool
+ create(port : String, baudRate : int, bitRate : int, stopBits : SerialPortStopBits, parity : SerialPortParity) : SerialPortStream
Se!6#"Po!S!e#;
+ getMilliseconds() : long
+ reset() : void
+ create() : Stoptimer
Sop6;e!
Y runLM : void
51read6od7
+ sleep(miliseconds : long) : void
+ join(miliseconds : int) : void
+ join() : void
+ run() : void
+ start() : void
+ setPriority(priority : ThreadPriority) : void
+ create(body : ThreadBody) : void
T)!e#d
+ write(buffer : byte[], offset : int, length : int) : int
+ read(buffer : byte[], offset : int, length : int) : int
+ getTimeouts(timeouts : Timeouts) : void
+ setTimeouts(timeouts : Timeouts) : bool
+ isOpen() : bool
+ close() : bool
+ open() : bool
+ open(host : String, port : int) : TCPSocketStream
TCPSo(SeS!e#;
+ STOPBTS_TWO : SerialPortStopBits
+ STOPBTS_ONE_DOT_FVE : SerialPortStopBits
+ STOPBTS_ONE : SerialPortStopBits
<<enum>>
Se!6#"Po!SopB6&
+ PARTY_ODD : SerialPortParity
+ PARTY_EVEN : SerialPortParity
+ PARTY_NONE : SerialPortParity
<<enum>>
Se!6#"Po!P#!6,
+ HighThreadPriority : ThreadPriority
+ RegularThreadPriority : ThreadPriority
+ LowThreadPriority : ThreadPriority
<<enum>>
T)!e#dP!6o!6,
Ob5e(
!igura >6: &iagrama de classes de baixo nPvel.
As classes de baixo nvel so divididas em trs pacotes (namespaces em C++):
"base, "stream e "concurrent. O pacote "base contm a classe "=bject, a qual todos os
objetos estendem. No cdigo em C++, as classes que representam referncias fracas e
ools de objetos tambm so parte do namesace "base; tais classes no aparecem no
diagrama de classes, pois so especficas da verso C++. J os pacotes "stream e
"concurrent contm, respectivamente, classes referentes a fluxos de dados (UART e
sockets) e referentes a operaes concorrentes, como semforos, threads,
temporizadores, entre outros.
A biblioteca foi implementada em Java e em C++. Na AP da linguagem Java,
existem algumas classes equivalentes ou muito semelhantes s definidas na biblioteca de
baixo nvel; neste caso, foram utilizadas as classes da AP em detrimento das da
biblioteca. A implementao em C++ foi feita para duas plataformas: primeiramente, foi
feita para Windows XP em arquitetura x86, o que foi utilizado apenas para
desenvolvimento, e depois foi feita para MicroC/OS- sobre processador NOS , o que
utilizado no firmware.
A interao entre a biblioteca de baixo nvel do cdigo Java e a porta serial feito
atravs da biblioteca "nrjavaserial, liberada sob licena LGPL
93
. A nrjavaserial um fork
da biblioteca RxTx, com a qual os membros da equipe j tinham familiaridade ao comeo
do projeto
11,25
. Em C++, usado para interagir com a UART Avalon um driver desenvolvido
pela prpria Altera.
A$<$: CPd67o de #"o n8%e"
A implementao das classes de alto nvel independente de plataforma, exceto as
classes que realizam movimentao e leitura de sensores no firmware. Assim, via de
regra, as operaes de baixo nvel utilizadas so apenas aquelas implementadas pelas
classes de baixo nvel.
Algumas classes de alto nvel foram projetadas para suas instncias enviarem
notificaes para outros objetos quando detectam algum evento que requer tratamento.
Um exemplo de situao em que isto til: um objeto representando um canal de
comunicao recebe uma mensagem, e envia uma notificao para outro objeto, que a
recebe trata a mensagem recebida. O paradigma adotado para implementar esta
mecnica foi a utilizao de callbacks. Esse paradigma envolve o uso de classes
abstratas ou interfaces que definem mtodos denominados "callbacks, os quais so
invocados toda a vez que houver uma nova notificao. possvel que qualquer classe
estenda as clases abstratas ou implemente as interfaces que definem os callbacks, de
forma que objetos projetados de forma independente possam registrar-se para receber
notificaes.
3.%.".1 Protocolo
As classes do protocolo de comunicao so utilizadas nos trs artefatos de
software e implementam todas as operaes associadas ao envio e ao recebimento de
mensagens atravs de um fluxo de dados. Essas operaes so referentes apenas ao
protocolo de baixo nvel, isto , ao mecanismo de requisio-resposta. O protocolo de alto
nvel implementado diferentemente em cada um dos artefatos de software. O diagrama
com as classes de protocolo pode ser visualizado na figura 65.
+ setByte(i : int, b : int) : void
+ getByte(i : int) : int
+ setd(id : int) : void
+ getBuffer() : byte[]
+ getLength() : int
+ getd() : int
+ getType() : int
+ create(type : int, length : int) : Message
Me&&#7e
# receive() : void
+ setClosedCallback(handler : ChannelClosedCallback) : void
+ getClosedCallback() : ChannelClosedCallback
+ setMessageCallback(callback : ChannelMessageCallback) : void
+ getMessageCallback() : ChannelMessageCallback
+ join() : void
+ isRunning() : boolean
+ stop() : void
+ start() : void
+ send(message : Message) : void
+ create(stream : Stream, magicWord : int, long byteTimeout : int) : Channel
C)#nne"
Y onGhannelGlosedLmessage : GhannelM : void
&1annel&losed&allbac8
Y on?essageLmessage : ?essageM : void
&1annelMessa$e&allbac8
+ sendReply(message : Message) : void
+ create(id : int, channel : Channel) : FlowReplier
F"o/Rep"6e!
Y onRelyLre2uest : ?essage, rely : ?essage, error : intM : void
Messa$eRepl7&allbac8
Y onRe2uestLre2uest : ?essage, relier : !lowRelierM : void
Messa$eRequest&allbac8
Y on!lowGlosedLflow : !lowM : void
+lo*&losed&allbac8
# receive() : void
+ onChannelClosed(channel : Channel) : void
+ onMessage(message : Message) : void
+ getClosedHandler() : FlowClosedCallback
+ setClosedHandler(handler : FlowClosedCallback) : void
+ getRequestCallback() : MessageRequestCallback
+ setRequestCallback(callback : MessageRequestCallback) : void
+ isOpen() : boolean
+ stop() : void
+ start() : void
+ send(message : Message, callback : MessageReplyCallback, timeout : long) : void
+ create(channel : Channel, minimalTimeout : long) : Flow
F"o/
0..1
0..1
0..*
1
1
1
Y writeLbuffer : byteJK, offset : int, length : intM : int
Y readLbuffer : byteJK, offset : int, length : intM : int
Y getTimeoutsLtimeouts : TimeoutsM : void
Y setTimeoutsLtimeouts : TimeoutsM : bool
Y is=enLM : bool
Y closeLM : bool
Y oenLM : bool
.tream
1 1
1
0..*
1
+ run() : void
+ create(channel : Channel) : ChannelThreadBody
C)#nne"T)!e#dBod,
1
1
+ run() : void
+ create(flow : Flow) : FlowThreadBody
F"o/T)!e#dBod,
1
1
!igura >3: &iagrama de classes de rotocolo.
Todas as classes do protocolo de comunicao encontram-se no pacote
(namespace em C++) "protocol. H trs classes principais neste pacote: "Message,
"Channel e "Flow. A classe "Message representa uma mensagem qualquer transmitida
atravs do protocolo e tem trs propriedades principais: o identificador, o tipo e o corpo. A
classe "Channel representa um canal de troca de mensagens construdo sobre um fluxo
de dados. Essa classe responsavel por enviar e receber mensagens. A classe "Flow
representa um fluxo de troca de mensagens construdo sobre um canal. Essa classe
responsvel por fazer matching de requisies e respostas e verificar que requisies
sofreram timeout. Em ambos os casos, as classes operam de forma assncrona, ento
tanto a classe "Channel quanto a classe "Flow disparam notificaes atravs de
mtodos callback.
3.%.".2 +irm*are
O firmware executado sobre um processador NOS com sistema operacional
MicroC/OS-, e a linguagem de programao utilizada para desenvolv-lo foi C++. O fato
de as classes de alto nvel serem quase inteiramente independentes da plataforma
possibilitou que grande parte do firmware fosse desenvolvida em uma outra plataforma na
qual o desenvolvimento fosse mais cmodo. As classes de baixo nvel foram
implementadas para ambiente Windows XP sobre processador x86, plataforma na qual foi
desenvolvido o firmware. Assim que o cdigo atingiu um certo grau de maturidade,
implementaram-se as classes de baixo nvel para MicroC/OS- sobre processador NOS
. Na verso definitiva do firmware, h algumas operaes de baixo nvel que so
realizadas diretamente nas classes de alto nvel, como leitura de sensores e definir
setpoints das patas. O diagrama de classes do firmware pode ser visualizado na figura 66.
+ setSensorsManager(value : SensorsManager) : void
+ getSensorsManager() : SensorsManager
+ setUartManager(value : UartManager) : void
+ getUartManager() : UartManager
+ setMovementManager(value : MovementManager) : void
+ getMovementManager() : MovementManager
+ create() : RobotManager
# m_sensors : SensorsManager
# m_uart : UartManager
# m_movement : MovementManager
- m_pool : ObjectPool<Class, Count>
RoboM#n#7e!
# onUnknownRequest(request : Message, replier : FlowReplier) : void
# onFetchSensorRequest(request : Message, replier : FlowReplier) : void
# onMoveRequest(request : Message, replier : FlowReplier) : void
# onSetMovementRequest(request : Message, replier : FlowReplier) : void
# onHaltRequest(request : Message, replier : FlowReplier) : void
# onCheckStatusRequest(request : Message, replier : FlowReplier) : void
# onHandshakeRequest(request : Message, replier : FlowReplier) : void
# onRequest(request : Message, replier : FlowReplier) : void
# onMovementAbortedNotificationReply(request : Message, reply : Message, error : int) : void
# onMovementFinishedNotificationReply(request : Message, reply : Message, error : int) : void
# onReply(request : Message, reply : Message, error : int) : void
+ start() : void
+ sendMovementAbortedNotification(operation : MovementOperation) : void
+ sendMovementFinishedNotifiction(operation : MovementOperation) : void
+ create(robot : RobotManager, flow : Flow) : UartManager
# m_adjustd : int
# m_willAdjust : boolean
# m_operation : MovementOperation
# m_flow : Flow
# m_robot : RobotManager
U#!M#n#7e!
# run() : void
+ isMoving() : boolean
+ sholdStop(movementd : int) : boolean
+ adjust(label : int) : void
+ move(operation : MovementOperation) : void
+ halt() : void
+ start() : void
+ create(robot : RobotManager) : MovementManager
# m_adjusterThread : Thread
# m_adjusterObject : MagnetometerAdjuster
# m_nextOperation : MovementOperation
# m_currentOperation : MovementOperation
# m_robot : RobotManager
# m_mutex : Semaphore
# m_halt : MovementOperation
# m_willAdjust : boolean
# m_isAdjusting : boolean
# m_legs : LegPositions
# m_currentd : int
Mo%e;enM#n#7e!
+ setLabel(value : int) : void
+ getLabel() : int
Y runLid : int, osition : Leg)ositions, manager : ?ovement?anagerM : void
Y getWalueLM : int
Y getLengthLM : int
- m_label : int
MovementOperation
+ run(id : int, position : LegPositions, manager : MovementManager) : void
+ getValue() : int
+ getLength() : int
+ create(distance : int, angle : int, isAligned : boolean, isBackward : boolean) : WalkOperation
# m_walkedDistance : int
# m_totalDistance : int
# m_targetAngle : int
# m_isAligned : boolean
# m_isBackward : boolean
M#"SOpe!#6on
+ xyz : int[6][3]
<<struct>>
Le7Po&66on&
+ heading : float
+ xyz : short[3]
<<struct>>
M#7neo;ee!D##
# run() : void
+ start() : Thread
+ stop() : void
+ create(sensors : SensorsManager) : MagnetometerAdjuster
# m_shouldStop : boolean
# m_sensors : SensorsManager
# m_min : MagnetometerData
# m_max : MagnetometerData
M#7neo;ee!Ad51&e!
# run() : void
# readSensors() : void
+ adjustMagnetometer(offsetX : int, offsetY : int, offsetZ : int) : void
+ start() : void
+ refresh() : void
+ readAccelerometer(accelerometer : AccelerometerData) : void
+ readMagnetometer(magnetometer : MagnetometerData) : void
+ isEnabled() : boolean
+ setEnabled(value : boolean) : void
# isEnabled : boolean
# m_accelerometer : AccelerometerData
# m_magnetometer : MagnetometerData
# m_mutex : Semaphore
# m_adjustZ : int
# m_adjustY : int
# m_adjustX : int
Sen&o!&M#n#7e!
# onReply(request : Message, reply : Message, error : int) : void
+ send(message : Message) : void
+ create(tries : int, flow : Flow, callback : MessageReplyCallback) : NotificationSender
# m_timeout : long
# m_remaining : int
# m_callback : MessageReplyCallback
# m_flow : Flow
No696(#6onSende!
+ getValue() : int
+ getLength() : int
+ create() : HaltOperation
H#"Ope!#6on
+ getValue() : int
+ getLength() : int
+ create(distance : int, isLeftToRight : boolean) : WalkSidewaysOperation
# m_walkedDistance : int
# m_totalDistance : int
# m_isLeftToRight : boolean
M#"SS6de/#,&Ope!#6on
+ getValue() : int
+ getLength() : int
+ create(angle : int, isClock : bool, isDelta : bool, data : MagnetometerData) : RotateOperation
# m_startAngle : int
# m_currentAngle : int
# m_targetAngle : int
# m_isClock : boolean
Ro#eOpe!#6on
+ getValue() : int
+ getLength() : int
+ create() : AdjustOperation
# m_current : int
# m_total : int
Ad51&Ope!#6on
+ getValue() : int
+ getLength() : int
+ create(cycles : int) : HulaHoopOperation
# m_cycles : int
# m_totalCycles : int
H1"#HoopOpe!#6on
+ getValue() : int
+ getLength() : int
+ create(pushUps : int) : PushUpOperation
# m_totalPushUps : int
# m_pushUps : int
P1&)UpOpe!#6on
1
1
1
1
1 1
0..1
1
1
1
Y onRelyLre2uest : ?essage, rely : ?essage, error : intM : void
Messa$eRepl7&allbac8
Y runLM : void
51read6od7
+ xyz : short[3]
<<struct>>
A((e"e!o;ee!D##
!igura >>: &iagrama de classes do firmware.
O firmware foi feito de forma modular, com cada mdulo responsvel por um
aspecto do funcionamento do rob. A cada um deles associada uma classe, sendo a
verso final composta de quatro mdulos, um responsvel pela integrao entre os
demais (classe "RobotManager) e os outros trs responsveis por: movimentao (classe
"MovementManager), comunicao (classe "UartManager) e leitura de sensores (classe
"SensorsManager). Uma viso geral do funcionamento do firmware, em forma de um
statechart, apresntada na figura 67.
!igura >B: #tatechart do firmware.
O mdulo de movimentao do rob, implementado pela classe
MovementManager, gerencia o posicionamento das patas e as sequncias de
movimentos do rob. Ele inclui uma thread que responsvel por atualizar as posies
das patas do rob durante uma operao de movimentao. Como o procedimento de
cinemtica inversa feito por hardware, o mdulo de movimentao apenas gerencia a
posio desejada da ponta da pata e o hardware converte esta posio em PWM para os
motores. A posio atual das seis patas do rob representada por uma estrutura do tipo
"LegPositions. Cada movimento que o rob pode realizar implementado em uma classe
distinta, que estende a classe abstrata MovementManager.
O mdulo de leitura de sensores, implementado pela classe SensorsManager,
gerencia a comunicao com os sensores. A classe mantm campos internos com leituras
dos sensores, os quais so constantemente atualizados por uma thread. As operaes de
obter leituras dos sensores, expostas atravs dos mtodos "readMagnetometer e
"readAccelerometer, obtm o valor armazenado da leitura, no o valor instantneo. As
operaes de comunicao com os sensores so bloqueantes, e consomem um certo
tempo de processamento. Assim, a thread de leitura de sensores poderia interferir com as
temporizaes das demais operaes, como no caso dos movimentos. A thread de leitura
de sensores, por sua vez, desativada durante o tempo de execuo de um movimento e
o prprio objeto responsvel pela movimentao fica responsvel por forar o mdulo dos
sensores a atualizar suas leituras, o que feito atravs do mtodo "refresh.
O mdulo de comunicao, implementado pela classe UartManager, trata todas as
mensagens recebidas do driver e tambm responsvel por enviar ao driver notificaes
de trmino de movimento. O envio de notificaes delegado a instncias de uma outra
classe, NotificationSender, que tenta reenviar as notificaes caso detecte problemas na
transmisso (at um nmero limite de tentativas). Esse nmero limite foi definido
arbitrariamente em 8 tentativas, com 1 segundo de intervalo quando h um erro.
Para que os movimentos do rob fiquem mais suaves, a transio entre duas
posies decomposta em vrios passos intermedirios atravs de interpolao. Em
diversos casos, a espera entre dois setpoints em um movimento interpolado deveria ser
menor que o tick mnimo do MicroC/OS-, que de 10 ms. Para fazer esta espera havia
duas possibilidades: utilizar espera ativa ou temporizadores externos e interrupes.
Apesar de os temporizadores serem a melhor opo, utilizou-se espera ativa devido
simplicidade de implement-la. Como o MicroC/OS- executa sempre a tarefa no-
bloqueada com maior prioridade, a tarefa de movimentao poderia impedir o restante do
sistema de funcionar, pois em busy-wait, o processador nunca explicitamente liberado
pela tarefa. Para evitar este problema, a prioridade da tarefa de movimentao mnima,
entretanto isso raramente ocorre porque na maior parte do tempo as demais tarefas esto
suspensas.
3.%.".3 !river
O driver a pea-chave na integrao do sistema. Ele responsvel por realizar a
comunicao com o rob atravs de um fluxo de UART e por realizar a comunicao com
um cliente a partir de um canal TCP. Seu diagrama de classes pode ser visualizado na
figura 68.
+ setRobot(value : RobotManager) : void
+ getRobot() : RobotManager
+ setClient(value : ClientManager) : void
+ getClient() : ClientManager
+ create() : DriverManager
- m_robot : RobotManager
- m_client : ClientManager
D!6%e!M#n#7e!
- sendNotification(type : int, body : byte[]) : void
- onReadSensorRequest(message : Message, replier : FlowReplier) : void
- onBeginMovementRequest(message : Message, replier : FlowReplier) : void
- onHaltMovementRequest(message : Message, replier : FlowReplier) : void
- onOpenPortRequest(message : Message, replier : FlowReplier) : void
- onEnumeratePortsRequest(message : Message, replier : FlowReplier) : void
- accept() : void
+ sendMovementFinishedNotification(body : byte[]) : void
+ sendMovementAbortedNotification(body : byte[]) : void
+ onRequest(message : Message, replier : FlowReplier) : void
+ onFlowClosed(flow : Flow) : void
+ run() : void
+ create(driver : DriverManager) : ClientManager
- m_flow : Flow
- m_state : State
- m_driver : DriverManager
C"6enM#n#7e!
# onRequest(message : Message, replier : FlowReplier) : void
- onMovementAbortedNotification(message : Message, replier : FlowReplier) : void
- onMovementFinishedNotification(message : Message, replier : FlowReplier) : void
- onKeepAliveNotification(message : Message, replier : FlowReplier) : void
- internalMove(message : Message) : Result
- internalHalt() : Result
- internalReadSensor(buffer : byte[], callback : GenericSensorReadCallback) : void
- internalClose() : void
- internalOpen(host : String, port : int, callback : OpenedCallback) : void
+ halt(callback : RobotHaltedCallback) : void
+ sendMovement(movement : byte[], callback : RobotMovingCallback) : void
+ readSensor(buffer : byte[], callback : GenericSensorReadCallback) : void
+ close() : void
+ open(host : String, port : int, callback : OpenedCallback) : void
+ getState() : State
+ create(driver : DriverManager) : RobotManager
- m_flow : Flow
- m_jobs : JobQueue
- m_callback : MessageCallback
- m_join : Semaphore
- m_connectiond : int
- m_state : State
- m_driver : DriverManager
RoboM#n#7e!
+ Connected : State
+ Accepting : State
+ Stopped : State
<<enum>>
S#e
+ Moving : State
+ dle : State
+ Opening : State
+ Closed : State
<<enum>>
S#e
+ onRequest(request : Message, replier : FlowReplier) : void
Me&&#7eC#""b#(S
Y on=enedLort : #tring, result : ResultM : void
Opened&allbac8
+ UnexpectedRobotResponse : Result
+ nvalidPort : Result
+ AlreadyConnected : Result
+ RobotTimeout : Result
+ UnexpectedClientResponse : Result
+ Offline : Result
+ ClientTimeout : Result
+ Success : Result
<<enum>>
Re&1"
Y on#ensorReadLsensor : byteJK, result : ResultM : void
Gene!6(Sen&o!Re#dC#""b#(S
+ nvalidSensor : Result
+ Closed : Result
+ Offline : Result
+ Success : Result
<<enum>>
Re&1"
+ nvalidMovement : Result
+ Closed : Result
+ Offline : Result
+ Success : Result
<<enum>>
Re&1"
Y onRobot?ovingLresult : ResultM : void
RobotMovin$&allbac8
Y onRobotDaltedLresult : ResultM : void
Robot)alted&allbac8
!igura >4: &iagrama de classes do driver.
Da mesma forma que o firmware, o driver foi desenvolvido de forma modular, com
cada mdulo responsvel por um aspecto distinto de seu funcionamento. O mdulo
central do driver denominado "DriverManager e faz a integrao entre os dois outros
mdulos: um que gerencia a comunicao com o rob (classe "RobotManager) e outro
que gerencia a comunicao com o cliente (classe "ClientManager). Uma viso geral do
funcionamento do driver apresentada, em forma de statechart, na figura 69.
!igura >C: #tatechart do driver.
O mdulo que gerencia a comunicao com o rob, implementado pela classe
"RobotManager, responsvel por estabelecer a conexo com o rob atravs de uma
porta serial e coordenar todas as trocas de mensagens. nicialmente, este mdulo no
est conectado a rob algum. Assim que o cliente envia uma requisio de abertura de
porta feita uma tentativa de conexo com o rob. Se tudo correr bem, o mdulo passa
para o estado "aberto. Enquanto o cliente estiver conectado ao driver ele no pode fechar
a conexo com o rob, ento a nica forma de fazer o RobotManager voltar para o estado
"fechado desconectando o cliente do driver.
O mdulo que gerencia a comunicao com o cliente, implementado pela classe
ClientManager, aceita conexes em uma porta de rede. Assim que um cliente aceito, ele
pode enviar comandos pelo canal TCP. Este mdulo responsvel por tratar todas as
mensagens de alto nvel do cliente e invocar os mtodos adequados do RobotManager.
Quando o cliente desconectado, este mdulo volta a aceitar conexes, e o
RobotManager instrudo a fechar a porta aberta para comunicao com o rob.
3.%."." &liente
O cliente o elemento menos modular dentre os trs artefatos principais de
software. Ele foi feito desta forma pois se comporta como uma "interface entre um outro
software (por exemplo, uma interface grfica) e o driver, ento mais conveniente que
seja utilizado atravs de chamadas simples de mtodos. O diagrama de classes do cliente
pode ser visualizado na figura 70.
# getStrings(buffer : byte[], offset : int, length : int) : String[]
# onMovementAbortedNotification(message : Message, replier : FlowReplier) : void
# onMovementFinishedNotification(message : Message, replier : FlowReplier) : void
# onPingRequest(message : Message, replier : FlowReplier) : void
# internalHalt(callback : RobotHaltedCallback) : void
# internalPushUp(id : int, pushUps : int, callback : RobotMovingCallback) : void
# internalHulaHoop(id : int, cycles : int, callback : RobotMovingCallback) : void
# internalWalkTo(id : int, angle : int, steps : int, isBackward : boolean, callback : RobotMovingCallback) : void
# internalLookTo(id : int, angle : int, callback : RobotMovingCallback) : void
# internalRotate(id : int, angle : int, isClockwise : boolean, callback : RobotMovingCallback) : void
# internalWalkSideways(id : int, steps : int, isRightToLeft : boolean, callback : RobotMovingCallback) : void
# internalWalk(id : int, steps : int, isBackward : boolean, callback : RobotMovingCallback) : void
# internalAdjust(id : int, callback : RobotMovingCallback) : void
# internalSendMovement(request : Message, callback : RobotMovingCallback) : void
# internalReadAccelerometer(callback : AccelerometerReadCallback) : void
# internalReadMagnetometer(callback : MagnetometerReadCallback) : void
# internalOpen(port : int, callback : OpenedCallback) : void
# internalEnumeratePorts(callback : PortsEnumeratedCallback) : void
# internalDisconnect(callback : DisconnectedCallback) : void
# internalConnect(host : String, port : int, callback : ConnectedCallback) : void
+ onRequest(message : Message, replier : FlowReplier) : void
+ onFlowClosed(flow : Flow) : void
+ halt(callback : RobotHaltedCallback) : void
+ pushUp(id : int, pushUps : int, callback : RobotMovingCallback) : void
+ hulaHoop(id : int, cycles : int, callback : RobotMovingCallback) : void
+ walkTo(id : int, angle : float, steps : int, isBackward : boolean, callback : RobotMovingCallback) : void
+ lookTo(id : int, angle : float, callback : RobotMovingCallback) : void
+ rotate(id : int, angle : float, isClockwise : boolean, callback : RobotMovingCallback) : void
+ walkSideways(id : int, steps : int, isRightToLeft : boolean, callback : RobotMovingCallback) : void
+ walk(id : int, steps : int, isBackward : boolean, callback : RobotMovingCallback) : void
+ adjust(id : int, callback : RobotMovingCallback) : void
+ readAccelerometer(callback : AccelerometerReadCallback) : void
+ readMagnetometer(callback : MagnetometerReadCallback) : void
+ open(port : int, callback : OpenedCallback) : void
+ enumeratePorts(callback : PortsEnumeratedCallback) : void
+ disconnect(callback : DisconnectedCallback) : void
+ connect(host : String, port : int, callback : ConnectedCallback) : void
+ removeMovementCallback(callback : MovementNotificationCallback) : void
+ addMovementCallback(callback : MovementNotificationCallback) : void
+ create() : RobotConnection
# m_callbacks : List<MovementNotificationCallback>
# m_jobs : JobQueue
# m_flow : Flow
# m_state : State
RoboConne(6on
+ Connected : State
+ Connecting : State
+ Offline : State
S#e
Y on?ovedLconnection : RobotGonnection, value : int, length : int, id : int, cause : GauseM : void
Movement9otification&allbac8
+ Aborted : Cause
+ Finished : Cause
C#1&e
Y onGonnectedLhost : #tring, ort : int, result : ResultM : void
&onnected&allbac8
+ NotAccepted : Result
+ Success : Result
Re&1"
Y on&isconnectedLresult : ResultM : void
!isconnected&allbac8
+ AlreadyDisconnected : Result
+ Success : Result
Re&1"
Y on)orts8numeratedLorts : #tringJK, result : ResultM : void
Ports:numerated&allbac8
+ UnexpectedResponse : Result
+ Timeout : Result
+ Offline : Result
+ Success : Result
Re&1"
Y on=enedLort : #tring, result : ResultM : void
Opened&allbac8
+ nvalidPort : Result
+ Offline : Result
+ Success : Result
<<enum>>
Re&1"
Y on?agnetometerReadLdata : ?agnetometer&ata, result : ResultM : void
Ma$netometerRead&allbac8
+ heading : float
+ z : int
+ y : int
+ x : int
<<struct>>
M#7neo;ee!D##
+ nvalidSensor : Result
+ Closed : Result
+ Offline : Result
+ Success : Result
<<enum>>
Re&1"
Y onRobot?ovingLresult : ResultM : void
RobotMovin$&allbac8
+ nvalidMovement : Result
+ Closed : Result
+ Offline : Result
+ Success : Result
<<enum>>
Re&1"
Y on!lowGlosedLflow : !lowM : void
+lo*&losed&allbac8
+ z : int
+ y : int
+ x : int
<<struct>>
A((e"e!o;ee!D##
Y on"ccelerometerReadLdata : "ccelerometer&ata, result : ResultM : void
-ccelerometerRead&allbac8
!igura B9: &iagrama de classes da biblioteca de cliente.
O cliente operacionalmente mais simples que as demais partes do software, pois
no realiza operaes em paralelo. Sua mquina de estados apresentada na figura 71.
!igura B%: #tatechart da biblioteca de cliente.
Como acontece com as classes de protocolo, o acoplamento entre cada instncia
da classe de cliente e outros objetos feita atravs de callbacks. Tanto o disparo de
eventos quando as chamadas aos mtodos so assncronas, disparando callbacks em
objetos especficos.
3.%.".% 0nterface $r2fica
O software de interface grfica desenvolvido foi implementado com o intuito de
validar e testar o funcionamento do rob. Todo o cdigo foi concentrado em um nico
arquivo-fonte, que contm o componente de controle do rob,
"HexapodCommandsControl.
A interface foi desenvolvida em linguagem Java, com a biblioteca Swing. Ela foi
concebida para permitir a utilizao de todas as funcionalidades implementadas na
biblioteca de cliente, ou quase todas. Uma captura de tela do software de interface grfica
logo aps ser aberto apresentada na figura 72.
!igura B+: Tela inicial do software de interface grQfica.
Assim que o software aberto, ele no est conectado a driver algum. Para
estabelecer a conexo com um driver preciso indicar host do computador no qual o
driver est e pressionar o boto "Conectar. Se a conexo for estabelecida com sucesso,
o usurio ser direcionado para a tela apresentada na figura 73.
!igura B,: Tela de conexHo com robI do software de interface grQfica.
Nesta tela, o software est conectado ao driver, mas o driver ainda no est
conectado ao rob. preciso selecionar a porta na qual o rob se encontra e pressionar o
boto "Conectar. Se tudo correr bem, o usurio ser direcionado para a tela apresentada
na figura 74.
!igura B6: Tela de execu*Ho de movimentos e leitura de sensores do software de
interface grQfica.
Uma vez nesta tela, o usurio pode obter leituras de sensores (atravs de botes
na parte inferior da tela) e iniciar a execuo de movimentos (atravs das abas na parte
superior da tela). Se os parmetros de um movimento forem preenchidos e o boto
"niciar for pressionado, a tela apresentada na figura 75 ser exibida. Nesta tela o usurio
pode abortar o movimento que foi iniciado. Quando o movimento terminar, ou for
abortado, a tela de leitura de sensores e execuo de movimentos exibida novamente.
!igura B3: Tela de movimento em andamento.
3.( Movimentos
Durante a execuo do projeto foram definidos, pela equipe, alguns movimentos
para ilustrar e validar todo o sistema de controle do hexpode desenvolvido. Essa etapa,
apesar de demandar um estudo prvio de como so realizados os movimentos de um
hexpode, foi muito mais prtica, no sentido de realizar testes e calibragens, do que as
outras.
Atravs da cinemtica inversa foi mais simples criar os movimentos pois no
preciso controlar a variao angular de cada um dos motores. Para isso basta variar a
posio da ponta da pata utilizando coordenadas cartesianas que a cinemtica trata de
ajustar os ngulos, quando for possvel, para que ocorra o deslocamento correto. Com
isso foi possvel criar um conjunto de posies pr definidas para realizar cada um dos
movimentos executados pelo hexpode. Entretanto, para criar movimentos mais fludos
todos as posies pr definidas so interpoladas, entre 10 e 32 pontos, fazendo com que
os servomotores realizem pequenos movimentos, em vez de um movimento brusco, para
mover de uma posio para outra.
A Seo "Gait apresentou algumas possveis configuraes para criar movimentos
para um robo hexpode. Das opes de gait disponveis, optou-se por utilizar o tripod gait.
Alm de ser a opo mais rpida umas das que mais se assemelha ao movimento de
animais hexpodes. Tomando o movimento de andar como base de demonstrao, so
utilizados 4 passos para cada pata com a finalidade de completar um ciclo,
desconsideradas as etapas de sada da posio de repouso e retorno a posio de
repouso. Quando 3 patas esto no ar, as outras 3 esto no cho. Essa rotina se repete,
alternando as patas no ar e no cho, at que o movimento seja completado.
Foram desenvolvidos 3 tipos de movimentos no projeto. Os movimentos bsicos
consistem em movimentos simples de locomoo do rob, como andar para frente ou
andar de lado. Os movimentos com magnetmetro so aqueles responsveis por
controlar a direo apontada pelo rob atravs de uma malha de controle onde os
movimentos so ajustados de acordo com as medidas do magnetmetro. Por ltimo, os
movimentos demonstrativos so aqueles que no deslocam o rob, eles apenas
executam uma srie de movimentos para ilustrar as capacidades do hexpode.
A$G$0 Mo%6;eno& b&6(o&
Existem quatro movimentos bsicos que podem ser executados pelo robo
hexpode: andar para frente, andar para trs, andar de lado para esquerda e andar de
lado para direita. Todos eles executam quatro etapas bsicas de movimentos pr
definidos para realizar um ciclo que pode ser encadeado inmeras vezes e com isso gerar
os movimentos de andar do rob. O ciclo basicamente o mesmo para todos os
movimentos bsicos, porm, o que os diferencia o sentido (no caso do andar para frente
ou para trs) ou a direo (no caso de andar para frente ou para o lado) em que eles
ocorrem. Outro fator importante que antes e depois de cada movimento so
realizados alguns deslocamentos das patas para sair da posio de descanso do
hexpode e coloc-lo na primeira posio do ciclo de movimento (incio do movimento),
ou sair da ltima posio do ciclo e coloc-lo novamente na posio de descanso (final do
movimento). As etapas pr-ciclo e ps-ciclo so importantes para evitar que haja
deslocamento no rob, portanto todos os movimentos so executados com as patas no ar
e sempre alternando os conjuntos de patas utilizadas no "gait triplo para manter a
estabilidade.
As quatro etapas do ciclo de um movimento bsico do hexpode so: 1) deslocar
as patas da frente e de trs do lado direto do rob e a pata central do lado esquerdo no
cho, enquanto as demais so deslocadas no sentido oposto no ar. 2) As patas que
estavam no cho se deslocam para cima (para o ar) e as patas que estavam no ar se
deslocam para baixo (para o cho). 3) deslocar as patas da frente e de trs do lado
esquerdo do rob e a pata central do lado direito no cho, enquanto as outras so
deslocadas no sentido oposto no ar. 4) Novamente as patas que estavam no ar se
deslocam para o cho e as patas que estavam no cho se deslocam para o ar.
Ao final das quatro etapas o rob volta a posio inicial do ciclo, que pode ser
repetido inmeras vezes e com isso gerar os movimentos bsico de locomoo do
hexpode. As diferenas entre os ciclos de movimentos para gerar os quatro movimentos
bsicos de locomoo so explicadas a seguir:
Andar para frente: consiste em realizar os deslocamentos no cho fazendo com
que as patas comecem mais a frente do rob e sejam deslocadas para trs.
Enquanto isso os movimentos no ar seguem o sentido oposto, ou seja, se
deslocam de trs para frente. Um ponto importante nesse movimento que para
evitar que o hexpode ande em "zigue-zague necessrio que a pata central de
cada lado se desloque o dobro das patas frontais e traseiras para que a fora
resultante do movimento no faa com que o hexpode gire.
Andar para trs: basicamente o mesmo movimento do andar para frente,
entretanto, as patas no cho so deslocadas de trs para frente as patas no ar so
deslocadas da frente para trs.
Andar de lado para direita: consiste em realizar os deslocamentos no cho fazendo
com que as patas que esto no cho comecem mais direita do rob e sejam
deslocadas para a esquerda. Ao mesmo tempo as patas que esto no ar so
deslocadas da esquerda para a direita.
Andar de lado para esquerda: o movimentos o mesmo do andar para a direita,
mas as patas que esto no cho se deslocam da esquerda para a direta e as patas
que esto no ar se deslocam da direita para a esquerda.
A$G$4 Mo%6;eno& (o; ;#7ne;e!o
Diferente dos movimentos bsicos de locomoo, que so controlados atravs do
nmero de ciclos de execuo, os movimentos com o magnetmetro so responsveis
por fazer com que o hexpode gire e aponte para alguma direo (variao em ngulo
com relao ao Norte) atravs de um controle utilizando o magnetmetro. Foram criados
trs movimentos bsicos utilizando magnetmetro: olhar para uma direo, girar no
sentido horrio e girar no sentido anti-horrio.
Para utilizar o magnetmetro corretamente necessrio calibr-lo, por isso foi
criado um quarto movimento de ajuste. Esse movimento faz com que o hexpode gire
completamente em torno do prprio eixo e realize medies com o magnetmetro. Com
isso so armazenados os valores extremos dos 2 eixos horizontais ao plano em que se
encontra o hexpode e ajustados os offsets para que o ponto mdio fique no ponto (0,0).
Apesar de existirem trs movimentos para rotacionar o hexpode, todos eles so
executados internamente no firmware como sendo o movimento de olhar para uma
direo. Para simplificar a movimentao os movimentos de girar tantos graus no sentido
horrio ou anti-horrio realizada uma leitura antes de comear a movimentao e
calculada a variao de acordo com os parmetros repassados para o usurio e com isso
encontrar o ngulo que o hexpode deve ser direcionado. Aps essa etapa iniciado
efetivamente o movimento de rotao do hexpode.
O movimento de rotao executado em trs etapas, primeiramente realiza a
leitura do magnetmetro, depois calculado o erro e por ltimo realizado um ciclo do
giro. Essas etapas so repetidas at que o hexpode consiga ser direcionado para o
ngulo de destino. Aps alguns testes foi definida que uma boa margem de erro para que
ele complete o movimento de rotao de 3 graus.
Aps ser realizada a leitura da posio atual do rob calculado o erro, ou seja,
quantos graus faltam para o hexpode ficar alinhado ao ngulo desejado. Atravs desse
erro dois pontos so estabelecidos para definir como ser o movimento para rotacionar o
rob. O primeiro fator verifica para qual o sentido que dever acontecer o giro, caso o erro
encontrado seja maior do que zero o giro acontece no sentido anti-horrio, caso contrrio
ele ser no sentido horrio. Como a margem de erro utilizada de 3 graus, se o mdulo
do erro for menor do que 3 o movimento encerrado.
O segundo ponto estabelecido durante o clculo do erro definir qual ser o
deslocamento das patas para realizar o giro. Depois de realizados alguns testes verificou-
se que o hexpode precisa na mdia de 26 giros para deslocar 360 graus utilizando
passadas de aproximadamente 50mm. Atravs disso possvel calcular a constante "c
que relaciona quantos graus cada milmetro de movimento rotaciona utilizando a equao
13 abaixo.
c=360/(26#0) (13)
Atravs disso foi possvel encontrar a constante proporcional para realizar o
controle do giro do hexpode (c = 0,27). Para calcular qual o deslocamento (Ay) da pata
para realizar o movimento de rotacionar. A equao 14 apresenta a relao existente
entre o erro atual e o deslocamento das patas para realizar o prximo movimento de
rotao. Onde "Ay representa o deslocamento da pata em milmetros e "e representa o
erro em graus.
y=032%e (1")
Depois de calculado o erro, o movimento de rotacionar efetivamente realizado
pelo hexpode. Tanto a rotao no sentido horrio quanto a rotao no sentido anti-
horrio so realizadas utilizando um ciclo com 7 pontos pr-definidos. O movimento foi
inspirado no mecanismo de giro utilizado pelos tanques de guerra, ou seja, enquanto as
patas de um lado do hexpode se deslocam para frente, as outras se deslocam para trs
fazendo com que o rob gire. A nica diferena entre o sentido horrio ou anti-horrio do
movimento qual o lado do hexpode que vai se deslocar para frente. Ao mover, no cho,
as patas da direita para trs e as patas da esquerda para frente o rob gira no sentido
anti-horrio, caso ocorra o oposto ele gira no sentido horrio.
Para exemplificar as sete etapas do ciclo do movimento de rotao ser utilizado o
movimento no sentido anti-horrio: 1) A pata da frente do lado direito, a pata traseira do
lado direito e a pata central do lado esquerdo so erguidas. 2) As patas do lado direito que
esto suspensas se deslocam para a frente enquanto a pata do lado esquerda se desloca
para trs. 3) As patas que estavam no ar so deslocadas para o cho. 4) A pata da frente
do lado esquerdo, a pata traseira do lado esquerdo e a pata central do lado direito so
erguidas. 5) A pata do lado direito suspensa se desloca para frente enquanto as patas do
lado esquerdo se deslocam para trs. 6) As patas que estavam no ar so deslocadas para
o cho. 7) As patas do lado direito que estavam mais a frente se deslocam para trs e as
patas do lado esquerdo que estavam mais atrs se deslocam para frente. Com isso o
hexpode realiza o giro e volta para a posio inicial.
A$G$A Mo%6;eno& de;on&!#6%o&
A ltima categoria de movimentos recebeu esse nome pois no apresenta nenhuma
utilidade prtica de locomoo e serve apenas pra ilustrar o controle existente do
hexpode. Para fins demonstrativos foram criados 2 movimentos. O primeiro, nomeado
"bambol, faz com que o rob alterne a altura das suas seis patas em quatro diferentes
nveis, sempre alternando a mais baixa e a mais alta em um ciclo de 6 posies (uma
para cada pata). Fazendo com que uma das patas fique em uma posio mais elevada, a
pata oposta aquela fique em uma posio mais baixa e as demais em nveis
intermedirios (elevados ou rebaixados dependendo da elevao da pata ao seu lado)
gerado um movimento semelhante ao de uma pessoa brincando com um bambol.
O outro movimento, intitulado "flexo, faz com que o hexpode assuma uma
posio semelhante ao movimento de uma pessoa fazendo flexo, onde as patas
traseiras ficam posicionadas mais para trs e as patas dianteiras ficam ligeiramente
abertas e variando entre uma posio mais elevada e uma posio no mesmo nvel das
patas traseiras, simulando o movimento realizado pelo exerccio fsico. Durante a
realizao do movimento as patas centrais ficam erguidas para no influenciarem na
execuo do mesmo.
3.; &onsidera'es
O hardware desenvolvido na FPGA teve de integrar diversos conceitos para
concretizar os requisitos do projeto. A utilizao de um processador softcore foi bastante
proveitosa principalmente no que se refere a comunicao. Mesmo nos casos em que a
biblioteca padro no tinha todos os recursos necessrios, o acoplamento de blocos de
hardware de terceiros aconteceu sem grandes dificuldades. Alguns conceitos, como por
exemplo a cinemtica inversa, ofereceram maiores dificuldades por necessitarem uma
maior maturidade terica pr-implementao e planejamento para integrar ao resto do
sistema. Deve-se mencionar tambm a mudana de paradigma que se deve ao fato da
FPGA tratar-se de um dispositivo que opera de forma concorrente, em oposio aos
microcontroladores e microprocessadores normalmente utilizados. O resultado final um
hardware que realiza o que foi proposto e uma soluo bastante robusta e compacta.
Para distribuir a alimentao e os dados entre a FPGA e os outros perifricos
(motores, sensores e XBee) foram desenvolvidas 2 placas de circuito impresso. Atravs
disso foi possvel separar a alimentao em dois canais, um de alta potncia utilizado nos
servomotores e outro de baixa potncia utilizado para alimentar o restante do projeto.
Apesar das dificuldades enfrentadas durante esta parte do projeto, foi possvel construir
um circuito modular, que alm de possuir um rendimento satisfatrio, apresentou uma
manuteno fcil por permitir que seus componentes sejam desacoplados rapidamente.
A alimentao do hexpode foi dividida em 2 partes, uma mais simples (baixa
potncia) utilizada na FPGA, XBee e sensores era fornecida por uma fonte comum de 9V
e 1.5A. A outra parte utilizava uma Fonte ATX de computador, utilizada no circuito de alta
potncia para alimentar os servomotores, que no apresentou nenhuma grande
complicao e foi suficiente para fornecer os aproximados 14A que os motores consomem
durante o funcionamento do hexpode.
A elaborao do protocolo em dois nveis (baixo e alto nvel) tornou mais simples o
desenvolvimento das classes de comunicao. Enquanto o protocolo de alto nvel
diferente para cada par de entes comunicantes, e ainda tratado diferentemente em cada
lado da comunicao, o protocolo de baixo nvel consistente em todos os sistemas.
Assim, o projeto das classes de comunicao tambm pde ser desenvolvido em duas
partes: uma comum a todos os artefatos de software (classes de protocolo) e outra
especfica para cada (classes de alto nvel especficas). Outra vantagem da
implementao elaborada o fato de as classes de comunicao serem elaboradas sobre
fluxos genricos de dados, de maneira que podem ser utilizadas sobre outros meios em
verses futuras do projeto.
As classes de gerenciamento automtico de memria e ools de objetos
elaboradas em C++ so totalmente independentes do cdigo especializado do firmware,
ento podem ser utilizadas em outros projetos de software. As classes de baixo nvel e
parte das classes de alto nvel (especialmente as referentes ao protocolo de baixo nvel)
tambm tm esta propriedade. Assim, um subproduto do rob hexpode so bibliotecas
de cdigo aberto em linguagens C++ e Java, que incluem classes de baixo nvel e
comunicao por troca de mensagens.
Adotou-se o procedimento de preservar grandemente a estrutura do cdigo os
diversos artefatos de software, mesmo entre linguagens distintas. Este procedimento tem
um lado negativo, por no levar em conta caractersticas especficas de cada linguagem
plataforma, o que s vezes pode levar escrita de cdigo desnecessrio. Em
contrapartida, o procedimento de desenvolvimento foi bastante simplificado, pois, se os
cdigos seguem a mesma sequncia de operaes, todas as alteraes feitas em um
(como por exemplo, correes de erros) so replicadas para os demais de forma trivial.
Dos trs artefatos principais de software, o mais complexo provavelmente o
firmware, pois responsvel por gerenciar diversos dispositivos em interao: as seis
patas, os sensores e a comunicao com o driver. O driver pode ser colocado em
segundo lugar em ordem de complexidade, pois, alm de se comunicar com o rob e com
o cliente, tem de coordenar, em termos de controle de concorrncia, a comunicao entre
ambos.A biblioteca de comunicao a seguinte em ordem decrescente de
complexidade: apesar de ter um controle rudimentar de concorrncia, sua funo acaba
resumindo-se apenas a enviar comandos ao driver, e ento esperar e tratar suas
respostas. O software de interface grfica tambm simples em termos de complexidade
de projeto, pois sua funo apenas enviar comandos utilizando a biblioteca de
comunicao, recebendo e tratando suas respostas. Ele, entretanto, apresenta outra
dimenso de complexidade, que a elaborao da interface em si, em termos de
usabilidade.
Captulo 4 Plano de testes 119
: P"#no de e&e&
Para verificar o funcionamento do sistema integrado, foi elaborado um plano de
testes. O plano contempla os requisitos funcionais sistmicos e os requisitos funcionais do
software de interface grfica. Cada caso de teste composto de um roteiro que deve ser
seguido. Se uma etapa do teste levar a um resultado diferente do esperado, considera-se
que o caso de teste como um todo falhou. Assim que o projeto foi terminado, no perodo
de integrao, todos os casos de teste foram executados com sucesso.
".1 &aso de teste 0< &one/o com o driver
Este caso de testes referente ao requisito RF9. Em resumo, consiste em verificar
se o software de interface grfica consegue conectar-se ao driver atravs da biblioteca de
comunicao.
P!@'(ond62Ue&* o software de interface grfica deve estar instalado em um computador A, e o driver deve
estar em execuo em um computador B.
E#p# In&!123o Re&1"#do e&pe!#do
1 Abra o software de interface no computador A. A tela inicial do software exibida.
2 Digite um endereo de P no qual o driver no
esteja sendo executado. Pressione o boto de
conectar.
Aps algum tempo, exibida a mensagem de
que no foi possvel conectar ao driver.
3 Digite o endereo de P do computador B.
Pressione o boto de conectar.
A tela de selecionar porta exibida.
".2 .&aso de teste 00< &one/o com o rob3
Este caso de testes referente aos requisitos RF3, RF7 e SWRF1. Em resumo,
consiste em verificar se o software de interface grfica consegue conectar-se ao rob
atravs da biblioteca de comunicao e do driver.
P!@'(ond62Ue&* o software de interface grfica est em execuo em um computador A, e o driver est em
execuo em um computador B. O software de interface grfica do computador A est conectado ao driver
do computador B. O rob est totalmente ligado.
1 Selecione uma porta, no computador A, na qual
o rob no esteja conectado. Se no houver tal
porta, pule para o passo 2. Pressione o boto
de conectar.
Aps algum tempo, exibida a mensagem de
que no foi possvel conectar ao rob.
2 Selecione uma porta, no computador A, na qual
o rob esteja conectado. Pressione o boto de
conectar.
A tela de enviar comandos e ler sensores
exibida.
".3 &aso de teste 000< Posio de repouso do rob3
Este caso de testes referente aos requisitos RF1 e RF4. Em resumo, consiste em
verificar se o rob vai para a posio de repouso e permanece nela.
P!@'(ond62Ue&* a eletrnica de potncia do rob est desligada, e as patas esto em posio diferente da
de repouso.
1 Ligue a eletrnica de potncia do rob. O rob fica na posio de repouso.
2 Aguarde alguns instantes. O rob no sai na posio de repouso.
"." .&aso de teste 0< Movimentao do rob3
Este caso de teste referente aos requisitos RF2, RF4, RF5, RF8 e SWRF2. Em
resumo, consiste em verificar se o rob locomove-se quando recebe um comando.
do computador B. O driver do computador B est conectado a um rob. O rob est totalmente ligado.
1 Selecione a aba de "andar e preencha os
parmetros para andar um passo para a frente.
Pressione o boto de iniciar.
O rob d um nico passo para a frente e para.
2 Selecione a aba de "andar e preencha os
parmetros para andar dez passos para a
frente. Pressione o boto de iniciar. Quando o
movimento iniciar, pressione o boto de
abortar.
O rob comea a andar para a frente, mas
para quando o boto pressionado.
".% &aso de teste < =eitura de sensores do rob3.
Este caso de teste referente aos requisitos RF6, RF8 e SWRF3. Em resumo,
consiste em verificar se possvel obter leituras dos sensores do rob.
do computador B. O driver do computador B est conectado a um rob. O rob est totalmente ligado.
1 Com o rob parado, pressione o boto de
atualizar leitura do magnetmetro.
Aps alguns instantes, a leitura do
magnetmetro na tela atualizada.
2 Mude o ngulo do rob em relao ao norte, e
pressione o boto de atualizar leitura do
magnetmetro.
magnetmetro na tela atualizada para um
valor distinto do apresentado anteriormente.
3 Pressione o boto de atualizar a leitura do
acelermetro.
acelermetro na tela atualizada.
".( &onsidera'es
Os casos de testes foram elaborados como uma maneira formal de validar o
funcionamento do rob. O plano de testes como um todo bastante curto, mas cada um
deles ( exceo do caso ) verifica mais de um requisito. comum que cada teste
englobe um nico requisito, mas, dado sofisticao do sistema integrado, no faria
sentido avaliar cada requisito independentemente.
Captulo 5 Gesto 122
< Ge&3o
Para desenvolver o projeto foi utilizado o processo em espiral. Esta abordagem foi
escolhida por conta do grande nmero de diferentes tecnologias e conceitos envolvidos.
O projeto seguiu trs ciclos principais de desenvolvimento: "estudos e validaes,
"desenvolvimento da arquitetura e "montagem e integrao". O primeiro ciclo consistiu
em estudar as tecnologias utilizadas e validar algumas ideias, como cinemtica inversa,
desenvolvimento dos servos prprios e blocos de controle do PWM, para definir a
arquitetura e verificar a viabilidade de certos aspectos do projeto. Nessa etapa foi
construda boa parte da fundamentao terica e criado o "alicerce do projeto.
No segundo ciclo, foi estabelecida e desenvolvida a arquitetura do sistema. Nele,
foram desenvolvidas as placas de circuito impresso, criada boa parte da lgica de
controle, aprimorada a cinemtica inversa, desenvolvido o driver da estao base e criado
o protocolo de comunicao. Nessa etapa adquiriram-se boa parte dos componentes
utilizados no projeto (estrutura mecnica, servomotores e sensores) e foi criada toda a
estrutura base do projeto para permitir integrar o hardware das PCs, o hardware
embarcado, o firmware embarcado e o software da estao base.
No ltimo ciclo, aconteceu a integrao de toda a estrutura desenvolvida
anteriormente. Nele a estrutura mecnica foi montada junto com os servomotores e as
placas de circuito impresso de alta e baixa potncia. Alm disso, ela foi integrada com a
FPGA, o XBee e os sensores. Nessa etapa tambm foram desenvolvidos os movimentos,
boa parte do software embarcado e o software de interface. Por fim, neste ciclo ocorreu a
grande maioria dos testes de integrao, ajustes e calibragens do hexpode.
%.1 :scopo
O principal objetivo do projeto era desenvolver um rob hexpode controlado por
lgica reconfigurvel, que fosse extensvel de alguma forma e pudesse ser controlado
atravs de algum dispositivo externo. Tambm foram levantados alguns outros objetivos
especficos: informar a direo apontada pelo rob, comunicar-se com um dispositivo
externo atravs de uma conexo sem fio e possibilitar o envio de comandos bsicos de
movimentao.
Todos os objetivos apontados no incio do projeto foram contemplados de alguma
maneira. Foi desenvolvido um rob hexpode utilizando uma FPGA para prover a lgica
Captulo 5 Gesto 123
reconfigurvel que pode ser controlado a partir de uma estao base (computador de
mesa comum) utilizando um mdulo de comunicao serial sem fio XBee. possvel
enviar uma srie de comandos bsicos ao hexpode e ainda realizar a leitura de alguns
sensores (magnetmetro e acelermetro).
Entretanto, alguns objetivos surgiram de acordo com o desenrolar do projeto, mas
nem todos foram totalmente contemplados. Grande parte deles surgiram ainda no
primeiro ciclo do projeto e tinham um impacto muito grande no resultado final dele, como,
por exemplo, o desenvolvimento dos servos prprios e o desenvolvimento da cinemtica
inversa. Nessa etapa surgiram duas possveis vertentes para atingir o objetivo principal, a
primeira consistia em desenvolver a cinemtica inversa do hexpode, realizar movimentos
mais elaborados e utilizar servomotores j existentes no mercado. A outra tinha como
principal foco desenvolver os servomotores atravs do controle na prpria FPGA,
desenvolver uma arquitetura de processador especfica para a robtica e realizar
movimentos mais simples utilizando somente a variao de ngulos pr estabelecidos,
sem utilizar uma cinemtica inversa.
Durante o primeiro ciclo a equipe trabalhou em paralelo com essas duas vertentes
e acabou escolhendo implementar a da cinemtica inversa por diversos motivos. Um dos
pontos mais interessantes em tentar desenvolver os prprios servos era o fato de poder
comprar servos mais baratos e melhor-los, reduzindo o custo efetivo do projeto,
entretanto, para fazer o controle desses servos seria necessrio utilizar um C de ponte H
(L298) para inverter o sinal e um LM555 para realizar a leitura de posio dos motores.
Com isto o custo final se tornaria semelhante a um servo importado e de boa qualidade
para o uso estabelecido no projeto. Outro fator importante foi que ao desenvolver o servo
a equipe percebeu que um dos grandes limitadores dos servos mais baratos a baixa
qualidade das engrenagens da caixa de reduo (feitas geralmente de plstico em servos
de baixo custo) e do potencimetro, resultando em uma melhoria de desempenho abaixo
do esperado. Por fim, a PC ficaria consideravelmente maior, mais cara e mais complexa
caso fossem utilizados os servos desenvolvidos pela equipe.
Foram analisados outros dois pontos durante o projeto que acabaram sendo
substitudos por outras alternativas. Uma das possibilidades consistia em utilizar uma
bateria para alimentar o hexpode, entretanto, essa alternativa foi descartada pois alm
de aumentar o custo, j que seriam necessrias pelo menos duas baterias durante a fase
de desenvolvimento, ele precisaria de um controle da carga para regular os ajustes do
projeto para suportarem a queda de tenso e sua autonomia seria muito baixa devida a
Captulo 5 Gesto 124
grande quantidade de corrente consumida pelos servomotores utilizados. Outro ponto que
foi descartado foi a possibilidade de criar um projeto mecnico, ou utilizar um projeto j
existente, e confeccionar as peas em algum local especializado em cortes de metal.
Entretanto, para agilizar o processo de aquisio da estrutura mecnica e evitar
problemas com fornecedores e possveis problemas com peas fora de medida, optou-se
por importar uma estrutura mecnica (MSR-H01) com qualidade j reconhecida por outros
desenvolvedores de hexpodes.
Apesar de algumas ideias terem sido descartadas, foram acrescentadas alguns
pontos positivos ao projeto que no tinham sido contemplados na ideia original. O projeto
da PC foi dividido em duas placas separadas, isolando a parte de alta potncia que
alimenta os motores da de baixa potncia que envia o sinal de PWM para os servos e
alimenta a FPGA e os sensores. Outro ponto positivo foi a utilizao de um processador
embarcado na FPGA (NOS ) com o RTOS MicroC para facilitar na comunicao e
gerenciar melhor a estrutura do hardware embarcado. Por ltimo, a mudana de escopo
que mais beneficiou o projeto foi uma alterao na arquitetura do software da estao
base. Para melhorar consideravelmente a extensibilidade do projeto decidiu-se por
separar o driver que comunica diretamente com o Hexpode, e precisa estar ao alcance
do XBee, do software de interface criando uma nova camada de comunicao atravs de
soc(ets. Com isso possvel controlar o hexpode em qualquer computador, ou
dispositivo, que consiga acessar, atravs da rede ou da internet, a mquina que est
executando o software com o driver do rob, desde que ele conhea a interface de
comunicao implementada no driver.
%.2 &ustos e &rono$rama
O custo do projeto pode ser avaliado atravs do gasto, em dinheiro, com
equipamentos e materiais e do total de horas trabalhadas pela equipe para desenvolv-lo.
Em termos monetrios o projeto custou R$2.291,10, entretanto, esse valor reflete o gasto
real da equipe e no leva em considerao algumas taxas de importao e equipamentos
que no precisaram ser comprados. Em relao ao tempo gasto foram necessrias
aproximadamente 1600 horas de trabalho, que foram divididas entre os 3 membros da
equipe durante um perodo pouco maior do que 1 ano (05/03/2012 30/04/2013).
nformaes mais detalhadas a respeito das atividades realizadas e dos gastos do projeto
so apresentadas no decorrer desta seo.
Captulo 5 Gesto 125
A primeira estimativa de gastos foi apresentada no incio deste documento durante
a seo de viabilidade financeira e pode ser vista na tabela 1. Entretanto, por conta de
algumas mudanas no escopo detalhadas na seo anterior, vrios itens utilizados no
foram estimados e outros nem chegaram a fazer parte do projeto. Apesar disso o custo
total estimado, que variava de R$2.000,00 a 2.400,00, foi mantido dentro do possvel. A
tabela 10 apresenta com detalhes todos os gastos do projeto. Eles esto separados em 9
grupos para facilitar a visualizao dos gastos. Dentro dos grupos podem ser vistas
informaes referentes a gastos unitrios e totais de um determinado material, gastos
com transporte e taxas de importao. Para todos os produtos importados so
apresentados os valores originais referentes a moeda corrente daquele pas e a cotao
em real utilizada no dia da compra. A coluna Tipo do custo utilizada para diferenciar o
custo total do projeto, ela indica se o produto um custo exclusivo de produo (P),
exclusivo de desenvolvimento (D) ou um custo efetivo (E) tanto para produo quanto
para desenvolvimento. Gastos com componentes eletrnicos de uso geral (ex: resistores,
capacitores, fios e material para solda) no foram discretizados para no poluir a tabela,
entretanto, o valor gasto com eles est agrupado nos itens de componentes diversos.
Captulo 5 Gesto 126
Tabela %9: Tabela de gastos do rojeto
Captulo 5 Gesto 127
Durante o processo de construo do plano de projeto, durante o primeiro semestre
de 2011, foi criado um planejamento das atividades necessrias para realizar o
desenvolvimento do projeto e com isso foi elaborado um diagrama de Gantt com o
cronograma preliminar que pode ser visto na figura 76. Apesar do diagrama contemplar
boa parte das tarefas desenvolvidas durante o projeto, ele foi criado em uma etapa onde a
equipe no tinha uma viso totalmente clara do projeto e nem um escopo completamente
definido. Por isso existe uma grande divergncia entre o planejamento inicial e o realizado
efetivamente. O perodo de execuo do projeto tambm foi diferente do planejado por
conta de dois eventos distintos, o primeiro envolve o intercmbio planejado de seis meses
de um dos membros da equipe e que durou um ano, entretanto, apesar de afetar o
planejamento a equipe chegou a desenvolver uma parte do projeto em paralelo mesmo
com um dos integrantes na Alemanha. O evento que efetivamente alterou todo o
cronograma do projeto foi a greve de 4 meses da UTFPR que ocorreu no ano de 2012.
Com isso o calendrio acadmico foi deslocado e o ano letivo que deveria acabar em
Dezembro de 2012 deve acabar somente em Maio de 2013. Por conta da greve a equipe
pode estender o cronograma e realizar a maior parte do trabalho aps o retorno do
integrante que estava realizando o itercmbio.
Atravs da tabela 10 possvel extrair 3 tipos de custos finais do projeto. O
primeiro representa o custo real de desenvolvimento do projeto, ou seja, tudo aquilo que
foi gasto de fato pela equipe. Nesse gasto so consideradas todos os materiais reservas
utilizados no projeto e todos os materiais utilizados em testes e que no foram agregados
ao produto final, entretanto, no so contemplados gastos com materiais que no
precisaram ser comprados, como por exemplo a fonte ATX, e nem a taxa alfandegria dos
servomotores, pois estes no foram tributados. O custo de produo, por sua vez,
descarta todos os materiais utilizados somente no desenvolvimento e as peas reservas,
porm, ele contempla o gasto com equipamentos que no precisaram ser comprados e as
taxas de importao de todos os produtos. Ele representa o "custo base para que o
projeto seja replicado caso necessite comprar todos os materiais e sejam tarifados todos
os produtos no processo de importao. Por ltimo, o custo total de desenvolvimento
reflete a soma de todos os componentes listados na tabela, ou seja, ele representa o
custo de desenvolvimento incluindo todas as taxas de importao e compra de todos os
componentes utilizados.
Captulo 5 Gesto 128
!igura B>: &iagrama de .antt do cronograma reliminar.
Captulo 5 Gesto 129
Alm dos eventos que alteraram as datas do cronograma preliminar do projeto a
equipe percebeu que o modelo de trabalho utilizado nele, apresentando datas de inicio e
de fim completamente estabelecidas para alguns grupos de tarefas, no se mostrou muito
eficaz pois ele no apresentava as horas estimadas e realizadas de trabalho. Com o
passar do tempo o projeto adquiriu mais consistncia e o escopo foi melhor definido,
porm at chegar em uma verso mais slida do que faltava ser feito vrias tarefas
sofreram alteraes e muitas outras foram acrescentadas. Por esses fatores a equipe
resolveu adotar uma nova estratgia para gerenciar as horas gastas no projeto e tentar
simplificar o tempo gasto com planejamento de tarefas futuras e frequentes alteraes
que ocorreram no cronograma. A soluo encontrada foi utilizar uma tabela criando
inicialmente grupos de tarefas e estimando algumas horas para eles. Durante a execuo
do projeto foram criadas tarefas para aqueles grupos e alocadas horas estimadas para
elas. Cada tarefa tambm apresenta uma coluna de status para acompanhar sua
evoluo e uma data de inicio e termino dela. Por fim uma coluna apresenta as horas
trabalhadas em cada tarefa. A verso completa da tabela com todas as atividades listadas
pode ser vista no Apndice E. A verso simplificada da tabela 11, apresenta somente o
agrupamento das tarefas.
A tabela de atividades representa quando foram realizadas as tarefas do TCC e
quantas horas foram necessrias para execut-las. O perodo apresentado nela vai de
Maro de 2012 a Abril de 2013 pois foram esses os meses de trabalho efetivo do projeto.
Algumas tarefas, como a compra de alguns componentes, ocorreram antes desse
perodo, entretanto, todas foram repassadas para a nova data de incio do projeto por no
haver um registro exato de quando elas ocorreram. A maioria das tarefas de estudo e
anlise se concentraram durante os 7 primeiros meses do projeto, ciclo 1 comentado no
inicio da seo sobre gesto, aps esta etapa o escopo do projeto foi definido
integralmente e comeou o ciclo 2, entre o inicio do ms de Novembro de 2012 e a
metade de Fevereiro de 2013, onde foi construda grande parte da arquitetura do sistema
e realizada a compra de boa parte dos componentes finais do projeto como a estrutura
mecnica, os servomotores e as placas de circuito integrado. O terceiro e ltimo ciclo foi
responsvel por integrar toda a arquitetura do sistema, implementar tarefas de mais alto
nvel de abstrao (software de interface e movimentos) e realizar testes, ajustes e
calibragens.
Captulo 5 Gesto 130
Tabela %%: Tabela resumida de atividades do rojeto
G!1po de T#!e9#& D## de In8(6o D## de T@!;6no Ho!#& E&6;#d#& Ho!#& T!#b#")#d#&
Re#"6V#! e&1do& d6%e!&o& 05/03/2012 20/02/2013 45,0 45,0
E&(!e%e! o !e"#P!6o 05/03/2012 30/04/2013 100,0 144,0
Ge!en(6#! o p!o5eo 05/03/2012 30/04/2013 80,0 80,0
Co;p!#! (o;ponene& 05/03/2012 21/02/2013 28,0 40,0
13/08/2012 02/11/2012 80,0 80,0
30/07/2012 20/01/2013 70,0 84,0
17/09/2012 23/12/2012 36,0 29,0
23/10/2012 06/12/2012 88,0 88,0
08/10/2012 18/04/2013 15,0 13,0
21/10/2012 10/03/2013 142,0 164,0
20/10/2012 05/02/2013 16,0 35,0
15/12/2012 18/01/2013 30,0 12,0
15/12/2012 04/02/2013 80,0 108,0
02/01/2013 23/02/2013 36,0 44,0
Mon#! o )expode 01/02/2013 30/2/2013 45,0 54,0
15/01/2013 28/02/2013 24,0 38,0
18/02/2013 13/04/2013 88,0 78,0
01/03/2013 13/04/2013 32,0 20,0
De&en%o"%e! o F6!;/#!e 18/02/2013 13/04/2013 32,0 32,0
24/03/2013 20/04/2013 20,0 22,0
02/01/2013 20/04/2013 52,0 16,0
Do(1;en#! o So9/#!e 07/04/2013 20/04/2013 40,0 57,0
15/03/2013 15/04/2013 36,0 28,0
08/03/2013 30/04/2013 157,0 266,0
To#" 05<03<2012 30<04<2013 1372=0 1577=0
E"#bo!#! e e&#! o& W&e!%o&
(#&e6!o&W
De&en%o"%e! # #!X16e1!#
de (on!o"e d# FPGA
I;p"e;en#! #& 91n2Ue&
b&6(#& do NIOS
E"#bo!#! o ;e(#n6&;o d#
(6ne;6(# 6n%e!&#
E"#bo!#! o& d6#7!#;#& de
H#!d/#!e
De&en%o"%e! #
(o;1n6(#23o d# e&#23o
b#&e (o; # FPGA
P!o5e#! o p!oo(o"o de #"o
n8%e"
De&en%o"%e! #
(o;1n6(#23o en!e d!6%e! e
&o9/#!e de 6ne!9#(e
P!o5e#! # PCI de
d6&!6b1623oQ #"6;en#23o e
&en&o!e&
De96n6! e e&#! 1;# 9one
de #"6;en#23o
De&e%o"%e! # 6ne!9#(e (o;
o& &en&o!e&
E&1d#! e e"#bo!#! o&
;o%6;eno&
De&en%o"%e! o So9/#!e d#
EB Yd!6%e!Z
De&en%o"%e! # b6b"6oe(#
do ("6ene
E"#bo!#! o& d6#7!#;#& de
So9/#!e
De&en%o"%e! o &o9/#!e d#
6ne!9#(e
Re#"6V#! e&e& de
6ne7!#23o 96n#"
O tempo total gasto no projeto registrado na tabela de atividades foi de 1577 horas,
mesmo esse tempo no sendo absoluto, pois muitas vezes difcil mensurar o tempo real
Captulo 5 Gesto 131
trabalhado em uma determinada tarefa, ele importante para manter um registro de horas
e ajudar em estimativas de trabalhos futuros. Como foram estimadas 1372 horas para
realizar o projeto, o calculo do erro entre o tempo estimado e o realizado foi de 13%,
cerca de 200 horas. Entretanto dois fatores contriburam para este valor no ser mais
elevado, primeiramente como o cronograma antigo no contemplava o nmero de horas
trabalhadas em cada tarefa o valor estimado foi igualado ao realizado em algumas tarefas
da parte inicial do projeto. Em segundo lugar, como o processo foi dividido em alguns
grupos de tarefas, grande parte das estimativas sugiram durante o prprio processo de
desenvolvimento, fazendo com que fosse possvel realizar algumas estimativas baseadas
no tempo gasto em tarefas anteriores.
%.3 -n2lise de Riscos
Durante o planejamento do projeto foram levantados seis principais riscos que
poderiam afetar o projeto de diferentes maneiras, podendo impactar no escopo,
cronograma ou oramento do projeto de alguma maneira. Esta seo tem como principal
objetivo apresentar como os riscos se desenvolveram durante o projeto e quais aes
foram tomadas para contorn-los. No Apndice F so apresentados os riscos
identificados de maneira mais detalhada com impacto, probabilidade e estratgias para
tentar reduzir o seu efeito negativo.
De todos os riscos levantados o "Erro na Estimativa de Tempo, Custo ou
Complexidade, risco 1 do Apndice F, foi o mais evidente e frequente durante a execuo
do projeto. Na seo anterior, Custos e Cronograma, foi apresentado o fato do projeto ter
ultrapassado o nmero de horas estimadas, entretanto, como foi realizado um esforo
adicional da equipe isso acabou por no impactar na data final de entrega do mesmo e
no foi necessrio realizar uma reduo de escopo para entreg-lo a tempo. Apesar de
grande parte das estimativas no coincidirem com o planejado, em termos de horas, foi
possvel realizar as tarefas dentro do intervalo de tempo estimado. Algumas tarefas como
o projeto das PCs e a implementao da cinemtica inversa passaram por constante
reviso e precisaram ser refeitos algumas vezes, fazendo com que as horas realizadas de
trabalho fossem bem maiores do que as estimadas. Outra etapa do projeto que acabou
demandando mais tempo do que o planejado foram as etapas de integrao do sistema,
pois alm de muitas vezes dependerem da presena de todos os membros da equipe
Captulo 5 Gesto 132
para a sua execuo, foram necessrios vrios testes e ajustes para garantir que tudo
estava funcionando conforme planejado.
Apesar do risco citado anteriormente ter sido o mais frequente durante a execuo
do projeto, a "Demora ou Atraso na Aquisio de Componentes, risco 2 do Apndice F, foi
provavelmente o risco que fez a equipe ficar mais receosa. Como muitos componentes
precisaram ser importados, para reduzir efetivamente os gastos ou por no haver
disponibilidade dos mesmos no Brasil, o projeto ficou muito suscetvel a dependncias
externas em uma fase crtica que poderia ter afetado diretamente o prazo de entrega. O
tempo de espera na alfndega, que pode variar de dias a meses, era o fator mais
significativo nesse atraso e, por se tratar de um rgo de fiscalizao federal, no havia
como a equipe, ou o vendedor do produto, fazerem nada para agilizar o processo.
Entretanto, nenhum dos componentes adquiridos demoraram tempo suficiente para
impactar o cronograma geral do projeto. A demora na chegada dos motores, comprados
no inicio de Dezembro e entregues somente no final de Janeiro, foi a nica situao que
quase levou a equipe a tomar uma ao imediata de aceitao do risco, fazendo com que
fosse necessrio realizar a compra de novos motores. Um dos motivos que agravou a
preocupao, e quase fez com que a equipe tomasse uma medida mais radical, foi o fato
do rastreamento dos correios no ter sido atualizado desde o envio do produto por parte
do vendedor.
O risco "Queima de Componente ou Componente Defeituoso, risco 4 do Apndice
F, ocorreu durante o projeto algumas vezes com componentes menores, entretanto de
fcil reposio. A nica ocasio que poderia ter acarretado em algum problema maior foi
um dos motores importados ter apresentado defeito de fabricao, entretanto a equipe
tinha tomado as devidas precaues comprando motores reservas e com isso o problema
foi resolvido de imediato. A "nexperincia da Tecnologia Utilizada, risco 5 do Apndice F,
foi outro risco presente no projeto, entretanto, como um perodo de estudos tinha sido
programado no inicio do cronograma a equipe j estava ciente e preparada para a
existncia deste problema. No foram encontradas ocorrncias evidentes dos outros dois
riscos levantados: "Erro nas Escolhas Tecnolgicas, risco 3 do Apndice F, e
"Documentao Errnea das Tecnologias utilizadas, risco 6 do Apndice F, durante a
execuo do projeto.
Captulo 5 Gesto 133
%." &onsidera'es
Apesar de no possuir um escopo completamente definido desde o inicio do
projeto, foi possvel realiz-lo sem grandes problemas que pudessem impactar o custo ou
o cronograma. Em termos de gastos monetrios o projeto com custo real de
aproximadamente R$2300,00 ficou dentro da faixa estimada, entre R$2000,00 e
R$2400,00, mesmo com as mudanas de abordagem realizadas durante a sua execuo.
O total de horas trabalhadas (1577 horas) foi superior ao total de horas estimadas
(1372 horas), entretanto, como foi possvel cumprir todos os objetivos propostos e dentro
do prazo, esse erro no apresentou impacto real no resultado final do projeto. Quanto aos
riscos no houve nenhum problema realmente srio que tenha impactado no
desenvolvimento do rob hexpode. Entretanto, a equipe reconhece ter corrido um alto
risco ao importar peas fundamentais do projeto, em uma etapa critica, e que poderia ter
acarretado srios problemas impedindo a concluso do projeto dentro do prazo.
Captulo 6 Trabalhos futuros 134
G T!#b#")o& 911!o&
O controle realizado para a movimentao atualmente open-loop, ou seja, no
envolve realimentao. Dessa forma, quando um movimento realizado, no h noo
precisa de quanto de deslocamento realmente ocorreu. nicialmente havia a ideia de
utilizar um acelermetro para estimar a distncia percorrida, mas percebeu-se que a
preciso obtida usando este procedimento muito ruim. Outra possibilidade era fazer uso
de um GPS, o que tambm foi descartado, pois na maioria das situaes o rob
utilizado em ambientes internos. Portanto, atualmente a estimativa de distncia feita
somente com base nos movimentos realizados, confiando na relao teoria-prtica da
cinemtica inversa. Diante das dificuldades encontradas, sugere-se para trabalhos futuros
procurar alguma forma melhor de realizar a odometria.
Uma boa distribuio de peso muito importante para que o rob consiga realizar
seus movimentos corretamente. No projeto, os motores foram calibrados manualmente
neste sentido, o que permitiu apenas eliminar as discrepncias mais grosseiras entre as
patas. Com sensores de presso nas patas, seria possvel avaliar de que forma a
distribuio de peso est ocorrendo, e ento ajust-la em tempo de execuo. Sugere-se
a adio de sensores de presso para trabalhos futuros.
Na poca do incio do projeto, no foram encontrados mdulos de comunicao
sem fio por Wi-Fi, que fossem comercialmente viveis, ento optou-se por utilizar
tecnologia ZigBee. Se fosse utilizada conexo por Wi-Fi, seria possvel aproveitar a
prpria infra-estrutura de rede para conectar o driver e o rob. Sugere-se como trabalho
futuro utilizar diretamente um hardware Wi-Fi conectado ao rob, que empregaria sockets
em lugar do canal de UART.
No projeto atual, tanto a alimentao dos motores como a alimentao da parte
lgica so feitas por cabo. Uma evoluo natural a utilizao de uma bateria junto do
corpo do hexpode, para que ele no tenha de ficar sempre prximo fonte de energia e
limitado pelo alcance do cabo. Entretanto, antes de realizar essa mudana, preciso
primeiramente reavaliar a capacidade dos servos, para verificar se so capazes de
suportar o peso adicional. Mesmo assim, sugere-se tal alterao para trabalhos futuros.
Atualmente so utilizados servos de hobby, que embora supram bem as
necessidades do projeto em termos de fora e preciso, so pouco eficientes: por
utilizarem no mximo 6V de tenso de alimentao, o consumo de corrente acaba ficando
Captulo 6 Trabalhos futuros 135
muito elevado. Seria uma boa opo utilizar servos com maior torque ou desenvolver
servos prprios a partir de motores DC de 12V ou superior, o que sugere-se para
trabalhos futuros.
Usou-se no projeto o MicroC/OS-, que um sistema operacional de tempo real
comercial. Ele gratuito para projetos com fins educacionais, como o caso do rob
hexpode, mas preciso comprar licenas para utiliz-lo comercialmente. Uma alternativa
seria empregar um sistema operacional gratuito, como o caso do FreeRTOS.
Captulo 7 Consideraes finais 136
H Con&6de!#2Ue& 96n#6&
O objetivo geral do projeto o desenvolvimento de um rob hexpode
implementado em um dispositivo de lgica reconfigurvel e controlado remotamente. Alm
de servir como forma de aplicao dos conhecimentos adquiridos durante o curso de
engenharia de computao, o projeto tem alguns objetivos especficos. Ele foi concebido
para ser expansvel, permitindo a adio de novas funcionalidades sem necessidade de
grandes alteraes. Outro objetivo especfico a diviso do sistema em trs partes: o
rob (sistema embarcado), a estao-base, com um driver de comunicao com o rob, e
a estao remota, com um software de alto nvel que comunica-se com o rob atravs do
driver da estao-base.
O rob desenvolvido controlado por FPGA, na qual foi utilizado um processador
embarcado de arquitetura RSC, o NOS , em conjunto com o sistema operacional
MicroC/OS-, desenvolvido pela empresa Micrium. Dentro da FPGA, existem diversos
blocos de hardware personalizados ligados ao processador, responsveis por realizar
funes de baixo nvel como gerao de PWM, clculo de cinemtica inversa, entre
outros. Os pinos de /O da FPGA so conectados a diversos dispositivos perifricos, como
o magnetmetro HMC5883, o mdulo ZigBee e dezoito optoacopladores. O
magnetmetro utilizado como bssola. O dispositivo ZigBee emula o funcionamento de
um canal de UART e utilizado para comunicao com um driver na estao base, de
onde o rob recebe instrues.
A estrutura mecnica do rob a MSR-H01, desenvolvida pela Micromagic
Systems. Esta estrutura de alumnio e necessita de trs servomotores por pata. Os
motores utilizados so semelhantes aos indicados na especificao da estrutura
mecnica: seis Corona DS329MG nas articulaes dos ombros, capazes de gerar um
torque de at 3,8 kgf.cm quando alimentados com 4,8 V, e doze BMS-620MG nas demais
articulaes, capazes de gerar torque de at 9,1 kgf.cm se alimentados com 4,8 V.
O circuito eletrnico do rob dividido em uma parte de baixa potncia (alimentada
por uma fonte DC comum 7.5V e 1A), cujo elemento central a FPGA, e outra de alta
potncia (alimentada por uma fonte ATX de 140W em regime na linha de 5V), cujos
elementos centrais so os dezoito servomotores. No h ligao eletrnica entre os dois
circuitos, que so optoacoplados.
Cada movimento do rob decomposto em uma srie de "setpoints, dados em
coordenadas cartesianas (x, y e z) das exterminadas de cada uma das patas, que passam
por algumas etapas antes de se transformarem em sinais de controle para servomotores.
A primeira etapa envolve o processamento das coordenadas cartesianas por um bloco de
cinemtica inversa (por hardware), que as converte em ngulos dos motores. Esses
ngulos so convertidos em larguras de pulso, e depois em sinais de PWM por outros
blocos, para ento serem enviados para os pinos de sada da FPGA. Estes pinos esto
ligados a optoacopladores, que funcionam como chaves no circuito de alta potncia,
resultando em sinais de PWM de maior potncia ligados aos servomotores, que s ento
mudam de posio.
H quatro elementos de software no projeto como um todo: firmware (software
embarcado), driver, biblioteca de comunicao e software de interface grfica. O firmware
controla a mquina de estados do hexpode, enviando para o hardware os movimentos
que devero ser executados pelo rob. O driver responsvel por comunicar-se com o
firmware atravs de um dispositivo ZigBee, recebendo comandos a partir de uma
biblioteca de comunicao. A biblioteca de comunicao utilizada pelo software de
interface grfica para envio de comandos a partir do driver.
Enquanto o firmware foi desenvolvido em linguagem C++, os demais elementos
foram desenvolvidos em linguagem Java. Todos os elementos de software foram
construdos sobre uma mesma biblioteca de baixo nvel, cuja implementao diferente
em cada linguagem. Em ambas as linguagens empregam-se meios de gerenciamento
automtico de memria: garbage collection em Java (o que nativo da mquina virtual
Java) e contagem de referncias em C++ (o que faz parte do cdigo desenvolvido).O
cdigo C++ ainda utiliza um mecanismo prprio de alocao de memria denominado
object pooling, que preserva as vantagens da alocao dinmica e da alocao esttica,
sem ter o no-determinismo inerente da alocao dinmica.
O desenvolvimento do projeto rob seguiu o modelo em espiral e foi feito de forma
modular, o que permitiu que diversas etapas fossem realizadas em paralelo. O tempo total
de trabalho em horas (somando os tempos gastos pelos trs membros) excedeu em
aproximadamente 15% o estimado, totalizando 1577 horas (de 1372 estimadas). Ao
trmino do desenvolvimento o plano de testes, que contemplou todos os requisitos
funcionais do projeto, foi executado com sucesso sem que houvesse maiores problemas.
O projeto exigiu grande parte dos conhecimentos adquiridos durante a formao de
engenharia de computao, especialmente referentes s disciplinas de Sistemas
Embarcados, Lgica Reconfigurvel, Engenharia de Software, Eletrnica , Redes de
Computadores e Comunicao de Dados. Conhecimentos no relacionados s disciplinas
da grade curricular tambm foram necessrios, como a cinemtica inversa e o projeto da
PC de alta potncia.
Geralmente robs hexpodes mais robustos tm custos elevados e documentao
fechada. O rob desenvolvido tem documentao completamente aberta em termos de
software e hardware, apesar de manter um custo elevado (cerca de R$ 2400,00). O
projeto ainda destaca-se por permitir expanses futuras: o hardware personalizado na
FPGA pode ser alterado e o software modular e bem documentado.
Referncias 139
Re9e![n(6#&
[1] RoboC1p$ Site oficial. Acessvel em: <http://www.robocup.org/>. Acessado em
20/04/2013.
[2] BTTCHER, S. (2006). P!6n(6p"e& o9 !obo "o(o;o6on$ Em Proc. Human Robot
nteraction Seminar SS2006, Univ. de Dortmund.
[3] SOYGUDER, S.,, ALL, H. (2007). De&67n #nd p!oo,pe o9 # &6x'"e77ed /#"S6n7
6n&e( !obo$ Em ndustrial Robot: An nternational Journal, v. 34, p. 412 - 422.
[4] B67Do7 ' T)e Mo& Ad%#n(ed Ro17)'Te!!#6n Robo on E#!)$ Boston Dynamics.
Site oficial. Acessado em 5 de abril de 2011. Acessvel em:
<http://www.bostondynamics.com/robot_bigdog.html>.
[5] WANG, Z.-Y, DNGA, X.-L., ROVETTA, A. (2010). An#",&6& o9 ,p6(#" "o(o;o6on o9
# &,;;e!6( )ex#pod !obo$ Em Robotica, v. 28, n..6.
[6] CAMPOS, R., MATOS, V., SANTOS, C. (2010). Hex#pod Lo(o;o6on* # Non"6ne#!
D,n#;6(#" S,&e;& App!o#()$ Em ECON 2010 - 36th Annual Conference on
EEE ndustrial Electronics Society, p. 1546 - 1551. SBN: 9781424452255.
[7] PAP,Z.,
,.,,.,AZ
,.,,P..Op6;6V#6on o9
)e Hex#pod Robo M#"S6n7 b, Gene6( A"7o!6);$ Em ntelligent Systems and
nformatics (SSY), 2010 8th nternational Symposium on 2010. p. 121 - 126. SBN:
781424473946.
[8] GO, Y. BOWLNG, A. (2005). A De&67n S1d, o9 # C#b"e'D!6%en Hex#pod$ Em
ntelligent Robots and Systems / EEE/RSJ nternational Conference, p. 671 - 678.
SBN: 0780389123.
[9] HOLLNGUM J. (1997). Hex#pod& o #Se o%e!\ Em ndustrial Robot: An
nternational Journal, v. 24, p. 428 - 431.
[10] BLASE, J., BONEV, ., MONSARRAT, B., BROT, S., LAMBERT, J.M., PERRON, C.
(2010). .6ne;#6( ()#!#(e!6&#6on o9 )ex#pod& 9o! 6nd1&!,$ Em ndustrial Robot:
An nternational Journal, v. 37, p. 79 - 88.
[11] KURPEL, F.D.; DO NASCMENTO, L.P.; HGASKNO, M.M.K., DA COSTA, R.F.
(2010). Rob O;n64 ' S6&e;# de N#%e7#23o do Rob O;n6d6!e(6on#"$
Monografia. Curso de Engenharia de Computao, Universidade Tecnolgica
Federal do Paran. Curitiba, 2010.
[12] E("6p&e ' T)e E("6p&e Fo1nd#6on open &o1!(e (o;;1n6, /eb&6e$ Site.
Referncias 140
Acessado em 26 de abril de 2011. Acessvel em: <http://www.eclipse.org>.
[13] REDA, S. (2007). Re(on9671!#b"e Co;p16n7$ Notas de Aula. Diviso de
Engenharia, Universidade de Brown.
[14] FPGA DEC'N#no$ Acessado em 31 de janeiro de 2013. Acessvel em:
<http://www.altera.com/education/univ/materials/boards/de0-nano/unv-de0-nano-
board.html>.
[15] T#%# L#n71#7e #nd =6!1#" M#()6ne Spe(696(#6on&$ Em Oracle. Acessvel em:
<http://docs.oracle.com/javase/specs/>. Acessado em 9 de abril de 2013.
[16] >1#!1& II Meb Ed66on So9/#!e$ Site oficial. Acessado em 31 de janeiro de 2013.
Acessado em: <http://www.altera.com/products/software/quartus-ii/web-edition/qts-
we-index.html>.
[17] C#dSo9 On"6ne* EAGLE P!od1( 6n9o!;#6on$ Site oficial. Acessado em 26 de abril
de 2011. Acessvel em: <http://www.cadsoft.de/info.htm>.
[18] T)e O996(6#" S6X16o Ho;ep#7e$ Site oficial. Acessvel em:
<http://www.stiquito.com>. Acessado em 22 de janeiro de 2013.
[19] SARANL, U., BUEHLER, M, KODTSCHEK, D.E. (2001). RHex* A S6;p"e #nd
H67)", Mob6"e Hex#pod Robo$ Em nternational Journal of Robotics Research, vol.
20, no. 7, pp. 616-631.
[20] RHex ' De%o1!& Ro17) Te!!#6n$ Boston Dynamics. Site oficial. Acessvel em
<http://www.bostondynamics.com/robot_rhex.html>. Acessado em 16 de fevereiro de
2013.
[21] L,nx;o6on Robo .6&$ Acessvel em <http://www.lynxmotion.com>. Acessado em
22 de janeiro de 2013.
[22] Hex, ' Open'So1!(eQ Lo/'Co& Hex#pod$ Em ArcBotics - gniting Open Robotics.
Acessvel em <http://arcbotics.com/products/hexy>. Acessado em 22 de janeiro de
2013.
[23] LOPES, C., CALORY FLHO, P., TEREZN, T.A. (2010). Rob Hexpode O!6en#do
p#!# Ap"6(#2Ue& Ped#7P76(#&$ Trabalho de Concluso de Curso (Graduao em
Engenharia Eletrnica) - Universidade Tecnolgica Federal do Paran.
[24] 0 USD IN BRL$ Google. Site. Acessado em 26 de abril de 2011. Acessvel em:
<http://www.google.com.br/searchq=1+usd+in+brl&ie=utf-8&oe=utf-8>.
[25] MERA. W.H.T., GOPPO, L.L., FONTOURA, F.M., LANES JUNOR, E.A. ,MARAL,
M.S. (2011). F1nI(on P!#n()# E"e!n6(#$ Monografia. Curso de Engenharia de
Computao, Universidade Tecnolgica Federal do Paran. Curitiba, 2010.
Referncias 141
[26] FPGA&$ M)# 6& #n FPGA\$ Acessado em 31 de janeiro de 2013. Acessvel em:
<http://www.altera.com/products/fpga.html>.
[27] FPGA F1nd#;en#"&$ Em National nstruments. Acessado em 31 de janeiro de
2013. Acessvel em: <http://www.ni.com/white-paper/6983/en>.
[28] N6o& II P!o(e&&o! Re9e!en(e H#ndbooS$ Manual. Acessado em 31 de janeiro de
2013. Acessvel em: <http://www.altera.com/literature/hb/nios2/n2cpu_nii5v1.pdf>.
[29] RTOS Con(ep&$ Em ChibiOS/RT Homepage. Acessado em 31 de janeiro de 2013.
Acessvel em: <http://www.chibios.org/dokuwiki/doku.php
id=chibios:articles:rtos_concepts>.
[30] DCEOS'II B T)e Re#"'T6;e .e!ne"$ Micrium. Site oficial. Acessado em 31 de janeiro
de 2013. Acessvel em: <http://micrium.com/rtos/ucosii/overview/>.
[31] So9/#!e De%e"op;en Too"& 9o! )e N6o& II P!o(e&&o!$ Altera. Site oficial.
Acessado em 31 de janeiro de 2013. Acessvel em:
<http://www.altera.com/devices/processor/nios2/tools/ide/ni2-ide.html>.
[32] Unde!&#nd6n7 F67Bee$ ZigBee Alliance. Site oficial Acessado em 31 de janeiro de
2013. Acessvel em: <http://www.zigbee.org/About/UnderstandingZigBee.aspx>.
[33] D676 XBee M6!e"e&& RF Mod1"e&$ Digi nternational. Acessado em 31 de janeiro de
2013. Acessvel em: <http://www.digi.com/xbee/>.
[34] XBee USB Ad#pe! Bo#!d$ Parallax nc. Site. Acessado em 31 de janeiro de 2013.
Acessvel em:
<http://www.parallax.com/Store/Accessories/CommunicationRF/tabid/161/ProductD/
643/List/0/Default.aspx>.
[35] Xbee Ad#pe! Bo#!d$ Parallax nc. Site. Acessado em 31 de janeiro de 2013.
Acessvel em:
<http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/xbee/List/0/SortFi
eld/4/ProductD/642/Default.aspx>.
[36] X'CTU So9/#!e$ Digi nternational. Site oficial. Acessado em 31 de janeiro de 2013.
Acessvel em: <http://www.digi.com/support/productdetailpid=3352>.
[37] A be76nne!]& 716de o #((e"e!o;ee!&$ Dimension Engineering. Site. Acessado em
31 de janeiro de 2013. Acessvel em:
<http://www.dimensionengineering.com/info/accelerometers>.
[38] ADXLA:<$ Analog Devices. Datasheet. Acessado em 31 de janeiro de 2013.
Acessvel em: <http://www.analog.com/static/imported-
files/data_sheets/ADXL345.pdf>.
Referncias 142
[39] Ho/ &199 /o!S&\ ' M#7neo;ee!$ HowStuffWorks. Site. Acessado em 31 de
janeiro de 2013. Acessvel em: <http://science.howstuffworks.com/magnetometer-
info.htm>.
[40] HMC<IIAL$ Honeywell. Datasheet. Acessado em 31 de janeiro de 2013. Acessvel
em: <http://www51.honeywell.com/aero/common/documents/myaerospacecatalog-
documents/Defense_Brochures-documents/HMC5883L_3-
Axis_Digital_Compass_C.pdf>.
[41] MSR'HC0 Hex#pod .6$ Micromagic Systems. Site oficial. Acessado em 31 de
janeiro de 2013. Acessvel em:
<http://www.hexapodrobot.com/products/robots/Hexapod_MSR-H01.html>.
[42] AN'<<G In!od1(6on o Po/e! S1pp"6e&$ Texas nstruments. Application Report.
Acessado em 10 de fevereiro de 2013. Acessvel em:
<http://www.ti.com/lit/an/snva006b/snva006b.pdf>.
[43] BMS'G4CMG B P#!6(1"#! Spe(696(#6on$ Blue Bird Technology. Em BP Hobbies.
Acessado em 10 de fevereiro de 2013. Acessvel em:
<http://www.bphobbies.com/pdf/BMS-620MG.pdf>.
[44] Co!on# DSA4KMG$ Corona. Site Oficial. Acessado em 10 de fevereiro de 2013.
Acessvel em: <http://www.corona-rc.com/coproductshowE.aspArticleD=179>.
[45] CRAG, J.J. (2004). In!od1(6on o Robo6(&$ 3 edio, pginas: 28; 62; 90.
Pearson Prentice Hall.
[46] BUSS, S.R. (2009). In!od1(6on o In%e!&e .6ne;#6(& /6) T#(ob6#n
T!#n&po&eQ P&e1do6n%e!&e #nd D#;ped Le#& SX1#!e& ;e)od&$ Departamento
de Matemtica, Universidade da Califrnia, San Diego. Acessado em 1 de abril de
2013. Acessvel em:
<http://math.ucsd.edu/sbuss/ResearchWeb/ikmethods/iksurvey.pdf>.
[47] FSCHER, M. (2007). In%e!&e .6ne;#6S$ Notas de Aula. FH Mnchen.
[48] T,pe& o9 Robo G#6$ Hexapod Robots - The Future of Robotics. site. Acessado em
05/05/2013. Acessvel em: <http://hexapodrobots.weebly.com/types-of-robot-
gait.html>.
[49] An#",&6& o9 M1"6'Le77ed An6;#" R Robo G#6&$ Oricom Technologies Site.
Acessado em 05/05/2013. Acessvel em: <http://www.oricomtech.com/projects/leg-
time.htm>.
[50] SAWCZ, D. Hobb, Se!%o F1nd#;en#"&$ Artigo tcnico. Acessado em 1 de
fevereiro de 2013. Acessado em:
Referncias 143
<http://www.princeton.edu/mae412/TEXT/NTRAK2002/292-302.pdf>.
[51] I4C'B1&* M)#^& )#\ Site. Acessado em 31 de janeiro de 2013. Acessvel em:
<http://www.i2c-bus.org/>.
[52] I4C B#(S7!o1nd$ Total Phase. Artigo tcnico. Acessado em 31 de janeiro de 2013.
Acessvel em: <http://www.totalphase.com/support/kb/10037/>.
[53] I4C$ Mikrocontroller.net. Site. Acessado em 31 de janeiro de 2013. Acessvel em:
<http://www.mikrocontroller.net/articles/2C>.
[54] WLSON, P.R., JOHNSTONE, M.S., NEELY, M., BOLES, D. (1995). D,n#;6(
So!#7e A""o(#6on* A S1!%e, #nd C!66(#" Re%6e/$ Em WMM 95 Proceedings of
the nternational Workshop on Memory Management, pgs 1-116. Springer-Verlag.
[55] RUGGER, C., MURTAGH, T.P. (1988). L69e6;e #n#",&6& o9 d,n#;6(#"", #""o(#ed
ob5e(&$ Em POPL 88 Proceedings of the 15th ACM SGPLAN-SGACT symposium
on Principles of programming languages, pginas 285-293. ACM.
[56] SAKS, D. (2008). T)e ,6n #nd ,#n7 o9 d,n#;6( #""o(#6on$ Embedded. Artigo.
Acessvel em: <http://www.embedded.com/4007569>. Acessado em 9 de abril de
2013.
[57] WLTAMUTH, S., HEJLSBERG, A (2003). C_ L#n71#7e Spe(696(#6on$ MSDN.
Especificao. Acessvel em: <http://msdn.microsoft.com/en-
us/library/aa645596.aspx>. Acessado em 9 de abril de 2013.
[58] PTTS, R.. In!o o D,n#;6( A""o(#6on$ Material didtico. Em Boston University
Computer Science Teaching Material Archive. Acessvel em
<http://www.cs.bu.edu/teaching/c/alloc/intro/>. Acessado em 9 de abril de 2013.
[59] DOUGLASS, B.P. (2003). Re#"'T6;e De&67n P#e!n&* Rob1& S(#"#b"e
A!()6e(1!e 9o! Re#"'6;e S,&e;&$ Livro. Addison-Wesley Professional.
[60] NYSTROM, R (2011). Op6;6V6n7 P#e!n&* Ob5e( Poo"$ Game Programming
Patterns. Acessado em 28 de fevereiro de 2013. Acessvel em
<http://gameprogrammingpatterns.com/object-pool.html>. Acessado em 9 de abril de
2013.
[61] C!e#6on#" P#e!n&* Ob5e( Poo"$ OODesign: Object Oriented Design. Site.
Acessvel em: <http://www.oodesign.com/object-pool-pattern.html>. Acessado em 9
de abril de 2013.
[62] XE, Y., AKEN, A. (2005). Conex' #nd P#)'&en&66%e Me;o!, Le#S Dee(6on$
Em Proceedings of the 10th European software engineering conference held jointly
with 13th ACM SGSOFT international symposium on Foundations of software
Referncias 144
engineering, pginas 115 - 125. ACM.
[63] KULKARN, M. (2012). Po6ne! C)e(Se! o dee( b199e! o%e!9"o/& #nd d#n7"6n7
po6ne!& +p#! 4-$ Em ntel Software. Acessvel em: <http://software.intel.com/en-
us/articles/pointer-checker-to-detect-buffer-problems-and-dangling-pointers-part-2>.
Acessado em 9 de abril de 2013.
[64] MYTTON, D. (2004). M), `o1 Need Cod6n7 S#nd#!d&$ Artigo. Em sitepoint.
Acessvel em <http://www.sitepoint.com/coding-standards/>. Acessado em 9 de abril
de 2013.
[65] T#%# Code Con%en6on& (1997). Sun Microsystems. Especificao. Acessvel em
<http://www.oracle.com/technetwork/java/codeconventions-150003.pdf>. Acessado
em 9 de abril de 2013.
[66] JONES, D. (2008). Ope!#nd n#;e& 6n9"1en(e ope!#o! p!e(eden(e de(6&6on&
+p#! 0 o9 4- ' Expe!6;en pe!9o!;ed # )e 4CCH ACCU Con9e!en(e$ Acessvel
em <http://www.knosof.co.uk/cbook/oprandname.pdf>. Acessado em 9 de abril de
2013.
[67] GNU Cod6n7 S#nd#!d&$ Free Software Foundation. Especificao. ltima
atualizao em 8 de maro de 2013. Acessvel em
<http://www.gnu.org/prep/standards/>. Acessado em 9 de abril de 2013.
[68] WENBERGER, B., SVERSTEN, C., ETZMANN, G. MENTOVA, M., LANDRAY, T.
Goo7"e CRR S,"e G16de$ Especificao. Reviso 3245. Acessvel em
<http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml>. Acessado em 9
de abril de 2013.
[69] Do(1;en#6on* SOPC B16"de!$ Altera. Documentao. Acessado em 13 de
fevereiro de 2013. Acessvel em: <http://www.altera.com/literature/lit-sop.jsp>.
[70] Me;o!, S,&e; De&67n$ Altera. Documentao. Acessado em 14 de fevereiro de
2013. Acessvel em: <http://www.altera.com/literature/hb/nios2/edh_ed51008.pdf>.
[71] DEC'N#no a N6o&II /6) SDRAM$ eStuffz. Site. Acessado em 14 de fevereiro de
2013. Acessvel em: <https://sites.google.com/site/fpgaandco/de0-nano-niosii-with-
sdram>.
[72] I4C +OpenCo!e&-$ Altera Wiki. Site. Acessado em 11 de fevereiro de 2013. Acessvel
em: <http://www.alterawiki.com/wiki/2C_(OpenCores)>.
[73] Robo6(& Too"box$ PeterCorke. Site. Acessado em 31 de janeiro de 2013. Acessvel
em: <http://www.petercorke.com/Robotics_Toolbox.html>.
[74] Den#%6'H#!enbe!7'No#6on$ Acessado em 31 de janeiro de 2013. Acessvel em:
Referncias 145
<https://www.fh-
muenster.de/fb11/labore/forschung/robotertechnik/downloads/Denavit_Hartenberg_N
otation.pdf>.
[75] =HDL 91n(6on 9o! 96nd6n7 &X1#!e !oo$ VHDL coding tips and tricks. Site.
Acessado em 31 de janeiro de 2013. Acessado em:
<http://vhdlguru.blogspot.com.br/2010/03/vhdl-function-for-finding-square-root.html>.
[76] BARR, M. (2007). In!od1(6on o P1"&e M6d) Mod1"#6on +PMM-$ BarrGroup.
Site. Acessado em 10 de fevereiro de 2013. Acessvel em:
<http://www.barrgroup.com/Embedded-Systems/How-To/PWM-Pulse-Width-
Modulation>.
[77] SOPC B16"de! U&e! G16de$ Altera. Manual. Acessado em 31 de janeiro de 2013.
Acessvel em: <http://www.altera.com/literature/ug/ug_sopc_builder.pdf>.
[78] OpenCo!e&$ Site. Acessado em 11 de fevereiro de 2013. Acessvel em:
<http://opencores.org/>.
[79] I4C (on!o""e! (o!e ** O%e!%6e/$ OpenCores. Site. Acessado em 11 de fevereiro de
2013. Acessvel em: <http://opencores.org/project,i2c>.
[80] M6&)bone B: ' MISHBONE S,&e;'on'C)6p +SoC- Ine!(onne(6on A!()6e(1!e
9o! Po!#b"e IP Co!e&$ OpenCores. Documentao. Acessado em 11 de fevereiro de
2013. Acessvel em: <http://cdn.opencores.org/downloads/wbspec_b4.pdf>.
[81] A%#"on Ine!9#(e ' Spe(696(#6on&$ Altera. Documentao. Acessado em 11 de
fevereiro de 2013. Acessvel em:
<http://www.altera.com/literature/manual/mnl_avalon_spec.pdf>.
[82] HERVELLE, R. (2003). I4C'M#&e! Co!e Spe(696(#6on$ OpenCores.
Documentao. Acessado em 1 de fevereiro de 2013. Acessvel em:
<http://opencores.org/websvn,filedetailsrepname=i2c&path=%2Fi2c%2Ftrunk
%2Fdoc%2Fi2c_specs.pdf>.
[83] Se!%o Moo! Moo!e()$ Motor tech. Site oficial. Acessado em 16 de abril de 2013.
Acessado em: <http://www.motortech.com.br/index.php/produtos/servo-motor>.
[84] PCB T!#(e M6d) C#"(1"#o!$ Reference Designer. Site. Acessado em 18 de abril de
2013. Acessvel em: <http://www.referencedesigner.com/cal/cal_06.php>.
[85] Con%e! #n ATX PSU o # Ben() Po/e! S1pp",$ Basic Electronics Tutorials Blog.
Site. Acessado em 17 de fevereiro de 2013. Acessvel em: <http://www.electronics-
tutorials.ws/blog/convert-atx-psu-to-bench-supply.html>.
[86] MSR'HC0 A&&e;b", G16de$ Micromagic Systems. Guia. Acessado em 10 de abril
Referncias 146
de 2013. Acessvel em:<http://www.hexapodrobot.com/Files/Guides/MSR-
H01_Assembly.pdf>.
[87] T#be"# de (ond1o!e& de (ob!e$ Departamento de Engenharia de Materiais - USP.
Material didtico. Acessado em 19 de abril de 2013. Acessvel
em:<http://www.demar.eel.usp.br/eletronica/aulas/Tabela_condutores_cobre.pdf>.
[88] MAZERO, C.A. (2011). Sistemas Operacionais (incompleto). Livro aberto.
[89] HEBEL, M. BRCKER, G. HARRS, D. (2010). Ge6n7 S#!ed /6) XBee RF
Mod1"e& ' A T1o!6#" 9o! BASIC S#;p #nd P!ope""e! M6(!o(on!o""e!&, v. 1.0.
Parallax nc.
[90] RFC HKA* T!#n&;6&&6on Con!o" P!oo(o" ' DARPA Ine!ne P!o7!#; P!oo(o"
Spe(696(#6on (1981). nternet Engineering Task Force (ETF). Especificao tcnica.
[91] COULOURS, G.F. DOLLMORE, J. KNDBERG, T. (2001). D6&!6b1ed S,&e;&*
Con(ep& #nd De&67n$ 3 edio. Pearson Education.
[92] MAZRES, D. M, R#n on CRR^& ope!#o! ne/$ Artigo tcnico. Acessvel em
<http://www.scs.stanford.edu/dm/home/papers/c++-new.html>. Acessado em 9 de
abril de 2013.
[93] n!5#%#&e!6#" ' Ne1!on Robo6(& T#%# Se!6#" L6b!#!,$ Google Project Hosting. Site.
Acessvel em <http://code.google.com/p/nrjavaserial/>. Acessado em 20 de abril de
2013.
Apndice A: Movimentos suportados pelo rob 147
Ap[nd6(e A* Mo%6;eno& &1po!#do& pe"o !ob
Mo%6;eno CPd67o de 6po P#!J;e!o& De&(!623o
And#! 9x"G8 Passos frente (4 bytes)
O rob anda em frente um certo nmero de
passos. Se o nmero de passos for negativo,
o rob anda para trs.
And#! de "#do 9xG9" Passos direita (4 bytes)
O rob anda para a direita um certo nmero
de passos. Se o nmero de passos for
negativo, o rob anda para a esquerda.
G6!#! 9xG"A ngulo 1024 (4 bytes)
O rob gira um certo nmero de ngulos no
sentido horrio. Se o nmero de ngulos for
negativo, o rob gira no sentido anti-horrio.
O")#! p#!# 9xA9" ngulo 1024 (4 bytes)
O rob gira para um certo ngulo no sentido
horrio em relao ao leste. Se o nmero de
ngulos for negativo, o ngulo de destino no
sentido anti-horrio em relao ao leste.
And#! p#!# 9x!"G"
ngulo 1024 (4 bytes)
Passos frente (4 bytes)
O rob caminha em frente um certo nmero
de passos na direo a certo ngulo no
sentido horrio em relao ao leste. Se o
nmero de ngulos for negativo, o ngulo de
destino no sentido anti-horrio em relao
ao leste. Se o nmero de passos for negativo,
o rob anda para trs.
B#;bo"e#! 9xG9G" Nmero de ciclos (4 bytes)
O rob faz movimento de bambolear um certo
nmero de vezes.
F#Ve! 9"exUe& 9xA9&8 Nmero de flexes (4 bytes) O rob faz um certo nmero de flexes.
C#"6b!#!E#51&#! 9xA8G9 Nenhum
O rob gira no prprio eixo para calibrar o
magnetmetro.
Apndice B: Sensores suportados pelo rob 148
Ap[nd6(e B* Sen&o!e& &1po!#do& pe"o !ob
Sen&o! CPd67o de 6po Fo!;#o d# "e61!# De&(!623o
A(e"e!;e!o 9xA8A"
Leitura em X (2 bytes)
Leitura em Y (2 bytes)
Leitura em Z (2 bytes)
Mede a acelerao nos trs eixos, em
cm/s.
M#7ne;e!o 9xG9G"
Leitura em X (2 bytes)
Leitura em Y (2 bytes)
Leitura em Z (2 bytes)
ngulo 64 (2 bytes)
Mede o campo magntico nos trs
eixos, e o ngulo em relao ao leste.
Apndice C: Mensagens do protocolo entre rob e driver 149
Ap[nd6(e C* Men&#7en& do p!oo(o"o en!e !ob e d!6%e!
Men&#7en& do d!6%e! p#!# o !ob
Men&#7e; CPd67o Co!po De&(!623o
H#nd&)#Se
9x9999
Lre2uisi*HoM
Vazio
Verificar se h conexo com o rob.
9x999%
LresostaM
Vazio
C)e(SS#1&
9x999+
Lre2uisi*HoM
Vazio
Verificar estado do rob.
Resultados:
0x00 = parado
0xFF = movimento em andamento
9x999,
LresostaM
Estado (1 byte)
H#"
9x99+9
Lre2uisi*HoM
Vazio
Faz o movimento atual do rob parar.
O movimento em andamento no para no instante que a
mensagem respondida, mas sim aps o trmino do ciclo
atual.
9x99+%
LresostaM
Vazio
SeMo%e;en
9x99++
Lre2uisi*HoM
Movimento (2 bytes)
dentificador (4 bytes)
Parmetros (varivel)
Definir o movimento seguinte do rob, associado a um
identificador de 4 bytes definido pelo cliente.
Caso o movimento no seja compreendido pelo rob,
enviada uma resposta com tipo 0x0021 (halt).
9x99+,
LresostaM
Vazio
Mo%e
9x99+6
Lre2uisi*HoM
Vazio
nicia a execuo do movimento seguinte do rob e limpa
a varivel que armazena o movimento seguinte.
Caso no haja movimento seguinte, essa operao no
tem efeito.
9x99+3
LresostaM
Vazio
Fe()Sen&o!
9x9969
Lre2uisi*HoM
Sensor (2 bytes)
Faz a leitura de um sensor. O valor lido no o valor no
instante do recebimento da mensagem, mas sim o valor
da ltima leitura feita pelo rob.
Caso o rob no tenha o sensor, a resposta enviada
com corpo vazio.
9x996%
LresostaM
Leitura (varivel)
E!!o!No696(#6on
9x99!8
Lre2uisi*HoM
Vazio ndica que ocorreu um erro com o driver.
Essa mensagem no utilizada na verso atual do
protocolo.
9x99!!
LresostaM
Vazio
Apndice C: Mensagens do protocolo entre rob e driver 150
Men&#7en& do !ob p#!# o d!6%e!
.eepA"6%e
9x9%99
Lre2uisi*HoM
Vazio Verificar se h conexo com o driver.
protocolo.
9x9%9%
LresostaM
Vazio
Mo%e;en
F6n6&)ed
No696(#6on
9x9%9+
Lre2uisi*HoM
Tamanho (4 bytes)
ndica que um movimento associado a um identificador de
4 bytes definido pelo cliente foi terminado com sucesso. A
mensagem tambm acompanha um valor numrico que
indica o tamanho do movimento, cuja interpretao varia
de um movimento para outro.
9x9%9,
LresostaM
Vazio
Mo%e;en
Abo!ed
No696(#6on
9x9%96
Lre2uisi*HoM
Valor (4 bytes)
Tamanho (4 bytes)
4 bytes definido pelo cliente foi abortado. A mensagem
tambm acompanha valores numricos que indicam o
valor atual do movimento e seu tamanho, cuja
interpretao varia de um movimento para outro.
9x9%93
LresostaM
Vazio
Apndice D: Mensagens do protocolo entre cliente e driver 151
Ap[nd6(e D* Men&#7en& do p!oo(o"o en!e ("6ene e d!6%e!
Men&#7en& do ("6ene p#!# o d!6%e!
En1;e!#ePo!&
9x4999
Lre2uisi*HoM
Vazio
Enumerar as portas disponveis no computador no qual o
driver est sendo executado.
A verso atual do rob opera sobre canais seriais apenas,
ento essa mensagem enumera as portas seriais.
A lista de portas codificada em ASC e as portas so
separadas por `\n`.
9x499%
LresostaM
Lista (varivel)
OpenPo!
9x499+
Lre2uisi*HoM
Porta (varivel)
Tenta estabelecer a conexo com o rob conectado a
certa porta. O nome da porta codificado em ASC.
Resultados:
0x00 = sucesso
0x01 = timeout
0x02 = j estava conectado
0x04 = porta invlida
9x499,
LresostaM
Resultado (1 byte)
Be76nMo%e;en
9x4949
Lre2uisi*HoM
Movimento (2 bytes)
Parmetros (varivel)
Tenta comandar o rob para iniciar um movimento. O
movimento codificado da mesma forma que no protocolo
entre o driver e o rob.
Resultados:
0x00 = sucesso
0x01 = timeout
0x02 = no est conectado ao rob
0x04 = movimento desconhecido/invlido
9x494%
LresostaM
Resultado (1 byte)
H#"Mo%e;en
9x494+
Lre2uisi*HoM
Vazio
Tenta comandar o rob para parar o movimento atual.
Resultados:
0x00 = sucesso
0x01 = timeout
0x02 = no est conectado ao rob
9x494,
LresostaM
Resultado (1 byte)
Re#dSen&o!
9x49G9
Lre2uisi*HoM
Sensor (2 bytes)
Tenta fazer a leitura de um sensor do rob.
Resultados:
0x00 = sucesso
0x01 = timeout
0x02 = no est conectado ao rob.
0x04 = sensor desconhecido/invlido
9x49G%
LresostaM
Resultado (1 byte)
Leitura (varivel)
E!!o!No696(#6on
9x49!8
Lre2uisi*HoM
Vazio ndica que ocorreu um erro com o cliente.
protocolo.
9x49!!
LresostaM
Vazio
Apndice D: Mensagens do protocolo entre cliente e driver 152
Men&#7en& do d!6%e! p#!# o ("6ene
P6n7
9xG999
Lre2uisi*HoM
Vazio
Verificar se h conexo com o cliente.
9xG99%
LresostaM
Vazio
Mo%e;en
F6n6&)ed
No696(#6on
9xG%9+
Lre2uisi*HoM
Tamanho (4 bytes)
4 bytes definido pelo cliente foi terminado com sucesso. A
mensagem tambm acompanha um valor numrico que
indica o tamanho do movimento, cuja interpretao varia
de um movimento para outro.
9xG%9,
LresostaM
Vazio
Mo%e;en
Abo!ed
No696(#6on
9xG%96
Lre2uisi*HoM
Valor (4 bytes)
Tamanho (4 bytes)
4 bytes definido pelo cliente foi abortado. A mensagem
tambm acompanha valores numricos que indicam o
valor atual do movimento e seu tamanho, cuja
interpretao varia de um movimento para outro.
9xG%93
Lre2uisi*HoM
Vazio
Apndice E: Tabela completa de atividades realizadas 153
Ap[nd6(e E* T#be"# (o;p"e# de #6%6d#de& !e#"6V#d#&
G!1po T#!e9# S#1& D## de In8(6o D## de T@!;6no Ho!#& E&6;#d#& Ho!#& T!#b#")#d#&
Re#"6V#! e&1do& d6%e!&o& Realizar estudos diversos 100% 05/03/2012 20/02/2013 45,0 45,0
E&(!e%e! o !e"#P!6o Escrever o relatrio 100% 05/03/2012 30/04/2013 100,0 144,0
Ge!en(6#! o p!o5eo Realizar reunies e ajustes de cronograma 100% 05/03/2012 30/04/2013 80,0 80,0
Co;p!#! (o;ponene&
Comprar FPGA 100% 05/03/2012 05/03/2012 3,0 3,0
Comprar mdulo XBee 100% 05/03/2012 05/03/2012 3,0 2,0
Comprar os servos de teste 100% 20/08/2012 20/08/2012 3,0 4,0
Comprar componentes da placa de teste 100% 20/09/2012 20/09/2012 3,0 6,0
Comprar os sensores 100% 08/01/2013 08/01/2013 3,0 4,0
Comprar os optoacopladores 100% 18/01/2013 18/01/2013 3,0 5,0
Comprar a estrutura mecnica [importada] 100% 26/11/2012 26/11/2012 3,0 5,0
Comprar os servos definitivos [importados] 100% 06/12/2012 06/12/2012 3,0 7,0
Comprar os componentes da PC final 100% 21/02/2013 21/02/2013 4,0 4,0
Definir o controle do servo 100% 04/09/2012 09/04/2012 4,0 4,0
Criar o diagrama de controle do servo caseiro
100%
13/08/2012 18/08/2012 4,0 4,0
Realizar testes simples com os servos 100% 06/09/2012 03/10/2012 6,0 6,0
100%
24/09/2012 14/10/2012 12,0 12,0
100%
22/10/2012 02/11/2012 14,0 14,0
100%
27/10/2012 02/11/2012 40,0 40,0
Desenvolver bloco de controle do servo 100% 30/07/2012 03/08/2012 2,0 12,0
Desenvolver bloco de controle de uma junta 100% 01/10/2012 05/10/2012 4,0 6,0
Desenvolver bloco de controle de uma pata 100% 08/10/2012 12/11/2012 24,0 24,0
100%
01/10/2012 05/10/2012 2,0 2,0
100%
01/10/2012 12/10/2012 8,0 8,0
Ajustar o NOS com os blocos de controle 100% 01/10/2012 15/01/2013 20,0 20,0
100%
01/10/2013 20/01/2013 10,0 12,0
Realizar configuraes bsicas do NOS 100% 17/09/2012 24/09/2012 12,0 12,0
100%
01/10/2012 12/10/2012 4,0 4,0
100%
05/11/2012 23/12/2012 14,0 10,0
100%
14/12/2012 23/12/2012 6,0 3,0
Elaborar o modelo 1 [soluo incremental] 100% 23/10/2012 23/10/2012 8,0 8,0
mplementar em C o modelo 1 100% 24/10/2012 31/10/2012 24,0 24,0
Testar o modelo 1 na estao base 100% 29/10/2012 31/10/2012 4,0 4,0
Testar o modelo 1 no NOS 100% 31/10/2012 12/11/2012 4,0 4,0
Otimizar o modelo 1 para o NOS 100% 31/10/2012 12/11/2012 12,0 12,0
Elaborar o modelo 2 [soluo geomtrica] 100% 17/11/2012 19/11/2012 4,0 4,0
mplementar em C o modelo 2 100% 19/11/2012 19/11/2012 2,0 2,0
Testar o modelo 2 no NOS 100% 20/11/2012 20/11/2012 2,0 2,0
mplementar o modelo 2 em VHDL 100% 20/11/2012 27/11/2012 16,0 16,0
Testar o modelo 2 em VHDL 100% 20/11/2012 06/12/2012 4,0 4,0
Otimizar o modelo 2 em VHDL 100% 20/11/2012 06/12/2012 8,0 8,0
E"#bo!#! e e&#! o& W&e!%o&
(#&e6!o&W
Projetar a malha caseira de controle com o
555
Testar a malha de controle com os servos
abertos
Elaborar e testar a placa simples [soldada]
com o controle do servo
De&en%o"%e! # #!X16e1!#
de (on!o"e d# FPGA
Desenvolver o interfaceamento serial com o
NOS
Desenvolver o interfaceamento SP com o
NOS
Desenvolver o nterfaceamento do 2C com
NOS
I;p"e;en#! #& 91n2Ue&
b&6(#& do NIOS
mplementar a leitura de dados do
acelermetro
Escrever as coordenadas de deslocamento
das patas
Utilizar um RTOS embarcado como SO no
NOS
E"#bo!#! o ;e(#n6&;o d#
(6ne;6(# 6n%e!&#
100%
16/02/2013 25/02/2013 1,0 1,0
100%
08/10/2012 10/12/2012 3,0 3,0
100% 08/10/2012 10/12/2012 2,0 2,0
Organizar os diagramas da PC 100% 16/02/2013 18/04/2013 1,0 1,0
100%
16/02/2013 18/04/2013 8,0 6,0
mplementar o cdigo em ANS-C 100% 21/10/2012 14/11/2012 16,0 16,0
Portar o cdigo existente para C++ 100% 14/11/2012 03/12/2012 4,0 4,0
Elaborar as classes base do sistema 100% 14/11/2012 22/12/2012 8,0 8,0
mplementar e testar o cdigo em Windows 100% 21/10/2012 22/12/2012 36,0 36,0
Elaborar o protocolo de baixo nivel 100% 01/12/2012 03/12/2012 8,0 8,0
mplementar o protocolo de baixo nivel 100% 03/12/2012 22/12/2012 8,0 10,0
100%
04/02/2013 12/02/2013 6,0 20,0
100%
12/02/2013 20/02/2013 4,0 10,0
100%
20/02/2013 28/02/2013 12,0 12,0
100%
15/12/2012 28/02/2013 20,0 12,0
100%
20/02/2013 10/03/2013 20,0 28,0
100%
20/10/2012 05/02/2013 8,0 21,0
100%
20/10/2012 05/02/2013 8,0 14,0
100%
15/12/2012 18/01/2013 30,0 12,0
100%
15/12/2012 06/01/2013 8,0 4,0
Elaborar circuito de alimentao do hexpode
100%
06/01/2013 13/01/2013 8,0 6,0
Criar o projeto das PCs no Eagle 100% 14/01/2013 25/01/2013 36,0 65,0
100%
22/01/2013 30/01/2013 24,0 30,0
Encomendar a PC 100% 04/02/2013 04/02/2013 4,0 3,0
100%
02/01/2013 09/01/2013 4,0 4,0
100%
09/01/2013 13/01/2013 12,0 8,0
Adquirir uma fonte de alimentao 100% 13/01/2013 31/01/2013 4,0 3,0
ntegrar e testar a fonte com o sistema 100% 15/02/2013 23/02/2013 8,0 11,0
Projetar e confeccionar o cabo extensor 100% 15/02/2013 23/02/2013 8,0 18,0
Mon#! o )expode
Montar das partes mecnicas 100% 02/02/2013 03/02/2013 9,0 18,0
100%
07/02/2013 07/02/2013 15,0 10,0
Adicionar as PCs a estrutura mecnica 100% 20/02/2013 23/02/2013 6,0 6,0
Testar o controle simples com a estrutura 100% 01/02/2013 30/02/2013 15,0 20,0
nterfacear o acelermetro com NOS 100% 15/01/2013 30/01/2013 4,0 4,0
nterfacear o giroscpio com NOS 100% 15/01/2013 30/01/2013 4,0 2,0
nterfacear o magnetmetro com NOS 100% 15/01/2013 30/01/2013 4,0 2,0
ntegrar a coleta de dados 100% 16/02/2013 28/02/2013 12,0 30,0
Estudar o movimento de hexpodes 100% 18/02/2013 28/02/2013 24,0 8,0
Definir e implementar os movimentos 100% 01/03/2013 05/04/2013 48,0 50,0
Testar os movimentos 100% 01/03/2013 13/04/2013 16,0 20,0
Elaborar o sistema de controle 100% 01/03/2013 01/04/2013 8,0 8,0
mplementar o sistema de controle 100% 24/03/2013 13/04/2013 24,0 12,0
E"#bo!#! o& d6#7!#;#& de
H#!d/#!e
Organizar os diagramas do circuitos internos
da FPGA
Elaborar o diagrama geral da arquitetura do
sistema
Elaborar o diagrama de blocos do circuito
eletrnico
Elaborar um fluxograma completo de um
comando
De&en%o"%e! #
(o;1n6(#23o d# e&#23o
b#&e (o; # FPGA
mplementar o protocolo de alto nvel do driver
em C++
Traduzir o protocolo de alto nvel do driver
para Java
mplementar o protocolo de alto nvel do driver
em Java
mplementar as classes base em RTOS
embarcado
mplementar o protocolo de alto nvel no
sistema embarcado
P!o5e#! o p!oo(o"o de
#"o n8%e"
Elaborar o protocolo de alto nivel entre
sistema embarcado e o driver
Elaborar o protocolo de alto nivel entre driver e
cliente
De&en%o"%e! #
(o;1n6(#23o en!e d!6%e!
e &o9/#!e de 6ne!9#(e
Traduzir de C++ para Java as classes de
comunicao
P!o5e#! # PCI de
d6&!6b1623oQ #"6;en#23o e
&en&o!e&
Elaborar circuito de interface da FPGA com
sensores e atuadores
Realizar testes, definir e realizar ajustes no
diagrama
De96n6! e e&#! 1;# 9one
de #"6;en#23o
Estimar o gasto de energia total e de cada
parte do hexpode
Definir uma fonte de alimentao para ser
utilizada
Encaixar e regular os servos na estrutura
mecnica
De&e%o"%e! # 6ne!9#(e (o;
o& &en&o!e&
E&1d#! e e"#bo!#! o&
;o%6;eno&
De&en%o"%e! o So9/#!e d#
EB Yd!6%e!Z
De&en%o"%e! o F6!;/#!e
Elaborar a maquina de estados 100% 18/02/2013 13/04/2013 8,0 8,0
mplementar 100% 01/03/2013 13/04/2013 24,0 24,0
Elaborar 100% 24/03/2013 13/04/2013 8,0 8,0
mplementar 100% 01/04/2013 20/04/2013 12,0 14,0
100%
02/01/2013 15/04/2013 16,0 4,0
100%
02/01/2013 15/04/2013 16,0 4,0
Criar o diagrama de blocos do driver 100% 02/01/2013 20/04/2013 12,0 4,0
Diagrama geral de Software 100% 02/01/2013 20/04/2013 8,0 4,0
Do(1;en#! o So9/#!e
Documentar o Firmware 100% 07/04/2013 20/04/2013 10,0 15,0
Documentar o Driver 100% 07/04/2013 20/04/2013 10,0 15,0
Documentar a biblioteca de cliente 100% 07/04/2013 20/04/2013 10,0 15,0
Documentar o sofware da interface 100% 14/04/2013 20/04/2013 10,0 12,0
Elaborar o sofware da interface 100% 15/03/2013 15/04/2013 12,0 8,0
mplementar o sofware da interface 100% 15/03/2013 15/04/2013 24,0 20,0
ntegrar as PCs com a FPGA 100% 08/03/2013 15/03/2013 42,0 40,0
ntegrar a cinematica inversa no hexpode 100% 15/03/2013 31/03/2013 30,0 80,0
ntegrar o driver com a FPGA 100% 15/03/2013 15/04/2013 35,0 50,0
ntegrar o driver com a interface 100% 01/04/2013 15/04/2013 20,0 24,0
Testar a integrao completa 100% 01/04/2013 30/04/2013 30,0 72,0
To#" 100% 05<03<2012 30<04<2013 1372=0 1577=0
De&en%o"%e! # b6b"6oe(#
do ("6ene
E"#bo!#! o& d6#7!#;#& de
So9/#!e
Realizar a documentao do protocolo de
baixo nvel
Realizar a documentao do protocolo de alto
nvel
De&en%o"%e! o &o9/#!e d#
6ne!9#(e
Re#"6V#! e&e& de
6ne7!#23o 96n#"
Apndice F: Riscos identificados 156
Ap[nd6(e F* R6&(o& 6den696(#do&
P!o5eo* Rob hexpode
1 etapa: Iden696(#23o do R6&(o
Denominao do risco: E!!o n# E&6;#6%# de Te;poQ C1&o o1 Co;p"ex6d#de
Nmero de identificao: 0
De&(!623o do !6&(o* Alguma das atividades pode ter seu prazo subestimado, devido falta de experincia
dos membros da equipe com o tipo de atividades envolvidas no projeto.
2 etapa: A%#"6#23o do R6&(o
I;p#(o* <+#"o- 4(mdio/alto) 3(mdio) 2(mdio/baixo) 1(baixo)
O projeto possui um deadline definida e a funcionalidade depende de praticamente todos os mdulos
estarem implementados. esperado que esse risco torne o projeto invivel dentro do prazo caso ocorra
este risco em grandes propores.
P!ob#b6"6d#de* 5(alta) :+;@d6#E#"#- 3(mdia) 2(mdia/baixa) 1 (baixa)
Os elementos da equipe tm pequena experincia em trabalhar com robtica. Estimar tempo sob esta
circunstncia levar quase que certamente a algumas etapas excederem o tempo planejado.
3 etapa: De&en%o"%6;eno d# Re&po&# #o R6&(o
E&!#@76#& e A2Ue&
E&!#@76#& e A2Ue& para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade)
P!e%en6!* Controle prximo por parte da equipe da evoluo das etapas; Planejamento dos tempos
considerando as aptides particulares dos elementos da equipe;
M667#!* Superestimar algumas tarefas para manter uma margem de segurana e planejar a data limite de
algumas tarefas de modo a deixar uma sobre no cronograma.
A(e6#!* A somatria de atrasos no pode ultrapassar o tempo das folgas devido ao deadline. Se no
houver folgas suficientes reduzir funcionalidades secundrias. Se isso tambm no for possvel cortar
funcionalidades principais em reunio com o orientador.
T!#n&9e!6!* N/A
Projeto< RobI hexQode
Denominao do risco: De;o!# o1 A!#&o n# AX16&623o de Co;ponene&
Nmero de identificao: 4
De&(!623o do !6&(o* A aquisio dos componentes um item de cronograma com dependncia externa.
Atrasos, especialmente no caso dos componentes importados e nos crticos do projeto, representam um
grande risco para o seu sucesso.
I;p#(o* <+#"o- 4(mdio/alto) 3(mdio) 2(mdio/baixo) 1(baixo)
Os prazos de entrega dos componentes eletrnicos podem influenciar o bom andamento do projeto,
forando o incio do trabalho em algumas etapas a atrasarem. O problema ainda maior no caso de
necessidade de reposio de componentes danificados. O impacto seria sentido provavelmente na
qualidade ou na funcionalidade do produto. Nos cenrios mais graves componentes crticos de reposio
poderiam no chegar a tempo no deadline, o que produziria um produto no usvel na data da entrega.
P!ob#b6"6d#de* 5(alta) 4(mdia/alta) A+;@d6#- 2(mdia/baixa) 1 (baixa)
No caso de componentes importados no raro haver pequenos atrasos. Podem ocorrer atrasos maiores
devido aos rgos fiscalizadores brasileiros como a receita e a alfndega. Alm disso ainda existe a
possibilidade de extravio da encomenda no pior cenrio.
E&!#@76#& e A2Ue&
P!e%en6!* Durante a elaborao da lista de componentes a serem usados no projeto deve-se levar em
considerao os prazos de entrega. Componentes com menor prazo de entrega devem ser favorecidos.
Deve ser prevista uma folga de cronograma na entrega dos componentes. Os componentes devem ser
adquiridos o mais cedo possvel. Para os componentes com maior risco determinar pelo menos 2 locais
que o vendem, preferencialmente em Curitiba ou em cidades que tenham frete rpido para Curitiba, como
o caso de So Paulo. Deve-se tambm manter alternativas para componentes de aquisio mais rpida,
mesmo que com caractersticas diferentes.
M667#!* No caso um componente estar atrasado a ponto de colocar em risco o projeto utilizar um
componente alternativo, de aquisio mais rpida. Comprar componentes sobressalentes, no caso de
componentes que no possam ser repostos rapidamente, caso ocorra um dano.
A(e6#!* Se no houver componente equivalente substitu-lo por outro com menor funcionalidade,
desempenho ou qualidade; Se o produto puder ser concludo sem o componente, mesmo com
funcionalidade reduzida, execut-lo, mediante reunio com o orientador do projeto.
T!#n&9e!6!* N/A
Denominao do risco: E!!o n#& E&(o")#& Te(no"P76(#&
Nmero de identificao: A
De&(!623o do !6&(o* A correta escolha de tecnologias crtica para o sucesso deste projeto. Os itens
escolhidos precisam atender em qualidade, desempenho e funcionalidades o projeto como um todo. Se as
tecnologias utilizadas no suportarem o projeto no tem como ser um sucesso.
I;p#(o* 5(alto) :+;@d6oE#"o- 3(mdio) 2(mdio/baixo) 1(baixo)
Caso algum dos itens no possua as caractersticas necessrias o produto ser afetado reduzindo
qualidade ou funcionalidade. Se a escolha for muito errada, pode comprometer o projeto como um todo.
P!ob#b6"6d#de* 5(alta) 4(mdia/alta) 3(mdia) 4+;@d6#Eb#6x#- 1 (baixa)
Dado que as funcionalidades do rob, pelo menos nos itens principais, serem mapeadas para
funcionalidades providas pelos componentes e as caractersticas de desempenho poderem ser estimadas.
A possibilidade disso ocorrer surge para os itens secundrios do projeto ou para itens que, por
inexperincia da equipe, sejam necessrios e a equipe no tenha cincia disso.
E&!#@76#& e A2Ue&
P!e%en6!* Levantar formalmente os itens de funcionalidade a serem atendidos e aprov-los com o cliente.
Mape-los formalmente com recursos dos componentes a serem adquiridos. Solicitar a um professor
experiente uma conferncia. Escolher componentes que possam ser substitudos por outros mais
poderosos, baratos e que possam ser adquiridos prontamente. nstruir a equipe a prestar ateno s
caractersticas dos equipamentos de forma a notificar rapidamente aos demais no caso da possibilidade de
alguma no-conformidade.
M667#!* Se houver um componente disponvel prontamente de baixo custo e com as caractersticas
necessrias deve-se adquiri-lo. Se for possvel uma soluo com baixa reduo de qualidade, deve-se
aplic-la.
A(e6#!* Se a caracterstica desejada reduzir alguma funcionalidade secundria do projeto, adequ-lo para
operar adequadamente com esta reduo.
T!#n&9e!6!* N/A
Denominao do risco: >1e6;# de Co;ponene o1 Co;ponene De9e61o&o
Nmero de identificao: :
De&(!623o do !6&(o* Durante o desenvolvimento do projeto existe o risco de dano a algum componente
eletrnico, de forma que ele pode se tornar inutilizvel no projeto.
Alguns dos componentes do projeto, como a FPGA, desempenham papis crticos no projeto. O no
funcionamento destes componentes inviabiliza o projeto Outros componentes so usados em quantidade
superior a uma unidade, como resistores ou opto acopladores, sendo que dano que afete apenas um deles
possa apenas reduz a funcionalidade do produto ou seja facilmente substitudo.
Dano em componente s ocorreria se houver falha grave no projeto da eletrnica ou se houver manuseio
incorreto dos componentes. Sem estes cuidados especiais acreditamos que a probabilidade de ocorrncia
deste risco mdia a baixa..
E&!#@76#& e A2Ue&
P!e%en6!* Os elementos da equipe que tiverem mais proficincia com eletrnicos devem atuar diretamente
na eletrnica do projeto. As especificaes contidas nos datasheets sobre limites de operao dos
componentes devem ser obedecidas. O manuseio, teste, montagem e operao da eletrnica devem ser
feitos preferencialmente tambm pela equipe com mais proficincia nestes aspectos. Quando o oramento
permitir, adquirir componentes sobressalentes e especialmente os componentes crticos. Escolher, na
medida do possvel, componentes da fcil reposio. Na medida do possvel, estabelecer formas de testar
a operao individual dos componentes o mais cedo possvel, antes de se iniciar a integrao da
eletrnica.
M667#!* Substituir por um sobressalente e adquirir novo componente, mas somente aps se determinar
por que o componente foi danificado e aps garantir-se, dentro do possvel, que o problema no vai
recorrer; Adaptar projeto para operar com componentes similares com grande disponibilidade; Caso no
haja, continuar trabalhando nas outras tarefas do projeto e convocar reunio de emergncia.
A(e6#!* Se no houver componente equivalente substitu-lo por outro com menor funcionalidade,
desempenho ou qualidade; Se o produto puder ser produzido sem o componente, mesmo com
funcionalidade reduzida, execut-lo, mediante a provao com o cliente.
T!#n&9e!6!* N/A
Denominao do risco: Inexpe!6[n(6# d# Te(no"o76# U6"6V#d#
Nmero de identificao: <
De&(!623o do !6&(o* Dificuldade de utilizao da tecnologia por no entender o funcionamento e a
utilizao desta.
I;p#(o* 5(alto) 4(mdio/alto) A+;@d6o- 2(mdio/baixo) 1(baixo)
Este risco pode provocar um atraso considervel, pois para algumas tecnologias complexo encontrar
referncias esclarecedoras sobre pontos que s so entendidas com a prtica com a utilizao destas.
Dado que este um trabalho de concluso de curso, espera-se que haja familiaridade, nem que
superficial, com a maior parte das tecnologias utilizadas.
E&!#@76#& e A2Ue&
P!e%en6!* nserir no plano de projeto datas para estudo e ensaio das tecnologias utilizadas no projeto para
se adquirir a experincia necessria.
M667#!* Escolher preferencialmente tecnologias em que j se tem experincia ou que se saiba que h
documentao clara e simples a respeito. Procurar algum que tenha conhecimento sobre a tecnologia,
como por exemplo os professores.
A(e6#!* N/A
T!#n&9e!6!* N/A
Denominao do risco: Do(1;en#23o E!!ne# d#& Te(no"o76#& U6"6V#d#&$
Nmero de identificao: G
De&(!623o do !6&(o* A documentao de qualquer das tecnologias utilizadas seja incompleta ou
imprecisa.
Os componentes escolhidos podem no fazer o que deveriam, ou fazer de forma errada.
P!ob#b6"6d#de* 5(alta) 4(mdia/alta) 3(mdia) 2(mdia/baixa) 0 +b#6x#-
Grande parte das tecnologias que se pensou em utilizar muito utilizada, ento pouco provvel que
sejam mal documentadas ou no faam o que prometem.
E&!#@76#& e A2Ue&
P!e%en6!* Busca-se o uso de tecnologias que j sejam bem estabelecidas, de forma que haja bastante
informao sobre elas.
M667#!* Procurar saber se existe uma tecnologia alternativa que possa ser utilizado no lugar da tecnologia
falha e estud-la para caso o problema ocorra.
A(e6#!* Diminuir a funcionalidade do projeto devido a incapacidades tcnicas ou trocar de tecnologia se
possvel.
T!#n&9e!6!* N/A

Robo Hexapode Controlado Por Fpga

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Robo Hexapode Controlado Por Fpga

Enviado por

Direitos autorais:

Formatos disponíveis

UNVERSDADE TECNOLGCA FEDERAL DO PARAN

DEPARTAMENTO ACADMCO DE ELETRNCA

Você também pode gostar