Automatização de um sistema industrial de limpeza

Universidade de Aveiro Departamento deElectr´onica, Telecomunica¸c˜oes e Inform´atica 2018 Departamento de Engenharia Mecˆanica

R´

uben Filipe

Ribeiro Esteves

Automatiza¸

c˜

ao de um Sistema Industrial de

Universidade de Aveiro Departamento deElectr´onica, Telecomunica¸c˜oes e Inform´atica 2018 Departamento de Engenharia Mecˆanica

R´

uben Filipe

Ribeiro Esteves

Automatiza¸

c˜

ao de um Sistema Industrial de

Limpeza

Relat´orio de est´agio apresentado `a Universidade de Aveiro para cumprimento dos requisitos necess´arios `a obten¸c˜ao do grau de Mestre em Engenharia de Automa¸c˜ao Industrial, realizada sob a orienta¸c˜ao cient´ıfica de Ant´onio Jos´e Ribeiro Neves, Professor Auxiliar do Departamento de Eletr´onica, Teleco-munica¸c˜oes e Inform´atica da Universidade de Aveiro e de Pedro Nicolau Faria da Fonseca, Professor Auxiliar do Departamento de Eletr´onica, Tele-comunica¸c˜oes e Inform´atica da Universidade de Aveiro.

O j´uri / The jury

Presidente / President Professor Doutor Miguel Armando Riem de Oliveira

Professor Auxiliar do Departamento de Engenharia Mecˆanica da Universi-dade de Aveiro

Vogais / Committee Professor Doutor V´ıtor Manuel Ferreira dos Santos

Professor Associado com Agrega¸c˜ao do Departamento de Engenharia Mecˆanica da Universidade de Aveiro

Professor Doutor Pedro Nicolau Faria da Fonseca

Professor Auxiliar do Departamento de Eletr´onica, Telecomunica¸c˜oes e Inform´atica da Universidade de Aveiro

Agradecimentos / Acknowledgements

Este projeto n˜ao poderia ter sido realizado sem as pessoas que, direta ou indiretamente deram o seu importante contributo para que tal fosse poss´ıvel. Gostaria ent˜ao de dar os meus agradecimentos.

Aos meus orientadores, Professor Doutor Pedro Fonseca, Professor Dou-tor Ant´onio Neves e Engenheiro S´ergio Almeida, pela disponibilidade, ori-enta¸c˜ao e acima de tudo por todo o conhecimento transmitido.

`

A Universidade de Aveiro e `a Renault CACIA, por providenciarem todas as condi¸c˜oes necess´arias `a realiza¸c˜ao deste projeto.

`

A minha fam´ılia, em especial aos meus pais, Fernando e Isaura, por todos os sacrif´ıcios, por serem os meus modelos a seguir, pela confian¸ca inabal´avel que depositam em mim e por toda a paciˆencia, compreens˜ao e apoio. `A minha irm˜a, Tatiana, pelo companheirismo e amizade sempre presentes. `A Carla, pelos passados anos de amizade, paciˆencia, carinho e incentivo. Aos colegas de curso e amigos, pela ajuda, companheirismo e bons momen-tos partilhados.

Palavras-chave Sistemas de Limpeza Industrial; Rob´otica M´ovel; Navega¸c˜ao Aut´onoma; Mapeamento; ROS

Resumo Este projeto estuda a viabilidade da aplica¸c˜ao de um sistema aut´onomo de limpeza baseado num robˆo aut´onomo e m´ovel em ambientes industriais, utilizando como caso concreto as instala¸c˜oes da Renault CACIA, em Aveiro. Inicialmente foi realizada a pesquisa dos sistemas desta natureza dispon´ıveis no mercado, com recurso a folhetos de produtos, feiras/exposi¸c˜oes e con-tacto a fornecedores, tendo como base as caracter´ısticas requeridas pela Renault CACIA.

De seguida foram estudados os componentes de hardware e software presen-tes neste tipo de sistemas, de forma a avaliar os v´arios robˆos e determinar a sua compatibilidade com a situa¸c˜ao proposta.

