Comunicacao Robos Moveis

INSTITUTO TECNOLÓGICO DE AERONÁUTICA
Rafael Rabelo de Carvalho
Uma técnica local para manutenção de eficiência de

comunicação em redes ad hoc de robôs móveis
Trabalho de Graduação
2013
Eletrônica
CDU: 681.327.8
Uma técnica local para manutenção de eficiência de comunicação

em redes ad hoc de robôs móveis
Orientador
Prof. Dr. Carlos Henrique Costa Ribeiro (ITA)
Co-orientador
Prof. Dr. Lorenzo Sabattini (UNIMORE)
Divisão de Engenharia Eletrônica
SÃO JOSÉ DOS CAMPOS

INSTITUTO TECNOLÓGICO DE AERONÁUTICA
2013
Dedico este trabalho a minha família,
namorada e amigos da faculdade, sem o
apoio de vocês nada disso seria possível.
Agradecimentos
Primeiramente, agradeço a Deus pelo dom da vida e inteligência, permitindo que eu

vencesse mais essa importante etapa na minha vida.
Aos meus familiares, que sempre me apoiaram com muito amor em todas as minhas
escolhas, independentemente da distância e da saudade que isso pudesse gerar. Por serem
verdadeiros suportes da minha busca constante pelos meus sonhos.
Aos meus colegas de quarto, Orlando Lustosa, Antônio César, Bruno Lima, João Paulo
de Podestà e Olaf Palmer, que me permitiram ter uma convivência harmoniosa e muito
me incentivaram a buscar constantemente a excelência acadêmica.
Aos meus colegas da Pastoral da Juventude da Paróquia Nossa Senhora do Loreto, que
foram grandes amizades e muito me confortavam em momentos de dificuldade durante a
minha trajetória acadêmica.
A todos os meus professores do ITA, que sempre se esforçaram em passar o seu conhe-
cimento de forma clara e profunda, contribuindo significativamente na minha formação
acadêmica. Dou aqui destaque especial àqueles que marcaram de alguma forma a minha
trajetória por essa instituição: Tânia Rabello, Carlos Alonso, Roberto Kawakami e José
Lacava. Não poderia deixar de destacar também o professor Armando Gouveia, que foi
um grande conselheiro, sempre aberto a me ouvir e me incentivar nas minhas escolhas
acadêmicas e profissionais.
Por fim, agradeço em especial ao professor Carlos Henrique Costa Ribeiro por ter me
apresentado a proposta deste trabalho e por ter muito bem me orientado durante todo
esse ano. Deixo também os meus agradecimentos ao engenheiro Vinicius Battagello por
ter me acompanhado durante esse ano, ajudando na concepção desse trabalho.
“Que os esforços desafiem as impossibilidades,
lembrai-vos de que as grandes coisas do homem
foram conquistadas do que parecia impossível.”
— Charles Chaplin
Resumo
Redes ad hoc-to-backbone móveis são uma importante configuração de rede, na qual os
dispositivos podem se deslocar livremente e servir de roteadores para transmissão de dados
de um nó origem até o seu destino final. A presença do Backbone permite que todos os nós
conectados a ele também o estejam entre si, garantindo a conectividade da rede. Porém, essas
conexões apresentam um consumo de energia maior para os nós da rede, de tal modo que é sempre
mais econômico buscar informações da vizinhança. E com o intuito de otimizar a quantidade
de acessos ao Backbone, foi desenvolvido o algoritmo LSWTC, que altera dinamicamente tais
conexões baseado apenas em informações locais.
No presente trabalho, buscou-se estudar o algoritmo LSWTC e implementá-lo em um si-
mulador de robôs móveis, para melhor entender como as interações físicas entre os agentes e
o ambiente influenciam no seu ganho de performance de comunicação. Para tanto, grandezes
como raio de transmissão, largura de simulação e distância mínima de aproximação apresenta-
ram um importante papel para identificar a eficiência do LSWTC em aproximar a configuração
da rede de robôs em uma rede Small-World. Os resultados experimentais demonstraram que
não somente o modelo de mobilidade escolhido tem a sua influência no ganho de Clustering Co-
efficient, mas também o algoritmo de desvio apresenta um importante papel. Por fim, conclui-se
que o LSWTC cumpre bem o seu papel, independentemente dos nós serem robôs móveis ou
não, restando saber como otimizar os seus parâmetros físicos para se obter o ganho máximo de
performance de comunicação da rede em estudo.

Abstract
Backbone assisted ad hoc networks are an important network configuration, whose nodes
could move arbitrarily and serve as routers for data transmission from one node to its destiny.
In addition, network connectivity is assured by Backbone links. Nevertheless, these connections
cost much more energy to the nodes, which means it is always an advantage to acquire data from
their neighborhood. And to optimize the amount of Backbone links over time, LSWTC algorithm
has been developed to dynamically change theses connections based only and exclusively on local
data.
In the present work, LSWTC was either studied and implemented into a mobile robots
simulator. The main goal was to understand the influences of physical interactions over commu-
nication performance of this algorithm. Parameters like transmission range, simulation width
and minimum approach distance were analyzed to understand how they affect LSWTC capabi-
lity of transforming network topology into a Small-World one. Empirical outcomes has shown
that not only mobility model, but also the collision avoidance algorithm have important role in
Clustering Coefficient gains. To sum up, it is possible to affirm LSWTC meets its expectations
even in a mobile robots simulator.

Lista de ilustrações
Figura 1 – Ilustração de uma rede ad hoc conectada . . . . . . . . . . . . . . . . . 21

Figura 2 – Ilustração de uma rede ad hoc-to-backbone [15] . . . . . . . . . . . . . 22
Figura 3 – Distribuição de nós e conexões de redes regulares, small world e aleatórias 24

Figura 4 – Decisão entre u e v para saber se a remoção de (u, v) incrementa o
cluster coefficient local para ambos os nós. [17] . . . . . . . . . . . . . 27
Figura 5 – Reduzindo o número de links conectados ao backbone; agrupamento k-
hop permite mais controle das conexões ao Backbone do que a versão
clássica com vizinhos 1-hop [17] . . . . . . . . . . . . . . . . . . . . . . 30
Figura 6 – Robôs real e sua versão simulada . . . . . . . . . . . . . . . . . . . . . 37

