UMA INFRA-ESTRUTURA PARA EXPERIMENTA ¸C ˜AO COM ENXAMES DE ROB ˆOS
Renato F. Garcia∗, Luiz Chaimowicz∗
∗VeRLab – Laborat´orio de Vis˜ao e Rob´otica
Departamento de Ciˆencia da Computa¸c˜ao Universidade Federal de Minas Gerais
Belo Horizonte, MG, Brasil
Emails: {renatofg, chaimo}@dcc.ufmg.br
Abstract— The use of swarms of robots is a novel research area that has received much attention in recent
years. One of the great challenges in this area is the development of scalable experimental frameworks that can be used with large groups of robots. This paper presents the environment developed at VeRLab for swarm experimentation. We describe the hardware platform, programming interfaces and the localization mechanism used in the environment and present several experiments that demonstrate its utility.
Keywords— Robot Swarms, Experimentation.
Resumo— A utiliza¸c˜ao de enxames de robˆos ´e uma ´area de pesquisa emergente que tem recebido bastante
aten¸c˜ao nos ´ultimos anos. Um dos grandes desafios que surgem quando se trabalha com enxames ´e o
desen-volvimento de ambientes de experimenta¸c˜ao que sejam escal´aveis para um grande n´umero de robˆos. Esse artigo
apresenta o ambiente desenvolvido no VeRLab para a experimenta¸c˜ao com enxames de robˆos. S˜ao descritos os
mecanismos de programa¸c˜ao e localiza¸c˜ao desenvolvidos bem como a plataforma de hardware utilizada. Al´em
disso, diversos experimentos realizados com a infra-estrutura s˜ao apresentados de forma a demonstrar a sua
utilidade.
Keywords— Enxames de Robˆos, Experimenta¸c˜ao.
1 Introdu¸c˜ao
A rob´otica cooperativa ´e uma ´area que tem re-cebido bastante aten¸c˜ao nos ´ultimos anos. Re-sumidamente, trata-se da utiliza¸c˜ao de grupos de robˆos trabalhando de maneira coordenada na exe-cu¸c˜ao de diversas tarefas, trazendo ganhos de de-sempenho, uma maior tolerˆancia a falhas e pos-sibilitando a execu¸c˜ao de tarefas que n˜ao pode-riam ser realizadas por um ´unico robˆo. Dentro da rob´otica cooperativa, uma ´area nova e que tem atra´ıdo bastante interesse recentemente ´e a utiliza-¸
c˜ao de grupos compostos por um grande n´umero de robˆos mais simples, que individualmente n˜ao possuem muita capacidade, mas em conjunto po-dem realizar diversos tipos de tarefas. Esses gru-pos s˜ao genericamente chamados de “enxames”de robˆos (swarms). O uso de enxames de robˆos tem uma forte inspira¸c˜ao biol´ogica uma vez que diver-sas sociedades de animais e insetos requerem, de uma forma ou de outra, a coordena¸c˜ao de m´ ultip-los agentes. Por exemplo, a forma com que abel-has e formigas buscam alimento, ou a migra¸c˜ao de p´assaros normalmente requer a coordena¸c˜ao efi-ciente de um grande n´umero de indiv´ıduos.
Nos ´ultimos anos, pesquisadores do VeRLab - UFMG (Laborat´orio de Vis˜ao Computacional e Rob´otica da UFMG) tˆem desenvolvido diver-sos trabalhos no controle e coordena¸c˜ao de enx-ames de robˆos, por exemplo (Chaimowicz and Ku-mar, 2004; Chaimowicz et al., 2005; Marcolino and Chaimowicz, 2008; Hsieh et al., 2008). Em sua maioria, a parte experimental desses trabalhos ´e
feita atrav´es simula¸c˜oes devido `a falta de platafor-mas adequadas para a realiza¸c˜ao de experimen-tos. Entretanto, na rob´otica, ´e sempre importante que os algoritmos sejam validados em plataformas reais, de forma a testar a sua robustez frente `as dificuldades inerentes ao mundo real, tais como ru´ıdos nos sensores, falhas de comunica¸c˜ao, etc.
Esse artigo apresenta a infra-estrutura de hardware e software desenvolvida no VeRLab para a experimenta¸c˜ao com enxames de robˆos. Uti-lizando um conjunto de robˆos off-the-shelf, essa infra-estrutura integra diversas ferramentas para permitir a localiza¸c˜ao, programa¸c˜ao e controle de um grande n´umero de robˆos de forma simples, efi-ciente e escal´avel.
2 Trabalhos Relacionados
Apesar da grande importˆancia de se validar os al-goritmos de controle em plataformas reais, poucos trabalhos implementaram arcabou¸cos para testes reais com grandes grupos de robˆos.
Um destes arcabou¸cos foi desenvolvido no GRASP Laboratory – University of Pennsylva-nia (Michael et al., 2008). Nele s˜ao utilizados robˆos terrestres e a´ereos e a programa¸c˜ao ´e feita atrav´es do sistema Player (Gerkey et al., 2003). O modelo de robˆo terrestre utilizado ´e o Scarab, desenvolvido no pr´oprio laborat´orio e que apre-senta dimens˜oes de 20 × 13,5 × 22,2cm, o que pode ser um ponto negativo quando se usa um grande grupo de robˆos. O sistema de localiza¸c˜ao ´e feito por cˆameras instaladas de modo a terem
uma vis˜ao superior da cena, de onde buscam pelo brilho de LEDs instalados sobre os robˆos, sendo que estes os identificam de acordo com o padr˜ao com que piscam.
Um outro arcabou¸co ´e apresentado em (Schwager et al., 2008), que utiliza um grupo de robˆos SwarmBot na execu¸c˜ao de experimentos de dispers˜ao e cobertura. Um sistema de localiza¸c˜ao tamb´em baseado em LEDs ´e utilizado para ground thruth. J´a o trabalho de (Howard et al., 2006) n˜ao utiliza um sistema de localiza¸c˜ao centralizado em cˆameras e marcos visuais, como os dois ante-riores. Aqui toda a estima¸c˜ao das poses ´e feita a partir dos sensores dos pr´oprios robˆos, sendo que estes formam um time heterogˆeneo, com um menor n´umero de robˆos de alta capacidade de pro-cessamento e melhores sensores, e muitos robˆos mais simples. Os robˆos mais capazes tˆem a re-sponsabilidade de mapear a ´area e ajudar na ori-enta¸c˜ao dos outros.
Outros poucos trabalhos na literatura real-izam experimentos reais com enxames de robˆos. Entre eles pode-se mencionar (Correll et al., 2006), (Konolige et al., 2003) e (McLurkin and Smith, 2004).
A infra-estrutura apresentada nesse ar-tigo traz algumas contribui¸c˜oes importantes. Primeiramente, ela foca na integra¸c˜ao de compo-nentes j´a desenvolvidos, como robˆos off-the-shelf (e-pucks) e plataformas de programa¸c˜ao comu-mente utilizados (Player). Outro ponto impor-tante ´e que ela procura facilitar o processo de ex-perimenta¸c˜ao atrav´es de APIs e ferramentas que diminuem o trabalho do programador. Por fim, ´e importante mencionar que essa infra-estrutura para experimenta¸c˜ao com grandes grupos de robˆos ´e in´edita no Brasil, trazendo uma importante con-tribui¸c˜ao no contexto nacional.
3 Infra-estrutura 3.1 Robˆos
O primeiro passo para a constru¸c˜ao da infra-estrutura foi a escolha do robˆo a ser usado nos experimentos. Para esse tipo de experimenta¸c˜ao, os robˆos devem ser de pequeno porte e preferen-cialmente possuir mecanismos de sensoriamento e comunica¸c˜ao locais. Por exemplo, sensores infra-vermelhos ou de contato para detectar obst´aculos e mecanismos de comunica¸c˜ao sem fio tais como IEEE 802.11 ou bluetooth. Al´em disso, ´e dese-j´avel que os robˆos fa¸cam processamento on-board e sejam simples de programar e usar.
Devido a esses requisitos foi feita a op¸c˜ao pela aquisi¸c˜ao de robˆos j´a prontos (off-the-shelf). Especificamente, foram adquiridos doze robˆos e-puck (Cianci et al., 2007), projetado pela EPFL - Ecole Polytechnique F´ed´erale de Lausanne na Su´ı¸ca. O e-puck ´e um robˆo diferencial de pequeno
Figura 1: “Enxame” de 12 robˆos e-puck.
Figura 2: Detalhe de um dos robˆos.
porte (7cm de diˆametro) voltado para educa¸c˜ao e pesquisa. Ele possui um microprocessador DsPic de 16 bits, comunica¸c˜ao bluetooth, uma micro-cˆamera VGA, um conjunto de 8 sensores infraver-melhos, um acelerˆometro 3D, alto-falante e trˆes microfones, dois motores de passo para controle das rodas, um anel de leds para sinaliza¸c˜ao e ba-teria recarreg´avel LiIon de 3,6V e 1,4Ah. Para program´a-lo ´e disponibilizada uma biblioteca es-crita em linguagem C, que fornece uma API para se controlar os v´arios perif´ericos. Todo o projeto e-puck ´e aberto, os projetos mecˆanico e eletrˆonico do robˆo s˜ao licenciados como open hardware e a biblioteca C como open software.
Os doze robˆos adquiridos pelo VeRLab po-dem ser visto na Figura 1, com o detalhe de um robˆo mostrado na Figura 2. Apesar de 12 robˆos n˜ao poderem ser considerados efetivamente um “enxame”, esse n´umero j´a permite a valida¸c˜ao de experimentos realizados em simula¸c˜ao com um n´umero maior de robˆos.
3.2 Programa¸c˜ao
Para a programa¸c˜ao do enxame, foi desenvolvido um arcabou¸co que funciona sobre a Plataforma Player/Stage/Gazebo (Gerkey et al., 2003), uma das plataformas de programa¸c˜ao mais utilizadas na comunidade de pesquisa em rob´otica. A princi-pal caracter´ıstica desta plataforma ´e fornecer uma API com interfaces para v´arios tipos de sensores e atuadores, sendo que estas interfaces n˜ao s˜ao de-pendentes de nenhum robˆo ou perif´erico espec´ıfico. Desta forma, um programa que utiliza a API do Player pode ser executado em diferentes tipos de robˆos sem nenhuma, ou no m´aximo com poucas altera¸c˜oes. Al´em disso, este mesmo c´odigo pode ser usado em simula¸c˜oes no Stage ou no Gazebo, os simuladores (2D e 3D) do Projeto Player.
A plataforma Player comunica-se com os dis-positivos f´ısicos atrav´es de drivers espec´ıficos. No caso do e-puck, tal driver ainda n˜ao existia. Por-tanto foi desenvolvido um driver para converter os comandos recebidos do servidor Player para chamadas apropriadas da biblioteca de progra-ma¸c˜ao do e-puck. Atualmente o Player se encon-tra na vers˜ao 2.1 mas a vers˜ao anterior, 2.0, ainda tem uma grande base instalada, pois ´e esta que est´a dispon´ıvel nos reposit´orios Debian e Ubuntu por exemplo. Por este motivo, o driver constru´ıdo ´e compat´ıvel com aquelas duas vers˜oes, 2.0 e 2.1. Para que sejam acessados pelo programador, os diversos dispositivos presentes no e-puck de-vem ser mapeados atrav´es do driver para uma das v´arias interfaces oferecidas pelo Player. No driver implementado, os motores, juntamente com infor-ma¸c˜oes de odometria, s˜ao acessados atrav´es da in-terface position2d, que permite o acesso `a pose at-ual do robˆo, bem como suas velocidades.
Quanto aos LEDs, a interface para acess´a-los depende da vers˜ao do Player que ´e utilizada. Na vers˜ao 2.1 eles est˜ao ligados `a interface blinken-light, que representa algum indicador luminoso. Por´em, os LEDs do e-puck n˜ao possibilitam o uso de todas as funcionalidades que a interface blinkenlight oferece, j´a que eles possuem uma ´unica cor, e podem somente ser ligados ou desligados, n˜ao sendo poss´ıvel fazˆe-los piscar a uma dada fre-quˆencia. J´a na vers˜ao 2.0 do Player, a interface blinkenlight ainda n˜ao estava dispon´ıvel, portanto a interface opaque foi utilizada. Esta ´e uma in-terface gen´erica, que pode ser usada quando nen-huma das outras op¸c˜oes for adequada.
Os dois ´ultimos perif´ericos interfaceados s˜ao a cˆamera e o infravermelho. A cˆamera usa a in-terface camera, e todas as informa¸c˜oes de configu-ra¸c˜ao que s˜ao necess´arias para a sua inicializa¸c˜ao podem ser informadas no arquivo de configura¸c˜ao do Player, na se¸c˜ao referente a este driver. Os sen-sores infravermelhos de proximidade usam a inter-face ir, de onde ´e poss´ıvel obter tanto os valores brutos lidos, quanto a distˆancia estimada dos ob-st´aculos percebidos. Outros dispositivos como os alto-falantes e os microfones ainda n˜ao foram in-terfaceados no driver, e a sua inclus˜ao ´e planejada para as futuras vers˜oes do driver.
3.3 Comunica¸c˜ao
O driver desenvolvido ´e divido em duas partes: uma ´e executada em um computador remoto jun-tamente com o Player e a outra ´e executada on-board no processdor dsPIC do e-puck. A comu-nica¸c˜ao entre estas duas partes ´e feita utilizando o protocolo bluetooth RFCOMM, que emula uma porta serial.
A parte do driver que ´e executada no e-puck foi projetada para realizar a menor carga de pro-cessamento poss´ıvel. A sua responsabilidade ´e
ba-sicamente receber os comandos do computador e chamar as fun¸c˜oes apropriadas da API do e-puck. Para a movimenta¸c˜ao por exemplo, a velocidade que cada cada um dos motores dever´a ter ´e re-cebida j´a em passos por segundo, e em seguida atribu´ıda aos motores. O c´alculo das posi¸c˜oes estimadas dos obst´aculos, percebidos pelo sen-sor infra-vermelho, tamb´em n˜ao ´e feito aqui, as leituras s˜ao enviadas para a outra parte do driver sem processamento.
A parte do driver que ´e executada no com-putador tem a responsabilidade de receber os co-mandos do programa no formato dado pelo Player, traduzir para um formato mais pr´oximo do esper-ado API do e-puck e enviar para a outra parte do driver. Inversamente, ele tamb´em recebe as leituras dos sensores enviadas pelo e-puck, as pro-cessa e repassa ao Player no formato esperado pela interface apropriada.
J´a a comunica¸c˜ao entre diferentes e-pucks ´e feita atrav´es de mecanismos de comunica¸c˜ao in-terprocessos do sistema operacional rodando nos computadores remotos. A principal raz˜ao para isso ´e o fato que o bluetooth dos e-pucks j´a est´a pareado com o computador em que o driver est´a sendo executado, n˜ao podendo, portanto ser uti-lizado na comunica¸c˜ao direta entre eles. Al´em disso, uma vez que todo o processamento dos da-dos que foram coletada-dos pelos sensores do robˆo ´e feito pela parte do driver que fica no computador e ´e tamb´em l´a que est´a o programa que ir´a de fato control´a-los, ´e natural que esta comunica¸c˜ao entre robˆos seja feita em um n´ıvel mais alto.
´
E importante mencionar que cada e-puck ´e controlado por um programa independente (nor-malmente v´arias instˆancias de um mesmo grama) e a plataforma Player permite o pro-cessamento distribu´ıdo de forma completamente transparente. Dessa forma, cada e-puck pode ser controlado por um computador diferente ou por m´ultiplas threads em um mesmo computador.
3.4 Sistema de Localiza¸c˜ao
Dado que o ambiente desenvolvido tem como fi-nalidade a realiza¸c˜ao de experimentos com enx-ames de robˆos, h´a frequentemente a necessidade de se conhecer com precis˜ao a pose de cada um dos componentes deste enxame. Para alcan¸car este objetivo foi constru´ıdo o Silver (Sistema de Localiza¸c˜ao VeRLab), que fornece esta localiza¸c˜ao utilizando cˆameras de v´ıdeo fixadas no teto do lab-orat´orio, e cujos campos de vis˜ao cobrem toda a ´
area de atua¸c˜ao dos robˆos. Para serem localiza-dos, cada um dos robˆos carrega um marco visual, pois a partir das imagens obtidas pelas cˆameras estes ser˜ao identificados. Cada uma das cˆameras ´e previamente calibrada com uma transforma¸c˜ao homogr´afica (Trucco and Verri, 1998) permitindo-se obter a popermitindo-se de cada robˆo.
O Silver ´e composto por trˆes m´odulos: silver-server, silver-cameras e silver-client. Cada um de-les ´e independente dos demais, no sentido de que s˜ao programas separados, possivelmente executa-dos em computadores diferentes. Toda a troca de dados entre eles ´e feita atrav´es de uma rede, us-ando o protocolo IP.
O m´odulo silver-cameras ´e um programa que controla a aquisi¸c˜ao das imagens pelas cˆameras, e a extra¸c˜ao das poses a partir dos marcos iden-tificados nelas. Ele pode ser instanciado si-multaneamente em quantos computadores forem necess´arios, e cada uma de suas instˆancias pode controlar qualquer n´umero de cˆameras, o limite sendo a capacidade do computador.
O m´odulo silver-server deve ser instanciado uma ´unica vez. Ele processa os dados obtidos pelas instˆancias dos silver-cameras, por exemplo eliminando duplicidades caso um mesmo marco tenha sido identificado por duas cˆameras em ´areas de interse¸c˜ao, e envia os resultados aos clientes.
Finalmente, o m´odulo silver-client ´e o com-ponente que recebe as poses desejadas do silver-server, e as entrega a algum programa do usu´ario. Atualmente existem duas implementa¸c˜oes deste m´odulo: a primeira na forma de uma biblioteca C++, que fornece uma API para ser usada pelo programa que ir´a receber as localiza¸c˜oes; e uma segunda como um driver do Player, que fornece a interface fiducial com as localiza¸c˜oes.
Uma vers˜ao preliminar desse sistema de lo-caliza¸c˜ao foi apresentado em (Garcia et al., 2007) onde foi demonstrado que o sistema ´e escal´avel para o uso com uma grande quantidade de robˆos. Naquela ocasi˜ao foram feitos testes nos quais at´e quarenta marcos foram localizados com sucesso, simultaneamente a 30 fps. Desde ent˜ao v´arias mel-horias foram feitas. Dentre as principais podemos citar uma maior modularidade do c´odigo, facili-tando o acr´escimo de novos modelos de cˆameras, novos tipos de marcos, e a possibilidade de se cal-cular a transforma¸c˜ao homogr´afica usando uma lookup table, ao inv´es do c´alculo usando uma ma-triz. Outro acr´escimo foi o m´odulo silver-client implementado como um driver Player, tornando mais homogˆeneo o acesso ao v´arios componentes do ambiente de experimenta¸c˜aoo.
´
E interessante mencionar tamb´em que o sis-tema desenvolvido pode ser usado n˜ao s´o para a localiza¸c˜ao dos robˆos durante a execu¸c˜ao mas tamb´em como um mecanismo de ground thruth, armazenando-se as trajet´orias de cada robˆo e fazendo uma an´alise ap´os a execu¸c˜ao.
4 Testes Preliminares
Para testar a interface de acesso aos sensores e atuadores dos e-pucks atrav´es do driver desen-volvido para o Player e a integra¸c˜ao do mecanismo
0.50 0.45 0.40 0.35 0.30 0.25 0.20 0.15 0.10 0.05 X (m) 0.20 0.15 0.10 0.05 0.00 0.05 0.10 0.15 0.20 0.25 Y (m)
Silver (Ground truth) Odometria
Figura 3: Ida e volta do e-puck a um ponto.
(a) Experimento montado.
0.25 0.20 0.15 0.10 0.05 0.00 0.05 0.10 0.15 X (m) 0.3 0.2 0.1 0.0 0.1 0.2 0.3 0.4 0.5 Y (m)
(b) Trajet´oria percorrida pelo e-puck.
Figura 4: Desvio de obst´aculo utilizando os sen-sores infravermelhos.
de localiza¸c˜ao, foram realizados alguns testes pre-liminares utilizando apenas um robˆo.
O teste mais simples consistiu de deslocar o e-puck para um ponto que se encontrava 40cm `a frente e 40cm `a direita de sua posi¸c˜ao inicial e, ao chegar l´a, retornar de volta `a origem. A estima¸c˜ao da pose durante o trajeto foi feita somente com a odometria, e o Silver foi usado como um ground truth. O gr´afico mostrando a trajet´oria pode ser visto na figura 3. Nele, o in´ıcio e o fim do trajeto n˜ao coincidem exatamente pois a implementa¸c˜ao considera que se alcan¸cou o destino caso se esteja a uma distˆancia de pelo menos 3cm dele.
No segundo teste o e-puck deveria ir a um ponto que em princ´ıpio poderia ser alcan¸cado deslocando-se em linha reta. Por´em, no caminho havia um obst´aculo desconhecido pelo robˆo, que deveria ser percebido pelos seus sensores infraver-melhos. O obst´aculo seria ent˜ao transposto pelo e-puck utilizando o algoritmo de bug. A montagem do experimento pode ser vista na figura 4(a), e o caminho percorrido pelo robˆo na figura 4(b).
5 Experimenta¸c˜ao com Enxames A infra-estrutura montada j´a est´a sendo utilizada para a realiza¸c˜ao de experimentos com enxames de robˆos. Um exemplo ´e o desenvolvimento de algoritmos distribu´ıdos para o controle de tr´afego de um grande n´umero de robˆos (Marcolino and Chaimowicz, 2009). A ideia geral do algoritmo ´e que os primeiros robˆos a perceberem o risco de um congestionamento avisem os outros, permitindo-os atualizar dinamicamente a trajet´oria de forma a evitar o problema.
Sempre que um robˆo detecta a presen¸ca de outro, ele envia uma mensagem avisando qual ´e sua dire¸c˜ao de destino. Assim, caso as dire¸c˜oes de destino sejam diferentes, os robˆos s˜ao capazes de perceber o risco iminente de um congestion-amento. Os robˆos que perceberam o risco de um congestionamento enviam uma mensagem aos seus vizinhos. Cada robˆo, ao receber essa men-sagem, a retransmite para seus respectivos viz-inhos. Dessa forma, a informa¸c˜ao do risco de um congestionamento ´e transmitida pelo enxame e cada grupo poder´a desviar de forma apropriada. Assim que um robˆo percebe esse risco, seja encon-trando um robˆo do outro grupo, seja pelo aviso de outros robˆos de seu pr´oprio grupo, ele desvia do local onde aconteceria o problema. Para re-alizar o desvio, o robˆo utiliza como base a dire¸c˜ao de seu destino. Pode-se especificar, por exemplo, que cada robˆo desviar´a no sentido anti-hor´ario.
Primeiramente foram realizados simula¸c˜oes desse algoritmo utilizando o simulador Stage. Uma sequˆencia de snapshots de uma simula¸c˜ao pode ser vista na Figura 5. Quatro grupos de robˆos devem navegar em dire¸c˜oes opostas no cen´ario. Como pode ser observado, os grupos circularam em torno da regi˜ao onde aconteceria o congestionamento, e todos conseguiram chegar de uma forma suave e eficiente no alvo proposto. Tamb´em foi realizada uma an´alise experimen-tal em simula¸c˜ao, onde comparou-se o algoritmo com uma execu¸c˜ao convencional, utilizando ape-nas for¸cas de repuls˜ao. Essa an´alise foi realizada com um intervalo de confian¸ca de 95% e mostrou um ganho no tempo de convergˆencia de 40%.
Ap´os a simula¸c˜ao, foram realizadas diversas execu¸c˜oes reais desse algoritmo utilizando a infra-estrutura desenvolvida. Praticamente o mesmo programa utilizado nas simula¸c˜oes pode ser us-ado nos robˆos reais gra¸cas ao uso da plataforma Player. Os snapshots de uma execu¸c˜ao com quatro grupos podem ser vistos na Figura 6. E-pucks com os leds acesos est˜ao desviando da regi˜ao de conges-tionamento. Os gr´aficos abaixo de cada imagem mostram as posi¸c˜oes dos robˆos obtidas pelo sis-tema de localiza¸c˜ao bem como o seu estado (des-viando ou n˜ao).
A realiza¸c˜ao deste experimento foi importante pois demonstrou na pr´atica a viabilidade da
infra-estrutura, onde os doze robˆos, juntamente com o sistema de localiza¸c˜ao foram utilizados com sucesso. Mais detalhes sobre esse algoritmo e os resultados experimentais podem ser obtidos em (Marcolino and Chaimowicz, 2009).
6 Conclus˜ao
A realiza¸c˜ao de experimentos reais ´e de suma im-portˆancia para a valida¸c˜ao de resultados obtidos em simula¸c˜ao. Esse artigo apresentou uma infra-estrutura para a experimenta¸c˜ao com grandes gru-pos de robˆos. A infra-estrutura engloba um con-junto de robˆos off-the-shelf, uma plataforma de programa¸c˜ao constru´ıda sobre o Player, mecan-ismos de comunica¸c˜ao sem fio, e um sistema de localiza¸c˜ao que permite a obten¸c˜ao da pose dos robˆos em tempo de execu¸c˜ao. Essa plataforma ´e in´edita no Brasil e tem permitido o estudo e experimenta¸c˜ao de diversos algoritmos para grandes grupos de robˆos no Laborat´orio de Vis˜ao e Rob´otica do DCC-UFMG (VeRLab).
Como trabalhos futuros pretende-se incre-mentar a infra-estrutura com a implementa¸c˜ao de novas funcionalidades (por exemplo, uma inter-face para acompanhamento e controle dos m´ ulti-plos robˆos em tempo real) al´em de continuar utilizando-a na experimenta¸c˜ao de novos algorit-mos de coordena¸c˜ao e controle de enxames.
Agradecimentos
Os autores gostariam de agradecer a Pedro Shi-roma, pelo aux´ılio no desenvolvimento do sis-tema de localiza¸c˜ao, e a Leandro Marcolino, pelo desenvolvimento e experimenta¸c˜ao do algoritmo mostrado na Se¸c˜ao 5. Esse trabalho foi parcial-mente financiado pela Fapemig e CNPq.
Referˆencias
Chaimowicz, L. and Kumar, V. (2004). Aerial shepherds: Coordination among uavs and swarms of robots, Proc. of the 7th In-ternational Symposium on Distributed Au-tonomous Robotic Systems (DARS 2004), pp. 231–240.
Chaimowicz, L., Michael, N. and Kumar, V. (2005). Controlling swarms of robots using interpolated implicit functions, Proc. of the 2005 IEEE International Conf. on Robotics and Automation, pp. 2498–2503.
Cianci, C. M., Raemy, X., Pugh, J. and Martinoli, A. (2007). Communication in a Swarm of Miniature Robots: The e-Puck as an Educa-tional Tool for Swarm Robotics, Simulation of Adaptive Behavior (SAB-2006), Swarm Robotics Workshop, Lecture Notes in Com-puter Science (LNCS), pp. 103–115.
Figura 5: Simula¸c˜ao do algoritmo de controle de tr´afego utilizando o Stage. −0.5 0 0.5 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 (a) −0.5 0 0.5 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 (b) −0.5 0 0.5 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 (c) −0.5 0 0.5 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 (d) −0.5 0 0.5 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 (e) −0.5 0 0.5 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 (f)
Figura 6: Experimenta¸c˜ao real utilizando a infra-estrutura desenvolvida.
Correll, N., Rutishauser, S. and Martinoli, A. (2006). Comparing coordination schemes for miniature robotic swarms: A case study in boundary coverage of regular structures, Proc. of the International Symposium on Ex-perimental Robotics (ISER).
Garcia, R. F., Shiroma, P. M., Chaimowicz, L. and Campos, M. F. M. (2007). Um arcabou¸co para a localiza¸c˜ao de enxames de robˆos, VIII Simp´osio Brasileiro de Automa¸c˜ao In-teligente (SBAI 2007), SBA.
Gerkey, B. P., Vaughan, R. T. and Howard, A. (2003). The player/stage project: Tools for multi-robot and distributed sensor systems, 11th International Conference on Advanced Robotics (ICAR 2003).
Howard, A., Parker, L. E. and Sukhatme, G. S. (2006). Experiments with a large hetero-geneous mobile robot team: Exploration, mapping, deployment and detection, Inter-national Journal of Robotics Research 25(5-6): 431–447.
Hsieh, M. A., Chaimowicz, L. and Kumar, V. (2008). Decentralized controllers for shape generation with robotic swarms, Robotica 26: 691–701.
Konolige, K., Ortiz, C., Vincent, R., Agno, A., Eriksen, M., Limketkai, B., Lewis, M., Briesemeister, L., Ruspini, E., Fox, D., Ko, J., Sftewart, B. and Guibas, L. (2003). Large-scale robot teams, Multi-Robot Sys-tems: From Swarms to Intelligent Autonoma, Kluwer Academic Publishers.
Marcolino, L. S. and Chaimowicz, L. (2008). No robot left behind: Coordination to overcome local minima in swarm navigation, Proc. of the 2008 IEEE International Conf. on Robotics and Automation.
Marcolino, L. S. and Chaimowicz, L. (2009). Traf-fic control for a swarm of robots: Avoiding group conflicts, Proc. of the 2009 IEEE In-ternational Conf. on Intelligent Robots and Systems.
McLurkin, J. and Smith, J. (2004). Distributed algorithms for dispersion in indoor environ-ments using a swarm of autonomous mobile robots, Proc. of the 7th International Sym-posium on Distributed Autonomous Robotic Systems (DARS 2004).
Michael, N., Fink, J. and Kumar, V. (2008). Experimental testbed for large multirobot teams, Robotics & Automation Magazine, IEEE 15(1): 53–61.
Schwager, M., McLurkin, J., Slotine, J. J. E. and Rus, D. (2008). From theory to practice: Dis-tributed coverage control experiments with groups of robots, Proc. of International Sym-posium on Experimental Robotics, Athens, Greece.
Trucco, E. and Verri, A. (1998). Introductory Techniques for 3-D computer Vision, Pren-tice Hall.