De forma a testar experimentalmente o tipo de componentes e algoritmos envolvidos no mapeamento e na navega¸c˜ao aut´onoma de um robˆo m´ovel, foram realizados testes pr´aticos de mapeamento e navega¸c˜ao na nave in-dustrial da Renault CACIA, com recurso ao robˆo m´ovel Turtlebot 2. Por fim, para analisar o controlo do robˆo, implementar e avaliar alguns tipos de trajet´orias do robˆo numa opera¸c˜ao de limpeza industrial, foi desenvolvida uma simula¸c˜ao em ROS/Gazebo que utiliza o modelo do Turtlebot 2 em navega¸c˜ao semi-aut´onoma nos corredores da nave industrial da Renault CA-CIA, implementando dois tipos distintos de trajet´oria e regresso aut´onomo `

Keywords Industrial Cleaning Systems; Mobile Robotics; Autonomous Navigation; Mapping; ROS

Abstract This project studies the viability of applying an autonomous cleaning system based on a mobile robot in industrial environments, using as a concrete case the installations of Renault CACIA, in Aveiro.

Initially, research was carried out on the systems available on the market, based on the characteristics required by Renault CACIA, using product bro-chures, fairs/exhibitions and contacting suppliers.

After this, the hardware and software components present in this type of systems were studied, in order to evaluate these robots and determine their compatibility with the proposed situation.

In order to experimentally test the type of components and algorithms in-volved in mapping and autonomous navigation of a mobile robot, practical tests of mapping and navigation in the industrial warehouse of Renault CA-CIA were carried out, using the Turtlebot 2 mobile robot.

Finally, in order to analyze, implement and evaluate some types of robot trajectories in an industrial cleaning operation, a simulation was develo-ped in ROS/Gazebo that uses the Turtlebot 2 model in semi-autonomous navigation in the corridors of the industrial warehouse at Renault CACIA, implementing two different types of trajectories and the autonomous return to the nearest battery charging base.

Conte´

udo

2 Revis˜ao do Estado da Arte 5 2.1 Solu¸c˜oes Dispon´ıveis no Mercado . . . 5

2.1.1 Cleanfix RA 660 Navi . . . 6

2.1.2 TASKI Intellibot Robotics . . . 6

Swingobot 1650 . . . 7

Duobot 1850 . . . 7

Swingobot 2000 . . . 8

2.1.3 Avidbots Neo . . . 9

2.1.4 Nilfisk Advance Liberty A50 . . . 10

2.1.5 Adlatus CR 700 . . . 11

2.1.6 Cyberdyne Cleaning Robot . . . 12

2.1.7 Fybots . . . 13

fy-Sweep L . . . 13

fy-Sweep XL . . . 14

2.1.8 Gaussian Robotics ECOBOT Scrub75 . . . 14

2.1.9 Compara¸c˜ao dos Sistemas de Limpeza Aut´onomos . . . 15

2.2 Sistemas Sensoriais . . . 17 2.2.1 Laser . . . 17 2.2.2 Sonar . . . 18 2.2.3 Vis˜ao . . . 20 3 Simula¸c˜ao 21 3.1 Plataforma de Desenvolvimento . . . 21 3.1.1 Software . . . 21 ROS . . . 21 Python . . . 23 Gazebo . . . 23 RViz . . . 23 Ubuntu . . . 23

3.2 SLAM - Simultaneous Localization and Mapping . . . 24 3.2.1 Mapeamento . . . 24 GMapping . . . 25 Hector SLAM . . . 25 Google Cartographer . . . 25 RTAB-Map . . . 25 3.2.2 Localiza¸c˜ao . . . 25 AMCL . . . 25 3.2.3 Navega¸c˜ao . . . 26 A* . . . 26 3.3 Cria¸c˜ao do Ambiente 3D . . . 27 3.4 Mapeamento . . . 30 3.5 Software da Simula¸c˜ao . . . 31 3.5.1 Cria¸c˜ao do Projeto . . . 31 3.5.2 Programa . . . 32

3.6 Coment´arios Finais . . . 34

4 Demonstra¸c˜ao Turtlebot 2 35 4.1 Setup . . . 35 4.1.1 Hardware . . . 35 Turtlebot 2 . . . 35 SICK LMS100 . . . 36 4.1.2 Software . . . 37 4.2 Mapeamento . . . 37 4.3 Navega¸c˜ao . . . 39

4.4 Reprodu¸c˜ao de Ficheiros bag . . . 41

4.5 Coment´arios Finais . . . 41

5 Conclus˜oes 43 A Sistema de Vis˜ao para Monitoriza¸c˜ao de Sujidade 49 A.1 Enquadramento . . . 49

A.2 Descri¸c˜ao do Problema . . . 49

A.3 Objetivos . . . 52

A.4 Equipamento Utilizado no Projeto . . . 52

A.4.1 Hardware . . . 52

A.4.2 Software . . . 53

A.5 Programa . . . 53

A.5.1 Diagrama de Blocos . . . 53

A.5.2 Fun¸c˜ao Principal . . . 54

A.5.3 Aquisi¸c˜ao de Dados de Imagem . . . 55

camTest.m . . . 55

vidTest.m . . . 55

A.5.4 Pr´e-Processamento . . . 55

A.5.5 Segmenta¸c˜ao . . . 56

B Ficheiro launch do Projeto em ROS 60

C Script Python Trajeto Tipo 1 62

D Script Python Trajeto Tipo 2 69

E Script Matlab PEA.m 76

F Script Matlab camTest.m 80

G Script Matlab vidTest.m 81

H Script Matlab getROI.m 82

Lista de Figuras

2.1 Robˆo de limpeza RA660 Navi . . . 6

2.2 Robˆo de limpeza Swingobot 1650 . . . 7

2.3 Robˆo de limpeza Duobot 1850 . . . 8

2.4 Robˆo de limpeza Swingobot 2000 . . . 9

2.5 Robˆo de limpeza Neo . . . 10

2.6 Robˆo de limpeza Advance Liberty A50 . . . 11

2.7 Robˆo de limpeza CR 700 . . . 12

2.8 Robˆo de limpeza Cleaning Robot . . . 12

2.9 Robˆo de limpeza fy-Sweep L . . . 13

2.10 Robˆo de limpeza fy-Sweep XL . . . 14

2.11 Robˆo de limpeza ECOBOT Scrub75 . . . 15

2.12 Representa¸c˜ao gr´afica de dados obtidos por sensores laser (LiDAR) . . . 18

2.13 Representa¸c˜ao gr´afica de dados obtidos por sensores ultrass´onicos . . . 19

2.14 Exemplo de dete¸c˜ao de obst´aculos a distˆancias vari´aveis utilizando vis˜ao est´ereo 20 3.1 Diagrama de Conceitos B´asicos de ROS . . . 23

3.2 Robˆo M´ovel Turtlebot 2 . . . 24

3.3 Funcionamento do algoritmo A* . . . 26

3.4 Planta de corredores da zona de testes na Renault CACIA . . . 27

3.5 Planta de corredores da zona de testes na Renault CACIA com dimens˜oes . . 28

3.6 Planta de corredores utilizada no building editor do Gazebo . . . 29

3.7 Representa¸c˜ao 3D dos corredores da nave fabril da Renault CACIA no Gazebo 30 3.8 Grid map da simula¸c˜ao visualizado em RViz . . . 31

3.9 Trajeto do tipo 1 implementado na simula¸c˜ao . . . 33

3.10 Trajeto do tipo 2 implementado na simula¸c˜ao . . . 33

4.1 Robˆo M´ovel Turtlebot 2 . . . 36

4.2 LIDAR 2D LMS1XX . . . 36

4.3 Grid map constru´ıdo com GMapping na demonstra¸c˜ao pr´atica . . . 38

4.4 Area correspondente `´ a zona de testes da demonstra¸c˜ao pr´atica . . . 38

4.5 Demonstra¸c˜ao pr´atica em RViz da navega¸c˜ao com Turtlebot 2 utilizando A* e AMCL . . . 40

A.1 Sec¸c˜ao limpa de um corredor . . . 50

A.2 Amostra 1 . . . 51 A.3 Amostra 2; Vermelho: zonas de sujidade intensa; Verde: zonas limpas;

Ama-A.5 MATLAB . . . 53

A.6 Diagrama de Blocos do Sistema . . . 54

A.7 Resultados Binariza¸c˜ao 1 . . . 56

A.8 Resultados Binariza¸c˜ao 2 . . . 56

A.9 Resultados FCM 1 (Imagem original) . . . 58

A.10 Resultados FCM 1 (Imagem processada) . . . 58

A.11 Resultados FCM 2 (Imagem original) . . . 58

A.12 Resultados FCM 2 (Imagem processada) . . . 59

A.13 Resultados FCM 3 (Imagem original) . . . 59

Cap´ıtulo 1

Introdu¸

c˜

ao

No presente Cap´ıtulo s˜ao introduzidos o enquadramento deste relat´orio, a descri¸c˜ao do problema em estudo, a apresenta¸c˜ao dos seus objetivos e as plataformas de desenvolvimento utilizadas a n´ıvel de hardware e software.

1.1

Enquadramento

Os sistemas AMH (Automated Material Handling) s˜ao a mais recente evolu¸c˜ao tecnol´ogica de sistemas guiados de forma autom´atica na ind´ustria. As empresas do sector industrial est˜ao a dar importˆancia acrescida a sistemas que permitam uma gest˜ao mais inteligente e eficiente de recursos, uma vez que estes podem ser empregues na execu¸c˜ao autom´atica de tarefas repetitivas e de baixa complexidade, oferecendo assim a melhoria das condi¸c˜oes de trabalho e a possibilidade da desloca¸c˜ao dos recursos humanos para execu¸c˜ao de tarefas de maior complexidade.

No ˆambito do aumento de fluxos automatizados e moderniza¸c˜ao de f´abrica, a Renault CACIA identificou a necessidade de automatizar os fluxos de limpeza, traduzindo-se numa melhoria das condi¸c˜oes de trabalho na fabrica¸c˜ao. Esta automatiza¸c˜ao consiste em equipar as naves das instala¸c˜oes da Renault CACIA com robˆos de limpeza que efetuem de forma aut´onoma as opera¸c˜oes de limpeza nas ´areas mais amplas e movimentadas das instala¸c˜oes, nomeadamente nos corredores de circula¸c˜ao dos AGVs e outros equipamentos m´oveis.

O emprego de equipamentos aut´onomos de limpeza na Renault CACIA poder-se-´a refle-tir, n˜ao s´o na possibilidade da desloca¸c˜ao das equipas especializadas de limpeza para zonas cujo n´ıvel de limpeza possui uma maior prioridade, como tamb´em na poupan¸ca de recursos energ´eticos e na melhoria das condi¸c˜oes gerais dos espa¸cos de trabalho e da manuten¸c˜ao da seguran¸ca nestes espa¸cos.

