Anais do XIX Congresso Brasileiro de Automática, CBA 2012.

INTEGRAÇÃO ENTRE SOFTWARE DE PLANEJAMENTO DE TAREFAS DE MOVIMENTAÇÃO E

O ROBÔ MÓVEL ROBOTINO

LARISSA LEME RESENDE, KLEBER R. S. SANTOS

Centro de Referência em Tecnologias da Informação, Instituto de Engenharia de Sistemas e Tecnologias da

Informação, Universidade Federal de Itajubá
Av. BPS, 1303. Itajubá-MG
E-mails: larissa.lresende@gmail.com, santoskr@unifei.edu.br

Abstract - This paper presents the integration of software for route planning, as developed for locomotion and accomplishment
of tasks of a mobile platform, until then simulated in a virtual environment with the development of routines to drive mobile ro-
bots. Using a mobile platform developed by FESTO®, Robotino called for testing and investigation of targets.

Keywords - Mobile Robots, Robotino, Planning, Integration.

Resumo - Este artigo apresenta a integração de um software de planejamento de rotas, já desenvolvido, para a locomoção e reali-
zação de tarefas de uma plataforma móvel, até então simulada em ambiente virtual; com o desenvolvimento de rotinas de movi-
mentação para robôs móveis. Utilizando-se a plataforma móvel desenvolvida pela FESTO®, denominada Robotino, para realiza-
ção de testes e averiguação de objetivos.

Palavras-chave - Robôs móveis, Robotino, planejamento de tarefas, integração.

1 Introdução FESTO® Ltda, se movimente em um ambiente par-

cialmente conhecido, executando as tarefas planeja-
das.
O desenvolvimento inicial dos robôs baseou-se
no esforço de automatizar as operações industriais.
Este esforço começou no século XVIII, na indústria 2 Materiais e Métodos
têxtil, com o aparecimento dos primeiros teares me-
cânicos. Com o contínuo progresso da revolução 2.1 – Robotino
industrial, as fábricas procuraram equipar-se com
máquinas capazes de realizar e reproduzir, automati- O Robotino é um robô móvel desenvolvido pela
camente, determinadas tarefas. empresa FESTO® Ltda., (Figura 1), com o propósito
Hoje a robótica faz parte de nosso dia a dia, seja didático de oferecer ao usuário um primeiro contato
na fabricação de bens de consumo ou no desenvol- com uma tecnologia que pode ser aplicada princi-
vimento da medicina. Com base neste avanço, surge palmente na área de automação industrial.
a possibilidade de substituir o trabalho humano para O Robotino é equipado com um sistema de dire-
torná-lo mais seguro ou simplesmente evitar o traba- ção omnidirecional e uma câmera com altura e incli-
lho repetitivo (Odaguil e Piesco, 2010). nação ajustáveis. Com a câmera é possível exibir
imagens em tempo real com a ajuda do software
Um exemplo é a substituição de tarefas de trans- Robotino View. A câmera utiliza conexão USB e tem
porte, isso pode ser realizado atualmente através de resolução máxima para vídeo de 640x480 pixels e de
robôs conhecidos como AVG’s (Automated Guided 1024x768 para captura de imagem, armazenadas em
Vehicle Systems), capazes de se locomover geralmen- formato BMP ou JPG.
te, por meio da orientação de uma linha (follow line).
Uma evolução dos AGV’s são os chamados
AIV’s (Automated Intelligent Vehicle Systems),
veículos autônomos inteligentes. Robôs que utilizam
técnicas de inteligência artificial para planejar e rea-
lizar sua movimentação, sem a utilização de guias.
Utilizando-se de softwares de planejamento de ações
com atribuição de valores, capacidade de busca e
reconhecimento de obstáculos. Ao se integrar estes
softwares junto ao controle de locomoção do robô é
possível que ele realize tarefas de maneira inteligente
e autônoma.
Com base nestes conceitos este trabalho visa integrar
o software de planejamento de tarefas, desenvolvido
Figura 1 – Robotino
pelo professor Kleber Santos (Santos, 2009), ao
software de movimentação. De maneira que a plata-
forma móvel Robotino, desenvolvida pela empresa

