Navegação híbrida num veículo autónomo com direção Ackermann

(1)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática 2016

Jo˜

ao Bernardo

Godinho Alves

Navega¸

c˜

ao H´ıbrida num Ve´ıculo Aut´

onomo com

Dire¸

c˜

ao Ackermann

(2)

(3)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática 2016

Jo˜

ao Bernardo

Godinho Alves

Navega¸

c˜

ao H´ıbrida num Ve´ıculo Aut´

onomo com

Dire¸

c˜

ao Ackermann

Disserta¸cão apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obten¸cão do grau de Mestre em Engenharia de Computadores e Telemática, realizada sob a orienta¸cão cient´ıfica de Artur José Carneiro Pereira, Professor Auxiliar do Departamento de Eletrónica, Telecomunica¸cões e Informática

(4)

(5)

o j´uri / the jury

presidente / president Professor Doutor Lu´ıs Filipe de Seabra Lopes

Professor Associado da Universidade do Aveiro

vogais / examiners committee Professor Doutor Armando Jorge Miranda de Sousa

Professor Auxiliar da Universidade do Porto

Professor Doutor Artur Jos´e Carneiro Pereira

(6)

(7)

agradecimentos / acknowledgements

Agrade¸co ao meu orientador, Professor Artur Pereira, e ao colaborador Eu-rico Pedro pela oportunidade prestada, pela imensa paciência e pelos co-nhecimentos adquiridos e transmitidos. Agrade¸co também à minha fam´ılia, que sempre fez de tudo para resolver qualquer tipo de problema que me incomoda-se, e a todos os meus colegas de Aveiro, em particular ao Da-vid Simões e Bernardo Marques, mas também àqueles que realizaram esta fase do percurso académico em simultâneo comigo. Agrade¸co também aos restantes elementos do IRIS-Lab que contribu´ıram para o desenvolvimento desta disserta¸cão.

(8)

(9)

Palavras chave Condu¸cão autónoma, ROS, navega¸cão h´ıbrida, Simula¸cão em robótica, Fes-tival Nacional de Robótica

Resumo O progresso realizado na área de condu¸cão autónoma torna poss´ıvel a existência, no mercado automóvel, de ve´ıculos capazes de se conduzir auto-nomamente com algumas restri¸cões. Este progresso contribui também para o aumento das funcionalidades de condu¸cão assistida oferecidas pelas em-presas. O ROTA é um pequeno ve´ıculo robótico que participa normalmente no Festival Nacional de Robótica, na prova de condu¸cão autónoma, onde tem de conduzir autonomamente numa pista com caracter´ısticas semelhan-tes àquelas encontradas numa estrada convencional.

No in´ıcio deste projeto, o software de controlo de alto n´ıvel do ve´ıculo ROTA baseava a sua navega¸cão num algoritmo de localiza¸cão global na pista. Isto resultava num movimento oscilatório, mesmo quando o ve´ıculo se deslocava ao longo de uma faixa de rodagem. Foi objetivo desta disserta¸cão o desenvolvimento de um módulo de navega¸cão de seguimento da faixa de rodagem, que proporcionasse um movimento mais suave, e a sua integra¸cão no software existente, criando um sistema de navega¸cão h´ıbrida que use em cada situa¸cão a estratégia mais adequada. Não existindo uma pista real, nem condi¸cões para construir uma, definiu-se também o objetivo de conceber e desenvolver um ambiente de simula¸cão realista que permitisse testar os algoritmos desenvolvidos, num formato que minimizasse o seu porte para o ambiente real.

O ambiente de simula¸cão desenvolvido inclui o ve´ıculo e a pista. Rela-tivamente ao ve´ıculo, o seu sistema de locomo¸cão, baseado em dire¸cão Ackermann, o seu sistema de visão, com capacidade de pan e tilt, e as funcionalidades de produ¸cão e de disponibiliza¸cão de informa¸cão por parte dos vários sensores foram desenvolvidos, de tal forma que o software que corre nas plataformas real e virtual é exatamente o mesmo. O ambiente de simula¸cão permite reproduzir o cenário de competi¸cão presente na prova de condu¸cão autónoma do Festival Nacional de Robótica.

Foi desenvolvido o módulo de navega¸cão que efetua o seguimento de faixa de rodagem. O seu funcionamento assenta na localiza¸cão do ve´ıculo de-finida em termos do posicionamento transversal e da orienta¸cão na faixa de rodagem. A localiza¸cão é probabil´ıstica, usando histogramas para re-presentar as distribui¸cões de probabilidade, sendo utilizada informa¸cão pro-veniente de um dispositivo RGB-D (câmara Kinect). Filtros de Bayes são usados para manter boas estimativas destas distribui¸cões. O sistema de navega¸cão h´ıbrida pode, sempre que achar necessário, comutar para outro comportamento mais adequado à situa¸cão presente.

O desempenho dos algoritmos de navega¸cão e a facilidade de porte destes do robô simulado para o real permitiram ao ve´ıculo ROTA alcan¸car o se-gundo lugar na prova de condu¸cão autónoma na edi¸cão de 2016 do Festival

(10)

(11)

Keywords Autonomous driving, ROS, hybrid navigation, Simulation in robotics, Por-tuguese Robotics Open

Abstract The progress made in autonomous driving makes possible the existence, in the automotive market, of vehicles able to drive autonomously with some restrictions. This progression also contributes to increase the assisted dri-ving features offered by companies. ROTA is a small robotic vehicle that usually participates in the autonomous driving competition on the Portu-guese Robotics Open, where it has to drive autonomously on a track that has similar characteristics with those found on a conventional road. In the beginning of this project, the high level control software of this vehi-cle had its navigation based in a global localization algorithm. This took to an oscillatory movement, even when the vehicle was moving along the lane. One objective of this dissertation was the development of a navigation mo-dule able to follow a lane, that could provide a smoother movement, and its integration with the existing software, creating a hybrid navigation system that uses the most appropriate strategy in each situation. In the absence of a real track and the lack of conditions to build one, it was also defined as an objective, conceiving and developing a realistic simulation environment that would allow to test the algorithms developed, in such a way that minimizes the transfer time to the real environment.

The simulated environment includes the vehicle and the track. Regarding the vehicle, its locomotion system, based in Ackermann steering, its vision system, with pan and tilt capabilities, as well as the production and avai-lability of its sensors’ information have been developed, in such a way that the software that runs in the real and virtual platforms is exactly the same. The simulation environment allows to reproduce the scenario present in the autonomous driving competition of the Portuguese Robotics Open.

It was developed a navigation module to follow a lane. The operation of this module is based on the vehicle location defined in terms of transverse po-sitioning and orientation on the lane. The localization is probabilistic, and relies on histograms to represent probability distribution functions, using information that comes from an RGB-D device (Kinect camera). Baye-sian Filters are used get good estimates of these distributions. The hybrid navigation system may, whenever necessary, switch to a behaviour more appropriate to the current situation.

The navigation algorithms performance and its easy transfer from the simu-lated robot to the real one, allowed ROTA to achieve second place in the autonomous driving competition on the Portuguese Robotics Open 2016 edition.

(12)

(13)

Conte´

udo

Conte´udo i

Lista de Figuras v

Lista de Tabelas vii

Siglas viii 1 Introdu¸cão 1 1.1 Motiva¸cão e contexto . . . 1 1.2 Objetivos . . . 1 1.3 Estrutura da disserta¸cão . . . 2 2 Projeto ROTA 3 2.1 Plataforma ROTA . . . 3 2.1.1 Locomo¸cão Ackermann . . . 4 2.1.2 Perce¸cão . . . 5

2.1.3 Controlo de baixo n´ıvel . . . 5

2.2 Robot Operating System . . . 6

2.2.1 Infraestrutura base . . . 7

2.2.2 Servi¸cos e Parˆametros . . . 7

2.2.3 Bibliotecas de suporte . . . 8

2.2.4 Ferramentas de apoio ao desenvolvimento . . . 9

2.3 Prova de Condu¸cão Autónoma do Festival Nacional de Robótica . . . 9

2.3.1 Ambiente de competi¸c˜ao . . . 10

2.3.2 Competi¸c˜ao . . . 11

2.4 Software de Controlo de Alto N´ıvel . . . 12

3 Simula¸cão 15 3.1 Simula¸cão em robótica . . . 15

3.2 Ambientes de simula¸c˜ao . . . 16

3.2.1 Preferˆencia pelo Gazebo . . . 19

3.3 Gazebo . . . 20

(14)

3.3.2 Motor gr´afico . . . 21 3.3.3 Sensores . . . 21 3.3.4 Plugins . . . 22 3.3.5 Arquitetura . . . 22 3.4 Linguagens de modela¸c˜ao . . . 23 3.4.1 SDF . . . 24 3.4.2 URDF . . . 25

4 Navega¸cão em ve´ıculos autónomos 27 4.1 Modela¸cão da faixa de rodagem . . . 27

4.2 Dete¸c˜ao da faixa de rodagem . . . 28

4.3 Seguimento da faixa de rodagem . . . 31

4.4 Planeamento de trajet´oria em ve´ıculos com locomo¸c˜ao Ackermann . . . 33