Para tal ser exequ´ıvel, ´e necess´ario fazer o estudo da situa¸c˜ao atual das naves da Renault CACIA em rela¸c˜ao `a intensidade da sujidade do ch˜ao, ao trˆansito nas zonas alvo de limpeza e `a topologia dos locais, seguido do estudo ponderado das ofertas atuais do mercado para sistemas aut´onomos de limpeza e a sua adequa¸c˜ao `a situa¸c˜ao estudada. Esta informa¸c˜ao ´e ´

1.2

Descri¸

c˜

ao do Problema

A Renault CACIA pretende analisar a viabilidade da automatiza¸c˜ao da opera¸c˜ao de lim-peza dos corredores das suas naves industriais, por meio da aquisi¸c˜ao de um sistema aut´onomo de limpeza, tendo em conta a garantia da redu¸c˜ao de custos nas opera¸c˜oes de limpeza fabris, a melhoria da eficiˆencia energ´etica e das condi¸c˜oes de trabalho, o aumento da frequˆencia e da qualidade da limpeza e a manuten¸c˜ao da seguran¸ca no trabalho.

Atualmente, a Renault subcontrata equipas especializadas de limpeza para operar em toda a ´area das naves fabris. As opera¸c˜oes de limpeza s˜ao efetuadas sobretudo por equipamentos guiados manualmente por um operador. Embora estes equipamentos sejam capazes de limpar uma superf´ıcie de ´area consideravelmente maior em menos tempo, apresentam custos de opera¸c˜ao e de utiliza¸c˜ao de consum´ıveis muito superiores a um equipamento aut´onomo que, a m´edio prazo, representam gastos financeiros significativos.

A solu¸c˜ao ideal seria conjugar ambos os tipos de limpeza, a aut´onoma e a manual, permi-tindo que as ´areas amplas de passagem, de sujidade menos intensa e mais regulares (facilitam a aplica¸c˜ao dos m´etodos autom´aticos de limpeza) fossem limpas pelos robˆos, e as ´areas pr´oximas da maquinaria de produ¸c˜ao, de elevado n´ıvel de sujidade e de acesso mais condicionado, fossem limpas pelas equipas de limpeza, aumentando assim a frequˆencia e a qualidade das opera¸c˜oes de limpeza e possivelmente conseguindo uma redu¸c˜ao de custos a longo prazo associados a esta opera¸c˜ao.

1.3

Objetivos

O projeto teve como objetivo principal o estudo de viabilidade da aplica¸c˜ao de um sistema aut´onomo de limpeza no ambiente fabril da Renault CACIA.

Para atingir este objetivo, foi realizado o estudo das solu¸c˜oes/ofertas de equipamentos aut´onomos de limpeza dispon´ıveis no mercado, dos sistemas sensoriais e de algoritmos de mapeamento/navega¸c˜ao deste tipo de robˆos m´oveis, o desenvolvimento de uma simula¸c˜ao em computador utilizando um modelo de robˆo m´ovel com caracter´ısticas equivalentes `as das m´aquinas previamente estudadas e foi realizado um teste demonstrativo pr´atico das opera¸c˜oes de mapeamento e navega¸c˜ao nos corredores de teste de uma das naves fabris da Renault CACIA utilizando o robˆo m´ovel da simula¸c˜ao.

Foi realizado paralelamente, na unidade curricular de Projeto em Engenharia de Au-toma¸c˜ao, um projeto que procura estudar e desenvolver algoritmos de monitoriza¸c˜ao da suji-dade no ch˜ao de unidades industriais com recurso a ferramentas de aquisi¸c˜ao e processamento de imagem digital, que pode ser integrado no mesmo ˆambito do projeto/est´agio. Encontra-se no anexo A, no final deste documento, um excerto do relat´orio deste projeto.

1.4

Estrutura do Documento

Este documento divide-se em cinco cap´ıtulos.

No Cap´ıtulo 1 s˜ao introduzidos o enquadramento deste relat´orio, a descri¸c˜ao do problema em estudo, a apresenta¸c˜ao dos seus objetivos e as plataformas de desenvolvimento utilizadas a n´ıvel de hardware e software.