ISBN: 978-85-8001-069-5 4076

 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.

2.2 – Matlab modelos, ricos em conhecimento, de diversos domí-

MATLAB (MATrix LABoratory) é um software
interativo de alta performance voltado para o cálculo
numérico. Ele integra análise numérica, cálculo com
matrizes, processamento de sinais e construção de
gráficos, onde problemas e soluções são expressos
somente como eles são escritos matematicamente.
O Robotino possui uma versão de ferramentas (Tool-
box) exclusiva para uso do MatLab, que permite a
programação, simulação, verificação de erros e con-
trole do robô pelo próprio programa. Por apresentar
uma versatilidade e uma gama maior de opções que o
programa básico oferecido pela Festo, o RobotinoVi-
ew, como a possibilidade de integrar a supervisão de
sensoriamento e de locomoção ao mesmo tempo,
optou-se por utilizar o Matlab para a criação do pro-
grama base de locomoção para o Robotino, obtido
em (Forum Robotino, 2011).
2.3 – Software de planejamento de trajetórias:
nios de planejamento reais através de diagramas
UML.
A partir da modelagem em UML, o software é
capaz de gerar o código em linguagem PDDL que
represente o domínio e o problema de planejamento
que se deseje desenvolver, podendo o programa em
PDDL ser carregado em um software de planejamen-
to (Planejador), para obtenção da solução do proble-
ma em questão.
2.3.C – Criação de Mapas
Um mapa do ambiente foi criado a partir de uma
planta baixa das dependências do andar térreo do
prédio da Engenharia Elétrica da UNIFEI – Univer-
sidade Federal de Itajubá, com dimensões reais, utili-
zando o software Mapper3Basic. O mapa utilizado
para este trabalho é representado na Figura 2, criado
por (Santos, 2009).

Para a determinação de tarefas, mapas e rotas

neste trabalho, utilizou-se como base a dissertação de
mestrado do professor da Unifei, Kleber Santos. Sua
dissertação consiste na criação de um software capaz
de planejar a execução de tarefas, para a movimenta-
ção de robôs. Porem, este software foi testado so-
mente em robôs simulados, portanto não houve testes
em plataformas reais.
O software desenvolvido utilizava diversas ferramen-
tas, que através de mapas compilados, consegue
planejar tarefas de movimentação e a melhor rota a
ser executada para a ação final. Para isto, o software
utiliza um criador de domínio de problemas (em
linguagem pddl). Uma vez com o domínio criado
(mundo de planejamento criado), as informações são
passadas para um planejador para gerar a sequência
de tarefas a serem executadas. Mais detalhes podem
ser encontrados em (Santos, 2009).

2.3.A –Aria e AriaNetworking:

ARIA (Advanced Robotics Interface for Applica-

tions) é uma base de desenvolvimento de fonte aber-
ta, para uma variedade de sistemas integrados aos
robôs.
A interface de comunicação pode ser feita pela
biblioteca ARNetworking, fornecendo o desenvolvi- Figura 2 – Mapa utilizado, (Santos, 2009)
mento da camada TCP/IP base para a comunicação
com a plataforma através da rede.
Embora tenha sido utilizado na tese de mestrado
na qual se baseia este artigo, para testes de validação 2.3.D – Planejador de Ações (FF)
da metodologia, o objetivo deste trabalho é substituir
esta biblioteca a fim de que as tarefas possam ser Planejadores de tarefas são softwares que geram
utilizadas em plataformas reais. uma lista de tarefas a serem realizadas para se atingir
um objetivo pré-estabelecido, utilizando-se para isso
2.3.B – Criador de Domínio e Problema de Pla- de um modelo do domínio e problema de planeja-
nejamento (Itsimple) mento desenvolvidos em uma linguagem de plane-
jamento como a PDDL.
O software itSIMPLE é um software de código O planejador utilizado neste trabalho foi o FF, a-
aberto (Open Source) que possibilita a criação de crônimo para Fast Forward. Esta busca é orientada

ISBN: 978-85-8001-069-5 4077

 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.

por uma função heurística que estima a distância da

solução em relação ao estado inicial. O FF ao encon-
trar um resultado para o problema gera uma lista de
ações que pode ser impressa na tela do computador
ou armazenada em um arquivo em formato texto.