5 Ambiente de simula¸c˜ao para o projeto ROTA 35 5.1 Modela¸c˜ao do ve´ıculo . . . 35

5.1.1 Modela¸c˜ao do chassis . . . 36

5.1.2 Modela¸c˜ao do sistema de locomo¸c˜ao . . . 36

5.1.3 Modela¸c˜ao do sistema laser . . . 37

5.1.4 Modela¸c˜ao do sistema de vis˜ao . . . 37

5.2 Modela¸c˜ao do ambiente . . . 37

5.2.1 Modela¸c˜ao da pista . . . 38

5.2.2 Modela¸c˜ao do painel sinal´etico . . . 38

5.2.3 Modela¸c˜ao dos sinais verticais . . . 39

5.2.4 Modela¸cão dos obstáculos, túnel e da zona de obras . . . 39

5.3 Plugins . . . 39

5.3.1 Plugin do ve´ıculo . . . 40

5.3.2 Plugin do painel sinal´etico . . . 42

5.3.3 Plugin do ambiente . . . 42

5.4 Valida¸c˜ao do ambiente de simula¸c˜ao . . . 43

5.4.1 Direc¸c˜ao Ackermann . . . 43

5.4.2 Sensores . . . 44

5.4.3 Diferen¸cas entre ambiente de simula¸c˜ao e mundo real . . . 45

5.5 Sum´ario . . . 45

6 Localiza¸c˜ao 47 6.1 Localiza¸c˜ao na pista . . . 47

6.2 Localiza¸c˜ao na faixa de rodagem . . . 48

6.3 Remo¸c˜ao do efeito perspetiva . . . 49

6.4 Extra¸c˜ao de caracter´ısticas . . . 50

6.5 Extra¸c˜ao semˆantica . . . 52

6.6 Filtro de histogramas . . . 54

(15)

6.8 Sum´ario . . . 56

7 Navega¸c˜ao 59 7.1 Arquitetura do Agente . . . 59

7.2 Copiloto . . . 59

7.3 Seguimento da faixa de rodagem . . . 61

7.4 Resultados . . . 62

7.5 Sum´ario . . . 64

8 Conclus˜ao e trabalho futuro 65 8.1 Conclus˜ao . . . 65

8.2 Trabalho futuro . . . 66

(16)

(17)

Lista de Figuras

2.1 Robˆo ROTA . . . 3

2.2 Dire¸c˜ao Ackermann . . . 4

2.3 Camada de perce¸c˜ao e atua¸c˜ao de baixo n´ıvel . . . 6

2.4 Processo de publica¸cão e subscri¸cão de um tópico, obten¸cão do conteúdo de um parâmetro e utiliza¸cão de um servi¸co . . . 8

2.5 Pista da prova de condu¸cão autónoma usada na edi¸cão de 2015 do Festival Nacional de Robótica . . . 10

2.6 Sinais de trânsito mostrados nos painéis sinaléticos colocados sobre a passadeira 10 2.7 Sinais de trânsito verticais colocados ao longo da pista . . . 11

2.8 Arquitetura da camada de alto n´ıvel . . . 13

3.1 Tipo de juntas, adaptado de [27] . . . 20

3.2 Modelo com e sem textura . . . 21

3.3 Arquitetura geral do gazebo, adaptado de [17] . . . 23

3.4 Ambiente de simula¸c˜ao Gazebo com o robˆo PR2 e diversos elementos . . . 24

3.5 Hierarquia dos v´arios elementos nda linguagem SDF . . . 26

4.1 Array acumulador de votos. C´elula a preto representa os parˆametros de uma poss´ıvel linha . . . 31

4.2 Caracter´ısticas da linha delimitadora . . . 32

4.3 Compara¸c˜ao gr´afica dos algoritmos de pesquisa . . . 34

5.1 Modelo do robˆo . . . 36

5.2 mesh do link base . . . 37

5.3 Pistas . . . 38

5.4 Pista com Monitores, obst´aculos, sinais verticais, zona de obras e t´unel . . . . 39

5.5 Informa¸c˜ao recebida e fornecida pelo plugin Sim Car Base . . . 40

5.6 Compara¸cão entre a posi¸cão angular desejada e a posi¸cão real da roda direita ao longo do tempo . . . 43

5.7 Componentes substitu´ıdas pelo ambiente de simula¸c˜ao . . . 46

6.1 Cadeia de processamento para estimativa da postura do robˆo . . . 49

6.2 Remo¸c˜ao do efeito perspetiva . . . 50

(18)

6.4 Identifica¸cão das linhas delimitadoras da faixa de rodagem após extra¸cão semântica

das linhas resultantes da aplica¸c˜ao da transformada de Hough . . . 53

