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.
Captulo 2 Estudos 41
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
Captulo 2 Estudos 42
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
.
Captulo 2 Estudos 43
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
Captulo 2 Estudos 44
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
.
Captulo 2 Estudos 45
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
Captulo 2 Estudos 46
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++.
Captulo 2 Estudos 47
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.
Captulo 2 Estudos 48
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.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 50
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 %.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 51
!igura +9: Gonfigura*Oes da controladora #&R"?, Qgina +.
!onte: "utoria r'ria.
!igura +%: Gonfigura*Ho da )LL da #&R"?.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 52
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.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 53
!igura +,: #istema #=)G comleto.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 54
!igura +6: .eometria de uma ata em detalhe.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 55
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.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 56
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.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 57
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.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 58
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?.
!onte: "utoria r'ria.
!igura +C: Aloco gerador de sinal )W?.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 59
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
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 60
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
Captulo 3 Desenvolvimento 61
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.
Captulo 3 Desenvolvimento 62
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.
Captulo 3 Desenvolvimento 63
!igura ,+: #ervo desmontado.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 64
!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.
Captulo 3 Desenvolvimento 65
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.
Captulo 3 Desenvolvimento 66
!igura ,6: 8s2uemQtico do circuito da )G< da !).".
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 67
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
!onte: "utoria r'ria.
Board - C0 [Pin] GPIO - 0 [Pin] FPGA [Pin] Funo
2 5 GPIO_02 Sinal de PWM para o Servo 1
4 4 GPIO_01 Sinal de PWM para o Servo 2
6 6 GPIO_03 Sinal de PWM para o Servo 3
8 8 GPIO_05 Sinal de PWM para o Servo 4
10 10 GPIO_07 Sinal de PWM para o Servo 5
12 14 GPIO_09 Sinal de PWM para o Servo 6
14 16 GPIO_011 Sinal de PWM para o Servo 7
16 18 GPIO_013 Sinal de PWM para o Servo 8
18 20 GPIO_015 Sinal de PWM para o Servo 9
20 - - GN
Captulo 3 Desenvolvimento 68
Tabela 3: Gonfigura*Ho dos inos do conector A="R&$G%
!onte: "utoria r'ria.
Board - C1 [Pin] GPIO - 0 [Pin] FPGA [Pin] Funo
1 22 GPIO_017 Sinal de PWM para o Servo 10
3 24 GPIO_019 Sinal de PWM para o Servo 11
5 26 GPIO_021 Sinal de PWM para o Servo 12
7 28 GPIO_023 Sinal de PWM para o Servo 13
9 32 GPIO_025 Sinal de PWM para o Servo 14
11 34 GPIO_027 Sinal de PWM para o Servo 15
13 36 GPIO_029 Sinal de PWM para o Servo 16
15 38 GPIO_031 Sinal de PWM para o Servo 17
17 40 GPIO_033 Sinal de PWM para o Servo 18
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.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 69
Tabela >: Gonfigura*Ho dos inos da <?R
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 70
!igura ,B: )inos do ?'dulo @Aee.
!onte: Retirada de J,3K
Tabela B: Gonfigura*Ho dos inos do ?'dulo @Aee na )G<
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 71
!igura ,4: &iagrama da )G< da !).".
!onte: "utoria r'ria.
!igura ,C: )G< da !)." com todos os comonentes soldados.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 72
!igura 69: )G< da !)." ligada com o @bee, a !)." e a <?R.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 73
!igura 6%: 8s2uemQtico do circuito da )G< dos servos.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 74
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
!onte: "utoria r'ria.
Alimentao [Pin] Funo
POW5/-3 GN do* Servo* 01 a 03
POW5/-4 5#0" do* Servo* 01 a 06
POW5/-5 GN do* Servo* 04 a 06
POW5/-6 5#0" 13li6ado no* Op3oa&opladore*
POW5/-7 GN do* Servo* 07 a 09
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/-15 GN do* Servo* 10 a 12
POW5/-16 GN do* Servo* 13 a 15
POW5/-17 GN do* Servo* 16 a 18
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
Captulo 3 Desenvolvimento 75
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.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 76
!igura 6,: )G< dos servos sem os comonentes soldados.
!onte: "utoria r'ria.
!igura 66: WersHo final da )G< dos servos arafusada ao hexQode.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 77
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.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 78
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.
Captulo 3 Desenvolvimento 79
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
2 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
11 3.3V Orange +3.3 VDC
12 012V Ble 012 VDC
13 COMMON Black Gron!
1" &'r(ON Green &o'er -++l) On (act,1e lo')
1# COMMON Black Gron!
16 COMMON Black Gron!
1% COMMON Black Gron!
18 0#V 2*,te 0# VDC
19 #V $e! +# VDC
20 #V $e! +# VDC
Captulo 3 Desenvolvimento 80
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.
Captulo 3 Desenvolvimento 81
!igura 6>: )e*as do ?#R$D9% com alguns servos encaixados
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 82
!igura 6B: 7it ?#R$D9% montado com todos os servos encaixados
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 83
!igura 64: DexQode com as )G<s e com a !)." mas sem a )G< suerior ter sido
soldada.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 84
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-.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 85
!igura 39: DexQode comleto.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 86
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
Captulo 3 Desenvolvimento 87
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.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 88
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.
Captulo 3 Desenvolvimento 89
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.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 90
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.
!onte: "utoria r'ria.
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.
!onte: "utoria r'ria.
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.
!onte: "utoria r'ria.
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
Nmero total de iteraes
do movimento
!igura 3>: !ormato da mensagem de movimento abortado.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 91
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.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 92
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.
!onte: "utoria r'ria.
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.
!onte: "utoria r'ria.
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.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 93
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
Nmero total de iteraes
do movimento
T#;#n)o
0x0008
M#76( /o!d
0x00BA0BAA
!igura >%: !ormato da mensagem de movimento terminado com sucesso.
!onte: "utoria r'ria.
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
Nmero total de iteraes
do movimento
M#76( /o!d
0x00BA0BAA
!igura >+: !ormato da mensagem de movimento abortado.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 94
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.
!onte: "utoria r'ria.
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:
Captulo 3 Desenvolvimento 95
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:
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. Usurio pressiona o boto de parar movimento.
7. O software retorna tela principal, assim que a biblioteca enviar notificao
de movimento abortado.
Fluxo alternativo
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 no faz nada, se os parmetros forem invlidos.
Fluxo alternativo
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.
Captulo 3 Desenvolvimento 96
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 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
Captulo 3 Desenvolvimento 97
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.
Captulo 3 Desenvolvimento 98
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.
Captulo 3 Desenvolvimento 99
+ 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.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 100
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.
Captulo 3 Desenvolvimento 101
+ 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&e
# 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.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 102
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
- m_pool : ObjectPool<Class, Count>
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
- m_pool : ObjectPool<Class, Count>
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_pool : ObjectPool<Class, Count>
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_pool : ObjectPool<Class, Count>
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
- m_pool : ObjectPool<Class, Count>
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
- m_pool : ObjectPool<Class, Count>
No696(#6onSende!
+ run(id : int, position : LegPositions, manager : MovementManager) : void
+ getValue() : int
+ getLength() : int
+ create() : HaltOperation
- m_pool : ObjectPool<Class, Count>
H#"Ope!#6on
+ run(id : int, position : LegPositions, manager : MovementManager) : void
+ getValue() : int
+ getLength() : int
+ create(distance : int, isLeftToRight : boolean) : WalkSidewaysOperation
# m_walkedDistance : int
# m_totalDistance : int
# m_isLeftToRight : boolean
- m_pool : ObjectPool<Class, Count>
M#"SS6de/#,&Ope!#6on
+ run(id : int, position : LegPositions, manager : MovementManager) : void
+ 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
- m_pool : ObjectPool<Class, Count>
Ro#eOpe!#6on
+ run(id : int, position : LegPositions, manager : MovementManager) : void
+ getValue() : int
+ getLength() : int
+ create() : AdjustOperation
# m_current : int
# m_total : int
- m_pool : ObjectPool<Class, Count>
Ad51&Ope!#6on
+ run(id : int, position : LegPositions, manager : MovementManager) : void
+ getValue() : int
+ getLength() : int
+ create(cycles : int) : HulaHoopOperation
# m_cycles : int
# m_totalCycles : int
- m_pool : ObjectPool<Class, Count>
H1"#HoopOpe!#6on
+ run(id : int, position : LegPositions, manager : MovementManager) : void
+ getValue() : int
+ getLength() : int
+ create(pushUps : int) : PushUpOperation
# m_totalPushUps : int
# m_pushUps : int
- m_pool : ObjectPool<Class, Count>
P1&)UpOpe!#6on
1
1
1
1
1 1
0..1
1
1
1
Y onRe2uestLre2uest : ?essage, relier : !lowRelierM : void
Messa$eRequest&allbac8
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.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 103
!igura >B: #tatechart do firmware.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 104
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
Captulo 3 Desenvolvimento 105
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&eC#""b#(S
Y onRe2uestLre2uest : ?essage, relier : !lowRelierM : void
Messa$eRequest&allbac8
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
+ UnexpectedRobotResponse : Result
+ nvalidSensor : Result
+ Closed : Result
+ RobotTimeout : Result
+ UnexpectedClientResponse : Result
+ Offline : Result
+ ClientTimeout : Result
+ Success : Result
<<enum>>
Re&1"
+ UnexpectedRobotResponse : Result
+ nvalidMovement : Result
+ Closed : Result
+ RobotTimeout : Result
+ UnexpectedClientResponse : Result
+ Offline : Result
+ ClientTimeout : Result
+ Success : Result
<<enum>>
Re&1"
Y onRobot?ovingLresult : ResultM : void
RobotMovin$&allbac8
Y onRobotDaltedLresult : ResultM : void
Robot)alted&allbac8
Y onRe2uestLre2uest : ?essage, relier : !lowRelierM : void
Messa$eRequest&allbac8
!igura >4: &iagrama de classes do driver.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 106
!igura >C: #tatechart do driver.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 107
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
+ AlreadyConnected : Result
+ 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
+ UnexpectedRobotResponse : Result
+ nvalidPort : Result
+ AlreadyConnected : Result
+ RobotTimeout : Result
+ UnexpectedClientResponse : Result
+ Offline : Result
+ ClientTimeout : 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##
+ UnexpectedRobotResponse : Result
+ nvalidSensor : Result
+ Closed : Result
+ RobotTimeout : Result
+ UnexpectedClientResponse : Result
+ Offline : Result
+ ClientTimeout : Result
+ Success : Result
<<enum>>
Re&1"
Y onRobot?ovingLresult : ResultM : void
RobotMovin$&allbac8
+ UnexpectedRobotResponse : Result
+ nvalidMovement : Result
+ Closed : Result
+ RobotTimeout : Result
+ UnexpectedClientResponse : Result
+ Offline : Result
+ ClientTimeout : Result
+ Success : Result
<<enum>>
Re&1"
Y on!lowGlosedLflow : !lowM : void
+lo*&losed&allbac8
Y onRe2uestLre2uest : ?essage, relier : !lowRelierM : void
Messa$eRequest&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.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 108
!igura B%: #tatechart da biblioteca de cliente.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 109
!igura B+: Tela inicial do software de interface grQfica.
!onte: "utoria r'ria.
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.
!onte: "utoria r'ria.
Captulo 3 Desenvolvimento 110
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.
!onte: "utoria r'ria.
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.
Captulo 3 Desenvolvimento 111
!igura B3: Tela de movimento em andamento.
!onte: "utoria r'ria.
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
Captulo 3 Desenvolvimento 112
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
Captulo 3 Desenvolvimento 113
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.
Captulo 3 Desenvolvimento 114
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)
Captulo 3 Desenvolvimento 115
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
Captulo 3 Desenvolvimento 116
"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.
Captulo 3 Desenvolvimento 117
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
Captulo 3 Desenvolvimento 118
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.
Captulo 4 Plano de testes 120
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.
E#p# In&!123o Re&1"#do e&pe!#do
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.
E#p# In&!123o Re&1"#do e&pe!#do
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.
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 driver do computador B est conectado a um rob. O rob est totalmente ligado.
E#p# In&!123o Re&1"#do e&pe!#do
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.
Captulo 4 Plano de testes 121
".% &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.
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 driver do computador B est conectado a um rob. O rob est totalmente ligado.
E#p# In&!123o Re&1"#do e&pe!#do
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.
Aps alguns instantes, a leitura do
magnetmetro na tela atualizada para um
valor distinto do apresentado anteriormente.
3 Pressione o boto de atualizar a leitura do
acelermetro.
Aps alguns instantes, a leitura do
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
!onte: "utoria r'ria.
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.
!onte: "utoria r'ria.
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
!onte: "utoria r'ria.
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# eo
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.
Captulo 7 Consideraes finais 137
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
Captulo 7 Consideraes finais 138
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!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* Menen& do p!oo(o"o en!e !ob e d!6%e!
Menen& do d!6%e! p#!# o !ob
Mene; 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
Menen& do !ob p#!# o d!6%e!
Mene; CPd67o Co!po De&(!623o
.eepA"6%e
9x9%99
Lre2uisi*HoM
Vazio Verificar se h conexo com o driver.
Essa mensagem no utilizada na verso atual do
protocolo.
9x9%9%
LresostaM
Vazio
Mo%e;en
F6n6&)ed
No696(#6on
9x9%9+
Lre2uisi*HoM
dentificador (4 bytes)
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
dentificador (4 bytes)
Valor (4 bytes)
Tamanho (4 bytes)
ndica que um movimento associado a um identificador de
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* Menen& do p!oo(o"o en!e ("6ene e d!6%e!
Menen& do ("6ene p#!# o d!6%e!
Mene; CPd67o Co!po De&(!623o
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)
dentificador (4 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.
Essa mensagem no utilizada na verso atual do
protocolo.
9x49!!
LresostaM
Vazio
Apndice D: Mensagens do protocolo entre cliente e driver 152
Menen& do d!6%e! p#!# o ("6ene
Mene; CPd67o Co!po De&(!623o
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
dentificador (4 bytes)
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.
9xG%9,
LresostaM
Vazio
Mo%e;en
Abo!ed
No696(#6on
9xG%96
Lre2uisi*HoM
dentificador (4 bytes)
Valor (4 bytes)
Tamanho (4 bytes)
ndica que um movimento associado a um identificador de
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!&#
Apndice E: Tabela completa de atividades realizadas 154
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# eo
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
Apndice E: Tabela completa de atividades realizadas 155
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
Apndice F: Riscos identificados 157
Projeto< RobI hexQode
1 etapa: Iden696(#23o do R6&(o
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.
2 etapa: A%#"6#23o do R6&(o
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.
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!* 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
Apndice F: Riscos identificados 158
Projeto< RobI hexQode
1 etapa: Iden696(#23o do R6&(o
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.
2 etapa: A%#"6#23o do R6&(o
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.
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!* 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
Apndice F: Riscos identificados 159
Projeto< RobI hexQode
1 etapa: Iden696(#23o do R6&(o
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.
2 etapa: A%#"6#23o do R6&(o
I;p#(o* 5(alto) :+;@d6oE#"o- 3(mdio) 2(mdio/baixo) 1(baixo)
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.
P!ob#b6"6d#de* 5(alta) 4(mdia/alta) 3(mdia) 4+;@d6#Eb#6x#- 1 (baixa)
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..
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!* 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
Apndice F: Riscos identificados 160
Projeto< RobI hexQode
1 etapa: Iden696(#23o do R6&(o
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.
2 etapa: A%#"6#23o do R6&(o
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.
P!ob#b6"6d#de* 5(alta) 4(mdia/alta) 3(mdia) 4+;@d6#Eb#6x#- 1 (baixa)
Dado que este um trabalho de concluso de curso, espera-se que haja familiaridade, nem que
superficial, com a maior parte das tecnologias utilizadas.
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!* 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
Apndice F: Riscos identificados 161
Projeto< RobI hexQode
1 etapa: Iden696(#23o do R6&(o
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.
2 etapa: A%#"6#23o do R6&(o
I;p#(o* 5(alto) :+;@d6oE#"o- 3(mdio) 2(mdio/baixo) 1(baixo)
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.
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!* 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