3 Procedimento

O desenvolvimento deste projeto pode ser dividi-

do em duas partes, o controle de movimentação do
Robotino e a integração com o software de planeja-
mento, concluindo-se com a união e sincronismo
destas duas etapas.
O software de planejamento inicialmente, ao ge-
rar o resultado, enviava as tarefas para que o ARIA o
executasse. Neste trabalho os resultados são lidos
pelo Matlab que por comunicação ao Robotino exe-
cuta as tarefas.
Portanto, do software criado na dissertação do
professor Kleber Santos (Santos, 2009), foi separada
a rotina de planejamento da rotina de execução. Sen-
do a rotina de execução realizada pelo Robotino e as
rotinas de movimentação criadas no Matlab.

3.1 – Software de planejamento e tratamento de

trajetória

Para o planejamento e criação de trajetória, utili-

zou-se o software desenvolvido na tese de mestrado
do professor Kleber Santos. Através da modelagem e
de um software planejador independente do domínio,
é gerado uma lista de ações a serem executadas (“Ge-
rador de Planos”), sendo esta armazenada e direcio-
nada para a execução correta (“Decisão e Armazena-
gem da Lista de Tarefas”). Um esquemático sequen-
cial de seu funcionamento é observado na Figura 3.
Com o “Gerador de Rotas” os planos são detalha-
dos para que o robô possa executá-los, este detalha-
mento utiliza o conhecimento que o robô tem do
ambiente a qual está inserido. Os mapas do ambiente
a ser explorado são fornecidos por meio de mapas
compilados inseridos ao processamento.
O domínio de planejamento foi criado a partir de
uma ferramenta de modelagem chamada itSIMPLE,
esta ferramenta permite a geração do código em
PDDL a partir de diagramas UML (Unified Modeling
Language). Nestes diagramas são criadas classes de
elementos que compõem o domínio de planejamento,
suas relações, ações e efeitos podem ser aplicadas
para gerar modificações no estado atual do sistema.
Figura 3 – Diagrama explicativo do funcionamento do Sistema de
Navegação Autônomo, (Santos, 2009)
Após a tradução dos diagramas é necessário esco-
lher um programa planejador, neste caso o FF (Fast-
Forward), para executar a busca por uma lista de
ações, um plano, que realize o objetivo esperado
mediante as condições iniciais.
Para desenvolvimento do planejamento topológi-
co da trajetória, o software se utiliza do algoritmo A*
(A star, ou A estrela). Baseado em planejar a trajetó-
ria por meio de busca e expansão com pesos para as
melhores opções. Para simplificar sua utilização,
quando o robô ingressa em um novo ambiente, ou
sala, o algoritmo é aplicado para achar a melhor
trajetória para a próxima sala de acordo com o plane-
jador de sequência a ser tomada.
A partir destes processos, há então a geração de
uma lista de ações a serem tomadas que seriam envi-
adas ao simulador da biblioteca Aria. Porém, a partir
deste ponto, como mostrada na Figura 4, o projeto se
diferencia. A lista de tarefas são convertida para um
formato .txt contendo as coordenadas necessárias
para a locomoção e realização das tarefas. Elas, en-
tão, são chamadas por uma função do Matlab, que
fica responsável pela sequência de movimentação do
Robotino.

ISBN: 978-85-8001-069-5 4078

 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.

3.2.A – Movimentação

O Matlab por meio de uma chamada de funções,

lê o .txt gerado pelo software de planejamento, con-
tendo as coordenadas de movimentação. Ao captar as
informações, faz a conversão das coordenadas para o
referencial do Robotino. Pois o que o software de
planejamento estipula como coordenadas (x,y) para o
Robotino são (-y,x). Mostrado na Figura 5.

Figura 4 – Área alterada no diagrama explicativo do funcionamen-

to do Sistema de Navegação Autônomo para a comunicação com o
Robotino Figura 5 – eixo cartesiano do Robotino

Uma vez convertidas as coordenadas, as variáveis