6.5 Histograma de medida da posi¸c˜ao transversal correspondente `as linhas delimi-tadoras mostradas na figura 6.4 . . . 53

6.6 Robˆo a circular na faixa da direita . . . 55

6.7 Robˆo a comutar de faixa . . . 55

6.8 Robˆo a circular na faixa da esquerda . . . 56

6.9 Desenvolvimento de m´odulos de localiza¸c˜ao . . . 57

7.1 M´aquina de estados da navega¸c˜ao . . . 60

7.2 Passadeira e vizinhan¸ca . . . 61

7.3 Sistema de controlo para o seguimento da faixa de rodagem . . . 62

(19)

Lista de Tabelas

3.1 Compara¸cão URDF/SDF . . . 26 5.1 Compara¸cão entre laser real e laser simulado . . . 44 6.1 Tempo de execu¸cão de cada fase do pipeline . . . 56

(20)

Siglas

API application programming interface. 10, 19, 21, 25, 41, 43 CAN Controller Area Network. 6, 7

GUI graphical user interface. 19 HAL Hardware Abstration Layer. 14 ICR Instantaneous Center of Rotation. 6 LLI Low-Level Infrastructure. 14

LRF Laser Range Finder. 7, 8, 14, 21, 24, 39, 47, 63, 68 OGRE Object-oriented Graphics Rendering Engine. 19, 23

ROS Robot Operating System. 5, 8–11, 14, 20–22, 26, 27, 35, 37, 42–44, 49, 52–54 URDF Unified Robot Description Format. 27, 28

(21)

Cap´ıtulo 1

Introdu¸

c˜

ao

1.1 Motiva¸

c˜

ao e contexto

Esta disserta¸cão foi desenvolvida no âmbito do projeto ROTA do IRIS-Lab (IEETA) da Universidade de Aveiro. O ROTA é um pequeno ve´ıculo robótico que surge no contexto de investiga¸cão em sistemas de condu¸cão autónoma e assistência à condu¸cão. Este ve´ıculo participa normalmente no Festival Nacional de Robótica na prova de condu¸cão autónoma, onde tem de conduzir autonomamente numa pista com caracter´ısticas semelhantes a uma estrada convencional.

Desenvolver algoritmos para esta competi¸cão pode dar origem a algoritmos que poderão ser usados em ambientes do mundo real, podendo estes ser usados para assistir o condutor na condu¸cão ou até mesmo para a realiza¸cão de condu¸cão autónoma. Em ambos os casos, pretende-se aumentar a seguran¸ca das pessoas que se encontram dentro e fora do ve´ıculo. Uma das fases mais cr´ıtica do desenvolvimento de software é a fase de testes, onde se determina a qualidade do software com base em critérios previamente estabelecidos. No campo da robótica, a fase de testes serve para testar na prática se a implementa¸cão de uma determinado algoritmo resulta num bom desempenho do robô numa tarefa espec´ıfica. O teste ideal teria de envolver o robô e o ambiente em que este iria desempenhar esta tarefa. Pode, no entanto, não ser poss´ıvel realizar este teste, devido a restri¸cões de recursos, como por exemplo espa¸co. Numa destas situa¸cões, pode-se no entanto recorrer-se a um ambiente simulado para se efetuar o teste, eliminando-se quer as restri¸cões de espa¸co, quer as restri¸cões a n´ıvel f´ısico. Uma das vantagens que se pode destacar é a possibilidade de qualquer pessoa poder usar o ambiente simulado desde que possua um sistema computacional com o hardware necessário para tal.

1.2 Objetivos

Atualmente o IRIS-Lab não possui nenhuma pista (total ou parcial) onde possa testar o software desenvolvido para o projeto ROTA. Por isso, a existência de um ambiente virtual de apoio ao desenvolvimento e teste é uma mais valia importante. A conce¸cão e desenvolvimento deste ambiente deve ter presente dois aspetos. Por um lado, pretende-se testar adequada-mente os algoritmos desenvolvidos. Por outro lado, queremos potenciar o porte do software

(22)

desenvolvido do ambiente simulado para o real. Assim, a concretiza¸cão de um ambiente de simula¸cão que permita atingir estes objetivos deve dar origem a um ambiente de simula¸cão o mais completo e realista poss´ıvel, pelo menos relativamente aos aspetos relevantes para o desenvolvimento.

A versão do software existente aquando do in´ıcio desta disserta¸cão baseava toda a na-vega¸cão no conhecimento que o ve´ıculo tinha da sua posi¸cão e orienta¸cão na pista. Em consequência, o ve´ıculo manifestava um andamento muito oscilatório, mesmo quando seguia por uma faixa de rodagem com limites bem definidos. Nestas situa¸cões, parece mais adequado que o ve´ıculo siga um comportamento de seguimento da faixa de rodagem, sem grandes pre-ocupa¸cões sobre o seu posicionamento longitudinal nessa faixa. Assim a concretiza¸cão do segundo objetivo pressupõe a conce¸cão e implementa¸cão de um modelo de localiza¸cão na faixa de rodagem, de desenvolvimento de um algoritmo de navega¸cão assente nesse modelo e da sua integra¸cão no software já existente. A utiliza¸cão deste comportamento de navega¸cão deve estar reservado às regiões da pista onde se adeque, sendo as restantes regiões cobertas pelas abordagens já existentes.

1.3 Estrutura da disserta¸

c˜

ao

Este documento encontra-se dividido em oito cap´ıtulos sendo este cap´ıtulo, referente à introdu¸cão, um deles. O 2º cap´ıtulo descreve a estrutura do robô que serve de base a este trabalho de disserta¸cão, a plataforma ROTA, sendo nesse cap´ıtulo descritas as caracter´ısticas do robô, o ambiente da competi¸cão no qual participa e o trabalho já realizado neste projeto. O 3º e o 4º cap´ıtulos referem o trabalho já realizado nas áreas relativas à simula¸cão em robòtica e à navega¸cão em ve´ıculos autonómos respetivamente. No cap´ıtulo 3 referimos brevemente os ambientes de simula¸cão já existentes e justificamos o destaque dado ao Gazebo. Ainda neste cap´ıtulo é feita a descri¸cão de duas linguagens pass´ıveis de ser usadas na descri¸cão dos modelos no simulador Gazebo. No 4º cap´ıtulo apresentamos os conceitos e algoritmos já usados para identificar as linhas delimitadoras da faixa em imagens, quais as técnicas utilizadas no seguimento da faixa de rodagem e os conceitos por detrás de um planeador que tem em conta as caracter´ısticas de um ve´ıculo automóvel.

Os cap´ıtulos 5, 6 e 7 cap´ıtulo referem-se ao trabalho realizado no âmbito desta disserta¸cão, estando incorporados em cada um deles os resultados obtidos. No cap´ıtulo 5 referimos quais os objetos que pretend´ıamos simular, quais foram as ferramentas utilizadas para o efeito e descrevemos o processo de modela¸cão para cada um destes objetos. O cap´ıtulo 6 apresenta dois tipos de localiza¸cão e o algoritmo desenvolvido para efetuar a localiza¸cão do robô na faixa de rodagem. O cap´ıtulo 7 descreve a integra¸cão da abordagem relativa à localiza¸cão local com o sistema de localiza¸cão global já desenvolvido no âmbito do projeto ROTA.

O cap´ıtulo 8 contem as conclusões que podem ser retiradas do trabalho desenvolvido nesta disserta¸cão. São apresentadas algumas ideias relativas ao trabalho que poderá vir a ser desenvolvido, que tem como propósito eliminar algumas limita¸cões do algoritmo de navega¸cão presente no cap´ıtulo 7. Estas ideias tem como base a experiência ganha na realiza¸cão desta disserta¸cão, bem como os conceitos que se encontram descritos no cap´ıtulo 2.

(23)

Cap´ıtulo 2

Projeto ROTA

O IRIS Lab possui uma linha de atividade relacionada com a condu¸cão autónoma, dentro da qual se enquadra o projeto ROTA. No contexto deste projeto, desenvolveu um ve´ıculo robótico, de dimensões reduzidas, capaz de navegar autonomamente em ambientes indoor. O software de controlo de alto n´ıvel corre num computador portátil, integrado no veiculo, e está desenvolvido em cima do Robot Operating System (ROS), middleware adequado ao desen-volvimento de aplica¸cões robóticas. O ve´ıculo participa anualmente nas provas de condu¸cão autónoma do Festival Nacional de Robótica.

Neste cap´ıtulo, descreve-se a plataforma robótica ROTA, faz-se uma breve apresenta¸cão do middleware ROS, descreve-se a prova de condu¸cão autónoma do Festival Nacional de Robótica e apresenta-se a estrutura geral do software de controlo de alto n´ıvel, real¸cando-se, neste último ponto, onde é que o trabalho realizado se enquadra.

2.1 Plataforma ROTA

O ve´ıculo ROTA, apresentado na figura 2.1, é uma plataforma robótica com uma base retangular de 60 cm de comprimento por 45 cm de largura. O seu sistema de locomo¸cão assenta numa estrutura em triciclo, fornecendo um controlo de dire¸cão do tipo Ackermann. O órgão sensorial principal é um dispositivo RGB-D (Kinect), montado num suporte com dois

(24)

Figura 2.2: Dire¸c˜ao Ackermann

graus de liberdade, permitindo controlo de pan e tilt. O software de controlo está estruturado em dois n´ıveis. Ao n´ıvel mais próximo de hardware, um conjunto de módulos, baseados em microcontroladores, permitem a manipula¸cão direta dos sensores e atuadores. Estes módulos estão interligados usando uma infraestrutura Controller Area Network (CAN), que comunica com um portátil, onde o software de alto n´ıvel corre.

2.1.1 Locomo¸c˜ao Ackermann

A dire¸cão Ackermann, apresentada na figura 2.2, é um disposi¸cão geométrica espec´ıfica das duas rodas dianteiras de um ve´ıculo, desenvolvida para resolver o problema da roda interior e exterior percorrerem c´ırculos de raio diferente quando o ve´ıculo se encontra a curvar.

Nesta disposi¸cão o raio da curvatura do ve´ıculo em rela¸cão ao Instantaneous Center of Rotation (ICR) determina qual a posi¸cão angular da roda central virtual (θc). Como o robô

ROTA possui duas rodas diretoras, o ângulo destas rodas são calculadas a partir do ângulo da roda central. Na figura 2.2, o ângulo da roda interior corresponde a θi, enquanto que o

ˆ

angulo da roda exterior ´e representado por θo.

Este tipo de dire¸cão é usada para prevenir a derrapagem das rodas e é concebido tendo como base um sistema de três rodas, uma roda motora atrás e duas rodas diretoras na dianteira.

O controlo da locomo¸cão é feito através de um motor, que comanda a roda motriz traseira, e de um servo, que determina a posi¸cão angular das rodas dianteiras. O motor da roda traseira está equipado com um encoder, que permite saber aproximadamente qual a distância percorrida por aquela roda, sendo que o servo da dire¸cão possui feedback da posi¸cão angular das rodas dianteiras. Da conjuga¸cão de ambos, obtêm-se dados odométricos, permitindo a implementa¸cão de um mecanismo de dead reckoning.

(25)

2.1.2 Perce¸c˜ao

O sensor principal deste robô é uma câmara RGB-D (Kinect ), que constitui o sistema de visão. Esta câmara está montada num suporte pan&tilt, constru´ıdo utilizando dois servos independentes, conferindo à câmara dois graus de liberdade.

Os ângulos relativos aos movimentos de pan e de tilt podem variar ao longo do tempo, dentro de gamas bem definidas. A gama do movimento permitido pelo movimento de pan está no intervalo [−180, 180] graus, enquanto que a do movimento de tilt se encontra compreendida entre [−90, 90] graus. As várias posturas que a câmara pode ter, torna poss´ıvel a captura de imagens em várias perspetivas, sendo poss´ıvel ao robô extrair informa¸cão útil sobre o ambiente em seu redor. Esta informa¸cão é posteriormente usada para a realiza¸cão de uma navega¸cão adequada.

A câmara é, portanto, usada para finalidades diferentes. Posta a apontar para baixo, permite observar a estrada e os elementos nela presentes, nomeadamente as linhas delimita-doras das faixas de rodagem, a passadeira e obstáculos. Posta a apontar para cima, permite observar sinalética que se encontre acima da posi¸cão do ve´ıculo, sejam estes sinais verticais ou semáforos. O robô tem também um Laser Range Finder (LRF), capaz de recolher informa¸cão sobre o ambiente que o rodeia. Este sensor pode ser usado na dete¸cão de obstáculos, podendo esta informa¸cão ser fundida com a que vem da câmara para se obter uma maior certeza sobre a presen¸ca de um objeto na frente do robô.

2.1.3 Controlo de baixo n´ıvel

A camada de baixo n´ıvel gere os dispositivos de hardware (motores, servos, sensores), sendo constitu´ıda por vários micro-controladores interligados entre si. E constitu´ıda por´ vários módulos baseados nestes micro-controladores, que se encontram interligados através de uma CAN, como se encontra apresentado na Figura 2.3.

Um destes módulos, designado gateway, é responsável por interligar esta camada à camada de controlo de alto n´ıvel, que corre num sistema computacional (computador portátil), incor-porado no ve´ıculo. A interliga¸cão é feita através de uma liga¸cão série, usando uma conexão Universal Serial Bus (USB).

O gateway reúne todas as informa¸cões proveniente dos vários módulos ligados à CAN, enviando-as para o sistema computacional que corre a camada de alto n´ıvel. O processo também acontece na dire¸cão contrária, ou seja o gateway recebe toda a informa¸cão relacio-nada com a camada de baixo n´ıvel, enviada pelo sistema computacional, e envia-as para os respetivos módulos da CAN.

O nó do motor é o módulo responsável por abstrair os detalhes técnicos do motor e dos encoders. Este interliga estes dois componentes e a camada de alto n´ıvel. Recebe, através da rede CAN ao qual se encontra ligado a ordem de atua¸cão destinada ao motor, que inclui a velocidade que se pretende aplicar à roda traseira do ve´ıculo, utilizando esta velocidade como valor alvo a atingir pelo controlador PI [18]. Este controlador usa a informa¸cão proveniente do encoder ligado à roda motora como valor de feedback. O valor da velocidade da roda, medida através deste sensor é também enviado para a camada de alto n´ıvel. Juntamente com

(26)

Figura 2.3: Camada de perce¸c˜ao e atua¸c˜ao de baixo n´ıvel

o feedback fornecido pelo servo das rodas dianteiras do ve´ıculo, é poss´ıvel o cálculo de dados odométricos, que são posteriormente utilizados pelo sistema de dead reckoning.

O pan, tilt e a dire¸cão são geridos pelo mesmo módulo devido ao modelo dos servos utilizados. Os servos utilizados são os AX-12 da Dynamixel. Estes permitem a liga¸cão entre si, podendo estes ser controlados por um único módulo. As mensagens são enviadas para todos os servos através da mesma liga¸cão, e cada uma destas inclui a identifica¸cão do servo destinatário.

A plataforma ROTA usa como fonte de alimenta¸cão duas baterias LiPO, sendo que uma delas é usada para alimentar o motor da roda traseira e a outra é utilizada para alimentar os mecanismos de controlo da direçcão e da câmara, sendo o LRF alimentado por USB. Se estas baterias descarregarem completamente, estas ficariam inutilizáveis pois não seria prático voltar a carregá-las. Para que tal não aconte¸ca, são utilizados dois monitores que emitem um alerta sonoro no caso de uma das células de qualquer uma destas baterias atingir um valor demasiado baixo em termos de voltagem.

O monitor da bateria é responsável por ler o estado das células das baterias, verificando se estas não atingem uma voltagem inferior a 3.2 volts. No caso do monitor emitir um aviso sonoro, isso significa que a voltagem de uma das células se encontra abaixo dos 3.2 volts, sendo necessário o carregamento da bateria respetiva de modo a que não fique inutilizável, caso se pretenda voltar a utilizá-la.

2.2 Robot Operating System

O Robot Operating System (ROS) [20] é uma infraestrutura open-source de apoio ao desen-volvimento de aplica¸cões robóticas, que se manifesta em três vertentes. Fornece uma camada de comunica¸cão estruturada em cima do sistema operativo, seguindo o paradigma produtor-consumidor, que visa simplificar a tarefa de criar comportamentos complexos e robustos para aplica¸cões robóticas. Disponibiliza um vasto leque de bibliotecas de software com solu¸cões

(27)

para problemas frequentes em aplica¸cões robóticas. Finalmente, disponibiliza ferramentas de apoio à visualiza¸cão e introspe¸cão do sistema.

2.2.1 Infraestrutura base

A infraestrutura de comunica¸cão assenta nos conceitos de nó, mensagem e tópico. Os nós são programas executáveis que usam a infraestrutura para comunicar entre si. A comunica¸cão em si é concretizada pelo envio e rece¸cão de mensagens, sendo os tópicos usados como rece-pientes para as armazenar. Não há liga¸cão direta entre um nó que envia uma mensagem e outro que a recebe: o primeiro limita-se a enviá-la para um tópico e o outro vai lá lê-la. Uma mensagem pode ser vista como uma instância de um tipo de dados espec´ıfico.

Cada tópico está associado a um e um só tipo de dados e tem uma identifica¸cão única. Um nó, antes de poder enviar mensagens para um tópico, tem de se registar como produtor de mensagens para esse tópico. O pedido é feito junto de um nó especial, designado ROS master, que funciona como um servi¸co de diretório. Do lado oposto, um nó, antes de poder receber mensagens de um tópico, tem de se registar como consumidor de mensagens desse tópico. O registo corresponde à indica¸cão de uma fun¸cão (callback ) que será usada para processar as mensagens chegadas ao tópico.

Como referido, as mensagens estão associadas a tipos de dados espec´ıficos. A estrutura base do ROS já fornece um leque vasto de mensagens. No entanto, é poss´ıvel a defini¸cão de novas mensagens, usando tipos primitivos e mensagens já existentes. A defini¸cão é feita numa meta-linguagem própria, existindo possibilidade de compila¸cão dessa defini¸cão para linguagens de programa¸cão diferentes. É poss´ıvel, desta maneira, a troca de mensagens entre nós desenvolvidos usando linguagens diferentes.

2.2.2 Servi¸cos e Parˆametros

Além da troca de mensagens através dos tópicos, existe outras formas de intera¸cão entre os nós: servi¸cos e parâmetros.

Servi¸cos são tarefas espec´ıficas executadas por nós dedicados apenas a isso, cuja execu¸cão é realizada a pedido de outros nós. Esta forma de intera¸cão segue o paradigma cliente servidor, onde é utilizado um par de mensagens: uma destinada ao pedido de execu¸cão do servi¸co e outra que contém a resposta do servidor ao cliente. Os tipos de mensagens usadas nos servi¸cos são descritos utilizando ficheiros espec´ıficos, pois estes servi¸cos têm pelo menos um tipo de dados associado. Este tipo de ficheiros está dividido em duas partes: a primeira é usada para definir o tipo de mensagem usada no pedido, e a segunda o tipo usado na resposta. Na defini¸cão de um servi¸co é poss´ıvel a utiliza¸cão de qualquer tipo de mensagem já existente no ecossistema ROS, ou criada pelo próprio utilizador. O ROS master funciona como um gestor de parâmetros globais, que funciona como um dicionário partilhado entre os vários nós de uma aplica¸cão. Através de uma API é poss´ıvel a um nó realizar várias opera¸cões sobre este dicionário, como por exemplo obter e modificar o conteúdo de um parâmetro, ou mesmo apagar um determinado parâmetro do dicionário. O pacote ROS dynamic reconfigure fornece um meio de alterar os parâmetros relativos a um nó a qualquer momento, sem ser

(28)

Orador _Ouvinte Tópico ROS Master Mensagem publicada Mensagem recebida parâmetro robot description

Descrição do robô

Serviço

Pedido Resposta

Figura 2.4: Processo de publica¸cão e subscri¸cão de um tópico, obten¸cão do conteúdo de um parâmetro e utiliza¸cão de um servi¸co

necessário o seu reinicio. Caso se pretenda usar as funcionalidades deste pacote, é preciso apenas desenvolver uma callback, que é despoletada sempre que exista uma altera¸cão nos parâmetros relativos a um determinado nó.

Na Figura 2.4 encontram-se representados as três formas diferentes de intera¸cão. A co-munica¸cão entre o nó Orador e o ROS Master é efetuado através da application programming interface (API) desenhada para a realiza¸cão de opera¸cões sobre parâmetros. Entre o nó Ora-dor e ouvinte a transmissão de informa¸cão é feita através de um tópico. Por fim, a troca de informa¸cão entre o nó Ouvinte e Servi¸co é realizada sempre que existe uma solicita¸cão por parte do nó ouvinte, ao qual é enviado uma resposta após o pedido ser processado.

2.2.3 Bibliotecas de suporte

Como já foi referido, o ecossistema ROS fornece uma vasta cole¸cão de bibliotecas, sob a forma de pacotes, que implementam fun¸cões úteis para a implementa¸cão de aplica¸cões em robótica, dando liberdade ao utilizador de utilizar apenas aqueles que precisa. No nosso projeto as bibliotecas mais usadas foram as tf, amcl, libfreenect, hokuyo node e joy.

A tf mantém uma árvore de transforma¸cões entre diversos referenciais. Permite facilmente obter coordenadas num referencial, mesmo quando a informa¸cão tenha sido publicada num outro referencial.

A libfreenect é uma biblioteca que inclui os drivers da primeira versão da câmara Kinect, dando a possibilidade ao utilizador de realizar a captura de v´ıdeo a cores, bem como a captura de uma imagem de profundidade, fornecendo também a imagem registada.

O hokuyo node interage com um laser range finder Hokuyo, disponibilizando os dados sensoriais por ele produzidos.

(29)

suportado pelo Linux. Este nó abstrai o funcionamento destes dispositivos e publica num tópico o valor do movimento dos eixos e o estado dos vários botões (pressionado ou não) de um comando espec´ıfico. Através deste driver foi poss´ıvel comandar o robô utilizando um comando da playstation 3 ou da xbox 360.

O AMCL implementa um algoritmo de localiza¸cão global para robôs com uma base móvel de dire¸cão holonómica, num mapa bidimensional, baseada na localiza¸cão adaptativa de Monte Carlo [8].

2.2.4 Ferramentas de apoio ao desenvolvimento

O ecossistema ROS possui também ferramentas de visualiza¸cão e introspe¸cão do sis-tema, úteis no desenvolvimento de software. Dentro destas ferramentas podemos destacar o rqt graph, o rviz e o rosbag.

O rqt graph é uma ferramenta gráfica que permite visualizar a arquitetura de uma aplica¸cão, em termos dos nós e dos tópicos envolvidos e da interliga¸cão entre eles. Permite, por exemplo, saber que tópicos um dado nó subscreve e publica.

O rviz é uma ferramenta de visualiza¸cão 3D, que possui várias funcionalidades. Estas permitem, por exemplo, a visualiza¸cão de um robô modelado em URDF, de dados provenientes dos sensores, da posi¸cão estimada pelo robô e da posi¸cão dos vários referenciais usados pela biblioteca tf, entre outras.

O rosbag permite ao utilizador gravar em ficheiros bag as mensagens que se encontram a ser publicadas nos diversos tópicos. É também capaz de reproduzir a informa¸cão guardada num ficheiro bag a qualquer momento.

2.3 Prova de Condu¸

c˜

ao Aut´

onoma do Festival Nacional de

Rob´

otica

O Festival Nacional de Robótica é um encontro cient´ıfico, organizado pela sociedade por-tuguesa de robótica, com competi¸cões de robótica que tem lugar em Portugal, realizando-se anualmente, desde a primeira edi¸cão em 2001, em várias localidades ao longo do pa´ıs. Este festival tem como objetivo reunir as pessoas e entidades interessadas nas diversas áreas abrangidas pela robótica estimulando-as a participar através de várias competi¸cões, englo-bando também um encontro cient´ıfico. Entre as diversas competi¸cões existentes neste festival referimo-nos neste documento à prova de condu¸cão autónoma, pois o trabalho realizado no contexto desta disserta¸cão encontra-se relacionado com esta prova em espec´ıfico.

A prova de condu¸cão autónoma tem como objetivo o desenvolvimento de ve´ıculos que consigam conduzir autonomamente numa pista com semelhan¸cas marcantes a uma estrada convencional. A pista poderá ter uma ou mais faixas de rodagem, delimitadas por linhas brancas, e possuir vários elementos de sinaliza¸cão, tais como uma passadeira, semáforos e sinais verticais. Além disso, a pista possui zonas de estacionamento e pode possuir uma seçcão em túnel, uma seçcão em obras e obstáculos obstruindo uma das faixas de rodagem.

(30)

Figura 2.5: Pista da prova de condu¸cão autónoma usada na edi¸cão de 2015 do Festival Nacional de Robótica

Figura 2.6: Sinais de trânsito mostrados nos painéis sinaléticos colocados sobre a passadeira

2.3.1 Ambiente de competi¸c˜ao

A figura 2.5 mostra a pista usada na prova de condu¸cão autónoma na edi¸cão de 2015 do Festival Nacional de Robótica. Corresponde a um circuito fechado, com a forma de um B e com duas faixas de rodagem durante todo o seu percurso. A meio possu´ıa uma passadeira, sobre a qual existia um pórtico que suportava dois painéis sinaléticos (TFTs), que funcionavam como semáforos. Possu´ıa duas zonas de estacionamento, uma paralela à uma das faixas de rodagem e a outra em espinha, esta com os lugares de estacionamento identificados com a letra P. Na imagem, há uma seçcão da pista em túnel, um sinal vertical e um obstáculo (um paralelep´ıpedo verde) a obstruir uma das faixas de rodagem.

O painel sinalético sobre o pórtico, a uma altura de 87 cm, apresenta os sinais (ver figura 2.6) que o ve´ıculo deve observar. Quatro desses sinais, designados STOP, AHEAD, LEFT e RIGHT, controlam o movimento do ve´ıculo, obrigando-o a parar na passadeira, ir em frente, virar à esquerda ou virar à direita. O sinal em xadrez, designado CHESS, indica ao ve´ıculo o termo da prova e o sinal com um P, designado PARK, indica que o ve´ıculo vai iniciar uma manobra de estacionamento.

Os sinais verticais (ver figura 2.7) podem aparecer ao longo da pista, do lado direito de uma faixa de rodagem, e apresentam padrões que têm de ser identificados pelo ve´ıculo. São suportados por um mastro e colocados a uma altura fixa, igual àquela a que estão os painéis sinaléticos no pórtico. Há 12 sinais, distribu´ıdos por 3 categorias. Dentro de cada categoria os sinais apresentam a mesma forma, mudando apenas o padrão.

(31)

Figura 2.7: Sinais de trˆansito verticais colocados ao longo da pista

2.3.2 Competi¸c˜ao

As regras da competi¸cão da prova de condu¸cão autónoma tem mudado ao longo das várias edi¸cões do Festival Nacional de Robótica, apresentando nas edi¸cões de 2015 e 2016 a forma de desafios. Houve 4 tipos de desafios:

1. desafios de condu¸c˜ao (tipo D)

2. desafios de estacionamento em faixa paralela `a faixa de rodagem (tipo P) 3. desafios de estacionamento em espinha (tipo B)

