paulo filipe pereira do vale plataforma de testes para...

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

-iv- Plataforma de testes para sistema multi-robo(MRS)

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

-vi- Plataforma de testes para sistema multi-robo(MRS)

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

-viii- Plataforma de testes para sistema multi-robo(MRS)

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

Indice

-xii- Plataforma de testes para sistema multi-robo(MRS)

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

Indice

-xiv- Plataforma de testes para sistema multi-robo(MRS)

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


coletivo de 160 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63



coletivo de 320 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65


coletivo de 320 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65



coletivo de 640 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


coletivo de 640 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


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




coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70


coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70






-xvi- Plataforma de testes para sistema multi-robo(MRS)

Lista de Figuras


coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73


coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73







coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76


coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76





efetiva do robo2 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78


coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79


coletivo de 80 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

1 Ilustracao da terminologia utilizada nas ordenacoes . . . . . . . . . . . . . . . 110

Plataforma de testes para sistema multi-robo(MRS) -xvii-

Lista de Figuras

-xviii- Plataforma de testes para sistema multi-robo(MRS)

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

Lista de Tabelas

-xx- Plataforma de testes para sistema multi-robo(MRS)

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


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


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.



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.


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


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


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/


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


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)


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.


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


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.


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/


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


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-



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/



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



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



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.



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.


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.



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,



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



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-



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.


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


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


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



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.



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



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



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



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.



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




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



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.



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


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.


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.



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.



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



• Formacao oblıqua

⇒ Posicao Inicial: (X,Y) → (510, 585) 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



2. Com obstaculos





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







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.



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





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


4.2. Analise e discussao dos resultados





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,



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



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.



• 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ção23: 1.7153 mmErroPosição12Max: 60.93 mm

ErroPosição13Max: 53.42 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



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.

−∗−



• 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







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º



AngReal12AngReal13AngReal23AngDej12 = AngDej23 = AngDej13 = 0º

Figura 4.13: Angulo Inter-robo ao longo do tempo na topologia em coluna



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.

−∗−



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.



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



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]


ErroPosição2Max

: 224.07 mm

ErroMédio

: 15.03 mm


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



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


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 ≈



0 5 10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

Nº Amostras

|Err

o| [m

m]


ErroPosição1Max

: 61.777 mm

ErroMédio

: 25.911 mm


0 10 20 30 40 50 600

5

10

15

20

25

30

35

40

45

50

Nº Amostras

|Err

o| [m

m]


ErroPosição2Max

: 47.479 mm

ErroMédio

: 10.105 mm


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



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


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,



0 5 10 15 20 25 30 35 400

100

200

300

400

500

600

Nº Amostras

|Err

o| [m

m]


ErroPosição1Max

: 551.77 mm

ErroMédio

: 67.117 mm


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]


ErroPosição2Max

: 97.529 mm

ErroMédio

: 15.616 mm


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-



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


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.



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]


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.



0 5 10 15 20 25 30 35 40 450

20

40

60

80

100

120

Nº Amostras

|Err

o| [m

m]


ErroPosição1Max

: 113.88 mm

ErroMédio

: 15.754 mm


0 10 20 30 40 50 60 700

20

40

60

80

100

120

140

160

180

Nº Amostras

|Err

o| [m

m]


ErroPosição2Max

: 173.18 mm

ErroMédio

: 28.381 mm




4.2.5.2 Com obstaculos - Master


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.



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]



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]





0 5 10 15 20 25 30 35 400

10

20

30

40

50

60

Nº Amostras

|Err

o| [m

m]


ErroPosição1Max

: 54.254 mm

ErroMédio

: 13.8 mm


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]


ErroPosição2Max

: 82.662 mm

ErroMédio

: 18.391 mm




4.2.5.3 Com obstaculos - Normal



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.



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]



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]





0 10 20 30 40 50 60 70 800

10

20

30

40

50

60

70

80

Nº Amostras

|Err

o| [m

m]


ErroPosição1Max

: 73.189 mm

ErroMédio

: 17.211 mm


0 10 20 30 40 50 600

10

20

30

40

50

60

Nº Amostras

|Err

o| [m

m]


ErroPosição2Max

: 50.977 mm

ErroMédio

: 14.555 mm




4.2.5.4 Com obstaculos - Slave



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.

−∗−



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]



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]





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]


ErroPosição1Max

: 10.43 mm ErroMédio

: 5.3476 mm


0 10 20 30 40 50 600

50

100

150

200

250

300

350

400

450

500

Nº Amostras

|Err

o| [m

m]


ErroPosição2Max

: 461.65 mm

ErroMédio

: 41.015 mm




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



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.

−∗−


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.


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.


5.2. Sugestoes para trabalho futuro


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.


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.


Bibliografia


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");


}

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 ************ */




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]);




cfg->Xrobot = MM2PAM( cfg->Auxiliar_X );

printf("cfg->Xrobot (Pam): %d \r\n " EOL, cfg->Xrobot);



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");

/* *********************************** */



cfg->Auxiliar_X3 = ( buffer1[10] );



cfg->Xrobot3 = MM2PAM( cfg->Auxiliar_X );

cfg->Auxiliar_Y3 = ( buffer1[11] );


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->Xrobot2 = MM2PAM( cfg->Auxiliar_X );

cfg->Auxiliar_Y2 = ( buffer1[8] );


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] );



(cfg->Actual_Reception_Time) = (

cfg->Reception_Time) * 0.10;

printf("cfg->Actual_Reception_Time (sec): %f \r\n " EOL,

cfg->Actual_Reception_Time);

/* *********************************** */


/* release resources */

tim_unlock();

}

/* ************Default**************** */

else{

printf("\n\rWaiting for data (#1)... \n\r");


}

}

else{

printf("\n\rWaiting for data (#1)... \n\r");


}

/* *****************End*************** */

for (i = 0; i < (buffer1[1]); i++)

buffer1[i] = 0;

return (cfg->VALIDATE_DATA_RECEPTION);

}


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[6] = ( cfg->Yrobot >> 0 ) & 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;


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[6] = ( cfg->Yrobot >> 0 ) & 0xFF; //

buffer[7] = ( cfg->Yrobot >> 8 ) & 0xFF; // 2os oito bytes



buffer[10]= (uint8) rint( true_v_cm * 4); // vMaster

while( (cfg->Phi) > (2*M_PI) )

(cfg->Phi)=REDUCE_ANGLE(cfg->Phi);


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]);


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);


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,


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] );


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



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");

}


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) );

}




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]);


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 ) )

{


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);

}


A.8. Ciclo de atualizacao de cada Robo

void syncMaster(struct goal *g, struct config *cfg)

{

integer i = 0;

(cfg->Check_Reception1=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 );



}

(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->VALIDATE_DATA_RECEPTION=FALSE);

/* ********************************** */

(cfg->count)++;

printf("cfg->count: %d \r\n " EOL, cfg->count);



(cfg->Check_Reception2) = getFromMaster1(cfg, g);


(cfg->VALIDATE_DATA_RECEPTION=FALSE);

/* ********************************** */


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


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



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,



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).

−∗−


paulo filipe pereira do vale plataforma de testes para...

Documents