3.2 – Rotinas de Movimentação e sensoriamento do são analisadas para gerar o movimento. Por exemplo,
Robotino caso o Robotino deva mover-se apenas para frente,
somente para a direita ou para um movimento verti-
A movimentação do Robotino deve ser progra- cal (frente e esquerda). O esquema de sentido e mo-
mada de modo que, não apenas ele se movimente em vimentação pode ser explicado pelo fluxograma da
todas as direções com velocidade e coordenadas Figura 6.
definidas, mas também seja capaz de realizar desvios
de objetos encontrados no decorrer do percurso.
As rotinas do Aria e AriaNet, são rotinas de mo-
vimentação ponto a ponto e de desvio de obstáculo.
Para substituir estas rotinas foram feitas duas etapas
no Matlab, a de movimentação e a de desvio de obs-
táculos.
A etapa de movimentação se utiliza dos sensores
de Odometria (encoders), que auxiliam na execução
das ações deliberativas de movimentação, captando
as posições da locomoção do robô. Enquanto os
sensores infravermelhos são utilizados na execução
das ações reativa do robô, detectando a aproximação
de objetos não especificados no mapa de rotas e
gerando uma rotina de desvio. As duas partes combi-
nadas são responsáveis pela locomoção do robô.
Inicialmente o robô recebe a informação, do
software de planejamento, do ponto final para o qual
ele deve se locomover. Ele calcula a distancia entre o
ponto presente e o ponto final, traçando uma trajetó-
ria retilínea pela qual ele deve percorrer. Esta ação é
considerada deliberativa. Ao iniciar a locomoção,
caso ele se depare com um obstáculo, os sensores são Figura 6 – fluxograma de movimentação do Robotino
ativados e o desvio de trajetória estipulado é realiza-
do, caracterizando uma ação reativa. Após o desvio, 3.2.B – Sensoriamento
novamente é calculado uma trajetória retilínea para
se atingir o ponto final. O sistema de desvio de obstáculos para que o Ro-
botino locomova-se sem dificuldades entre o territó-
rio planejado, ocorre devido aos 9 sensores infraver-
melhos dispostos a 40º de distancia entre si em torno
do robô. Uma vez ativados os sensores, uma diferen-

ISBN: 978-85-8001-069-5 4079

 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.
ça de potencial (ddp) ocorre ao se aproximar de obje-
tos. Um esquemático de seu funcionamento é obser-
vado na Figura 7.
Figura 7 – fluxograma de sensores de distância infravermelhos do
Robotino
Para esta aplicação, dividiu-se os sensores em 4
grupos: direita, esquerda, frente e traz. Uma vez que
um desses grupos seja ativado, a programação de
locomoção do robô é interrompida e a tarefa de des-
vio ativada. O Robotino foi programado para, então,
se direcionar tangenciando o objeto detectado até que
seus sensores não o detectem mais e assim, retornar a
função de movimentação padrão.
3.2.C – Conexão com o Robotino
O Robotino dispõem de um teclado de interação
com display, como mostra a Figura 8.
Figura 8 – Teclado e Display na parte superior do Robotino. (1)
Display; (2) Led; (3)on/off; (4)Subir de secão; (5) ir para baixo;
(6) Enter; (7) ir para cima
Para conectar o Robotino via wireless ao compu-
tador, primeiramente, deve-se liga-lo, apertando o
botão on/off por cerca de 3 segundos até as luzes e o
ISBN: 978-85-8001-069-5
display se acenderem. Após 30 segundos, será mos-
trado o canal de conexão em que o Robotino está
gerando via wireless. Seus dados, no caso deste tra-
balho são: IP: 172.26.1.1, versão utilizada de confi-
guração: 1.7 e os quadrados abaixo dos dados, como
indicado a Figura 9 indicam a capacidade de auto-
nomia que a bateria fornece.
Figura 9 – Display do Robotino
Se nenhum botão é acionado por mais de 10 se-
gundos, o display se apaga para economia de energia.
Para reacendê-la basta acionar qualquer botão do
teclado do Robotino.
Concluída a iniciação, deve-se então conectar o
computador a rede wireless do Robotino. Ao buscar
as opções de rede, encontra-se a opção “Robotino”,
porém apenas para acesso ao robô, sem conexão com
a Internet, como mostra a Figura 10. Para verificar se
a conexão está correta uma opção é rodar um arquivo
de exemplo já oferecido pelo pacote do Robotino ou
verificar via MS-DOS.
Figura 10 – Opção de rede wireless do Robotino
Para o reconhecimento e acionamento, seja dos
sensores quanto dos motores e do acesso ao Robotino
via wireless, deve-se, primeiramente, “construir” os
Id’s no Matlab, sendo estes destruídos ao final da
rotina do programa. Foram utilizados os 9 sensores
infravermelhos e o Bumper que detecta colisão.
4080
 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.