4. desafios de identifica¸c˜ao de sinais verticais (V)

Houve 4 desafios de condu¸cão, designados D1 a D4. Em todos os desafios, o ve´ıculo iniciava a sua presta¸cão imediatamente antes da passadeira, de forma a que a projeçcão vertical da sua frente ficasse por cima da linha da passadeira perpendicular à faixa de rodagem. No desafio D1, o ve´ıculo tinha de dar duas voltas completas à pista e imobilizar-se na passadeira, numa posi¸cão correspondente à da partida. O in´ıcio da prova era dado pelo sinal presente no painel sinalético ao passar de STOP para AHEAD. No desafio D2, o ve´ıculo, à passagem pela passadeira, tinha de respeitar o sinal presente no painel. Este sinal, podia obrigá-lo a imobilizar-se, seguir em frente, virar à esquerda ou virar à direita. O in´ıcio da prova era dado pela passagem do sinal de STOP para AHEAD ou LEFT. O desafio D3 era semelhante ao D2, com a dificuldade adicional de que parte da pista tinha um túnel e iriam aparecer obstáculos a obstruir a faixa de rodagem. Finalmente, no desafio D4, era adicionada uma zona em obras, caso em que havia um desvio delimitado por cones.

Houve 3 tipos de estacionamento na faixa paralela à faixa de rodagem, com dificuldades crescentes, designados P1 a P3. Em P1, a faixa de estacionamento estava completamente livre; em P2, possui um obstáculo, à frente do qual o ve´ıculo deveria estacionar; em P3, havia dois obstáculos, obrigando o ve´ıculo a estacionar entre eles. O in´ıcio das provas era dado pelo sinal presente no painel sinalético ao passar de STOP para PARK.