O Cap´ıtulo 3 refere-se `a simula¸c˜ao realizada no ˆambito dos testes de trajetos de um robˆo m´ovel equivalente aos sistemas estudados no Cap´ıtulo anterior e ´e dada uma vis˜ao geral sobre a t´ecnica de SLAM (Simultaneous Localization and Mapping ) e alguns algoritmos que implementam formas desta t´ecnica, seguida da descri¸c˜ao de alguns algoritmos mais conhecidos de localiza¸c˜ao e navega¸c˜ao.

No Cap´ıtulo 4 ´e explicada detalhadamente a demonstra¸c˜ao pr´atica do Turtlebot 2 na nave fabril da Renault CACIA, referindo o hardware e software utilizados e os processos de mapeamento e navega¸c˜ao demonstrados.

Finalmente, no Cap´ıtulo 5, s˜ao apresentadas as conclus˜oes que se tiraram do trabalho desenvolvido.

No final do documento, sob a forma de anexos, tˆem-se os ficheiros de c´odigo utilizados na simula¸c˜ao e demonstra¸c˜ao do robˆo m´ovel em ROS/Gazebo e um excerto do relat´orio de Projeto em Engenharia de Automa¸c˜ao, onde ´e descrito e explicado o desenvolvimento de um sistema de vis˜ao para monitoriza¸c˜ao da sujidade no ch˜ao de unidades industriais, bem como os ficheiros de c´odigo relevantes neste projeto. S˜ao explicados os algoritmos de aquisi¸c˜ao e tratamento de imagem digital, bem como os algoritmos testados para a segmenta¸c˜ao de imagem.

Cap´ıtulo 2

Revis˜

ao do Estado da Arte

Neste Cap´ıtulo s˜ao apresentados os sistemas aut´onomos de limpeza dispon´ıveis no mer-cado, fazendo uma breve compara¸c˜ao de todos, e o tipo de sistemas sensoriais existentes em robˆos m´oveis desta natureza.

2.1

Solu¸

c˜

oes Dispon´ıveis no Mercado

O objetivo desta sec¸c˜ao ´e apresentar as solu¸c˜oes atualmente dispon´ıveis no mercado, iden-tificadas como potencialmente adequadas ao problema em estudo.

Uma vez que o sistema escolhido deve ser capaz de ser o mais aut´onomo e livre de opera¸c˜ao humana quanto poss´ıvel. Dever´a evitar colis˜oes com quaisquer obst´aculos em movimento ou est´aticos e ser capaz de limpar detritos como part´ıculas de p´o, manchas de ´oleo e marcas de borracha.

Foram tomados em considera¸c˜ao por esta pesquisa fatores como a autonomia das baterias, a taxa de limpeza (´area limpa por hora), m´etodos de limpeza (“scrubber ” - escovador, “swee-per ” - varredor, “vacuum” - aspirador, “drier ” - secador), o volume dos dep´ositos de ´agua e o grau de autonomia (carregamento/reabastecimento autom´atico, entre outras funcionalidades) que os sistemas de cada fabricante oferecem.

Da pesquisa efetuada foram identificados os seguintes fabricantes de sistemas aut´onomos de limpeza: • Cleanfix; • Intellibot Robotics; • Avidbots; • Nilfisk; • Adlatus; • Cyberdyne Inc.; • Fybots; • Gaussian Robotics.

fa-2.1.1 Cleanfix RA 660 Navi

A Cleanfix ´e uma empresa sediada na Su´ı¸ca que desenvolve e produz m´aquinas de limpeza para uso profissional.

O sistema de limpeza aut´onomo que disponibilizam ´e o RA 660 Navi, equipado com o sistema de navega¸c˜ao patenteado da Cleanfix, trˆes escovas de limpeza e uma unidade de suc¸c˜ao.

De seguida s˜ao apresentadas as caracter´ısticas principais deste produto [1]. • M´etodo de limpeza: vacuum/scrubber;

• Tempo m´aximo de opera¸c˜ao: 2.5h;

• ´Area limpa por hora: 1200m2_{/h (sem obst´aculos);}

• ´Area limpa por hora: 550m2_{/h (com obst´aculos);}

• Modo de limpeza manual;

• N˜ao possibilita o carregamento autom´atico de baterias/reabastecimento autom´atico; • Volume do dep´osito: 45L

• Dimens˜oes (C x L x A): 925 x 850 x 880mm; • Peso: 260kg.

O RA660 Navi ´e mostrado na Figura 2.1.

Figura 2.1: Robˆo de limpeza RA660 Navi [1]

2.1.2 TASKI Intellibot Robotics

A Intellibot Robotics ´e uma empresa sediada nos EUA, fundada em 2003, que trabalha como divis˜ao de rob´otica da TASKI (fabricante de m´aquinas de limpeza, propriedade da Sealed Air) e tem os trˆes robˆos de limpeza analisados de seguida.

Uma caracter´ıstica fundamental destes robˆos ´e o seu sistema de reciclagem de l´ıquidos, que pode filtrar part´ıculas nos dep´ositos de ´agua at´e 1µm, permitindo uma maior economiza¸c˜ao

Swingobot 1650

O Swingobot 1650 ´e uma m´aquina que opera por escovagem. De seguida s˜ao enumeradas as suas caracter´ısticas principais [2].

• M´etodo de limpeza: scrubber; • Tempo m´aximo de opera¸c˜ao: 4h; • ´Area limpa por hora: 929m2_/h;

• Modo de limpeza manual;

• Carregamento autom´atico de baterias/reabastecimento autom´atico; • Volume do dep´osito: 53L;

• Dimens˜oes (C x L x A): 1220 x 810 x 1090 mm; • Peso: 326.6kg.

A Figura 2.2 demonstra o Swingobot 1650.

Figura 2.2: Robˆo de limpeza Swingobot 1650 [2]

Duobot 1850

O Duobot 1850 ´e muito idˆentico ao sistema anterior, com a exce¸c˜ao do m´etodo de limpeza com o qual opera. Este robˆo utiliza duas escovas contra-rotativas e uma escova longitudinal no centro.

As suas caracter´ısticas principais s˜ao mostradas de seguida [3]. • M´etodo de limpeza: sweeper/scrubber;

• Tempo m´aximo de opera¸c˜ao: 4h; • ´Area limpa por hora: 929m2_/h;

• Modo de limpeza manual;

• Carregamento autom´atico de baterias/reabastecimento autom´atico; • Volume do dep´osito: 53L;

• Dimens˜oes (C x L x A): 1220 x 810 x 1090 mm; • Peso: 313kg.

A Figura 2.3 demonstra o Duobot 1850.

Figura 2.3: Robˆo de limpeza Duobot 1850 [3]

Swingobot 2000

Este ´e o robˆo mais recente da s´erie Swingobot e o sucessor do modelo 1650. As suas caracter´ısticas s˜ao mostradas de seguida [4].

• M´etodo de limpeza: scrubber/drier; • Tempo m´aximo de opera¸c˜ao: 4h; • ´Area limpa por hora: 1050m2_/h;

• Modo de limpeza manual;

• Carregamento autom´atico de baterias/reabastecimento autom´atico; • Volume do dep´osito: 90L;

• Dimens˜oes (C x L x A): 1350 x 900 x 1280 mm; • Peso: 376kg.

A Figura 2.4 representa o Swingobot 2000.

Figura 2.4: Robˆo de limpeza Swingobot 2000 [4]

2.1.3 Avidbots Neo

A Avidbots ´e uma empresa canadiana fundada em 2014. O seu produto principal ´e o robˆo de limpeza Neo, atualmente na 8ª gera¸c˜ao de design de produto.

As caracter´ısticas mais relevantes deste sistema s˜ao mostradas de seguida [5]. • M´etodo de limpeza: vacuum/scrubber;

• Tempo m´aximo de opera¸c˜ao: 5h; • ´Area limpa por hora: - ;

• Modo de limpeza manual;

• Carregamento autom´atico de baterias/reabastecimento autom´atico; • Volume dos dep´ositos (´agua limpa/residual): 120L/124L;

• Dimens˜oes (C x L x A): 1400 x 600 x 1200mm; • Peso: 476kg.

Figura 2.5: Robˆo de limpeza Neo [5]

2.1.4 Nilfisk Advance Liberty A50

A Nilfisk ´e uma empresa fundada em 1906, na Dinamarca, e ´e atualmente uma das maiores fabricantes de equipamento de limpeza a n´ıvel mundial. O seu primeiro e atual sistema aut´onomo de limpeza ´e o Advance Liberty A50.

Este equipamento ainda n˜ao est´a dispon´ıvel no mercado e, por isso, n˜ao ´e disponibilizada informa¸c˜ao detalhada que permita uma melhor an´alise e compara¸c˜ao das suas especifica¸c˜oes [6].

• M´etodo de limpeza: scrubber; • Modo de limpeza manual;

• Lan¸camento para o mercado previsto para 2018. Este sistema pode funcionar em trˆes modos distintos:

• Manual: a m´aquina pode ser operada como um scrubber normal;

• Fill-in: o operador utiliza a m´aquina manualmente de forma a completar o per´ımetro de uma ´area a limpar, ap´os esta opera¸c˜ao o robˆo preenche a ´area dentro do per´ımetro de forma aut´onoma;

• CopyCat: replica um percurso realizado de forma manual. A Figura 2.6 demonstra o Advance Liberty A50.

Figura 2.6: Robˆo de limpeza Advance Liberty A50 [6]

2.1.5 Adlatus CR 700

A Adlatus Robotics ´e uma empresa alem˜a que desenvolve, fabrica e vende robˆos de servi¸co. O sistema aut´onomo de limpeza que disponibilizam ´e o Adlatus CR 700. Este robˆo possui carregamento de bateria e reabastecimento autom´aticos.

As caracter´ısticas do Adlatus CR 700 s˜ao apresentadas de seguida [7]. • M´etodo de limpeza: sweeper/scrubber;

• Tempo m´aximo de opera¸c˜ao: 4h; • ´Area limpa por hora: 1125m2_/h;

• Modo de limpeza manual;

• Carregamento autom´atico de baterias/reabastecimento autom´atico; • Volume dos dep´ositos (´agua limpa/residual): 120L/68L;

• Dimens˜oes (C x L x A): 1000 x 755 x 980 mm; • Peso: 300kg.

Figura 2.7: Robˆo de limpeza CR 700 [7]

2.1.6 Cyberdyne Cleaning Robot

A Cyberdyne Inc. ´e uma empresa de pesquisa e desenvolvimento de tecnologia. Possuem um sistema aut´onomo de limpeza, o Cleaning Robot.

Este robˆo opera apenas por aspira¸c˜ao, n˜ao se adequando assim `a situa¸c˜ao proposta, uma vez que no ambiente industrial alvo ´e necess´aria uma opera¸c˜ao de limpeza mais complexa. Por esta raz˜ao, este sistema n˜ao ir´a fazer parte da discuss˜ao dos sistemas estudados.

De seguida s˜ao apresentadas as caracter´ısticas do Cleaning Robot [8]. • M´etodo de limpeza: vacuum;

• Tempo m´aximo de opera¸c˜ao: 3h; • ´Area limpa por hora: 816m2_/h;

• Dimens˜oes (C x L x A): 850 x 720 x 1150 mm; • Peso: 160kg.

A Figura 2.8 ilustra o Cleaning Robot da Cyberdyne.

2.1.7 Fybots

A Fybots ´e uma empresa francesa que trabalho na ´area da rob´otica aplicada e de sistemas embebidos.

De entre os seus produtos, os dois robˆos apresentados de seguida (fy-Sweep L e XL) s˜ao os sistemas mais relevantes para o caso em estudo, embora possam n˜ao ser t˜ao eficientes como um sistema scrubber, pois operam apenas por varredura.

fy-Sweep L

Este ´e o modelo mais compacto da Fybots. De seguida s˜ao apresentadas algumas das suas caracter´ısticas principais [9].

• M´etodo de limpeza:sweeper; • Tempo m´aximo de opera¸c˜ao: 4h; • ´Area limpa por hora: 600m2_/h;

• Modo de limpeza manual;

• Carregamento autom´atico de baterias/reabastecimento autom´atico; • Volume do dep´osito: 4.9L;

• Dimens˜oes (C x L x A): 660 x 880 x 460 mm; • Peso: 70kg.

A Figura 2.9 mostra o robˆo fy-Sweep L.

fy-Sweep XL