Também o acionamento dos motores por meio dos

sensores de Odometria e pelo Omnidrive.
Abaixo estão os códigos de construção dos Id dos
sensores e parâmetros do motor:

%Definindo variáveis e sensores: (construindo e

chamando sensores)
ComId = Com_construct;
OmniDriveId = OmniDrive_construct;
DistanceSensor0Id = DistanceSensor_construct(0);
...
DistanceSensor8Id = DistanceSensor_construct(8);
BumperId = Bumper_construct;

Criação e associação com o Ip do Robotino:

% Definir IP
com_setaddress(ComId, '172.26.1.1:80');
Com_connect(ComId);

Ao se encerrar a realização de tarefas, a conexão

deve ser desfeita e a ligação entre o programa e os
sensores e motores interrompida (“destruída”), para
isto ao final do programa, utiliza-se de códigos para
o cancelamento desta comunicação. Destruição da
ligação via Ip do Robotino e dos sensores, utilizado
ao final do programa:

%desconecta do Robotino
Com_disconnect(ComId);
% Destrói chamada de sensores Figura 11 – Pontos para rota de teste, modificada de (Santos,
DistanceSensor_destroy(DistanceSensor0Id); 2009)
...
DistanceSensor_destroy(DistanceSensor8Id);
Bumper_destroy(BumperId); Executando o programa desenvolvido para plane-
OmniDrive_destroy(OmniDriveId); jamento de rotas, obtem-se a rota otimizada a ser
Com_destroy(ComId); realizada, divida em etapas, geradas individualmente
ao entrar em cada novo ambiente. Cada etapa é proje-
Uma vez concluída a movimentação e retornado tada pelo algoritmo A*, como mostrado na Figura
o resultado, o Matlab gera um resultado “ok” para 12.
que o gerenciador de tarefa processe a nova função
de posição a ser tomada.

4 Resultados:

Concluída todas as etapas descritas acima, ini-

ciou-se os testes aplicados ao Robotino, a fim de
detectar erros intrínsecos e possíveis conflitos de
programação.
Dentre as rotas selecionadas para teste, uma utili-
zada para validação do sistema consiste na posição
inicial do Robotino no “Corredor 2”, a existência de
um pacote na “Sala ELL”, sendo o objetivo final de
entrega no “Carro Zafira” que se encontra na “Gara-
gem”. Este percurso pode ser observado no mapa da
Figura 11.
Figura 12 – Exemplo de rota planejada entre o “Corredor2” e a
“Sala ELL”, no planejador de rotas

Porém, ao se iniciar os testes, uma primeira ob-

servação a ser feita foi o erro causado na odometria

ISBN: 978-85-8001-069-5 4081

 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.