(32)

Houve 2 tipos de estacionamento em espinha (bay parking), designados B1 e B2. A diferen¸ca entre ambos era que em B2 um dos lugares estava ocupado por um obstáculo. Estes desafios apenas podiam ser considerados após a conclusão de um desafio de condu¸cão. O in´ıcio das provas era dado pelo sinal presente no painel sinalético ao passar de STOP para PARK.

Houve um único desafio de identifica¸cão de sinais verticais, designado V1. Consistia em identificar e classificar os sinais verticais de trânsito colocados ao longo da pista. Eram colocados seis sinais (dois de cada categoria) de entre os doze apresentados na figura 2.7. O in´ıcio da prova era dado pelo sinal presente no painel sinalético ao passar de STOP para AHEAD, dispondo o ve´ıculo de duas voltas à pista para ultrapassar o desafio.

Em geral, a competi¸cão estava estruturada em 4 mangas, cada uma com a dura¸cão de 10 minutos por cada equipa participante. Em cada manga, havia um conjunto de desafios que o ve´ıculo poderia tentar ultrapassar. Os desafios podiam ser atacados em mais do que uma manga, mas o número máximo de tentativas por desafio estava limitado a três.

2.4 Software de Controlo de Alto N´ıvel

Na figura 2.8 apresenta-se um diagrama geral do software de controlo de alto n´ıvel da plataforma ROTA. Os blocos retangulares representam dados (conjuntos de t´opicos ROS) ou dispositivos, enquanto que os ovais representam blocos de processamento.

Os dispositivos são representados pelas 3 caixas retangulares com delimita¸cão dupla, cor-respondendo ao LRF, ao dispositivo RGB-D (Kinect) e à Low-Level Infrastructure (LLI). Esta ´

ultima representa, na realidade, todos os sensores e atuadores manipuladores pela camada de controlo de baixo n´ıvel (ver sec¸c˜ao 2.1).

Tal como referido nessa seçcão, a comunica¸cão entre a camada de baixo n´ıvel e a de alto n´ıvel é feita através de uma liga¸cão série, usando um cabo USB. O módulo Hardware Abstration Layer (HAL) é responsável por esta comunica¸cão e por criar uma abstra¸cão na forma como o alto n´ıvel interage com o baixo n´ıvel. Por exemplo, os dados de odometria relativos à roda motriz e a posi¸cão do servo da dire¸cão são conjugados, sendo publicados os valores de dead reckoning. A informa¸cão relativa à posi¸cão pan e tilt da câmara Kinect é também publicada, sendo obtida através dos encoders presentes nos servos de suporte do dispositivo RGB-D.