O fy-Sweep XL tem uma autonomia em bateria e capacidade do dep´osito superiores `a sua vers˜ao compacta, o que o torna mais eficaz na limpeza de ´areas de maior superf´ıcie. De seguida s˜ao apresentadas algumas das suas caracter´ısticas principais [10].

• M´etodo de limpeza: sweeper; • Tempo m´aximo de opera¸c˜ao: 8h; • ´Area limpa por hora: 1200m2_/h;

• Modo de limpeza manual;

• Carregamento autom´atico de baterias/reabastecimento autom´atico; • Volume do dep´osito: 30L;

• Dimens˜oes (C x L x A): 1150 x 730 x 920 mm; • Peso: 240kg.

A Figura 2.10 mostra o robˆo fy-Sweep XL.

Figura 2.10: Robˆo de limpeza fy-Sweep XL [10]

2.1.8 Gaussian Robotics ECOBOT Scrub75

A Gaussian Robotics ´e uma divis˜ao da Shanghai Gaussian Automation Technology Deve-lopment Company, uma empresa chinesa fundada em 2014 que se especializa no desenvolvi-mento e produ¸c˜ao de sistemas aut´onomos de limpeza.

O produto desta empresa escolhido para an´alise ´e o ECOBOT Scrub75. Estas s˜ao algumas das suas caracter´ısticas mais relevantes [11]:

• ´Area limpa por hora: 227m2_/h;

• Modo de limpeza manual;

• Carregamento autom´atico de baterias/reciclagem de res´ıduos; • Volume dos dep´ositos (´agua limpa/residual): 65/55L;

• Dimens˜oes (C x L x A): 1290 x 760 x 1120 mm; A Figura 2.11 representa o ECOBOT Scrub75.

Figura 2.11: Robˆo de limpeza ECOBOT Scrub75 [11]

2.1.9 Compara¸c˜ao dos Sistemas de Limpeza Aut´onomos

As Tabelas 2.1, 2.2 e 2.3 representam um breve resumo dos sistemas de limpeza estudados: Tabela 2.1: Tabela Resumo de Sistemas de Limpeza 1

Sistema de limpeza RA660 Navi Swingobot 1650 Duobot 1850 Neo

Largura de trabalho [cm] 66 74 64 81 Autonomia [h] 2.5 4.0 4.0 5.0 Volume de tanques [L] 45 53 53 120 Peso [kg] 260 326 313 476 Comprimento [mm] 925 1220 1220 1400 Largura [mm] 850 810 810 600 Altura [mm] 880 1090 1090 1200 ´

-Tabela 2.2: -Tabela Resumo de Sistemas de Limpeza 2

Sistema de limpeza CR700 Swingobot 2000 fy-Sweep L fy-Sweep XL

Largura de trabalho [cm] 70 70 88 120 Autonomia [h] 4.0 4.0 6,0 8,0 Volume de tanques [L] 120 90 4,9 30 Peso [kg] 300 376 70 240 Comprimento [mm] 1000 1350 660 1150 Largura [mm] 755 900 880 730 Altura [mm] 980 1280 460 920 ´

Area limpa por hora [m2/h] 1125 1050 600 1200

Tabela 2.3: Tabela Resumo de Sistemas de Limpeza 3 Sistema de limpeza Ecobot Scrub75 Largura de trabalho [cm] 74.7 Autonomia [h] 6.0 Volume de tanques [L] 65 Peso [kg] -Comprimento [mm] 1290 Largura [mm] 760 Altura [mm] 1120 ´

Area limpa por hora [m2/h] 3227

Finalmente, a Tabela 2.4 apresenta uma compara¸c˜ao geral entre todos os sistemas em rela¸c˜ao `as caracter´ısticas principais referidas (largura de trabalho [cm], autonomia [h] e ´area limpa por hora [m2/h]), de forma a facilitar a conclus˜ao da an´alise do estado da arte dos sistemas aut´onomos de limpeza.

Tabela 2.4: Tabela de Compara¸c˜ao Geral de Sistemas Aut´onomos de Limpeza Robˆo / Caracter´ısticas Largura de Trabalho Autonomia Area limpa por hora´

RA660 Navi 66 2.5 1200 Swingobot 1650 74 4.0 929 Duobot 1850 64 4.0 929 Neo 81 5.0 -CR700 70 4.0 1125 Swingobot 2000 70 4.0 1050 fy-Sweep L 88 6.0 600 fy-Sweep XL 120 8.0 1200 Ecobot Scrub75 74.7 6.0 3227

Entre os sistemas aut´onomos de limpeza analisados, s˜ao exclu´ıdos das poss´ıveis solu¸c˜oes os sistemas que utilizem apenas aspira¸c˜ao como m´etodo de limpeza, visto que este m´etodo n˜ao ´e suficiente para efetuar a limpeza do tipo de detritos existentes no ch˜ao dos corredores da unidade industrial da Renault CACIA. Por esta raz˜ao, isto exclui das solu¸c˜oes vi´aveis os

´

E determinado que a melhor op¸c˜ao na aquisi¸c˜ao de um destes sistemas seja um robˆo que combine as opera¸c˜oes de sweeping com scrubbing. Dentro dos sistemas que satisfazem esta condi¸c˜ao, o que melhor satisfaz os requerimentos impostos ´e o ECOBOT Scrub75 da Gaussian Robotics, pois tem uma autonomia de trabalho em horas elevada e ´e capaz de limpar a maior ´

area por hora.

2.2

Sistemas Sensoriais

De uma forma geral, os robˆos m´oveis utilizados em espa¸cos interiores utilizam rodas para se movimentar. Um m´etodo b´asico para medir o movimento do robˆo ´e portanto atrav´es de sensores ´oticos ou magn´eticos, como encoders, e atrav´es de um conjunto de parˆametros conhecidos do robˆo, como o raio das rodas e a distˆancia entre as mesmas. Este m´etodo ´e chamado de odometria.

Com apenas a odometria de um robˆo m´ovel e conhecendo a sua posi¸c˜ao inicial ´e poss´ıvel localiz´a-lo dentro de um dado espa¸co. Isto ´e, com o c´alculo consecutivo da sua posi¸c˜ao atual, ´e poss´ıvel determinar a distˆancia do robˆo ao ponto inicial e assim saber a sua localiza¸c˜ao; este ´e o processo conhecido como ”dead reckoning ”.

Por´em, este m´etodo ´e sujeito a erros sistem´aticos que resultam, por exemplo, de imper-fei¸c˜oes na estrutura do robˆo, e a erros n˜ao sistem´aticos, como o escorregamento do robˆo quando este se move numa superf´ıcie irregular ou sofre alguma a¸c˜ao externa. Estes efeitos podem ser atenuados com a utiliza¸c˜ao de sensores internos mais avan¸cados, como girosc´opios e aceler´ometros ou at´e praticamente eliminados com a utiliza¸c˜ao de sensores externos como sensores laser, sonares e vis˜ao computacional com algoritmos pr´oprios.

2.2.1 Laser

Os scanners laser funcionam pela medi¸c˜ao do tempo entre a emiss˜ao e o regresso de um pulso laser, permitindo determinar a distˆancia a obst´aculos. Este tipo de sensores est´a em constante evolu¸c˜ao e ´e amplamente utilizado na rob´otica.

Tendo como base o tipo de sensor laser [12] utilizado na demonstra¸c˜ao pr´atica exposta no Cap´ıtulo 4, este tipo de sensores oferece vantagens como:

• Elevada resolu¸c˜ao angular (0.25° - 0.5°); • Elevada precis˜ao (cerca de 10mm); • Elevada velocidade de medi¸c˜ao;

• Os dados medidos podem ser interpretados diretamente como a distˆancia a um obst´aculo numa dada dire¸c˜ao (idˆentico aos sonares e de leitura muito mais simples quando com-parado a cˆamaras de imagem).

Algumas desvantagens dos sensores laser s˜ao: • Pre¸co elevado;