devido à irregularidade do piso pelo qual ele se lo-
comovia. Devido a relevos presentes no piso do
“Corredor 2”, o robô, apesar de se deslocar correta-
mente na distancia planejada, sofria um desvio de até
8 cm a cada metro aproximadamente, no outro eixo,
mostrado na Figura 13.
Figura 13 – Exemplo de desvio devido à irregularidade do piso
Além disto, ainda há um desvio de rota intrínseco
do próprio Robotino, podendo ser observado pela
leitura dos valores de odometria, quando testado em
pisos mais regulares. Estes valores variam de 1cm a
2cm por metro, em ambos os eixos. Há também, o
desvio em ângulo, causando erro de até 6º positivos
ou negativos em relação ao eixo (x,y) do robô . Estes
erros tornam-se acumulativos com o decorrer do
percurso, pois é um erro intrínseco, com desvios
demasiados pequenos para se consertarem. Como
observado no gráfico da Figura 14.
Figura 14 – Gráfico de uma rota teórica x rota real, com os desvios
médios observados.
Também observou-se o desvio de obstáculos do
Robotino, para permitir que ele continuasse sua lo-
ISBN: 978-85-8001-069-5
comoção em um ambiente com obstáculos não espe-
cificados no mapa de trajetórias. Uma primeira ob-
servação foi que a posição dos sensores laterais pre-
judica um pouco o sensoriamento do robô, pois os
sensores estão distribuídos com 40º de distância entre
si, prejudicando um pouco o fato dos sensores late-
rais (eixo y do Robotino) não serem exatamente
perpendiculares a estrutura, assim detectando algu-
mas vezes objetos que não interfeririam na trajetória
e realizando desvios desnecessários. Outro fator
agravante é a altura dos sensores em relação a estru-
tura do robô, como estes são posicionados muito
próximos ao chão a estrutura superior pode se depa-
rar com um obstáculo que os sensores não detecta-
ram.
A locomoção auxiliada com o sensoriamento
mostrou-se eficiente, principalmente no auxílio de
desvio de objetos próximos às paredes, porém com
certa dificuldade de correção de rota com relação a
objetos encontrados no meio do percurso, pois o robô
julga o obstáculo como um objeto único (formato
cúbico), não realizando os desvios de acordo com
seus contornos. Este desvio mais detalhado pode ser
solucionado com o replanejamento envolvendo um
algoritmo de controle mais elaborado e também uma
melhoria nas distinções dos sensores.
5 Dificuldades encontradas
Como precauções para a utilização do Robotino,
recomenda-se, inicialmente, a realização em piso
liso, sem irregularidades a fim de que o desvio pre-
visto seja mínimo, dentro das tolerâncias de erro
intrínseco. Uma solução possível é melhoria do re-
planejamento de rotas, a fim de diminuir este erro,
por meio de um algoritmo de controle mais elabora-
do.
6 Conclusão
Após a realização de testes separados de cada e-
lemento do projeto e da integração dos softwares,
provou-se ser possível a implementação de um soft-
ware de planejamento juntamente com a função de
movimentação com a plataforma móvel Robotino,
para locomoção de ambiente parcialmente conhecido.
Conclui-se também que a utilização apenas dos
sensores de odometria para a captação das posições
não é de total confiança, tanto pelo erro acumulativo
na movimentação quanto para a correção de desvio
de rotas. Para melhorias futuras em um projeto como
este, recomenda-se o acoplamento de demais senso-
res para referencia inercial, tais como giroscópios e
acelerômetros, a fim de melhorar a exatidão na mo-
vimentação do robô.
Uma última observação importante é a relevância
do piso para a realização da movimentação. Pois a
presença de relevos no piso prejudica a locomoção
precisa do robô, alterando o posicionamento. A re-
4082
 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.

comendação é que tanto testes quanto a realização de

tarefas seja realizada em piso liso.
A metodologia utilizada neste trabalho, além de
seus fins didáticos, pode ser expandida ao uso em
diversos tipos de robôs autônomos, podendo assim
ser aplicado para realização de tarefas diversas, com
supervisão via web, ou para buscas em armazéns
complexos ou em terrenos de grande risco.

Agradecimentos

A FAPEMIG pelo apoio proporcionado através

do projeto APQ-00744-08.
Aos alunos de Engenharia de Controle e Automa-
ção, João Paulo Almeida Barbosa e Felipe Lira San-
tana e ao professor Guilherme Bastos pelo auxilio
prestado.

Referências Bibliográficas

Fórum Robotino (2011)[online]. Disponível em:

forum.openrobotino.org/. [Acesso em 10 de Ju-
lho de 2011].

Odaguil, F. I. K.; Piesco, M. M. (2010). Monito-

ramento de manufatura via internet com robô
móvel. Trabalho de Conclusão de Curso – Esco-
la Politécnica da Universidade São Paulo, 2010.

Santos, K. R. S. (2009). Sistema de navegação

autônoma para robôs móveis baseado em arqui-
tetura híbrida: teoria e aplicação. Dissertação de
Mestrado - Universidade Federal de Itajubá,
2009.

ISBN: 978-85-8001-069-5 4083