O módulo ImageAcq é responsável pela aquisi¸cão das imagens do dispositivo RGB-D (uma Kinect atualmente) e pela publica¸cão dessas imagens ou de imagens delas derivadas. Essas imagens serão processadas por dois módulos diferentes. O módulo RoadImageProc trabalha as imagens com o objetivo de extrair informa¸cão que ajudem na localiza¸cão do ve´ıculo. Est´ a-se a falar esa-sencialmente da identifica¸cão das linhas delimitadoras das faixas de rodagem e da passadeira. A informa¸cão extra´ıda é publicada para posterior utiliza¸cão pelo módulo de localiza¸cão. O módulo SignImageProc é responsável por identificar os sinais afixados nos painéis sinaléticos ou nos sinais verticais. Este módulo funciona como um prestador de servi¸cos ROS, no sentido em que apenas efetua o processamento em consequência de um pedido.

(33)

LRF Kinect LLI Aquisição ImageAcq Imagens SignImageProc Decision Ordens de atuação Localizer Características da estrada HAL

Pan & tilt e

dead reckoning

Posição e Orientação RoadImageProc

(34)

O módulo Localizer é responsável por determinar uma estimativa adequada da loca-liza¸cão e orienta¸cão (postura) do ve´ıculo, podendo usar para isso a estimativa anterior, os dados de dead reckoning e a informa¸cão sobre a estrada extra´ıda das imagens. A estimativa da postura é publicada no tópico Pose.

O m´odulo Decision representa a entidade respons´avel por resolver os desafios colocados ao ve´ıculo.

(35)

Cap´ıtulo 3

Simula¸

c˜

ao

A simula¸cão é uma técnica em que se concebem modelos de um sistema dinâmico. Possui uma elevada importância em várias áreas de negócio, como por exemplo nas indústrias de pilotagem comercial, automa¸cão, jogos de v´ıdeo, automóvel, entre outras. Devido à diversi-dade de aplica¸cões que esta área pode ter, podem existir simula¸cões com vários objetivos. Um desses objetivos pode ser a utiliza¸cão de um ambiente de simula¸cão que permite ao utilizador verificar qual o comportamento adotado por um determinado modelo no mundo virtual, sendo desejável que este seja semelhante ao do sistema f´ısico real.

3.1 Simula¸

c˜

ao em rob´

otica

A simula¸cão é uma ferramenta essencial para todos os que trabalham na área da robótica. Os simuladores são aplica¸cões que fornecem a possibilidade de desenvolver modelos virtuais de sistemas f´ısicos e todo o espa¸co envolvente, permitindo reproduzir acontecimentos reais num ambiente virtual.

Desta forma é poss´ıvel testar ideias, teorias e software sem os custos de desenvolver uma entidade f´ısica, que muitas vezes envolve gastar mais recursos do que desenvolver um mo-delo simulado de um robô e um ambiente de simula¸cão. Esta ferramenta é também útil na prototipagem de um robô, sendo que é poss´ıvel perceber antes da conce¸cão f´ısica do mesmo quais as caracter´ısticas f´ısicas mais adequadas para o robô real, de maneira a que este consiga executar de forma mais eficiente uma determinada tarefa.

