Upload
dinhdiep
View
230
Download
1
Embed Size (px)
Citation preview
Paulo Filipe Pereira do Vale
Plataforma de testes para sistemas multi-robô
Paul
o Fi
lipe
Pere
ira d
o Va
le
Dezembro de 2012UMin
ho |
201
2Pl
ataf
orm
a de
test
es p
ara
sist
emas
mul
ti-ro
bô
Universidade do MinhoEscola de Engenharia
Dezembro de 2012
Tese de MestradoCiclo de Estudos Integrados Conducentes ao Grau de Mestre emEngenharia Eletrónica Industrial e Computadores
Trabalho efetuado sob a orientação doProfessor Doutor Sérgio Monteiro
Paulo Filipe Pereira do Vale
Plataforma de testes para sistemas multi-robô
Universidade do MinhoEscola de Engenharia
Agradecimentos
As proximas linhas sao arrancadas do coracao, porque vale incomensuravelmente mais
aquilo que sentimos, do que aquilo que dizemos. Assim, as proximas linhas neste capıtulo, que
ironicamente e o mais pequeno, retratam verdadeiramente toda a essencia deste documento.
Porque a realizacao deste documento nao foi obra de um trabalho solitario de uma unica
pessoa, isolada no tempo e espaco, gostaria prestar o meu profundo agradecimento e gratidao a
todos que, de uma forma ou de outra, contribuıram para a concretizacao deste trabalho.
Deste modo, em primeiro lugar, ao Professor Sergio Monteiro, meu orientador, pelo apoio,
simplicidade, e estımulo ao acreditar na realizacao deste trabalho, e por toda a sua disponibili-
dade, discussao e revisao deste documento.
A todos os tecnicos das oficinas, na pessoa do Sr. Carlos, do Sr. Joel e da Dona Angela,
o meu agradecimento pela sua assistencia ao disponibilizaram o seu tempo na substituicao das
baterias dos robos Khepera.
A todo o pessoal do laboratorio de robotica movel e antropomorfica pela sua abertura e
disponibilidade que sempre demonstraram comigo, presto a minha gratidao.
Todos os meus familiares e amigos, autenticos fatores de enriquecimento humano (e boa
disposicao), que durante o sobe e desce da vida, estao sempre presentes com o seu apoio,
estimulo e incentivo, forca sem a qual, com a desenrolar de todos os deveres academicos, a
realizacao deste trabalho nao seria possıvel.
A todos os companheiros de viagem academica que conheci e com quem partilhei este cami-
nho arduo e difıcil, atraves das quais me tornei uma melhor pessoa, o meu agradecimento.
”O agradecimento e a memoria do coracao.”
Lao Zi
iii
Resumo
O teste de algoritmos sofisticados em sistemas multi-robo, podera ser facilitado se for im-
plementado recorrendo a mini-robos num ambiente a escala. Desta forma conseguem-se validar
os conceitos, antes de serem efetivamente testados em ambiente real.
Esta dissertacao, visa implementar uma plataforma de teste para sistemas multi-robo (MRS)
onde cada robo recebe primitivas de localizacao, isto e, pretende-se dotar um robo de um me-
canismo de posicao absoluta, recorrendo, para o efeito, a utilizacao de mini-robos que cabem
na palma da mao. Assim, e uma vez que, os sistemas de posicionamento global nao funcionam
dentro de portas, e necessario, para se suprir esta lacuna, recorrer a metodos alternativos. Neste
contexto, e fazendo uso destes mini-robos, esta dissertacao utiliza uma camara situada sobre
o ambiente de trabalho, que funciona como um sensor primario, de onde toda a informacao e
recolhida. Para alem da camara, faz tambem parte deste sistema pseudo-GPS, um computador
central que efetua todo o processamento de dados e que possibilita o seu envio para o robo.
Posteriormente, pretende-se efetuar formacoes de robos, utilizando, para o efeito, uma ar-
quitetura de controlo assente em atratores de sistema dinamicos nao lineares (SDNL), que faca
uso destas primitivas. Por fim, sao caraterizados os resultados obtidos atraves da utilizacao de
metricas standard para a avaliacao do sistema multi-robo.
Palavras-chave: Robotica, Mini-robos, sistema Pseudo-GPS.
v
Abstract
The test of complex algorithms in multi-robot systems, might be easier if done using mini-
robots, because of scale issues. This allow us to validate the concepts, before of actually test
them in the real world.
In this thesis, we intend to implement a test bed for multi-robot system (MRS) where each
robot receives localization primitives, or, in another words, provide to a robot, a mechanism that
determine its absolute position or the absolute position of another robot, using for this purpose,
a set of mini-robots that fit in the palm of a hand. Thus, and because the global positioning
system does not work indoors, it is necessary to solve this problem using alternative methods.
In this context, and making use of these mini-robots, this thesis uses a camera located above
the desktop, which acts as a primary sensor, where all information is collected. In addition to
the camera, also forms part of this pseudo-GPS system, a central computer that performs all the
data processing and enables the data transmission to the robot.
Later, is intended to make robot formations, using for this purpose, a control architecture
based on non-linear attractor dynamics, that makes use of these primitives. Finally, the obtai-
ned results are characterized using a set of standard metrics for the evaluation of the multi-robot
system.
Keywords: Robotics, Mini-robots, Pseudo-GPS System.
vii
Indice
Lista de Figuras xv
Lista de Tabelas xix
1 Introducao e objetivos 1
1.1 Definicao do problema e objetivos . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Breve descricao da solucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Organizacao da dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Estado da Arte 9
3 Desenvolvimento da plataforma de testes 17
3.1 Mini-robos Khepera I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Aplicacao reacTIVision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Construcao da mesa de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Plano de fundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 Camara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3 Iluminacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Funcionalidades adicionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Arquitetura de controlo utilizada . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Resultados 45
4.1 Descricao dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.1 Teste com um robo Khepera . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.2 Testes com dois robos Khepera . . . . . . . . . . . . . . . . . . . . . 49
4.1.3 Testes com tres robos Khepera . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Analise e discussao dos resultados . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1 Sincronismo entre o reacTIVision e os robos Khepera . . . . . . . . . . 61
4.2.2 Intervalo de Tempo = 160ms . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.3 Intervalo de Tempo = 320ms . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.4 Intervalo de tempo = 640ms . . . . . . . . . . . . . . . . . . . . . . . 66
ix
Indice
4.2.5 Intervalo de tempo = 80ms . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2.5.1 Sem obstaculos . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2.5.2 Com obstaculos - Master . . . . . . . . . . . . . . . . . . . 71
4.2.5.3 Com obstaculos - Normal . . . . . . . . . . . . . . . . . . . 74
4.2.5.4 Com obstaculos - Slave . . . . . . . . . . . . . . . . . . . . 77
5 Conclusoes e trabalho futuro 83
5.1 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2 Sugestoes para trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Bibliografia 87
Apendice A - Codigo Fonte de Rotinas 91
A.1 Rotina para a rececao do pacote de dados do PC - Tempo de espera individual . 91
A.2 Rotina para a rececao do pacote de dados do PC - Tempo de espera coletivo . . 94
A.3 Rotina para a transmissao da posicao do Master para cada Slave - Tempo de
espera individual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.4 Rotina para a transmissao da posicao do Master para cada Slave - Tempo de
espera coletivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
A.5 Rotina para a rececao da informacao do Master em cada Slave - Tempo de
espera individual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.6 Rotina para a rececao de informacao do Master em cada Slave - Tempo de
espera coletivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A.7 Rotina para a sincronizacao de movimento entre Master e Slave . . . . . . . . 105
A.8 Ciclo de atualizacao de cada Robo . . . . . . . . . . . . . . . . . . . . . . . . 106
Apendice B - Sistema dinamico 109
B.1 Conceitos basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
-x- Plataforma de testes para sistema multi-robo(MRS)
Lista de Abreviaturas
API Application Programming Interface (Application Programming Interface)
BR Taxa de sımbolos por segundo (BaudRate)
CR Mudanca de Linha (Carriage Return)
DEI Departamento de Eletronica Industrial (Industrial Electronics Department)
DI Iluminacao Difusa (Diffused Illumination )
FPS Frame por Segundo (Frame per Second)
FTIR Frustrated Total Internal Reflection (Frustrated Total Internal Reflection)
GPS Sistema de Posicionamento Global (Global Positioning System)
IEEE Instituto de Engenharia Eletronica e Eletrica (Institute of Electrical and Electronics Engineers)
IR Infravermelha (Infrared)
LED Diodo Emissor de Luz (Light-Emitting Diode)
MRS Sistemas multi-robo (multi-Robot Systems)
OSC Open Sound Control (Open Sound Control)
RAM Random Access Memory (Random Access Memory)
RF Radio Frequencia (Radio Frequency)
SDNL Sistemas Dinamicos Nao-Lineares (Nonlinear Dynamical System)
USB Barramento Serie Universal (Universal Serial Bus)
PAM Unidade de espaco interna do robo Khepera (Space intern unity of Robot Khepera)
TIC Unidade de tempo interna do robo Khepera (Time intern unity of Robot Khepera)
xi
Lista de Sımbolos
a Aceleracao Linear [m/s2]
v Velocidade Linear [m/s]
x,y Posicao Linear [m]
α Aceleracao Angular [rad/s2]
ω Velocidade Angular [rad/s]
θ Posicao Angular [rad]
Φ Orientacao de navegacao do robo [rad]
Ψ Orientacao do seguidor em relacao ao lıder [rad]
xiii
Lista de Figuras
1.1 Exemplos de Formacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Perspectiva geral da solucao proposta . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Representacao do fluxo de dados (Malha Fechada) . . . . . . . . . . . . . . . 7
3.1 Esquema da solucao implementada centralizada . . . . . . . . . . . . . . . . . 18
3.2 Esquema da solucao implementada distribuıda . . . . . . . . . . . . . . . . . . 19
3.3 Ilustracao do metodo de transmissao de dados de forma cıclica . . . . . . . . . 20
3.4 Ilustracao do robo Khepera I . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Robos Khepera utilizando o marcador da aplicacao reacTIVision ao lado de uma
moeda de 2AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Exemplo dos marcadores utilizados pela aplicacao reacTIVision . . . . . . . . 23
3.7 Ilustracao do marcador da aplicacao reacTIVision . . . . . . . . . . . . . . . . 24
3.8 Captura de ecra da aplicacao reacTIVision durante um teste . . . . . . . . . . . 25
3.9 Referencial de coordenadas utilizadas pelo reacTIVision em x e em y . . . . . . 26
3.10 Metodo de identificacao do angulo de orientacao do robo . . . . . . . . . . . . 27
3.11 Ilustracao da implementacao pratica da mesa de trabalho . . . . . . . . . . . . 29
3.12 Esquematico da mesa de trabalho experimental . . . . . . . . . . . . . . . . . 29
3.13 Captura de ecra ilustrativa da detecao dos marcadores utilizando uma pelıcula
de cor branca como plano de fundo . . . . . . . . . . . . . . . . . . . . . . . . 30
3.14 Capturas de ecra da selecao da resolucao a utilizar . . . . . . . . . . . . . . . . 31
3.15 Captura de ecra da aplicacao reacTIVision no decorrer de um teste . . . . . . . 31
3.16 Experimentacao da detecao dos marcadores utilizados em toda a tela . . . . . . 32
3.17 Ficheiro configuration.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.18 Fluxograma da arquitetura de controlo com mecanismo de sincronizacao im-
plementada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1 Posicao inicial e final do robo . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Trajetoria adquirida pelo robo . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Capturas de ecra da formacao em coluna sem obstaculos com dois robos . . . . 49
4.4 Capturas de ecra da formacao oblıqua sem obstaculos com dois robos . . . . . 50
xv
Lista de Figuras
4.5 Capturas de ecra da formacao coluna com obstaculos com dois robos . . . . . . 51
4.6 Capturas de ecra da formacao oblıqua com obstaculos com dois robos . . . . . 52
4.7 Capturas de ecra da formacao em coluna sem obstaculos com tres robos . . . . 53
4.8 Capturas de ecra da formacao oblıqua sem obstaculos com tres robos . . . . . . 54
4.9 Apresentacao das metricas utilizadas . . . . . . . . . . . . . . . . . . . . . . . 55
4.10 Distancia Inter-robo ao longo do tempo na topologia oblıqua . . . . . . . . . . 57
4.11 Angulo Inter-robo ao longo do tempo na topologia oblıqua . . . . . . . . . . . 57
4.12 Distancia Inter-robo ao longo do tempo na topologia em coluna . . . . . . . . . 59
4.13 Angulo Inter-robo ao longo do tempo na topologia em coluna . . . . . . . . . . 59
4.14 Scatter das posicoes dos robos unificado (160 ms) . . . . . . . . . . . . . . . . 62
4.15 Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao
coletivo de 160 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.16 Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao
coletivo de 160 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.17 Scatter das posicoes dos robos unificado (320 ms) . . . . . . . . . . . . . . . . 64
4.18 Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao
coletivo de 320 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.19 Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao
coletivo de 320 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.20 Scatter das posicoes dos robos unificado (640 ms) . . . . . . . . . . . . . . . . 66
4.21 Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao
coletivo de 640 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.22 Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao
coletivo de 640 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.23 Scatter das posicoes dos robos unificado (640 ms) . . . . . . . . . . . . . . . . 68
4.24 Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao
efetiva do robo1 utilizando um intervalo de tempo coletivo de 80 ms . . . . . . 69
4.25 Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao
efetiva do robo2 utilizando um intervalo de tempo coletivo de 80 ms . . . . . . 69
4.26 Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao
coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.27 Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao
coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.28 Scatter das posicoes dos robos unificado (80 ms) . . . . . . . . . . . . . . . . 71
4.29 Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao
efetiva do robo1 utilizando um intervalo de tempo coletivo de 80 ms . . . . . . 72
4.30 Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao
efetiva do robo2 utilizando um intervalo de tempo coletivo de 80 ms . . . . . . 72
-xvi- Plataforma de testes para sistema multi-robo(MRS)
Lista de Figuras
4.31 Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao
coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.32 Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao
coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.33 Scatter das posicoes dos robos unificado (80 ms) . . . . . . . . . . . . . . . . 74
4.34 Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao
efetiva do robo1 utilizando um intervalo de tempo coletivo de 80 ms . . . . . . 75
4.35 Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao
efetiva do robo2 utilizando um intervalo de tempo coletivo de 80 ms . . . . . . 75
4.36 Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao
coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.37 Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao
coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.38 Scatter das posicoes dos robos unificado (80 ms) . . . . . . . . . . . . . . . . 77
4.39 Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao
efetiva do robo1 utilizando um intervalo de tempo coletivo de 80 ms . . . . . . 78
4.40 Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao
efetiva do robo2 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.41 Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao
coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.42 Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao
coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
1 Ilustracao da terminologia utilizada nas ordenacoes . . . . . . . . . . . . . . . 110
Plataforma de testes para sistema multi-robo(MRS) -xvii-
Lista de Tabelas
3.1 Especificacoes Tecnicas - Khepera I . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Sintaxe de uma set message apresentada pela aplicacao reacTIVision . . . . . . 25
3.3 Descricao dos parametros de uma set message utilizada pelo protocolo TUIO . 25
3.4 Sintaxe do pacote enviado para os robos com tempo de espera individual . . . . 34
3.5 Sintaxe do pacote enviado para os robos com tempo de espera coletivo . . . . . 35
3.6 Formato do pacote utilizado para a comunicacao PC → Master com espera
individual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7 Combinacao usada para a identificacao do robo . . . . . . . . . . . . . . . . . 38
3.8 Formato do pacote utilizado para a comunicacao PC → Master com espera
coletivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9 Formato do pacote utilizado para a comunicacao Master → Slave com espera
individual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.10 Descricao dos parametros usados na transmissao de dados Master → Slave com
tempo de espera individual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.11 Formato do pacote utilizado para a comunicacao Master → Slave com espera
coletiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.12 Descricao dos parametros usados na transmissao de dados Master → Slave com
tempo de espera coletivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1 Tabela comparativa para os valores de intervalo de tempo utilizados . . . . . . 80
xix
Capıtulo 1
Introducao e objetivos
A cooperacao e um facto natural. Esta ocorre quer nos seres humanos, quer na natureza,
onde diversos seres colaboram entre si, de modo a atingir um objetivo comum. Desta forma, e
atraves deste trabalho em comum com outrem sao conseguidos resultados mais produtivos para
ambos. Assim, existe na propria natureza esta nocao de cooperacao entre entidades, de onde
e produzida uma mentalidade coletiva em detrimento de uma mentalidade individual, e onde
o esforco combinado de cada uma destas entidades, visa o alcance de um objetivo comum a
ambas, ou o benefıcio de ambas de formas distintas.
Na robotica, este acontecimento e cada vez mais explorado, onde sistemas multi-robo sao
utilizados para realizar tarefas complexas, sem o mınimo de interferencia humana, tais como,
transporte de objetos volumosos [1], exploracao de ambientes hostis [2], tarefas de construcao
[3], transporte de lıquidos, etc., tirando partido das suas vantagens intrınsecas, como o facto
de permitir explorar uma area maior, de forma mais eficiente. Para alem destes, existem es-
tudos que retratam, a utilizacao de sistemas multi-robo como forma de exploracao do meio
ambiente onde se encontram, de forma coordenada [4], cobrindo desta forma, uma maior area
de exploracao e de forma mais celere. Outra das aplicacoes tıpicas de sistemas multi-robo as-
senta na constituicao de formacoes, onde sao emuladas formacoes realizadas quer por humanos,
quer pela natureza. Exemplos de formacoes utilizadas em campo militar, sao apresentadas na
Figura 1.1.
Nestes tipo de sistemas, que seguem a logica do todo ser maior que a soma das partes indi-
viduais, um dos seus problemas tıpicos e a coordenacao e a dinamica de grupo necessaria entre
todos os intervenientes do sistema. Assim, e a medida que as tarefas se tornam mais complexas
e muito importante que os robos possuam a capacidade de cooperar entre si. Posteriormente,
e a nıvel pratico, a medida que o numero de elementos destes sistemas aumenta, torna-se mais
difıcil a sua experimentacao devido as necessidades de espaco a usar. Assim, numa fase inicial,
e de forma a testar estes algoritmos e, de todo, vantajoso recorrer a modelos a escala durante
o processo de desenvolvimento de solucoes. Desta forma, a experimentacao de algoritmos e
facilitada, recorrendo a utilizacao de mini-robos, que nao so eliminam a necessidade de ter um
1
Fonte: http://www.flightglobal.com/blogs/the-dewline/2011/11/
(a) Formacao em Triangulo
Fonte: http://cdn2.wn.com/pd/b6/c7/bc78edfaba1ff01881b2c3aedf52_grande.jpg
(b) Formacao em Coluna
Fonte: http://manvshorse.wordpress.com/2009/04/02/empire-total-war-battle-report/
(c) Formacao em Linha
Fonte: http://manvshorse.wordpress.com/2009/04/02/empire-total-war-battle-report/
(d) Outras Formacoes
Figura 1.1: Exemplos de Formacoes: (a), (b), (c) e (d)
espaco de maiores dimensoes para o seu teste, como o manuseamento destes mini-robos se
torna muito mais facil e comodo.
Desta feita, a coordenacao entre os diversos robos para o desenvolvimento de tarefas em
conjunto, emerge como um dos aspectos mais sensıveis em sistemas envolvendo mais do que
um robo. Para proceder a sua coordenacao, torna-se necessario ter conhecimento da localizacao
absoluta ou relativa do robo, bem como, da sua orientacao no seu ambiente de trabalho. Deste
modo, devido a relevancia do problema existem na literatura varias propostas de metodologias
para a sua minimizacao.
Borenstein [5] evidencia seis categorias gerais, onde cada metodo, para a obtencao da
posicao do robo no espaco, se pode inserir. As duas primeiras permitem a obtencao da posicao
relativa do robo e as seguintes da sua posicao absoluta .
• Odometria
Atraves deste metodo a posicao do robo e obtida atraves da utilizacao de sensores
que estimam a posicao do robo ao longo do tempo. Podem ser utilizados encoders que
medem as rotacoes das rodas e/ou a orientacao da direcao. Por este facto, existem erros
de odometria associados a medicao. Este erro possui uma componente sistematica e uma
componente nao sistematica. Estes ultimos, dependem do meio ambiente onde o robo
se desloca e diferem de um meio para o outro. Por outro lado, os erros sistematicos sao
aqueles erros que sao inerentes a cinematica do robo e as propriedades do seu controlador,
e sao independentes do meio ambiente onde se situa o robo.
-2- Plataforma de testes para sistema multi-robo(MRS)
• Navegacao Inercial
Este metodo utiliza sensores de movimento (acelerometros) e sensores de rotacao (gi-
roscopios) para calcular a sua posicao, a orientacao e a velocidade do robo, num dado
momento. Estas medicoes sao posteriormente integradas uma, ou duas vezes, para obter
a posicao deste. Por um lado, este metodo possui a vantagem dos dados poderem ser
obtidos diretamente pelo proprio robo, com recurso aos seus proprios sensores, sem o
auxilio de componentes externos ao robo. Por outro lado, um pequeno erro constante pre-
sente a quando da leitura dos sensores sera aumentado, devido a necessidade de integrar
os dados lidos para obter a posicao pretendida. Devido a este facto, torna-se importante
utilizar sensores com a maxima precisao possıvel.
• Active Beacons
Aqui existem transmissores colocados no meio ambiente, em sıtios pre-determinados
pelo robo, e que utilizam, normalmente, sinais RF ou sinais de luz. Atraves da medicao
da direcao de incidencia de tres ou mais, destes sinais transmitidos, e possıvel calcular a
posicao absoluta do robo.
• Artificial Landmark Recognition
Utilizando este metodo, sao colocadas marcas artificiais distintas em lugares especifi-
cos no meio ambiente. Deste modo, atraves da visualizacao de tres ou mais destas marcas,
o robo estima a sua posicao no seu meio ambiente. Estas marcas podem ser produzidas de
forma a facilitar a sua detecao pelo robo no seu meio ambiente. Para alem disto, podem
ser obtidos atraves da analise destas marcas (como o calculo da sua area ou a analise da
sua geometria), outros dados, tais como, a orientacao ou a distancia que separa o robo a
marca.
• Natural Landmark Recognition
Este metodo e em tudo semelhante ao anterior, com a diferenca das marcas, ao se-
rem naturais, se encontrarem incorporadas no meio ambiente do robo. Por esta razao,
o meio ambiente natural do robo deve ser conhecido a partida. Regra geral, o grau de
confiabilidade deste metodo e menor do que, usando marcas artificiais para a navegacao.
• Model Matching
Atraves deste metodo, todos os dados lidos pelos sensores do robo sao comparados
com um mapa modelo do meio ambiente onde se insere o robo. Assim, a posicao absoluta
do robo e estimada atraves da combinacao/comparacao do seu modelo do meio ambiente
armazenado em memoria, com o modelo recolhido atraves dos sensores do robo. Este
mapa modelo armazenado no robo, e que e representativo do seu meio ambiente pode ir
Plataforma de testes para sistema multi-robo(MRS) -3-
1.1. Definicao do problema e objetivos
evoluindo ao longo do tempo, sendo possıvel ao robo, quer assimilar novas alteracoes no
seu meio ambiente (pela sua presenca num meio ambiente dinamico), quer acrescentar
novos mapas, de modo a cobrir novas areas de exploracao.
Atendendo aos metodos em cima enumerados, o sistema de posicionamento global (GPS)
pode, assim, ser inserido na categoria de Active Beacons. Neste sistema, os satelites que orbi-
tam na Terra, sao os transmissores de informacao, atraves de sinais RF. Uma vez, conhecida a
distancia do receptor a tres satelites torna-se possıvel calcular a sua localizacao por trilateracao
(latitude, a longitude e a altitude do receptor). Por sua vez, a distancia do receptor ao satelite e
obtida atraves do tempo de voo do sinal RF, enviado pelo satelite.
1.1 Definicao do problema e objetivos
Do ponto de vista do robo movel, e importante conhecer a sua localizacao, com relativa
precisao e a localizacao de outros robos em sistemas multi-robo. A estimativa da sua posicao e
das posicoes de outros robos, pode ser algo complexa e morosa, usualmente, obtidas atraves de
metodos que utilizam fusao sensorial, tais como, Arithmetic Mean, Weight Grid, filtros Kalman,
metodo de localizacao de Monte Carlo, ou atraves de combinacoes destas tecnicas [6].
Esta dissertacao visa desenvolver uma plataforma de testes para sistemas multi-robo, do-
tando este sistema de um mecanismo, que seja capaz de obter a sua posicao absoluta no am-
biente de trabalho. No caso, pretende-se equipar cada um dos robos com primitivas de localizacao.
Assim, e devido as limitacoes proprias do sistema GPS de nao funcionar dentro de portas,
torna-se necessario recorrer a metodos alternativos de localizacao. Neste sentido, e de modo a
introduzir pontos de sincronismo de posicao absoluta para ambientes interiores e utilizado um
sistema de visao aereo, que permite a visualizacao de todo o ambiente de trabalho, sendo capaz
de, por um lado, identificar cada robo presente neste individualmente, e por outro, torna possıvel
a extracao das principais caraterısticas que retratam o comportamento de cada robo presente no
ambiente de trabalho, nomeadamente: a sua posicao (a duas dimensoes) (x,y), orientacao (a),
vector velocidade (X,Y), velocidade angular (A), aceleracao linear (m) e aceleracao angular (r).
Para o efeito, optou-se pela utilizacao do software open source reacTIVision1, que permite o
seguimento de marcas em objetos fısicos.
Atraves deste metodo, e possıvel fornecer aos robos um conjunto de informacao espacial
de forma simples, evitando calculos de odometria que podem ser complexos, e elimina decor-
rentes erros que afetam a medicao da distancia percorrida. Para alem disso, outro dos aspetos
importantes relativos a esta aplicacao, e o fato de esta ser uma boa ferramenta de analise de
algoritmos implementados, uma vez que a visualizacao da evolucao da trajetoria destes robos
ocorre em tempo real. Desta forma, o algoritmo desenvolvido e monitorizado pela aplicacao
1Disponıvel em: http://reactivision.sourceforge.net
-4- Plataforma de testes para sistema multi-robo(MRS)
1.2. Breve descricao da solucao
reacTIVision, sendo possıvel a sua avaliacao atraves do desempenho dos robos no ambiente de
trabalho.
Assim, de modo a proceder a implementacao de uma plataforma de teste para sistemas
multi-robo (MRS), esta dissertacao assume como objetivos:
1. Por um lado, uma proposta de solucao que consiga efetuar o tracking do robo e suas
especificacoes (software reacTIVision, localizacao da camara, luzes e marcas nos robos);
2. Por outro lado, pretende-se fornecer primitivas de localizacao a cada robo presente no
ambiente de trabalho;
3. Obter uma ferramenta que possibilite a avaliacao de um algoritmo desenvolvido;
4. Por ultimo, deseja-se implementar e testar a solucao proposta, nomeadamente atraves
da constituicao de formacoes (coluna e oblıqua), utilizando comunicacao direta do PC
central para os robos, documentando e avaliando todos os resultados obtidos.
Na Figura 1.2, e possıvel visualizar o objetivo da implementacao da solucao proposta.
Figura 1.2: Perspectiva geral da solucao proposta
1.2 Breve descricao da solucao
Esta dissertacao assume duas abordagens relativamente ao seu conteudo. A primeira incide
sobre a montagem de uma mesa de testes, atraves do posicionamento de uma camara sobre
Plataforma de testes para sistema multi-robo(MRS) -5-
1.3. Organizacao da dissertacao
esta, avaliando as condicoes favoraveis de iluminacao e de contraste, necessarias ao bom fun-
cionamento do sistema; por outro lado, pretende-se fornecer primitivas de localizacao a cada
robo do Sistema Multi-Robo. Para o efeito utiliza-se esta camara, como um simples sensor de
imagem sendo responsavel pela extracao de informacao sobre o que se passa no ambiente de
teste, nomeadamente, a posicao, a velocidade e a aceleracao linear e angular, de cada um dos
robos individualmente.
Esta camara, por sua vez, encontra-se conectada a um PC central atraves de ligacao USB,
permitindo a visualizacao e a recolha de dados do sistema em tempo real. Desta forma, os
robos nao calculam a sua posicao relativa atraves de odometria, evitando a acumulacao de erros
com o decorrer do tempo. Esta informacao e obtida atraves da aplicacao reacTIVision, que e
uma aplicacao Open Source, Cross-Platform, orientada a visao por computador, que possui um
algoritmo rapido e robusto para fazer o seguimento (tracking) de marcadores especıficos e que
podem ser anexados a objetos fısicos, bem como, o tracking da ponta de dedos. Esta informacao
e disponibilizada, em tempo real, atraves do display destes dados sob a forma de mensagem,
na consola no da sua aplicacao no PC, podendo, posteriormente, estes dados ser enviados pela
rede de Internet atraves do protocolo TUIO.
Para o teste da solucao proposta sao utilizados mini-robos, que possuem a vantagem de
serem facilmente manuseaveis, tornando-se ideais para efetuar testes num ambiente montado
numa mesa ou bancada. O facto de ja existir um conjunto destes mini-robos no Laboratorio de
Robotica do DEI, no qual ja foi feito trabalho de investigacao, permite, a partida, a existencia
de alguma informacao compilada sobre o seu funcionamento e utilizacao, de forma a poderem
serem implementados os algoritmos pretendidos. No caso, os mini-robos utilizados no decorrer
desta dissertacao sao os mini-robos Khepera I.
A Figura 1.3 ilustra o fluxo de informacao no sistema implementado.
1.3 Organizacao da dissertacao
A dissertacao esta ordenada segundo a ordem temporal do trabalho elaborado, seguindo
pontos definidos pelos objetivos no primeiro capıtulo.
O primeiro capıtulo aborda uma breve introducao de sistemas multi-robo e sao enunciadas as
categorias, onde cada metodo para o calculo da posicao do robo no espaco se insere. Para alem
disto, e tambem descrita a motivacao e os objetivos deste trabalho, bem como, a organizacao da
dissertacao.
O capıtulo dois explora o estado da arte de sistemas que facam uso de aplicacoes de recon-
hecimento de marcas fiduciais, nomeadamente as suas vantagens e/ou desvantagens intrınsecas,
relativamente com o trabalho em causa. Sao tambem apresentados exemplos de solucoes im-
plementadas que tirem partido da visao aerea de uma camara exposta sobre a mesa de trabalho
e que realizem o feedback dos dados recolhidos.
-6- Plataforma de testes para sistema multi-robo(MRS)
1.3. Organizacao da dissertacao
Figura 1.3: Representacao do fluxo de dados (Malha Fechada)
No capıtulo tres e apresentada com mais detalhe a solucao proposta, assente no software
de reconhecimento de marcas fiduciais reacTIVision, assim como, a descricao do protocolo
utilizado para a comunicacao com os mini-robos Khephera I. E tambem exposto o processo de
preparacao e montagem dos dos varios constituintes do sistema.
O capıtulo quatro procede a apresentacao de um pequeno resumo da arquitetura de controlo
utilizada para a constituicao de formacoes ordenadas e, posterior, descricao e correspondente
analise, dos resultados experimentais obtidos durante a fase de testes, para a solucao proposta.
No ultimo capıtulo apresentam-se as conclusoes e as perspectivas para a continuacao do
trabalho no futuro.
Plataforma de testes para sistema multi-robo(MRS) -7-
Capıtulo 2
Estado da Arte
A utilizacao cada vez mais crescente de robos a nıvel mundial, quer de robos industriais,
quer de robos domesticos, que focam a sua interacao com o ser humano, e resultado da adaptacao
destes robos a realidade do ser humano, ajudando este na realizacao das suas tarefas. Neste sen-
tido, e porque algumas algumas tarefas sao desempenhadas de forma mais eficiente atraves da
utilizacao de um conjunto de robos, do que propriamente por um robo apenas, torna-se impor-
tante avaliar o comportamento e o desempenho destes sistemas multi-robo.
Assim, e uma vez que, a validacao de algoritmos pode ser moroso e difıcil, sao cada vez
mais utilizados sistemas multi-robos de dimensoes reduzidas, pois estes sao mais praticos de
serem utilizados numa mesa de teste, nao requerendo grande espaco para a sua utilizacao. Deste
modo, pretende-se demonstrar que a utilizacao deste tipo de sistemas constitui um bom metodo
para implementar novos algoritmos e de, posteriormente, analisar o seu desempenho.
Kowalczyk [7] compara tres tipos de arquitetura de controlo utilizadas em sistemas multi-
robo. A primeira e um modelo lıder-seguidor (leader-follower), onde os robos seguem um
robo especifico designado lıder. Deste modo, o lıder tem a sua trajetoria pre-definida, sendo
acompanhado pelos seus seguidores na realizacao da respetiva tarefa, mantendo-se as relacoes
espaciais entre todos, tendo em conta o trabalho a desempenhar. Ja no inverso, isto nao se
verifica, uma vez que, quando um robo seguidor vira (p.e.), os outros robos na formacao nao
sao afetados pela manobra. A segunda trata-se do modelo de estrutura virtual, que considera
que cada robo de um sistema multi-robo, como o proprio nome do modelo indica, faz parte de
uma estrutura rıgida imaginaria, movendo-se como se fizesse parte desse mesmo corpo rıgido,
nao existindo nenhum lıder para o efeito. Por fim, a terceira trata-se do modelo comporta-
mental, onde cada robo possui uma serie de comportamentos elementares, como por exemplo,
aproximar-se de um alvo e afastar-se de obstaculos. O comportamento efetuado depende, di-
retamente, da funcao dos comportamentos elementares. A arquitetura de controlo adotada no
sistemas multi-robo utilizado e o modelo lıder-seguidor.
Borenstein [5] define estes marcadores fiduciais (landsmarks), como figuras distintas que
permitem ao robo serem reconhecidas, atraves de sensores de entrada. Estas sao escolhidas com
9
cuidado, de forma a permitir a sua identificacao (contraste suficiente com o plano de fundo).
Um robo pode utilizar estas landmarks para a sua navegacao; onde as suas caracterısticas de-
vem ser conhecidas e armazenadas em memoria do robo. A principal funcao da landmark e
portanto, permitir a sua identificacao e, posteriormente, conhecer a posicao exata do robo. Es-
tas landmarks podem classificadas em duas grandes categorias:
• Naturais - sao objetos ou figuras que ja se encontram inseridas no meio ambiente, e
que permitem outras funcoes, para alem da navegacao do robo (funcionam melhor em
ambientes estruturados, tais como, portas, juncoes de paredes, etc.)
• Artificiais - sao objetos ou marcas especialmente desenhadas e criadas, que precisam de
ser colocadas no meio ambiente, apenas com o proposito de permitir a navegacao do robo.
A abordagem seguida assenta portanto, num sistema de visao global (Global Vision), onde
pontos caraterısticos que constituem um padrao num robo movel sao identificados e localizados
desde uma vista unica [5]. Desta forma, o uso de camaras colocadas numa localizacao fixa no
meio ambiente de trabalho, aumenta o espaco de trabalho, sujeito ao alcance dos sensores.
Existem estudos semelhantes, tendo em conta a analise de um sistema multi-robo, utili-
zando um camara colocada sobre a bancada de ensaios, para o seguimento de robos e a sua
monitorizacao em tempo real, e que seguem esta abordagem de visao global.
Sahin [8] apresenta-nos um ambiente de teste integrado, de nome KITE, que permite avaliar
a localizacao e os algoritmos de navegacao utilizados pelos robos. Para tal, recorre a utilizacao
de mini-robos Khepera I, que utilizam um marcador na sua superfıcie, permitindo a sua detecao
por uma camara colocada sobre o ambiente de trabalho, atraves da qual obtem as coordenadas de
cada mini-robo, usando um sistema de coordenadas comum pelo sistema. Por outro lado, existe
uma camara a bordo do robo, que permite a implementacao de um algoritmo de navegacao, ba-
seado em marcas artificiais presentes no ambiente de trabalho. Deste modo, e possıvel analisar
o desempenho destes algoritmos de navegacao e de localizacao em tempo real. A identificacao
e a localizacao dos robos e feita atraves de um sistema desenvolvido, que consiste num modulo
de segmentacao e de localizacao. O primeiro e responsavel pela detecao e pela segmentacao de
um objeto, e o segundo responsavel pela sua localizacao atraves de mudancas no tamanho do
objeto, enquanto o robo se desloca.
Hawick [9] apresenta um sistema vocacionado para utilizadores moveis, tais como, PDA’s.
O seu objetivo visa recolher um conjunto de informacoes padrao acerca da sua utilizacao, que
passam pela sua informacao espacial e pela sua informacao pessoal, designadas de preferencias
ativas. Desta forma, dependendo da localizacao do utilizador, sao efetuadas um conjunto de
operacoes pre-definidas (p.e., quando se encontrar numa ou varias localizacoes desligar o som
do dispositivo). Assim, e como forma de teste, recorre a utilizacao de um conjunto de robos
-10- Plataforma de testes para sistema multi-robo(MRS)
Cybot Mechatronics, que correm o programa prototipo DISCWorld, que interagem entre si, e
comunicam para uma estacao base, supervisionadas por uma camara colocada sobre o ambiente
de trabalho, que extrai a localizacao exata dos robos.
Samiloglu [10] propoe um ambiente de teste simples e de custo reduzido, que consegue efe-
tuar o seguimento (tracking), de varios robos simultaneamente, em tempo real. Neste sentido,
utiliza um conjunto de seis robos E-puck, que interagem e se relacionam entre si, numa mesa
de trabalho. Sobre esta, encontra-se situada uma camara, que cobre toda a area de acao da mesa
(120x180 cm). Assim, e utilizada uma camara webcam QuickCam Pro9000, a uma resolucao
de 640x480, conectada a um PC via USB, sendo todo o processamento de imagem feito atraves
de MATLAB, onde todos os calculos sao efetuados. Esta informacao e depois transmitida aos
robos atraves de um interface Bluetooth, permitindo estarem conectados ate sete robos. O pro-
cesso de identificacao e de orientacao, de cada um destes robos, e feito atraves de um conjunto
de tres pontos coloridos, situados sobre o robo. A cor da mesa e de leve cinzento de modo a
maximizar o contraste para a superfıcie do robo.
LabtiVision1 e um projeto de origem Holandes, que visa a implementacao de uma sistema,
em tudo semelhante a reacTable, isto e, um projeto musical com uma superfıcie tactil. Desta
forma, e com vista a chegar a esse fim, este projeto faz uso de uma camara Stingray F125B e um
projetor Optoma EP739H, usufruindo de uma area de trabalho, que utiliza uma mesa de vidro
fosco, de dimensoes: 100x75 cm; esta mesa, por sua vez, encontra-se colocada por cima, a uma
altura de 100 cm, relativamente a camara. Em termos de iluminacao, e porque, a utilizacao do
projetor ao incidir sobre a imagem utilizada pela camara, para efetuar o seguimento de marcas,
vai-se sobrepor a imagem original dos marcadores, interferindo e deteriorando a qualidade do
seguimento por parte do reacTIVision, sao utilizados dois espetros eletromagneticos diferentes.
Assim, e utilizada radiacao infravermelha (IV), situada fora da regiao do visıvel, assim como,
uma camara IV para iluminar os marcadores; e por outro lado, e utilizado o projetor no espetro
visıvel, de modo a dar o feedback visual pretendido. Neste sentido, e utilizado o metodo DI
(Diffuse Ilumination) para proceder a esta iluminacao, recorrendo a barras de alumınio com
LED’s IV na sua extensao.
Noldus [11] e outro exemplo de uma aplicacao integrada, que permite atraves de uma
camara, colocada por cima da bancada de testes, visualizar o comportamento do sistema, conse-
guindo identificar, seguir e gravar a atividade do sistema. Contudo, este estudo nao transmite a
informacao recolhida atraves da camara para os robos (posicao/orientacao,etc.), limitando-se a
visualizacao do sistema para posterior analise.
O ARTag, apresentado por Fiala [12], e outra proposta de um sistema de marcadores pla-
nares, cujos contornos sao reconhecidos pelo algoritmo de visao de computador, que atribui a
cada um destes contornos uma identificacao unica. Neste caso, este sistema tem a capacidade
de reconhecer ate dois mil e dois marcadores diferentes. Tal como o reacTIVision, o ARTag,
1Mais informacoes em: https://trac.v2.nl/wiki/LabtiVision
Plataforma de testes para sistema multi-robo(MRS) -11-
tambem esta disponıvel para fins nao comerciais de forma gratuita2. O ARTag e um sistema
de identificacao de marcadores considerado robusto, ja que foi especialmente desenvolvido de
forma a minimizar os seguintes problemas: 1. Problemas de correspondencia dos marcadores
- falsos positivos; 2. Obter uma reduzida taxa de confusao intra-marcador; 3. Problemas de
correspondencia dos marcadores - falsos negativos; 4. Tamanho minimo em pixeis, em que
seja possıvel a detecao do marcador; 5. Imunidade a variacoes das condicoes de iluminacao
(condicoes adversas de iluminacao com oclusao); e 6. jitter detection, isto e, a quantidade
de oscilacao que existe na imagem ao detetar os marcadores. Atendendo a medicao destes
parametros, Fiala, apresenta o resultado da avaliacao da performance do sistema de marcadores
fiduciais ARTag. Desta forma, permite a sua incorporacao em aplicacoes onde, de modo geral,
e necessario, a posicao do marcador em relacao a camara, ajudando a navegacao do robo atraves
da colocacao destes marcadores no seu percurso (landmark navegation) ou em aplicacoes que
efetuam o seguimento da posicao destes marcadores.
Uma vez que existem varios sistemas de marcadores torna-se necessario avaliar o seu de-
sempenho. Desta forma, Zhang X. [13] apresenta uma comparacao entre alguns dos tipos de
sistemas de marcadores existentes, apresentando os seus resultados, nomeadamente avaliando-
os quanto a sua usabilidade, eficiencia, precisao e fiabilidade. Desta forma, sao apresentados os
pontos fortes e os pontos fracos, de cada um dos sistemas de marcadores analisados.
A SwisTrack3 e uma ferramenta Open Source, madura e estavel, atualmente na sua versao
4, vocacionada nao so para o seguimento de robos, mas tambem de insetos que se encontram
no ambiente de trabalho, tirando partido de uma camara fixa colocada sobre este. Desta forma,
esta ferramenta possui a vantagem de permitir o seguimento de objetos, que nao possuem mar-
cadores artificiais anexados ao mesmo. Este software possibilita o interface com camaras co-
nectadas em tempo real e com ficheiros .AVI gravados. Lochmatter [14] apresenta os compo-
nentes que constituem a arquitetura do software SwisTrack, assim como, retrata os resultados
de experiencias realizadas utilizando, em primeiro lugar, uma camara fixa sobre o ambiente de
trabalho e, em segundo lugar, explica como usar o SwisTrack fazendo uso de varias camaras
sobre o ambiente de trabalho em simultaneo. Relativamente, a arquitetura implementada pelo
SwisTrack, esta e constituıda por uma sequencia ordenada de transformacoes aplicadas a ima-
gem, de modo a conseguir identificar o robo ou inseto. No caso, a aquisicao de imagem e feita
por intermedio de uma camara conectada ao PC, via USB, FireWire ou Basler GigE, sendo
tambem possıvel a aquisicao de imagem por parte de um ficheiro de vıdeo, em formato AVI.
Esta imagem e, primeiramente, convertida para cor ou para tons de cinzento, e posteriormente
convertida numa imagem em binario, atraves de um metodo de segmentacao simples, neste caso
threshold (isto e, atribui o valor um, a valores de pixeis ate determinado limite, atribuindo o va-
lor zero a todos os outros). De seguida, procede-se a detecao de pontos, atraves da detecao de
2Mais informacoes em: http://www.artag.net3Disponıvel em: http://sourceforge.net/projects/swistrack/
-12- Plataforma de testes para sistema multi-robo(MRS)
blob’s, ou seja, um conjunto de pixeis com o mesmo valor numa imagem binaria. A sucessao de
frames de imagem, possibilita efetuar o seguimento destes pontos, assimilando uma trajetoria
para cada um.
A Vicon Motion Systems4 apresenta varias solucoes profissionais completas de alto desem-
penho no ambito de recolha de dados, e de seguimento de objetos em vıdeo em varios ambientes.
Recorrendo a camaras capazes de obter 100 frames/segundo, a uma resolucao de 656x492, com
possibilidade de aumentar esta taxa, ao diminuir a sua resolucao. Dependendo da aplicacao,
permite a identificacao, tanto de marcadores distintos do plano de fundo (background), como
o reconhecimento de um padrao pre-definido, sem o auxilio de qualquer tipo de marcador ar-
tificial. Estas aplicacoes nao se encontram contudo disponıveis de forma gratuita, sendo a sua
utilizacao paga.
Sirota [15] apresenta-nos o RoboTracker, outro exemplo de Global Vision, onde a camara
se encontra posicionada sobre o ambiente de trabalho, onde os robos de deslocam. Por sua
vez, estes utilizam um chapeu colorido que funciona como marcador, permitindo identificar
e analisar, a posicao de cada robo individualmente. Estes dados podem ser transmitidos via
TCP/IP para qualquer cliente. Esta aplicacao tambem nao se encontra disponıvel de forma
livre.
A seguir, apresentam-se alguns estudos que utilizam metricas para a caraterizacao de um
sistema multi-robo.
Arkin e Balch [16] utilizam tres tipos de metricas para avaliar a performance de um sistema
multi-robo, nomeadamente:
1. Relacao de Comprimento do Caminho (Path Length Ratio) - que e a distancia media
percorrida pelos robos, dividida pela distancia em linha reta do percurso;
2. Erro de Posicao Media (Average Position Error ) - correspondente ao deslocamento medio
da posicao correta, ao longo de todo o trajeto percorrido;
3. Percentagem de Tempo Fora da Formacao (Percent of Time Out of Formation) - traduz a
percentagem de tempo fora da formacao, refletindo o tempo em que os robos saem das
suas posicoes durante uma formacao.
Fredslund e Mataric [17] realizaram cerca de quarenta experiencias recorrendo a robos
moveis, com o objetivo de formarem e conservarem uma forma geometrica pre-definida, ao
longo da tarefa. A sua performance e avaliada recorrendo a metricas, que se baseiam na
utilizacao de um criterio de percentagem de tempo dentro da formacao. Sendo que, considera-se
que um robo se encontra dentro da formacao se:
4Disponıvel em: http://www.vicon.com/index.html
Plataforma de testes para sistema multi-robo(MRS) -13-
1. Dispersao Uniforme (Uniform Dispersion) - todos os robos pertencentes a formacao
mantem a mesma distancia entre os robos que se encontram na sua vizinhanca, com um
tolerancia maxima de εd1.
Isto e, matematicamente falando, diz-se que: ∃ d, tal que ∀ os pares de vizinhos imediatos
(Ri1,Ri2), de modo que:
|d−dist(Ri1,Ri2)| ≺ εd1, (2.1)
|d−ddese jada| ≺ εd1. (2.2)
2. Forma (Shape) - os robos encontram-se nas posicoes atribuıdas dependendo da formacao
desejada e com uma tolerancia maxima de εd2 ao redor da posicao desejada. Nenhum
angulo na sua forma original deve ser esticado mais de εa, de modo que os pontos sejam
considerados corretos.
∃ uma funcao de alongamento f com f (G)=G, tais que ∀ angulos Θ ∈ G:
|f(Θ)−Θ| ≺ εa, (2.3)
e tal que ∀ robos Ri, com uma distancia dist(Ri,G) ≺ εd2.
3. Orientacao (Orientation) - Relativamente a orientacao assumida em cada par de robos,
tem-se:
|f(h)−h| ≺ εa, (2.4)
para pequenas εd1, εd2, εa � 0.
Naffin e Sukhatme [18] realizaram experiencias, na area dos sistemas multi-robo, usando
apenas sensores com o objetivo manterem a sua formacao geometrica, sem coordenacao centra-
lizada. Estas experiencias foram realizadas utilizando como formacao uma simples linha. Para
avaliar a performance do sistema foram utilizadas as seguintes metricas:
1. Erro de Posicao (Positional Error) - onde uma determinada formacao e caraterizada pe-
los seguintes parametros, G indicadora de uma determinada forma geometrica, h e a
posicao desejada e d correspondente ao espaco entre robos desejada, sendo que exis-
tem K posicoes para o lıder, que representam a formacao perfeita. Assim, existindo N
robos esforcando-se para construir a respetiva formacao, onde N ≤ K, o erro de posicao
da formacao e definido como
P =1N
N
∑i=1
|D(pi,ki), (2.5)
-14- Plataforma de testes para sistema multi-robo(MRS)
onde pi e a enesima posicao do robo (relativamente ao lıder) e D(pi,ki) e a distancia entre
duas posicoes. Um determinado conjunto de robos encontra-se em formacao se P ≺ ε,
onde ε e uma tolerancia especificada pelo utilizador.
2. Tempo de Convergencia (Time to Converge) - tempo de convergencia Tc(N) e definido
como o tempo necessario para uma formacao atingir um tamanho N e estar em formacao
para esse tamanho.
3. Percentagem de Tempo na Formacao (Percentage of Time in Formation) - a percentagem
de tempo na formacao e dada por:
F =tin
ttotal, (2.6)
onde tin e o tempo de formacao e ttotal e o tempo total decorrido ate a formacao atingir o
seu tamanho atual.
Plataforma de testes para sistema multi-robo(MRS) -15-
Capıtulo 3
Desenvolvimento da plataforma de testes
Esta dissertacao assume duas abordagens relativamente ao seu conteudo. A primeira incide
sobre a montagem de uma mesa de testes, atraves do posicionamento de uma camara sobre
esta, avaliando as condicoes favoraveis de iluminacao e de contraste, necessarias ao bom fun-
cionamento do sistema; por outro lado, pretende-se fornecer primitivas de localizacao, a cada
robo do sistema multi-robo. Para o efeito utiliza-se esta camara, como um simples sensor de
imagem sendo responsavel, pela extracao de informacao sobre o que se passa no ambiente de
teste, nomeadamente, a posicao, a velocidade e a aceleracao linear e angular, de cada um dos
robos individualmente.
Esta camara, por sua vez, encontra-se conectada a um PC central atraves de ligacao USB,
permitindo a visualizacao e a recolha de dados do sistema em tempo real. Desta forma, os
robos nao calculam a sua posicao relativa atraves de odometria, evitando a acumulacao de erros
com o decorrer do tempo. Esta informacao e obtida atraves da aplicacao reacTIVision, que
e uma aplicacao Open Source, Cross-Platform, orientada a visao por computador, que possui
um algoritmo rapido e robusto para fazer o seguimento (tracking) de marcadores especıficos
e que podem ser anexados a objetos fısicos, bem como, tracking da ponta de dedos. Esta
informacao e disponibilizada, em tempo real, atraves do display destes dados numa consola no
PC, posteriormente, estes dados podem ser enviados pela rede de Internet atraves do protocolo
TUIO.
Assim, e utilizada a aplicacao reacTIVision que determina as posicoes e orientacoes dos
robos, atraves da colocacao de uma camara sobre a mesa de trabalho, eliminando a necessidade
de lidar com odometria de baixo nıvel (estimacao e correcao de erros).
Desta forma, e tirando partido das potencialidades do reacTIVision que extrai um conjunto
de parametros relativos a cada robo, e os torna disponıveis no PC, e possıvel dispor destes dados
e reenviar para cada robo, a sua posicao absoluta no ambiente de trabalho, bem como, outros
parametros disponıveis. Desta forma o fluxo de dados torna-se um ciclo em malha fechada,
sendo que cada robo e alimentado com informacao proveniente da camara, que retrata o seu
proprio movimento, ja demonstrado na Figura 1.3.
17
Assim, de modo a fazer pleno uso desta aplicacao, e a implementar este ciclo de dados,
procedeu-se a sua implementacao utilizando um conjunto de tres robos que utilizam uma ar-
quitetura do tipo lıder seguidor, ja descrita anteriormente. Posteriormente, sao utilizadas tres
metricas, enumeradas por Fredslund e Mataric [17], para avaliar o desempenho do sistema
multi-robo enquanto formacao.
Neste sentido, e uma vez em posse destes dados disponibilizados pelo reacTIVision , optou-
se em primeiro lugar, por uma estrategia de comunicacao centralizada no lıder, isto e, onde
todos os pacotes de dados transmitidos pelo PC central sao recebidos primeiramente pelo lıder
e depois redirecionados para o robo destinatario. Esta estrategia pode ser visualizada a seguir
na Figura 3.1
Figura 3.1: Esquema da solucao implementada centralizada
Esta solucao implementada, com comunicacao centralizada no Mestre (ou lıder) revelou-
se inconsequente na realizacao dos ensaios experimentais com tres Kheperas I em simultaneo,
ainda que com apenas dois robos, o Mestre consegue convergir para o seu objetivo (goal),
apesar da comunicacao para com o seguidor (ou escravo) ser efetuada de forma lenta. Nas
experiencias com os tres Kheperas I verificou-se uma sobrecarga de dados no Master, estando
este essencialmente na grande maioria do tempo a lidar com comunicacoes, ora a receber dados,
ora a reencaminhar estes para a Slave correspondente. Como resultado o Master nao consegue
convergir para o objetivo pretendido. Desta forma, optou-se por implementar outra metodologia
-18- Plataforma de testes para sistema multi-robo(MRS)
de comunicacao, onde cada um dos robos recebe diretamente, a partir do PC a sua localizacao
no ambiente de trabalho, libertando desta forma o Master de todo o trabalho de rececao e
verificacao do pacote de dados, e do posterior reencaminhamento. Esta solucao e apresentada a
seguir, na Figura 3.2.
Figura 3.2: Esquema da solucao implementada distribuıda
Com esta estrategia de comunicacao distribuıda, verificou-se uma melhoria de desempenho
de todos os robos em geral, convergindo o Master de forma mais rapida para o objetivo, assim
como, ambas as Slaves viram a rececao destes dados de atualizacao ser efetuada de forma mais
celere, ainda que em alguns casos, com dificuldade na rececao de dados por parte do PC central.
De referir que, do ponto de vista do PC central, e em termos de pacotes de dados envia-
dos, os dois metodos descritos anteriormente, utilizam um pacote de dados relativo a cada um
dos robos, assim sendo, se a informacao obtida corresponder ao Robo1 (robo com o marcador
1), sera transmitida essa informacao num pacote com o marcador do robo 1, e assim suces-
sivamente para os restantes robos. Assim, e de modo complementar, optou-se tambem pela
implementacao de outro metodo de envio de dados, onde toda a informacao posicional dos tres
robos e transmitida num pacote de dados de forma cıclica. A Figura 3.3 demostra este processo
de transmissao de dados.
Plataforma de testes para sistema multi-robo(MRS) -19-
3.1. Mini-robos Khepera I
Figura 3.3: Ilustracao do metodo de transmissao de dados de forma cıclica
3.1 Mini-robos Khepera I
Tal como foi dito atras, os mini-robos utilizados no decorrer desta dissertacao foram os
mini-robos Khepera, mais concretamente, os mini-robos Khepera de primeira geracao, vulgar-
mente designados de Khepera I (ver Figura 3.4). O mini-robo Khepera I foi desenvolvido pela
Escola Politecnica Federal de Lausanne (EPFL - Ecole Polytechnique Federale de Lausanne)
e e atualmente comercializado pela empresa Suica K-Team1, que fabrica e desenvolve robos,
essencialmente vocacionados para o ensino e investigacao academica na aerea da robotica.
Fonte: http://ubirobot.ucd.ie/files/media/09112009468.jpg
Figura 3.4: Ilustracao do robo Khepera I
Estes robos de pequenas dimensoes, com 70 mm de diametro e 30 mm de altura (visıveis na
Figura 3.5), sao equipados com modulos radio compactos, que dotam o robo de uma capacidade
de comunicacao sem fios, permitindo o empacotamento de dados, segundo o formato suportado,
assim como, a transmissao e a rececao de dados. A seguir na Figura 3.5 apresentam-se tres
imagens dos robos Khepera I.
No caso, a sintaxe do protocolo utilizado para o envio e rececao de mensagens imposta pelos
robos Khepera pressupoe em primeiro lugar a identificacao do robo destinatario, em segundo
lugar o tamanho da mensagem a enviar e por fim, a mensagem propriamente dita a transmitir,
seguido do valor treze (0x0D CR), indicador do final da mensagem. De notar que o protocolo
utilizado pelo Khepera I limita a mensagem de dados a enviar a 16 bytes.
1Mais informacoes em: http://www.k-team.com/
-20- Plataforma de testes para sistema multi-robo(MRS)
3.1. Mini-robos Khepera I
(a) (b)
(c)
Figura 3.5: Robos Khepera utilizando o marcador da aplicacao reacTIVision ao lado de uma moeda de2AC: (a), (b) e (c)
Desta forma, e possıvel a comunicacao entre os diferentes mini-robos e a Torre Base, trans-
mitindo esta os dados a uma frequencia de 433 MHz. De resto, de referir a inexistencia de qual-
quer protocolo de acesso ao meio por parte dos robos Khepera, o que possibilita a ocorrencia
de colisoes de pacotes de dados durante a comunicacao PC/robo e robo/robo. Assim, o robo
limita-se ao simples envio do pacote de dados sem qualquer mecanismo de controlo de colisoes.
As suas principais caracterısticas sao resumidas na Tabela 3.1, a seguir apresentada.
Da tabela salienta-se o facto, do Khepera I nao possuir grande capacidade de processamento,
sendo que o seu processador nao suporta funcoes trigonometricas [19]. Outra das limitacoes do
Khepera I e, o facto de nao possuir uma grande quantidade de memoria, sendo que solucao im-
plementada se encontra no limite de memoria suportada pelo robo. Por outro lado, o mini-robo
e robusto e de tamanho reduzido, o que facilita o seu manuseamento, sendo bastante versatil
nesse aspeto, permitindo realizar varios testes de forma simples e pratica. Assim, e possıvel
testar a solucao implementada e averiguar os acerca dos seus resultados.
De notar que, os ensaios (na sua maioria) sao efetuados tirando partido das baterias proprias
do robo, que e responsavel pela alimentacao deste, permitindo o seu funcionamento de forma
autonoma ao longo de ≈30 min. Desta forma, torna a execucao dos testes mais pratica e mais
Plataforma de testes para sistema multi-robo(MRS) -21-
3.2. Aplicacao reacTIVision
Tabela 3.1: Especificacoes Tecnicas - Khepera I
Especificacoes Tecnicas
Processador Motorola 68331, 25 MHzRAM 256 kbytesFlash 256 kbytesMotores 2 Servomotores DC c/ encoders (≈ 12 pulsos/mm)Velocidade Max: 0.5 m/s, Min: 0.02m/sSensores 8 infravermelhos e de luz (≈ 20 mm a 60 mm)I/O 3 Entradas Analogicas (0 - 4.3V, 8bit)Energia Cabo de Energia ou Baterias NiCd (≈ 30 min.)Comunicacao Porta Serie Standard, ate 38400bpsExtensao de Barramento Modulos de expansao c/ barramento K-ExtensionDiametro: 130 mm Altura: 70 mmPeso: ≈ 690 g
comoda, evitando o natural constrangimento da utilizacao de cabos no decorrer dos testes. As-
sim, o programa desenvolvido e inicialmente descarregado para o Khepera I utilizando os seus
cabos serie proprios para o efeito, e posteriormente retirados, sendo o robo alimentado atraves
das suas proprias baterias, necessitando apenas de comutar o seu swicth das baterias correspon-
dente. Desta forma, o robo funciona de forma independente, sem o auxilio de qualquer cabo.
O unico aspeto negativo, e o fato de, ao nao existir qualquer cabo entre o robo e o PC central,
o display do estado da comunicacao nao pode ser observado em tempo real, mas apenas no fim
da experiencia ao descarregar o log de cada robo.
O log e a apresentacao da evolucao dos parametros mais importantes em termos da arqui-
tetura utilizada, no caso, e exibido um vetor com a seguinte sintaxe, por cada iteracao: [X, Y,
Φ, Xgoal , Ygoal , d0, d1, d2, d3, d4, d5, dt, TIME UPDATE]. Onde, X, Y e Φ correspondem a
posicao do robo em mm, e a sua orientacao em graus; Xgoal e Ygoal correspondem a posicao
final do robo para a qual este deve convergir; d[0..5] descrevem o valor em termos de proximi-
dade de um objeto pelo respetivo sensor de bordo; dt corresponde ao tempo de execucao de um
ciclo; e por fim, TIME UPDATE que representa o tempo em que a atualizacao ocorreu, e que
foi transmitida pelo PC central. Este ultimo parametro foi acrescentado ao vetor a apresentar,
de modo a conhecer o tempo de atualizacao em cada transmissao bem sucedida.
3.2 Aplicacao reacTIVision
O reacTIVision e um software orientado para o seguimento em vıdeo de marcadores es-
pecıficos em tempo real. Neste sentido, este utiliza os seus proprios marcadores caracterısticos
que podem ser anexados a objetos fısicos, que sao, por sua vez, identificados e seguidos atraves
de um algoritmo de visao otimizado para este tipo de marcador especifico, melhorando a velo-
-22- Plataforma de testes para sistema multi-robo(MRS)
3.2. Aplicacao reacTIVision
cidade do processo de reconhecimento e tornando-o mais robusto.
Esta aplicacao foi desenvolvida em primeira instancia, pela Universidade Fabra de Barce-
lona, por M. Kaltenbrunner e R. Bencina, com o proposito da sua incorporacao na Reactable2,
que e basicamente uma mesa com superfıcie tatil, que reproduz musica atraves do toque e do
movimento de objetos em cima desta.
De referir que, o reacTIVision e uma aplicacao multiplataforma (cross-platform), em codigo
aberto (Open Source), que pode ser descarregada de forma gratuita no site do reacTIVision, no
sourceforge3, para cada uma das plataformas disponıveis (para alem do algoritmo de visao do
reacTIVision, encontra-se disponıvel uma aplicacao cliente e um simulador da aplicacao).
Relativamente aos marcadores utilizados por esta aplicacao, existem varias famılias destes
marcadores, que foram mudando e evoluindo ao longo do tempo, de forma a maximizar a
eficiencia de detecao e do seguimento destes marcadores, variando, essencialmente, no seu ta-
manho e na sua morfologia. No caso, o reacTIVision apresenta tres famılias de marcadores dife-
rentes na sua topologia: marcadores classic, marcadores dtouch e marcadores amoeba. Sendo
que a topologia amoeba a mais recente e a topologia classic a mais antiga. Para a solucao
implementada, sao utilizados os marcadores da famılia amoeba, que possui dentro desta, tres
tipos de marcadores que variam apenas no seu tamanho: legacy (5,5 cm), small (3 cm) e mini-
set (2,5 cm), pelo que se optou pela utilizacao dos marcadores legacy, devido ao seu tamanho
ser compatıvel com o tamanho dos robos utilizados, e, consequentemente, devido a sua menor
exposicao a distorcao da camara. Estes marcadores utilizados apresentam duzentos e dezesseis
marcadores distintos deste tipo, que sao claramente suficientes para anexar aos robos, e recriar
as experiencias pretendidas. A seguir, na Figura 3.6 sao apresentados os marcadores deste tipo,
utilizados durante as experiencias.
5,5
cm
5,5 cm
Figura 3.6: Exemplo dos marcadores utilizados pela aplicacao reacTIVision[20]
2Mais informacoes em: http://www.reactable.com/products/3http://reactivision.sourceforge.net/
Plataforma de testes para sistema multi-robo(MRS) -23-
3.2. Aplicacao reacTIVision
Estes marcadores podem ser imprimidos em qualquer impressora, preferencialmente numa
folha branca, de modo a maximizar o contraste do marcador para com o papel imprimido [21].
Neste sentido, e porque o plano de fundo utilizado e uma tela branca, deve-se evitar a sua
impressao numa folha que nao seja branca. De forma complementar, e de modo a evitar riscos
e deformacoes destes marcadores, cobriu-se o marcador com uma pelıcula transparente, nao
interferindo assim, na detecao do marcador por parte da aplicacao. Na Figura 3.7 apresenta-se
o marcador selecionado, com um pelıcula protetora transparente.
Figura 3.7: Ilustracao do marcador da aplicacao reacTIVision
Desta forma, atraves da utilizacao destes marcadores anexados a cada robo, o reacTIVision
extrai um conjunto de informacao relativos aos marcadores, que por sua vez, sao relativos a
cada um destes robos, que assentam nas propriedades do movimento e da trajetoria tomada pelo
robo.
De referir que, a aplicacao limita-se apenas a monitorizacao da atividade do sistema, iden-
tificando cada robo presente no ambiente de trabalho, indicando a sua posicao, bem como,
outros parametros relativos a cada robo, sendo esta informacao apresentada em tempo real na
consola da aplicacao. Na Figura 3.8 e ilustrada a aplicacao reacTIVision no decorrer de uma
experiencia.
De modo a permitir a monitorizacao de cada um dos seus marcadores presentes em tempo
real, a aplicacao reacTIVision faz uso do seu protocolo TUIO, baseado no protocolo OSC (Open
Sound Control) [22]. Atraves deste, sao retratados todos os acontecimentos que se vao suce-
dendo ao longo do tempo, no ambiente de trabalho. Assim, e do modo a atingir esse proposito,
este protocolo classifica toda as mensagens em duas grandes categorias: set messages e alive
messages. As alive messages indicam que marcador e que se encontra no ambiente de trabalho,
atraves da atribuicao de uma identificacao temporaria a cada marcador (ID da Sessao); ja as set
messages apresentam toda a informacao correspondente a cada marcador, nomeadamente, a sua
posicao, orientacao e restantes parametros.
A seguir na Tabela 3.2 apresenta-se a sintaxe de uma mensagem da aplicacao reacTIVision
no plano a duas dimensoes, com que sao atualizados os dados de cada robo, no caso, uma set
-24- Plataforma de testes para sistema multi-robo(MRS)
3.2. Aplicacao reacTIVision
Figura 3.8: Captura de ecra da aplicacao reacTIVision durante um teste
message. De igual modo, e apresentada a Tabela 3.3 com o significado de cada um dos seus
parametros.
Tabela 3.2: Sintaxe de uma set message apresentada pela aplicacao reacTIVision
set s i x y a X Y A m r
Tabela 3.3: Descricao dos parametros de uma set message utilizada pelo protocolo TUIO
Parametros Tipo Definicaos int32 ID da Sessaoi int32 ID do Marcadorx,y float32, Valor [0...1] Posicao [x,y]a float32, Valor [0...2π] Angulo de OrientacaoX .Y float32, Vetor Velocidade LinearA float32 Velocidade Angularm float32 Aceleracao Linearr float32 Aceleracao Angular
Seguidamente, explica-se em pormenor, cada um dos parametros apresentados:
• ID da Sessao (s): Este parametro apresenta a ordem pela qual estes marcadores sao identi-
ficados pela aplicacao reacTIVision, isto e, o primeiro marcador identificado toma o valor
de ID de Sessao de um, o segundo marcador identificado toma o valor de ID de Sessao de
Plataforma de testes para sistema multi-robo(MRS) -25-
3.2. Aplicacao reacTIVision
dois, e assim sucessivamente. Desta forma e atribuıdo um valor temporario a cada mar-
cador detetado no ambiente de trabalho, pois no caso de qualquer um destes marcadores
deixar de ser detetado pela aplicacao, este valor de ID de Sessao e descartado, sendo
atribuıdo a esse marcador um outro valor de ID de Sessao, quando voltar a ser detetado
no ambiente de trabalho.
• ID do Marcador (i): Este parametro corresponde a identificacao fixa e definitiva do
proprio marcador, sendo que, neste caso, existem duzentos e dezasseis marcadores dis-
tintos do tipo utilizado. Desta forma, e atribuıda a cada um destes marcadores, uma
identificacao unica e distinta perante a aplicacao reacTIVision.
• Posicao (x, y): A posicao no ambiente de trabalho, e obtida pelo seu valor no eixo dos
x e y. De notar a necessidade de existencia de referenciais comuns entre a aplicacao
reacTIVision, assim como da arquitetura de controlo utilizada no robos Khepera I. No
caso, optou-se pela inversao do sentido do eixo do x, da aplicacao reacTIVision, de modo
a estes serem comuns. Desta forma, e definido o sentido positivo em ambos os eixos,
apresentado na Figura 3.9.
x
y
Figura 3.9: Referencial de coordenadas utilizadas pelo reacTIVision em x e em y
Para alem disto, a aplicacao apresenta os valores das posicoes no eixo de x e de y
normalizados, isto e, com valores compreendidos entre 0 e 1, sendo posteriormente ne-
cessario multiplicar estes valores pelas dimensoes da mesa de trabalho (largura e compri-
mento), de forma a obter a posicao real do robo no ambiente de trabalho.
• Angulo (a): O angulo de orientacao do robo e apresentado em radianos, e encontra-se
compreendido entre [0...2π] rad. O valor do angulo de orientacao do marcador e obtido
atraves de um vector, que e utilizado para a sua orientacao. Para alcancar este vetor,
e calculado em primeiro lugar, o centroide (centro geometrico) do marcador, tendo em
conta os seus pontos pretos e brancos, seguido do calculo do centroide utilizando apenas
os seus pontos pretos (ou brancos). A linha reta que une estes dois pontos e o vector
usado para a orientacao do marcador. Este processo e facilmente reconhecido atraves da
Figura 3.10, a seguir apresentada.
-26- Plataforma de testes para sistema multi-robo(MRS)
3.2. Aplicacao reacTIVision
Figura 3.10: (a) Marcador da aplicacao reacTIVision (b) Centroide do marcador total (c) Centroide domarcador parcial (d) O vetor orientacao resultante [20]
• Vector Velocidade (X, Y): o vector velocidade e definido como a velocidade do marcador
sobre um dado eixo, isto e, e o valor da velocidade obtida atraves da divisao da distancia
entre duas posicoes, pelo tempo que decorre entre essas duas amostras em segundos. Por
exemplo, o movimento de um marcador da direita para a esquerda, de todo o eixo de
x num segundo, representa um vector velocidade de (1.0,0.0), da mesma forma que, o
movimento de cima para baixo, de todo o eixo do y num segundo, e representado por um
vector velocidade de (0.0,1.0).
• Velocidade Angular (A): O valor da velocidade angular representa a mudanca do angulo
de orientacao que ocorre num instante de tempo, e o seu valor e obtido atraves da divisao
da diferenca dos dois angulos, pela diferenca de tempo das duas amostras em segundos.
Isto e, por exemplo, se o marcador der uma rotacao completa em um segundo, corres-
ponde a um valor de velocidade angular de 1.0 rotacao/segundo.
• Aceleracao Linear (m): O valor da aceleracao linear representa a taxa de variacao da
velocidade linear, e e obtida pela diferenca entre duas amostras de velocidade linear,
dividido pelo tempo em que essas duas amostras ocorreram em segundos.
• Aceleracao Angular (r): O valor da aceleracao angular representa a taxa de variacao da
velocidade angular, e e obtida pela diferenca entre duas amostras de velocidade angular,
dividido pelo tempo em que essas duas amostras ocorreram em segundos.
Atraves da atualizacao em tempo real destas mensagens, relativas a cada robo, a aplicacao
reacTIVision descreve o que acontece no ambiente de trabalho. Como a aplicacao apenas efetua
a monitorizacao dos tres robos no ambiente de trabalho, optou-se pela criacao de um logfile
para cada robo, para onde estes dados sao descarregados, com o intuito de analisar e de carate-
rizar todo o desempenho do robo, a posteriori. Para alem da informacao disponibilizada pelo
reacTIVision, e acrescentado uma etiqueta de tempo, que associa esta informacao ao momento
da ocorrencia.
Esta informacao disponibilizada pelo protocolo TUIO, pode ser selecionada e enviada para
uma aplicacao cliente, atraves da utilizacao do protocolo de transporte UDP.
Plataforma de testes para sistema multi-robo(MRS) -27-
3.3. Construcao da mesa de testes
Para alem da monitorizacao em tempo real do ambiente de trabalho, a aplicacao reacTIVi-
sion possui outras caraterısticas: entre elas, a capacidade de seguir a ponta dos dedos. Para o
efeito, existe um marcador simples e minimo que se pode colocar na ponta do dedo, permitindo
a aplicacao efetuar o seu seguimento ao longo da area de trabalho. Devido ao seu tamanho
reduzido apenas e identificada a sua posicao, nao sendo possıvel identificar a sua orientacao.
Na solucao implementada, e devido ao fato da camara se encontrar posicionada sobre a mesa de
trabalho ao inves, de se encontrar sob a mesa, inviabiliza a aplicacao pratica desta caraterıstica.
Desta forma, esta caracterıstica acaba por nao ser exequıvel nesta aplicacao, uma vez que, seria
necessario colocar este pequeno marcador na ponta do dedo, e virar o dedo em relacao a camara
e nao deslocar este sobre a mesa de trabalho, tornando visıvel toda a extensao do braco. Neste
sentido nao e de todo pratico, a utilizacao desta caraterıstica em termos de solucao proposta.
Para alem disto, a aplicacao permite a sua calibracao de modo a ajustar a grelha da aplicacao
reacTIVision a mesa de trabalho. Para tal, esta aplicacao fornece duas grelhas, uma em forma
retangular e outra de forma quadrada, devendo ser imprimida a respetiva grelha que corresponde
ao formato da mesa de trabalho utilizada. A grelha selecionada deve ser impressa de forma
a obter o tamanho da mesa utilizada, devendo posteriormente ser colocada sobre a mesa de
trabalho. Atraves da visualizacao da aplicacao, verifica-se se ambas as grelhas coincidem,
permitindo o ajustamento da grelha da aplicacao a grelha colocada sobre a mesa de trabalho, no
caso de estas nao coincidirem de forma perfeita.
E tambem possıvel colocar o sistema em pausa e retomar a aplicacao a qualquer momento.
3.3 Construcao da mesa de testes
A mesa de testes constitui um fator importante no desempenho do sistema reacTIVision,
sendo necessario tomar em conta alguns aspetos, antes de se proceder a sua elaboracao, tendo
em vista o maximo desempenho do sistema.
Em primeiro lugar, e necessario diferenciar o metodo utilizado nesta dissertacao com o
metodo para o qual o reacTIVision foi inicialmente projetado. Isto porque, a reacTable para a
qual, o reacTIVision foi inicialmente projetado, utiliza uma camara (e um projetor), por baixo
da mesa de testes. Neste caso, os marcadores sao anexados sob os objetos, possibilitando a
sua detecao atraves da utilizacao de uma superfıcie de acrılico de modo a minimizar a taxa de
detecao de falsos positivos (detecao de lixo).
Deste modo, a camara encontra-se posicionada sobre a mesa de trabalho, a uma distancia
de 1,6 m para a sua superfıcie. As dimensoes da mesa de trabalho sao apresentadas a seguir na
Figura 3.12 e a mesa implementada ilustrada na Figura 3.11.
A seguir, apresentam-se os principais fatores que afetam diretamente o desempenho do sis-
tema.
-28- Plataforma de testes para sistema multi-robo(MRS)
3.3. Construcao da mesa de testes
Figura 3.11: Ilustracao da implementacao pratica da mesa de trabalho
Figura 3.12: Esquematico da mesa de trabalho experimental
3.3.1 Plano de fundo
Desta forma, foram testadas varias pelıculas de cores diferentes como plano de fundo da
mesa de testes. Com o decorrer das experiencias, torna-se evidente que este plano de fundo
(background), influi diretamente no desempenho do sistema, ja que que esta diretamente ex-
posto a camara devendo ser diferenciado, dos marcadores utilizados pelo reacTIVision, de forma
a maximizar o contraste entre o marcador e a tela. De outra forma, pode ocorrer a identificacao
de marcadores fictıcios (lixo), neste plano de fundo introduzindo obvios erros no sistema. Desta
forma, e atraves de experiencias realizadas e possıvel afirmar que, o plano de fundo deve ser
uniforme, isto e, de apenas uma cor, sendo a identificacao dos marcadores mais acentuada,
Plataforma de testes para sistema multi-robo(MRS) -29-
3.3. Construcao da mesa de testes
quando utilizado como plano de fundo uma cor branca.
Comparando estes resultados com outros planos de fundo utilizados, verificou-se que uti-
lizando um amarelo brilhante o desempenho do sistema e semelhante, enquanto que por outro
lado, utilizando uma superfıcie escura (preto), o seu desempenho e manifestamente inferior.
Na Figura 3.13 e apresentado o reconhecimento dos marcadores utilizando uma pelıcula de
cor branca como plano de fundo.
Figura 3.13: Captura de ecra ilustrativa da detecao dos marcadores utilizando uma pelıcula de corbranca como plano de fundo
Neste caso, verifica-se uma uma maior dificuldade de reconhecimento do marcador em
pelıculas de cor escura, em contraste com a sua identificacao em pelıculas de cor clara.
3.3.2 Camara
A qualidade de imagem captada pela camara, nomeadamente a sua resolucao e a sua taxa de
frames/segundo influi diretamente no desempenho do reconhecimento dos marcadores na mesa
de trabalho [21]. Quanto maior for a sua resolucao, mais nıtida e portanto a imagem disponıvel
no PC central, tornando a posterior identificacao dos marcadores mais facil.
A escolha de camara recaiu sobre a Webcam QuickCam Pro9000, que possui uma resolucao
maxima de 1600x1200 pixels a 5fps, a um preco acessıvel. Sendo que, no decorrer das ex-
periencias optou-se pela sua utilizacao, recorrendo a uma resolucao de 1280x720 a 5fps, visto
que a resolucao maxima do PC utilizado ser de 1366x768, nao permitindo visualizar toda a tela
da mesa de trabalho com a resolucao maxima da camara e tornando um pouco pratico a sua
execucao. Durante os ensaios praticos, verifica-se que a escolha desta resolucao e suficiente,
servindo os nossos interesses em termos de desempenho do reconhecimento dos marcadores
-30- Plataforma de testes para sistema multi-robo(MRS)
3.3. Construcao da mesa de testes
fiduciais. Assim, e em paralelo com uma resolucao de 1280x720 a 5fps, e focado toda a area de
testes para a altura da camara utilizada.
E de referir, porem, que a possibilidade da escolha de uma camara de interface firewire, de
alta performance, que combina uma elevada resolucao, bem como uma elevada taxa de FPS,
tal como a utilizada na reacTable original (AVT Guppy F080B), constitui-se como uma opcao
dispendiosa, a qual foi colocada de parte a sua aquisicao. Na Figura 3.14 apresenta-se a selecao
da resolucao utilizada para o decorrer de todas as experiencias, bem como, na Figura 3.15 uma
captura de ecra retirada no decorrer de um teste.
Figura 3.14: Capturas de ecra da selecao da resolucao a utilizar
Figura 3.15: Captura de ecra da aplicacao reacTIVision no decorrer de um teste
Assim, pode-se afirmar que o aspeto negativo da utilizacao desta webcam e o fato do se-
guimento destes marcadores ser efetuado a uma taxa de 5 frames/segundo, sendo por vezes
demasiado lento, retirando a sensacao de movimento em determinados momentos. Para se ob-
Plataforma de testes para sistema multi-robo(MRS) -31-
3.3. Construcao da mesa de testes
ter uma taxa superior a 5 fps a resolucao maxima a utilizar e de 960x720 pıxeis. A seguir na
Figura 3.16 apresenta-se a identificacao dos marcadores utilizados nos quatro cantos da mesa
de testes.
(a) Canto Inferior Direito (b) Canto Inferior Esquerdo
(c) Canto Superior Esquerdo
28cm
30cm
(d) Canto Superior Direito
Figura 3.16: Experimentacao da detecao dos marcadores utilizados em toda a tela: (a), (b), (c) e (d)
Devido ao fato desta webcam possuir uma lente wide angle, isto e, com um angulo de visao
de 75o, verificou-se, durante a fase de ensaios, a ocorrencia de distorcao no canto superior di-
reito da imagem da webcam, tendo por sua vez o reacTIVision muita dificuldade em reconhecer
os marcadores nesse local. Deste modo, perde-se area de trabalho util, pois ao existir distorcao
do marcador, leva a que, por sua vez, o reconhecimento efetivo dos marcadores seja difıcil.
Atraves dos ensaios efetuados pode-se caraterizar esta zona como 30x28 cm.
3.3.3 Iluminacao
Devido ao fato da nossa solucao proposta nao incluir a utilizacao de um projetor e uma
camara em simultaneo, ao contrario da reacTable, projeto sintetizador de musica atraves do
toque, para o qual o reacTIVision, for inicialmente concebido, as condicoes de iluminacao
simplificam-se bastante. Assim sendo, nao ha necessidade da existencia de dois espetros dife-
rentes, possibilitando o funcionamento do sistema, utilizando apenas como iluminacao, lampadas
normais, no caso sao utilizadas lampadas fluorescentes, que apresentam comprimentos de onda
na regiao do visıvel, para a iluminacao da mesa de trabalho.
-32- Plataforma de testes para sistema multi-robo(MRS)
3.4. Funcionalidades adicionadas
Desta forma, a iluminacao da mesa de trabalho deve ser uniforme em toda a sua area, sendo
necessario a grande maioria das vezes ajustar os parametros da Webcam, tais como, o foco, o
brilho, contraste, intensidade de cor, de forma a maximar o reconhecimento dos marcadores.
3.4 Funcionalidades adicionadas
Ao software reacTIVision foram adicionadas funcionalidades extra, de modo a poderem
ser atingidos os objetivos inicialmente propostos. Assim, e porque esta aplicacao apenas se
limita a monitorizacao do ambiente de trabalho, retratando a evolucao das trajetorias de cada
robo presente sob a forma de mensagens na sua aplicacao, torna-se necessario dispor dessa
informacao e retransmiti-la para os robos.
Neste sentido, procedeu-se a implementacao de funcionalidades extra modo a tornar possıvel
transmitir essa informacao, disponıvel pelo reacTIVision, para cada um dos robos. Estas fun-
cionalidades tornam possıvel em primeiro lugar a transmissao de dados via a porta serie do
PC, para cada robo. Numa fase inicial, e de modo a poder ser possıvel a escolha de qual dos
parametros se quer enviar para os robos, optou-se pela criacao de um ficheiro xml, de nome
configuration.xml, de modo a filtrar o conjunto de informacao a ser enviado para os robos.
Neste ficheiro encontram-se evidenciados todos os parametros disponibilizados pela aplicacao
reacTIVision, bastando colocar a um os parametros pretendidos, para selecionar que parametros
sao transmitidos para o robo. Na Figura 3.17 apresenta-se o correspondente ficheiro configu-
ration.xml.
Porem, e tendo em vista a otimizacao de conteudo de todos os pacotes utilizados na comunica-
cao PC/robo, foi restringida esta funcionalidade na parte final desta dissertacao, uma vez que
seria necessario o envio de um ou mais pacotes para cada robo (consoante fossem incluıdas
variaveis que relacionam dois robos, como a sua distancia ou angulo inter-robo), traduzindo-se
uma inevitavel perda da qualidade de comunicacao entre o PC central e cada um dos robos.
Para alem da escolha dos parametros a enviar, e tambem definido o tempo de atualizacao
individual para cada robo, ou o tempo de atualizacao geral para todos os robos. Este tempo
de atualizacao estipula o tempo mınimo que deve decorrer, para transmitir novos dados para o
robo. De outra forma, isto e, se nao fosse estipulado um tempo de detecao mınimo, ou se este
fosse zero, sempre que a aplicacao atualizasse a informacao deste marcador, seriam enviados
para o robo os dados selecionados de forma continua, o que com tres robos sobre a mesa de
testes, resultaria num envio contınuo para a porta serie dos dados a enviar. Este fato resulta em
termos praticos no colapso do envio dos dados para cada robo, por parte da Torre Base, sendo
necessario, desligar e voltar a ligar a mesma, de forma recorrente.
Assim, ao definir um tempo de atualizacao para cada um dos robos, a aplicacao reacTIVision
ao detetar um primeiro robo envia para este os dados selecionados, sendo que ao detetar este
mesmo robo durante o tempo de atualizacao inserido pelo utilizador, a aplicacao nao envia para
Plataforma de testes para sistema multi-robo(MRS) -33-
3.4. Funcionalidades adicionadas
o robo qualquer dado, so depois de exceder este tempo, sera efetuado a transmissao dos dados
para o robo. No caso do tempo de atualizacao geral, e transmitido a informacao de forma cıclica,
isto e, durante o tempo de espera introduzido pelo utilizador, sao guardados na correspondente
estrutura os dados mais recentes relativos a cada um dos robos, sendo envida esta informacao
de cada vez que e esgotado esse tempo. De referir que, a insercao do tempo de atualizacao no
ficheiro .xml ser em milissegundos.
Desta forma, assegura-se uma forma simples e de facil interpretacao para o utilizador para
a configuracao da aplicacao.
De notar que, o protocolo utilizado pelo Khepera I limita a mensagem a enviar a 16 bytes
(de dados), sendo contudo suficiente para o envio de todos os parametros extraıdos pelo reac-
TIVision, mas insuficiente para, numa mesma mensagem enviar outras variaveis calculadas,
como por exemplo, a distancia que separa dois robos no ambiente de trabalho, ou o angulo
que os separam. Para enviar, estas variaveis seria necessario, de cada vez enviar mais do que
uma mensagem para o robo, consumindo a transmissao mais tempo, e tornando o processo de
aquisicao de dados e de sincronizacao mais difıcil.
Figura 3.17: Ficheiro configuration.xml
Logo, e de modo a permitir a transmissao do PC central para cada Khepera I, os parametros
selecionados encaixam numa mensagem de dezasseis bytes da forma evidenciada na Tabela
3.4:
Tabela 3.4: Sintaxe do pacote enviado para os robos com tempo de espera individual
M0 M1 x y a X Y A m r s0 s1 ms0 ms1 SIG
Ou, no caso da transmissao de dados ser efetuada de forma cıclica, o pacote e retratado pela
sintaxe descrita na Tabela 3.5:
Devido ao tamanho maximo da mensagem a enviar suportada pela sintaxe Khepera e ne-
cessario proceder a uma normalizacao dos valores a enviar, de modo a ser possıvel transmitir
-34- Plataforma de testes para sistema multi-robo(MRS)
3.5. Arquitetura de controlo utilizada
Tabela 3.5: Sintaxe do pacote enviado para os robos com tempo de espera coletivo
M0 M1 x1 y1 a1 x2 y2 a2 x3 y3 a3 s0 s1 ms0 SIG
cada valor num byte, resultando numa inevitavel perda de resolucao nos valores transmitidos.
Assim sendo todos restantes parametros transmitidos (a excecao do tempo) sao aproximados ao
seu valor inteiro mais proximo.
3.5 Arquitetura de controlo utilizada
De modo a permitir um melhor entendimento da arquitetura de controlo implementada em
cada robo, e apresentado o seu fluxograma correspondente na Figura 3.18. Nesta encontra-se
destacado o mecanismo de sincronizacao introduzido para a atualizacao do robo. De seguida
sao explicados, na medida do essencial, cada um dos blocos constituintes do fluxograma, da
arquitetura de controlo utilizada. Assim sendo:
1. Initial Computing
Este bloco define como procedimento inicial, a leitura dos sensores do robo. Para
tal, a BIOS do Khepera possui o comando tim find association(reference) que permite
a associacao de um apontador comum de trinta e dois bits, a uma string de dezasseis
carateres. Atraves desta associacao, e efetuada a leitura de cada elemento de uma tabela,
onde sao guardados os valores obtidos pelos sensores do robo.
2. Sincronizacao Master/Slave
A sincronizacao entre o Master e cada Slave do sistema, ocorre de forma a sincronizar
o inicio do movimento entre todos os robos. Desta forma, e em primeiro lugar, o Master
espera pela rececao do seu pacote de dados, onde se encontra definida, para alem de
outros parametros, a sua posicao inicial – syncMaster(). Uma vez recebido este pacote
de dados, e posteriormente transmitido o objetivo (posicao final) do Master, para cada
uma das Slaves. Assim, e do ponto de vista de cada Slave, consiste apenas numa espera
pela rececao desta informacao por parte do Master, antes de iniciar o seu movimento –
syncSlave().
3. Calculo do intervalo de tempo dt
Uma vez que a arquitetura de controlo utilizada recorre, como processo de estimacao
da posicao, ao metodo Dead Reckoning, e necessario estimar o intervalo de tempo que
decorre em cada ciclo (dt). Este intervalo de tempo dt corresponde a quantidade de tempo
que o robo progride, utilizando os mesmos valores das variaveis comportamentais. Neste
Plataforma de testes para sistema multi-robo(MRS) -35-
3.5. Arquitetura de controlo utilizada
Figura 3.18: Fluxograma da arquitetura de controlo com mecanismo de sincronizacao implementada
sentido, este intervalo de tempo e medido como a soma de duas componentes: a primeira,
e constituıda pelo tempo que decorre entre o fim do ultimo ciclo, ate ao principio do
presente ciclo; e a segunda, e composta pelo tempo que decorre entre o inicio e o fim, do
ultimo ciclo. Desta forma, e obtido o valor do intervalo de tempo dt em milissegundos.
-36- Plataforma de testes para sistema multi-robo(MRS)
3.5. Arquitetura de controlo utilizada
4. Dead Reckoning
O metodo utilizado para a estimativa da corrente posicao e orientacao do robo, consiste
na utilizacao da equacao de Euller progressiva, isto pois utiliza uma amostra para a frente.
Esta equacao, ja descrita no capitulo anterior, e implementada da seguinte forma:
cfg->Xrobot = cfg->Xrobot + (integer) rint(ds*cos(cfg->Phi));
cfg->Yrobot = cfg->Yrobot + (integer) rint(ds*sin(cfg->Phi));
Com, ds = dt x vRobo, representando vRobo o valor da velocidade atual do robo.
No entanto, existem alguns aspetos a considerar, nomeadamente as unidades internas
do robo, que se encontram definidas como PAM e TIC, que correspondem a unidade de
espaco interna e a unidade de tempo interna do robo Khepera I, respetivamente. Assim,
sao adotadas, como unidade de espaco oficial a PAM, em detrimento do milımetro, sendo
estabelecida a seguinte relacao: 1 PAM = 0.08 mm; e em termos de tempo e definida
a unidade TIC, descrita como 1/100 s = 10 ms. Posteriormente, a velocidade linear e
definida como PAM/TIC, e a velocidade angular e definida como rad/TIC. Desta forma
e necessario converter a variavel temporal dt, de milissegundos para TIC, assim como,
as variaveis posicionais Xrobot e Yrobot, de milımetros para PAM, de forma a poder
executar de forma correta a equacao de Euller.
5. Atualizar posicao e orientacao do robo
Contudo, antes de ser executada a equacao de Euller, e chamada a funcao getFrom-
Master1(cfg) que lida com a rececao do pacote de dados proveniente do PC. Se esta
rececao ocorrer com sucesso por parte do robo, os seus valores intrınsecos relativos a sua
posicao e orientacao, sao atualizados pelos dados enviados pelo PC central, ocorrendo o
bypass do metodo Dead Reckoning utilizado para estimar a posicao e orientacao do robo.
Assim sendo, torna-se importante descrever o pacote de dados utilizado no protocolo
implementado entre o PC central e cada um dos robos, presentes no ambiente de trabalho.
• Tempo de espera individual
Em primeiro lugar, e utilizando um tempo de espera individual para cada robo,
tem-se, tal como ja foi dito, um pacote de dados que possui como limite maximo,
um buffer de dezasseis bytes de dados, decorrente da sintaxe utilizada pelos robos
Khepera I [23]. Desta forma, e limitado o espaco de cada variavel, sendo a sua trans-
missao efetuada num byte cada. Tendo isso em conta, o pacote de dados transmitido
do PC central para cada robo, respeita a sintaxe da Tabela 3.6.
Desta feita, os dois primeiros bytes (M1 e M0) sao utilizados como marcadores
do protocolo, que identificam a qual dos robos a mensagem se destina, com maior
Plataforma de testes para sistema multi-robo(MRS) -37-
3.5. Arquitetura de controlo utilizada
Tabela 3.6: Formato do pacote utilizado para a comunicacao PC → Master com espera individual
M1 | M0| x | y | a | X | Y | A | m | r | s0 | s1 | ms0 | ms1 | CR
grau de precisao. Assim, a combinacao AJ, BF e CK, identificam que a mensagem
se destina para o robo1, robo2 e robo3, respetivamente (o nome robo e atribuıdo pela
identificacao selecionada no proprio Khepera e pelo seu correspondente marcador).
Tal e demonstrado na Tabela 3.7, a seguir apresentada.
Tabela 3.7: Combinacao usada para a identificacao do robo
M1M0 IdentificacaoAJ robo1
BF robo2
CK robo3
Todas as outras combinacoes entre M1 e M0 sao, portanto, descartadas, isto e,
consideradas lixo. A etiqueta de tempo presente em cada pacote de dados, associa a
este conjunto de dados o tempo de detecao ocorrido, sendo, neste caso, transmitidos
os segundos (s0 s1) e os milissegundos (ms0 ms1) em cada pacote de dados. O CR
(0x0D ou 13) presente na final de cada vetor transmitido e obrigatorio, de modo a
transmissao ocorrer com sucesso, fazendo parte da sintaxe de transmissao de dados
do Khepera I.
Desta forma de cada vez que a funcao getFromMaster1(cfg) e executada, e
colocado no buffer o pacote de dados recebido, sendo em seguida verificada a
identificacao da mensagem e assimilado por parte do robo os valores recebidos.
Assim sao substituıdos os seus valores calculados atraves da equacao de Euler para
a frente, pelos valores recebidos pelo robo na sua estrutura, se a identificacao da
mensagem coincidir com a identificacao do robo; caso contrario, se a identificacao
da mensagem nao corresponder a identificacao do robo, ou se a rececao do pacote de
dados nao ocorrer, a mensagem sera descartada (na topologia centralizada o Master
transmite o respetivo pacote a Slave).
De notar que ao assimilar os dados da mensagem, nomeadamente a posicao do
robo, e necessario transformar os valores para PAM a unidade interna do robo.
• Tempo de espera coletivo
Ao utilizar o mecanismo de transmissao cıclica de dados com um tempo de
espera coletivo, de forma a otimizar a transmissao de dados PC→robos, isto e, mi-
nimizando o impacto dos pacotes perdidos (enviados pelo PC central mas nao rece-
bidos por parte dos robos) na constituicao da formacao, optou-se por incorporar em
-38- Plataforma de testes para sistema multi-robo(MRS)
3.5. Arquitetura de controlo utilizada
apenas um pacote de dados toda a informacao posicional num dado instante, dis-
ponıvel pelo reacTIVision, dos tres robos presentes no ambiente de trabalho. Para
alem disto, implementou-se no PC central uma rotina, baseada num Timer Multime-
dia do Windows, que procede ao envio deste pacote de dados de forma cıclica (ver
Figura 3.3). Sendo o valor deste intervalo de tempo definido pelo utilizador, atraves
da sua especificacao do seu valor (em ms) no ficheiro configuration.xml. Assim,
durante o intervalo estipulado o reacTIVision procede a monitorizacao dos robos no
ambiente de trabalho em constante atualizacao, sendo guardada a informacao mais
recente relativa a cada robo numa estrutura, permitindo desta forma, no momento
em que o Timer disparar, se encontrem disponıveis para cada um dos robos a sua
atualizacao mais recente.
Uma vez recebido o pacote por parte do Master, este assimila os novos valores
recebidos correspondentes a si e guardando os dados relativos aos robos seguidores.
Posteriormente, de cada vez que o Master enviar os pacotes para as Slaves, sao
enviados tambem os dados posicionais mais recentes relativas a Slave. Assim sendo,
o pacote de dados transmitido pelo Master para cada uma das Slaves, tambem foi
reformatado, enviando agora, nao so dados relativos ao Master, mas tambem dados
relativos a propria Slave. A seguir, na Tabela 3.8 apresentam-se a nova morfologia
dos novos pacotes usados na transmissao de dados.
Tabela 3.8: Formato do pacote utilizado para a comunicacao PC → Master com espera coletivo
M0 | M1 | x1 | y1 | a1 | x2 | y2 | a2 | x3 | y3 | a3 | s0 | s1 | ms0 | CR
6. Calculo do angulo de navegacao do robo (φi)
Para o calculo do angulo de navegacao do robo, e efetuada a simples soma de tres
contribuicoes: contribuicao da direcao alvo (ftar(φi)), contribuicao da direcao dos obstacu
los detetados (fobs(φi)) e a adicao de ruıdo gaussiano (Gaussian Noise) (fstoch).
Assim, e erigido um atrator na direcao de φtar, com vista a atrair o sistema, nomeada-
mente o angulo de navegacao, para essa direcao; em contrapartida, e erigido um repulsor
na direcao de φobs, de modo ao sistema afastar-se deste angulo de navegacao. A somar
a isto, e acrescentada uma pequena perturbacao, sob a forma de uma matriz [40][5], isto
e, com duzentas amostras de ruıdo gaussiano previamente gerado, de modo a impedir
com que o sistema se situe efetivamente nos pontos instaveis. Desta forma, impede-se
o sistema de se manter no ponto instavel recorrendo a introducao de ruıdo, pois o valor
da variavel de estado, neste caso, o angulo de navegacao do robo (φi) encontrar-se-a nao
no ponto instavel, mas nas suas proximidades. No caso contrario, ou seja, no caso dos
Plataforma de testes para sistema multi-robo(MRS) -39-
3.5. Arquitetura de controlo utilizada
pontos estaveis, nao existe diferenca significativa pois a sua tendencia sera a mesma de
convergir para o ponto estavel (para mais informacoes ver Anexo B).
7. Calcular a velocidade pretendida (vdese jada)
A velocidade do robo e calculada atraves da equacao diferencial que governa o sis-
tema dinamico para a velocidade, usando o metodo de Euller. Esta implementacao e
efetuada da seguinte forma:
v_cm = old_v_cm - \textit{dt} * INVSEC_2_INVTIC( cfg->lambdav ) *
( old_v_cm - v_des );
Posteriormente ao obter os valores de velocidade resultantes em cada roda do robo, e
necessario aproximar os valores obtidos ao numero inteiro mais proximo, pois apenas e
possıvel aplicar aos motores valores inteiros compreendidos, entre +127 e -128 PAM/TIC,
ou seja, 0.08 mm/10ms.
8. Aplicar valores aos motores
Aplicar os valores inteiros da velocidade obtida de cada uma das roda do robo ao
motor associado, atraves da funcao mot new speed 2m(speed1, speed0), correspondendo
a valor da velocidade speed1 ao motor1 (motor do lado direito), e o valor da velocidade
speed0 ao motor0 (motor do lado esquerdo).
9. Comunicacao Master/Slave
• Tempo de espera individual
Corresponde a comunicacao por parte do Master, da sua posicao e orientacao a
cada uma das Slaves presentes no ambiente de trabalho. Para alem destas, e trans-
mitido a velocidade do Master e uma indicacao por parte deste, se a posicao final foi
atingida. Este pacote de dados enviado pelo Master para cada Slave e apresentado a
seguir, na Tabela 3.9, bem como a descricao de todos os elementos.
Tabela 3.9: Formato do pacote utilizado para a comunicacao Master → Slave com espera individual
ID | MSG SIZE | x0 | x1 | x2 | x3 | y0 | y1 | y2 | y3 | vM | φ0 | φ1 | MT | CR
De referir que se trata de uma transmissao unidirecional, onde apenas o Master
transmite informacao e encontrando-se as Slaves a escuta do Master, nao transmi-
tindo qualquer feedback ao mesmo.
-40- Plataforma de testes para sistema multi-robo(MRS)
3.5. Arquitetura de controlo utilizada
Como e visıvel este pacote apenas utiliza um buffer com quinze elementos, nao
usufruindo do tamanho do buffer maximo permitido pelo protocolo Khepera. As-
sim, e indicado no primeiro elemento do buffer o destinatario da mensagem do Mas-
ter, podendo este valor ser um , dois ou tres, consoante o robo destinatario ser o robo
com a identificacao um, dois ou tres. Contudo, e porque o objetivo e atualizar todas
as Slaves com informacao atual do Master, e colocado -1, como valor da ID, sendo
a mensagem difundida desta forma para todos os robos presentes no ambiente de
trabalho. Deste modo, todas as Slaves sao atualizadas com a posicao do Master a
cada transmissao. Em segundo lugar, e colocado o tamanho da mensagem a enviar.
Estes dois primeiros campos sao obrigatorios de modo que a transmissao aconteca
com sucesso.
Em termos de parametros propriamente ditos, o Master transmite para cada
Slave a sua posicao no ambiente de trabalho, no eixo do x e no eixo do y, e a sua
velocidade. Na Tabela 3.10 sao descritos todos os elementos enviados.
Tabela 3.10: Descricao dos parametros usados na transmissao de dados Master → Slave com tempo deespera individual
Parametros DefinicaoID Identificacao do roboMSG SIZE Tamanho da mensagem a enviarXrobot[0..3] Posicao do Master em relacao ao eixo dos xxY robot[0..3] Posicao do Master em relacao ao eixo dos yyvMaster Velocidade do Masterφ[0..1] Angulo de navegacao do MasterMT MasterThereCR Assinatura do fim de mensagem
Como e visıvel, o valor das coordenadas em x e em y do Master sao dividas em
quatro bytes, devido ao fato destas variavel Xrobot e Yrobot serem do tipo unsigned
int, isto e, de tamanho quatro bytes, e como o buffer e do tipo uint8, isto e, de
apenas oito bytes e necessario, em ordem a nao perder resolucao no valor da variavel
a enviar, colocar um byte de cada vez no buffer, atraves de operacoes logicas de
deslocamento de bits. A seguir indica-se a sua implementacao pratica.
buffer[2] = ( cfg->Xrobot >> 0 ) & 0xFF; // 1o byte de Xrobot
buffer[3] = ( cfg->Xrobot >> 8 ) & 0xFF; // 2o byte de Xrobot
buffer[4] = ( cfg->Xrobot >> 16 ) & 0xFF; // 3o byte de Xrobot
buffer[5] = ( cfg->Xrobot >> 24 ) & 0xFF; // 4o byte de Xrobot
A somar as coordenadas em x e y do Master, e tambem transmitida a sua velo-
cidade. O valor da sua velocidade e transmitido em apenas um byte, sendo dividido
Plataforma de testes para sistema multi-robo(MRS) -41-
3.5. Arquitetura de controlo utilizada
o seu valor por quatro, sendo posteriormente necessario, a quando da rececao do
buffer por parte da Slave, multiplicar este valor por quatro, de modo a obter o valor
da velocidade real do Master. O angulo de navegacao do Master e transmitido uti-
lizando dois bytes, sendo o seu valor transmitido em degraus e em base 180. Esta
conversao e demonstrada a seguir.
buffer[11] = ( phiMaster % 180 );
buffer[12] = ( phiMaster / 180 );
O valor da variavel MT (MasterThere) possui o proposito simples de indicar a
Slave se o Master ja chegou a sua posicao final (objetivo) ou nao, consoante o seu
valor for um ou zero, respetivamente.
A variavel CR, tal como, ja foi explanado atras, faz parte do protocolo Khepera
sendo necessaria a sua incorporacao em todos os buffers, de modo a ser possıvel a
transmissao de dados entre estes robos. No caso, a variavel toma o valor treze na
posicao final de cada buffer.
• Tempo de espera coletivo
Ao utilizar o metodo de transmissao cıclica, este pacote sofre alteracoes, incor-
porando informacao nao so do proprio Master mas tambem informacao relativas a
Slave. A seguir na Tabela 3.11 e apresentado o formato do pacote utilizado neste
metodo.
Tabela 3.11: Formato do pacote utilizado para a comunicacao Master → Slave com espera coletiva
ID | MSG SIZE | x0 | x1 | x2 | x3 | y0 | y1 | y2 | y3 | vMaster | φMaster | MT | xS2 | yS2 | aS2 | CR
A seguir apresenta-se na Tabela 3.12 o significado de cada uma destes parametros.
-42- Plataforma de testes para sistema multi-robo(MRS)
3.5. Arquitetura de controlo utilizada
Tabela 3.12: Descricao dos parametros usados na transmissao de dados Master → Slave com tempo deespera coletivo
Parametros Definicao
ID Identificacao do roboMSG SIZE Tamanho da mensagem a enviarXrobot[0..3] Posicao do Master em relacao ao eixo dos xxY robot[0..3] Posicao do Master em relacao ao eixo dos yyvMaster Velocidade do MasterφMaster Angulo de navegacao do MasterMT MasterTherexS Posicao da Slave em relacao ao eixo dos xxyS Posicao da Slave em relacao ao eixo dos yyaS Angulo de navegacao da SlaveCR Assinatura do fim de mensagem
Plataforma de testes para sistema multi-robo(MRS) -43-
Capıtulo 4
Resultados
Os resultados apresentados a seguir, sao obtidos utilizando dois PC’s. O primeiro e res-
ponsavel pela captura de imagem, e pela identificacao das marcas fiduciais, sendo tambem
res-ponsavel pelo empacotamento de dados e pela sua retransmissao. O segundo PC e utili-
zado, numa primeira fase para descarregar o programa desenvolvido para os robos, atraves da
sua porta serie, e numa segunda fase, responsavel pela visualizacao e monitorizacao dos dados
recebidos entretanto, atraves do TeraTerm (programa terminal dos robos Khepera disponıvel de
forma gratuita).
A seguir sao apresentados os correspondentes testes efetuados, nomeadamente, com
apenas um robo, dois robos e por fim, com tres robos na area de trabalho. Em anexo encontram-
se disponıveis os conceitos basicos que regem o funcionamento da arquitetura de controlo uti-
lizada para testar a solucao desenvolvida.
Relativamente ao calculo da posicao do robo ao longo do tempo, a arquitetura de controlo
utiliza o metodo dead reckoning, onde, fazendo apenas uso da posicao inicial do robo, orientacao
e da sua velocidade, e possıvel estimar a sua posicao final [24]. Neste caso, a arquitetura im-
plementada utiliza como tipo de dead reckoning, a odometria, ao inves da navegacao inercial,
ja explanada anteriormente.
Este metodo possui a vantagem de todos os seus calculos poderem ser efetuados no Khepera,
no caso particular, e utilizado o Metodo de Euller progressivo (para a frente), para a estimativa
da sua posicao:
xnew(t +Δt) = xold(t)+dt∗ vcos(φ) (4.1)
ynew(t +Δt) = yold(t)+dt∗ vsin(φ) (4.2)
Onde, v e a velocidade do robo, xold e yold as coordenadas atuais do robo, e dt o intervalo
de tempo decorrido. Assim, e estipulada a posicao final do robo, a partir da sua posicao atual,
da sua velocidade e orientacao, em cada intervalo de tempo dt.
Porem, este metodo acarreta erros de posicao associados, que se vao acumular ao longo do
45
tempo em cada intervalo de tempo dt, sendo estes erros proporcionais a distancia percorrida
pela robo.
Neste sentido, e baseados nestes calculos, ao se estabelecerem as formacoes vao existir erros
de posicionamento entre dois robos, deteriorando progressivamente a qualidade da formacao
estabelecida ao longo do tempo. Este fato impede que os robos percorram uma grande distancia,
pois estes erros tendem a acumular-se, acabando por desvirtuar o estabelecimento da formacao
pretendida.
Assim sendo, pretende-se substituir este metodo de estimacao da posicao de cada robo
no ambiente de trabalho, atraves da rececao por parte do robo, de um pacote de dados, com
a sua posicao (assim como outros parametros), proveniente da aplicacao reacTIVision. Esta
atualizacao e efetuada de forma cıclica, sendo transmitido um pacote de dados por parte do PC
central, de acordo com o intervalo de tempo de espera inserido no ficheiro configuration.xml.
Por parte do robo, e executada a funcao getFromMaster1(cfg), que trata da rececao deste pacote
de dados, verificando a identidade e a conformidade do pacote. Se a rececao for efetuada com
sucesso, sao atualizados os dados atuais pelos dados recebidos.
Contudo, verificou-se na pratica que a atualizacao dos dados, por parte do robo, em todos
os seus ciclos, e inviavel. Isto porque, a aplicacao reacTIVision procede a monitorizacao de
tres robos na area de trabalho, onde o tempo de detecao e atualizacao dos dados de cada robo,
associado ao tempo consumido pela transmissao destes para cada robo, inviabiliza a sua rececao
em todos os ciclos do programa principal, por parte de cada um dos robos.
De referir que, o programa pode ser descrito basicamente como um ciclo onde: em primeiro
lugar, sao lido os valores dos oito sensores do Khepera; em segundo lugar, sao calculados os
valores das variaveis comportamentais; e por ultimo, sao aplicados os respetivos valores aos
motores; de seguida, retorna-se ao inicio. Este ciclo apenas e quebrado, em duas ocasioes: o
robo conclui com sucesso a respetiva tarefa; e em segundo, o numero de ciclos maximo foi
atingido.
Deste modo, optou-se por uma abordagem mista, onde sao utilizados tanto os valores cal-
culados atraves da odometria, como os valores recebidos atraves do PC central. Assim, o me-
canismo para a atualizacao de dados em cada robo, funciona da seguinte maneira: o PC central
envia os pacotes de dados, de acordo com os dados e o intervalo de tempo, selecionados no
ficheiro configuration.xml, de forma cıclica para cada robo; e do lado do robo, uma vez em
cada ciclo, nomeadamente, antes do calculo da sua posicao atraves da equacao de Euller, e exe-
cutada a funcao getFromMaster1(cfg) que trata da rececao deste pacote de dados, verificando
se a comunicacao for efetuada com sucesso, a conformidade e a identidade do mesmo. Se, a
comunicacao for efetuada com secesso e se o respetivo robo for o destinatario da mensagem, os
dados do robo sao atualizados pelos dados recebidos; caso contrario, o ciclo prossegue normal-
mente, sendo calculada a sua posicao recorrendo a equacao de Euller. Segundo esta abordagem,
o programa nao fica ”pendurado”, a espera da rececao do seu pacote de dados.
-46- Plataforma de testes para sistema multi-robo(MRS)
4.1. Descricao dos resultados
4.1 Descricao dos resultados
Neste capitulo, sao apresentados os resultados finais das experiencias realizadas, nomeada-
mente atraves da exibicao de capturas de ecra, que ajudem a demonstrar os resultados obtidos.
Assim, cada experiencia encontra-se documentada com todos os parametros mais relevantes, de
modo a analisar e a avaliar o desempenho do sistema enquanto solucao proposta.
Deste modo, todas as experiencias sao realizadas utilizando marcadores amoeba do tipo
legacy (5,5 cm), sobre os mini-robos Khepera I, utilizando, no decorrer destas, uma resolucao
unica de 1280x720 a 5fps, de modo a cobrir toda a mesa de trabalho. O tempo de atualizacao de
cada robo e, regra geral, 500 ms em cada experiencia, salvo indicacao em contrario e o tempo
de cada um dos testes e de aproximadamente 1 minuto.
Em termos de comandos enviados para o robo, numa primeira fase, sao constituıdos pela
posicao inicial de cada robo, que e descartada pois o robo so inicia o movimento quando ocorre
a rececao, por parte do PC central, da sua posicao; e da posicao final do lıder (objetivo), isto e,
o local para o qual este deve convergir; e por ultimo, o angulo e a distancia de cada slave para
com o lıder, definindo desta forma a formacao geometrica pretendida.
4.1.1 Teste com um robo Khepera
Em primeiro lugar, e apresentado um teste recorrendo a apenas um robo, como exemplo.
⇒ Posicao Inicial: (X,Y) → (375, 450) mm
⇒ Posicao Final: (X,Y) → (1125, 450) mm
Posição Final
Posição Inicial
Figura 4.1: Posicao inicial e final do robo
A Figura 4.2 evidencia a trajetoria tomada pelo robo para atingir a posicao final, contor-
nando os obstaculos presentes no ambiente de trabalho.
Plataforma de testes para sistema multi-robo(MRS) -47-
4.1. Descricao dos resultados
050010001500
0
100
200
300
400
500
600
700
800
900
TRAJETÓRIA DO ROBÔ
Y[m
m]
X[mm]
goalR
1
init
Figura 4.2: Trajetoria adquirida pelo robo
Este teste consegue um desempenho otimizado, pois a taxa de atualizacao da posicao do
robo e obtida com sucesso na esmagadora maioria das vezes, fornecendo a posicao a este de
uma forma mais celere e mais precisa.
-48- Plataforma de testes para sistema multi-robo(MRS)
4.1. Descricao dos resultados
4.1.2 Testes com dois robos Khepera
A seguir sao apresentadas capturas de ecra correspondentes a cada uma das formacoes pre-
tendidas, nomeadamente, coluna, linha e oblıqua. Em primeiro lugar, as formacoes sao efetua-
das sem o auxılio de obstaculos pela frente, sendo, em segundo lugar, introduzidos obstaculos
na area de trabalho.
1. Sem obstaculos
• Formacao em coluna
⇒ Posicao Inicial1: (X,Y) → (510, 585) mm;
⇒ Posicao Inicial2: (X,Y) → (510, 730) mm;
⇒ Posicao Final: (X,Y) → (1125, 450) mm;
Na Figura 4.3 sao apresentados os resultados da formacao em coluna sem obstaculos:
POSIÇÃO FINAL
(a)
POSIÇÃO FINAL
(b)
POSIÇÃO FINAL
(c)
POSIÇÃO FINAL
(d)
POSIÇÃO FINAL
(e)
POSIÇÃO FINAL
(f)
Figura 4.3: Capturas de ecra da formacao em coluna sem obstaculos com dois robos
Plataforma de testes para sistema multi-robo(MRS) -49-
4.1. Descricao dos resultados
• Formacao oblıqua
⇒ Posicao Inicial: (X,Y) → (510, 585) mm;
⇒ Posicao Inicial: (X,Y) → (510, 730) mm;
⇒ Posicao Final: (X,Y) → (1125, 450) mm;
A seguir na Figura 4.4 sao apresentados os resultados da formacao oblıqua:
POSIÇÃO FINAL
(a)
POSIÇÃO FINAL
(b)
POSIÇÃO FINAL
(c)
POSIÇÃO FINAL
(d)
POSIÇÃO FINAL
(e)
POSIÇÃO FINAL
(f)
Figura 4.4: Capturas de ecra da formacao oblıqua sem obstaculos com dois robos
-50- Plataforma de testes para sistema multi-robo(MRS)
4.1. Descricao dos resultados
2. Com obstaculos
• Formacao em coluna
⇒ Posicao Inicial: (X,Y) → (510, 585) mm;
⇒ Posicao Inicial: (X,Y) → (510, 730) mm;
⇒ Posicao Final: (X,Y) → (1125, 450) mm;
A seguir na Figura 4.5 sao apresentados os resultados da formacao em coluna:
POSIÇÃO FINAL
(a)
POSIÇÃO FINAL
(b)
POSIÇÃO FINAL
(c)
POSIÇÃO FINAL
(d)
POSIÇÃO FINAL
(e)
POSIÇÃO FINAL
(f)
Figura 4.5: Capturas de ecra da formacao coluna com obstaculos com dois robos
Plataforma de testes para sistema multi-robo(MRS) -51-
4.1. Descricao dos resultados
• Formacao oblıqua
⇒ Posicao Inicial: (X,Y) → (510, 585) mm;
⇒ Posicao Inicial: (X,Y) → (510, 730) mm;
⇒ Posicao Final: (X,Y) → (1125, 450) mm;
A seguir na Figura 4.6 sao apresentados os resultados da formacao oblıqua:
POSIÇÃO FINAL
(a)
POSIÇÃO FINAL
(b)
POSIÇÃO FINAL
(c)
POSIÇÃO FINAL
(d)
POSIÇÃO FINAL
(e)
POSIÇÃO FINAL
(f)
Figura 4.6: Capturas de ecra da formacao oblıqua com obstaculos com dois robos
Os ensaios envolvendo dois robos Kheperas sem obstaculos revelaram uma convergencia
para o objetivo de ambos os robos na formacao selecionada. Verificou-se ainda um decrescimo
da taxa de pacotes enviados/pacotes recebidos face a utilizacao de apenas um robo Khepera,
sendo que o Master e atualizado mais frequentemente do que a Slave. Com a introducao de
obstaculos os robos conseguem mudar de direcao de forma a evitar o obstaculo, deformando se
necessario a formacao pretendida e retornando posteriormente a formacao em questao.
-52- Plataforma de testes para sistema multi-robo(MRS)
4.1. Descricao dos resultados
4.1.3 Testes com tres robos Khepera
A seguir sao apresentadas as capturas de ecra correspondentes a cada uma das formacoes
pretendidas, nomeadamente, coluna, linha e triangulo. Em primeiro lugar as formacoes sao
efetuadas sem o auxilio de obstaculos pela frente e a segundo lugar sao introduzidos obstaculos
na area de trabalho.
1. Sem obstaculos
• Formacao em coluna
⇒ Posicao Inicial: (X,Y) → (510, 585) mm;
⇒ Posicao Inicial: (X,Y) → (510, 730) mm;
⇒ Posicao Final: (X,Y) → (1125, 450) mm;
A seguir na Figura 4.7 sao apresentados os resultados da formacao em coluna:
POSIÇÃO FINAL
(a)
POSIÇÃO FINAL
(b)
POSIÇÃO FINAL
(c)
POSIÇÃO FINAL
(d)
POSIÇÃO FINAL
(e)
POSIÇÃO FINAL
(f)
Figura 4.7: Capturas de ecra da formacao em coluna sem obstaculos com tres robos
Plataforma de testes para sistema multi-robo(MRS) -53-
4.2. Analise e discussao dos resultados
• Formacao oblıqua
⇒ Posicao Inicial: (X,Y) → (510, 585) mm;
⇒ Posicao Inicial: (X,Y) → (510, 730) mm;
⇒ Posicao Final: (X,Y) → (1125, 450) mm;
A seguir na Figura 4.8 sao apresentados os resultados da formacao em triangulo:
POSIÇÃO FINAL
(a)
POSIÇÃO FINAL
(b)
POSIÇÃO FINAL
(c)
POSIÇÃO FINAL
(d)
POSIÇÃO FINAL
(e)
POSIÇÃO FINAL
(f)
Figura 4.8: Capturas de ecra da formacao oblıqua sem obstaculos com tres robos
Utilizando tres robos Khepera sem obstaculos verificou-se o estabelecimento da formacao
pretendida, sendo que a taxa de pacotes enviados/pacotes recebidos decresce face a utilizacao de
dois robos Khepera, sendo ainda menor do que a quando da utilizacao de apenas um robo Khe-
pera. Observou-se tambem que o Master obtem predominancia em relacao as Slaves, sendo
atualizado de forma mais assıdua que ambas as Slaves. A sua implementacao recorrendo a
obstaculos nao foi possıvel devido a inoperancia de um dos robos.
4.2 Analise e discussao dos resultados
A seguir sao analisados os resultados da implementacao de dois tipos de formacao distintas,
no caso, uma formacao em coluna e uma formacao em triangulo, em cenarios sem obstaculos,
-54- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
e cuja experiencia e documentada na Figura 4.7 e na Figura 4.8, respetivamente.
Assim, e de forma a analisar de forma qualitativa os resultados obtidos, em termos das
formacoes estabelecidas, sao utilizadas metricas, enunciadas por Fredslund e Mataric [17], e ja
referenciadas no capıtulo Estado da Arte. De forma simples, basicamente pretende-se que cada
robo se posicione a uma distancia predefinida em relacao ao robo lıder, bem como, um angulo
desejado relativamente a este. Neste sentido, e modo sintetico, sao definidos tres criterios para
a avaliacao do sistema multi-robo, sao eles:
(1) Dispersao Uniforme (Uniform Dispersion)
(2) Forma (Shape)
(3) Orientacao (Orientation)
A seguir na Figura 4.9 e indicada a nomenclatura utilizada para a implementacao das
metricas seguidas.
Figura 4.9: Apresentacao das metricas utilizadas
No fundo, e de uma forma simples, o primeiro criterio dita que a diferenca entre a distancia
efetiva entre um par de robos e a distancia desejada para cada par de robos, deve ser sempre
Plataforma de testes para sistema multi-robo(MRS) -55-
4.2. Analise e discussao dos resultados
menor que um valor εd1 predefinido, de forma a se poder afirmar que os robos se encontram em
formacao; o segundo criterio indica que o angulo correspondente entre as posicoes de cada robo,
em ordem a obter a formacao pretendida, nao deve ser superior a εa; desta forma as posicoes de
cada robo situam-se dentro de um limite de forma a constituir a formacao pretendida; o terceiro
criterio define que a diferenca entre o angulo de orientacao do robo real (h) e o desejado seja,
por sua vez, inferior a εa.
Logo, e modo a ser possıvel utilizar as definicoes apresentadas para a analise da estabilidade
das formacoes, procedeu-se a definicao do valor de εd1 e εa. Assim, e durante todas as ex-
periencias utilizou-se a definicao 1 com ddese jada=15 cm, εd1=(0.20xddese jada) e εa=(0.08×2π).
Desta forma, define-se εd1 como 20% da distancia inter-robo desejada e εa a poderem obter um
desvio ate 28.8 degraus.
Neste sentido, sao apresentados os graficos das duas experiencias com tres robos realiza-
das, nomeadamente, utilizando uma formacao coluna e uma formacao oblıqua sem obstaculos,
atraves do qual descrevem a evolucao comportamental em termos de distancia entre cada par
de robos, bem como os seus angulos correspondentes. De referir porem que, nos procedi-
mentos experimentais efetuados os robos nao iniciam o seu movimento na sua ordem correta
de formacao, sendo importante distinguir a primeira fase da simulacao como o estabelecer da
formacao e a sua segunda fase como o manter a formacao, de modo a validar a estabilidade da
formacao. Neste contexto nao devem ser aplicadas estas metricas estando os robos na sua fase
de estabelecer a formacao.
-56- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
• Topologia triangular (R1 = 750 ms, R2 = 450ms, R3 = 450ms)
1) Distancia Inter-robo
0 50 100 150 200 250 30050
100
150
200
250
300
Nº Amostras
Dis
tânc
ia[m
m]
DISTÂNCIA INTER−ROBÔ AO LONGO DO TEMPO
ErroPosição12: 19.975 mm
ErroPosição13: 19.609 mm
ErroPosição23: 1.7153 mmErroPosição12Max: 60.93 mm
ErroPosição13Max: 53.42 mm
ErroPosição23Max: 146.16 mm
DistReal12DistReal13DistReal23DistDej23 = 212.12mm
DistDej12 = DistDej13 = 150mm
Figura 4.10: Distancia Inter-robo ao longo do tempo na topologia oblıqua
2) Angulo Inter-robo
Figura 4.11: Angulo Inter-robo ao longo do tempo na topologia oblıqua
Plataforma de testes para sistema multi-robo(MRS) -57-
4.2. Analise e discussao dos resultados
Como e possıvel observar na Figura 4.10, as distancias de cada duo de robos conver-
gem para a distancia pretendida em cada caso. Assim, para a topologia oblıqua, verifica-
se que o valor das distancia12 e distancia13 possuem um erro de formacao de cerca de 2
cm (≈ 2 cm), em relacao a distancia ideal, previamente definida como 150 mm (erro de
13%). Por outro lado, a distancia23, encontram-se bastante proximo da distancia ideal,
possuindo um erro menor que 1 cm (erro de 7%).
No que diz respeito a evolucao do angulo de cada duo de robos, tambem se verifica
uma convergencia para os angulos pretendidos nesta formacao a medida que o tempo
decorre. Assim, como todos os robos se encontram inicialmente em coluna, todos os
angulos entre si se encontram a 0o, evoluindo de modo a se aproximarem cada vez mais
do angulo pretendido em cada caso, como se pode ver na Figura 4.11. Da mesma forma,
observa-se contudo um erro de ≈ 13o entre o Robo1 e o Robo3 (erro de 29%), bem como,
um erro de ≈ 7o para o par de robos23 (erro de 15%). Em relacao ao par de robos12 o
erro constitui aproximadamente 1o de desvio (erro de 2%).
Assim sendo, e tendo em conta as metricas a utilizar, os robos consideram-se em
formacao pois a distancia que separa cada par de robos e menor que o valor de 20% da
distancia desejada, e, por outro lado, em termos de desvio no angulo constituıdo entre
cada par de robos, todos se encontram dentro do limite de 8%preestabelecido.
Durante as experiencias realizadas verificou-se que a taxa de atualizacao do lıder era
maior que qualquer uma das taxas de atualizacao dos seus seguidores, sendo o lıder atua-
lizado com os dados transmitidos pelo PC central de forma mais assıdua que qualquer
outro robo. O fato do lıder monopolizar parcialmente as comunicacoes pode explicar a
diferenca em termos de distancia e angulo, que existe em ambos os pares de robos en-
volvendo o lıder, uma vez que, as taxas de atualizacao de dados dos seguidores sao mais
reduzidas que a do seu lıder.
−∗−
-58- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
• Topologia em coluna (R1 = 750 ms, R2 = 450ms, R3 = 450ms)
1) Distancia Inter-robo
0 50 100 150 200 250 300100
150
200
250
300
350
400
450
500
550
Nº Amostras
Dis
tânc
ia[m
m]
DISTÂNCIA INTER−ROBÔ AO LONGO DO TEMPO
ErroPosição12: 22.216 mm
ErroPosição13: 19.944 mm
ErroPosição23: 7.7625 mm
ErroPosição12Max: 228.23 mm
ErroPosição13Max: 210.92 mm
ErroPosição23Max: 162.05 mm
DistReal12DistReal13DistReal23DistDej12 = DistDej23 = 150mm
DistDej13 = 300mm
Figura 4.12: Distancia Inter-robo ao longo do tempo na topologia em coluna
2) Angulo Inter-robo
0 50 100 150 200 250 300−100
−80
−60
−40
−20
0
20
40
60
80
100
Nº Amostras
Âng
ulo[
deg]
ÂNGULO INTER−ROBÔ AO LONGO DO TEMPO
ErroAngulo12: 28.041º
ErroAngulo13: 14.495º
ErroAngulo23: 0.3196º
AngReal12AngReal13AngReal23AngDej12 = AngDej23 = AngDej13 = 0º
Figura 4.13: Angulo Inter-robo ao longo do tempo na topologia em coluna
Plataforma de testes para sistema multi-robo(MRS) -59-
4.2. Analise e discussao dos resultados
Atraves da Figura 4.12, e possıvel notar a evolucao em termos de distancia entre
cada par de robos na topologia coluna. Inicialmente e devido ao robos se encontrarem em
triangulo, a distancia inter-robos e maior que a definida, aumentando ainda inicialmente
mais a distancia12 e 13 ao estabelecer a formacao, atingindo um pico de desvio, sensivel-
mente a meio do percurso, a quando da constituicao da formacao de aproximadamente 22
cm em ambos os casos. A partir deste pico verifica-se uma convergencia para a distancia
pretendida em cada duo de robos. Ja em formacao observa-se a existencia de um desvio
de aproximadamente 2cm para a distancia12 e 13, bem como, um desvio da distancia23
inferior a 1 cm (erro de 5%).
Relativamente a evolucao do angulos que os robos formam entre si ao longo do tempo,
visıvel na Figura 4.13, observa-se uma convergencia desde o inicio de movimento para
o valor do angulo desejado, que, no caso da formacao em coluna, sao 0o. Desta feita,
ja em formacao o erro entre o Robo2 e o Robo3 e praticamente inexistente (inferior a 1
cm), coincidindo com o valor desejado quase de forma perfeita. Nos restante pares de
robos existe um desvio acumulado de aproximadamente 14o para o par de robos23 (erro
de 14%), e um erro de aproximadamente 28o para o duo de robos12 (erro de 28%).
Relativamente a estabilidade em formacao, e tendo em conta as metricas utilizadas,
pode-se concluir que os robos se encontram em formacao, uma vez que cada distancia
inter-robo se encontra dentro dos limites pre-definidos, isto e, o desvio presente encontra-
se dentro dos 20% da distancia efetivamente pretendida. Em termos de angulo inter-robo,
verifica-se a existencia de um desvio presente em cada um dos angulo correspondentes.
Atraves do grafico da Figura 4.13 torna-se visıvel que, o angulo entre o robo 1 e 3 situa-se
em cerca de 15o, o angulo associado aos robos 2 e 3 e praticamente nulo, enquanto que,
por sua vez, o angulo correspondente ao par de robos 1 e 2 situa-se nos 28o. Desta forma,
todas os angulos inter-robos situam-se dentro da margem de 8% inicialmente estabelecida
(ainda que o angulo entre o robo 1 e 2 se situe muito perto dessa margem).
O fato dos seguidores serem atualizados menos frequentemente que o lıder poder
explicar o desvio da distancia e do seu angulo correspondente, entre o lıder e os seus
seguidores. Derivado a esse fato, a posicao de cada seguidor face ao seu lıder nao e a
mais precisa, proporcionando a existencia de um erro ao manter a formacao pretendida.
−∗−
-60- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
Atraves da dados obtidos a partir da realizacao dos testes, pode-se afirmar que a comunicacao
entre o PC central e o robo presente no ambiente de trabalho e cada vez mais moroso, a medida
que a quantidade de robos neste ambiente aumenta.
Desta feita, verifica-se que a taxa de sucesso da comunicacao entre PC e robo e bastante
superior aquando da presenca, no ambiente de trabalho, de apenas um robo. Neste caso, obtem-
se uma velocidade de atualizacao por parte do robo muito boa, isto e, a rececao de cada pacote
de dados e conseguida com sucesso a esmagadora maioria das vezes. O fato da aplicacao
reacTIVision apenas se encontrar a monitorizar um robo, vai efetuar com que atualize os seus
dados mais rapidamente, enviando, posteriormente, pacotes de dados relativos a unico robo.
Por outro lado, devido ao fato desta comunicacao ser efetuada sem fios (RF), podem existir
possıveis colisoes de dados, pois o lıder tem de enviar periodicamente a sua posicao para cada
seguidor, podendo colidir com os pacotes de dados provenientes do PC central. Como resultado,
verifica-se uma convergencia para o objetivo por parte do lıder, com uma taxa de atualizacao
muito elevada, tudo que e enviado, e recebido.
As experiencias recorrendo a dois e a tres robos revelam, por sua vez, um aumento da
dificuldade para estabelecer com sucesso, a comunicacao entre o PC e o respetivo robo. Esta
dificuldade traduz-se numa reduzida taxa de atualizacao dos seus dados. Isto pode ser explicado
pelo fato da aplicacao reacTIVision funcionar apenas a uma taxa de 5 fps, a resolucao preten-
dida, sendo mais lenta ao monitorizar e atualizar os dados dos tres robos presentes no ambiente
de trabalho. Este fato resulta na convergencia por parte de lıder para o objetivo definido, mas
acarretando os erros na constituicao de uma formacao indicados pelos graficos apresentados
anteriormente.
Como nota, e necessario salientar que os robos utilizados nao fazem uso de qualquer tipo de
mecanismo intrınseco para evitar colisoes, limitando-se apenas ao puro envio e a pura rececao
dos pacotes de dados.
A seguir apresentam-se os resultados tendo em conta o sincronismo entre a aplicacao reac-
TIVision e os robos Khepera, utilizando o metodo de transmissao de dados de forma cıclica.
4.2.1 Sincronismo entre o reacTIVision e os robos Khepera
De modo a notar as diferencas resultantes entre a evolucao da trajetoria de cada robo sob o
ponto de vista do reacTIVision, e a evolucao da trajetoria sob o ponto de vista dos proprios robos
sao realizadas experiencias com valores de intervalo de tempo distintos, utilizando comunicacao
cıclica. Assim sendo, sao apresentados os resultados das experiencias para cada valor de in-
tervalo de tempo estipulado, bem como um exemplo com um intervalo de tempo fixo com a
presenca de obstaculos em tres casos diferentes: com obstaculo diante do Master, com obstaculo
diante da Slave e com obstaculo em posicao intermedia em relacao ao Master e a Slave.
Plataforma de testes para sistema multi-robo(MRS) -61-
4.2. Analise e discussao dos resultados
4.2.2 Intervalo de Tempo = 160ms
Figura 4.14: Scatter das posicoes dos robos unificado (160 ms)
A Figura 4.14 apresenta as trajetorias dos robos segundo a aplicacao reacTIVision e se-
gundo os proprios robos Khepera utilizando um intervalo de tempo de 160 ms. Atraves da
sua visualizacao pode-se constatar uma concordancia entre as duas trajetorias apresentadas,
verificando-se tambem a existencia de uma gralha por parte da aplicacao reacTIVision que e
posteriormente transmitida para o robo Khepera 1, sendo entretanto corrigida na atualizacao
seguinte. Esta gralha pode ser ter origem num congelamento que por por vezes ocorre por parte
da aplicacao reacTIVision, ou simplesmente atraves do reconhecimento do marcador num local
errado por parte desta aplicacao.
A seguir e apresentado o grafico do modulo de erro presente em cada robo, isto e, o desvio
efetivo que existe em cada momento entre a aplicacao reacTIVision e os proprios robos. Assim,
a Figura 4.15 retrata a evolucao deste erro para o robo 1 e a Figura 4.16 evidencia a evolucao
do erro para o robo 2. Atraves da sua analise verifica-se que a media do modulo do erro para
o robo 1 situa-se aproximadamente em 1 cm, enquanto que, o seu valor correspondente para o
robo 2 se situa, aproximadamente, em 1.5 cm. A existencia de picos em cada grafico deste erro
refletem a ocorrencia de gralhas na aplicacao reacTIVision que nao sao filtradas pela aplicacao
-62- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
0 10 20 30 40 50 60 700
20
40
60
80
100
120
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
ErroPosição1Max
: 101.15 mm
ErroMédio
: 11.357 mm
Figura 4.15: Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao coletivo de160 ms
0 10 20 30 40 50 60 70 800
50
100
150
200
250
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
ErroPosição2Max
: 224.07 mm
ErroMédio
: 15.03 mm
Figura 4.16: Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao coletivo de160 ms
e que sao posteriormente transmitidas para os robos. De notar que apenas existe filtragem de
lixo, isto e, se a aplicacao reconhecer a existencia de um marcador que nao corresponda ao
marcador utilizado pelo robo (1, 2 ou 3) esta informacao sera descartada. Por outro lado, se a
aplicacao reconhecer a existencia de um marcador utilizado pelo robo de forma momentanea
Plataforma de testes para sistema multi-robo(MRS) -63-
4.2. Analise e discussao dos resultados
e ocasional num local errado tendo em conta a posicao do robo, nao ha forma de controlo
deste erro, sendo este necessariamente propagado para cada robo, e apenas sendo corrigido na
proxima atualizacao do robo. Outra possibilidade que pode explicar a ocorrencia destas gralhas
e fato da plicacao reacTIVision, utilizando a camara ja especificada anteriormente, correr a
uma taxa de 5 fps (a resolucao utilizada), contudo, por vezes este valor baixa, congelando
por momentos a imagem, podendo nesse instante ser transmitido para o robo em causa uma
atualizacao incorreta da sua posicao no ambiente de trabalho.
4.2.3 Intervalo de Tempo = 320ms
Figura 4.17: Scatter das posicoes dos robos unificado (320 ms)
Na Figura 4.17 e possıvel verificar ambas as trajetorias, correspondendo a aplicacao reacTI-
Vision e segundo os proprios robos utilizando um intervalo de tempo de 320 ms. Na experiencia
realizada e notorio atraves da visualizacao da Figura 4.17 a inexistencia de qualquer gralha fora
da trajetoria de cada robo. Este aspeto pode tambem ser observado atraves da visualizacao do
grafico do modulo do erro para ambos os robos apresentados, na Figura 4.18 e na Figura 4.19,
correspondendo ao modulo do erro do robo 1 e do robo 2, respetivamente. Destes dois graficos
destaca-se o fato do valor de desvio maximo encontrado ser de ≈ 6 cm para o robo 1 e de ≈
-64- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
0 5 10 15 20 25 30 35 40 45 500
10
20
30
40
50
60
70
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
ErroPosição1Max
: 61.777 mm
ErroMédio
: 25.911 mm
Figura 4.18: Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao coletivo de320 ms
0 10 20 30 40 50 600
5
10
15
20
25
30
35
40
45
50
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
ErroPosição2Max
: 47.479 mm
ErroMédio
: 10.105 mm
Figura 4.19: Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao coletivo de320 ms
5 cm para o robo 2. Em termos do erro medio presente nos dois casos, o robo 1 apresenta um
valor de aproximadamente 2.5 cm e, o robo 2 a apresentar um valor de aproximadamente 1 cm.
Atraves da Figura 4.17 pode-se pode-se associar o surgimento destes erros acentuados
Plataforma de testes para sistema multi-robo(MRS) -65-
4.2. Analise e discussao dos resultados
com o fato da aplicacao reacTIVision baixar por vezes demasiado a sua taxa de frames por
segundo, o que pode provocar a perda de informacao por parte desta aplicacao, uma vez que, a
monitorizacao dos robos para momentaneamente, nao conseguindo acompanhar a real evolucao
do robo no ambiente de trabalho. Desta forma, os robos podem ser atualizados com informacao
que nao corresponde a realidade de cada robo.
4.2.4 Intervalo de tempo = 640ms
Figura 4.20: Scatter das posicoes dos robos unificado (640 ms)
A Figura 4.20 apresenta as trajetorias seguidas segundo os proprios robos e segundo a
aplicacao reacTIVision para um intervalo de tempo de 640ms. Atraves da sua visualizacao
contata-se o fato da ocorrencia de uma evidente gralha ocorrida na aplicacao reacTIVision, que
reconhece o marcador numero 1 numa posicao nao verıdica. Apesar da ocorrencia desta gralha,
esta nao e transmitida para o robo, acabando por ser irrelevante do ponto do vista do robo a
ocorrencia desta gralha momentanea na aplicacao reacTIVision.
Ja sob o ponto de vista estatıstico, este erro tem naturalmente relevancia sendo retratado na
representacao do grafico do modulo do erro do robo 1. Assim, a Figura 4.21 e a Figura 4.22
apresentam a evolucao do modulo do erro entre a aplicacao reacTIVision e os proprios robos,
-66- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
0 5 10 15 20 25 30 35 400
100
200
300
400
500
600
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
ErroPosição1Max
: 551.77 mm
ErroMédio
: 67.117 mm
Figura 4.21: Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao coletivo de640 ms
0 5 10 15 20 25 30 35 40 45 500
10
20
30
40
50
60
70
80
90
100
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
ErroPosição2Max
: 97.529 mm
ErroMédio
: 15.616 mm
Figura 4.22: Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao coletivo de640 ms
para cada um dos robos. Atraves da sua visualizacao, e possıvel extrair como facto, o estabe-
lecimento de um valor maximo de desvio do robo 1 de 55 cm, correspondendo a esta gralha
detetada pela aplicacao reacTIVision e por sua vez nao transmitida para o respetivo robo 1; re-
Plataforma de testes para sistema multi-robo(MRS) -67-
4.2. Analise e discussao dos resultados
lativamente ao valor de erro maximo identificado para o robo 2, este situa-se em ≈ 10 cm. Em
relacao ao valor de erro medio apresentado, este e determinado como ≈ 7cm para o robo 1 e de
≈ 16 cm para o robo 2.
4.2.5 Intervalo de tempo = 80ms
A seguir e apresentado um exemplo completo, isto e, um cenario com a presenca de obstaculos
e sem obstaculos, para um intervalo de tempo correspondente de 80 ms. Para alem da trajetoria
assumida por cada robo e do seu correspondente grafico do modulo do erro, e apresentado o seu
diagrama cartesiano e o seu histograma associado.
4.2.5.1 Sem obstaculos
Figura 4.23: Scatter das posicoes dos robos unificado (640 ms)
A Figura 4.23 retrata a evolucao das posicoes dos robos segundo a aplicacao reacTIV-
sion e segundo os proprios robos para um intervalado de tempo de 80 ms sem a utilizacao de
obstaculos. Atraves da visualizacao do seu modulo do erro, apresentado na Figura 4.27 e na
Figura 4.26, constata-se o valor de erro medio para o robo 1 de aproximadamente 1.6 cm, e de
um valor de erro medio para o robo 2 de aproximadamente 2.8 cm.
-68- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
0 5 10 15 20
−10
10
30
50
70
90
110
−70 −50 −30 −10 10 300
5
10
15
20
−80 −60 −40 −20 0 20 40
−20
0
20
40
60
80
100
120
X[mm]
Y[m
m]
DISTÂNCIA REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
Figura 4.24: Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao efetiva dorobo1 utilizando um intervalo de tempo coletivo de 80 ms
0 5 10 15 20 25 30
−70
−50
−30
−10
10
30
50
70
−15 15 45 75 105 135 1650
10
20
30
0 50 100 150
−80
−60
−40
−20
0
20
40
60
80
X[mm]
Y[m
m]
DISTÂNCIA REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
Figura 4.25: Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao efetiva dorobo2 utilizando um intervalo de tempo coletivo de 80 ms)
Nesta experiencia nao se verifica a ocorrencia de erros momentaneos na aplicacao reacTI-
Vision.
Plataforma de testes para sistema multi-robo(MRS) -69-
4.2. Analise e discussao dos resultados
0 5 10 15 20 25 30 35 40 450
20
40
60
80
100
120
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
ErroPosição1Max
: 113.88 mm
ErroMédio
: 15.754 mm
Figura 4.26: Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao coletivo de80 ms
0 10 20 30 40 50 60 700
20
40
60
80
100
120
140
160
180
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
ErroPosição2Max
: 173.18 mm
ErroMédio
: 28.381 mm
Figura 4.27: Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao coletivo de80 ms
-70- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
4.2.5.2 Com obstaculos - Master
Figura 4.28: Scatter das posicoes dos robos unificado (80 ms)
A Figura 4.28 representa a evolucao das posicoes dos robos segundo a aplicacao reacTIV-
sion e segundo os proprios robos para um intervalo de tempo de 80 ms, utilizando obstaculos
em frente do robo lıder. Atraves da sua visualizacao e durante o decorrer do teste observou-
se a quando da identificacao do obstaculo por parte do robo lıder,o robo seguidor sofre uma
aceleracao rapida para a frente e para tras nesse instante. Esta situacao relativa ao robo segui-
dor e retratada pelo grafico a verde correspondente, sendo que a aplicacao reacTIVision nao
consegue acompanhar esta rapida aceleracao por parte do robo seguidor. Em termos de valores
do erro medio obtidos, o robo 1 apresenta um erro medio de aproximadamente 1.4 cm e o robo
2 um erro medio de aproximadamente 1.8 cm.
Nesta experiencia nao se verifica a detecao de marcadores fora da linha de trajetoria adotada
por cada robo, apenas a existencia de uma aceleracao mais forte do robo seguidor, no momento
em que o robo lıder se desvia do obstaculo identificado.
Plataforma de testes para sistema multi-robo(MRS) -71-
4.2. Analise e discussao dos resultados
0 5 10 15 20
−15
−10
−5
0
5
10
15
−10 10 30 500
5
10
15
20
−20 0 20 40 60
−15
−10
−5
0
5
10
15
X[mm]
Y[m
m]
DISTÂNCIA REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
Figura 4.29: Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao efetiva dorobo1 utilizando um intervalo de tempo coletivo de 80 ms
0 5 10 15
−35
−25
−15
−5
5
15
25
35
−50 −30 −10 10 30 50 700
5
10
15
20
25
−60 −40 −20 0 20 40 60 80
−40
−30
−20
−10
0
10
20
30
40
X[mm]
Y[m
m]
DISTÂNCIA REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
Figura 4.30: Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao efetiva dorobo2 utilizando um intervalo de tempo coletivo de 80 ms
-72- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
0 5 10 15 20 25 30 35 400
10
20
30
40
50
60
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
ErroPosição1Max
: 54.254 mm
ErroMédio
: 13.8 mm
Figura 4.31: Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao coletivo de80 ms
0 5 10 15 20 25 30 35 40 450
10
20
30
40
50
60
70
80
90
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
ErroPosição2Max
: 82.662 mm
ErroMédio
: 18.391 mm
Figura 4.32: Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao coletivo de80 ms
Plataforma de testes para sistema multi-robo(MRS) -73-
4.2. Analise e discussao dos resultados
4.2.5.3 Com obstaculos - Normal
Figura 4.33: Scatter das posicoes dos robos unificado (80 ms)
A Figura 4.33 representa a evolucao das posicoes dos robos segundo a aplicacao reacTIV-
sion e segundo os proprios robos, utilizando um intervalo de tempo de 80 ms com obstaculos
entre o robo lıder e o robo seguidor. Nesta experiencia o valor do erro medio para o robo 1
corresponde a aproximadamente 1.7 cm e de aproximadamente 1.5 cm para o robo 2.
Nesta experiencia nao se verifica a o reconhecimento de marcadores fora da linha de tra-
jetoria adotada por cada robo por parte da aplicacao reacTIVision.
-74- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
0 5 10 15 20 25 30
−50
−40
−30
−20
−10
0
−10 10 30 50 700
10
20
30
−20 0 20 40 60 80
−50
−40
−30
−20
−10
0
X[mm]
Y[m
m]
DISTÂNCIA REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
Figura 4.34: Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao efetiva dorobo1 utilizando um intervalo de tempo coletivo de 80 ms
0 5 10 15
−25
−20
−15
−10
−5
0
5
10
15
20
25
−50 −30 −10 10 300
5
10
15
−60 −40 −20 0 20 40
−25
−20
−15
−10
−5
0
5
10
15
20
25
X[mm]
Y[m
m]
DISTÂNCIA REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
Figura 4.35: Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao efetiva dorobo2 utilizando um intervalo de tempo coletivo de 80 ms
Plataforma de testes para sistema multi-robo(MRS) -75-
4.2. Analise e discussao dos resultados
0 10 20 30 40 50 60 70 800
10
20
30
40
50
60
70
80
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
ErroPosição1Max
: 73.189 mm
ErroMédio
: 17.211 mm
Figura 4.36: Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao coletivo de80 ms
0 10 20 30 40 50 600
10
20
30
40
50
60
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
ErroPosição2Max
: 50.977 mm
ErroMédio
: 14.555 mm
Figura 4.37: Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao coletivo de80 ms
-76- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
4.2.5.4 Com obstaculos - Slave
Figura 4.38: Scatter das posicoes dos robos unificado (80 ms)
A Figura 4.38 representa a evolucao das posicoes dos robos segundo a aplicacao reacTIV-
sion e segundo os proprios robos utilizando um intervalo de tempo de 80 ms, com a presenca de
obstaculos na frente da Slave. Atraves da sua visualizacao e possıvel constatar a discrepancia
existente entre a posicao constatada pela aplicacao reacTIVision e a posicao na qual o robo 2
”pensa”que se encontra. Este facto reflete-se no grafico da Figura 4.42, onde o valor do erro
medio para o robo 2 e de aproximadamente 4 cm, ao inves do robo lıder que possui um desvio
inferior a 1 cm.
Nesta experiencia nao ocorre qualquer detecao de marcadores fora da linha de trajetoria
adotada por cada robo.
−∗−
Plataforma de testes para sistema multi-robo(MRS) -77-
4.2. Analise e discussao dos resultados
0 5 10 15
−6
−4
−2
0
2
4
6
8
10
−10 −5 0 5 10 150
2
4
6
8
10
12
−10 −5 0 5 10 15
−6
−4
−2
0
2
4
6
8
10
X[mm]
Y[m
m]
DISTÂNCIA REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
Figura 4.39: Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao efetiva dorobo1 utilizando um intervalo de tempo coletivo de 80 ms
0 5 10 15 20 25 30 35
−75
−45
−15
15
45
75
105
135
165
−475−425−375−325−275−225−175−125−75 −25 25 75 125 1750
10
20
30
40
−500 −400 −300 −200 −100 0 100 200−100
−50
0
50
100
150
X[mm]
Y[m
m]
DISTÂNCIA REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
Figura 4.40: Diferenca em termos posicionais entre a aplicacao reacTIVision e a posicao efetiva dorobo2 utilizando um intervalo de tempo coletivo de 80 ms
-78- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
0 5 10 15 20 25 30 35 401
2
3
4
5
6
7
8
9
10
11
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ1 E A APLICAÇÃO REACTIVISION
ErroPosição1Max
: 10.43 mm ErroMédio
: 5.3476 mm
Figura 4.41: Grafico do modulo do erro para o robo1 utilizando um tempo de transmissao coletivo de80 ms
0 10 20 30 40 50 600
50
100
150
200
250
300
350
400
450
500
Nº Amostras
|Err
o| [m
m]
PLOT DO ERRO REAL ENTRE ROBÔ2 E A APLICAÇÃO REACTIVISION
ErroPosição2Max
: 461.65 mm
ErroMédio
: 41.015 mm
Figura 4.42: Grafico do modulo do erro para o robo2 utilizando um tempo de transmissao coletivo de80 ms
Plataforma de testes para sistema multi-robo(MRS) -79-
4.2. Analise e discussao dos resultados
A tabela 4.1 ilustra de forma sumaria os valores do modulo do erro, nomeadamente o seu
valor medio e o seu valor maximo, para cada intervalo de tempo utilizado. Neste sentido, e
possıvel verificar que utilizando um valor de intervalo de tempo de 160 ms, obtem-se em geral
um menor erro medio associado. Para este valor de intervalo de tempo o modulo do erro medio
para o robo 1 e o menor de todos os intervalos de tempo testados; ja no que diz respeito ao
robo 2, o intervalo de tempo de 320 ms apresenta um menor erro medio para este robo, contudo
nao muito afastado do valor do erro medio utilizando um intervalo de tempo de 160 ms. Em
suma e em geral, o intervalo de tempo de 160 ms apresenta-se com um melhor desempenho,
pois possui um menor desvio em relacao ao robo 1 e um desvio na mesma ordem de grandeza
para o robo 2 (o intervalo de tempo de 320 ms possui um erro medio mais acentuado no robo
1), que se situa entre 1 e 1.5 cm para ambos os robos, configurando-se como a melhor escolha
no que diz respeito ao intervalo de tempo a utilizar. A partir do intervalo de tempo de 320 ms
observa-se um aumento consideravel no valor do erro medio para o robo 1.
De referir, no entanto que, as experiencias onde emergiram gralhas por parte da aplicacao
reacTIVision (e a sua posterior transmissao ou nao para o respetivo robo) proporciona um in-
evitavel acrescimo do valor do erro medio existente entre estas duas entidades. Contudo, as
gralhas sao consideradas parte integrante das experiencias realizadas nao se podendo classificar
ou qualificar a experiencia sem a ocorrencia destes erros.
Tabela 4.1: Tabela comparativa para os valores de intervalo de tempo utilizados
Intervalo de tempo [ms] ErroMedio1 | ErroMax1 [mm] ErroMedio2|ErroMax2[mm]
80 15.754|113.88 28.381|173.18160 11.357|101.15 15.030|224.07320 25.911|61.777 10.105|47.479640 67.117|551.77 15.616|97.529
Das experiencias realizadas extrai-se que a medida que este intervalo de tempo aumenta, o
desvio em termos posicionais entre a aplicacao reacTIVision e a posicao baseada em odometria
de cada robo aumenta, sendo este desvio mais saliente no robo lıder. Este fato pode ser expli-
cado pela aumento de tempo que os robos ficam sem receber uma atualizacao da sua posicao,
dependendo de forma exclusiva do seu calculo de odometria para a sua estimativa de posicao,
acumulando uma maior quantidade de erros quanto maior for o tempo em que nao existir uma
atualizacao da sua posicao da sua posicao fidedigna.
De referir mais uma vez que, de uma forma ideal, o valor deste intervalo de tempo devia
ser nulo, recebendo os robos presentes no ambiente de trabalho todas e quaisquer atualizacao
detetada pela aplicacao reacTIVivision deste o inıcio do seu trajeto ate ao fim do mesmo.
Relativamente as gralhas que despontam durante o decorrer das experiencias na aplicacao
reacTIVision, nomeadamente o reconhecimento de marcadores existentes no ambiente de tra-
balho em posicoes incorretas, esses erros serao transmitidos para os robos sem qualquer tipo
-80- Plataforma de testes para sistema multi-robo(MRS)
4.2. Analise e discussao dos resultados
de filtragem entre ambos. Ja a detecao de lixo no ambiente de trabalho, isto e, a detecao de
marcadores nao presentes no ambiente de trabalho (falsos positivos) nao sao transmitidos para
os robos. Este fato explica a existencia de picos em cada grafico do modulo do erro entre a
aplicacao reacTIVision e a posicao efetiva de cada robo. Desta forma, o robo e informado de
forma errada, evoluindo de acordo com esta atualizacao ate nova rececao de novos dados.
Por fim, salienta-se o facto das atualizacao transmitidas pelo PC central para cada robo
presente no ambiente de trabalho nao serem recebidas na sua totalidade e de forma intacta,
conferindo ao mecanismo de sincronismo um aspeto instavel e volatil.
−∗−
Plataforma de testes para sistema multi-robo(MRS) -81-
Capıtulo 5
Conclusoes e trabalho futuro
5.1 Consideracoes finais
Como conclusao e tendo em vista a concretizacao dos objetivos inicialmente propostos,
e especificado o software reacTIVision responsavel pela identificacao e detecao da evolucao
dos robos no ambiente de trabalho. Por sua vez, esta aplicacao e utilizada como base para
implementar o sincronismo com os robos presentes no ambiente de trabalho, alimentando cada
robo com os seus proprios dados, fechando a malha de dados. A analise a solucao proposta
implementada e efetuada, atraves da incorporacao deste mecanismo de sincronizacao, numa
arquitetura que permite a constituicao de formacoes geometricas, nomeadamente, formacoes
do tipo coluna e oblıqua.
De referir que, a arquitetura de controlo utilizada baseada na odometria possui o incon-
veniente de apenas permitir testes de curto alcance, sendo que se o teste se desenrolar por um
espaco maior que ≈ 0.5 m a formacao diluıa-se, isto e, a arquitetura nao conseguia manter o tipo
de formacao pretendida. Com a introducao deste tipo de mecanismo de sincronismo consegue-
se a vantagem de estabelecer a formacao por mais tempo, sendo a sua estabilidade fortemente
dependente da qualidade de comunicacao existente entre PC → robo. Contudo, e porque a
rececao por parte dos robos nao e estavel, nao e possıvel garantir a absoluta rececao em todos
os robos de todas as atualizacoes enviadas pelo PC central. Assim, a formacao estabelecida sera
desfeita se, por um lado, a comunicacao falhar totalmente, ou, por outro lado, a comunicacao
falhar parcialmente, ou seja, a frequencia de atualizacao de cada robo nao e suficiente para man-
ter o robo em formacao. Deste modo e importante garantir a constante e sistematica estabilidade
de comunicacao PC → robo, pois se isso for conseguido os robos permanecem em formacao
com sucesso.
Durante a fase de testes, verifica-se de forma clara esta dependencia da qualidade de comuni-
cacao entre PC → robo e a respetiva constituicao da formacao entre robos. Atraves dos resul-
tados obtidos e possıvel caraterizar a performance e a precisao de cada formacao do sistema
multi-robo, utilizando um sistema de posicionamento global, tal como era inicialmente previsto
83
5.1. Consideracoes finais
como ferramenta de analise de algoritmos desenvolvidos.
No decorrer dos testes verificou-se a existencia de um erro de posicionamento sistematico,
que atinge o seu pico durante a sua fase inicial de estabelecimento de cada formacao, dimi-
nuindo este erro em geral, durante a fase de manter a formacao estabelecida ate alcancar a
sua posicao final. Estas imprecisoes em termos posicionais podem ser explicadas pelo fato de,
a comunicacao entre o PC central e cada um destes robos, nao ocorrer sempre com sucesso.
Assim, ao atualizar uma vez a posicao de um robo, e enquanto a atualizacao dos outros dois
robos nao ocorre, torna-se evidente o ligeiro desfasamento da posicao do robo em relacao a sua
posicao ideal na formacao. Idealmente, e como o PC central envia ciclicamente a atualizacao de
todos os robos que se encontram no ambiente de trabalho, cada robo podia assim receber o seu
pacote de dados e atualizar a sua posicao, a luz daquilo que a aplicacao reacTIVision. Contudo,
a rececao destes dados por parte do robo, nao ocorre de uma forma sistematica.
Atraves dos resultados obtidos e possıvel caraterizar a performance e a precisao de cada
formacao do sistema multi-robo, assim como, identificar as possıveis causas das imprecisoes
ocorridas. Neste sentido, conclui-se que a convergencia de todos os robos para a formacao pre-
tendida, utilizando um sistema de posicionamento global, ocorre mas com um erro de formacao
adquirido que e fortemente dependente da qualidade da comunicacao entre PC central e cada
robo, isto pois, se esta comunicacao nao for realizada com sucesso de forma periodica, ou seja,
se apenas for realizada esporadicamente a atualizacao das posicoes do robo, o erro de posicao de
cada robo vai aumentar, aumentando por inerencia o erro da formacao estabelecida, nao sendo
possıvel a constituicao de uma formacao perfeita.
De relatar diversos problemas que decorreram durante a execucao dos procedimentos expe-
rimentais, concretamente, das fichas adaptadoras, que efetuam a conexao entre o PC central e o
robo, as quais foram alvo de substituicao de diversos componentes. Aquando da realizacao dos
testes verificou-se tambem que o estado das baterias dos robos nao permitiam a realizacao de
testes sem fios, nao funcionando os robos de forma independente, necessitando de alimentacao
externa atraves da utilizacao de cabos, que ligam o robo a ficha adaptadora. Devido a este fato,
foram substituıdas todas as baterias originais por baterias novas, de forma a tornar possıvel a
realizacao de testes sem fios, sem o inevitavel incomodo da utilizacao de fios na realizacao dos
ensaios.
Outro dos constrangimentos ocorridos, esta relacionado com a Torre Base dos robos. Esta
Torre Base que esta conectada ao PC central atraves de um cabo conversor USB-Serie, e res-
ponsavel pela transmissao dos dados provenientes do PC em Radio Frequencia (RF). Contudo
foi notorio, no decorrer dos testes que a sua transmissao era frequentemente interrompida, sendo
necessario desligar e voltar a ligar a Torre Base, de forma a voltar a efetuar a correta transmissao
de dados.
-84- Plataforma de testes para sistema multi-robo(MRS)
5.2. Sugestoes para trabalho futuro
5.2 Sugestoes para trabalho futuro
Tal como ja fora indicado atras, torna-se necessario, de forma a melhorar o desempenho do
sistema multi-robo, maximizar a taxa de sucesso da comunicacao entre PC → robo. Assim,
qualquer opcao escolhida no futuro deve seguir este caminho de otimizacao do protocolo de
comunicacao entre PC e robo.
Desta forma deve ser privilegiada a melhoria do protocolo de comunicacao entre o PC cen-
tral e cada um dos robos, de forma a, melhorar a qualidade dos resultados obtidos, nomeada-
mente, em termos de precisao da posicao de cada robo na formacao. De referir que, o fato dos
robos utilizados se limitarem ao puro envio do pacote de dados, nao existindo qualquer tipo de
protocolo de acesso ao meio que evite colisoes, pode explicar os problemas de comunicacao
obtidos aquando da presenca de tres robos no ambiente de trabalho. Este aspeto poderia ser
melhorado com a utilizacao de um protocolo de acesso ao meio, que minimizasse as colisoes
de dados (p.e. CSMA/CD), de forma que, se algum robo detetasse que o meio estava a ser
ocupado, esperava um tempo aleatorio antes de transmitir a sua mensagem, de forma a evitar
erros de colisao. Desta forma, e maximizado o sucesso das transmissoes dos robos entre si e,
entre o PC central e cada robo. Contudo, devido ao robos utilizados nao e possıvel implementar
um protocolo deste tipo, sendo para tal necessario implementar toda a arquitetura em robos que
permitam a sua realizacao.
Um metodo alternativo passıvel de ser implementado em termos da transmissao de dados
entre PC → robo, seria utilizando uma metodologia de passagem de testemunho (token ring).
Neste contexto, o testemunho circula numa topologia em anel em que cada um dos robos deve
aguardar a sua recepcao em ordem a estabelecer a comunicacao com o PC. Desta forma a
transmissao de dados da-se durante uma pequena janela de tempo, e apenas por quem detem o
testemunho, sendo a cadencia de transmissao de dados definida pelo PC central.
Outro dos aspetos que pode aumentar de forma significativa o desempenho da solucao pro-
posta e a escolha de uma camara que permita o funcionamento da aplicacao reacTIVision a uma
definicao semelhante, mas a uma taxa de fps superior a utilizada nesta solucao. Este fato per-
mite monitorizar e atualizar os dados de uma forma mais celere, retirando aquela sensacao de
”arrastamento”, que por vezes acontece na solucao implementada com a taxa de 5fps. Por outro
lado, a utilizacao de uma resolucao superior permite a detecao dos marcadores em zonas do am-
biente de trabalho onde e difıcil a sua identificacao, perdendo-se momentaneamente a trajetoria
do marcador identificado. Uma alternativa interessante que se apresenta para a sua incorporacao
na solucao desenvolvida e a camara PS3 eye, que combina uma resolucao de 800x600 pixeis a
uma taxa de 60fps, constituindo-se como uma alternativa viavel e que possibilita a melhora da
qualidade dos resultados obtidos, melhorando a performance do tracking dos marcadores.
Plataforma de testes para sistema multi-robo(MRS) -85-
Bibliografia
[1] T. Machado, “Transporte de objectos por equipas de robos moveis autonomos:
implementacao e validacao de uma arquitectura de controlo distribuıda, baseada em siste-
mas dinamicos nao lineares,” 2008.
[2] L. Ludwig and M. Gini, “Robotic swarm dispersion using wireless intensity signals,” Dis-
tributed Autonomous Robotic Systems 7, pp. 135–144, 2006.
[3] C. Parker, H. Zhang, and C. Kube, “Blind bulldozing: multiple robot nest construction,”
in Intelligent Robots and Systems, 2003.(IROS 2003). Proceedings. 2003 IEEE/RSJ Inter-
national Conference on, vol. 2, pp. 2010–2015, IEEE, 2003.
[4] W. Burgard, M. Moors, D. Fox, R. Simmons, and S. Thrun, “Collaborative multi-robot ex-
ploration,” in Robotics and Automation, 2000. Proceedings. ICRA’00. IEEE International
Conference on, vol. 1, pp. 476–481, IEEE, 2000.
[5] H. E. J. Borenstein and L. Feng, Where am I? Sensors and Methods for Mobile Robot
Positioning. No. ISBN 1-56881-058-X, A.K. Peters, Lda, Wellesley, MA, February 1996.
[6] A. Ferrein, L. Hermanns, and G. Lakemeyer, “Comparing sensor fusion techniques for
ball position estimation,” RoboCup 2005: Robot soccer world cup IX, pp. 154–165, 2006.
[7] W. Kowalczyk, “Multi-robot coordination,” in Proc. of the 2nd Internat. Workshop on
Robot Motion and Control, pp. 219–223, 2001.
[8] E. Sahin and P. Gaudiano, “Kite: The khepera integrated testing environment,” 1999.
[9] K. Hawick and H. James, “Middleware for context sensitive mobile applications,” in Pro-
ceedings of the Australasian information security workshop conference on ACSW frontiers
2003-Volume 21, p. 141, Australian Computer Society, Inc., 2003.
[10] V. G. Andac T. Samiloglu, Omer Cayirpunar and A. B. Koku, “An experimental set-up for
multi-robot applications,” in Workshop Proceedings of SIMPAR 2008 Intl. Conf. on Simu-
lation, Modeling and Programming for Autonomous Robots, no. ISBN 978-88-95872-01-
8, November 2008.
87
Bibliografia
[11] R. A. T. Lucas P.J.J. Noldus, Andrew J. Spink, “Computerised video tracking, movement
analysis and behaviour recognition in insects,” Computers and Electronics in Agriculture,
2002.
[12] M. Fiala, “Artag, a fiducial marker system using digital techniques,” 20-25 June 2005.
[13] X. Zhang, S. Fronz, and N. Navab, “Visual marker detection and decoding in ar systems:
A comparative study,” in Proceedings of the 1st International Symposium on Mixed and
Augmented Reality, ISMAR ’02, (Washington, DC, USA), pp. 97–, IEEE Computer So-
ciety, 2002.
[14] T. Lochmatter, P. Roduit, C. Cianci, N. Correll, Jacot, and A. Martinoli, “Swistrack - a
flexible open source tracking software for multi-agent systems,” in Intelligent Robots and
Systems, 2008. IROS 2008. IEEE/RSJ International Conference on, pp. 4004–4010, IEEE,
2008.
[15] A. Sirota, “Robotracker - a system for tracking multiple robots in real time,” Technion
Israel Institute of Technology, Tech. Rep, 2004.
[16] R. Arkin and T. Balch, “Behavior-based formation control for multi-robot teams,” 1999.
[17] J. Fredslund and M. J. Mataric, “A general algorithm for robot formations using local
sensing and minimal communication,” 2002.
[18] D. Naffin and G. Sukhatme, “Negotiated formations,” in Intelligent Autonomous Systems
8: The Intelligent Autonomous Systems Conference, p. 181, Ios Pr Inc, March 2004.
[19] Motorola, MC68331 Users Manual. Motorola, Inc, 1996.
[20] R. Bencina and M. Kaltenbrunner, “The design and evolution of fiducials for the reactivi-
sion system,” 2005.
[21] M. Kaltenbrunner and R. Bencina, “Reactivision: A computer-vision framework for table-
based tangible interaction,” in TEI ’07: Proceedings of the 1st International Conference
on Tangible and Embedded Interaction, (New York, NY, USA), pp. 69–74, ACM, 2007.
[22] M. Kaltenbrunner, T. Bovermann, R. Bencina, and E. Costanza, “Tuio: A protokol for
table-top tangible user interfaces,” in Proceedings of Gesture Workshop 2005, Gesture
Workshop, 2005.
[23] E. Franzi, “Khepera radio turret user manual v1.0,” K-Team SA, Lausanne, 1999.
[24] J. Borenstein, Experimental results from internal odometry error correction with the Om-
niMate mobile robot. IEEE Transactions on Robotics and Automation, Vol. 14, No. 6,
Dec. 1998.
-88- Plataforma de testes para sistema multi-robo(MRS)
Bibliografia
[25] R. Bencina, M. Kaltenbrunner, and S. Jorda, “Improved topological fiducial tracking in
the reactivision system,” vol. 0, (Los Alamitos, CA, USA), p. 99, IEEE Computer Society,
2005.
[26] E. Bicho and S. Monteiro, “Formation control for multiple mobile robots: a non-linear at-
tractor dynamics approach,” in Intelligent Robots and Systems, 2003.(IROS 2003). Procee-
dings. 2003 IEEE/RSJ International Conference on, vol. 2, pp. 2016–2022, IEEE, 2003.
[27] E. Franzi, “Khepera radio base user manual v1.0,” K-Team SA, Lausanne, 1999.
[28] E. Franzi, “Khepera user manual v5.02,” K-Team SA, Lausanne, 1999.
[29] E. Franzi, “Khepera bios reference manual v5.01,” K-Team SA, Lausanne, 1998.
[30] A. T. Hayes and P. Dormiani-Tabatabaei, “Self-organized flocking with agent failure: Off-
line optimization and demonstration with real robots,” 2002.
[31] S. Monteiro, Attractor dynamics approach to formation. PhD thesis, Universidade do
Minho, 2007.
[32] S. Monteiro and E. Bicho, “A dynamical systems approach to behavior-based formation
control,” in Robotics and Automation, 2002. Proceedings. ICRA’02. IEEE International
Conference on, vol. 3, pp. 2606–2611, IEEE, 2002.
[33] S. Monteiro, M. Vaz, and E. Bicho, “Attractor dynamics generates robot formation: from
theory to implementation,” in Robotics and Automation, 2004. Proceedings. ICRA’04.
2004 IEEE International Conference on, vol. 3, pp. 2582–2586, IEEE, 2004.
[34] M. Ribeiro and P. Vale, Robo de baixo custo para Sistemas Multi-Robo. Janeiro de 2009.
[35] E. Scheinerman, Invitation to dynamical systems. Prentice Hall Upper Saddle River, NJ,
1996.
[36] F. Schneider, D. Wildermuth, and A. Kraußling, “Discussion of exemplary metrics for
multi-robot systems for formation navigation,” vol. 2, pp. 345–353, Citeseer, 2005.
[37] J. Spletzer, A. Das, R. Fierro, C. Taylor, V. Kumar, and J. Ostrowski, “Cooperative locali-
zation and control for multi-robot manipulation,” in Intelligent Robots and Systems, 2001.
Proceedings. 2001 IEEE/RSJ International Conference on, vol. 2, pp. 631–636, IEEE,
2001.
[38] M. Vaz, “Control of navigation in formation of three autonomous robots: a nonlinear
dynamical systems approach,” vol. Relatorio de Estagio Obrigatorio, September 2003.
Plataforma de testes para sistema multi-robo(MRS) -89-
Apendice A - Codigo Fonte de Rotinas
A.1 Rotina para a rececao do pacote de dados do PC - Tempo
de espera individual
A rotina a seguir apresentada lida com a rececao do pacote de dados enviado pelo PC central.
A seguir e descrita a trama a receber pelos Robos:
M0 | M1| x | y | a | X | Y | A | m | r | s0 | s1 | ms0 | ms1 | CR
int getFromMaster1(struct config *cfg, struct goal *g)
{
int32 status1;
int32 status2;
int32 status3;
static uint8 i=0;
static decimal Auxiliar=0;
static uint8 buffer1[1 + 1 + 16] =
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
/* ****************************************************** */
/* ****************************************************** */
if( radio_getStatus() & 2 )
{
/* *********************** KHEPERA1 ********************* */
/* ************* DATA_RECEPTION#1 - AJ(0x41|0x4A) ******* */
91
A.1. Rotina para a rececao do pacote de dados do PC - Tempo de espera individual
/* lock resources */
tim_lock();
radio_recBuffer (buffer1); // Recebe o Primeiro Buffer
if( (buffer1[1]==SIZE_BUFFER) && (buffer1[2]==0x41) &&
(buffer1[3]==0x4A) && (buffer1[16]==PROTOCOL_SIG) ){
printf ("\r\n\r");
printf("<* ******************************** *>\n");
printf ("ID of the sender %d\r\n", buffer1[0]);
printf ("Size of the message %d\r\n", buffer1[1]);
printf ("Message(00) ... ");
for (i = 0; i < buffer1[1]; i++)
printf ("%d ", buffer1[2 + i]);
printf ("\r\n\r\n");
cfg->Auxiliar_X = ( buffer1[4] / 255.0 );
cfg->Auxiliar_X = ( cfg->Auxiliar_X )*( TABLE_WIDTH_X );
cfg->Xrobot = MM2PAM( cfg->Auxiliar_X );
printf("cfg->Xrobot (Pam): %d \r\n " EOL, cfg->Xrobot);
cfg->Auxiliar_Y = ( buffer1[5] / 255.0 );
cfg->Auxiliar_Y = ( cfg->Auxiliar_Y )*( TABLE_WIDTH_Y );
cfg->Yrobot = MM2PAM( cfg->Auxiliar_Y );
printf("cfg->Yrobot (Pam): %d \r\n " EOL, cfg->Yrobot);
cfg->Phi = ( buffer1[6] / 4.0 );
printf("cfg->Phi (Rad): %f \r\n " EOL, cfg->Phi);
printf("<* ************************************* *>\n");
printf ("\n");
(cfg->VALIDATE_DATA_RECEPTION) = TRUE;
/* release resources */
tim_unlock();
}
-92- Plataforma de Testes para Sistema Multi-Robo(MRS)
A.1. Rotina para a rececao do pacote de dados do PC - Tempo de espera individual
else{
if( (buffer1[1]==PROTOCOL_SIG) && (buffer1[14]==PROTOCOL_SIG) ){
cfg->Xrobot = buffer1[2] + ( buffer1[3] << 8 ) +
( buffer1[4] << 16 ) + (buffer1[5] << 24 );
cfg->Yrobot = buffer1[6] + ( buffer1[7] << 8 ) +
( buffer1[8] << 16 ) + ( buffer1[9] << 24 );
g->vMaster = buffer1[10] / 4.0;
cfg->Phi = DEG_2_RAD( buffer1[12] * 180 + buffer1[11] );
g->masterTHERE = buffer1[13];
printf("\r\n\r");
printf("<* ******* Data from Master... ********** *>\n");
printf("g->X (Pam): %d \r\n " EOL, g->X);
printf("g->Y (Pam): %d \r\n " EOL, g->Y);
printf("g->PhiMaster (Rad): %f \r\n " EOL, g->PhiMaster);
/* *************************************************** */
printf ("\n");
(cfg->VALIDATE_DATA_RECEPTION) = TRUE;
}
else{
printf("\n\rWaiting for data (#1)...\n\r");
for (i = 0; i < buffer1[i]; i++)
buffer1[i]=0;
(cfg->VALIDATE_DATA_RECEPTION) = FALSE;
tim_suspend_task(50);
}
}
}
else{
Plataforma de Testes para Sistema Multi-Robo(MRS) -93-
A.2. Rotina para a rececao do pacote de dados do PC - Tempo de espera coletivo
printf("\n\rWaiting for data (#1)...\n\r");
}
for (i = 0; i < (buffer1[1]); i++)
buffer1[i] = 0;
return (cfg->VALIDATE_DATA_RECEPTION);
}
A.2 Rotina para a rececao do pacote de dados do PC - Tempo
de espera coletivo
A rotina a seguir apresentada trata da rececao do pacote de dados enviado pelo PC central
de forma cıclica. A sua sintaxe e apresentada a seguir:
M0 | M1| x1 | y1 | a1 | x2 | y2 | a2 | x3 | y3 | a3 | s0 | s1 | ms0 | CR
int getFromMaster1(struct config *cfg)
{
int32 status1;
int32 status2;
int32 status3;
static uint8 i=0;
static decimal Auxiliar=0;
static uint8 buffer1[1 + 1 + 16] =
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
/* *********************************** */
if ( radio_getStatus() & 2 )
{
/* ************* KHEPERA1 ************ */
-94- Plataforma de Testes para Sistema Multi-Robo(MRS)
A.2. Rotina para a rececao do pacote de dados do PC - Tempo de espera coletivo
/* lock resources */
tim_lock();
radio_recBuffer (buffer1); // Recebe o Primeiro Buffer
if( (buffer1[1]==SIZE_BUFFER) && (buffer1[2]==0x41) &&
(buffer1[3]==0x4A) && (buffer1[16]==PROTOCOL_SIG) ){
printf ("\r\n\r"); *********************** *>\n");
printf ("ID of the sender %d\r\n", buffer1[0]);
printf ("Size of the message %d\r\n", buffer1[1]);
printf ("Message(00) ... ");
for (i = 0; i < buffer1[1]; i++)
printf ("%d ", buffer1[2 + i]);
printf ("\r\n\r\n");
cfg->Auxiliar_X = ( buffer1[4] / 255.0 );
cfg->Auxiliar_X = ( cfg->Auxiliar_X )*( TABLE_WIDTH_X );
cfg->Xrobot = MM2PAM( cfg->Auxiliar_X );
printf("cfg->Xrobot (Pam): %d \r\n " EOL, cfg->Xrobot);
cfg->Auxiliar_Y = ( buffer1[5] / 255.0 );
cfg->Auxiliar_Y = ( cfg->Auxiliar_Y )*( TABLE_WIDTH_Y );
cfg->Yrobot = MM2PAM( cfg->Auxiliar_Y );
printf("cfg->Yrobot (Pam): %d \r\n " EOL, cfg->Yrobot);
cfg->Phi = ( buffer1[6]);
if( (cfg->Phi)==48 )
cfg->Phi = 0;
else
cfg->Phi = ( buffer1[6] / 4.0 );
printf("cfg->Phi (Rad): %f \r\n " EOL, cfg->Phi);
printf ("\r<* *************************** *>\n");
printf ("\n");
/* *********************************** */
Plataforma de Testes para Sistema Multi-Robo(MRS) -95-
A.2. Rotina para a rececao do pacote de dados do PC - Tempo de espera coletivo
cfg->Auxiliar_X3 = ( buffer1[10] );
cfg->Auxiliar_X = ( buffer1[10] / 255.0 );
cfg->Auxiliar_X = ( cfg->Auxiliar_X )*( TABLE_WIDTH_X );
cfg->Xrobot3 = MM2PAM( cfg->Auxiliar_X );
cfg->Auxiliar_Y3 = ( buffer1[11] );
cfg->Auxiliar_Y = ( buffer1[11] / 255.0 );
cfg->Auxiliar_Y3 = ( cfg->Auxiliar_Y )*( TABLE_WIDTH_Y );
cfg->Yrobot3 = MM2PAM( cfg->Auxiliar_Y );
cfg->Auxiliar_Phi3 = ( buffer1[12]);
if( (cfg->Auxiliar_Phi3)==48 )
cfg->Auxiliar_Phi3 = 0;
else
cfg->Auxiliar_Phi3 = ( buffer1[12]);
/* *********************************** */
cfg->Auxiliar_X2 = ( buffer1[7] );
cfg->Auxiliar_X = ( buffer1[7] / 255.0 );
cfg->Auxiliar_X = ( cfg->Auxiliar_X )*( TABLE_WIDTH_X );
cfg->Xrobot2 = MM2PAM( cfg->Auxiliar_X );
cfg->Auxiliar_Y2 = ( buffer1[8] );
cfg->Auxiliar_Y = ( cfg->Auxiliar_Y )*( TABLE_WIDTH_Y );
cfg->Yrobot2 = MM2PAM( cfg->Auxiliar_Y );
cfg->Auxiliar_Phi2 = ( buffer1[9] );
if( (cfg->Auxiliar_Phi2)==48 )
cfg->Auxiliar_Phi2 = 0;
else
cfg->Auxiliar_Phi2 = ( buffer1[9] );
/* *********************************** */
(cfg->Reception_Time) =
ASCII2int( buffer1[13], buffer1[14], buffer1[15] );
-96- Plataforma de Testes para Sistema Multi-Robo(MRS)
A.2. Rotina para a rececao do pacote de dados do PC - Tempo de espera coletivo
(cfg->Actual_Reception_Time) = (
cfg->Reception_Time) * 0.10;
printf("cfg->Actual_Reception_Time (sec): %f \r\n " EOL,
cfg->Actual_Reception_Time);
/* *********************************** */
(cfg->VALIDATE_DATA_RECEPTION) = TRUE;
/* release resources */
tim_unlock();
}
/* ************Default**************** */
else{
printf("\n\rWaiting for data (#1)... \n\r");
(cfg->VALIDATE_DATA_RECEPTION) = FALSE;
}
}
else{
printf("\n\rWaiting for data (#1)... \n\r");
(cfg->VALIDATE_DATA_RECEPTION) = FALSE;
}
/* *****************End*************** */
for (i = 0; i < (buffer1[1]); i++)
buffer1[i] = 0;
return (cfg->VALIDATE_DATA_RECEPTION);
}
Plataforma de Testes para Sistema Multi-Robo(MRS) -97-
A.3. Rotina para a transmissao da posicao do Master para cada Slave - Tempo de esperaindividual
A.3 Rotina para a transmissao da posicao do Master para
cada Slave - Tempo de espera individual
Rotina implementada no lıder, utilizada para atualizar as Slaves. A trama utilizada e descrita
a seguir:
x3 | x2 | x1 | x0 | y3 | y2 | y1 | y0 | vMaster | | ΦMaster0 | ΦMaster1 | | MT | CR
void send2Slave(struct goal *g,
struct config *cfg,
real true_v_cm )
{
integer phiMaster;
uint8 buffer[18] =
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
buffer[14] = 13;
/* Send stuff over the radio */
buffer[2] = ( cfg->Xrobot >> 0 ) & 0xFF;
buffer[3] = ( cfg->Xrobot >> 8 ) & 0xFF;
buffer[4] = ( cfg->Xrobot >> 16 ) & 0xFF;
buffer[5] = ( cfg->Xrobot >> 24 ) & 0xFF;
buffer[6] = ( cfg->Yrobot >> 0 ) & 0xFF;
buffer[7] = ( cfg->Yrobot >> 8 ) & 0xFF;
buffer[8] = ( cfg->Yrobot >> 16 ) & 0xFF;
buffer[9] = ( cfg->Yrobot >> 24 ) & 0xFF;
buffer[10]= (uint8) rint( true_v_cm * 4);
phiMaster = (integer) RAD_2_DEG( cfg->Phi );
buffer[11]= phiMaster % 180;
buffer[12]= phiMaster / 180;
buffer[13]= 0;
/* SOMEKIND OF SIGNATURE */
buffer[0] = -1;
-98- Plataforma de Testes para Sistema Multi-Robo(MRS)
A.4. Rotina para a transmissao da posicao do Master para cada Slave - Tempo de esperacoletivo
buffer[1] = 13;
radio_sndBuffer( buffer );
}
A.4 Rotina para a transmissao da posicao do Master para
cada Slave - Tempo de espera coletivo
Rotina utilizada para atualizar cada Slave, utilizando um tempo de espera coletivo. A trama
utilizada e descrita a seguir:
x3 | x2 | x1 | x0 | y3 | y2 | y1 | y0 | vMaster | | ΦMaster | | MT | xSlave | ySlave | aSlave | CR
void send2Slave(struct goal *g, struct config *cfg, real true_v_cm )
{
integer i=0;
integer phiMaster;
uint8 buffer[18] =
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
buffer[15] = 13;
/* Send stuff over the radio */
buffer[2] = ( cfg->Xrobot >> 0 ) & 0xFF; //
buffer[3] = ( cfg->Xrobot >> 8 ) & 0xFF; // 1os oito bytes
buffer[4] = ( cfg->Xrobot >> 16 ) & 0xFF; //
buffer[5] = ( cfg->Xrobot >> 24 ) & 0xFF; //
buffer[6] = ( cfg->Yrobot >> 0 ) & 0xFF; //
buffer[7] = ( cfg->Yrobot >> 8 ) & 0xFF; // 2os oito bytes
buffer[8] = ( cfg->Yrobot >> 16 ) & 0xFF; //
buffer[9] = ( cfg->Yrobot >> 24 ) & 0xFF; //
buffer[10]= (uint8) rint( true_v_cm * 4); // vMaster
while( (cfg->Phi) > (2*M_PI) )
(cfg->Phi)=REDUCE_ANGLE(cfg->Phi);
Plataforma de Testes para Sistema Multi-Robo(MRS) -99-
A.4. Rotina para a transmissao da posicao do Master para cada Slave - Tempo de esperacoletivo
phiMaster = (uint8) rint( (cfg->Phi) * 4); // PhiMaster
buffer[11]= phiMaster; //
buffer[12]= 0; // masterTHERE
buffer[13]= (cfg->Auxiliar_X3); // Xrobot3
buffer[14]= (cfg->Auxiliar_Y3); // Yrobot3
buffer[15]= (cfg->Auxiliar_Phi3); // Phi3
buffer[16]= 13; // CR
/* SOMEKIND OF SIGNATURE */
buffer[0] = -1;
buffer[1] = 15;
radio_sndBuffer( buffer );
printf ("<* ******************************* *>\n");
printf (" ID of the sender %d\r\n", buffer[0]);
printf (" Size of the message %d\r\n", buffer[1]);
printf (" Send2Slave(MASTER) ... ");
for (i = 0; i < buffer[1]; i++)
printf ("%d ", buffer[2 + i]);
printf ("\r\n\r\n");
g->X_aux = buffer[2] + ( buffer[3] << 8 ) +
( buffer[4] << 16 ) + ( buffer[5] << 24 );
printf(" g->X_aux: %d \r\n", g->X_aux);
g->Y_aux = buffer[6] + ( buffer[7] << 8 ) +
( buffer[8] << 16 ) + ( buffer[9] << 24 );
printf(" g->Y_aux: %d \r\n", g->Y_aux);
g->vMaster = buffer[10] / 4.0;
printf(" g->vMaster: %d ", g->vMaster);
-100- Plataforma de Testes para Sistema Multi-Robo(MRS)
A.5. Rotina para a rececao da informacao do Master em cada Slave - Tempo de esperaindividual
g->PhiMaster = buffer[11];
g->PhiMaster = g->PhiMaster / 4.0;
printf(" g->PhiMaster: %f \r\n", g->PhiMaster);
g->masterTHERE = buffer[12];
printf(" g->masterTHERE: %d \r\n", g->masterTHERE);
cfg->Auxiliar_X = (buffer[13] / 255.0);
cfg->Auxiliar_X = ( cfg->Auxiliar_X ) * ( TABLE_WIDTH_X );
cfg->Xrobot3 = (integer) rint( cfg->Auxiliar_X );
cfg->Xrobot3 = MM2PAM( cfg->Xrobot3 );
printf(" cfg->Xrobot3 (Pam): %d \r\n", cfg->Xrobot3);
cfg->Auxiliar_Y = (buffer[14] / 255.0);
cfg->Auxiliar_Y = ( cfg->Auxiliar_Y ) * ( TABLE_WIDTH_Y );
cfg->Yrobot3 = (integer) rint( cfg->Auxiliar_Y );
cfg->Yrobot3 = MM2PAM( cfg->Yrobot3 );
printf(" cfg->Yrobot3 (Pam): %d \r\n", cfg->Yrobot3);
cfg->Phi3 = buffer[15];
cfg->Phi3 = (cfg->Phi3) / 4.0;
printf(" cfg->Phi3: %f \r\n", cfg->Phi3);
printf ("<* ************************************ *>\n");
(cfg->contador)=0;
}
A.5 Rotina para a rececao da informacao do Master em cada
Slave - Tempo de espera individual
Rotina implementada em cada Slave utilizada para receber a trama enviada pelo Master com
tempo de espera individual:
x3 | x2 | x1 | x0 | y3 | y2 | y1 | y0 | vMaster | | ΦMaster0 | ΦMaster1 | | MT | CR
void getFromMaster(struct goal *g, struct config *cfg,
Plataforma de Testes para Sistema Multi-Robo(MRS) -101-
A.6. Rotina para a rececao de informacao do Master em cada Slave - Tempo de esperacoletivo
real useless_variable)
{
uint8 buffer[18] =
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
if ( radio_getStatus() & 2 )
{
radio_recBuffer(buffer);
if ( buffer[14] == 13 )
{
g->X = buffer[2] + ( buffer[3] << 8 ) +
( buffer[4] << 16 ) + ( buffer[5] << 24 );
g->Y = buffer[6] + ( buffer[7] << 8 ) +
( buffer[8] << 16 ) + ( buffer[9] << 24 );
g->vMaster = buffer[10] / 4.0;
g->PhiMaster = DEG_2_RAD( buffer[12] * 180 + buffer[11] );
g->masterTHERE = buffer[13];
printf("(cfg->Xrobot, cfg->Yrobot) -> (%d, %d) \r\n " EOL,
cfg->Xrobot, cfg->Yrobot);
printf("(g->X, g->Y) -> (%d, %d) \r\n " EOL, g->X, g->Y);
printf("cfg->Phi: %f \r\n " EOL, cfg->Phi);
}
}
}
A.6 Rotina para a rececao de informacao do Master em cada
Slave - Tempo de espera coletivo
Rotina implementada em cada Slave utilizada para receber a trama enviada pelo Master com
tempo de espera coletivo:
x3 | x2 | x1 | x0 | y3 | y2 | y1 | y0 | vMaster | | ΦMaster | | MT | xSlave | ySlave | aSlave | CR
-102- Plataforma de Testes para Sistema Multi-Robo(MRS)
A.6. Rotina para a rececao de informacao do Master em cada Slave - Tempo de esperacoletivo
natural getFromMaster(struct goal *g,
struct config *cfg, real useless_variable)
{
uint8 i = 0;
uint8 buffer[18] =
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
(cfg->Check)=0;
while ( !( radio_getStatus() & 2 ) )
{
printf("\nWait for it...\r\n");
}
/* lock resources */
tim_lock();
radio_recBuffer(buffer);
if ( buffer[0] == 1 && buffer[1] == 15 &&
buffer[16] == 13 && buffer[2] != 65 )
{
g->X = buffer[2] + ( buffer[3] << 8 ) +
( buffer[4] << 16 ) + ( buffer[5] << 24 );
g->Y = buffer[6] + ( buffer[7] << 8 ) +
( buffer[8] << 16 ) + ( buffer[9] << 24 );
g->vMaster = ( (buffer[10]) / (4.0) );
printf("g->vMaster: %f \n\r", g->vMaster);
if( (buffer[11])==0 ){
g->PhiMaster = 0.00;
}
else{
g->PhiMaster = ( (buffer[11]) / (4.0) );
}
g->masterTHERE = buffer[12];
Plataforma de Testes para Sistema Multi-Robo(MRS) -103-
A.6. Rotina para a rececao de informacao do Master em cada Slave - Tempo de esperacoletivo
printf("g->masterTHERE: %d \n\r", g->masterTHERE);
if(g->masterTHERE==1)
mot_stop();
printf("Mission Accomplished: %d \n\r", g->masterTHERE);
cfg->Auxiliar_X = ( (buffer[13]) / (255.0) );
cfg->Auxiliar_X = ( cfg->Auxiliar_X ) * ( TABLE_WIDTH_X );
cfg->Xrobot = (integer) rint( cfg->Auxiliar_X );
cfg->Xrobot = MM2PAM( cfg->Xrobot );
cfg->Auxiliar_Y = ( (buffer[14]) / (255.0) );
cfg->Auxiliar_Y = ( cfg->Auxiliar_Y ) * ( TABLE_WIDTH_Y );
cfg->Yrobot = (integer) rint( cfg->Auxiliar_Y );
cfg->Yrobot = MM2PAM( cfg->Yrobot );
if( (buffer[15])==0 ){
cfg->Phi = 0.00;
}
else{
cfg->Phi = ( (buffer[15]) / (4.0) ) ;
}
printf("Recepcao... OK! \n\r", EOL);
printf("cfg->Xrobot: %d \n\r", cfg->Xrobot);
printf("cfg->Yrobot: %d \n\r", cfg->Yrobot);
printf("cfg->Phi: %f \n\r", cfg->Phi);
printf("g->X: %d \n\r", g->X);
printf("g->Y: %d \n\r", g->Y);
printf("g->PhiMaster: %f \n\r", g->PhiMaster);
(cfg->Check)=1;
printf(" %d \n\r", cfg->Check );
printf ("<* ****************************** *>\n");
printf (" ID of the sender %d\r\n", buffer[0]);
-104- Plataforma de Testes para Sistema Multi-Robo(MRS)
A.7. Rotina para a sincronizacao de movimento entre Master e Slave
printf ("Size of the message %d\r\n", buffer[1]);
printf ("Message(getFromMaster) ... ");
for (i = 0; i < buffer[1]; i++)
printf ("%d ", buffer[2 + i]);
printf ("\r\n\r");
printf ("<* ******************************* *>\n");
/* unlock resources */
tim_unlock();
}
return (cfg->Check);
}
A.7 Rotina para a sincronizacao de movimento entre Master
e Slave
void syncSlave(struct goal *g, struct config *cfg)
{
integer i = 0;
(cfg->Received=FALSE);
while ( !( radio_getStatus() & 2 ) )
{
tim_suspend_task(500);
printf("Tou a espera\r\n");
}
for ( i=0; i<2; i++){
(cfg->Received)=getFromMaster1(cfg,g);
while(cfg->Received==FALSE)
(cfg->Received)=getFromMaster1(cfg,g);
}
(cfg->Received=TRUE);
printf("Aqui vou eu!
E Deus esta em (%d, %d)!\r\n", g->X, g->Y);
}
Plataforma de Testes para Sistema Multi-Robo(MRS) -105-
A.8. Ciclo de atualizacao de cada Robo
void syncMaster(struct goal *g, struct config *cfg)
{
integer i = 0;
(cfg->Check_Reception1=FALSE);
(cfg->Check_Reception2=FALSE);
(cfg->GOAL_SENT=FALSE);
(cfg->Check_Reception1) = getFromMaster1(cfg);
printf("\n Check1... %d \r\n",
cfg->Check_Reception1 );
for (i = 0; i < TWO_TIMES; i++){
while( (cfg->Check_Reception1) == FALSE )
(cfg->Check_Reception1) = getFromMaster1(cfg);
printf("\n Check2... %d \r\n",
cfg->Check_Reception1 );
tim_suspend_task(50);
(cfg->Check_Reception1=FALSE);
}
(cfg->GOAL_SENT = TRUE);
printf("(%d, %d) ----> (%d, %d)\r\n",
cfg->Xrobot, cfg->Yrobot, g->X, g->Y );
}
A.8 Ciclo de atualizacao de cada Robo
(cfg->Check_Reception2=FALSE);
(cfg->VALIDATE_DATA_RECEPTION=FALSE);
/* ********************************** */
(cfg->count)++;
printf("cfg->count: %d \r\n " EOL, cfg->count);
-106- Plataforma de Testes para Sistema Multi-Robo(MRS)
A.8. Ciclo de atualizacao de cada Robo
(cfg->Check_Reception2) = getFromMaster1(cfg, g);
(cfg->Check_Reception2=FALSE);
(cfg->VALIDATE_DATA_RECEPTION=FALSE);
/* ********************************** */
Plataforma de Testes para Sistema Multi-Robo(MRS) -107-
Apendice B - Sistema dinamico
B.1 Conceitos basicos
A arquitetura de controlo utilizada que permite que cada robo navegue de forma a que seja
possıvel, proceder a formacao geometrica definida previamente pelo utilizador, segue uma abor-
dagem de atratores dinamicos nao lineares e encontra-se inicialmente apresentada por Monteiro
e Bicho [32], e posteriormente desenvolvida em [26, 33].
Resumidamente e de forma simplista, esta arquitetura assenta num sistema dinamico que e
utilizado para a modelacao do comportamento do robo, sendo esta modelacao efetuada atraves
de um vetor de variaveis de estado, isto e, variaveis que descrevem de forma matematica o
estado do sistema dinamico. Assim, a disposicao dos robos e a sua permanencia em formacao
e, obtida seguindo uma abordagem baseada em pontos fixos do sistema dinamico, ou seja,
valores da variavel de estado para o qual, o sistema nao se move, isto e, um estado fixo que nao
varie com o tempo. Uma vez atingido este estado, por parte do sistema dinamico, este manter-
se-a nele para sempre. Desta forma, ao utilizar esta abordagem dota o sistema de mais robustez
contra perturbacoes.
A arquitetura de controlo utilizada e do tipo lıder-seguidor, ja explanada anteriormente.
Portanto, e em primeiro lugar, e necessario averiguar acerca da estabilidade destes pontos
fixos, de modo a conhecer o comportamento do sistema dinamico. Neste sentido, estes pontos
fixos podem ser classificados em tres categorias: assimptoticamente estaveis, marginalmente
estaveis ou instaveis [35]. Assim sendo, e de modo a encontrar a localizacao dos pontos fixos
do sistema dinamico, procede-se a resolucao da equacao:
φp f ∈ IR :
∣∣∣∣dφi(t)dt
∣∣∣∣φ=φp f
= fi(φp f ) = 0 (1)
Uma vez encontrados os pontos fixos, o proximo passo e verificar a estabilidade dos pontos
fixos. Desta forma, resolve-se:
dφi(t)dt
= f’i(φi) = 0 (2)
m = |f’i(φi)|φ=φp f= 0 (3)
109
B.1 Conceitos basicos
Sendo que:
⇒
⎧⎪⎨⎪⎩
m < 0 , φp f e assimptoticamente estavel
m > 0 , φp f e marginalmente estavel
m = 0 , φp f e instavel
(4)
Por outras palavras, φp f e instavel se, para valores de φ perto de φp f , o sistema desloca-
se para longe de φp f ; φp f e assimptoticamente estavel, se para valores perto de φp f o sistema
converge para φp f ; e por ultimo, φp f e marginalmente estavel se, para valores proximos de φp f ,
o sistema mantem-se perto de φp f , mas nao converge para φp f .
−∗−Assim, tendo como objetivo a constituicao de formacoes geometricas como comportamento
desejado, sao constituıdos dois comportamentos elementares, de forma a atingir o objetivo final,
no caso, sao constituıdos o comportamento elementar manter formacao e o comportamento
elementar evitar obstaculos. Atraves de um sistema dinamico nao-linear, correspondente a
cada formacao geometrica e da sua bifurcacao, e escolhida a solucao mais indicada a executar.
A seguir apresenta-se a nomenclatura utilizada, em termos dos angulos existentes.
(a) Disposicao em coluna (b) Disposicao em triangulo
(c) Disposicao em linha
Figura 1: Ilustracao da terminologia utilizada nas ordenacoes: (a), (b) e (c)
Deste modo, tem-se para cada uma das tres formas geometricas, o comportamento do robo
definido por duas equacoes diferenciais, onde φi(t) corresponde a orientacao de navegacao do
-110- Plataforma de Testes para Sistema Multi-Robo(MRS)
B.1 Conceitos basicos
robo e vi(t), a sua velocidade de navegacao, com i = robo1, robo2 e robo3.
dφi
dt= fi(φi, parametros) (5)
dvi
dt= fi(vi, parametros) (6)
Assim sendo, tem-se para cada uma das disposicoes de robos um sistema dinamico corres-
pondente ao seu controlo da orientacao e outro para o controlo da velocidade do robo. Um
sistema dinamico que permite implementar o comportamento em coluna e o seguinte:
dφi
dt= fcol,i(φi) =−λcol sin(φi −ψi) (7)
Com ψi a ser a direcao na qual o seguidor ve o lıder, e o parametro λcol que tem de ser
obrigatoriamente positivo, a representar a forca de atracao do atrator, correspondendo a sua
taxa de relaxacao.
Em termos de velocidade, tem-se:
vi,d =
{v j − (li,d − li)/T2c , li ≥ li,d−v j − (li,d − li)/T2c
(8)
Onde T2c e um parametro controla a aceleracao e a desaceleracao do robo.
Na formacao em triangulo, e necessario que ambos os robos seguidores se encontrem numa
posicao obliqua (45o), relativamente ao robo lıder, mantendo a sua distancia e orientacao constante,
relativamente a este. Para esse fim, e implementado o seguinte sistema dinamico, com duas
contribuicoes:
dφi
dt= foblique(φi) = fattract(φi)+ frepel(φi) (9)
Onde:
fk(φi) =−λobliqueλk(li)sin(φi −ψk) (10)
Sendo k = atrator, repulsor.
Em f emerge um atrator na direcao de ψattract , aumentando a sua forca de atracao do seu
atrator, a medida que a distancia entre os robos aumenta (li). Sendo:
ψattract = ψi +Δψi,d −π/4 (11)
Com,
λattract(li) = 1/(1+ exp(−(li − li,d)/µ). (12)
A segunda contribuicao e dada por um atrator, na direcao oposta ao movimento do lıder,
Plataforma de Testes para Sistema Multi-Robo(MRS) -111-
B.1 Conceitos basicos
sendo a sua forca de atracao menor, a medida que a distancia entre robos aumenta (li). A sua
forca de atracao e erigida na direcao de ψrepel e e obtida pela seguinte formula:
ψrepel = ψi +Δψi,d +π/4 (13)
Com,
λrepel(li) = 1−λattract(li). (14)
A velocidade e controlada da mesma forma que na formacao em coluna. Em suma, quando
os robos se encontram com uma distancia maior que a ideal, a forca do atrator na direcao de
ψattract e maior que a forca do atrator na direcao de ψrepel , convergindo o robo de acordo com
a direcao do robo lıder. Caso contrario, se a sua distancia relativamente com o robo lıder for
menor que a ideal, a forca de atracao na direcao de ψrepel, e maior que a forca de atracao na
direcao de ψattract , movendo-se o robo de forma a se afastar do robo lıder. Quando a distancia
entre robos e a ideal, as duas forcas de atracao tem o mesmo valor, convergindo o robo na
direcao ψi,d = ψi +Δψi,d .
Na formacao em linha, o sistema dinamico implementado e, em tudo e semelhante ao im-
plementado para a formacao em triangulo, a unica diferenca reside no fato de Δψi,d tomar o
valor fixo de ±π/2, consoante o robo seguir a direita, ou a esquerda do robo lıder.
A velocidade e controlada da seguinte forma:
vi,d,line = DE1.v j(1−|sin(ψi)|)+DE2.v j(1−|cos(ψi)|)+AC1.v j(1+Kv|sin(ψi)|)+AC2.v j(1+Kv|cos(ψi)|)
(15)
Onde DE1, DE2, AC1 e AC2 sao variaveis logicas, mutuamente exclusivas, que dizem se o
robo deve desacelerar (DE1 e DE2) ou acelerar (AC1 e AC2).
−∗−
-112- Plataforma de Testes para Sistema Multi-Robo(MRS)