Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
São Carlos
2016
1
São Carlos
2016
2
`
3
4
“Não crescemos quando as coisas ficam fáceis, e sim quando enfrentamos nossos
desafios.”
(DESCONHECIDO)
5
AGRADECIMENTOS
RESUMO
C++. Para efeitos de validação, foram feitas simulações com um robô terrestre,
companhia CoppeliaRobotics.
Os resultados mostram que o algoritmo Bug1 acaba sendo lento devido à necessidade
Bug2, assim como o Bug1, apresenta a mesma simplicidade de código e baixo custo
necessidade de mapeamento prévio. Dessa forma, pode ser usado em conjunto com o
potenciais.
autônomo.
7
8
ABSTRACT
The objective of this work was to develop, program and compare different algorithms
of autonomous navigation and path planning for autonomous robots. The Bug 1, Bug2
and A* (Astar) algorithms were developed. The codes were developed in C++
language using ROS platform (Robotic Operating System). To test the algorithms, it
For all the algorithms used, it were verified its advantages and disadvantages for each,
comparing its efficiency, time to achieve the goal, complexity and code structure.
The results showed that Bug1 algorithm is slow because it needs to circumnavigate
the entire obstacle until start going through the goal again. Bug2 just like Bug1
presents the same code simplicity and low execution cost. However, it stands out in
relation to Bug1 for its good performance and its needlessness to circumnavigate the
entire obstacle, as it just needs to find the m-line again to pursue the goal.
The A* (Astar) besides presenting a complex code and higher computational cost of
execution, showed itself as an excellent global path planning, being the only negative
point the necessity to have a map previously passed to it. Thus, it can be used in
Keywords: Path Planning, ROS, Bug, A*, Astar, VREP, Autonomous Robot,
Obstacle avoidance.
9
10
LISTA DE FIGURAS
Figura 15 – Robôs utilizados para simulação dos algoritmos. a) robô sonar; b) robô
laser .............................................................................................................................. 42
LISTA DE TABELAS
LISTA DE GRÁFICOS
Gráfico 1 – BUG 1 versus BUG 2: comparação de tempos de execução nos três mapas
diferentes ...................................................................................................................... 67
14
SÚMARIO
RESUMO ....................................................................................................................... 6
ABSTRACT................................................................................................................... 8
1- Introdução ............................................................................................................ 16
2.2.2 Conceitos..................................................................................................... 20
2.3VREP .................................................................................................................. 27
2.5Algoritmo A* (A star)......................................................................................... 35
3 – DESENVOLVIMENTO ........................................................................................ 40
3.1 Objetivo.............................................................................................................. 40
5- CONCLUSÃO ......................................................................................................... 73
REFERÊNCIAS........................................................................................................... 75
16
Capítulo 1
1- INTRODUÇÃO
devem ser capazes de interagir com o ambiente a sua volta e tomar decisões de forma
necessitam de uma alta precisão em sua montagem. Apesar de todo esse sucesso, no
manipulador fixo apresenta um alcance de trabalho limitado pelo local onde é fixado.
(Siegwart&Nourbakhsh, 2004).
17
em robôs autônomos foram feitos a partir dos anos 80. Nos últimos anos,
Neste trabalho, foram escolhidos os algoritmos da classe Bug, a qual está inserida
tempo real. Além disso, utilizou-se o algoritmo A* (Astar) para o planejamento global
do robô). Para efeito de validação, foi utilizado o software V-REP. Este permite a
Capítulo 2
2- REVISÃO BIBLIOGRÁFICA
de fácil leitura, pois a linguagem permite separar seu código em partes e arquivos para
Para realização deste trabalho, foi escolhido o ROS (Robot Operating System), um
entanto, o ROS não é considerado um sistema operacional, pois ele não pode ser
hardware, assim como, por exemplo, acontece como uso dos sistemas operacionais de
como um “grafo”, tem seus NÓS (nodes) fracamente acoplados usando a infra-
código escrito para ROS possa ser usado com outros frameworks.
2013).
2.2.2 Conceitos
-Nós (nodes): nós são os processos responsáveis pela execução computacional. ROS é
projetado para ser modulável em uma escala refinada, um sistema de controle do robô
- Mestre (Master): O ROS Mestre (nó mestre) fornece registro e pesquisa de nome
para o resto do Grafo computacional. Sem o Mestre, os nós não seriam capazes se
- Mensagens: os nós se comunicam uns com os outros, por meio de mensagens. Uma
digitados. Tipos primitivos padrão (inteiro, ponto flutuante, booleano, etc.) são
determinado tipo de dados irá assinar para o tópico apropriado. Pode haver vários
publicar e/ou assinar para vários tópicos. Em geral, os publicadores e assinantes não
conectar ao barramento para enviar ou receber mensagens, desde que eles são o tipo
certo.
flexível, mas para casos que tenham muitas requisições/respostas com interações, que
sensores, que podem ser difíceis de coletar, mas são necessários para desenvolver e
testar algoritmos.
22
Além da comunicação entre nós pelo nó mestre, os nós podem se conectar a outros
servidor DNS. Os nós que subscrevem um tópico irão solicitar conexões a partir de
nós que publicam esse tópico, e estabelecerá a conexão sobre um acordo sobre
meios pelos quais os sistemas maiores e mais complexos podem ser construídos. Os
parâmetros têm nomes. Cada biblioteca do ROS suporta linhas de comandos para
de computação diferente.
informações sobre ROS. Qualquer um pode se inscrever para uma conta e contribuir
Navigation Stack é um conjunto de bibliotecas do ROS. Ele traz uma base pronta para
velocidade para uma base móvel. Para que este pacote possa ser aplicado a um robô, é
preciso garantir alguns pontos: 1) o robô deve estar rodando ROS, 2)a pose
disso, ele deve ser configurado de acordo com o formato e dimensões do robô para
Figura 2 - Representação do funcionamento do Navigation Stack. Fonte: WikiRos
O Navigation Stack presume que o robô esteja configurado da maneira padrão para
robô.
2.2.2.2 Nav_core
Figura 3 - Representação da visão geral do pacote nav_core. Fonte: WikiRos
Pode-se ter uma visão geral do pacote nav_core com suas interfaces fundamentais
2.2.2.3 Move_base
global e um local para realizar sua tarefa de navegação. Ele suporta qualquer tipo de
componentes são mostradas na Figura 2, onde as elipses azuis variam de acordo com
a plataforma do robô, as cinzas são opcionais, mas são fornecidas para todos os
2.2.2.4 Map_server
comando que permite que mapas gerados dinamicamente possam ser salvos em
arquivos.
obstáculos.
26
representam pixels ocupados, e pixels entre estas duas cores são desconhecidos.
2.2.2.5 TF
no tempo. O que permite um rápido e fácil acesso, além das transformações entre as
Outra vantagem do uso do TF é que este pode operar num sistema distribuído, ou seja,
2.2.2.6 Rviz
Este visualizador foi utilizado para poder verificar a trajetória gerada pelo robô laser
2.3 VREP
seja, cada objeto/modelo pode ser individualmente controlado via embedded script,
ROS, remote API cliente ou ainda uma solução customizada, o que torna o VREP
muito versátil para aplicações robóticas. Os códigos para controle do robô podem
ainda ser escritos em C/C++, Python, Java, Lua, Matlab, Octave ou Urbi (V-REP
Este software foi então escolhido para realização das simulações com os algoritmos
citadas, quanto pela facilidade em criar os cenários de teste quanto pela existência de
uma licença gratuita para fins educacionais (V-REP Virtual Robot Experimentation
Plataform, 2013)
Os algoritmos da classe BUG são aqueles que se enquadram nos tipos de códigos
predeterminado chamado aqui de ponto de chegada (Dias, 2011). Para este tipo de
Os algoritmos da classe BUG são estruturados por sensores, ou seja, o robô utiliza um
exemplo, ser um sensor de proximidade. Além desse sensor, o robô também tem a
ambiente (mapa). O BUG pode realizar dois movimentos padrão para essa classe de
obstáculo existente no mapa. Apesar de serem algoritmos simples, eles garantem que
se existirem caminhos válidos do robô ao alvo, com certeza ele será encontrado (Dias,
2011).
Inspirado nos deslocamentos dos insetos (Bugs) o ambiente para implementação dos
estas. Dessa forma, de maneira ideal, inicia-se a trajetória e, toda vez que o robô
encontrar um obstáculo, ele deve seguir seu perímetro até encontrar um caminho livre
29
2015).
Figura 4 - Exemplo genérico de uma trajetória utilizando o algoritmo BUG (CHOSET, 2015)
Os algoritmos Bug mais conhecidos são o Bug 0, Bug1, Bug2 e Tangent Bug (Dias,
2.4.1 BUG 0
Para o caso específico do BUG0 (zero), seu algoritmo é muito simples. Ele se baseia
em traçar uma linha reta do ponto de partida em direção ao ponto de chegada, e dar
início a trajetória. Toda vez que o robô encontrar um obstáculo, ele deve seguir seu
para guardar a posição de onde deixou quando se depara com o obstáculo ou quando
Ø Continue.
Chegada Chegada
Partida Partida
Dessa forma, este algoritmo nem sempre irá retornar um caminho possível devido às
2.4.2 BUG 1
O algoritmo BUG1 foi detalhado por Stepanov em 1987 e foi o primeiro algoritmo
desta categoria a ser desenvolvido (COSTA, 2011). Ele foi desenvolvido com o
“memória” para garantir que o ponto de chegada seja alcançado. Assim, toma-se o
(CHOSET, 2015).
31
Seu funcionamento dá-se da seguinte forma: o robô deve sair do ponto de partida e
como Hout sempre o ponto com menor distância entre a localização atual e o ponto de
deve mover-se novamente até o ponto Hout (de menor distância), circunavegando o
2015).
• Loop:
• Else: i=i+1.
Figura 6- Exemplo de trajetória para robô utilizando o algoritmo BUG 2 (CHOSET, 2015)
percorre por todo o perímetro do mesmo, e, ao chegar num ponto em que ele
menor distância entre sua posição e seu ponto de chegada e só então dá continuidade
Para os casos e cenários abordados neste trabalho para os bugs, iremos assumir as
será tratado como uma curva fechada de comprimento finito e espessura diferente de
zero, uma linha reta cruza um obstáculo em um número finito de vezes, os obstáculos
Podemos então estimar o melhor e pior cenário para o percurso necessário para
melhor trajeto possível será D (distância em linha reta do ponto de partida até a
(PLAKU).
2.4.3 BUG 2
determinação de uma linha reta (m-line) que liga o ponto de partida ao ponto de
chegada. O robô deve seguir essa linha até encontrar um obstáculo, então conforme
• Loop:
• Untill:
Goal) ou
Verificamos aqui que o Bug2 é um algoritmo mais voraz que o Bug1, pois age de
maneira mais rápida que seu predecessor, sempre que encontra a m-line parte para em
direção ao Goal, o que confere a ele uma maior agilidade na resolução de muitos
casos com um menor trajeto necessário, porém para alguns casos isso não se verifica.
ser planejar o melhor caminho, o algoritmo utiliza além das informações dos nós ao
seu redor, a distância que falta para chegar ao seu destino. “O algoritmo é completo,
O algoritmo A* é um algoritmo que foi descrito pela primeira vez por Peter Hart, Nils
de cálculos por meio de uma função heurística f(n). Esta, por sua vez, é a soma de
duas funções: g(n) e h(n). A função g(n) é uma função que representa o custo
necessário para ir do ponto inicial até o ponto n que está sendo calculado. Enquanto a
função h(n) é uma função heurística que faz a estimativa do custo de trajetória a partir
36
do ponto n até o ponto de chegada. Utilizando da função heurística f(n) para explorar
o mapa e alcançar o ponto de chegada pelo melhor caminho, sempre é escolhida uma
§ n(pai) = atual
nó inicial, calcula-se o seu f(inicial) e coloca-se esse nó em uma lista aberta. Escolhe-
se o nó n da lista aberta cuja função f(n) tem o menor valor (menor custo). Este nó é
então removido da lista aberta, por ser considerado já analisado, e adicionado à lista
fechada, que contém todos os nós já processados. A partir de então se analisam todos
os nós adjacentes (nós que estão diretamente ligados ao nó atual): caso o nó adjacente
37
não pertença à lista fechada, seu valor f(n) é calculado e, caso ainda não pertença à
pai do nó. Caso o nó já esteja na lista fechada, nada é feito para este nó (COSTA,
2011).
qual é o seu pai. Em seguida verifica-se nesse nó o seu Pai e assim sucessivamente até
se chegar ao nó inicial. Este algoritmo, tal como está apresentado, tem uma boa
eficiência, pois, com a utilização da lista fechada, o algoritmo previne que não se
Para ilustrar seu funcionamento, pode-se demonstrar com as figuras a seguir, onde, na
figura 9, se tem um mapa em que a posição de início está representada pela célula em
Figura 9 - Ambiente para o Exemplo do Algoritmo A*.Célula em verde determina a origem e em amarelo o
destino, as células pretas são obstáculos.
Durante a primeira iteração a célula inicial é colocada na lista aberta e todas as células
ilustrado na figura 10. Está célula (inicial) é então considerada já visitada e é retirada
da lista aberta e adicionada a lista fechada. Após serem visitadas, estas são incluídas
na lista aberta e dentre elas aquela com menor valor de F é escolhida e colocada na
38
lista fechada. Todas as células vizinhas são atribuídas como filhas da célula
quadrados em azul indicam que foram visitados e incluídos na lista aberta. O quadrado com F igual a 4 será o
Durante a segunda iteração os quadrados vizinhos da célula com menor F (que está
colocadas na lista aberta (azul) e aquela com menor valor de F é colocada na lista
seus vizinhos serão visitados e colocados na lista vazia e assim por diante.
Figura 11 - Segunda iteração –Quadrados vizinhos do que está, em vermelho, são visitados e os valores de G, F, H
calculado, estas são colocadas na lista aberta (Azul) e aquela com menor valor é colocada na lista fechada, (ficará
Ao fim das iterações, quando encontra-se a célula de destino ou quando a lista aberta
Figura 12 - Figura final – Células em cinza determinam o caminho encontrado, células em vermelho são as que
Capítulo 3
3 – DESENVOLVIMENTO
3.1 Objetivo
Intel Core 2 Duo CPU P7450 2.13 GHz. RAM 6,0 GB.
Para simulação dos algoritmos estudados neste trabalho, foram escolhidos seis
ambientes (mapas) no VREP. Destes, três foram usados para simulação dos
algoritmos Bug1 e Bug2 e outros três para simulação do A*(A star). O modelo para
41
Para o desenvolvimento e teste dos algoritmos no V-rep foram utilizados dois robôs.
sensores presentes. Quanto à estrutura, são quadrados, com duas rodas, e apresentam
Quanto aos sensores, o primeiro, escolhido para a classe BUG, será chamado de robô
sonar (figura 15.a). Ele apresenta três sensores de proximidade do tipo ultrassom na
único sensor a laser (Negri, Rodrigues, & Becker, 2016). Os robôs são apresentados
na figura 15.
a b
Para a modelagem cinemática dos robôs, como ambos apresentam a mesma forma,
Para que o robô possa se mover no mapa, é necessário que o sistema de controle envie
para as posições desejadas, com as velocidades escalares desejadas. Além disso, essa
modelagem garante que o robô consiga manobrar ao longo do mapa, uma vez que, a
Para realizar esta modelagem do acionamento descrito, tanto para o robô sonar quanto
para o laser, usou-se o modelo que pode ser visto na Figura 16.
Figura 16 - Representação do robô e velocidades
com relação a sua base; Vf – velocidade linear passada ao robô com relação a sua
base; Vr1 – velocidade linear da roda direita; Vr2 – velocidade linear da roda esquerda
cada roda do robô; Wr1 – velocidade angular da roda direita do robô; Wr2 – velocidade
Temos então que a velocidade resultante linear Vf com relação a base do robô será
igual a média entre as velocidades lineares de cada uma das rodas do robô 𝑉!! e 𝑉!! ,
resultante com relação à base do robô 𝑊! , será igual a diferença entre as velocidades
lineares de cada roda, dividido pela distância entre eixos, aqui tomada como a largura
𝑉!! + 𝑉!!
𝑉! = [1]
2
𝑉!! − 𝑉!!
𝑊! = [2]
𝑏
Assim:
Onde A representa a matriz 2x2 da equação [5], 𝑉!" a matriz das velocidades com
Para que se possa calcular as velocidades 𝑉!! e 𝑉!! necessária para um determinado
𝑉! e 𝑊! faz-se:
45
Então:
!! 𝑉!
𝑉!! 1/2 1/2
= [10]
𝑉!! 1/𝑏 −1/𝑏 𝑊!
A equação 10 é válida quando A não singular, ou seja, det A ≠0, o que pode-se
! ! !
verificar facilmente que sempre ocorrerá, pois det A = − !! − !! = − !!, e b igual a
3.3.1.2 KINECONTROLLER
rodas do robô, são calculadas e enviadas através dos tópicos que acionam as rodas
/vrep/vehicle/LeftMotor e /vrep/vehicle/RightMotor.
passado pelo programa VREP para o ROS por meio de uma configuração que não foi
implementada neste trabalho. O VREP permite que se configure o robô por meio de
46
um arquivo script no programa. Uma vez que se fez a integração do ROS com o
/vrep.
O robô sonar foi implementado junto ao VREP por meio de um Script (documento no
VREP com códigos para o robô, o qual já estava implementado). Este documento
contém drivers para os sensores sonar, para a odometria e para os motores de cada
roda. Todas essas funcionalidades são disponibilizadas ao ROS por meio do nó /vrep,
o qual permite que sejam acessadas para receber informações ou atuadas usando os
algoritmos desenvolvidos.
- /vrep/vehicle/motorLeftSpeed
- /vrep/vehicle/motorRightSpeed
- /vrep/vehicle/leftSonar
- /vrep/vehicle/RighttSonar
- /vrep/vehicle/FrontSonar
47
- /vrep/vehicle/odometry
[nav_msgs/Odometry]
- /tf
tempo [tf2_msgs/TFMessage]
Assim como o robô sonar, o robô laser foi implementado junto ao Vrep por meio de
um Script (o qual já estava configurado). A única diferença entre eles é que, ao invés
dos sensores de ultrassom, o robô sonar apresenta um único sensor laser. O driver
- /vrep/vehicle/motorLeftSpeed
- /vrep/vehicle/motorRightSpeed
- /vrep/vehicle/scan
- /vrep/vehicle/odometry
[nav_msgs/Odometry]
- /tf
tempo [tf2_msgs/TFMessage]
Para simulação dos algoritmos da classe BUG foi escolhido o robô sonar, conforme
de trajetória, bug_node.
O bug_node tem como função criar os objetos das classes Bug1 e Bug2, gerenciando
e trabalhando com os nós /vrep e / kinecontrolerdo ROS. Por sua vez, os códigos que
pelo nó /vrep.Então um objeto do tipo Bug1 ou Bug2 é criado para lidar com a lógica
da melhor trajetória epublica a velocidade que deve ser executada pelo robô no tópico
/cmd_vel. Este tópico /cmd_vel será assinado pelo nó /kinecontroler, o qual ira
implementação não há muito que citar quanto aos seus desenvolvimentos, portanto os
Figura 17- Interface do grafo de execução da classe BUG.
Conforme a Figura 11, o nó /bug publica a velocidade adquirida, por meio do código
Para simulação dos algoritmos A*, foi escolhido o robô laser, conforme descrito
Para que o pacote Navigation Stack pudesse ser utilizado corretamente, foi necessário
preparar o robô laser para recebê-lo, conforme descrito na sessão 3.6.1 Configurando
métodos a partir daqui descritos. É importante ressaltar que, por se tratar de um robô
essas informações.
51
Dentre os requisitos para que se pudesse utilizar o Navigation Stack no robô laser
temos:
publicado sobre o tópico /cmd_vel na base do robô em (x, vy, vtheta) <==>
configurado.
salvos em arquivo (bag). Este requisito foi atendido caminhando com o robô
nos tópicos /scan, /odom e /tf. Depois de terminado, gerou-se uma imagem
52
marcação.
Após garantir que todos os requisitos foram atendidos, foi necessário ajustar o
Navigation Stack para funcionar com o robô laser. Para isso utilizou-se um tutorial no
toda a configuração e lançar os arquivos para o Navigation Stack. Esta pasta contém
nível para o Navigation Stack. Dentre os arquivos que tiveram que ser criados dentro
costmap_common_params.yaml, global_costmap_params.yaml,
local_costmap_params.yaml e move_base_params.yaml.
O arquivo launch file (move_base.launch) traz à tona todos os nós do robô e configura
use_sim_time = true, que permite a utilização do tempo por meio do tópico /clock do
que é responsável por lidar com as informações sobre o mapa utilizado para o
gráfica do mapa bem como suas respectivas localizações no computador (file= “$find(
...)).
trajetetórias globais. Para configurar os mapas de custo, primeiro foi necessário criar
o mapa em um formato que pudesse ser utilizado pelo Navigation Stack, a partir do
teclado. Dessa forma, todo o mapa pode ser varrido pelo sensor, gerando um arquivo
contendo as informações das leituras do laser sobre o mapa (um Bag). Após
54
mapa a partir das informações do laser_scan. Após a criação do arquivo do mapa, foi
Figura 19–Arquivo local_costmap_params.yaml
Figura 20 - Arquivo global_costmap_params.yaml
Figura 21 - Arquivo costmap_common_params
55
coordenadas que delimitam o tamanho do robô tendo como base o seu centro. A
para determinar qual a melhor das trajetórias geradas baseadas em células ao invés de
metros; pdist_scale determina o peso para quanto o planejador deve ficar próximo do
caminho que foi dado; gdist_scalescale determina o peso para quanto o planejador
deve tentar alcançar o caminho dado; occ_dist_scale determina o peso para quanto o
planejador não deve tentar prever a trajetória, mas se basear na distância atual do robô
custos do caminho que o robô esta calculando; sim_time determina o tempo usado
robô deve andar para que o flag de oscilação seja resetado; sim_time determina o
indicando não irá se usar este tipo de planejador, usando o Trajectory Rollout.
Figura 23 - Arquivo move_base_params.yaml
57
2.5.
que adcioná-lo como um plugin do ROS, permitindo que fosse usado com o
necessárias para o uso do costmap_2d::Costmap2D que irá ser usado pelo A* como o
mapa de input. Este mapa sera acessado automaticamente pela classe do path planner
quando este é definido como um plugin. Dessa forma, não é necessário que se
o AstarPlannerROS();
o AstarPlannerROS(std::stringname, costmap_2d::Costmap2DROS*
costmap_ros);
o BoolmakePlan(constgeometry_msgs::PoseStamped& start,
constgeometry_msgs::PoseStamped&goal,
std::vector<geometry_msgs::PoseStamped>&plan );
planejador global para o BaseGlobalPlanner, isso foi feito através da linha de código
(Astar_planner::AstarPlannerROS, nav_core::BaseGlobalPlanner).
algoritmo. Então esses índices são transmitidos para a função de planejamento A*.
Quando a função terminar sua execução irá retornar o caminho calculado em formato
dos índices de células. Após estes passos, basta apenas converter os índices para as
vetor serão então enviadas para o move_base do global planner, o qual sera enviado
ao move_base que irá publicá-lo por meio do tópico nav_msgs/Path, o qual será então
Para poder compilar a classe A* como o global planner do Navigation Stack, teve-se
catkin_make o arquivo foi compilado para gerar os arquivos binários, ou seja, criar o
Finalizada esta parte e após sua implementação a classe global planner do A* está
pronta, necessitando apenas criar o plugin para que este possa integrar o módulo
rastarplanner permitindo que esta classe seja carregada de forma dinâmica pelo
Teve-se que criar também um arquivo XML, o qual contém a descrição do plugin,
in, etc. No caso deste trabalho, de um planejador global, precisou-se criar um novo
especifica-se o nome do plugin do global_planner que vai ser usado mais tarde no
qual planejador global deve ser utilizado no nav_core do Navigation Stack. Foi
sobre o plugin.
explicitamente quais plugins são exportados e quais bibliotecas dos pacotes contêm
<export>
<nav_core plugin="${prefix}/astar_planner_plugin.xml" />
</export>
astar_planner_plugin.xml.
sendo passado ao move_base por meio do arquivo astar_planner. Na figura 24, pode
Figura 24–Grafo de execução do NavegationStack funcionando no robô lase.Neste grafo temos todo o
funcionamento do Navigation Stack onde tem-se os nós /move_base, /map_server, /vrep e /kine_controller.
62
/map_server através do tópico /map, e das informações passadas pelo /vrep através
dos tópicos /odom, /tf, /scan, o /move_base cria os mapas de custo e as trajetórias
locais e globais. Isto é feito por meio do acesso aos tópicos que podem ser vistos
dentro da caixa move_base. Após fazer a lógica da trajetória a velocidade para mover
/AMR/motoRightSpeed no nó /vrep.
63
4 – RESULTADOS E DISCUSSÕES
Ao escolher-se um algoritmo de planejamento de trajetória, deve-se analisar
Para simulação do código BUG 1, três mapas foram utilizados. O código definia que
o robô circunavegasse por inteiro cada obstáculo, salvando qual o menor ponto de
Figura 25 - Simulação do BUG 1 no MAPA 1, sendo o (1) o momento que o robô sai da posição inicial, e (16) o
momento que o robô chega ao seu destino.
64
Figura 26 - Simulação do BUG 1 no MAPA 2, sendo o (1) o momento que o robô sai da posição inicial, e (14) o
momento que o robô chega ao seu destino.
Figura 27 - Simulação do BUG 1 no MAPA 3, sendo o (1) o momento que o robô sai da posição inicial, e (18) o
momento que o robô chega ao seu destino.
65
Para simulação do código BUG 2, os mesmos três mapas do BUG 1 foram utilizados.
O código definia que o robô circunavegasse cada obstáculo até encontrar a linha m,
Figura 28 - Simulação do BUG 2 no MAPA 1, sendo o (1) o momento que o robô sai da posição inicial, e (8) o
momento que o robô chega ao seu destino.
Figura 29 -Simulação do BUG 2 no MAPA 2, sendo o (1) o momento que o robô sai da posição inicial, e (8) o
momento que o robô chega ao seu destino.
66
Figura 30 –Simulação do BUG 2 no MAPA 3, sendo o (1) o momento que o robô sai da posição inicial, e (10) o
momento que o robô chega ao seu destino.
4.3 RESULTADOS BUG 1 versus BUG 2
mesmo robô. Sendo assim, é possível fazer uma análise comparativa entre elas. Para
tal, foram escolhidos três mapas para simulação dos dois algoritmos, contendo o
Tempo (s)
4:48:00 04:32:02
4:19:12
3:50:24
03:22:06
3:21:36 3:04:09
2:52:48
Tempo (s)
02:29:03
2:24:00 BUG 1
01:46:04 BUG 2
1:55:12
01:28:06
1:26:24
0:57:36
0:28:48
0:00:00
Mapa 1 Mapa 2 Mapa 3
Gráfico 1- BUG 1 versus BUG 2: comparação de tempos de execução nos três mapas diferentes
68
mapas usando cada um dos algoritmos. Pode-se notar que no mapa 2 temos uma
menor diferença entre os Bugs, pois este mapa denota um dos casos críticos para o
do Bug2.
Já as distâncias percorridas até o ponto de chegada (goal) em cada caso, por sua vez,
Distância (m)
Foi gerado um gráfico comparando o Bug1 e Bug2 em cada um dos mapas. Para o
Mapa 1, a trajetória ideal, em linha reta (caso não houvesse obstáculos no percurso)
69
entre o ponto de início e ponto de chegada, tem valor de distância igual a 6,9 metros,
para o Mapa2 7,67 metros e para o Mapa 3 8,52 metros, representadas nas figuras 25
90,00 83,30
80,00
70,00
60,48
60,00 52,50
Distância (m)
50,00 44,83
BUG 1
40,00
30,53 BUG 2
30,00
19,32
20,00
10,00
0,00
Mapa 1 Mapa 2 Mapa 3
Por meio dos resultados gráficos é possível notar a diferença de trajetória, tempo e
Para simulação do código A*, três mapas diferentes dos utilizados nos Bugs foram
seguir.
Figura 31 - Simulação do algoritmo A* (Astar) no mapa 1. As imagens (a) representam a simulação no RViz
(visualizador do global planner), onde a linha fina em azul representa a trajetória global projetada pelo A*, a linha
verde a trajetória local, e a linha vermelha a trajetória percorrida pelo robô. As imagens (b) são representações do
VRep.
Figura 32 - Simulação do algoritmo A* (Astar) no mapa 2. As imagens (a) representam a simulação no RViz
(visualizador do global planner), onde a linha fina em azul representa a trajetória global projetada pelo A*, a linha
verde a trajetória local, e a linha vermelha a trajetória percorrida pelo robô. As imagens (b) são representações do
VRep.
71
Figura 33 - Simulação do algoritmo A* (Astar) no mapa 3. As imagens (a) representam a simulação no RViz
(visualizador do global planner), onde a linha fina em azul representa a trajetória global projetada pelo A*, a linha
verde a trajetória local, e a linha vermelha a trajetória percorrida pelo robô. As imagens (b) são representações do
VRep.
As simulações para o algoritmo A* (Astar) foram realizadas nos três mapas ilustrados
na seção anterior com o robô laser. Para poder avaliar seu desempenho foram aferidas
tempo necessário para planejar cada trajetória e tempo necessário para executar a
desenvolvido. Para a velocidade do robô, esta foi limitada a 0,4 m/s tanto para a
velocidade angular quanto para a linear. Teve-se que adotar tais velocidades muito
do Navigation Stack.
um dos mapas:
Tempo (s)
registradas. Sendo:
Distância (m)
AM1D 13,93
AM2D 17,72
AM3D 15,74
5- CONCLUSÃO
Diante dos resultados obtidos verificou-se que o algoritmo Bug 2, por se tratar de um
entanto, acaba sendo lento devido à necessidade de dar uma volta completa no
obstáculo. Ainda, vale ressaltar como ponto positivo que ambos não necessitam de
Quanto ao A*, é uma opção excelente para o planejamento de trajetórias, pois apesar
conhecer o mapa previamente, uma vez que, este planeja a trajetória a partir de um
74
mapa estático, e caso haja alguma alteração neste, ele não receberá esta atualização e
caso ocorra alguma alteração no mapa durante execução, pode-se usar o Bug 2 para
Dessa forma, temos o Bug 2 excelente por sua simplicidade de código, baixo custo de
prévio.
real.
75
REFERÊNCIAS BIBLIOGRÁFICAS
Negri, J., Rodrigues, R. T., & Becker, M. (Setembro de 2016). A V-REP/ROS Model
for Validating Motion Planning and Control Algorithms in Simulated Environment.
São Carlos, Brazil: In 24th USP International Symposium of Undergraduate Research
(SIICUSP).
Robot operating systems: Bridging the gap between human and2012System Theory
(SSST)
ROS Wiki2013