Para verificar qual o comportamento de um robô real aquando da execu¸cão de um al-goritmo espec´ıfico é necessário ter o robô operacional, programá-lo e testar os algoritmos desenvolvidos. Este processo de teste pode repetir-se várias vezes dependendo dos resultados obtidos, sendo que em cada itera¸cão se afina quer o algoritmo em si, quer os parâmetros usados por este. Este processo levado a cabo no robô real envolve desgaste das componentes f´ısicas de todo o ve´ıculo como exemplo baterias, servos, rodas, entre outros, que pode levar à inutiliza¸cão de alguns destes componentes. Em cenários reais existem vários riscos associados `

a estrutura f´ısica do robô, como por exemplo, falha de hardware ou a colisão deste contra outros objetos f´ısicos. Em compara¸cão com o mundo real, o ambiente virtual traz muitas vantagens sendo que podemos destacar as seguintes:

(36)

1. Testar os algoritmos desenvolvidos sem os riscos associados ao hardware;

2. Modificar o estado do mundo mais rapidamente, podendo-se testar o comportamento do robô em várias situa¸cões;

3. Manipular o tempo da simula¸c˜ao de modo a se poder executar uma melhor depura¸c˜ao do nosso programa, de modo a identificar-se poss´ıveis erros;

4. Executar v´arias vezes o mesmo algoritmo de uma vez s´o e verificar qual a taxa de sucesso.

Para além das vantagens já mencionadas, é também poss´ıvel verificar que existe uma vantagem clara no caso de teste em ambiente simulado em rela¸cão a um cenário real quando o robô tem de come¸car sempre numa posi¸cão espec´ıfica, como acontece na prova de condu¸cão autónoma. Isto porque no mundo real o transporte do robô pode requerer uma quantidade considerável de esfor¸co e tempo, enquanto que no mundo virtual esta opera¸cão pode ser feita instantaneamente.

Embora um robô virtual traga muitas vantagens em rela¸cão à entidade f´ısica do mesmo, existem fatores que influenciam o comportamento do robô apenas percet´ıveis no mundo real. Alguns desses fatores são o comportamento f´ısico do mesmo e o reduzido número de cenários simulados em compara¸cão com aqueles encontrados no mundo real. O primeiro fator pode ser minimizado por uma modela¸cão f´ısica dos modelos mais cuidada, enquanto que o segundo requereria uma grande quantidade de cenários tendo estes de ser foto-realistas, sendo que este número de cenários só se podem encontrar atualmente em jogos de v´ıdeo comerciais.

Os simuladores podem também ser usados para criar um grande conjunto de dados com imagens e informa¸cões relativas à classifica¸cão de objetos nessa mesma imagem ao n´ıvel do pixel. Usando v´ıdeo jogos comerciais com grandes espa¸cos abertos é poss´ıvel criar este grande conjunto de dados, devido a poder-se capturar os comandos de rendering: geometria, shading e de texturiza¸cão que definem objetos, sendo que estes comandos são iguais para classes de objetos iguais e que permanecem válidas ao longo de todo o jogo [21].

No resto do cap´ıtulo apresenta-se um breve estudo de alguns ambiente de simula¸cão para robótica. É feita uma cobertura mais profunda ao Gazebo, uma vez que foi o ambiente usado no âmbito do trabalho desta disserta¸cão, apresentando-se as razões subjacentes à sua escolha.

3.2 Ambientes de simula¸

c˜

ao

Os simuladores concebidos para realizar a simula¸cão na área de robótica permitem mode-lar os robôs e o espa¸co envolvente, conferir-lhes um comportamento f´ısico adequado, produzir informa¸cão a partir de sensores, visualizar o mundo virtual onde o robô opera e os dados pro-duzidos pelos sensores deste. Estes simuladores incorporam normalmente duas componentes, correspondentes à simula¸cão f´ısica e gráfica.

A componente f´ısica da simula¸cão permite a modela¸cão de entidades f´ısicas reais, sendo responsável por fornecer comportamentos plaus´ıveis quando as várias entidades dentro do mesmo ambiente de simula¸cão interagem entre si. Para simular esta componente os simula-dores utilizam geralmente um motor de f´ısica, que fornece aos modelos uma dinâmica realista

(37)

em tempo real.

Na produ¸cão de informa¸cão por parte de sensores virtuais os simuladores robóticos são auxiliados pela utiliza¸cão de um motor gráfico como o Object-oriented Graphics Rendering Engine (OGRE) ou uma API como OpenGL. A utiliza¸cão destas bibliotecas gráfica tem dois objetivos, sendo uma delas a simula¸cão de sensores.

O segundo objetivo da utiliza¸cão de uma biblioteca gráfica, que incorpora o motor de rendering, é permitir ao utilizador visualizar qual o estado do mundo simulado através da graphical user interface (GUI) do simulador, podendo este interagir com todos os modelos que se encontram dentro do ambiente de simula¸cão.

Para além de permitirem a visualiza¸cão do robô e dos restantes elementos no mundo, os simuladores permitem também ver uma representa¸cão gráfica dos dados capturados pelos sensores.

No campo da simula¸cão robótica existem várias plataformas de simula¸cão, algumas delas espec´ıficas para um determinado fim enquanto outras são completamente genéricas. As que são espec´ıficas apenas simulam robôs em ambientes espec´ıficos, como por exemplo bra¸cos robóticos em linhas de montagem. As plataformas genéricas são aquelas que permitem a simula¸cão de qualquer tipo de robô, independentemente do seu propósito. Entre as diversas plataformas podemos destacar as seguintes:

1. V-REP 2. SimTwo 3. Webots 4. RobotStudio 5. Gazebo

Para além destes, existem outros simuladores que não se encontram enumeramos devido a alguns terem sido descontinuados e outros não terem atualiza¸cões regulares. Um dos si-muladores descontinuados foi o Microsoft robotics developer studio devido ao encerramento da seçcão de robótica desta empresa1, encontrando-se ainda o software dispon´ıvel para os utilizadores que pretendam utilizá-lo. Outros simuladores como por exemplo o simSpark ainda são utilizados em competi¸cões como o RoboCup na liga de simula¸cão, embora a última atualiza¸cão deste simulador tenha sido efetuada em 2010.

V-REP

O V-REP é um simulador 3D [22] open-source de âmbito geral com um ambiente de desenvolvimento incorporado, multi-plataforma (Windows/Linux /Mac OS X), criado pela Coppelia Robotics. Permite a modela¸cão de um sistema robótico completo ou apenas com-ponentes deste, tal como sensores, atuadores, entre outros comcom-ponentes.

Assenta numa arquitetura de controlo distribu´ıda em que cada modelo pode ser controlado de diversas formas, tornado-se num simulador vers´atil e flex´ıvel. Este simulador permite

(38)

também que os controladores sejam escritos em várias linguagens como C/C++, Python, Java, Lua, Matlab, Octave ou Urbi sendo também poss´ıvel o controlo através de um nó ROS.

´

E usado para simula¸cões de automa¸cão em fábricas, prototipagem rápida, simula¸cões com objetivos educacionais, entre muitas outras aplica¸cões. É um dos simuladores open-source que mais motores de f´ısica suporta, incluindo funcionalidade como dete¸cão de colisões, gera¸cão de dados de diversos tipos de sensores, grava¸cão e visualiza¸cão de informa¸cão, entre outros.

SimTwo

O SimTwo ´e um simulador 3D realista e gratuito, que suporta diferentes tipos de robˆos [5], desenhado para ser executado na plataforma Windows.

O controlo dos robôs dentro deste ambiente de simula¸cão pode ser feita utilizando RemOb-ject Pascal Script2. Inclu´ı um sistema de scripting que pode ser usado para controlar o estado dos robôs simulados, podendo alterar-se a sua posi¸cão, o estado dos motores, etc. Permite também a existências de múltiplos robôs no mesmo cenário, que podem ser equipados com sensores e atuadores. A descri¸cão do mundo encontra-se num ficheiro XML que é carregada quando a simula¸cão come¸ca.

Este simulador é utilizado na simula¸cão da prova Robot@Factory do Festival Nacional de Robótica.

Webots

Webots é um software multi-plataforma (Windows / Linux / Mac OS X) criado pela Cy-berbotics, que tem como público alvo investigadores e professores na área da robótica. Fornece um ambiente para prototipagem rápida para robôs simulando também o seu comportamento f´ısico.

Este simulador agrega um ambiente de desenvolvimento usado para modelar, programar e simular robôs móveis acoplado a uma interface gráfica 3D, onde são mostrados visualmente os modelos desenvolvidos pelo utilizador ou modelos já inclu´ıdos no próprio simulador.

´

E poss´ıvel a constru¸cão de simula¸cões dinâmicas do ponto de vista f´ısico com vários robôs possuindo várias interfaces incluindo matlab e ROS. Os robôs neste simulador podem ser controlados com código escrito em C/C++, Java, Python ou Matlab.

Inclui uma vasta gama de sensores que podem ser usados para equipar os modelos, podendo-se afinar os parâmetros relacionados com estes como por exemplo o ru´ıdo. Alguns dos sensores são por exemplo, sensores de distância, bumpers, câmaras, laser range finders, entre muitos outros. Existem também alguns atuadores como por exemplo LEDs, servos e grippers. Os robôs e o mundo encontram-se definidos num ficheiro world.

RobotStudio

RobotStudio é um software de simula¸cão criado pelo ABB com o objetivo de simular robôs industriais. Fornece uma lista de componentes que podem ser usados para modelar o robô e

(39)

os seus sensores e atuadores. Para modelar o ambiente envolvente este simulador permite a modela¸cão de objetos t´ıpicos numa fábrica como por exemplo passadeira rolantes, elevadores para bra¸cos robóticos, entre outros. Possui também mecanismos para dete¸cão de colisões e a capacidade de verificar se todos os objetos na simula¸cão são alcan¸cáveis pelo bra¸co robótico.

Gazebo

Gazebo é um simulador multi robô 3D open-source [11] desenvolvido em C++, concebido em primeiro lugar para sistemas operativos baseados em Linux, embora tenha sido efetuado um porte para Windows a partir da versão 5 deste simulador. Mantido atualmente pela Open Source Robotics Foundation (OSRF), permite desenvolver modelos de robôs e modelar os ambientes que os robôs podem encontrar, tendo a capacidade de modelar sistemas com diversos sensores, atuadores e outros objetos.

Neste simulador os objetos e o ambiente envolvente são descritos num ficheiro .world, que incluem os modelos, fatores como a ilumina¸cão e caracter´ısticas relacionadas com a f´ısica. Todos estes elementos podem ser descritos por duas linguagens de marca¸cão distintas. Um poss´ıvel cenário de simula¸cão, onde é poss´ıvel verificar que o robô tem pelo menos dois sen-sores, uma câmara e um LRF.

A API fornecida pelo Gazebo é usado pelo próprio simulador dando acesso ao utilizador a capacidade de atuar ou obter dados sobre estado do mundo, tendo esta como base bibliotecas de terceiros para visualiza¸cão e simula¸cão da parte f´ısica. Neste simulador todos os objetos exceto luzes têm propriedades f´ısicas, que permitem aos modelos simulados terem compor-tamentos realistas quando sujeitos a for¸cas exteriores. Possui também uma forte liga¸cão à plataforma ROS, devido à sua integra¸cão pioneira com esta framework.

3.2.1 Preferˆencia pelo Gazebo

O Gazebo e o V-REP possuem ambos licen¸ca gratuita e podem ser executados na pla-taforma Linux, o que os torna eleg´ıveis para a realiza¸c˜ao deste trabalho, embora no caso do V-REP esta s´o seja gratuita em contexto educacional.

Para a realiza¸cão deste projeto de simula¸cão foi necessária uma forma de desenvolver um modelo de um robô com um sistema de dire¸cão Ackermann, que fosse capaz de produzir dados provenientes de um dispositivo RGB-D simulado e de um LRF Hokuyo também simulado. Ambos os simuladores possuem as caracter´ısticas necessárias ao desenvolvimento do projeto, mas na modela¸cão de objetos existe uma diferen¸ca no modo como é efetuado a representa¸cão f´ısica do modelo. Enquanto que o Gazebo separa a componente visual da f´ısica do modelo, em V-REP estas duas componentes são representadas pela mesma geometria. Neste aspeto penso que a abordagem tomada pelo simulador Gazebo é a mais apropriada.

A modela¸cão foi poss´ıvel gra¸cas à linguagem de descri¸cão SDF enquanto que a dire¸cão Ackermann e a produ¸cão de dados a partir dos sensores foi obtida gra¸cas a vários plugins.

Para além das razões já apresentadas, o Gazebo tem sido uma ferramenta já utilizada no IRIS-Lab (IEETA), sendo também um simulador com uma elevada simbiose com o ecossistema ROS, que é a framework utilizada neste projeto. A decisão da versão do simulador Gazebo a

(40)

Figura 3.1: Tipo de juntas, adaptado de [27]

utilizar foi condicionada pela versão de ROS utilizada na realiza¸cão do trabalho de disserta¸cão. Como é utilizado o ROS Indigo, a versão do Gazebo escolhida foi a versão 2.2.3, pois esta encontra-se totalmente integrada com o sistema ROS usado.

3.3 Gazebo

O Gazebo é um ambiente de simula¸cão para aplica¸cões robóticas, capaz de descrever modelos de robôs e outros objetos presentes no seu meio envolvente. Os objetos, incluindo o robô, são tratados como um conjunto de partes (links) interligados por juntas. A descri¸cão de cada parte inclui uma representa¸cão para as colisões, uma representa¸cão visual e um modelo inercial. A cada parte podem ainda ser associados sensores. As juntas, que funcionam como articula¸cões, podem ter diferentes graus de liberdade.

3.3.1 Motor de f´ısica

O Gazebo tem como uma das suas caracter´ısticas fundamentais a simula¸cão das propri-edades f´ısicas dos diversos objetos e a intera¸cão destes objetos entre si. Portanto, devido à importância das intera¸cões f´ısicas entre os diversos modelos, o Gazebo optou por utilizar um motor de f´ısica já existente. Este motor é um software que tem como principal objetivo simu-lar as propriedades de todos os corpos materiais e as leis que tendem a modificar o estado e o movimento desses corpos, sem lhes modificar a natureza. O motor de f´ısica usado na versão do Gazebo utilizado neste projeto é o Open Dynamics Engine (ODE). As caracter´ısticas for-necidas ao Gazebo por este motor são várias nas quais estão inclu´ıdas dete¸cão de colisões, tipos de movimento efetuado pelas juntas, massa e inércia.

Uma junta estabelece liga¸cões entre os corpos de um determinado modelo, de forma a criar rela¸cões dinâmicas. Os tipos de juntas existentes foram concebidas tendo como base as juntas do motor de f´ısica usado na sua conce¸cão.

Existem v´arios tipos de juntas dispon´ıveis das quais podemos destacar as juntas prism´aticas, as revolute do tipo 1 e 2 e as do tipo bola que se encontram na Figura 3.1. As juntas

(41)

prismáticas têm um grau de liberdade em termos translacionais e permitem a dois corpos deslocaram-se num dos eixos, limitados por um intervalo cont´ınuo de valores. As revolute 1 possui um grau de liberdade em termos rotacionais e permitem a um corpo rodar sobre um eixo em rela¸cão ao seu centro de rota¸cão, enquanto que as revolute 2 são apenas duas juntas revolute 1 em série permitindo a rota¸cão sobre dois eixos em simultâneo, podendo-se restringir ou não essa rota¸cão. Nas juntas do tipo bola os corpos rodam apenas em rela¸cão ao seu centro de rota¸cão tendo três graus de liberdade em termos rotacionais.

3.3.2 Motor gr´afico

O simulador Gazebo usa o motor gráfico OGRE. O OGRE é um motor 3D open-source escrito em C++, desenhado especificamente para fornecer uma visualiza¸cão gráfica do mundo, embora possa ser usado para outros fins.

Este motor gráfico é usado pela biblioteca de rendering do Gazebo, para fornecer uma interface capaz de realizar o rendering de cenários 3D. Os cenários 3D já renderizados permi-tem apresentar ao utilizador uma interface gráfica com o estado do mundo. O motor gráfico é também utilizado pelas bibliotecas relacionadas com os sensores.

Dentro das carater´ısticas deste simulador está a possibilidade de atribuir texturas a um modelo no seu todo ou apenas a uma parte deste. No caso de se pretender apenas mapear a textura numa região espec´ıfica do modelo pode ser utilizado um programa de modela¸cão externo, ficando a informa¸cão do mapeamento incorporado no ficheiro da mesh no momento da exporta¸cão, sendo esta posteriormente usada pelo Gazebo. Um exemplo da aplica¸cão em Gazebo de texturas em modelos pode ser encontrado na Figura 3.2.

Figura 3.2: Modelo com e sem textura

3.3.3 Sensores

Os sensores são módulos sem qualquer tipo de representa¸cão f´ısica que criam informa¸cão a partir do mundo virtual, fornecendo-a posteriormente ao utilizador. Em Gazebo já existem vários tipos de sensores capazes de fornecer feedback realista ao utilizador, como por exemplo alt´ımetros, câmaras, sensores de contacto, profundidade, GPS, IMU entre outros, podendo-se ou não introduzir ru´ıdo nos dados produzidos por estes. Param além dos tipos de sensores

(42)

já existentes, o utilizador pode criar os seus próprios sensores utilizando plugins Gazebo espec´ıficos. Como os sensores são entidades separadas do modelo, é poss´ıvel reutiliza-los em qualquer modelo presente no mundo virtual. Na figura 3.4, é vis´ıvel que o robô PR2 está equipado com dois tipos de sensores, um LRF e uma câmara RGB.

3.3.4 Plugins

Este simulador permite também o desenvolvimentos de plugins utilizando a linguagem de programa¸cão C++, que fornece acesso à API do Gazebo. No Gazebo existem seis tipos de plugins que são os seguintes:

1. Plugin do mundo 2. Plugin de modelo 3. Plugin de sensor 4. Plugin do sistema

5. Plugin da parte visual do modelo 6. Plugin da interface gr´afica

Os plugins do mundo ligam-se a um determinado mundo virtual, permitindo a altera¸cão do seu estado, através da manipula¸cão de qualquer objeto presente neste, ou por meio da adi¸cão/remo¸cão de objetos nesse mundo, ou mesmo através da altera¸cão das caracter´ısticas relacionadas com a f´ısica ou com a ilumina¸cão.

Os plugins de modelo permitem aproximar o mais poss´ıvel a dinâmica do objeto modelado ao comportamento da entidade real do objeto, pois é poss´ıvel com este mecanismo obter informa¸cões sobre o estado interno deste e atuar sobre as várias juntas móveis do objeto.

Os plugins de sistema fornecem ao utilizador controlo sobre o processo de inicializa¸cão do próprio Gazebo. Um exemplo da utiliza¸cão deste tipo de plugins é a grava¸cão de imagens em disco produzidas dentro do ambiente de simula¸cão.

Os plugins da parte visual encontram-se ligadas a um modelo em espec´ıfico, e permitem alterar o material de um dos corpos que constituem esse modelo.

Os plugins da interface gráfica permitem ao utilizador criar interfaces personalizáveis dentro do próprio Gazebo.

3.3.5 Arquitetura

Este simulador encontra-se dividido em duas partes: o servidor e o cliente. Cada uma destas partes executa tarefas distintas (ver Figura 3.3), podendo-se executar apenas o servidor independentemente do cliente, embora o contrário não seja verdade. O simulador Gazebo e esta divisão de componentes permitem a execu¸cão das diferentes partes deste simulador em sistemas operativos distintos.

(43)

Plugins e comunicação entre processos Geração de dados dos sensores Ciclo de execução Atualização da física Geração da interface gráfica do mundo Manipulação de modelos

Figura 3.3: Arquitetura geral do gazebo, adaptado de [17]

O servidor encarrega-se de ler de um ficheiro espec´ıfico onde se encontra a descri¸cão do mundo para gerar o mundo, dispondo os objetos neste de seguida. Encontra-se também encarregue de executar o ciclo de atualiza¸cão responsável pelo comportamento f´ısico dos modelos no mundo, pelas colisões e pela informa¸cão obtida pelos sensores.

A parte do cliente executa uma interface gráfica baseada em QT, que fornece ao utilizador uma visualiza¸cão do mundo e dos objetos contidos neste, que podem ser facilmente apagados se assim se desejar. É poss´ıvel também a execu¸cão de várias tarefas de manipula¸cão sobre os vários modelos, incluindo luzes, como por exemplo mover e rodar. Para além destas opera¸cões, o utilizador pode inserir objetos criados por si ou descarregados dos repositórios da OSRF. Existem também outros tipos de clientes, como por exemplo uma interface web ou um cliente feito para um determinado propósito. Estes clientes com um objetivo espec´ıfico podem desempenhar tarefas como enviar uma mensagem com a finalidade de despoletar uma determinada a¸cão dentro do simulador.

A API do Gazebo permite também efetuar a comunica¸cão entre os diversos elementos presentes no mundo, usando Google Protocol Buffers como mecanismos de serializa¸cão de mensagens e a biblioteca Boost.Asio como mecanismo de transporte. Estes componentes servem como base a uma paradigma de comunica¸cão publicador/subscritor. A possibilidade de escrever plugins associado ao mecanismo de comunica¸cão entre processos permite despoletar a¸cões no mundo em determinados instantes, obter informa¸cões sobre este e sobre os modelos existentes neste.

3.4 Linguagens de modela¸

c˜

ao

Modelos são entidades virtuais que representam as caracter´ısticas do objeto f´ısico que se pretende simular. A posi¸cão e orienta¸cão no espa¸co, a massa e momentos de inércia, a forma, os graus de liberdade relativos das várias pe¸cas são exemplos de caracter´ısticas do objeto que o modelo virtual pode representar. No campo da robótica, normalmente, um modelo é definido

(44)

Figura 3.4: Ambiente de simula¸c˜ao Gazebo com o robˆo PR2 e diversos elementos

por um conjunto de corpos r´ıgidos interligados por juntas. Um modelo pode representar um simples cubo ou um robˆo complexo.

As linguagens de modela¸cão permitem a defini¸cão de um modelo através de um ficheiro onde se descrevem das carater´ısticas adequadas à simula¸cão do objeto real. O ambiente de simula¸cão Gazebo aceita modelos descritos em duas linguagens, SDF e URDF. O SDF é a linguagem criada originalmente para descrever os modelos do Gazebo, mas devido à forte interliga¸cão entre este simulador e ROS, também é poss´ıvel efetuar a descri¸cão destes utilizando a linguagem URDF.

3.4.1 SDF

SDF é um dialeto XML que permite a descri¸cão de objetos, estáticos e dinâmicos, e de ambientes para simula¸cão de robôs. Atualmente encontra-se na versão 1.6, mas no contexto desta disserta¸cão trabalhou-se com a versão 1.4, uma vez que é a versão compat´ıvel com a versão de Gazebo utilizada.

Como referido atrás, um modelo caracteriza um objeto e é composto por um conjunto de um ou mais corpos r´ıgidos, interligados por juntas. Além disso, contém ainda um conjunto de plugins e as propriedades do objeto que representa. Por sua vez, cada corpo r´ıgido, link na terminologia usada no SDF, é composto por um conjunto de elementos, dos quais se podem destacar a representa¸cão visual, o modelo de colisões e o modelo inercial. A separa¸cão entre a representa¸cão visual e o modelo de colisões permite criar simula¸cões mais eficientes. O rendering gráfico pode ser feito no GPU, o que permite usar modelos visuais realistas. Por outro lado, as colisões são tratadas normalmente no CPU, podendo-se usar modelos mais simples. Por exemplo, uma roda de um robô pode ser representada por um simples cilindro, em termos de colisões, e por uma estrutura gráfica mais complexa, em termos de representa¸cão visual.