Figura 7 – Simulador Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 8 – Simulação de um hospital altamente povoado no Stage . . . . . . . . . 39
Figura 9 – Simulação em perspectiva no Stage . . . . . . . . . . . . . . . . . . . . 39
Figura 10 – Configuração Inicial dos robôs . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 11 – Modelo de robôs [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 12 – Movimentação aleatória dos robôs . . . . . . . . . . . . . . . . . . . . . 43
Figura 13 – Simulação com n = 130 sem algoritmo de desvio . . . . . . . . . . . . . 43
Figura 14 – Aproximação de dois robôs a uma distância dmin = 3 . . . . . . . . . . 44
Figura 15 – Caracterização dos pesos dos robôs na biblioteca Libgosu . . . . . . . . 45
Figura 16 – Simulação utilizando a biblioteca Libgosu . . . . . . . . . . . . . . . . 46
Figura 17 – APL com LSWTC e dmin variando de 0 a 5 . . . . . . . . . . . . . . . 49

Figura 18 – CC com LSWTC e dmin variando de 0 a 5 . . . . . . . . . . . . . . . . 49
Figura 19 – APL com LSWTC e k variando de 2 a 7 . . . . . . . . . . . . . . . . . 51
Figura 20 – CC com LSWTC e k variando de 2 a 7 . . . . . . . . . . . . . . . . . 51
Figura 21 – Modelo de robôs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 22 – APL com LSWTC e k variando de 2 a 5 . . . . . . . . . . . . . . . . . 53
Figura 23 – CC com LSWTC e k variando de 2 a 5 . . . . . . . . . . . . . . . . . 53
Figura 24 – APL sem LSWTC e k variando de 2 a 5 . . . . . . . . . . . . . . . . . 55
Figura 25 – CC sem LSWTC e k variando de 2 a 5 . . . . . . . . . . . . . . . . . . 56
Figura 26 – Comparação APL para d = 5 . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 30 – Comparação CC para d = 5 . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 33 – Comparação CC para d = 11 . . . . . . . . . . . . . . . . . . . . . . . 59
Lista de tabelas
Tabela 1 – Valores de densidades para l = 30 . . . . . . . . . . . . . . . . . . . . . 48

Tabela 2 – Valores de densidades para l = 20 . . . . . . . . . . . . . . . . . . . . . 48
Tabela 3 – APL, CC e número de clusterheads para k = 2 . . . . . . . . . . . . . 54
Lista de abreviaturas e siglas
APL Average Path Length
CBTC Cone-Based Topology Control
CC Clustering Coefficient
CT Controle de Topologia
JiST Java in Simulation Time
KHOPCA K-hop Clustering Coefficient
LMST Local Minimum Spanning Tree
LSWTC Local Small-World Topology Control Algorithm
ROS Robot Operation System
RR Reckful Roaming
SW Small-World
SWANS Scalable Wireless Ad hoc Network Simulator
USC University of Southern California

Lista de símbolos
d(u, v) Distância entre os nós u e v
n Número total de nós da rede
d Densidade da rede
dmin Distância mínima de aproximação permitida entre dois robôs
l Largura da área de simulação
r Raio de transmissão dos robôs
k Número máximo de saltos até um clusterhead
kK Peso máximo permitido a um nó
euv Aresta que liga os nós u e v
Ni Vizinhança do nó i
CCi Clustering Coefficient Local para o nó i
CC Clustering Coefficient Global
W (N (v)) Conjunto de pesos da vizinhança de v
O(n) Complexidade da Mensagem
Ginit Topologia da rede em estudo antes do LSWTC
GRR Topologia da rede em estudo após aplicação do RR
GKHOP CA Topologia da rede em estudo após aplicação do KHOPCA
GF inal Topologia da rede em estudo após o LSWTC

Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2 Plano de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Modelo do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Grafo de comunicação ad hoc . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Grafo de comunicação ad hoc-to-backbone . . . . . . . . . . . . . . . . . . 21
3 Algoritmo LSWTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Redes Small-World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Average Path Length . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Clustering Coefficient . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Otimização do Clustering Coefficient: Reckful Roaming . . . . . . . . . . . 27
3.3 Otimização da Average Path Length: K-hop Clustering Algorithm . . . . . 30
3.4 Protocolo LSTWC - Atuação conjunta Reckful Roaming e K-hop Cluste-
ring Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1 Sincronização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2 Complexidade da Mensagem (O(n)) . . . . . . . . . . . . . . . . . . 34
4 Modelo de simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Configuração Player/Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Informações Básicas . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.2 Modelo de Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.3 Algoritmo de Desvio . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Biblioteca Libgosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5 Resultados das Simulações . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.1 Resultados da simulação para l = 30, r = 10 . . . . . . . . . . . . . . . . . 48
5.1.1 Estudo de dmin para k = 4 . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.2 Estudo de k para dmin = 2.5 . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Resultados da simulação com/sem LSWTC com l = 20, r = 5, dmin = 2.5 . 52
5.2.1 Estudo de k para dmin = 2.5 . . . . . . . . . . . . . . . . . . . . . . 53
5.2.2 APL e CC sem LSWTC, com dmin = 2.5 e clusterheads fixos . . . . 54
5.2.3 Comparação resultados Random e LSWTC . . . . . . . . . . . . . . 55
6 Conclusões e Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . 60

6.1 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
APÊNDICE A Arquivos Player/Stage . . . . . . . . . . . . . . . . . . . . 64

A.1 map.inc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.2 bigbob.inc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.3 simulation.rb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.4 bigbob.rb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.5 empty.rb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.6 clusterhead.rb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
APÊNDICE B Arquivos Libgosu . . . . . . . . . . . . . . . . . . . . . . . 77

B.1 circle.rb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.2 constants.rb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
B.3 teste.rb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
17
1. Introdução
A desenvolvimento da transmissão via wireless e o advento do uso de dispositivos

eletrônicos móveis permitiu acreditar que é possível estar conectado em qualquer parte
do mundo e em qualquer momento.. Redes Ad Hoc tornam-se uma boa alternativa para
satisfazer esse anseio. As redes Ad Hoc consistem de um conjunto de dispositivos mó-
veis operando independentemente de uma estrutura física central administradora. Basi-
camente um conjunto de elementos com movimentação aleatória e conectados entre si.
Devido às limitações de potência e utilização de canal, um dispositivo host (clusterhead)
pode não se comunicar diretamente com os demais com apenas um link de distância (1-
hop). Nesse caso, um cenário multi-hop é desejado, no qual os pacotes precisam passar
por nós intermediários antes de chegarem ao seu destino final.
Embora a comunicação militar para formação tática é ainda considerada a primeira

aplicação para as redes wireless Ad Hoc, interesses comerciais nessa área continuam em
ascensão. Apesar desse crescente estudo, ainda existem diversos desafios técnicos relaci-
onados às redes Ad Hoc. A sua topologia é altamente dinâmica e mudanças frequentes
são difíceis de se prever. Com a utilização de links wireless, a rede sofre com altas taxas
de perda de informação, podendo experimentar grandes atrasos e ruídos. Não se pode
desconsiderar que as redes Ad Hoc são a base de bateria (dispositivos móveis), portanto
a economia de energia tem importância fundamental na construção e exploração dessas
redes.
Para restringir o número de saltos entre o nó fonte e o destino final, bem como garantir
a total conexão da rede Ad Hoc, é possível adicionar um Backbone, nada mais do que uma
camada de comunicação externa, porém de custo maior. O Backbone garante que todos
os nós ligados a ele estejam diretamente conectados, permitindo que a rede se mantenha
totalmente conectada. Do ponto de vista de restrição de energia, não compensa que todos
Capítulo 1. Introdução 18
os nós se comuniquem com o Backbone diretamente, devendo esses darem preferência

sempre para a transmissão de dados peer-to-peer. Por outro lado, a comunicação wireless
tem seus percalços como citado anteriormente, ou seja, o número de saltos entre o nó fonte
e o destino final deve ser restrito de tal forma a garantir a transmissão da informação com
uma baixa taxa de erro e um pequeno atraso. Com isso, o que deve ser buscado é uma
relação de compromisso entre nós conectados ao Backbone e máximo número de saltos
entre fonte e destino, de tal forma a se construir uma topologia eficiente.
1.1 Objetivos
Este trabalho tem por finalidade apresentar um algoritmo de otimização da topologia
para redes Ad-Hoc-Backbone (LSWTC) em um ambiente de simulação de robôs reais
(Player/Stage), com o intuito de estudar as cntribuições de interações físicos sobre a
eficiência do LSWTC.
1.2 Plano de Trabalho

O primeiro passo foi estudar os conceitos de redes ad hoc-to-backbone e do algo-
ritmo LSWTC. A partir disso, buscou-se na literatura algum simulador de robôs que
pudesse compartilhar um ambiente gráfico e fosse de fácil utilização. Como sugestão ini-
cial, estudou-se o Java in Simulation Time / Scalable Wireless Ad hoc Network Simulator
(JiST/SWANS), porém, a carência de um ambiente para simular robôs físicos, bem como
a falta de familiaridade com a linguagem, fez com que fosse descartado. Como segunda
opção, estudou-se o Robot Operating System (ROS), esse, por sua vez, apresentava um
ambiente gráfico para simular robôs de alto nível, porém, carecia de uma documentação
e bibliotecas para executar uma rede de robôs, como desejado.
Pelas suas características mais próximas de um simulador de robô real, o ROS foi
escolhido. Devido a incompatibilidade do sistema operacional, optou-se por utilizar a
máquina virtual de Linux - Ubuntu 12.0.4 que já vinha com a sua versão Groovy instalada.
Porém, ao estudar a biblioteca Stage para simulações 2D de redes de robôs, percebeu-se
que a sua documentação era muito mais extensa quando utilizada conjuntamente com o
controlador Player, diferentemente do ROS. O Player, por sua vez, também foi projetado
Capítulo 1. Introdução 19
para funcionar em Linux, podia ser programado em C, C++, Python, Ruby e Matlab e
apresentava um ambiente completo necessário para o desenvolvimento deste projeto.
Com o ambiente computacional configurado, optou-se por utilizar a linguagem Ruby.

A partir disso, implementou-se no Player/Stage o algoritmo LSWTC a partir de um
modelo de mobilidade baseado no Random Waypoint.
Devido a algumas limitações da biblioteca Stage com respeito ao seu ambiente gráfico,
buscou-se na literatura uma outra solução que permitisse uma melhor visualização dos
resultados do LSWTC. Por fim, escolheu-se a biblioteca Libgosu para implementar um
novo simulador gráfico. Com essa última ferramenta, foi possível concluir o presente
trabalho e realizar as análises necessárias.
1.3 Estrutura do trabalho

No Capítulo 1, foi realizada uma introdução ao tema desse trabalho, bem como os
objetivos, o plano de trabalho efetuado e a descrição de sua estrutura.
No Capítulo 2, a idéia é apresentar um modelo matemático para redes wireless Ad hoc

e Ad hoc-to-Backbone a partir da teoria de grafos.
No Capítulo 3, será apresentado a teoria de redes Small-World, com enfoque nos

conceitos de Cluster Coefficient e Average Path Length. Além disso, serão enunciados os
algoritmos K-hop Clustering Algorithm e Reckful Roaming. Por fim, o algoritmo LSWTC,
base desse trabalho, será apresentado
No Capítulo 4, será apresentado todo o processo de instalação e configuração dos am-

bientes computacionais requeridos para simular o algoritmo LSWTC. Todas as premissas,
passos de simulação e pré-requisitos serão bem ilustrados nesse capítulo.
No Capítulo 5, serão apresentados os resultados das simulações do algoritmo LSWTC

para Redes ad hoc de robôs móveis.
No Capítulo 6, serão apresentadas as conclusões e as sugestões para trabalhos futuros

na área.
20
2. Modelo do sistema
Uma rede wireless consiste basicamente de um conjunto de dispositivos ou sensores

conectados por links sem fio. Através do uso de tecnologias como Bluetooth e Wi-Fi, esses
dispositivos são capazes de criar links de comunicação dentro de seu raio de transmissão.
Nessa linha de raciocínio, pode-se definir as redes ad hoc, que nada mais são do que
redes wireless nas quais os nós podem se mover livremente e atuar como roteadores para
prover comunicação sem fio. Devido a mobilidade dos nós dentro do seu ambiente, a sua
topologia representa um ponto crucial quanto os quesitos de performance e conectividade.
O controle da topologia de redes ad hoc é geralmente baseado no ajuste da potência

de transmissão, que é realizado pelo controle de quais links serão incluídos ou retirados
da rede para atingir o objetivo desejado (redução de interferência, redução do consumo
de energia, aumento da capacidade efetiva da rede, etc). As técnicas de controle são
centralizadas ou distribuidas. Para algoritmos centralizados de controle de topologia, uma
entidade principal computa a potência de transmissão usando a posição de cada nó com
o objetivo de garantir um arranjo com forte conectividade. Nos algoritmos distribuídos,
os nós móveis ajustam a sua potência de transmissão de acordo com informações locais
para manter um número desejável de vizinhos conectados.
Um segundo ponto fundamental na análise de redes ad hoc é a sua conectividade.

Uma rede ad hoc é dita conectada se, e semente se existe pelo menos um caminho que
liga cada par de nós móveis. Portanto, a conectividade da rede é afetada por mudanças
na sua topologia provenientes da mobilidade de seus nós: quebra de links, atualizações de
rotas entre nós, etc. Porém, em uma rede dinâmica, onde todos os nós tem mobilidade
total no seu espaço definido, como garantir que todos estejam a uma distância mínima
uns dos outros de tal forma a manter a rede conectada?
Uma possível solução para esse problema da conectividade foi a inserção de um Back-
Capítulo 2. Modelo do sistema 21
Figura 1: Ilustração de uma rede ad hoc conectada
bone às redes Ad hoc. O backbone nada mais é do que uma rede externa, a qual alguns
nós estão conectados, de tal forma a garantir a comunicação entre nós distantes a um
custo e consumo de energia maiores. Dessa forma, nós isolados que tiverem acesso ao
Backbone ainda conseguiram se comunicar com os demais.
2.1 Grafo de comunicação ad hoc

O grafo que bem representa matematicamente uma rede ad hoc é bem definido a
seguir.
Seja V ∈ R2 um conjunto de nós uniformemente distribuídos em uma região bi-

dimensional quadrada de lado l. O grafo simétrico G = (V, E), tal que para qualquer par
u, v ∈ V de nós cuja distância dist(u, v) ≤ r =⇒ u, v ∈ E e dist(u, v) > r =⇒ u, v ∈
/E
é chamado de grafo de disco r. E esse grafo de disco r define matematicamente o grafo
da rede comunicação Ad hoc entre os seus dispositivos móveis.
2.2 Grafo de comunicação ad hoc-to-backbone

Para a construção de redes Ad hoc-to-backbone, uma possível alternativa seria inserir
adaptadores GSM/UMTS de tal forma a garantir a construção dos links de Backbone.
Devido ao seu alto custo e consumo de energia, conectar muitos dispositivos diretamente
Capítulo 2. Modelo do sistema 22
ao Backbone pode sobrecarregá-lo. Portanto essas conexões devem ser minimizadas.
Figura 2: Ilustração de uma rede ad hoc-to-backbone [15]
Um link de Backbone é definido como um link (u, v) entre os nós u e v, onde u ∈

/ E.
Esse link conecta dois nós que não estão na mesma vizinhança, ou seja, não estão dentro
raio de transmissão.
Por fim, todos os dispositivos conectados ao Backbone são considerados totalmente

conectados. No contexto das redes de comunicação Ad hoc e do presente trabalho, um
link de backbone será contado igualmente a um link entre dois nós vizinhos de outra
natureza (Wi-Fi, Bluetooth, etc).
23
3. Algoritmo LSWTC
A área de Controle de Topologia (CT) busca aumentar a eficiência da operação da rede

a partir da otimização da vida útil da bateria, reduzindo interferências e ruídos, tudo isso
a partir do controle da formação física da rede. Com esse objetivo, diversos protocolos
foram elaborados.
O protocolo LMST (Local Minimum Spanning Tree) busca determinar o menor raio
em que todos os nós da rede ainda estejam conectados. Ele aproxima uma árvore de
espalhamento com conhecimento local a partir do algoritmo de Prim. A sua mensagem
tem complexidade O(n) e, no pior caso, ele consegue garantir a conectividade da rede
Já o protocolo CBTC (Cone-Based Toplogy control) busca minimizar o consumo de

energia ao remover links redundantes, de tal forma a manter a conectividade da rede. O
CBTC divide o ambiente em cones de angulo α que são tecnologicamente detectados por
antenas diretas chamadas de CBTC(α). O CBTC foi extendido para garantir tolerância
a falhas ao mesmo tempo que mantém a rede de ordem k (número máximo de links entre
origem e destino) conectada.
Os algoritmos acima consideram a conectividade como um critério de tolerância a

falhas. Por outro lado, a abordagem de garantir a robustez da rede e a tolerância a falhas
baseadas em manter a sensibilidade da distância média entre os nós e a susceptabilidade
da rede baixas, não é abordada pelos algoritmos de Controle de Topologia.
Uma possível solução para esse problema é aproximar a topologia da rede em questão
a de uma rede Small-World, aumentando a sua robustez e tolerância a falhas, sem perder
a conectividade.
O desafio de inserir as propriedades de redes Small-Worlds em redes móveis ad hoc-to-

backbone é construir um algoritmo que trabalhe somente com informações locais, ou seja,
Capítulo 3. Algoritmo LSWTC 24
cada nó acessando somente os dados da sua vizinhança, porém influenciando propriedades

globais como a Average Path Length e o Clustering Coefficient.
E é com essa proposta que foi elaborado o algoritmo LSWTC (Local Small-World
Topology Control). O LSWTC busca construir, a partir de informações locais, uma rede
robusta e tolerante a falhas através da aproximação a uma rede Small-World. Para tanto,
ele se vale de dois algoritmos: KHOPCA (K-hop Clustering Clgorithm) para otimizar o
número de pontos de acesso ao Backbone; e o RR (Reckful Roaming) que busca otimizar
o Clustering Coefficient global removendo links redudantes.
3.1 Redes Small-World

Uma rede Small-World é um grafo matemático em que a maioria dos nós não estão
conectados, porém, qualquer nó pode ser alcançado através de um número pequeno de
saltos a partir de qualquer outro. Nessa linha de raciocínio, as redes small world são
caracterizadas pela distãncia L entre dois nós quaisquer crescer proporcional ao logaritmo
do número de nós N na rede.
Figura 3: Distribuição de nós e conexões de redes regulares, small world e aleatórias
A predominância do fenômeno Small World em inúmeras redes eficientes, tais como

redes sociais, Internet e sistema nervoso, implica que tal propriedade é uma solução evo-
lutiva para redes locais em crescimento [17]. Essas redes exigem pequenas distâncias para
comunicação entre os seus elementos, em contradição ao seu potencial diâmetro (distância
máxima entre dois nós da rede), porém, ao mesmo tempo, são robustas contra falhas ale-
atórias. Ao integrar essas propriedades em redes de comunicação humanas, drasticamente
observa-se um aumento de eficiência e performance, todavia representa um enorme desafio
no caso de redes Ad hoc, visto que o seu grafo de comunicação confia em princípios locais
de construção.
Redes Small World são caracterizadas por dois importantes atributos, uma pequena
APL (Average Path Length) - média das menores distâncias entre dois nós - e um alto CC
(Clustering Coefficient) - coeficiente de agrupamento. Na área de redes móveis Ad hoc,
uma baixa APL é importante para os mecanismos de roteamento e para a performance
geral da comunicação da rede.
3.1.1 Average Path Length
A APL é um importante conceito em topologia de redes que é definido como a média

do número de saltos para os menores caminhos entre dois nós da rede. Em termos de
transmissão de dados, uma pequena APL favorece um espalhamento mais rápido e eficiente
dentro da rede.
Definição 1. Considere um grafo sem peso G(V, E). Seja d(v1 , v2 ), com v1 , v2 ∈ V , a
menor distância entre v1 , v2 . Assuma que d(v1 , v2 ) = 0 se v1 = v2 ou v2 é isolado de v1 .
Portanto, a APL pode ser definido por:
1 X
AP L = d(vi , vj )
n(n − 1) i,j
, onde n é o número de vértices de G.
3.1.2 Clustering Coefficient
Na teoria de grafos, o CC é uma medida do grau de agrupamento de nós. De uma

forma simplificada, o CC reflete a probabilidade de que dois nós que estejam conectados
tenham um terceiro nó que também esteja conectado a ambos. Dessa forma, é possível
determinar um CC local para cada nó, representando o quão próximo de um clique é o
grafo formado por ele e seus vizinhos. Já o CC global, caracterizado pela média de todos
os CC locais, busca caracterizar o comportamento geral da rede.
Definição 2. Seja um grafo sem peso G = (V, E) com eij a aresta que conecta os vértices
vi e vj . A vizinhança Ni do vértice vi caracterizada pela sua conexão direta.
Ni = {vj |eij ∈ E ∧ eji ∈ E}

Considere ki como o número de vértices de Ni . O Clustering Coefficient local para o

vértice vi pode ser bem definido como a razão entre a quantidade de links em Ni e o número
total de possíveis conexões. Para grafos bi-direcionais, considera-se eij 6= eji , portanto,
para ki vizinhos, espera-se um número máximo de ki (ki − 1) links em Ni . Portanto, o
Clustering Coefficient fica assim definido:
|{ejk |vj , vk ∈ Ni ; ejk ∈ E}|

CCi =
ki (ki − 1)
Já para a sua versão global, basta calcular a média dos Clustering Coefficients locais
para todos os nós que compõem a rede:
n
1X
CC = CCi
n i=1
Uma outra forma de definir o Clustering Coefficient global é a partir do conceito de

triplas - conjunto de três vértices - e triângulos - conjunto de triplas fechadas e conectadas:
3 × numero de triangulos
CC =
numero de triplas conectadas
Para melhor entender os benefícios de um alto Clustering Coefficient em redes de

comunicação, pode-se estudar o problema do espalhamento de doenças em redes Small-
Worlds. Inicialmente, considere uma população de nós na qual uma fração q é suceptível
a doença. Além disso, vale ressaltar que somente essa porção de nós pode transmistir a
doença e também é afetada por ela. Em [10] ilustrou-se que, para que ocorra uma epide-
mia, necessariamente qSmall − W orld >> qrandom. Ao analisarmos as características
das redes Small-Worlds, o seu alto CC permite que a doença se espalhe somente para os
nós susceptíveis que fazem parte da vizinhança do nó que iniciou a doença. Caso a cone-
xão com outros clusters seja feita por nós não susceptíveis, não haverá externalização da
doença, ficando essa restrita somente ao grupo inicial. Com isso, pode-se concluir que as
redes Small-Worlds são robustas quanto a propagação de doenças e, no mesmo raciocínio,
de falhas.
Em uma rede com um alto CC, falhas aleatórias não tendem a incrementar a APL,
portanto tal característica não somente ajuda a manter a APL pequena como também
mais estável. Portanto, muitas vezes, remover certos links da rede, ou seja, recursos de
comunicação, aumenta a robustez da rede.
3.2 Otimização do Clustering Coefficient: Reckful Roaming

Como ilustrado no capítulo anterior, o modelo matemático utilizado para representar
a rede ad hoc-to-backbone é um grafo de disco r. Portanto, os nós detectam seus vizinhos
por estarem dentro do seu raio de transmissão r. E para otimizar o Clustering Coefficient
dessa rede, as únicas operações permitidas na estrutura do grafo é retirar ou deixar o link
de comunicação entre dois nós.
Ao analisar a definição de CC, intuitivamente espera-se que quanto mais links na

vizinhanhça de um nó, melhor será. Porém, no caso onde um novo link não forma um
triângulo (tripla fechada e conectada), é fácil perceber que o número de links na vizinhança
aumenta e consequentemente o CC decresce. E é com esse propósito, verificar a existência
de links redundantes e eliminá-los, que o algoritmo Reckful Roaming vai atuar. A sua
principal função é estudar localmente a distribuição de links entre os nós e seus vizinhos,
de tal forma a encontar os links cuja remoção irá promover um aumento de CC.
Figura 4: Decisão entre u e v para saber se a remoção de (u, v) incrementa o cluster

coefficient local para ambos os nós. [17]
Inicialmente, para determinar se o link (u, v) ∈ E é um bom candidato a ser removido,

calcula o Clustering Coefficient local de u para a configuração original. Depois, retira-se
o nó v da vizinhança de u quebrando o link entre eles e calcula-se novamente o Clustering
Coefficient para esse último. Caso haja um incremento de CC com essa remoção de (u, v),
esse link ainda não é removido de imediato, visto que a sua extinção deve incrementar o CC
de ambos os nós, por hora ele é simplesmente marcado como candidato a ser removido.
Por outro lado, a remoção de (u, v) também é sentida pelos nós vizinhos de u e v, e,
portanto, uma fase de confirmação deve ser levada em consideração para garantir que o
CC global da rede seja, de fato, incrementado.
Na fase de confirmação, ocorre o cálculo recíproco do Clustering Coefficient local. Se

inicialmente calculou-se o CC para o nó u e concluiu-se que o link (u, v) é um candidato
a remoção, agora calcula-se o CC para o nó v e verifica se também há um incremento
no seu Clustering Coefficient. Caso o resultado seja positivo, a fase final do algoritmo
Reckful Roaming é executada, caso contrário, o link (u, v) permanece.
Na última fase, inicialmente será calculado o CC global para a subrede composta

pelas vizinhanças de u e v. Logo após, remove-se o nó u da vizinhança de v e calcula-se
novamente o CC global da mesma subrede, agora com um nó a menos. Caso esse último
resultado seja superior ao primeiro, verifica se a remoção de (u, v) não irá desconectar a
vizinhança de u com a vizinhança de v. Satisfazendo essa última condição, a remoção do
link (u, v) deixará de existir.
Algoritmo 1 Função permit (para o nó v)

1: INPUT: N : Conjunto inicial de nós vizinhos
2: for all k ∈ N (v) do
3: if N (u) ∩ N (k) 6= ∅ then
4: return f alse
5: end if
6: end for
7: return true
Define-se a função permit para bem ilustrar que a remoção do link (u, v) não propor-
ciona uma perda de comunicação entre as vizinhanças de u e v.
Algoritmo 2 Reckful Roaming RRc (para o nó v)

1: INPUT: N : Conjunto inicial de nós vizinhos
2: INPUT: RC: Conjunto de nós candidatos a remoção
3: OUTPUT: NRR : Nós vizinhos finais
|{evu |vu ,vv ∈N ;euv ∈E}|
4: CC(v) = kv (kv −1)
5: RC(v) ← ∅
6: for all u ∈ N do
7: N (v) ← N (v) \ {u}
|{evu |vu ,vv ∈N ;euv ∈E}|
8: CCRC (v) = kv (kv −1)
9: if CCRC (v) > CC(v) then

10: RC(v) ← RC(v) ∪ {u}
11: end if
12: N (v) ← N (v) ∪ {u}
13: end for
14: sendRC(v, RC(v))
15: sendRC(u, RC(u))
16: for all w ∈ RC(v) do
17: if v ∈ RC(w) then
CC(uv) ←
P
18: x∈(N (v)∪N (w)) CC(x)
19: N (v) ← N (v) \ {w}
CCRC (uv) ←
P
20: x∈(N (v)∪N (w)) CC(x)
21: if CCRC (uv) > CC(uv) then
22: if N (v) ∩ N (w) == ∅ then
23: if permit(v) == true then
24: N (v) ← N (v) ∪ {w}
25: end if
26: end if
27: end if
28: end if
29: end for
30: NRR (v) ← N (v)
3.3 Otimização da Average Path Length: K-hop Clustering Al-

gorithm
Ao se falar em otimização da Average Path Length, a principal questão é como limitar
o número de acessos ao Backbone com apenas informações locais, se o próprio Backbone
não tem conhecimento de todos os dispositivos da rede?
Na prática, o KHOPCA separa a rede em clusters de c elementos com c < n. Uma vez
que cada cluster é ligado a um clusterhead, e cada clusterhead serve de ponto de acesso a
rede Backbone, o número de links ao Backbone fica globalmente determinado a partir de
informações locais apenas. A eficiência do KHOPCA é medida pela capacidade de bem
reduzir e adaptar o número de clusters de acordo com o requerimento.
O pior cenário possível é aquele em que todos os nós buscam uma conexão direta com
o Backbone. Por outro lado, um requerimento para garantir a conexão total da rede é ter
pelo menos uma conexão ao Backbone por partição. Como as partições podem ter uma
extensão grande, muitas vezes não será prático administrar tal cenário. Porém, usando
um sistema de agrupamento multi-hop, é possível encontrar uma solução intermediária:
clusters com dispositivos a no máximo k saltos de distância de um clusterhead.
Figura 5: Reduzindo o número de links conectados ao backbone; agrupamento k-hop

permite mais controle das conexões ao Backbone do que a versão clássica com vizinhos
1-hop [17]
Utilizando essa otimização indireta, é possível controlar o número de clusterheads ao

aumentar o tamanho dos clusters. Quanto maior for o tamanho do cluster, menor será a
sua quantidade, e consequentemente, o número de clusterheads.
O KHOPCA consiste basicamente de um conjunto de 4 regras principais que descrevem

as transições entre estados de um nó, somente a partir do conhecimento dos estados do
seus vizinhos (Algoritmo 3).
Inicialmente, para cada nó v ∈ V é escolhido um peso wv entre 0 e k de forma aleatória.

Nesse momento, o nó v tem conhecimento somente do peso dos clusterheads que é igual
a 0 e que existe um número máximo de k saltos de distância a um clusterhead. A única
informação disponível ao nó v é a informação da sua vizinhança N (v) e os seus pesos
W (N (v)). Uma vez inicializada a rede, aplica-se as seguintes regras:
1. O nó copia o menor peso dentre todos os seus vizinhos adicionado de uma unidade.
Essa regra é importante para criar uma estrutura hierárquica na rede.
2. Quando um nó isolado não tem um clusterhead a uma distância de até k saltos, o

seu peso recebe 0 e ele se torna um clusterhead.
3. Quando nós com peso inferior atraem nós vizinhos com um peso maior. Com o
intuito de evitar clusters fragmentados, esses nós sucessivamente incrementam o seu
peso com o objetivo de se conectar ao um cluster pré-existente.
4. Quando dois clusterheads se encontram na mesma vizinhança, de acordo com um

segundo critério como a identificação do nó (ID), um nó permanece com o peso 0,
enquanto o outro recebe um incremento do seu peso em uma unidade.
Algoritmo 3 KHOP CA para o nó v

1: INPUT: N : Conjunto inicial de nós vizinhos {n1 , . . . , n|N | }
2: INPUT: W : Conjunto de pesos dos nós vizinhos {w1 , . . . , w|W | }
3: INPUT: ID: Uma função de ID única para cada nó
4: INPUT: kK : Máximo peso
5: OUTPUT: wv : Novo peso para o nó v
6: if min(W ) < wv (Regra 1) then
7: wv ← min(W ) + 1
8: else if min(W ) = kK ∧ wv = kK (Regra 2) then
9: wv ← 0
10: else if min(W ) ≥ wv ∧ wv 6= 0 (Regra 3) then
11: wv ← wv + 1
12: else if min(W ) = 0 ∧ wv = 0 (Regra 4) then
13: if ID(N (min(W ))) > ID(v) then
14: wv ← wv + 1
15: end if
16: end if
3.4 Protocolo LSTWC - Atuação conjunta Reckful Roaming e

K-hop Clustering Algorithm
O protocolo LSWTC é constituído basicamente por duas partes: (a) RR otimiza o
Clustering Coefficient e (b) KHOPCA busca otimizar a distância média do grafo ajustando
as conexões ao backbone. A atuação conjunta desses dois algoritmos podem ser bem
descrita com as seguintes relações matemáticas:
GRR ← RR(Ginit );
GKHOP CA ← KHOP CA(GRR );
GF inal ← GRR ;
Inicialmente o Reckful Roaming remove os links reduntantes da topologia GInit , re-

sultando na nova topologia GRR . Para múltiplas iterações, a topologia final será, de fato,
GRR , o RR não leva em consideração GKHOP CA . O KHOPCA, por sua vez, não altera a
topologia da rede, pois não remove conexões, ele busca determinar uma estrutura para en-
contrar caminhos eficientes ao clusterhead mais próximo. Vale ressaltar que as mudanças
feitas pelo RR irão afetar os resultados de KHOPCA, pois altera a topologia do sistema,
já a recíproca não é verdadeira.
Outro ponto importante a se destacar é a conectividade do Backbone propriamente

dito. Embora o link de Backbone é considerado semelhante ao link entre dois nós vizinhos,
em uma rede SW, essa conexão ao Backbone é muito mais complexa. Não se pode
desconsiderar a otimização da comunicação da rede Backbone, todavia esse estudo não
faz parte do escopo desse trabalho.
3.4.1 Sincronização
Observe que essa atuação conjunta entre o Reckful Roaming e o K-hop Clustering
Algorithm se dá de forma síncrona, no entanto, os nós não atuam de forma síncrona, visto
que eles não tem conhecimento se a vizinhança já terminou de calcular GRR . Devido a
influência da mobilidade, a topologia da rede é modificada constantemente, gerando um
ambiente fundamentalmente assíncrono.
O KHOPCA somente permite que os nós coletem informações a respeito dos pesos de
seus vizinhos, e, a partir disso, tomar uma decisão a respeito do seu próprio peso. Por
outro lado, quando se observa o resultado gerado pelo RR, comprova-se que ele é muito
mais sensível a assincronizações, uma vez que ele depende do acordo entre nós vizinhos.
Visto que o ambiente é dinâmico com os nós se movimentando aleatoriamente, além

de que o RR depende de informações das vizinhanças de u e v - supondo o link (u, v)
candidato a remoção -, como forma de simplificação, escolhe-se trabalhar em um ambiente
síncrono. Dessa forma, durante intervalos de tempo constantes, aplica-se o algoritmo
LSWTC, de tal forma que a posição de todos os nós seja fixa nesses instantes. Com
isso, a configuração resultante do LSWTC permanece até o próximo clock. Ao tomar
intervalos de clock pequenos, da ordem de milisegundos, é possível aproximar de um
modelo assíncrono e garantir a dinâmica e continuidade da rede.
3.4.2 Complexidade da Mensagem (O(n))
Para sistemas distribuídos, a complexidade da mensagem apresenta uma relevância

superior a complexidade de tempo e espaço. Ela é definida como a quantidade de men-
sagens enviadas em um sistema. Portanto, em um sistema com comunicação wireless,
uma mensagem enviada pelo nó v a todos os seus vizinhos em N (v) conta como 1. Natu-
ralmente, a complexidade da mensagem do protocolo LSWTC consiste da somatória das
contribuições individuais dos algoritmos Reckful Roaming e K-hop Clustering Algorithm.
Assume-se que o tamanho da mensagem é inferior a O(log n) bits, pois já é mais do que
suficiente para codificar toda a informação necessária a ser transmitida entre os nós da
rede.
Como o KHOPCA não requer nenhuma configuração inicial, cada nó pode potencial-
mente escolher qualquer valor entre 0 e k. Portanto, nenhuma transmissão de informação
é requerida nessa etapa. Em um segundo momento, cada nó coleta apenas os pesos de
cada vizinho e compara com o seu próprio, escolhendo a regra adequada. Por isso, pode-se
concluir que a complexidade da mensagem para cada aplicação de KHOPCA sobre a rede
resulta em O(n), sendo n o número total de nós.
A otimização de RR confia na medida do CC, que inerentemente demanda informação

das vizinhanças dos dois nós avaliados. Para o cálculo de tais informações, faz-se neces-
sário a transmissão do ID do nó v a seus vizinhos, bem como da lista de potenciais links
para remoção. Por fim, o último estágio é a negociação entre os nós conectados aos links
candidatos a remoção. Todos esses passos, garantem uma complexidade de mensagem
O(n). Portanto, conclui-se que a complexidade do LSWTC é O(n) + O(n) = O(n).
35
4. Modelo de simulação
O objetivo do presente trabalho gira em torno de, não somente implementar o al-
gorimto LSWTC, mas também executá-lo em um simulador de robôs, de tal forma a
estudar o seu comportamento em um ambiente mais fidedigno ao mundo real. Visto que,
no futuro, a idéia é realmente transformar o LSWTC em um protocolo de comunica-
ção para dispositivos móveis, é de extrema importância colher resultados que levem em
consideração as interações físicas entre os agentes.
Com esse intuito, dois ambientes computacionais foram propostos: JisT/SWANS (Java
in Simulation Time / Scalable Wireless Ad hoc Network Simulator); e o ROS (Robot
Operating System).
Para o JiST/SWANS foram identificadas as seguintes características após um estudo

inicial:
• Simulador de eventos discretos com alto desempenho. Excelente para analisar si-
mulações muito densas;
• Apresenta o código aberto - fácilidade para o estudo + implementação de novas

funcionalidades, caso necessário;
• Linguagem Java;
• Modelos de Mobilidade já implementados;
• Sistema operacional windows;
Por outro lado, o ROS apresentou as seguintes características:
• Simulador de eventos discretos com aplicação em robótica;

Capítulo 4. Modelo de simulação 36
• Linguagens C++ e Python;
• Independente de protocolos de comunicação e sem modelos de mobilidade previa-

mente implementados;
• Boa documentação no site www.ros.org/wiki
• Sistema operacional linux, porém já existe uma máquina virtual com o ROS insta-
lado no seu website;
Devido a necessidade de implementar o LSWTC em um ambiente físico, com interações

entre os agentes, não restou dúvidas de que o ROS seria a ferramenta a ser utilizada. No
entanto, como o estudo desse trabalho é sobre redes ad hoc-to-backbone, uma biblioteca
para simulação de uma grande quantidade de robôs seria necessária. A partir dessa
necessidade, optou-se por utilizar a biblioteca Stage, que apresentava toda uma interface
gráfica para simular ambientes com populações de robôs, porém carecia de uma boa
documentação.
Como solução final, optou-se por estudar o Player, que da mesma forma como o ROS,
consiste de um conjunto de ferramentas para realizar pesquisas e estudos com robôs e
sensores. Esse, por sua vez, é um dos servidores para robô mais utilizado no mundo,
sendo almplamente documentado. Além disso, ele é totalmente compatível com a mesma
biblioteca gráfica para simulação de múltiplos agentes, Stage.
4.1 Player
O Player nada mais é do que um sistema para controle de robôs desenvolvido por
pesquisadores da USC (University of Southern California) nos anos 2000 e amplamente
utilizado por universidades e institutos de pesquisa do mundo inteiro. Por ser um sistema
de código aberto e livre distribuição, o Player busca ser atualizado constantemente para
se compatibilizar com as novas plataformas robóticas e sensores comerciais.
Ao rodar em um robô, o Player proporciona uma interface simples para os sensores

a atuadores através da rede IP. O programa cliente comunica-se com o Player via TCP
socket, lendo os dados dos sensores, enviando comandos aos atuadores e configurando os
dispositivos em tempo real.
O Player foi projetado para ser independente da linguagem de programação e da

plataforma utilizada. Portanto, o programa cliente pode rodar em qualquer máquina que
tenha conexão de rede com o robô e pode ser escrito em qualquer linguagem que tenha
suporte ao TCP sockets. Além disso, o Player garante total liberdade quanto a estrutura
dos seus programas, apresentando um caráter mais minimalistas quando comparado a
soluções semelhantes. Dessa forma, ele permite criar programas simples ler-pensar-agir
ou Multithreads para operar diferentes dispositivos paralelamente e concomitantemente.
O Player foi desenvolvido para suportar virtualmente qualquer número de clientes.

Cada cliente pode se conectar a qualquer instância do Player de modo a ler as informa-
ções dos sensores ou escrever comandos para os atuadores. Portanto, em tempo real, as
requisições dos dispositivos permitem que os clientes ganhem acesso a diferentes sensores
e atuadores a medida da sua necessidade.
Além disso, o Player permite gerar interfaces com múltiplos dispositivos ao mesmo
tempo. Conjuntamente com o Simulador Stage, os programas de controle para robôs
simulados terão o mesmo comportamento em robôs real.
(b) Modelo simulado no Stage

(a) Pioneer DX2
Figura 6: Robôs real e sua versão simulada

4.2 Stage
O Stage, por sua vez, permite simular uma população de robôs móveis, sensores e
objetos em um ambiente bi-dmensional bitmap. Ele foi projetado para suportar pes-
quisas em sistemas autônomos multi-agentes, portanto oferece modelos simples e com-
putacionalmente baratos dos mais variados dispositivos sem a preocupação em emular
fidedignamente qualquer um deles.
Figura 7: Simulador Stage
Outro ponto importante a acrescentar é que o Stage é um software independente do

Player ou do ROS, podendo ser usado em outros projetos de C++. Os controladores dos
robôs são compilados e executados em tempo real, mas também podem ser adicionados a
qualquer modelo. Os controladores tem completo acesso a API do Stage.
Usualmente, o Stage é utilizado como um módulo do Player, proporcionando a simu-

lação de uma população de robôs. Os usuários irão escrever controladores para os robôs
e algoritmos para os sensores como clientes do Player. Na prática, os clientes não conse-
guem identificar a diferença entre robôs reais e os simulados no Stage, o que permite a
sua utilização sem modificação em módulos físicos. Dessa forma, é possível fazer estudos
iniciais com grande acurácia para modelos físicos de robôs sem a necessidade de possui-los.
Como toda a comunicação cliente/servidor é feita através da rede TCP/IP, basta alterar
o endereço de IP para o do robô físico e pronto.
Figura 8: Simulação de um hospital altamente povoado no Stage
Figura 9: Simulação em perspectiva no Stage
4.3 Configuração Player/Stage

Para realizar as simulações no ambiente Player/Stage, optou-se por utilizar a lingua-
gem Ruby 1.8.7. Para tanto, fez-se necessário instalar essa versão no sistema operacional
Ubuntu 12.0.4, bem como o software SWIG que possibilita a comunicação entre códigos
em Ruby com códigos em C, C++.
A instalação do Player/Stage foi feita segundo [?, 6], utilizando as versões Player 3.0.2
e Stage 3.2.2.
Toda simulação no ambiente Player/Stage é composta por três partes essenciais:

• Código - comunica-se com o Player;
• Player - pega o código desenvolvido e envia as instruções para o robô. Por outro
lado, do robô ele retira as informações dos sensores e envia para o código;
• Stage - trabalha com o Player da mesma forma que o hardaware de um robô. Recebe
instruções do Player e movimenta os robôs no ambiente, da mesma forma envia
informações de sensores de volta ao Player
No simulador Player/Stage, existem basicamente três tipos de arquivos que são neces-
sários entender o seu funcionamento:
• .world (arquivo de construção do ambiente)
• .cfg (arquivo de configuração)
• .inc (arquivo para incluir e compactar outros arquivos .world)
Basicamente, o arquivo .world informa ao Player/Stage o que está disponível para ser
colocado no ambiente de simulação. Nesse arquivo serão descritos todos os robôs agentes,
objetos que ajudam a povoar o ambiente e todo o layout da simulação.
O arquivo .inc segue o mesmo formato de um arquivo .world, porém ele pode ser
incluído em outros arquivos .world. Uma boa prática para esses arquivos .inc é utilizá-lo
para descrição de modelos de robôs, permitindo a reutilização do mesmo elemento em
diferentes ambientes de simulação. Além disso, para alterar a configuração do robô, basta
fazê-lo somente uma vez, modificando esse arquivo .inc.
Já o arquivo .cfg permite ao Player ler todas as informações a respeito dos robôs
simulados. Ele vai informar ao Player quais drivers são necessários utilizar para interagir
com os robôs. Além disso, os arquivos .cfg informam ao Player como interpretar os dados
recebidos dos drivers de forma a ser apresentável para o código cliente. Todos os items
descritos no arquivo .world, obrigatoriamente, devem ser descritos aqui para permitir
interação com o código cliente.
Como todo objeto que se deseja ter comunicação tem que ser descrito nos arquivos
.world e .cfg, optou-se por criar um script em Ruby que escrevesse esses arquivos baseado
na quantidade de robôs que se desejava simular. Além disso, cada robô já seria inicializado
em uma posição aleatória do mapa e com uma separação mínima de 2 unidades entre o
seu centro e o dos demais.
Figura 10: Configuração Inicial dos robôs
Como o interesse é simular um ambiente com uma população de robôs móveis indepen-
dentes, fez-se uso de programação concorrente baseada em Threads de tal forma a rodar
os códigos para cada robô de forma simultânea. Os robôs tinham que constantemente
e simultanemente captar e enviar informações de seus sensores, desviar de seus pares e
se mover pelo mapa. Por outro lado, não é possível criar muitas Threads sem que haja
sobrecarga do sistema.
4.3.1 Informações Básicas
A descrição dos atributos que descrevem cada um dos arquivos .world e .cfg pode ser
estudada em [?]. Além disso, no Apêndice é possível ver o código com toda a descrição
do robô e do ambiente construido para as simulações do presente trabalho.
Na prática, o modelo de robô configurado fica bem descrito pela figura [?]. Inicial-
mente, todos os robôs estarão dispostos na mesma direção e sentido, porém espalhados
ao longo de todo o mapa. A motivação é que a referência angular de cada robô é baseado
na direção que aponta inicialmente. Desse jeito, alinha-se o eixo x do robô ao eixo x do
ambiente.
(a) Geometria Robô (b) Exemplo de robos
Figura 11: Modelo de robôs [18]
O ambiente utilizado é, da forma mais simples, um quadrado de lado l sem obstáculos.

A partir disso, escolhe-se quantos robôs se deseja simular e define as suas posições alea-
toriamente. As cores de cada robô no ambiente Player/Stage são escolhidas também de
forma aleatória dentre o conjunto {verde, vermelho, amarelo, azul, roxo}, sem nenhuma
representação.
4.3.2 Modelo de Mobilidade
Com relação a movimentação dos agentes, optou-se por utilizar como base o modelo
de mobilidade Random Waypoint, para tanto cada robô escolhe uma posição aleatória do
mapa para se deslocar. Ao chegar ao seu destino, ele calcula uma nova posição para ir,
gira com uma velocidade angular constante de π3 rad/s, alinha a sua dianteira na direção
e sentido do seu destino e avança até chegar ao ponto desejado. Vale ressaltar que o
sentido da rotação é escolhido baseado no tempo de rotação, portanto se a rotação no
sentido horário fará com que orobô se alinhe na direção desejada mais rapidamente, ela
será escolhida. Uma vez alinhado, o robô se deslocará em linha reta com uma velocidade
constante de 0.5un/s até o seu destino final. Assim que ele chegar, calcula-se uma nova
posição, reiniciando o ciclo.
Figura 12: Movimentação aleatória dos robôs
4.3.3 Algoritmo de Desvio
Uma vez com o modelo de mobilidade bem definido, era necessário construir também
um algoritmo de desvio para os robôs, visando evitar colisões entre os diversos nós.
Figura 13: Simulação com n = 130 sem algoritmo de desvio

Para evitar esses choques entre os robôs, inicialmente determinou-se uma distância
mínima de aproximação dmin , de tal forma que a distância entre os centros dos dois robôs
não pudesse ser menor ou igual a esse valor. Caso isso aconteça, ambos os robôs irão
se virar na direção que une os seus centros, porém com sentidos contrários, e iriam se
afastar um do outro durante 0.5s com a mesma velocidade 0.5un/s. Após esse período,
eles reiniciariam o modelo de mobilidade, escolhendo aleatoriamente uma nova posição
do mapa para se deslocar.
Na prática, o algoritmo de desvio se dava de forma síncrona, ou seja, a cada 0.3s, para
cada nó, determinava-se quem são seus vizinhos e dentre esses, aqueles que estavam a uma
distância igual ou inferior a dmin . Para um grande número de nós (> 50), observava-se um
atraso constante para os robôs, de modo que o algoritmo não conseguia evitar a colisão.
Figura 14: Aproximação de dois robôs a uma distância dmin = 3
4.4 Biblioteca Libgosu

Nos quesitos de simulação de robôs móveis e implementação do algoritmo LSWTC, o
Player/Stage satisfazia todas as necessidades. Porém, modificar as propriedades dos ar-
quivos .world, como as cores dos robôs, ou permitir desenhar linhas para simbolizar links
de comunicação na tela de simulação, em tempo de execução, não era possível com a lin-
guagem Ruby. No entanto, uma visualização gráfica seria extremamente importante para
avaliar o correto funcionamento tanto dos algoritmos RR, KHOPCA e consequentemente
do LSWTC.
Com isso em mente, buscou-se na literatura bibliotecas gráficas para Ruby 1.8.7 que
permitissem criar um ambiente gráfico de forma prática e com boa documentação, che-
gando ao final por escolher a Libgosu. Essa biblioteca é utilizada para o desenvolvimento
de jogos 2D para as linguagens de programação C++ e Ruby. Além do mais, ela per-
mitia desenhar elementos, linhas unindo os nós e alterar as suas cores em tempo real,
solucionando o problema de visualização dos resultados que o Player/Stage apresentava.
Como o intuito era verificar o funcionamento do LSWTC, bastava enviar para a bi-
blioteca libgosu a posição de cada nó, o seu respectivo peso e uma lista de todos os seus
vizinhos. Isso foi feito a partir de um arquivo output.txt que também informava a ID
do nó e o tempo da medição desde o início da simulação. A partir desse arquivo .txt, a
biblioteca libgosu obtinha as informações descritas anteriormente, quanto ao peso, esse foi
caracterizado pelas cores de cada nó, representados por círculos com o ID no seu centro,
e o conjunto de vizinhos podia ser observado pelas ligações entre os nós.
Figura 15: Caracterização dos pesos dos robôs na biblioteca Libgosu
Com o ambiente gráfico construido na biblioteca Libgosu, fica fácil observar o com-
portamento do RR e do KHOPCA. Na figura 4.11, os clusterheads, que tem peso 0, ficam
bem destacados em vermelho e os nós vizinhos a eles assumem o peso 1 e a cor laranja e
assim por diante. Além disso, pode-se notar que claramente o RR removeu o link entre os
nós 24 e 39 para aumentar o CC da rede. Portanto, esse ambiente gráfico criado resolve os
problemas apresentados anteriormente, o código pode ser encontrado no apêndice desse
trabalho.
Figura 16: Simulação utilizando a biblioteca Libgosu

47
5. Resultados das Simulações
A performance do LSWTC pode ser avaliada a partir da sua simulação. Para tanto,
diferentes configurações de rede serão utilizadas. Um grafo de disco r descreverá a rede
de comunicação móvel ad hoc, sendo r o raio de transmissão. Além disso os nós estarão
inicialmente posicionados segundo uma distribuição uniformemente aleatória na região de
simulação de lado l.
Como o objetivo principal do LSWTC tem preocupação com as propriedades topológi-

cas da rede, propriedades como a velocidade dos nós, não afetam o resultado da simulação
[17]. Porém, para o resultado presente, os nós estão se movendo aleatoriamente segundo o
modelo de mobilidade baseado no random waypoint a uma velocidade média de 0.6m/s.
r2 πn
A densidade da rede pode ser bem definido por d = l2
, sendo n o número de nós da
rede. Na prática, essa densidade bem representa o número médio de links por nó. Como
base desse trabalho, escolheu-se o limite inferior d = 5 e limite superior d = 11 para
buscar comparar os resultados das simulações com os de [17, LSWTC]. Para trabalhar
com esses valores de densidade, a partir de diferentes valores de l e r, optou-se por variar
a quantidade de nós a cada simulação.
As Tabelas 5.1 e 5.2 apresentam distintos valores de densidade para l = 30 e l = 20,

respectivamente ao variar o raio de transmissão e a quantidade de robôs simulados. As
células em amarelo representam os valores que estão dentro da faixa de interesse para
realizar as simulações.
Cada simulação teve duração aproximada de 1min e as medidas de Average Path

Length, Clustering Coefficient e, em alguns casos, do número de clusterheads eram reali-
zadas a cada 0.3s. Ao final, calculava-se a média aritmética para cada um desses atributos,
sendo esses resultados apresentados ao final.
Capítulo 5. Resultados das Simulações 48
Tabela 1: Valores de densidades para l = 30
Tabela 2: Valores de densidades para l = 20
5.1 Resultados da simulação para l = 30, r = 10

Inicialmente, escolheu-se a largura da área de simulação l = 30 e o raio de transmis-
são r = 10. Para essa primeira análise, buscou-se dois valores antagônicos da faixa de
densidades, utilizando n = 17 → d ≈ 6 e n = 32 → d ≈ 11.
Todas as medidas foram feitas após a aplicação do algoritmo LSWTC sobre a rede.
5.1.1 Estudo de dmin para k = 4
Como primeira proposta de simulação, optou-se por entender a influência da distância

mínima de aproximação do algoritmo de desvio sobre a APL e o CC. Portanto, para
k = 4,variou-se dmin desde 0 - sem algoritmo de desvio - até 5. Vale ressaltar que valores
entre 0 e 2 não foram simulados, pois, devido ao tamanho dos robôs, a colisão naturalmente
ocorreria, e os resultados seriam semelhantes ao caso com dmin = 0.
Average Path Length

2.42
2.50
2.25
2.30 2.21
2.16 2.17
2.10
2.10
1.87 2.12 2.11 2.11
k-‐hops
1.84 d=6
1.90
1.87 d=11
1.70 1.83
1.50 1.62 1.63

1.58
1.30
dmin=0 dmin=2 dmin=2.5 dmin=3 dmin=3.5 dmin=4 dmin=4.5 dmin=5
Figura 17: APL com LSWTC e dmin variando de 0 a 5
Clustering Coefficient
0.79 0.79
0.80
0.77
0.78
0.79 0.75 0.75
0.76 0.74
0.74
0.72 0.7
0.70 d=6
0.71 0.67
0.68 0.70 d=11
0.66 0.68 0.68
0.64
0.65 0.65 0.65
0.62
0.60
dmin=0 dmin=2 dmin=2.5 dmin=3 dmin=3.5 dmin=4 dmin=4.5 dmin=5
Figura 18: CC com LSWTC e dmin variando de 0 a 5
Com relação a dmin , a partir dos resultados ilustrados na figura 5.1, observou-se um
incremento da Average Path Length quanto maior a distância mínima de aproximação
de dois nós. Do ponto de vista intuitivo, o resultado obtido faz sentido, uma vez que
os robôs tenderão a se manter mais afastados um dos outros, de modo que menos robôs
estarão dentro do raio de transmissão. Dessa maneira, é de se esperar que mais saltos
sejam necessários para se alcançar os demais nós, em média. Outro ponto importante
a notar é que para menores densidades, esse fenômeno mostra mais regularidade, tal
fato deve-se a dois motivos, com um grande número de nós nem sempre o espaço será
suficiente para que a separação mínima entre 2 nós, de fato, ocorra. Muitas vezes, os nós
estarão sempre a uma distância menor do que a mínima e estarão constantemente tentado
fugir, porém, nesse processo, acabam encontrando um outro nó e começam a fugir desse
também. Por fim, vale salientar que é de se esperar uma saturação, pois os nós tenderão
a se espalhar pelo mapa e se distribuir o mais afastado um dos outros, portanto muitos
se desconectarão da rede, tornando-se novos clusterheads e, a partir daí, a distância aos
demais clusterheads se torna 1 e a contribuição desse nó passa a ser menor.
Quando analisado a evolução do Clustering Coefficient com o crescimento de dmin , a

partir da figura 5.2, nota-se claramente uma redução, ou seja, ele tem um comportamento
inverso ao da APL com relação a essa grandeza. Na prática, o CC mede o grau de
agrupamento dos nós, portanto se a distância mínima de aproximação dos nós aumenta,
os nós se espalham mais pelo mapa, diminuindo a quantidade de nós possíveis a ser
detectado pelo raio de transmissão. Com isso, os robôs seguem a tendência de ficarem
menos agrupados, reduzindo o seu CC, como observado. Outro fator importante é a
saturação do resultado para d = 11, pois devido a densidade maior dos nós, muitas vezes
não é possível posicionar todos os nós com distâncias de separação maiores de 4 a 5, por
exemplo. Com isso, na prática, os últimos três casos apresentam um cenário semelhante
com respeito ao CC.
Por fim, não restam dúvidas de que a relação dmin tem uma grande influência nos
valores de APL e CC, porém o tamanho do robô também não pode ser desconsiderado,
pois, para valores menores de r, esse valor começa a ser mais relevante. Não faz parte do
escopo desse trabalho o estudo das dimensões do robô, no entanto, é uma grandeza que
está implicitamente relacionada com dmin
5.1.2 Estudo de k para dmin = 2.5
Como segunda análise, optou-se por estudar, assim como em [17], a influência do
número máximo de saltos k permitido de um nó até o clusterhead mais próximo. A idéia
é também avaliar a influência desse parâmetro sobre as grandezas Average Path Length
e Clustering Coefficient. Para tanto, assumiu dmin = 2.5 e variou-se o valor de k desde 2
até 7 e, da mesma forma como o caso anterior, utilizou-se os dois valores antagônicos de
d, 6 e 11.
Ao observar os resultados da APL, a partir da figura 5.3, notou-se que o seu valor
permaneceu constante para ambas densidades ao longo de k. Por outro lado, o aumento
de k intuitivamente deveria aumentar o valor de APL, pois, menos acessos ao Backbone
seriam criados e, portanto, haveria, em média, mais saltos entre dois nós quaisquer da
Average Path Length

2.5
1.92 1.98
1.85 1.84 1.79 1.88
2
1.5 1.77 1.8 1.78 1.77

k-‐hops
1.63 1.71 d=6

1 d=11
0.5
0
k = 2 k = 3 k = 4 k = 5 k=6 k=7
Figura 19: APL com LSWTC e k variando de 2 a 7
Clustering Coefficient
0.85
0.8
0.78 0.78
0.8 0.77
0.75 0.75
0.75
d=6
0.7 d=11
0.71 0.71
0.69
0.65 0.68 0.68
0.67
0.6
k = 2 k = 3 k = 4 k = 5 k=6 k=7
Figura 20: CC com LSWTC e k variando de 2 a 7
rede. Na prática, o que se observou foi um raio de transmissão muito grande quando
comparado ao tamanho da simulação, pois os nós não ficavam separados o suficiente
para exigir um número grande de saltos de separação, tal fato pode ser comprovado nas
figuras 5.4 e 5.5. Por isso, ao variar o número de hops, não observou nenhuma variação
significativa na APL.
De forma semelhante, o CC também manteve o seu valor constante ao variar k, po-

rém, independente da relação entre r e l como citado anteriormente, o CC é influenciado
somente pela topologia da rede, ou seja, pela atuação do Reckful Roaming. Na prática,
espera-se que as pequenas variações nas simulações sejam provenientes única e exclusiva-
mente da aleatoriedade da movimentação dos nós.
(a) Simulação LSWTC com n = 17 e k = 7 (b) Simulação LSWTC com n = 32 e k = 7
Figura 21: Modelo de robôs
5.2 Resultados da simulação com/sem LSWTC com l = 20,

r = 5, dmin = 2.5
Com o intuito de observar a influência real do LSWTC sobre a APL com a variação
de k, optou-se por modificar os parâmetros da simulação. Porém, ao realizar testes
com diferentes valores de n, notou-se que para n > 60, o algoritmo de desvio ficava
descaracterizado, pois o processamento era tão intenso que cada robô sofria um atraso
sobre as suas ações, de tal modo que não conseguiam desviar a tempo uns dos outros.
Resumindo, em poucos segundos, os robôs estavam todos colididos. Para poder trabalhar
com o mesmo intervalo de densidades, reduziu-se a área de simulação para l = 20 e r = 5,
variando n desde 26 até 56 para garantir o mesmo intervalo de densidades. Dessa forma,
a relação r/l seria reduzida, permitindo que mais saltos fossem identificados na simulação
e a variação da APL ao longo de k pudesse ser observada.
Além disso, uma outra importante consideração é ter conhecimento do quanto se

ganha em termos de Average Path Length e Clustering Coefficient quando comparados
com simulações sem o LSWTC, para, de fato, comprovar a eficiência de performance do
algoritmo em ambientes físicos reais. Para esse caso, os clusterheads são fixos durante
toda a simulação. A sua quantidade é determinada como o inteiro mais próximo da
média do número de clusterheads obtidos durante as simulações com o LSWTC a partir
das medições a cada 0.3s.
5.2.1 Estudo de k para dmin = 2.5
Apesar do número maior de nós sendo simulados, optou-se por variar o valor de k
somente entre 2 e 5, acreditando que para valores maiores, as curvas iriam saturar. Além
disso, foram simuladas 4 curvas, com os valores de densidade pertencentes ao seguinte
conjunto 5, 7, 9, 11.
Average Path Length (LSWTC)

3.00
2.90
2.80
2.70
2.60 d=5
k-‐hops
2.50 d=7
2.40
d=9
2.30
d=11
2.20
2.10
2.00

k=2 k=3 k=4 k=5
Figura 22: APL com LSWTC e k variando de 2 a 5
Clustering Coefficient (LSWTC)

0.66
0.63
0.60
d=5
0.57
d=7
0.54
d=9
0.51 d=11
0.48
0.45

k=2 k=3 k=4 k=5
Figura 23: CC com LSWTC e k variando de 2 a 5
Com relação a APL, obteve-se um resultado mais próximo do esperado, de tal forma
que ela cresce com o incremento do valor de k. Uma vez que a razão entre o raio de
transmissão e o lado l da simulação é menor, é possível observar maior quantidade de
saltos até o clusterhead quando comparados com o caso anterior.
Já o CC, manteve-se novamente constante para os diversos valores de k, satisfazendo

a condição de que ele só é alterado por modificações na topologia da rede, ou seja, nas
ligações entre os nós.
Além da APL e do CC, para as simulações bem ilustradas pelas figuras 5.6 e 5.7,
mediu-se a quantidade de clusterheads presentes no ambiente a cada 0.3s, calculando a
sua média e aproximando para o inteiro mais próximo. Tais resultados poder ser conferidos
nas tabelas 5.3 a 5.6
Tabela 3: APL, CC e número de clusterheads para k = 2
5.2.2 APL e CC sem LSWTC, com dmin = 2.5 e clusterheads fixos
Para os mesmos valores de densidade e fixando os clusterheads de acordo com os

valores explícitos nas tabelas 5.3 a 5.6, obteve-se os resultados de Average Path Length e
Clustering Coefficient.

Average Path Length (Random)

2.70
2.60
2.50
d=5
2.40
k-‐hops
d=7
2.30
d=9
2.20
d=11
2.10
2.00

k=2 k=3 k=4 k=5
Figura 24: APL sem LSWTC e k variando de 2 a 5
De forma similar as simulações com o LSWTC, observou-se um incremento da APL

ao longo de k, bem como uma constância do CC para essa mesma variação. O mais
importante, porém, é comparar as duas grandezas, de modo a verificar se o LSWTC
possibilitou uma aproximação da rede a uma rede Small-World.
5.2.3 Comparação resultados Random e LSWTC
Para cada uma das simulações com e sem LSWTC, plotou-se em um mesmo gráfico
ambos os valores. Portanto, comparou-se tanto a APL quanto o CC para esses dois casos
para as densidades d pertencentes ao conjunto {5, 7, 9, 11} com dmin = 2.5, l = 20 e r = 5.
Ao se comparar os resultados da APL entre a simulação com o LSWTC e sem (ran-

dom), nota-se que a aplicação do LSWTC garante um aumento dessa grandeza. Tal
resultado era esperado, visto que o Reckful Roaming remove links da vizinhanças de al-
guns nós, de tal forma que a menor distância não somente a esses nós deixa de ser 1,
mas aos outros nós que utilizavam esse como intermediário também poderão sofrer um
incremento. O ponto é que esse incremento não demonstrou ser significativo a desca-
Clustering Coefficient (Random)

0.65
0.63
0.61
0.59
0.57 d=5
0.55 d=7
0.53 d=9
0.51
d=11
0.49
0.47
0.45

k=2 k=3 k=4 k=5
Figura 25: CC sem LSWTC e k variando de 2 a 5
APL -‐ d = 5
2.80
2.70 2.68
2.60
2.49
2.50 2.44
k-‐hops
2.37 Random
2.40
2.32 LSWTC
2.30 2.31
2.20
2.20 2.20
2.10
2.00
k = 2 k = 3 k = 4 k = 5
Figura 26: Comparação APL para d = 5
racterizar completamente de uma rede Small-World. Muitas vezes, o ganho de APL era
insignificativo que a própria natureza aleatória causava mais sensibilidade a esse atributo
do que a aplicação do LSWTC.
Por outro lado, quando analisado o ganho do Clustering Coefficient da rede, todos os
casos geraram um ganho real. Não importando a densidade utilizada, foi observado um
incremento do CC, aproximando a uma rede SW. É importante ressaltar também que o
ganho não foi expressivo como em [17], pois, mesmo sem o LSWTC, o que se observa
durante a simulação é um agrupamento dos nós na região central. Os nós tentam se
deslocar utilizando o Random Waypoint, porém o algoritmo de desvio faz com que, a
toda hora, eles fiquem reativando a localização do próximo destino. Além disso, quanto
APL -‐ d = 7
3.00 2.91
2.90
2.80 2.69
2.70 2.61
2.60
k-‐hops
2.43 2.63
2.50 2.57 Random
2.40
LSWTC
2.30 2.40
2.36
2.20
2.10
2.00

k=2 k=3 k=4 k=5
APL -‐ d = 9
2.90
2.80
2.80 2.75
2.70
2.60 2.58
k-‐hops
2.50 2.43 2.52 2.54 2.56

Random
2.40 2.41
LSWTC
2.30
2.20
2.10
2.00

k=2 k=3 k=4 k=5
mais nós, menos liberdade eles terão, pois não tem como garantir a distância mínima de
aproximação entre todos eles. Portanto, com o aumento da densidade, o CC naturalmente
deve aumentar, de modo a reduzir a diferença entre os resultados com e sem LSWTC.
No entanto, quando comparado aos valores absolutos dos primeiros resultados com
LSWTC para l = 30 e dmin = 2.5 variando k, o resultado é consideravelmente inferior.
Tal motivo deve-se a razão dmin /r ser superior no último caso. Como comprovado na
primeira simulação, quanto maior essa relação, mais difícil será manter as características
de redes SW para a rede em estudo.
APL -‐ d = 11

2.85
2.90
2.80
2.70
2.60 2.54
2.51
2.48
k-‐hops
2.50
2.53 2.52 Random
2.40 2.47
LSWTC
2.30 2.36
2.20
2.10
2.00

k=2 k=3 k=4 k=5
CC -‐ d = 5
0.66 0.65
0.64
0.62 0.62
0.62
0.60
0.60
0.58 Random
0.58 LSWTC
0.56 0.57
0.56
0.54
0.54
0.52
0.50
k = 2 k = 3 k = 4 k = 5
Figura 30: Comparação CC para d = 5
CC -‐ d = 7
0.66
0.64 0.64
0.63 0.63
0.64
0.62
0.60
0.61
0.58 Random
0.58 0.58
0.56 LSWTC
0.57
0.54
0.52
0.50

k=2 k=3 k=4 k=5

CC -‐ d = 9
0.66
0.64
0.63
0.64
0.62 0.62
0.62
0.60
0.60
0.58 Random
0.59 0.59 0.59
0.56 LSWTC
0.54
0.52
0.50

k=2 k=3 k=4 k=5
CC -‐ d = 11
0.64 0.63
0.63 0.62 0.62
0.62
0.62
0.60
0.60 0.60
0.58
0.58 Random
0.56
LSWTC
0.54
0.52
0.50

k=2 k=3 k=4 k=5

60
6. Conclusões e Trabalhos Futuros
6.1 Conclusão
Nesse trabalho, foi implementado o LSWTC, algoritmo para manutenção da eficiência
de comunicação em redes ad hoc, em um ambiente de robôs móveis. Para tanto, utilizou-se
o simulador Player/Stage que proporcionava criar robôs, interagir e comunicar com eles.
E, para melhor analisar a influência do LSWTC sobre os robôs, construiu-se um ambiente
gráfico de visualização de nós a partir da biblioteca Libgosu. Com esse conjunto de
ferramentas, era possível povoar o ambiente, inserir um modelo de mobilidade individual
para cada robô, bem como aplicar individualmente um algoritmo de desvio entre eles
e analisar a performance de comunicação da rede como um todo. Para tanto, foram
utilizadas técnicas de programação concorrente e orientação a objetos, de modo a melhor
caracterizar cada entidade presente na simulação e garantir que a comunicação com cada
robô se desse simultaneamente.
A partir dos resultados das simulações, pôde-se observar, na prática, quais parâmetros
físicos influenciavam não somente o modelo de mobilidade, mas também a performance do
LSWTC. Aprendeu-se que as dimensões físicas dos robôs, alcance do raio de transmissão,
tamanho da simulação e distância mínima de aproximação, eram extremamente relevan-
tes na busca de maximizar a eficiência do algoritmo em questão. Mas, de modo geral,
apesar da influência dos parâmetros listados, o LSWTC promoveu ganhos reais quanto ao
Clustering Coefficient ao mesmo tempo que aumentou um pouco a Average Path Length.
Por fim, pode-se afirmar que o LSWTC aproximou sim a rede ad hoc-to-backbone de
robôs móveis a uma rede Small-World.
Capítulo 6. Conclusões e Trabalhos Futuros 61
6.2 Trabalhos Futuros

Desde o início, o presente trabalho já fazia parte de uma coletânea de outros trabalhos
de pesquisa do algoritmo LSWTC, com o intuito de transformá-lo em um protocolo de co-
municação. E, por esse motivo, houve um especial cuidado em deixar documentado todos
os passos realizados para ser futuramente reproduzido e, consequentemente, melhorado.
Por outro lado, o desenvolvimento desse trabalho também levantou novos questiona-
mentos e dúvidas com respeito ao ganho de performance oferecido pelo LSWTC a redes
ad hoc de robôs móveis.
Levando em consideração as questões a respeito da implementação do LSWTC em

um simulador com interações físicas entre os agentes, bem como as futuras aplicações do
LSWTC, são propostas as seguintes frentes de trabalho:
• Alteração do algoritmo de desvio, de forma a aumentar a sua inteligência;
• Otimização do raio de transmissão, largura de simulação e distância mínima de

aproximação com o intuito aumentar ao máximo a performance do LSWTC;
• Implementação de um algoritmo de conectividade com Backbone móvel para traba-

lhar conjuntamente com o LSWTC;
• Implementação do LSWTC em linguagens de mais baixo nível, como C, C++, com

o intuito de transferir a inteligência para robôs reais;
Por fim, conclui-se que os trabalhos com o LSWTC são extensos, porém, de extrema
valia, pois, no fundo, a sua aplicação em dispositivos móveis, como smartphones, permitirá
um ganho constante de eficiência de comunicação e transmissão de dados.
62
Referências
[1] http://www.cnblogs.com/boyfood/archive/2012/04/06/2434699.html. Acesso

em 15-10-2013.
[2] Average Path Length. http://en.wikipedia.org/wiki/Average_path_length.

Acesso em 15-10-2013.
[3] Biblioteca Libgosu. http://www.libgosu.org/. Acesso em 15-10-2013.
[4] Clustering Coefficient. http://en.wikipedia.org/wiki/Clustering_

coefficient. Acesso em 15-10-2013.
[5] How to install SWIG in Linux centos. http://stackoverflow.com/questions/

3050520/how-to-install-swig-on-linux-centos. Acesso em 15-10-2013.
[6] Installing Player and Stage in Ubuntu. http://www.control.aau.dk/~tb/wiki/

index.php/Installing_Player_and_Stage_in_Ubuntu. Acesso em 15-10-2013.
[7] Player/Stage Tutorials. http://playerstage.sourceforge.net/doc/Player-cvs/

player/group__tutorials.html. Acesso em 15-10-2013.
[8] Player/Stage Tutorials - Mobotica. http://mobotica.blogspot.in/search/

label/Player%2FStage. Acesso em 15-10-2013.
[9] Small-World Network. http://en.wikipedia.org/wiki/Small-world_network.

Acesso em 15-10-2013.
[10] M. Newman e D. Watts. Scaling and percolation in the small-world network model.
Physical Review, 60, 1999.
[11] Rama Cont e Emili Tanimura. Small World graphs: characterization and alternative
constructions. Advances in Applied Probability, 40(4), 2008.
[12] Duncan J. Wattasand e Steven H. Strogatz. Collective dynamics os ’small-world’

networks. Nature, (393), June 1998.
Referências 63
[13] Ben Liang e Zygmunt J. Haas. Virtual backbone generation and maintenance in
ad hoc network mobility management. INFOCOM 2000. Nineteenth Annual
Joint Conference of the IEEE Computer and Communications Socie-
ties. Proceedings. IEEE, 2000.
[14] Douglas S.J. de Couto Hu lmm Lww e Robert Morris Jinyang Li, Charles Blake.
Capacity of Ad Hoc Wireless Networks. MobiCom, 2001.
[15] Mario Gerla Kaixin Xu, Xiaoyan Hong. An Ad Hoc Network with Mobile Backbones.
IEEE International Conference on Communications, 5, 2000.
[16] Ding-Zhu Du Panos M. Pardalos Makin Min, Feng Wang. A Reliable Virtual Back-
bone Scheme in Mobile Ad-Hoc Networks. Publicação interna da Universidade de
Minnesota.
[17] Damla Turgut e Steffen Rothkugel Matthias R. Brust, Carlos H.C. Ribeiro. LSWTC:
A Local Small-World Topology Control Algorithm for Backbone-Assisted Mobile Ad
hoc Networks. IEEE 35th Conference on Local Computer Networks (LCN), 2010.
[18] Jennifer Owen. How to Use Player/Stage, 2nd edition, April 2010.
[19] Nicolas Puech Michel Riguidel Rabah Meraihi, Gwendal Le Grand. Improving ad
hoc network performance with backbone topology control. Vehicular Technology
Conference, 2004.
[20] Bevan Das e Vaduvur Bharghavan Raghupathy Sivakumar. Spine routing in ad hoc
networks. Cluster Computing, 1, 1998.
[21] R. K. Chauhan Ramesh Kait and Kuldeep Kherwal. Route mechanisms for
wireless adhoc networks: classifications and comparison analysis. In-
ternational Journal of Science, Environment and Technology, 1(2), 2012.
[22] Jie Wu. Handbook on Theoretical and Algorithmic Aspects of Sensor, Ad Hoc Wire-
less, and Peer-to-Peer Networks. Auerbach Publications, 2005.
[23] Weizhao Wang e Xiang-Yang Li Yu Wang. Distributed Low-Cost Backbone Forma-

tion for Wireless Ad Hoc Networks. ACM MobiHoc, 2005.
64
A. Arquivos Player/Stage
Primeiramente, como todo o código foi construído em cima da linguagem de progra-

mação Ruby, é necessário instalá-la. Para tanto, é necessário abrir uma janela no terminal
e digitar o seguinte comando:
sudo apt-get install ruby1.8
Será solicitado a senha do admnistrador, caso esteja utilizando a a máquina virtual de

Linux 12.0.4 com ROS Groovy previamente instalado, a senha será viki. Como próximo
passo, basta instalar a biblioteca SWIG, que permitirá compatibilizar o código em Ruby
com o simulador Player/Stage. O procedimento de como instalar a SWIG pode ser bem
orientado por [5]
Vale lembrar que se houver quaisquer erros com respeito a alguma falta de dependência
e não seja possível completar a instalação, é importante verificar no terminal exatamente
o que aconteceu, de modo a procurar por soluções na Internet.
Para que o simulador seja corretamente instalado, basta seguir as informações em

[1, 6]. Novamente, sempre observando o sucesso ou não das instalações no terminal.
Com todos os softwares corretamente instalados, pode-se dar início a configuração da

simulação.
Para que que o código do Apêndice funcione corretamente, é necessário que os arquivos
.world, .cfg e .inc estejam no mesmo diretório. Para iniciar a janela de simulação com os
robôs dispostos em suas posições iniciais, basta executar o seguinte comando no terminal.
player (nome do arquivo).cfg

APÊNDICE A. Arquivos Player/Stage 65
Seguem abaixo todos os arquivos utilizados para executar as simulações do Player/S-

tage
A.1 map.inc
Os arquivos .inc foram criados para serem facilmente incluídos em arquivos .world,
portanto são utilizados para salvar configurações de objetos e cenários que se deseja re-
produzir no futuro.
Com relação ao ambiente, define-se características como a cor, espessura dos limites,
resposta aos sensores e outras coisas mais que podem ser encontrado em [18]. Em se
tratando da desrição do robô, tem-se a delimitação de sua geometria, sensores e atuadores.
# map.inc - useful setup for a floorplan bitmap

# Authors: Richard Vaughan
# $Id$
define floorplan model

(
# sombre, sensible, artistic
color "white"
# most maps will need a bounding box

boundary 1
gui_nose 0
gui_grid 0
gui_move 0
gui_outline 0
gripper_return 0
fiducial_return 0
ranger_return 0.5
)
define zone model

(
color "orange"
size [ 4 4 0.02 ]
gui_nose 0
gui_grid 0
gui_move 1
gui_outline 0
# insensible to collision and range sensors

obstacle_return 0
ranger_return -1 # transparent to range sensors
)
A.2 bigbob.inc
Em se tratando da desrição do robô, o arquivo .inc bem representa a descrição deta-
lhada da sua geometria, dos seus sensores e atuadores. Caso haja um interesse de entender
melhor todos os parâmetros utilizados, veja em [18]
define bigbob position

(
# actual size
size [1.25 1 1]
# centre of rotation offset

origin [0.125 0 0 0]
# the shape of Bigbob
block
(
points 6
point[0] [0.75 0]
point[1] [1 0.25]
point[2] [1 0.75]
point[3] [0.75 1]
point[4] [0 1]
point[5] [0 0]
z [0 1]
)
block
(
points 4
point[3] [1 0.75]
point[2] [1.25 0.75]
point[1] [1.25 0.625]
point[0] [1 0.625]
z [0 0.5]
)
block
(
points 4
point[3] [1 0.375]
point[2] [1.25 0.375]
point[1] [1.25 0.25]
point[0] [1 0.25]
z [0 0.5]
)
# positonal things
drive "diff"
# sensors attached to bigbob

bigbobs_sonars()
bigbobs_eyes()
bigbobs_laser()
obstacle_return 1
laser_return 1
ranger_return 1
blob_return 1
)
define bigbobs_sonars ranger

(
# number of sonars
scount 4
# define the pose of each transducer [xpos ypos heading]
spose[0] [ 0.75 0.1875 0 ] #fr left tooth
spose[1] [ 0.75 -0.1875 0 ] #fr right tooth
spose[2] [ 0.25 0.5 30] # left corner
spose[3] [ 0.25 -0.5 -30] # right corner
# define the field of view of each transducer

# [range_min range_max view_angle]
sview [0.3 2.0 10]
# define the size of each transducer [xsize ysize] in metres

ssize [0.01 0.05]
)
define bigbobs_eyes blobfinder

(
# number of colours to look for
colors_count 2
# which colours to look for

colors ["orange" "DarkBlue"]
# camera parameters
image [160 120] #resolution
range 5.00
fov 1.047196667 # 60 degrees = pi/3 radians
)
define bigbobs_laser laser

(
# distance between teeth in metres
range_max 0.25
# does not need to be big
fov 20
#number of ranges measured
samples 180
pose [0.625 0.125 -0.975 270]
size [0.025 0.025 0.025]
)
A.3 simulation.rb
O presente arquivo visa buscar criar dinamicamente os arquivos .cfg e .world chamando
métodos do arquivo helper.rb incluído e inicializar a janela do Stage com os robôs em
suas posições iniciais. Além disso, ele precisa incluir também as bibliotecas rubygems e
playercpp. Por fim, vale ressaltar que a execução desse arquivo automaticamente inicializa
a janela do Player/Stage, pois, ao final, ele chama o comando player empty.cfg.
#!/usr/bin/ruby
require ’rubygems’
require ’helper’
require ’playercpp’
n_robots = ARGV[0].to_i # Gets the number of robots based on terminal first parameter
pos = create_world(n_robots) # Creates a .world file based on the number of robots
create_cfg(n_robots) # Creates .cfg file based on the number of robots
# Initalizes Player/Stage window with robots displayes on their initial position

‘player empty2.cfg‘
A.4 bigbob.rb
O arquivo bigbob.rb é o mais importante de todos, apresentando toda a lógica da simu-
lação. Portanto, as implementações do Reckful Roaming e K-hop Clustering Algorithm
podem ser encontradas nesse arquivo. Além disso, todas as ações e atributos individuais
dos robôs estarão aí descritas.
class Bigbob
# Class to define all robots attributes and actions
attr_accessor :ID, :weight, :cc

attr_reader :port, :pp, :lp, :sp, :size, :x_start, :y_start, \
:pos_x, :pos_y, :yaw, :neighbors, :neighbors2, :min_dist
def initialize(robot, port, x_start, y_start)

@neighbors = []
@x_start = x_start
@y_start = y_start
@port = port
@k_hop = 6
@min_dist = 2.5
@weight = rand(@k_hop+1)
@cc = 0
# @weight = rand(@k_hop) + 1 # Without LSWTC
@pp = Playercpp::Position2dProxy.new(robot, @port)

@lp = Playercpp::LaserProxy.new(robot, @port)
@sp = Playercpp::SonarProxy.new(robot, @port)
@pp.RequestGeom()
@lp.RequestGeom()
@sp.RequestGeom()
@size = @pp.GetSize()
end
def go_to(x_new, y_new, x_old, y_old, yaw_old)

# Makes robot travel in a straight line up to its destiny
w = 60.0
v = 0.5
tan_arc = (y_new - y_old)/(x_new - x_old)
yaw_new = Math::atan(tan_arc)
yaw_new -= Math::PI if y_new < y_old && x_new < x_old
yaw_new += Math::PI if y_new > y_old && x_new < x_old
rotation_time = (yaw_new - yaw_old) / (w * Math::PI / 180.0)

rotation_time += 360.0 / w if rotation_time < 0.0
if rotation_time > 180.0 / w

rotation_time = (360.0 / w) - rotation_time
w *= -1
end
dist = get_distance(x_old, x_new, y_old, y_new)

straight_time = dist / (v)
@pp.SetSpeed(0.0, w * Math::PI / 180.0)

sleep(rotation_time)
@pp.SetSpeed(v, 0.0)
sleep(straight_time)
end
def stop
# Stops robot from moving or rotating
@pp.SetSpeed(0.0, 0.0)
end
def detecting_neighbors(i, radio, bob, n_robots, thread)

# Determines which nodes are inside target robot neighborhood
px = []
py = []
old_neighbors = []
dist = []
old_neighbors = @neighbors
@neighbors = []
@pos_x = bob[i].pp.GetXPos() + @x_start
@pos_y = bob[i].pp.GetYPos() + @y_start
@yaw = bob[i].pp.GetYaw()
(0...n_robots).each do |j|
px[j] = bob[j].pp.GetXPos() + bob[j].x_start
py[j] = bob[j].pp.GetYPos() + bob[j].y_start
dist[j] = get_distance(@pos_x, px[j], @pos_y, py[j])
if dist[j] > 0 && dist[j] <= radio

@neighbors << j
end
end
@neighbors.delete(i)
@neighbors.each do |j| # Colision Avoidance algorithm

if dist[j] < @min_dist
thread[i] = Thread.new do
self.stop
w = 60.0
tan_arc = (@pos_y - py[j])/(@pos_x - px[j])
yaw_new = Math::atan(tan_arc)
yaw_new -= Math::PI if @pos_y < py[j] && @pos_x < px[j]
yaw_new += Math::PI if @pos_y > py[j] && @pos_x < px[j]
rotation_time = (yaw_new - @yaw) / (w * Math::PI / 180.0)

rotation_time += 360.0 / w if rotation_time < 0.0
if rotation_time > 180.0 / w

rotation_time = (360.0 / w) - rotation_time
w *= -1
end
@pp.SetSpeed(0.0, w * Math::PI / 180.0)

sleep(rotation_time)
@pp.SetSpeed(0.5, 0.0)
sleep(0.5)
end
end
end
end
def khopca(bob)
# Defines KHOPCA algorithm
min_weight = @k_hop
min_node = @ID
@neighbors.each do |i|
if min_weight > bob[i].weight
min_weight = bob[i].weight
min_node = i
end
end
if min_weight < @weight

@weight = min_weight + 1
elsif min_weight == @k_hop && @weight == @k_hop

@weight = 0
elsif min_weight >= @weight && @weight != 0

@weight += 1
elsif min_weight == 0 && @weight == 0

@weight += 1 if bob[min_node].ID > @ID
end
end
def reckful_roaming(i, bob)

# Defines RR algorithm
rc = remove_candidates(i, bob)
rc_neighbors = Hash.new([])
rc.each do |u|
rc_neighbors[u] = remove_candidates(u, bob)
if rc_neighbors[u].include?(i)
new_neighbors = @neighbors | bob[u].neighbors

cc_sum = global_clustering_coefficient(new_neighbors, bob)
@neighbors.delete(u)
bob[u].neighbors.delete(i)
new_neighbors2 = @neighbors | bob[u].neighbors

cc_sum_rc = global_clustering_coefficient(new_neighbors2, bob)
if cc_sum_rc > cc_sum

if @neighbors2 & bob[u].neighbors2 == []
File.open(’ca.txt’, ’a’) { |f| f.print "\n\n#{i}: \
#{@neighbors2.inspect}\n#{u}: #{bob[u].neighbors2.inspect}" }
if permit(u, bob)
@neighbors << u
bob[u].neighbors << i
File.open(’ca.txt’, ’a’) { |f| f.print " - ok" }
end
end
File.open(’ca.txt’, ’a’) { |f| f.print "\nNode #{i}: #{bob[i].neighbors.inspect} \

\nNode #{u}: #{bob[u].neighbors.inspect}\n" }
else
@neighbors << u
bob[u].neighbors << i
end
end
end
@neighbors2 = @neighbors
@neighbors
end
def permit(u, bob)

# Defines permit method in RR algorithm
@neighbors.each { |j| return false if bob[j].neighbors2 & bob[u].neighbors2 != [] }
return true
end
def clustering_coefficient(i, bob)

# Calculates local clustering coefficient
neighbors = bob[i].neighbors
ki = neighbors.length
num = 0.0
den = ki * (ki-1)
neighbors.each do |j|
inter = neighbors & bob[j].neighbors
num += inter.length
end
ki <= 1 ? cc = 0.0 : cc = num / den
end
def distance(i,bob)
# Calculates minimum distance between a robot and all the others
n = bob.length
dist = Array.new(n) {0}

confirm = Array.new(n) {false}
confirm[i] = true
queue = []
queue.push(i)
until queue.empty?
elem = queue.shift
bob[elem].neighbors2.each do |k| # Simulation with LSWTC

# bob[elem].neighbors.each do |k| # Simulation without LSWTC
unless confirm[k]
dist[k] = dist[elem] + 1
confirm[k] = true
queue.push(k)
end
end
if bob[elem].weight == 0
(0...n).each do |k|
if bob[k].weight == 0
unless confirm[k]
dist[k] = dist[elem] + 1
confirm[k] = true
queue.push(k)
end
end
end
end
end
dist
end
def remove_candidates(i, bob)

# Decides which neighbors are removing candidates
bob[i].cc = clustering_coefficient(i, bob)
len = bob[i].neighbors.length
rc = []
(0...len).each do |j|
candidate = bob[i].neighbors.shift
cc_rc = clustering_coefficient(i, bob)
rc << candidate if cc_rc > bob[i].cc
bob[i].neighbors.push(candidate)
end
rc
end
end
A.5 empty.rb
O arquivo empty.rb é que permitirá a comunicação com o simulador Player/Stage, no
sentido de obter informações dos sensores, bem como enviar novos comandos aos robôs.
Note que o arquivo bigbob.rb é incluído aqui para permitir essa interação com os agentes.
A partir dele, é iniciada a comunicação com o simulador, determina-se o intervalo de
sincronização ao utilizar a biblioteca rufus-scheduler, escreve as saídas em arquivos textos
e deixa a simulação rodando sem parar.
#!/usr/bin/ruby
require ’rufus/scheduler’
require ’playercpp’
require ’bigbob’
radius = ARGV[0].to_i # Defines transmission range based on terminal params

pos, n_robots = get_position # Gets number of robots
# Create a client object and connect it

robot = Playercpp::PlayerClient.new(’localhost’) # Starts Player client
simulation = Playercpp::SimulationProxy.new(robot, 0) # Starts Simulation Proxy
scheduler = Rufus::Scheduler.new # Starts Time tracker
bob = []
# n_clusterheads = 2 # To calculate APL and CC without LSWTC
cc = 0
apl = 0
# Create proxies
(0...n_robots).each { |i| bob[i] = Bigbob.new(robot, i, 13+pos[i][0], 13+pos[i][1]) }
bob.each_index do |i|
bob[i].ID = i + 1
# bob[i].weight = 0 if i < n_clusterheads # To set a fix number of clusterhead for
# random simulation without LSWTC
end
thr = Array.new(n_robots, Thread.new { })
inital_time = Time.now.to_f
# Initializes .txt files with important data to analyze LSWTC performance

File.open(’output.txt’, ’w’) { |f| f.print "#{n_robots}" }
File.open(’apl.txt’, ’w’) { |f| f.print "#{n_robots}\n"}
File.open(’cc.txt’, ’w’) { |f| f.print "#{n_robots}\n" }
File.open(’ca.txt’, ’w’) { |f| f.print "#{n_robots}\n" }
File.open(’ch.txt’, ’w’) { |f| f.print "#{n_robots}\n" }
scheduler.every ’0.3s’ do
robot.Read() # Gets robot data from their sensors
File.open(’output.txt’, ’a’) do |f|

measured_time = Time.now.to_f
neigh = []
# Find the neighborhood for each robot

(0...n_robots).each { |i| bob[i].detecting_neighbors(i, radius, bob, n_robots, thr) }
# Applies Reckful Roaming algorithm over all robots

(0...n_robots).each { |i| neigh[i] = bob[i].reckful_roaming(i, bob) }
# Applies K-hop Clustering Coefficient algorithm over all robots

(0...n_robots).each { |i| bob[i].khopca(bob) }
cc = global_clustering_coefficient((0...n_robots).to_a, bob)
apl = average_path_length(bob)
f.print "\n"
(0...n_robots).each do |i| # Composes output .txt file
f.print "\n#{measured_time - inital_time}: #{i} %.3f %.3f %.3i" % \
[bob[i].pos_x, bob[i].pos_y, bob[i].weight]
f.print "\nNeighbors: "
neigh[i].each { |j| f.print "#{j} " }

# bob[i].neighbors.each { |j| f.print "#{j} " } # Without LSWTC
end
end
end
scheduler.every ’1s’ do
File.open(’apl.txt’, ’a’) { |f| f.print "\n#{apl}" } # Writes APL results
File.open(’cc.txt’, ’a’) { |f| f.print "\n#{cc}" } # Writes CC results
File.open(’ch.txt’, ’a’) do |f| # Writes number of clusterheads results
ch = 0
(0...n_robots).each { |i| ch += 1 if bob[i].weight == 0 }

f.print "\n#{ch}"
end
end
while true # Infinite loop for running the simulation

px = []
py = []
pa = []
(0...n_robots).each do |i|
unless thr[i].status
px[i] = bob[i].pp.GetXPos() + bob[i].x_start
py[i] = bob[i].pp.GetYPos() + bob[i].y_start
pa[i] = bob[i].pp.GetYaw()
new_x = (rand(26.0 * 2.0) + 1.0) / 2.0

new_y = (rand(26.0 * 2.0) + 1.0) / 2.0
# Sends the robot to a new random position into the simulation area
thr[i] = Thread.new { bob[i].go_to(new_x, new_y, px[i], py[i], pa[i]) }
end
end
end
A.6 clusterhead.rb
O presente arquivo é um auxiliar para calcular as médias da Average Path Length,
Clustering Coefficient e do número de clusterheads, imprimindo os resultados no próprio
terminal.
def number_of_clusterheads
# Calculates the average of clusterheads amount
afile = File.new(’ch.txt’)
lines = afile.readlines
len = lines.length
avg = 0.0
(2...len).each { |i| avg += lines[i].chomp.to_i }
afile.close
avg /= (len-2)
end
def cluster
# Calculates the average of global clustering coefficient
afile = File.new(’cc.txt’)
len = lines.length
avg = 0.0
count = 0
(2...len).each do |i|
avg += lines[i].chomp.to_f
count += 1 if lines[i].chomp.to_f > 0
end
avg /= count
end
def apl
# Calculates the average of Average Path Length
afile = File.new(’apl.txt’)
len = lines.length
avg = 0.0
count = 0
(2...len).each do |i|
avg += lines[i].chomp.to_f
count += 1 if lines[i].chomp.to_f > 0
end
avg /= count
end
# Prints in terminal window the result for averages of APL, CC, clusterheads
puts "CC = #{cluster}"
puts "APL = #{apl}"
puts "Clusterheads = #{number_of_clusterheads}"
77
B. Arquivos Libgosu
Uma vez realizada a simulação no Player/Stage, cabe agora visualizar a simulação do

ponto de vista do correto funcionamento do LSWTC. Para tanto, foi utilizada a biblioteca
libgosu. A sua instalação pode ser feita com o seguinte comando no terminal:
sudo gem install gosu
É sempre importante atentar às dependências exigidas, provavelmente a instalação

não se dará na primeira vez, alguns arquivos adicionais deverão ser instalados a priori.
Basicamente, o código gerado a partir da biblioteca Libgosu irá ler os traces do arquivo
de saída output.txt e construir o ambiente gráfico em torno deles. Além disso, os arquivos
que se seguem partem do princípio de que eles estão em um diretório no interior do
diretório dos arquivos do Player/Stage.
Para que todos os arquivos funcionem corretamente, é necessário ter 3 abas do terminal
simultaneamente abertas, sendo as duas primeiras no diretório dos arquivos Player/Stage
e a terceira no diretório do Libgosu. Por fim, executar os seguintes comandos:
1. ruby simulation.rb
2. ruby empty.rb
3. ruby teste.rb
B.1 circle.rb
O presente arquivo busca permitir o desenho de círculos na janela de simulação
APÊNDICE B. Arquivos Libgosu 78
class Circle # Class to draw a full circle in Gosu Library

attr_reader :columns, :rows
def initialize radius

@columns = @rows = radius * 2
lower_half = (0...radius).map do |y|
x = Math.sqrt(radius**2 - y**2).round
right_half = "#{"\xff" * x}#{"\x00" * (radius - x)}"
"#{right_half.reverse}#{right_half}"
end.join
@blob = lower_half.reverse + lower_half

@blob.gsub!(/./) { |alpha| "\xff\xff\xff#{alpha}"}
end
def to_blob
@blob
end
end
B.2 constants.rb
Todas as constantes a respeito da equivalência entre cores e pesos para o algoritmo
KHOPCA podem ser encontradas nesse arquivo.
COLORS = { #Hexadecimal colors code to represent nodes weight

:cyan => 0xFF00F7F1,
:blue => 0xFF0000FF,
:orange => 0xFFF69F00,
:yellow => 0xFFEAF800,
:green => 0xFF00FF00,
:purple => 0xFFB200F8,
:red => 0xFFFE0000,
:white => 0xFFFFFFFF,
:black => 0xFF000000
}.freeze
# Sequence of colors from the least weight to the great one

WEIGHT = [:red, :orange, :yellow, :green, :purple, :blue, :cyan, :white].freeze
B.3 teste.rb
O arquivo teste.rb é o principal para executar os códigos da biblioteca Libgosu. Ele
apresenta toda a lógica de como deve ser atualizada a disposição dos robôs a cada frame,
a remoção ou manutenção dos links após aplicação do algoritmo RR e a atualização dos
pesos através da mudança de cores dos robôs. Mas note que ele só garante que o arquivo
output.txt seja corretamente executado, a lógica da implementação do LSWTC se dá
inteiramente no Player/Stage.
require ’gosu’
require ’circle’
require ’constants’
class GameWindow < Gosu::Window
def initialize
# Runs on instance creation
@x = []
@y = []
@neighbors = []
@weight = []
@img = Hash.new
super(450, 450, false) # Creates the window where the simulation will appear
self.caption = "Gosu Tutorial Game"
afile = File.new("../output.txt")
@lines = afile.readlines
@len = @lines.length
@which_line = 2
@n_robots = @lines[0].chomp.to_i
end
def update
# Updated frames at a rate of 60hz
if @which_line < @len
(0...@n_robots).each do |i|
circle_with_numbers(i)
data = @lines[@which_line + 2*i].split
@x[i] = data[2].to_f * 14 + 15
@y[i] = data[3].to_f * 14 + 15
@weight[i] = data[4].to_i
data_neighbors = @lines[@which_line + 2*i + 1].split

data_neighbors.length == 1 ? @neighbors[i] = [] : @neighbors[i] \
= data_neighbors[1..data_neighbors.length]
end
@which_line += (@n_robots * 2 + 1)
end
end
def draw
# Function that draw all objects in simulation on every update

(0...@n_robots).each do |i|
draw_with_numbers(@x[i], @y[i], 3, i, WEIGHT[@weight[i]])
unless @neighbors[i].empty?
# Draws line between nodes in the same neighborhood
@neighbors[i].each { |j| draw_line(@x[i]+10, @y[i]+10, COLORS[:black], \
@x[j.to_i]+10, @y[j.to_i]+10 , COLORS[:black], 2)}
end
end
# Limits simulation area inside simulation window

draw_quad(0, 0, COLORS[:white], 0, 450, COLORS[:white], 450, \
450, COLORS[:white], 450, 0, COLORS[:white])
end
private
def circle_with_numbers(i)
# Creates a circle with a number inside representing its ID
@img[[i,0]] = Gosu::Image.new(self, Circle.new(10), true)
@img[[i,1]] = Gosu::Image.from_text(self, i+1, "Arial", 16, 15, 20, :center)
end
def draw_with_numbers(x, y, z, i, col)

# Draws the circle with numbers on the screen
@img[[i,0]].draw(x, y, z, factor_x = 1, factor_y = 1, color = COLORS[col])
@img[[i,1]].draw(x, y + 2, 10, factor_x = 1, factor_y = 1, COLORS[:black])
end
end
window = GameWindow.new
window.show
FOLHA DE REGISTRO DO DOCUMENTO
1. 2. 3. 4.
CLASSIFICAÇÃO/TIPO DATA REGISTRO N° N° DE PÁGINAS
TC 21 de novembro de 2013 DCTA/ITA/TC-076/2013 80

5.
TÍTULO E SUBTÍTULO:
Uma técnica local para manutenção de eficiência de comunicação em redes ad hoc de robôs móveis.
6.
AUTOR(ES):

7. INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):
Instituto Tecnológico de Aeronáutica – ITA

8. PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
Redes ad hoc-to-backbone; Redes Small-World; LSWTC; Robôs móveis; Eficiência de comunicação.
9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Redes ad hoc; Comunicação sem fio; Dinâmica de robôs; Redes de comunicação; Engenharia eletrônica.
10.
APRESENTAÇÃO: X Nacional Internacional
ITA, São José dos Campos. Curso de Graduação em Engenharia Eletrônica. Orientador: Prof. Dr. Carlos
Henrique Costa Ribeiro; coorientador: Prof Dr. Lorenzo Sabattini. Publicado em 2013.
11.
RESUMO:
Redes ad hoc-to-backbone móveis são uma importante configuração de rede, na qual os dispositivos
podem se deslocar livremente e servir de roteadores para transmissão de dados de um nó origem até o seu
destino final. Além disso, a conectividade da rede é garantida pelos ligações com o Backbone. Porém,
essas conexões apresentam um consumo de energia maior para os nós da rede, de tal modo que sempre é
melhor buscar informações a partir dos seus vizinhos. E com o intuito de otimizar a quantidade de
acessos ao Backbone foi desenvolvido o algoritmo LSWTC, que altera dinamicamente tais conexões
baseado apenas em informações locais. No presente trabalho, buscou-se estudar o algoritmo LSWTC e
implementá-lo em um simulador de robôs móveis para melhor entender como as interações físicas entre
os agentes e o ambiente influenciam no seu ganho de performance de comunicação. Para tanto, grandezes
como raio de transmissão, largura de simulação e distância mínima de aproximação apresentaram um
importante papel para identificar as dificuldades encontradas pelo LSWTC em aproximar a configuração
da rede de robôs a uma rede Small World. Os resultados experimentais demonstraram que não somente o
modelo de mobilidade escolhido para os nós tem a sua influência no ganho de Clustering Coefficient,
mas também o algoritmo de desvio apresenta um importante papel. Por fim, conclui-se que o LSWTC
cumpre bem o seu papel, independentemente dos nós serem robôs móveis ou não, restando saber como
otimizar os seus parâmetros físicos para se obter o ganho máximo de performance de comunicação da
rede.
12.
GRAU DE SIGILO:
(X ) OSTENSIVO ( ) RESERVADO ( ) CONFIDENCIAL ( ) SECRETO

Comunicacao Robos Moveis

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Comunicacao Robos Moveis

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO TECNOLÓGICO DE AERONÁUTICA

Rafael Rabelo de Carvalho

Uma técnica local para manutenção de eficiência de

Rafael Rabelo de Carvalho

Uma técnica local para manutenção de eficiência de comunicação

Divisão de Engenharia Eletrônica

SÃO JOSÉ DOS CAMPOS

Primeiramente, agradeço a Deus pelo dom da vida e inteligência, permitindo que eu

Redes ad hoc-to-backbone móveis são uma importante configuração de rede, na qual os

dispositivos podem se deslocar livremente e servir de roteadores para transmissão de dados

mais econômico buscar informações da vizinhança. E com o intuito de otimizar a quantidade

conexões baseado apenas em informações locais.

No presente trabalho, buscou-se estudar o algoritmo LSWTC e implementá-lo em um si-

o ambiente influenciam no seu ganho de performance de comunicação. Para tanto, grandezes

como raio de transmissão, largura de simulação e distância mínima de aproximação apresenta-

ram um importante papel para identificar a eficiência do LSWTC em aproximar a configuração

da rede de robôs em uma rede Small-World. Os resultados experimentais demonstraram que

performance de comunicação da rede em estudo.

In addition, network connectivity is assured by Backbone links. Nevertheless, these connections

even in a mobile robots simulator.

Figura 1 – Ilustração de uma rede ad hoc conectada . . . . . . . . . . . . . . . . . 21

Figura 3 – Distribuição de nós e conexões de redes regulares, small world e aleatórias 24

Figura 6 – Robôs real e sua versão simulada . . . . . . . . . . . . . . . . . . . . . 37

Figura 17 – APL com LSWTC e dmin variando de 0 a 5 . . . . . . . . . . . . . . . 49

Tabela 1 – Valores de densidades para l = 30 . . . . . . . . . . . . . . . . . . . . . 48

APL Average Path Length

CBTC Cone-Based Topology Control

JiST Java in Simulation Time

KHOPCA K-hop Clustering Coefficient

LMST Local Minimum Spanning Tree

LSWTC Local Small-World Topology Control Algorithm

ROS Robot Operation System

SWANS Scalable Wireless Ad hoc Network Simulator

USC University of Southern California

d(u, v) Distância entre os nós u e v

n Número total de nós da rede

dmin Distância mínima de aproximação permitida entre dois robôs

l Largura da área de simulação

r Raio de transmissão dos robôs

k Número máximo de saltos até um clusterhead

kK Peso máximo permitido a um nó

euv Aresta que liga os nós u e v

CCi Clustering Coefficient Local para o nó i

CC Clustering Coefficient Global

W (N (v)) Conjunto de pesos da vizinhança de v

O(n) Complexidade da Mensagem

Ginit Topologia da rede em estudo antes do LSWTC

GRR Topologia da rede em estudo após aplicação do RR

GKHOP CA Topologia da rede em estudo após aplicação do KHOPCA

GF inal Topologia da rede em estudo após o LSWTC

5 Resultados das Simulações . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Conclusões e Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . 60

APÊNDICE A Arquivos Player/Stage . . . . . . . . . . . . . . . . . . . . 64

APÊNDICE B Arquivos Libgosu . . . . . . . . . . . . . . . . . . . . . . . 77

A desenvolvimento da transmissão via wireless e o advento do uso de dispositivos

Embora a comunicação militar para formação tática é ainda considerada a primeira

os nós se comuniquem com o Backbone diretamente, devendo esses darem preferência

1.2 Plano de Trabalho

Com o ambiente computacional configurado, optou-se por utilizar a linguagem Ruby.

1.3 Estrutura do trabalho

No Capítulo 2, a idéia é apresentar um modelo matemático para redes wireless Ad hoc

No Capítulo 3, será apresentado a teoria de redes Small-World, com enfoque nos

No Capítulo 4, será apresentado todo o processo de instalação e configuração dos am-

No Capítulo 5, serão apresentados os resultados das simulações do algoritmo LSWTC