No contexto das tarefas de mapeamento e localiza¸c˜ao de um robˆo m´ovel, o SLAM (Simul- taneous Localization and Mapping) ´e o problema computacional da constru¸c˜ao de um mapa e da auto-localiza¸c˜ao destes robˆos de forma simultˆanea e em constante atualiza¸c˜ao.
Existe um n´umero de algoritmos que implementam cada parte deste problema, cujo fun- cionamento depende sempre do hardware sensorial do robˆo. Neste projeto, com os recursos dispon´ıveis, podem ser utilizados os algoritmos apresentados nas subsec¸c˜oes de mapeamento e de localiza¸c˜ao.
Apesar de n˜ao ter sido implementado SLAM neste projeto, s˜ao utilizados m´odulos que em conjunto funcionariam como tal, isto ´e, ao inv´es de ser utilizado software que implemente SLAM no robˆo m´ovel para localiza¸c˜ao e mapeamento em simultˆaneo, s˜ao utilizados pacotes de software separadamente para implementar cada tarefa.
Com um pacote de mapeamento ´e constru´ıdo o mapa local, controlando o robˆo manu- almente. No fim da constru¸c˜ao do mapa ´e utilizado um pacote de navega¸c˜ao/localiza¸c˜ao juntamente com um programa que crie a rotina de trajetos do robˆo para navegar no mapa constru´ıdo, executando a tarefa pretendida.
3.2.1 Mapeamento
A tarefa de mapeamento consiste na aquisi¸c˜ao de dados sensoriais, fazendo uso do hardware dispon´ıvel no robˆo m´ovel (desde as cˆamaras laser e de alta defini¸c˜ao, sonares, LIDAR, `a pr´opria odometria) para a cria¸c˜ao de um mapa topol´ogico do espa¸co onde o robˆo ir´a navegar.
Alguns algoritmos que implementam esta tarefa e tˆem pacotes de software dispon´ıveis em ROS s˜ao o GMapping, Hector SLAM, Google Cartographer e RTAB-Map. O algoritmo utilizado para tarefas de mapeamento neste projeto foi o GMapping, por ser o algoritmo de mapeamento utilizado no robˆo da demonstra¸c˜ao pr´atica discutida no Cap´ıtulo 4 e pela existˆencia abundante de documenta¸c˜ao e tutoriais deste algoritmo.
Segue-se uma breve descri¸c˜ao de cada algoritmo mencionado, bem como o respetivo nome do n´o de ROS.
GMapping
O GMapping ´e um algoritmo de mapeamento que constr´oi mapas de grelha (grid maps) atrav´es de dados obtidos por telemetria laser de longo alcance e odometria [19].
Utilizando o pacote gmapping no ROS, ´e poss´ıvel criar um mapa de ocupa¸c˜ao de grelha 2-D, semelhante `a planta de um edif´ıcio, atrav´es da recolha de dados laser e da posi¸c˜ao de um robˆo m´ovel [20].
Hector SLAM
O Hector SLAM ´e outra abordagem ao SLAM, que pode ser utilizado sem a odometria do robˆo. Possui um n´o de ROS dedicado, o hector mapping, que ´e baseado em SLAM LiDAR sem utiliza¸c˜ao de odometria e com baixa utiliza¸c˜ao de recursos computacionais [21, 22]. Google Cartographer
O Google Cartographer ´e um sistema que fornece SLAM em 2D e 3D em tempo real, compat´ıvel com v´arias plataformas e tipos de sensores [23].
O cartographer node ´e o n´o do ROS que implementa este algoritmo [24]. RTAB-Map
O RTAB-Map (Real-Time Appearance-Based Mapping) ´e um algoritmo de SLAM gr´afico RGB-D baseado em sensores (ou cˆamaras) de profundidade [25].
O pacote de ROS que implementa este algoritmo ´e o rtabmap ros [26].
3.2.2 Localiza¸c˜ao
Na rob´otica m´ovel um robˆo n˜ao se pode deslocar a um dado ponto de forma aut´onoma sem conhecer a sua localiza¸c˜ao atual. Esta localiza¸c˜ao ´e relativa a algum ponto de referˆencia, como um ponto de origem.
De uma forma geral, os algoritmos de localiza¸c˜ao fornecem informa¸c˜ao sobre a sua pose num dado ambiente. Estes algoritmos podem determinar a localiza¸c˜ao de um robˆo de v´arias formas, sendo a mais b´asica a t´ecnica de Dead Reckoning, que utiliza a localiza¸c˜ao inicial do robˆo e a sua odometria para determinar a que distˆancia do ponto inicial est´a o robˆo. Este m´etodo ´e utilizado frequentemente com outros para melhorar a sua precis˜ao.
O algoritmo de localiza¸c˜ao utilizado neste projeto, tanto na simula¸c˜ao como na demons- tra¸c˜ao pr´atica, ´e o AMCL (ou Adaptive Monte Carlo Localization).
AMCL
O AMCL (Adaptive Monte Carlo Localization) ´e um sistema de localiza¸c˜ao probabil´ıstico para o movimento de um robˆo a duas dimens˜oes.
Em ROS ´e utilizado o pacote amcl que, atrav´es da leitura de um mapa baseado em leituras laser e mensagens de transformadas (provenientes da odometria do robˆo), d´a a estimativa da posi¸c˜ao de um robˆo [27].
3.2.3 Navega¸c˜ao
A capacidade de navegar num dado ambiente e evitar quaisquer obst´aculos e colis˜oes ´e, especialmente no caso em estudo, de extrema importˆancia. Para tal, os robˆos m´oveis executam algoritmos de planeamento de trajet´orias que contam j´a com a capacidade de auto-localiza¸c˜ao para definir o melhor trajeto poss´ıvel entre dois pontos tendo em conta os obst´aculos existentes em seu redor e no mapa no qual se est´a a localizar.
A sec¸c˜ao seguinte descreve sucintamente o algoritmo de path-planning utilizado no projeto, o A* (A-star ). A escolha deste algoritmo deve-se ao facto de se encontrar implementado no pacote move base do ROS, utilizado para enviar os comandos de navega¸c˜ao ao robˆo e efetuar os posteriores c´alculos de trajet´oria, pelo que s´o ´e abordado este algoritmo neste relat´orio.
Outros exemplos destes algoritmos s˜ao, por exemplo, o algoritmo de B* [28], D* [29] e B-Theta* [30], que tˆem todos por base o c´alculo do trajeto de menor custo de um dado n´o inicial a um n´o final.
A*
O A* (A-star ) ´e um algoritmo de planeamento de trajet´orias muito utilizado em rob´otica m´ovel e uma variante do algoritmo de Dijkstra. ´E o algoritmo utilizado por omiss˜ao pelo n´o global planner do ROS, que comunica com o n´o move base que, por sua vez, ´e o pacote de ROS que providencia a implementa¸c˜ao de uma a¸c˜ao que, dado um ponto “objetivo”num mundo, vai tentar alcan¸car esse objetivo com a base m´ovel do robˆo [31]. O seu objetivo ´e encontrar o trajeto mais curto entre dois pontos ou n´os.
O algoritmo constr´oi uma ´arvore de trajetos com o menor “custo”desde o n´o inicial at´e ao n´o objetivo. Utiliza uma fun¸c˜ao que d´a, para cada n´o, a estimativa do custo total de um caminho que utiliza esse n´o, implementando assim uma heur´ıstica. Esta fun¸c˜ao tem em conta o custo obtido at´e ao n´o atual e a estimativa do custo do n´o atual at´e ao objetivo. Este ´ultimo parˆametro ´e a heur´ıstica da fun¸c˜ao.
O funcionamento do algoritmo ´e ilustrado na Figura 3.3.
Figura 3.3: Funcionamento do algoritmo A* [32]
Neste exemplo, o algoritmo inicia no n´o a vermelho e considera todas as c´elulas adjacentes. As c´elulas inacess´ıveis ou ocupadas por obst´aculos s˜ao filtradas. De seguida, a c´elula com o
para o objetivo (n´o azul) tenha sido encontrado. As cores dos quadrados representam o custo acumulado at´e ao n´o atual (ou distˆancia ao n´o inicial), do menor custo, a amarelo, ao maior custo, a azul [32].
3.3
Cria¸c˜ao do Ambiente 3D
O ambiente criado no editor de edif´ıcios (building editor ) do Gazebo ´e uma r´eplica `a escala 1:10 dos corredores da zona de teste da Renault CACIA. A planta original ´e representada na Figura 3.4.
Figura 3.4: Planta de corredores da zona de testes na Renault CACIA
A planta da Figura 3.4 foi importada para Autocad para efetuar as medi¸c˜oes dos corre- dores e criar uma imagem mais simples para utiliza¸c˜ao no Gazebo. Os resultados podem ser observados nas Figuras 3.5 e 3.6 que representam, respetivamente, a planta do edif´ıcio com medi¸c˜oes e a imagem utilizada para a constru¸c˜ao do modelo 3D do edif´ıcio no Gazebo.
Figura 3.6: Planta de corredores utilizada no building editor do Gazebo
O building editor do Gazebo possui uma funcionalidade que permite a importa¸c˜ao de um ficheiro em formato png ou jpg da planta de um edif´ıcio. Isto facilita a constru¸c˜ao do modelo, pois ´e necess´ario apenas fornecer uma escala para convers˜ao de p´ıxeis para metros na ferramenta de importa¸c˜ao do building editor e desenhar as paredes do edif´ıcio diretamente sobre a imagem.
Figura 3.7: Representa¸c˜ao 3D dos corredores da nave fabril da Renault CACIA no Gazebo Neste momento, o mundo 3D criado j´a pode ser utilizado numa simula¸c˜ao real´ıstica, que tem em conta aspetos f´ısicos como as colis˜oes com os obst´aculos e o efeito da gravidade sobre todos os objetos.
3.4
Mapeamento
O mapeamento do mundo 3D criado foi necess´ario para a cria¸c˜ao do grid map fornecido ao pacote amcl do ROS para que o robˆo se pudesse localizar no ambiente no qual tem de navegar.
Inicialmente foi utilizado o pacote gmapping do ROS para a cria¸c˜ao do mapa 2D, seguindo um tutorial dedicado a este processo [33]. Devido ao tamanho das ´areas a cartografar e `a falta de caracter´ısticas distingu´ıveis (obst´aculos diferentes) `a exce¸c˜ao das paredes dos corredores no mundo 3D criado no Gazebo, este m´etodo n˜ao teve os resultados pretendidos. Como tal, foi utilizado um script (MakeROSMap.py) em Python que produz os ficheiros pgm e yaml [34] atrav´es de uma imagem em formato png. A imagem utilizada para produ¸c˜ao do mapa foi a da Figura 3.6. O ficheiro pgm pode ser editado utilizando um editor de imagem, para corrigir eventuais detalhes.
O resultado final do mapa do mundo 3D da nave fabril da Renault CACIA, visualizado no RViz, ´e apresentado na Figura 3.8. Note-se que o resultado obtido ´e o mesmo que se teria obtido com uma utiliza¸c˜ao bem sucedida do gmapping; numa situa¸c˜ao pr´atica, tal como na demonstra¸c˜ao experimental que ´e apresentada no cap´ıtulo seguinte, o mapeamento com gmapping teria sido poss´ıvel.
Figura 3.8: Grid map da simula¸c˜ao visualizado em RViz
3.5
Software da Simula¸c˜ao
A presente sec¸c˜ao ir´a descrever por t´opicos a metodologia utilizada na cria¸c˜ao do software projeto em ROS e do programa que implementa as trajet´orias a testar.
3.5.1 Cria¸c˜ao do Projeto
Para o programa que consiste na simula¸c˜ao foi necess´ario primeiro criar e configurar o workspace e o pacote do projeto de ROS, antes de poder juntar os restantes pacotes da simula¸c˜ao e o controlo pelo programa principal [35].
De forma a ter sempre acesso aos comandos do ROS Kinetic em todas as consolas abertas, ´e boa pr´atica adicionar a linha de c´odigo “source /opt/ros/kinetic/setup.bash”ao ficheiro “ /$USER/.bashrc”. O c´odigo dentro deste ficheiro ´e executado apenas uma vez, no arranque do sistema operativo. Se este passo n˜ao for realizado, ´e necess´ario escrever a linha de c´odigo acima mencionada sempre que se pretende utilizar o ROS Kinetic numa nova consola.
A cria¸c˜ao do workspace ´e conseguida com o seguinte c´odigo, escrito na linha de comandos (ou consola) do Ubuntu:
mkdir −p ˜/ c a t k i n w s / s r c
cd ˜/ c a t k i n w s / c a t k i n m a k e
Para criar o pacote do projeto (ou “catkin package”), que cont´em ficheiros com a descri¸c˜ao do projeto, ficheiros de build, fonte e outros, basta, depois da cria¸c˜ao do workspace, escrever o seguinte c´odigo na consola, seguindo o exemplo do projeto:
cd ˜/ c a t k i n w s / s r c
c a t k i n c r e a t e p k g d p e t e s t s t d m s g s r o s p y r o s c p p
Este comando segue o prot´otipo catkin create pkg <package name> [depend1] [depend2] [depend3]. As dependˆencias std msgs, rospy e roscpp s˜ao bibliotecas de ROS necess´arias para este projeto.
No fim, basta executar os comandos “catkin make”(ou “catkin build”) para fazer o build dos pacotes de ROS criados ou alterados (sempre que seja feita uma altera¸c˜ao aos ficheiros do pacote) e “. /catkin ws/devel/setup.bash”, para adicionar o workspace ao ambiente do ROS. Agora j´a podem ser criados os ficheiros launch, world, e outros.
3.5.2 Programa
Com o mundo 3D, o grid map para o n´o amcl (localiza¸c˜ao) e o workspace/package criados, pode ser criado o ficheiro launch do ROS, que ir´a incluir todos os n´os e parˆametros necess´arios para a execu¸c˜ao do programa. Este ficheiro ´e chamado atrav´es da introdu¸c˜ao do comando “roslaunch [package name] [launch file name]”na consola.
O ficheiro launch do projeto (dpe tb2.launch), possui informa¸c˜ao sobre o ficheiro world a utilizar, sobre o robˆo a simular e os respetivos sensores, parˆametros da simula¸c˜ao do Gazebo, o ficheiro yaml do grid map e faz a chamada do Gazebo e do n´o amcl com os respetivos mapas carregados, bem como o n´o move base, para a navega¸c˜ao aut´onoma do robˆo.
A visualiza¸c˜ao da simula¸c˜ao completa-se pela chamada do RViz, para visualiza¸c˜ao do mapa e dos dados adquiridos pelo robˆo, ap´os qual deve ser fornecida a estimativa do ponto inicial do robˆo no mapa utilizando a ferramenta 2D Pose Estimate do RViz, e pela posterior execu¸c˜ao de um dos dois scripts codificados em Python (path1.py e path2.py) que implementam, respetivamente, os dois tipos de trajetos analisados num dos corredores do mundo 3D de uma das naves fabris da Renault CACIA.
# Abre o RViz p a r a v i s u a l i z a ¸c ˜a o do p r o c e s s o r o s l a u n c h t u r t l e b o t r v i z l a u n c h e r s v i e w n a v i g a t i o n . l a u n c h # Execu ¸c ˜a o d o s s c r i p t s de t r a j e t ´o r i a s em Python python < d i r e t o r i a do s c r i p t >/path1 . py # ou . . . python < d i r e t o r i a do s c r i p t >/path2 . py
Os trajetos implementados, representados nas Figuras 3.9 e 3.10 atrav´es das linhas verdes, permitem j´a determinar por compara¸c˜ao o melhor tipo de trajeto que um sistema aut´onomo de limpeza deve utilizar para a limpeza dos corredores em rela¸c˜ao `a sua eficiˆencia, como o n´umero de mudan¸cas de orienta¸c˜ao do robˆo durante o trajeto e o consequente aumento no tempo requerido para a limpeza da mesma ´area.
Foi tamb´em implementado o regresso do robˆo `a “doca”de recarga de bateria mais pr´oxima, quando a distˆancia ao pr´oximo objetivo excede a distˆancia m´axima definida, de forma a simular ciclos de carregamento de bateria. As docas s˜ao tamb´em vis´ıveis nas Figuras 3.9 e
Figura 3.9: Trajeto do tipo 1 implementado na simula¸c˜ao
Figura 3.10: Trajeto do tipo 2 implementado na simula¸c˜ao
Como referido anteriormente, os scripts path1.py e path2.py executam, respetivamente, os caminhos demonstrados nas Figuras 3.9 e 3.10. Estes fazem uso das bibliotecas de Python do ROS para controlar o Turtlebot no ambiente 3D criado.
Os scripts seguem a estrutura abaixo:
• Importa¸c˜ao das bibliotecas de ROS e Python necess´arias;
• Declara¸c˜ao da classe GoToPose: possui os m´etodos (fun¸c˜oes) de gest˜ao do movimento do robˆo;
• Declara¸c˜ao de fun¸c˜oes gerais (c´alculos, desloca¸c˜ao `as bases de recarga); • Ciclo principal: chamada das fun¸c˜oes e execu¸c˜ao da trajet´oria definida.
O programa consiste na realiza¸c˜ao dos trajetos mostrados previamente, dentro de um retˆangulo definido pelas coordenadas dos respetivos v´ertices. O robˆo inicia sempre o movi- mento nas coordenadas da primeira base de carregamento. As coordenadas deste retˆangulo s˜ao medidas utilizando a fun¸c˜ao do RViz e guardadas numa vari´avel.
No caso do primeiro tipo de trajeto, o robˆo ir´a percorrer o corredor segundo o eixo x, entre as coordenadas x inicial e final dos cantos opostos (segundo x ) do retˆangulo. Sempre que chega a um extremo do corredor, a vari´avel que guarda a coordenada y dos pontos
objetivo enviados para o robˆo ´e incrementada por um valor igual ao do diˆametro do robˆo, e o movimento em x ao longo do corredor ´e repetido at´e y n˜ao poder ser incrementado, o que corresponde `a posi¸c˜ao de maior proximidade `a parede superior do corredor.
O segundo tipo de trajeto ´e implementado exatamente da mesma forma, diferenciando-se apenas pela troca de eixos. O robˆo movimenta-se segundo o eixo y, invertendo o sentido do movimento em y e efetuando incrementos segundo x quando atinge a coordenada em y mais pr´oxima da parede.
O regresso a uma base de carregamento da bateria ´e feito quando a distˆancia de Manhattan do ponto objetivo `a pr´oxima base somado `a distˆancia euclidiana do ponto atual ao ponto objetivo excede a distˆancia m´axima percorr´ıvel (simula¸c˜ao de falta de energia nas baterias do robˆo). Nessa situa¸c˜ao, antes de avan¸car para o pr´oximo objetivo, o robˆo desloca-se `a base de carregamento mais pr´oxima, deslocando-se posteriormente ao ponto objetivo.
O ciclo termina quando s˜ao percorridas todas as linhas poss´ıveis (dentro das condi¸c˜oes definidas) do corredor ou quando o utilizador envia o comando CTRL+C no terminal da si- mula¸c˜ao.