• N˜ao deteta corretamente obst´aculos de alguns materiais, como o vidro;

(fa-As Figuras 2.12a e 2.12b mostram, respetivamente, dados obtidos por sensores laser (Li-DAR - Light Detection And Ranging) a trˆes e a duas dimens˜oes.

(a) Mapa batim´etrico obtido com sensores LiDAR [13]

(b) Mapa 2D obtido com sensor LiDAR, visualizado no RViz

Figura 2.12: Representa¸c˜ao gr´afica de dados obtidos por sensores laser (LiDAR)

2.2.2 Sonar

Estes sensores baseiam-se no mesmo princ´ıpio de medi¸c˜ao da distˆancia a obst´aculos dos sensores laser, medindo o tempo da emiss˜ao de um sinal sonoro `a sua rece¸c˜ao para determinar a distˆancia a obst´aculos.

As vantagens principais da utiliza¸c˜ao deste tipo de sensores s˜ao: • Baixo pre¸co;

Por outro lado, estes sensores apresentam um elevado n´umero de desvantagens:

• Efeito de crosstalk: atua¸c˜ao de v´arios sonares idˆenticos no mesmo espa¸co pode provocar a rece¸c˜ao de sinais de sensores diferentes;

• Medi¸c˜oes muito mais lentas do que com laser (consequˆencia da grande diferen¸ca entre as velocidades do som e da luz);

• Baixa resolu¸c˜ao angular.

As Figuras 2.13a e 2.13b mostram, respetivamente, exemplos de dados obtidos por sensores ultrass´onicos (SONAR - Sound Navigation And Ranging) a trˆes e a duas dimens˜oes.

(a) Exemplo de medi¸c˜ao de profundidade utilizando sensores ultrass´onicos [14]

(b) Mapa 2D obtido com sensor ultrass´onico [15]

2.2.3 Vis˜ao

Em rela¸c˜ao aos tipos de sensores mencionados anteriormente, uma capacidade ´unica que os sensores de vis˜ao possuem ´e a possibilidade da utiliza¸c˜ao das propriedades da superf´ıcie dos obst´aculos, como a cor e a textura, para dete¸c˜ao e identifica¸c˜ao de objetos.

Algumas vantagens destes sensores s˜ao:

• Aquisi¸c˜ao de informa¸c˜ao 3D do ambiente (com vis˜ao est´ereo);

• Aquisi¸c˜ao de uma grande quantidade de informa¸c˜ao, como a identifica¸c˜ao de obst´aculos e o c´alculo da distˆancia aos mesmos, segmenta¸c˜ao de diferentes objetos, por exemplo, pelas suas formas e cores.

As principais desvantagens s˜ao:

• Capta¸c˜ao de imagem severamente influenciada pela ilumina¸c˜ao; • Requer grandes recursos computacionais para extra¸c˜ao de informa¸c˜ao.

A Figura 2.14 mostra um exemplo da aplica¸c˜ao de vis˜ao est´ereo na dete¸c˜ao de obst´aculos.

Figura 2.14: Exemplo de dete¸c˜ao de obst´aculos a distˆancias vari´aveis utilizando vis˜ao est´ereo [16]

Em conclus˜ao relativamente `a tecnologia sensorial existente, tendo em conta o tipo de ambiente que se encontra na nave industrial da Renault CACIA, a utiliza¸c˜ao de scanners laser num robˆo m´ovel seria perfeitamente vi´avel. Este tipo de sensor poderia ser utilizado em conjunto com cˆamaras de imagem digital, permitindo uma aquisi¸c˜ao de informa¸c˜ao mais completa que poderia inclusivamente ser utilizada para a an´alise da sujidade do espa¸co a limpar, para al´em de complementar as desvantagens referidas dos sensores laser.

Cap´ıtulo 3

Simula¸

c˜

ao

Atualmente existe j´a um n´umero consider´avel de algoritmos de mapeamento, localiza¸c˜ao e navega¸c˜ao para robˆos m´oveis, e considerou-se relevante explorar alguns destes para aplica¸c˜ao num robˆo m´ovel simulado que cont´em semelhan¸cas ao n´ıvel de sensores e atuadores em rela¸c˜ao aos robˆos de limpeza analisados. Para tal, foi criada uma simula¸c˜ao em ROS e Gazebo.

Com a simula¸c˜ao criada pretende-se estudar a aplica¸c˜ao dos algoritmos de mapeamento, localiza¸c˜ao e navega¸c˜ao dispon´ıveis, num robˆo m´ovel cujo tipo de movimento ´e semelhante ao dos sistemas de limpeza analisados, de forma a estudar a sua compatibilidade com a tarefa da limpeza dos corredores da Renault CACIA. Esta implementa¸c˜ao tem ainda como um dos principais objetivo o estudo da eficiˆencia de algumas trajet´orias quanto ao tempo de execu¸c˜ao e ´area navegada.

Para a implementa¸c˜ao desta tarefa, foi necess´aria a cria¸c˜ao do ambiente 3D que replica os corredores da zona de testes (superf´ıcie dos corredores, com zonas da maquinaria interditas ao robˆo), a cria¸c˜ao do mapa 2D para a navega¸c˜ao do robˆo e a cria¸c˜ao de um programa que utiliza os n´os de ROS respons´aveis pelo planeamento de trajet´orias e navega¸c˜ao do robˆo para definir as trajet´orias a percorrer. As sec¸c˜oes seguintes destinam-se `a exposi¸c˜ao deste conte´udo.

3.1

Plataforma de Desenvolvimento

Esta sec¸c˜ao procura apresentar e justificar as escolhas em rela¸c˜ao ao hardware e software utilizados no projeto.

3.1.1 Software

Os seguintes t´opicos explicam de forma breve o software envolvido no desenvolvimento pr´atico desta disserta¸c˜ao.

Neste ˆambito, foi utilizado um conjunto de softwares para o desenvolvimento da simula¸c˜ao de navega¸c˜ao do robˆo m´ovel (ROS, Gazebo e RViz) que implica a escrita de c´odigo em Python. Este software ´e executado numa distribui¸c˜ao espec´ıfica de Linux, o Ubuntu.

ROS

O ROS (Robotic Operating System) ´e um framework para desenvolvimento de software de robˆos. Cont´em um conjunto de ferramentas, bibliotecas e regras cujo objetivo ´e simplificar

a tarefa da cria¸c˜ao de comportamentos robustos e complexos de robˆos numa variedade de plataformas rob´oticas.

A utiliza¸c˜ao do ROS neste projeto deve-se `a sua modularidade, existˆencia de software que integra o hardware do robˆo com as tarefas que este ir´a implementar, documenta¸c˜ao extensa, disponibilidade de tutoriais e possibilidade do desenvolvimento em comunidade, uma vez que opera sob uma licen¸ca que permite a sua utiliza¸c˜ao em produtos comerciais e/ou closed source. O ROS possui pacotes de software otimizados e prontos a utilizar com um m´ınimo de parametriza¸c˜ao necess´ario. No caso em estudo, estes s˜ao utilizados para a estimativa de pose, localiza¸c˜ao, mapeamento e navega¸c˜ao de um robˆo, bem como para a pr´opria visualiza¸c˜ao e grava¸c˜ao dos dados da simula¸c˜ao.

Explicado de forma breve, o ROS opera sob o seguinte formato conceptual, a n´ıvel com-putacional [17]:

• N´os: processos computacionais, o sistema de controlo de um robˆo consiste na opera¸c˜ao conjunta de v´arios n´os (e.g. um para aquisi¸c˜ao de dados de um scanner laser, um para o controlo dos atuadores, outro para localiza¸c˜ao, entre outros);

• Master: O ROS Master controla todos os n´os, faz a atribui¸c˜ao e procura de nomes para que os n´os possam comunicar entre eles;

• Mensagens: estrutura de dados de tipos padr˜ao (inteiro, flutuantes, booleanos, etc.) para comunica¸c˜ao entre diferentes n´os do ROS;

• T´opicos: o ROS gere a comunica¸c˜ao entre diferentes n´os atrav´es de um sistema de publica¸c˜ao/subscri¸c˜ao. Um n´o envia uma mensagem publicando-a para um dado t´opico. Um t´opico ´e um nome usado para identificar o conte´udo de uma mensagem. Um n´o ”subscreve-se”(conecta-se) a um t´opico quando necessita especificamente da informa¸c˜ao que este cont´em;

• Servi¸cos: definidos por dois tipos de estrutura de mensagem, um para pedidos e outro para respostas. Um dado n´o oferece um servi¸co com um nome e um dado cliente (outro n´o) usa este servi¸co enviando-lhe uma ”mensagem pedido”e esperando pela respetiva resposta;

• Bags: formato de grava¸c˜ao e playback de dados do ROS.

Esclarecendo a diferen¸ca entre um servi¸co e um t´opico do ROS, um servi¸co ´e uma via de comunica¸c˜ao de um-para-um n´o, enquanto um t´opico pode ser publicado e subscrito por v´arios n´os simultaneamente.

A Figura 3.1 ilustra os conceitos mencionados anteriormente, mostrando como pode ser realizada a comunica¸c˜ao entre dois n´os distintos.

Figura 3.1: Diagrama de Conceitos B´asicos de ROS [17]

A vers˜ao deste software utilizada no desenvolvimento da simula¸c˜ao ´e o ROS Kinetic Kame. Python

O Python ´e uma linguagem de programa¸c˜ao de alto-n´ıvel para uso geral, orientada a objetos, dinˆamica e de f´acil leitura de c´odigo.

´

E uma linguagem de programa¸c˜ao suportada pelo ROS, juntamente com C++. Foi dada preferˆencia ao Python pela sua facilidade de escrita e legibilidade.

A vers˜ao de Python utilizada no desenvolvimento da simula¸c˜ao ´e a s´erie 2.7.x. Gazebo

O Gazebo ´e um conjunto de bibliotecas e software de simula¸c˜ao de rob´otica com motor de f´ısica e gr´aficos 3D. Este software permite a cria¸c˜ao de ambientes 3D e visualiza¸c˜ao da intera¸c˜ao de modelos rob´oticos com estes ambientes.

A vers˜ao de Gazebo utilizada no desenvolvimento da simula¸c˜ao ´e a s´erie 7.x, compat´ıvel com a vers˜ao de ROS definida.

RViz

O RViz ´e uma ferramenta de visualiza¸c˜ao de dados para ROS. Possui uma interface para visualiza¸c˜ao de dados sensoriais, modelos de robˆos e mapas de ambientes simulados para desenvolvimento e debug de projetos de controlo de robˆos.

Ubuntu

O Ubuntu ´e um sistema operativo “open-source” e uma distribui¸c˜ao de Linux baseada em Debian.

A utiliza¸c˜ao do ROS Kinetic Kame implica a utiliza¸c˜ao de um sistema operativo com-pat´ıvel. Nesta disserta¸c˜ao foi escolhido o Ubuntu Xenial (16.04 LTS).

3.1.2 Hardware

O hardware simulado neste projeto foi o robˆo m´ovel did´atico Turtlebot 2 (sec¸c˜ao 4.1.1), ilustrado na Figura 3.2.

Figura 3.2: Robˆo M´ovel Turtlebot 2 [18]

3.2

SLAM - Simultaneous Localization and Mapping

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 carregamovi-mento. 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.

3.6

Coment´

arios Finais

Sumariamente, ´e poss´ıvel concluir-se com esta simula¸c˜ao que o melhor trajeto a imple-mentar ´e o que efetua o menor n´umero de manobras (executa trajetos com retas maiores), pois assim torna-se mais r´apido e apresenta um menor gasto de energia, logo ´e tamb´em o mais eficiente.

O ROS ´e uma solu¸c˜ao vi´avel na implementa¸c˜ao do sistema de controlo para um robˆo m´ovel, pois integra de forma relativamente simples o hardware do robˆo com o seu software, n˜ao sendo necess´aria a cria¸c˜ao de drivers para o hardware, se este for compat´ıvel com ROS.

No mesmo sentido, os algoritmos testados, nomeadamente o GMapping no processo de mapeamento, o AMCL na localiza¸c˜ao e o A* na navega¸c˜ao, s˜ao solu¸c˜oes vi´aveis para o software de controlo do robˆo, tendo sido verificados resultados positivos no planeamento de trajet´orias e desvio de obst´aculos. No cap´ıtulo seguinte ´e feita a valida¸c˜ao experimental tanto do hardware como do software utilizados na simula¸c˜ao, numa ´area pr´e-definida nos corredores da nave industrial da Renault CACIA.

O c´odigo de ambos os scripts encontra-se em anexo, devidamente comentado, para uma compreens˜ao mais detalhada do programa.

Cap´ıtulo 4

Demonstra¸

c˜

ao Turtlebot 2

De forma a testar experimentalmente os recursos simulados, foi realizada uma demons-tra¸c˜ao pr´atica do Turtlebot 2 numa zona de corredores da nave fabril da Renault CACIA.

Esta demonstra¸c˜ao consistiu em duas fases, a de mapeamento da ´area de teste e a na-vega¸c˜ao na mesma.

4.1

Setup

O hardware e software utilizados nesta demonstra¸c˜ao foram, salvo algumas exce¸c˜oes, os mesmos da simula¸c˜ao. Isto permitiu assim avaliar a viabilidade dos resultados da simula¸c˜ao e o comportamento real do controlo de um robˆo m´ovel utilizando o ROS.

4.1.1 Hardware

O robˆo utilizado na demonstra¸c˜ao foi o Turtlebot 2 (Figura 4.1), equipado com um LiDAR 2D, o SICK LMS100.

Turtlebot 2

O Turtlebot 2 ´e a segunda vers˜ao do robˆo m´ovel did´atico Turtlebot, de baixo custo e com software open-source. Possui uma base m´ovel (Kobuki) que permite a liga¸c˜ao a um computador com ROS e ´e compat´ıvel com v´arios sensores, como sensores laser, sensores de contacto mecˆanico e encoders.

A utiliza¸c˜ao de um LiDAR deve-se principalmente ao elevados alcance e precis˜ao de um sensor laser, ideal para a situa¸c˜ao da demonstra¸c˜ao.

De seguida s˜ao apresentadas as caracter´ısticas mais relevantes deste robˆo [36]: • Velocidade m´axima (transla¸c˜ao): 70cm/s;

• Velocidade m´axima (rota¸c˜ao): 180°/s; • Payload: 5kg;

• Odometria (encoders): 52 pulsos/volta (enc), 2578.33 pulsos/volta (roda), 11.7 pul-sos/mm;

Figura 4.1: Robˆo M´ovel Turtlebot 2 [18]

SICK LMS100

O LMS100 ´e um LiDAR 2D. Num robˆo m´ovel, ´e utilizado para obter dados da distˆancia a obst´aculos para mapeamento e localiza¸c˜ao.

A lista que se segue mostra alguns dados relevantes deste sensor [12]. • ˆAngulo de abertura 270°;

• Frequˆencia de scan 25Hz/50Hz; • Resolu¸c˜ao angular: 0.25°/0.5°; • Alcance: 0.5m...20m.

A Figura 4.2 demonstra o aspeto visual dos LiDAR 2D da s´erie LMS1XX da SICK.

4.1.2 Software

O software utilizado na demonstra¸c˜ao foi, tal como na simula¸c˜ao, o ROS, para a utiliza¸c˜ao dos n´os/pacotes de gmapping, amcl, map server e turtlebot teleop, RViz para visualiza¸c˜ao do processo de mapeamento e localiza¸c˜ao do robˆo.

Para poder utilizar o ROS no computador que controla o Turtlebot, ´e necess´ario que os dois computadores (Turtlebot e controlo) estejam ligados `a mesma rede local e que ambos estejam a executar o ROS. ´E necess´ario tamb´em adicionar as seguintes linhas de c´odigo ao ficheiro /.bashrc do computador de controlo:

# IP l o c a l do T u r t l e b o t ( exemplo )

e x p o r t ROS MASTER URI=h t t p : / / 1 9 2 . 1 6 8 . 8 . 1 7 0 : 1 1 3 1 1

# IP l o c a l do computador de c o n t r o l o ( exemplo )

e x p o r t ROS IP = 1 9 2 . 1 6 8 . 8 . 1 6 1

4.2

Mapeamento

O processo de mapeamento consistiu na utiliza¸c˜ao dos n´os de ROS respons´aveis pela aquisi¸c˜ao de dados sensoriais para a constru¸c˜ao do grid map 2D que resulta depois na re-ferˆencia do robˆo para a localiza¸c˜ao e navega¸c˜ao no ambiente em que se encontra.

Para iniciar o mapeamento da zona definida, foram executados os seguintes comandos no computador do Turtlebot [33]:

# Execu ¸c ˜a o d o s n´o s de f u n c i o n a m e n t o b a s e do T u r t l e b o t

r o s l a u n c h t u r t l e b o t b r i n g u p minimal . l a u n c h

# I n i c i a o n´o gmapping do ROS

r o s l a u n c h t u r t l e b o t n a v i g a t i o n gmapping demo . l a u n c h

No computador de controlo, foram executados os comandos seguintes:

# 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 em tempo r e a l

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

# I n i c i a o n´o de c o n t r o l o , p e r m i t e c o n t r o l o p e l o t e c l a d o

r o s l a u n c h t u r t l e b o t t e l e o p k e y b o a r d t e l e o p . l a u n c h

A Figura 4.3 representa o mapa constru´ıdo pelos scans laser do Turtlebot 2 utilizando o pacote de gmapping do ROS.

Figura 4.3: Grid map constru´ıdo com GMapping na demonstra¸c˜ao pr´atica

A Figura 4.4 representa, delimitada a vermelho no excerto da planta do edif´ıcio, a ´area da zona de testes correspondente `a Figura 4.3 que foi mapeada pelo Turtlebot 2.

No final de mapear a zona pretendida, foram gravados os ficheiros yaml e pgm correspon-dentes ao mapa criado. Para a grava¸c˜ao, pode ser escrito no terminal do Turtlebot ou do computador de controlo o c´odigo abaixo:

# Execu ¸c ˜a o do n´o m a p s e r v e r p a r a g r a v a ¸c ˜a o do mapa c r i a d o .

r o s r u n m a p s e r v e r m a p s a v e r − f < d i r e t o r i a >/<nome do mapa>

Neste momento o mapa constru´ıdo ´e j´a utiliz´avel para navega¸c˜ao nas zonas a branco, apesar de n˜ao ter sido feito nenhum tratamento da imagem (no ficheiro pgm). Neste ficheiro, edit´avel em editores de imagem compat´ıveis com o formato, podem ser removidas zonas irre-levantes ou adicionadas ”paredes”virtuais para evitar que o robˆo entre em zonas indesejadas.

4.3

Navega¸

c˜

ao

Na fase da demonstra¸c˜ao da navega¸c˜ao do robˆo na ´area mapeada, foram utilizadas as fun¸c˜oes de 2D Pose Estimate e 2D Nav Goal para atribuir pontos de destino ao robˆo, de forma a verificar experimentalmente o comportamento dos algoritmos amcl (localiza¸c˜ao) e A*/Dijkstra (navega¸c˜ao) num ambiente fabril. Ao fornecer um dado ponto no mapa, o robˆo calcula o melhor trajeto para o ponto, desloca-se para ele e desvia-se de qualquer obst´aculo, mesmo aqueles que n˜ao foram mapeados (e.g. pessoas e ve´ıculos), como demonstrado na Figura 4.5.

Figura 4.5: Demonstra¸c˜ao pr´atica em RViz da navega¸c˜ao com Turtlebot 2 utilizando A* e AMCL

Na Figura 4.5, pode ser visualizado o robˆo (mancha verde) no centro do local map (qua-drado colorido) produzido pelas leituras sensoriais do robˆo. Dentro do local map s˜ao assi-nalados os obst´aculos na vizinhan¸ca do robˆo. a linha verde representa a melhor trajet´oria calculada pelo algoritmo A*.

Para iniciar a navega¸c˜ao, ´e necess´ario primeiro iniciar o ROS em ambos os dispositivos (Turtlebot e computador de controlo). De seguida, do lado do computador do Turtlebot, ´e necess´ario executar os seguintes comandos:

# Executa o s n´o s n e c e s s ´a r i o s ao f u n c i o n a m e n t o b a s e do T u r t l e b o t

r o s l a u n c h t u r t l e b o t b r i n g u p minimal . l a u n c h

# F o r n e c i m e n t o do mapa g r a v a d o ao amcl

r o s l a u n c h t u r t l e b o t n a v i g a t i o n amcl demo . l a u n c h \ m a p f i l e :=/tmp/my map . yaml

Ap´os a prepara¸c˜ao dos sistemas, do lado do computador de controlo, ´e necess´ario introdu-zir a posi¸c˜ao inicial estimada do robˆo no RViz, com a fun¸c˜ao 2D Pose Estimate, para reduzir a incerteza do amcl. A partir deste momento, com a fun¸c˜ao 2D Nav Goal no RViz, podem ser enviados pontos para o robˆo.

4.4

Reprodu¸

c˜

ao de Ficheiros bag

Os dados da demonstra¸c˜ao, desde a constru¸c˜ao do mapa `a navega¸c˜ao dentro do mapa constru´ıdo foram gravados com o comando de ROS “rosbag record -a”enquanto se execu-tavam os processos, que permite a grava¸c˜ao de todos os t´opicos dos n´os de ROS em execu¸c˜ao. Assim ´e poss´ıvel visualizar novamente todo o processo executado, utilizando o c´odigo seguinte na consola:

Mapeamento:

# Execu ¸c ˜a o do ROS

r o s c o r e

# Reprodu ¸c ˜a o d o s c o n t e ´u d o s d o s t ´o p i c o s g r a v a d o s

r o s b a g p l a y <nome do f i c h e i r o mapeamento >. bag

# Reprodu ¸c ˜a o v i s u a l da o p e r a ¸c ˜a o de mapeamento 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 Navega¸c˜ao: # Execu ¸c ˜a o do ROS r o s c o r e # F o r n e c i m e n t o do mapa g r a v a d o ao m a p s e r v e r

r o s r u n m a p s e r v e r m a p s e r v e r <nome do mapa>. yaml

# Reprodu ¸c ˜a o d o s c o n t e ´u d o s d o s t ´o p i c o s g r a v a d o s

r o s b a g p l a y <nome do f i c h e i r o navega ¸c ˜ao >. bag

# Reprodu ¸c ˜a o v i s u a l da o p e r a ¸c ˜a o de navega ¸c ˜a 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

4.5

Coment´

arios Finais

Concluindo este cap´ıtulo, o m´etodo de mapeamento utilizado com o algoritmo GMapping e o hardware dispon´ıvel demonstrou ser pr´atico, r´apido e eficiente. O mapa visualizado na Figura 4.3 foi constru´ıdo em cerca de 15 minutos (dura¸c˜ao aproximada do ficheiro bag que cont´em a grava¸c˜ao do processo), com uma ´area estimada do espa¸co de 400m2.

Assim, seria expect´avel que o mapeamento da ´area total estimada dos corredores (1900m2) tivesse uma dura¸c˜ao n˜ao muito superior a uma hora, o que ´e um resultado bastante satisfat´orio quando comparado aos sistemas existentes que requerem mapeamento pr´evio do espa¸co de trabalho.