Ambiente de simulação 3D para um veículo de condução autónoma

(1)

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

Ricardo Jorge

Silva Machado

Ambiente de simula¸

c˜

ao 3D para um ve´ıculo de

(2)

(3)

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

Ricardo Jorge

Silva Machado

Ambiente de simula¸

c˜

ao 3D para um ve´ıculo de

condu¸

c˜

ao aut´

onoma

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 do Prof. Dr. Artur José Carneiro Pereira e do Prof. Dr. Manuel Bernardo Salvador Cunha, Professores do Departamento de Electrónica, Telecomunica¸cões e Informática (DETI) da Universidade de Aveiro

(4)

(5)

o j´uri / the jury

presidente / president Tom´as Ant´onio Mendes Oliveira e Silva

Professor Associado da Universidade de Aveiro

vogais / examiners committee Artur Jos´e Carneiro Pereira

Professor Auxiliar da Universidade de Aveiro (orientador)

Manuel Bernardo Salvador Cunha

Professor Auxiliar da Universidade de Aveiro (co-orientador)

Lu´ıs Paulo Gon¸calves dos Reis

(6)

(7)

agradecimentos / acknowledgements

´

E com muito gosto que aproveito esta oportunidade para agradecer aos meus pais pela confian¸ca que me depositaram ao longo dos anos.

Aos meus amigos, sempre prontos a ajudar, e aos professores Artur Pereira e Bernardo Cunha pela orienta¸c˜ao e apoio que me deram no decorrer do desenvolvimento desta disserta¸c˜ao.

(8)

(9)

Palavras-chave Robótica, Condu¸cão Autónoma, Festival Nacional de Robótica, Simula¸cão, 3D, Modela¸cão

Resumo O software que controla um ve´ıculo de condu¸cão autónoma é composto por um conjunto de algoritmos, cada um encarregue por um aspecto da condu¸cão, e que juntos permitem que o ve´ıculo se movimente autonoma-mente num dado ambiente. Contudo, basta um erro para que tudo possa deixar de funcionar correctamente, e se crie uma situa¸cão perigosa. A real-iza¸cão de testes exaustivos ao software de controlo é assim essencial. Estes, contudo, exigem um ambiente de teste controlado, nem sempre dispon´ıvel, e podem estar limitados pelas caracter´ısticas do ve´ıculo ou por questões de seguran¸ca, entre outras. Para atenuar as dificuldades que resultam do uso de um ve´ıculo real para executar esses testes pretendeu-se, com este tra-balho, desenvolver um ambiente de simula¸cão que permita simular o ve´ıculo e o ambiente que o rodeia. Este ambiente de simula¸cão tenta emular o hard-ware utilizado no ve´ıculo real, o que implica emular os actuadores e sensores e a comunica¸cão entre o hardware e o software. Esta abordagem, por sua vez, proporciona uma separa¸cão clara entre a simula¸cão e o software que está a ser testado, uma vez que este não sabe se está a interagir com o ve´ıculo real ou com o simulado. O segundo objectivo desta disserta¸cão foi o de estudar a viabilidade de utiliza¸cão de outros motores de f´ısica e lingua-gens de programa¸cão para além dos que são normalmente utilizados nestes tipos de projectos.

O Departamento de Electrónica, Telecomunica¸cões e Informática da Univer-sidade de Aveiro possui um grupo de trabalho focado no desenvolvimento de ve´ıculos e software para participa¸cão nas provas de condu¸cão autónoma do Festival Nacional da Robótica. O simulador foi desenvolvido para este grupo, de modo a facilitar a execu¸cão de testes aos algoritmos usados no ve´ıculo para condu¸cão autónoma, o que fez com que a modela¸cão do am-biente de simula¸cão se tenha baseado na pista usada nestas provas, e que os sensores e actuadores modelados sejam os usados no ve´ıculo real. Apesar do simulador não ter sido conclu´ıdo a tempo para ser usado nos testes do software de controlo de alto n´ıvel do ve´ıculo usado na edi¸cão de 2011 do Festival Nacional da Robótica, foi usado posteriormente para analisar a causa de problemas lá detectados. Também foi realizado algum trabalho na área de condu¸cão autónoma para a camada de alto n´ıvel do ve´ıculo, que contribuiu para a obten¸cão do terceiro lugar no Festival.

(10)

(11)

Keywords Robotics, Autonomous Driving, Portuguese Robotics Open, Simulation, 3D, Modeling

Abstract The software that controls an autonomous driving vehicle consists of a set of algorithms, each responsible for one aspect of driving, and together al-low the vehicle to move autonomously in a given environment. However, just one error is enough to make everything stop working properly, creating a dangerous situation. That is why the exhaustive testing of the control software is so essential. These tests, however, require a controlled environ-ment, not always available, and may be limited by the characteristics of the vehicle or for security reasons, among others. To alleviate the difficulties arising from the use of a real vehicle to run these tests it was intended, with this work, to develop a simulation environment that allows simulating the vehicle and the environment that surrounds it. This simulation tries to em-ulate the hardware used on the actual vehicle, which implies the emulation of the actuators and sensors and the communication between hardware and software. This approach, in turn, provides a clear separation between the simulation and software that is being tested, since it does not know if it is interacting with the real vehicle or with the simulated. The second objective of this dissertation was to study the viability of using other physics engines and programming languages other than those normally used in these types of projects.

The Department of Electronics, Telecommunications and Informatics at the University of Aveiro has a workgroup focused on developing software for ve-hicles and participating in the autonomous driving competition of the Por-tuguese Robotics Open. The simulator was developed for this workgroup in order to facilitate the testing of the algorithms used in the autonomous driving vehicle, which in turn made the modeling of the simulation environ-ment to be based on the track used in the competition, and the sensors and actuators to be modeled based on those used in the real vehicle.

Although the simulator was not completed in time to be used for testing for the 2011 edition of the Portuguese Robotics Open, it was used after to analyze the cause of the problems that existed in the high-level control. Also, some work was done in the high-level control of the vehicle, which helped achieve the third place.

(12)

(13)

Conte´

udo

Conte´udo i

Lista de Figuras iii

Lista de Tabelas v

1 Introdu¸c˜ao 1

1.1 Motiva¸c˜ao . . . 1

1.2 Objectivos . . . 2

1.3 Estrutura . . . 2

2 Condu¸cão Autónoma 5 2.1 Festival Nacional de Robótica (FNR) . . . 6

2.1.1 Condu¸c˜ao Aut´onoma no FNR . . . 6

2.2 Projecto ROTA . . . 8

2.2.1 Arquitectura geral da plataforma ROTA . . . 9

2.2.2 Software de controlo de alto n´ıvel . . . 12

2.3 Modela¸cão e simula¸cão em condu¸cão autónoma . . . 14

2.4 jMonkey . . . 16 2.4.1 Motor gráfico . . . 16 2.4.2 Motor de F´ısica . . . 16 2.5 Sumário . . . 17 3 Simulador 19 3.1 Introdu¸cão . . . 19 3.2 Modela¸cão do ambiente . . . 20 3.2.1 Modela¸cão da Pista . . . 20

3.2.2 Modela¸c˜ao dos elementos . . . 28

3.2.3 Luz e Sombra . . . 34 3.3 Modela¸cão do ve´ıculo . . . 38 3.3.1 Comunica¸cão . . . 38 3.3.2 Arquitectura geral . . . 40 3.3.3 Controlo . . . 42 3.3.4 Visão . . . 43

3.4 Interaçcão com a simula¸cão . . . 45

3.4.1 Interface Gr´afica . . . 47

(14)

4 Resultados 51

4.1 Participa¸c˜ao no FNR 2011 . . . 51

4.1.1 Detec¸c˜ao de linhas da estrada . . . 51

4.1.2 Template matching eficiente . . . 52

4.1.3 Deteçcão de obstáculos . . . 52

4.1.4 Conclusões . . . 53 4.2 Tempos de execu¸cão . . . 53 4.2.1 Cria¸cão da pista . . . 54 4.2.2 Ciclo de execu¸cão . . . 55 4.2.3 Comunica¸cão TCP . . . 58 4.3 Precisão do simulador . . . 59 4.4 Adaptabilidade do simulador . . . 64 5 Conclusões 67 5.1 Conclusões . . . 67 5.2 Trabalho Futuro . . . 68 Bibliografia 73

(15)

Lista de Figuras

2.1 Pista usada na prova de Condu¸c˜ao Aut´onoma . . . 6

2.2 Sinais indicados pelos sem´aforos . . . 7

2.3 Sinais de transito usados nas provas . . . 8

2.4 Plataformas usadas no Projecto ROTA. . . 9

2.5 Arquitectura geral da plataforma ROTA . . . 10

2.6 Subsistema de controlo de baixo n´ıvel da plataforma ROTA . . . 11

2.7 Arquitectura do software da plataforma ROTA . . . 12

2.8 Calculo da suspens˜ao no Bullet . . . 17

3.1 Representa¸c˜ao f´ısica e visual do carro . . . 20

3.2 Representa¸c˜ao da pista do FNR no simulador. . . 21

3.3 Pista do FNR dividida por sec¸c˜oes. . . 21

3.4 Programa de edi¸c˜ao da pista. . . 23

3.5 Ru´ıdo base . . . 25

3.6 Ru´ıdo aleat´orio . . . 25

3.7 C´alculo da ilumina¸c˜ao difusa . . . 26

3.8 Normal Mapping . . . 27

3.9 Convers˜ao de uma textura para um mapa de NormalMapping . . . 27

3.10 Fases de constru¸c˜ao da textura da pista . . . 28

3.11 Representa¸c˜ao do obst´aculo no simulador. . . 29

3.12 Representa¸c˜ao do parque de estacionamento no simulador. . . 30

3.13 Representa¸cão da área de manuten¸cão no simulador. . . 31

3.14 Representa¸c˜ao do t´unel no simulador. . . 32

3.15 Representa¸c˜ao do painel semaf´orico no simulador. . . 33

3.16 Representa¸c˜ao do sinal de transito no simulador . . . 34

3.17 Exemplo do diferentes tipos de luz existentes . . . 35

3.18 Conceito de Shadow Map . . . 36

3.19 Conceito de Shadow Volume . . . 37

3.20 Altera¸cões necessárias à arquitectura actual do ROTA . . . 38

3.21 Camadas de abstraçcão na interaçcão com o ve´ıculo simulado. . . 40

3.22 Modelo adoptado para mover e rodar objectos no simulador . . . 46

3.23 Interface gr´afica do simulador. . . 47

3.24 Janela de visualiza¸c˜ao 3D da interface gr´afica. . . 49

4.1 Impacto do n´umero de cˆamaras na performance . . . 56

(16)

4.3 An´alise pormenorizada do tempo gasto na 3a fase . . . 57

4.4 ROTA a percorrer o 1o Cen´ario . . . 60

4.9 Pista criada para o teste de adaptabilidade. . . 64

4.10 ROTA a percorrer a nova pista. . . 64

4.11 Ve´ıculo criado para o teste de adaptabilidade . . . 65

4.12 Novo ve´ıculo a percorrer a pista . . . 66

(17)

Lista de Tabelas

4.1 Requisitos m´ınimos do simulador . . . 54 4.2 Caracter´ısticas do port´atil de testes usado . . . 54

(18)

(19)

Cap´ıtulo 1

Introdu¸

c˜

ao

1.1 Motiva¸

c˜

ao

A fase de testes é uma das mais importantes fases no ciclo de desenvolvimento de qual-quer software. Alguns métodos de desenvolvimento de software encorajam a defini¸cão de teste antes de escrever qualquer código, uma vez que permite definir exactamente qual é o comportamento de uma dado método, quais as entradas válidas e a sa´ıda esperada, sendo assim mais fácil escrever código que obedece às especifica¸cões dadas. Os testes, quando de-vidamente estruturados e realizados, permitem demonstrar que o software está a funcionar como seria de esperar e isso dá confian¸ca ao programador. Contudo, os testes nem sempre são fáceis de executar, e nem sempre permitem recolher dados conclusivos ou obter uma conclusão definitiva.

Isto manifesta-se em diversas situa¸cões, em particular no desenvolvimento de software para um robot que se movimenta autonomamente. Devido a vários factores, como a fragilidade do robot, a dificuldade em movimentá-lo ou o espa¸co necessário para realizar os testes, pode não ser poss´ıvel realizar todos os tipos de testes que se gostaria, e os que são poss´ıveis de realizar podem ser demorados e requerer a aten¸cão total da pessoa encarregue por os realizar. Uma forma de ultrapassar estas dificuldades consiste em recorrer ao uso de um ambiente de simula¸cão que permita simular o robot em questão e o ambiente onde este se movimenta. Essa abordagem apresenta uma série de vantagens, tais como:

• Controlo sobre o tempo e espa¸co: uma vez que estamos num ambiente simulado temos controlo absoluto sobre o espa¸co, podendo alterar a posi¸cão do robot sem esfor¸co, re-colocá-lo exactamente na mesma posi¸cão para refazer testes, acelerar o tempo de modo a executar testes mais depressa, ou até mesmo reduzir o tempo de modo a analisar, passo a passo, a evolu¸cão do comportamento do robot em cada momento. Isto liberta-nos do trabalho árduo de estar repetidamente a colocar o robot nas posi¸cões certas para fazer os testes e esperar que o robot acabe a execu¸cão para ir observar os ficheiros de log. • Redu¸cão de custos: normalmente os robots utilizados em investiga¸cão são protótipos,

´

unicos no mundo e bastante caros, estando a possibilidade de constru¸cão de mais do que um normalmente fora de questão, e qualquer dano causado pode inutilizar o robot durante alguns dias, até ser arranjado. Na simula¸cão podemos ter o números que quisermos de robots, com os sensores e actuadores simulados o mais sofisticadamente poss´ıvel, e sem ter medo de destruir o robot durante o processo de teste. A utiliza¸cão de

(20)

um simulador também possibilita que os testes possam decorrer em qualquer s´ıtio, não sendo necessário que uma pessoa tenha acesso f´ısico ao robot para testar o seu software, e permitindo que várias pessoas testem em simultâneo, cada uma com o seu simulador. O IEETA participa desde 2001 na prova de condu¸cão autónoma do Festival Nacional de Robótica, tendo já desenvolvido diversos ve´ıculos para participa¸cão. O teste do software de controlo de alto n´ıvel é sempre uma tarefa árdua e muitas vezes imposs´ıvel de realizar em laboratório. A pista onde as provas se realizam tem dimensões que impossibilitam o teste no laboratório com a pista real, sendo necessário esperar pelo evento para se fazerem os testes globais. A existência de uma ambiente de simula¸cão onde se pudessem recriar condi¸cões semelhantes às da competi¸cão é uma mais-valia desejada.

1.2 Objectivos

Os objectivos principais desta disserta¸cão desdobravam-se a dois n´ıveis. Por um lado, pretendia-se construir um ambiente de simula¸cão que torne o processo de execu¸cão de testes o mais simples e eficaz poss´ıvel. Por outro, participar na prova de condu¸cão autónoma da edi¸cão de 2011 do Festival Nacional de Robótica. O simulador em questão deveria permitir testar todos os componentes de software do robot, com o m´ınimo de altera¸cões poss´ıveis e desejavelmente nenhumas. Deveria emular todo do hardware utilizado, criando um interface que permita a utiliza¸cão do software de controlo tal como é usado no robot real. O simulador deveria ser flex´ıvel e configurável de modo a permitir facilmente usar pistas diferentes e mesmo ve´ıculos diferentes.

O desenvolvimento do ambiente de simula¸c˜ao deveria ter em considera¸c˜ao os seguintes aspectos:

• Pretende-se utilizar o simulador para testar algoritmos de visão. Portanto o simulador deverá ser capaz de produzir imagens de elevado realismo de modo a emular a imagem produzida pelas câmaras reais.

• Num trabalho anterior sobre simula¸c˜ao [1], utilizou-se o ODE como motor de f´ısica. Neste simulador pretende-se utilizar o motor de f´ısica Bullet de modo a explorar a sua viabilidade em rela¸c˜ao ao mais popular ODE.

• Fornecer uma interaçcão com o ambiente de simula¸cão simples e intuitiva.

A um segundo n´ıvel, o elemento que abra¸casse este projecto faria parte integrante da equipa do IEETA que iria participar na prova de condu¸cão autónoma da edi¸cão de 2011 do Festival Nacional de Robótica. Nesse sentido, teria que se envolver na prepara¸cão da partic-ipa¸cão. Visto que o Festival decorreria a meio da disserta¸cão, isso significaria uma interrup¸cão no trabalho com o ambiente de simula¸cão para um envolvimento com o desenvolvimento do software de controlo autónomo do ve´ıculo. No entanto, esta experiência com o robot real traria uma mais profunda consciência da importância do ambiente de simula¸cão.

1.3 Estrutura

(21)

Cap´ıtulo 2 - Condu¸cão Autónoma - Neste capitulo será apresentada uma visão geral sobre a condu¸cão autónoma e sobre o ve´ıculo desenvolvido para participar na prova de condu¸cão autónoma do Festival Nacional de Robótica, sobre a qual esta disserta¸cão se irá focar. Será também discutida as necessidades de simula¸cão para o ambiente em questão, e a solu¸cão encontrada tendo em considera¸cão os requisitos impostos.

Capitulo 3 - Simulador - Neste cap´ıtulo será descrito em pormenor todo o desenvolvi-mento do ambiente de simula¸cão, incluindo a simula¸cão do ve´ıculo, do ambiente onde este se encontra, e a interaçcão do utilizador com a simula¸cão.

Cap´ıtulo 4 - Resultados - Neste cap´ıtulo serão discutidos os resultados obtidos, os testes implementados para obter a precisão do simulador em rela¸cão à realidade, o tempo de execu¸cão de vários aspectos da simula¸cão, e a adaptabilidade do simulador a novos tipos de ve´ıculos e cenários. Será ainda apresentado o trabalho desenvolvido para o ve´ıculo autónomo, e como este trabalho influenciou vários aspectos no desenvolvimento do simulador.

Cap´ıtulo 5 - Conclusões - Finalmente neste cap´ıtulo serão discutidos os resultados obtidos e serão apresentadas sugestões de trabalho futuro.

(22)

(23)

Cap´ıtulo 2

Condu¸

c˜

ao Aut´

onoma

A maioria dos acidentes na estrada são causados por erro humano [2], seja por excesso de velocidade, desrespeito pelos sinais de trânsito, álcool ou outras drogas, cansa¸co, sono, distraçcões, ou muitas outras razões. A verdade é que à medida que o número de ve´ıculos a circular na estrada aumenta, também o número de acidentes aumenta, e tudo isto seria evitável se existisse algo que conduzisse por nós quando fosse necessário, alguém que não se cansasse, não se distra´ısse, que consiguisse tomar decisões em fraçcões de segundo, alguém como um computador. Este é o objectivo da condu¸cão autónoma: criar um ve´ıculo que conduza sozinho, em qualquer tipo de terreno, rural ou urbano, e que consiga ultrapassar qualquer desafio, garantindo a seguran¸ca dos passageiros, e acima de tudo que consiga ir de A para B autonomamente.

Este futuro está próximo. O primeiro ve´ıculo autónomo foi criado em 1977, no Laboratório de Engenharia Mecânica Tsukuba no Japão, e era capaz de seguir linhas brancas, como aquela que existem na estrada, a uma velocidade máxima de 30 km/h. Actualmente já se comercializam ve´ıculos que estacionam sozinhos, controlam a distância ao ve´ıculo da frente, etc. O interesse despertado por esta área junto dos investigadores, os quais têm tido cada vez mais sucesso no desenvolvimento de um ve´ıculo que consiga um dia conduzir em qualquer ambiente, faz com que seja apenas uma questão de tempo até que os primeiros carros que consigam conduzir autonomamente estejam dispon´ıveis comercialmente.

São vários os projectos e eventos internacionais que têm sido lan¸cados no sentido de promover a investiga¸cão na área da condu¸cão autónoma. Em 1980 a DARPA (Defense Ad-vanced Research Projects Agency) criou o ALV (Autonomous Land Vehicle) que foi o primeiro ve´ıculo a conseguir conduzir autonomamente numa estrada com uma velocidade de 30km/h, usando para isso radares laser, visão processada por computador e um mecanismo de controlo robótico [3]. Mais recentemente esta agência promoveu o DARPA Grand Challenge, uma competi¸cão que decorreu em 2004 e 2005 com o objectivo de promover o desenvolvimento na ´

area da condu¸cão autónoma. Em 1987 o EUREKA Prometheus Project foi o maior projecto de investiga¸cão e desenvolvimento para o objectivo de obter um carro que conduza sozinho, tendo sido suportado por fundos europeus [4]. Desde 1987 a 1994 este projecto desenvolveu vários protótipos de ve´ıculos de condu¸cão autónoma, de entre os quais o ViTA (Vision Tech-nology Application) e o VaMP se destacam.

Em Portugal, o Festival Nacional de Robótica tem, desde a sua origem, promovido a investiga¸cão nessa área, através de uma competi¸cão em condu¸cão autónoma. A Universidade de Aveiro, institui¸cão co-promotora da cria¸cão do Festival, tem participado activamente nessa

(24)

competi¸cão com equipas oriundas de vários dos seus departamentos. Uma dessas equipas pertence ao IEETA, no âmbito do qual esta disserta¸cão foi desenvolvida.

No resto deste cap´ıtulo ir-se-á apresentar uma descri¸cão do Festival Nacional de Robótica (FNR), com particular destaque da prova de condu¸cão autónoma. A seguir descrever-se-á o projecto ROTA, projecto em desenvolvimento no IEETA focado na condu¸cão autónoma e que tem participado no Festival. Finalmente, falar-se-á um pouco sobre modela¸cão e simula¸cão em condu¸cão autónoma, descrevendo-se o jMonkey, ferramenta usada para construir uma ambiente de simula¸cão dos ve´ıculos do projecto ROTA.

2.1 Festival Nacional de Rob´

otica (FNR)

O Festival Nacional de Robótica (FNR) é actualmente uma iniciativa da Sociedade Por-tuguesa de Robótica, originalmente criada por alguns docentes das Universidades de Aveiro, Minho e Instituto Superior Técnico. Tem como objectivo promover o encontro entre entidades e pessoas que em Portugal se dedicam à robótica e promover o desenvolvimento na área da robótica através de competi¸cões robóticas e de um encontro cient´ıfico.

De entre as várias competi¸cões existentes no FNR destaca-se aqui a prova de condu¸cão autónoma, pela importância que tem para o trabalho desenvolvido no âmbito desta dis-serta¸cão.

2.1.1 Condu¸c˜ao Aut´onoma no FNR

Figura 2.1: Pista usada na prova de Condu¸cão Autónoma, com 14x9 metros de dimensão real.

(25)

a b c

d e

Figura 2.2: Sinais indicados pelos sem´aforos (a) parar na passadeira; (b) seguir para a es-querda; (c) seguir em frente; (d) ir para o parque de estacionamento; e (e) fim da prova.

A prova de Condu¸cão Autónoma ”representa um desafio técnico no qual um robô móvel e autónomo deve percorrer um percurso ao longo de uma pista fechada, que apresenta semel-han¸cas marcantes com a condu¸cão de um ve´ıculo automóvel numa estrada convencional. A pista utilizada tenta reproduzir, em certa medida, um cenário real, embora a competi¸cão decorra num ambiente estruturado. A pista, em formato de 8, simula uma estrada com duas vias à qual foram adicionados uma passadeira com um par de painéis semafóricos (um em cada sentido), um túnel, uma zona de obras, um obstáculo e uma área de estacionamento com dois lugares em que um deles está ocupado. A posi¸cão do obstáculo na pista, a localiza¸cão exacta da área de estacionamento e a posi¸cão livre nessa área são dados desconhecidos para o robô no in´ıcio da sua prova”[5]. A figura 2.1 ilustra a forma da pista da prova e os seus vários elementos.

A prova é composta por 3 fases (mangas), cada uma com um n´ıvel de dificuldade acrescido [6]. Em todas as fases os robôs partem da passadeira após o reconhecimento do sinal ”seguir em frente”exibido no painel semafórico e percorrem autonomamente a pista executando duas voltas completas. A primeira fase apenas exige que o robot reconhe¸ca correctamente o sinal exibido no painel semafórico e que execute as duas voltas sem sair da pista, no menor tempo poss´ıvel.

A segunda fase já exige que o robot seja capaz de identificar um de 5 sinais diferentes (Figura 2.2) exibidos pelo painel semafórico e que reaja em conformidade. Alem dos sinais, o robot também deve ser capaz de identificar e de se desviar de vários obstáculos que ocupam uma das faixas de rodagem e cuja posi¸cão na pista é desconhecida até ao in´ıcio da prova.

Finalmente, na terceira fase são adicionados mais dois desafios aos já existentes: um túnel que cobre uma parte do caminho e uma zona de obras. O túnel tem como objectivo alterar as condi¸cões de luz, alterando a forma como o robot navega. A zona de obras é um desvio do percurso inicial que é desconhecido a priori. O novo percurso é marcado através de cones coloridos, unidos através de uma fita de plástico. Nesta zona, o robot deve deixar a faixa inicial, seguir pelo novo caminho sem tocar em qualquer dos elementos que o delimita e reentrar na pista onde a zona de obras termina.

No final da segunda e terceira fases o robot terá que, autonomamente, localizar e estacionar no parque de estacionamento após o fim da prova. Este parque contém dois lugares para estacionar, sendo que um deles está obstru´ıdo por um obstáculo, o que obriga ao robot a

(26)

Figura 2.3: Sinais de transito usados nas provas. Cada sinal é identificado por um número (1 ou 2) e um grupo (perigo, obrigatório ou informativo).

identificar qual o lugar que est´a livre e a estacionar l´a.

Nas três fases existem sinais de trânsito situados nas margens da pista, cuja posi¸cão exacta é desconhecida, e onde a correcta deteçcão destes sinais pelo carro proporciona bónus. Existem ao todo seis sinais de trânsito (Figura 2.3), dois de perigo (triangulares), dois obrigatórios (circulares) e dois informativos (quadrados).

2.2 Projecto ROTA

Desde 2001, o primeiro ano em que decorreu o FNR, que o DETI/IEETA participa na prova de condu¸cão autónoma do FNR, tendo obtido 3 primeiros lugares, 1 segundo e 3 ter-ceiros. Foram várias as plataformas robóticas usadas na participa¸cão. Dessas plataformas destacam-se aqui as duas mais recentes, o ROTA a o Zinguer (ver figura 2.4), actualmente usadas no Projecto ROTA para desenvolvimento, apresenta¸cões e participa¸cão em provas. O ROTA nasceu em 2006, ano em que a pista usada na competi¸cão sofreu altera¸cões profundas, passando a ter duas faixas de rodagem. Em 2008, foi desenvolvida uma versão melhorada, o RatoZinguer, posteriormente abreviado para zinguer. São estas plataformas que estão asso-ciadas ao trabalho aqui apresentado.

(27)

(a) ROTA (2006) (b) RatoZinguer (2008)

Figura 2.4: Plataformas usadas no Projecto ROTA.

Ambas as plataformas são do tipo ”triciclo”, com uma roda motriz e duas rodas direc-cionais, e ambas têm uma arquitectura semelhante. A cria¸cão do RatoZinguer deveu-se à existência de várias lacunas detectadas na arquitectura do ROTA. O ROTA utilizava uma solu¸cão baseada em SBC (Single Board Computer ) para a camada de alto n´ıvel, que difi-cultava o processo de teste e debugging do software, devido à falta de monitor e teclado. A versão RatoZinguer foi constru´ıda de modo a incluir espa¸co para um portátil, que não só facilita o processo de upgrading do hardware caso seja necessário — basta substituir o portátil — como resolve o problema de visualiza¸cão e interaçcão com o software, gra¸cas ao monitor/teclado/rato embutido no portátil. O ROTA também possu´ıa uma grave falha de constru¸cão: a distância do seu chassis em rela¸cão ao chão era tão reduzida que, em algumas provas, onde o chão tinha relevos e imperfei¸cões, o ve´ıculo colidia com os relevos e mudava de trajectória ou parava completamente.

2.2.1 Arquitectura geral da plataforma ROTA

A arquitectura geral da plataforma ROTA pode ser dividida em 4 subsistemas principais, nomeadamente controlo de alto n´ıvel, sistema de vis˜ao, controlo de baixo n´ıvel e camada mecˆanica (ver figura 2.5).

(28)

(a) (b)

Figura 2.5: Arquitectura geral da plataforma ROTA: (a) Diagrama de blocos; (b) localiza¸c˜ao no ve´ıculo[7].

Subsistema mecˆanico

A estrutura mecânica da plataforma ROTA é constitu´ıda por uma base onde estão im-plantados um sistema de locomo¸cão do tipo Ackermann, dois sensores de obstáculos, dois sensores de chão, dois fárois e duas baterias.

O sistema de locomo¸cão é em forma de triciclo, com uma roda motriz à trás, comandada por um motor, e duas rodas direccionais à frente, comandadas por um único servo-motor. A rota¸cão do motor e a posi¸cão do servo-motor são controlados pelo subsistema de controlo de baixo n´ıvel.

Os sensores de obstáculos estão posicionados na frente de modo a detectar a existência de obstáculos no seu caminho. A deteçcão é feita com base num feixe de luz infra-vermelho que é reflectivo no obstáculo, sendo esta reflexão colhida por uma lente no sensor que permite calcular a distância do sensor ao obstáculo.

O sensor de chão consiste num par emissor/receptor de infra-vermelhos colocados na frente do robot que detectam superf´ıcies reflectoras de infra-vermelhos. São usados para deteçcão de sa´ıdas da pista ou passagem pela passadeira. Estes sensores aproveitam o facto do chão da pista ser preto e absorver infravermelho, enquanto que as linhas delimitadoras são brancas e reflectem infravermelhos.

Subsistema de controlo de baixo n´ıvel

O controlo de baixo n´ıvel serve como middleware entre a camada de alto n´ıvel e a camada mecânica, proporcionando a quem está a desenvolver o software de controlo de alto n´ıvel uma interface simples para a interaçcão com o robot. A comunica¸cão entre as duas camadas é feita através da troca de tramas de informa¸cão enviadas por uma porta série. No sentido descendente seguem as mensagens de actua¸cão, dirigidas ao motor e servo-motor do sistema de locomo¸cão, e as de controlo dos faróis. No sentido ascendente seguem as mensagens de conteúdo sensorial, nomeadamente dados de odometria, estado dos sensores de obstáculos, estado dos sensores de chão e carga das baterias.

Cada trama ´e codificada numa sequˆencia ASCII, respeitando o formato $XXXXYY· · · YY&ZZ#

(29)

sendo

$ o s´ımbolo de in´ıcio de trama;

XXXX uma palavra de 16 bits, codificada em 4 d´ıgitos hexadecimais ASCII, que iden-tifica o tipo da mensagem;

YY· · · YY o campo informativo da mensagem, com um número variável de pares YY, cada um representando um byte de informa¸cão codificado em hexadecimal ASCII; & o s´ımbolo de fim de informa¸cão;

ZZ o checksum da mensagem, codificado em hexadecimal ASCII; e # o s´ımbolo de fim da trama.

O subsistema de baixo n´ıvel está estruturado em nós de processamento baseados em micro controladores e interligados numa rede CAN (Controller Area Network). O diagrama geral pode ser visto na figura 2.6. Estes nós são responsáveis pelo controlo da camada mecânica, nomeadamente controlo do motor da roda de traçcão, controlo do servo-motor da direçcão, recolha de dados odométricos, actua¸cão dos diferentes faróis do carro e monitoriza¸cão das baterias. Um nó especial funciona como gateway entre a rede CAN e o subsistema de con-trolo de alto n´ıvel. Este nó é responsável pelo processamento das tramas do protocolo de comunica¸cão.

Figura 2.6: Subsistema de controlo de baixo n´ıvel da plataforma ROTA [8] Subsistema de vis˜ao

Existem duas câmaras Firewire (IEEE 1394) montadas no topo do robot, responsáveis por recolher informa¸cão visual do mundo e que formam o sistema de visão. Uma das câmaras é usada para ver a faixa de rodagem e os objectos que lá se encontram. Está montada no centro do carro com alguma eleva¸cão e apontada para a estrada de modo a captar a maior quantidade de informa¸cão poss´ıvel. A segunda câmara é usada para ver o painel sinaléctico que funciona como semáforo [9]. Está montada segundo um ângulo espec´ıfico de modo a que quando o robot está parado na passadeira, o painel sinalético que está suspenso seja perfeitamente vis´ıvel.

Ambas as câmaras são configuradas para uma capta¸cão a 30 frames por segundos e com uma resolu¸cão de 320 por 240 pixéis, utilizando o formato YUV444.

(30)

Figura 2.7: Arquitectura do software da plataforma ROTA

Subsistema de controlo de alto n´ıvel

Um sistema computacional montado no topo robô, ao qual se ligam o subsistema de visão e o subsistema de controlo de baixo n´ıvel, é responsável pelo controlo de alto n´ıvel do robô. Na versão mais recente da plataforma robótica, o ve´ıculo zinguer, este sistema é um portátil a correr linux.

Esta camada é responsável por recolher informa¸cão das câmaras e do subsistema de con-trolo de baixo n´ıvel, processar essa informa¸cão, tomar uma decisão com base nela, e enviar comandos para o sistema de traçcão e de direçcão do ve´ıculo de modo a controlar o seu movimento.

2.2.2 Software de controlo de alto n´ıvel

A arquitectura do software usada baseia-se num modelo composto por três entidades: Percep¸cão, Modelo do mundo e Decisão e Açcão (Figura 2.7). A Percep¸cão é responsável por recolher e pré-processar a informa¸cão vinda dos sensores. Esta entidade recebe a informa¸cão em bruto e processa-a de forma a retirar os dados relevantes para as próximas entidades. O Modelo do mundo, usando a informa¸cão recebida da percep¸cão, tenta manter uma caracter-iza¸cão actual do mundo onde o robot se insere adequada à tomada de decisões e actua¸cões. Finalmente o bloco de Decisão e Açcão, com base na descri¸cão actual do mundo, escolhe e executa a melhor açcão consoante a situa¸cão, enviando comandos para a camada de controlo de baixo n´ıvel.

(31)

Modelo do Mundo

O mundo do robot é constitu´ıdo por uma pista e pelo robot inserido nessa pista. A pista é definida como uma malha interligada de tro¸cos (seçcões de pista), cada um com uma geometria bem definida. Trata-se de uma abordagem topológico-geométrica [10]. A estrutura base da pista é assumida como sendo conhecida e é fornecida ao software através de um ficheiro de configura¸cão [11].

Para além do robot que nela se movimenta, e cuja localiza¸cão é preciso conhecer, vários outros elementos podem povoar a pista. Um ou mais obstáculos — parelip´ıpedos de cor verde — podem ser colocados sobre as faixas de rodagem, dificultando a movimenta¸cão do robot. Cones indicadores de zona de obras podem ser colocados na pista, definindo uma zona de rodagem fora da definida pelos riscos brancos delimitadores. Um semáforo, colocado sobre a passadeira, afixa um sinal que condiciona a forma como o ve´ıculo se deve deslocar.

Usando como matéria-prima a informa¸cão vinda da Percep¸cão, o bloco de Modelo do mundo tem de manter actualizada, tanto quanto poss´ıvel, a caracteriza¸cão do mundo, ofer-ecendo ao módulo de Açcão uma visão coerente e simples do mundo. Esta fun¸cão é obtida através do uso de integradores. Actualmente existem 3 tipos de integradores:

• O Integrador de Sinais tem como objectivo identificar adequadamente o sinal de trânsito apresentado pelo semáforo. Com base na localiza¸cão do ve´ıculo na pista define a região de imagem que deve ser analisada pelo perceptor de sinais. Por outro lado, evita a ocorrência de falsas identifica¸coes, considerando que a deteçcão de um sinal apenas ocorre quando este foi detectado n vezes consecutivas.

• O Integrador de Obstáculos é responsável por localizar os obstáculos na pista. Fil-trando as deteçcões de obstáculos feitas pelo módulo de percep¸cão, tenta estimar o mais fielmente poss´ıvel as suas localiza¸cões na pista. mas neste caso para a deteçcão de obstáculos.

• O Integrador de Localiza¸cão O estado do ve´ıculo contempla, entre outros atributos, a sua localiza¸cão na pista e num tro¸co. O papel deste integrador é determinar estas localiza¸cões. Para isso usa os dados vindos da percep¸cão relativos à odometria e à localiza¸cão dos riscos delimitadores da faixa de rodagem e o conhecimento existente relativo à configura¸cão da pista.

Toda a informa¸cão é armazenada numa memória partilhada (RTDB) acess´ıvel a todas as entidades, onde cada entidade pode ler e escrever sem haver problemas de concorrência no acesso à informa¸cão.

Percep¸c˜ao

Como referido atrás, o bloco de percep¸cão é responsável pela recolha e pré-processamento dos dados produzidos pelos sensores. Pode-se considerar este blocos dividido nos seguintes perceptores:

• O Perceptor da Pista usa a frame de imagem da câmara de estrada para localizar pon-tos pertencentes aos riscos delimitadores das faixas de rodagem. Estes ponpon-tos, fornecidos em coordenadas do mundo, são usados pelo Integrador de Localiza¸cão para localizar o ve´ıculo na pista. São usadas técnicas de segmenta¸cão e análise de imagem de modo a

(32)

localizar na imagem as linhas da estrada e. com essa informa¸cão, obter a distância real do carro em rela¸cão a estas.

• O Perceptor de Sinais usa a imagem da cˆamara de sinal para, usando Template Matching[12], identificar qual o sinal mostrado no painel sinal´etico.

• Através do subsistema de controlo de baixo n´ıvel são recebidos os dados sensoriais relativos à odometria, aos sensores de obstáculos e aos sensores de chão. O Baixo N´ıvel é responsável por tratar as mensagens que transportam esses dados.

Decisão e Açcão

Com base na caracteriza¸cão do mundo (posi¸cão do ve´ıculo na pista, sinal afixado no painel semafórico e obstáculos existentes na pista) o bloco de Decisão e Actua¸cão decide qual a melhor estratégia para ultrapassar os desafios existentes e completar a pista. Esta decisão é efectuada com base num modelo de três camadas.

• Ao mais alto n´ıvel, o Decisor tem como principal objectivo escolher o papel a desem-penhar pelo robot. Esse papel est´a relacionado com a pista onde o robot se est´a a movimentar.

• O Papel é basicamente uma máquina de estados, onde cada estado representa um determinado comportamento que o robot deve executar para completar a pista. A mudan¸ca de estados ocorre em determinadas etapas da pista de modo a responder a cada desafio existente, como por exemplo, o estado “passar pelo túnel”, que implica ligar os faróis para se poder ver a estrada, “esperar pelo sinal”, que implica ficar parado na passadeira até que o sinal mude para verde, entre vários outros.

• Ao mais baixo n´ıvel estão os comportamentos básicos de movimenta¸cão do ve´ıculo (ca-mada Comportamento). Existem actualmente três comportamentos implementados: um que pára o robot, outro que conduz mantendo uma determinada distância constante `

a linha central da estrada, e finalmente o ´ultimo que segue um caminho definido por pontos de passagem colocados no mundo [13].

Da execu¸cão do comportamento resultam ordens de actua¸cão sobre a direçcão e traçcão do ve´ıculo.

2.3 Modela¸

c˜

ao e simula¸

c˜

ao em condu¸

c˜

ao aut´

onoma

A simula¸cão não é uma área nova, tendo sido utilizada ao longo dos tempos, maioritari-amente em cenários de guerra e conflito. Actualmente é usada em várias áreas distintas que vão desde a medicina até às ciências sociais [14]. Simula¸cão é um conceito que engloba 4 conceitos fundamentais, modela¸cão, simula¸cão, visualiza¸cão e análise, e é usada para obter conhecimento, validar modelos e experiências, treinar humanos, fornecer suporte à análise estat´ıstica, controlar processos em tempo real, prever potenciais resultados, testar e avaliar novos sistemas, e suporte a analises “what-if”.

Praticamente qualquer área pode usufruir das vantagens que a utiliza¸cão de uma simula¸cão oferece. Destacam-se a seguir algumas dessas vantagens:

(33)

• habilidade de escolher correctamente cada altera¸c˜ao ao sistema, testando todos os as-pectos de uma proposta de mudan¸ca sem comprometer recursos adicionais;

• comprimir e expandir tempo para permitir ao utilizador acelerar ou retardar compor-tamentos ou fen´omenos de modo a facilitar avalia¸c˜ao em profundidade;

• explorar possibilidades no contexto de pol´ıticas, procedimentos operacionais e m´etodos, sem perturbar o sistema real;

• diagnosticar problemas percebendo a interaçcão entre variáveis que fazem parte do sistema;

• desenvolver uma compreens˜ao do sistema observando como este opera em vez de prever como iria operar;

• investir de forma inteligente porque um estudo baseado num simulador tem um custo menor em rela¸c˜ao ao custo de mudar ou alterar o sistema actual.

Modelo é a representa¸cão ou aproxima¸cão de um evento ou objecto, real ou fict´ıcio. Sim-ula¸cão é a imita¸cão de uma opera¸cão de um processo ou sistema ao longo do tempo, ou seja, a execu¸cão do modelo num intervalo de tempo.

Ao construir-se uma versão virtual do mundo real, é essencial que se encontre uma maneira de o descrever utilizando um modelo matemático ou simbólico que possa ser codificado em software. Com o objectivo de encontrar este modelo é necessário um processo de aquisi¸cão de dados e análise do modelo em questão. O processo de aquisi¸cão de dados para a constru¸cão de um modelo requer muitas vezes que este seja feito por quem está a implementar o simulador, porque é importante que se perceba em primeira mão a razão pala qual uma simula¸cão é necessária e o que se pretende simular.

A visão humana é uma das melhores ferramentas de análise de dados existentes, e como tal o processo de cria¸cão de uma representa¸cão visual a partir dos dados da simula¸cão é uma aspecto importante em qualquer simula¸cão, uma vez que possibilita ao utilizador da simula¸cão fazer uma análise rápida e eficaz.

A interaçcão com o ambiente de simula¸cão, como para qualquer software que seja utilizado por um humano, é um aspecto fundamental, uma boa interface e usabilidade permite ao utilizador tirar o maior partido da simula¸cão e das ferramentas dispon´ıveis.

O ambiente de simula¸cão deverá reproduzir de forma realista a camada mecânica e sistema de visão do ve´ıculo de condu¸cão autónoma. Isto significa que para simular a camada mecânica terá de se simular todos os actuadores e sensores, o que inclui o próprio movimento do robot, que deverá ser realista. Para simular o sistema de visão deverá ser sintetizada o v´ıdeo produzido pelas câmara. Além da modela¸cão do ve´ıculo também é necessário modelar o espa¸co onde este se movimenta. Neste caso o espa¸co corresponde às provas de condu¸cão autónoma do FNR, e a modela¸cão irá incidir sobre os vários elementos que compõem cada prova, tais como obstáculos, zona de obras e túnel, que deverão obedecer às leis da f´ısica, por forma a detectar colisões, e reagir em conformidade.

Dos objectivos consta a inten¸cão de explorar o Bullet enquanto motor de simula¸cão de f´ısica. Consta também a necessidade de sintetizar as imagens capturadas pelas duas câmaras que equipam o ve´ıculo. Isto significa que o motor gráfico usado deverá produzir gráficos de alta qualidade por forma a reproduzir a qualidade do mundo real.

(34)

Dos motores de jogo open-source existentes que associam um motor gráfico com o Bullet (por exemplo o Crystal Space [15] e Game Blender [16]), o jMonkey destaca-se pelo seu desenvolvimento de ra´ız para suportar f´ısica, e em especial o suporte nativo para ve´ıculos, e as várias técnica avan¸cadas de rendering dispon´ıveis que permitem alcan¸car o realismo necessário.

2.4 jMonkey

O trabalho a realizar no âmbito da cria¸cão do ambiente de simula¸cão foca-se principal-mente na área de modela¸cão, visualiza¸cão e interaçcão, uma vez que a simula¸cão em si já existe. O Bullet oferece uma arquitectura de simula¸cão de ve´ıculos em que apenas é necessário especificar o número e posi¸cão das rodas para ter um ve´ıculo virtual pronto a usar. A visual-iza¸cão e interaçcão foi um aspecto importante neste caso porque como se trata da simula¸cão de um ve´ıculo autónomo, a visualiza¸cão do seu comportamento enquanto se movimenta é informa¸cão suficiente para que se fa¸ca análise e se retire uma conclusão.

2.4.1 Motor gr´afico

jMonkeyEngine é um motor de jogo 3D, open source, escrito 100% em Java, que aglomera várias bibliotecas as quais fornecem gráficos 3D e 2D, áudio, f´ısica, entre outros[17]. Criado em 2003, vai actualmente na sua 3a versão, integra de raiz com o motor de f´ısica jBullet, a versão do Bullet para Java, e o motor gráfico Lightweight Java Game Library1 (LWJGL), que permite o acesso em Java à biblioteca gráfica OpenGL2 (Open Graphics Library). O sistema gráfico foi constru´ıdo com base numa arquitectura de shaders, de forma a garantir a compatibilidade com a corrente e próxima gera¸cão de standards gráficos 3D, tendo já suporte a várias técnicas avan¸cadas para produ¸cão de imagens com elevado realismo (Shadow Map, Parallax Map, HDR, Ambient Oclusion, Depth of Field ).

O jMonkey funciona em qualquer sistema que consiga correr Java e que suporte o OpenGL 2.0. Actualmente possui um desenvolvimento activo e uma grande comunidade que apoia o projecto, tendo sido usado para criar projectos comerciais, como por exemplo o Urban Galax Online3, e projectos de investiga¸c˜ao, como por exemplo CARS – Configurable Automotive Research Simulator4.

2.4.2 Motor de F´ısica

A f´ısica no jMonkey é calculada com a ajuda da versão para Java do motor de f´ısica Bullet, o jBullet5. Além do cálculo de colisões e simula¸cão das leis do movimento que seria de esperar de qualquer motor de f´ısica, este motor já oferece um modelo de simula¸cão de ve´ıculos, que se baseia num modelo simplificado usado em vários jogos de condu¸cão comerciais.

Ao invés de utilizar juntas avan¸cadas e restri¸cões ao movimento de modo a simular a suspensão e as rodas e movimentar o carro de acordo com a sua direçcão, neste modelo o carro é representado por um único corpo r´ıgido, o chassis, que flutua em cima de quatro (dependendo

1 http://lwjgl.org/ 2 http://www.opengl.org/ 3_{http://www.urbangalaxyonline.com/} 4 http://cars.pcuie.uni-due.de/ 5_{http://jbullet.advel.cz/}

(35)

a

c

b

Figura 2.8: Calculo da suspensão. a: ponto de origem do raio. b: ponto de colisão com o chão. c: centro da roda, dado pela diferen¸ca entre o ponto de colisão e o raio da roda.

do número de rodas) raios imaginários [18]. Estes raios são lan¸cados verticalmente em direçcão ao chão a partir da localiza¸cão de cada uma das rodas, mais especificamente da posi¸cão onde a suspensão encaixa no chassis e o ponto de interseçcão entre o raio e o chão será usado para calcular a suspensão. A compressão da suspensão, vis´ıvel na Figura 2.8, é dada pela diferen¸ca entre o comprimento original da suspensão e o comprimento actual, ou seja, distância de a) a c) e daqui resulta a for¸ca que será aplicada ao chassis do carro, que o impede de colidir com o chão. Caso a distância do raio seja maior que a soma de distância da suspensão e o raio da roda, indica que a roda do carro não está em contacto com o chão e portanto não existe friçcão.

Além da suspensão são aplicadas mais duas for¸cas ao chassis, uma for¸ca lateral e uma for¸ca longitudinal, relacionadas directamente com as rodas em si e que fazem o carro movimentar-se. Estas for¸cas são calculadas para cada roda que está em contacto com o chão, tendo em conta a friçcão, o torque e direçcão da roda, sendo posteriormente aplicadas ao chassis.

(36)

(37)

Cap´ıtulo 3

Simulador

3.1 Introdu¸

c˜

ao

Existem dois mundos no jMonkey, o mundo visual e o mundo f´ısico. O mundo visual é o que é capturado pelas câmaras, o que contém todos os objectos vis´ıveis, e no jMonkey, tal como muitos outros motores gráficos, a visualiza¸cão deste mundo (rendering) é realizado com base num ciclo infinito que é composto por três fases:

1a fase – actualiza¸c˜ao do mundo, todos os objectos s˜ao preparados e posicionados correcta-mente.

2a fase – rendering da cena, o sistema gr´afico desenha a imagem vista por cada uma das cˆamara activas.

3a fase – p´os-processamento, onde as imagens criadas anteriormente s˜ao retiradas e algum processamento sobre elas pode ser efectuado.

Este ciclo pode ser executado sem interrup¸cões, ou seja, executado à velocidade máxima que o sistema suporta, ou com pausas de modo a obter um número de imagem por segundo (fps) constante.

O mundo f´ısico funciona de forma diferente. O seu ciclo de actualiza¸cão é constante (60 fps) e independente do ciclo visual. O mundo f´ısico impõe certas regras; aqui todos os objectos possuem massa e estão sujeitos à for¸ca gravitacional, cada objecto colide com todos os outros, e dois objectos não podem ocupar o mesmo espa¸co f´ısico. Este mundo é governado pelas leis da f´ısica.

Existe a possibilidade de criar uma liga¸cão entre um objecto f´ısico e um objecto vis´ıvel, o que na prática significa dar propriedades f´ısicas a um objecto vis´ıvel, ou vice-versa, dar uma representa¸cão visual a um objecto f´ısico. O objecto f´ısico e o vis´ıvel não têm de ser iguais, pelo contrario, até é prefer´ıvel que sejam diferentes, isto porque objectos simples como caixas, esferas, cilindros e cápsulas possuem fórmulas simples e eficientes para calcular as colisões entre si, enquanto que objectos mais complexos, côncavos e compostos por vários triângulos obrigam a fórmulas mais complexas e que demoram mais tempo a calcular. Por esta razão é que sempre que poss´ıvel os objectos vis´ıveis são representados no mundo f´ısico por aproxima¸cões usando objectos simples. Por exemplo, a representa¸cão do robot no mundo f´ısico e visual são bastante diferentes, como já foi referido, e tal pode ser observado na Figura 3.1. O chassis do robot que reúne vário componentes, de entre os quais as câmaras e respectivos

(38)

Figura 3.1: Representa¸cão f´ısica e visual do ve´ıculo. A esquerda o carro ´` e representado fisicamente por um caixa que corresponde ao chassis e três raios imaginários que sustentam o chassis e que correspondem às rodas; à direita a representa¸cão visual dos mesmos elementos.

suportes, não se assemelham a uma caixa. Contudo o objectivo neste simulador é detectar as colisões do robot com obstáculos, e estas colisões acontecem sempre na parte frontal ou lateral, nunca na parte superior, portanto, dado a silhueta do robot é seguro utilizar um caixa como aproxima¸cão sem que exista grande perda de fidelidade.

Como o mundo visual impõe que os objectos só sejam alterados na primeira fase e a f´ısica funciona de forma independente, a sincroniza¸cão dos objectos vis´ıveis que têm uma correspondência no mundo f´ısico só acontece durante a primeira fase. Basicamente o ciclo de actualiza¸cão do mundo visual ”governa/dita”a execu¸cão de todo o simulador, e de modo a inserir todo o conceito de sensores/actuadores neste ciclo estabeleceu-se que durante a primeira fase as ordens para os actuadores são processadas e executadas, e durante a terceira fase a informa¸cão dos sensores é recolhida e enviada para o software.

3.2 Modela¸

c˜

ao do ambiente

O ambiente no qual o ve´ıculo se movimenta no simulador tenta recriar com o m´aximo de fidelidade a realidade do FNR. Cada um dos elementos que comp˜oem cada prova foi criado de acordo com o regulamento do concurso.

3.2.1 Modela¸c˜ao da Pista

(39)

Figura 3.2: Representa¸c˜ao da pista do FNR no simulador.

A imagem que é aplicada ao plano tem o nome de textura e normalmente num motor grafico 3D as texturas são carregadas a partir de ficheiros de imagem (jpg,bmp,raw) e aplicadas ao objectos 3D durante o rendering da cena. No nosso caso o simulador tem de ser flex´ıvel o suficiente para permitir o uso de diferentes pistas de diferentes tamanhos, e por consequências, diferentes texturas.

Na arquitectura usada pelo robot, uma pista é descrita com base em 3 elementos básicos: Recta, Curva e Passadeira. Em conjunto, estes elementos permitem descrever a maioria das configura¸cões poss´ıveis de uma pista, em especial a pista do FNR. Como se pode ver na Figura 3.3 existem ao todo 7 seçcões diferentes nessa pista, havendo sobreposi¸cão entre elas.

Figura 3.3: Pista do FNR dividida por sec¸c˜oes.

A descri¸cão da pista é feita a partir de um ficheiro de configura¸cão em formato texto, onde para cada seçcão é enumerado cada um dos seus atributos, e os valores que estes tomam, como se pode ver no exemplo 3.1.

(40)

1 Type = S t r i n g; // t i p o de s e c ¸c ˜a o : ”CROSSWALK” , ”STRAIGHT” , ”CURVE”

2 Name = S t r i n g; //nome p e l o q u a l v a i s e r i d e n t i f i c a d a , ex : ” Recta 1 ” , ” Curva

Esquerda ” 3 C o o r d i n a t e s : // c o o r d e n a d a s da p o s i ¸c ã o 4 { 5 X = i n t; // p o s i ¸c ã o X em m i l i m e t r o s do i n ´ı c i o da s e c ¸c ã o 6 Y = i n t; // p o s i ¸c ã o Y em m i l i m e t r o s do i n ´ı c i o da s e c ¸c ã o 7 t h e t a = f l o a t; // r o t a ¸c ã o h o r i z o n t a l em r a d i a n o s 8 } ; 9 D i m e n s i o n s : // dimens õ e s 10 {

11 Width = f l o a t; // comprimento do a r c o em r a d i a n o s p a r a o c a s o da ”CURVE

” , comprimento em m i l i m e t r o s p a r a o s o u t r o s c a s o s 12 Length = i n t; // l a r g u r a em m i l i m e t r o s 13 } ; 14 Radius = i n t; // r a i o da curva , ( o s e u s i n a l i n d i c a a d i r e c ¸c ã o ) , s ó s e a p l i c a a s e c ¸c õ e s do t i p o ”CURVE” 15 16 17 L e f t L i n e = ( // l i s t a de d e f i n i ¸c õ e s que formam a l i n h a e s q u e r d a 18 { 19 t y p e = S t r i n g // t i p o de l i n h a , p r e v i a m e n t e d e f i n i d o n a s L i n e s ( ) 20 s t a r t = f l o a t; // i n ´ı c i o da l i n h a em r e l a ¸c ã o à s e c ¸c ão , em p e r c e n t a g e m ( 0 . 0 − 1 . 0 ) 21 end = f l o a t; // f i n a l da l i n h a em r e l a ¸c ã o à s e c ¸c ão , em p e r c e n t a g e m ( 0 . 0 − 1 . 0 ) 22 p h a s e = f l o a t; // o f f s e t p a r a come ¸c a r o padr ã o ( P a t t e r n ) , s ó é u t i l i z a d o em l i n h a s do t i p o ”DASHED” 23 } 24 ) ; 25 26 C e n t e r L i n e = ( // l i s t a de d e f i n i ¸c õ e s que formam a l i n h a c e n t r a l 27 { 28 t y p e = S t r i n g // t i p o de l i n h a , p r e v i a m e n t e d e f i n i d o n a s L i n e s ( ) 29 s t a r t = f l o a t; // i n ´ı c i o da l i n h a em r e l a ¸c ã o à s e c ¸c ão , em p e r c e n t a g e m ( 0 . 0 − 1 . 0 ) 30 end = f l o a t; // f i n a l da l i n h a em r e l a ¸c ã o à s e c ¸c ão , em p e r c e n t a g e m ( 0 . 0 − 1 . 0 ) 31 p h a s e = f l o a t; // o f f s e t p a r a come ¸c a r o padr ã o ( P a t t e r n ) , s ó é u t i l i z a d o em l i n h a s do t i p o ”DASHED” 32 } 33 ) ; 34 35 R i g h t L i n e = ( // l i s t a de d e f i n i ¸c õ e s que formam a l i n h a d i r e i t a 36 { 37 t y p e = S t r i n g // t i p o de l i n h a , p r e v i a m e n t e d e f i n i d o n a s L i n e s ( ) 38 s t a r t = f l o a t; // i n ´ı c i o da l i n h a em r e l a ¸c ã o à s e c ¸c ão , em p e r c e n t a g e m ( 0 . 0 − 1 . 0 ) 39 end = f l o a t; // f i n a l da l i n h a em r e l a ¸c ã o à s e c ¸c ão , em p e r c e n t a g e m ( 0 . 0 − 1 . 0 ) 40 p h a s e = f l o a t; // o f f s e t p a r a come ¸c a r o padr ã o ( P a t t e r n ) , s ó é u t i l i z a d o em l i n h a s do t i p o ”DASHED” 41 } 42 ) ;

(41)

1 Type = S t r i n g; // t i p o de l i n h a : ”DASHED” , ” SOLID”

2 Name = S t r i n g; //nome p e l o q u a l v a i s e r i d e n t i f i c a d o ex : ” l i n h a

c o n t i n u a ” , ” l i n h a t r a c e j a d a ”

3 Width = i n t; // l a r g u r a da l i n h a em m i l i m e t r o s

4 P a t t e r n = {i n t ,i n t , . . . } // padr ˜a o a l t e r n a d o que d e f i n e a l i n h a do t i p o ”

DASHED” , ex : { 8 0 0 , 1 0 0 } c r i a uma l i n h a c o n t i n u a com 800mm s e g u i d a de 100mm v a z i o , r e p e t i n d o i n f i n i t a m e n t e

Listing 3.2: Linguagem de descri¸c˜ao das linhas da pista.

Este ficheiro era originalmente usado pelo robot, permitindo-lhe conhecer as caracter´ısticas da pista que estava a percorrer, mas como a informa¸cão lá existente é suficiente para criar a textura da pista para o simulador decidiu-se reutilizar este ficheiro para desenhar a pista, como alternativa à cria¸cão de um ficheiro adicional com uma nova linguagem de descri¸cão.

Para criar a pista de uma maneira eficiente foi desenvolvida uma aplica¸cão gráfica em Java que permitisse abrir, visualizar, criar e guardar ficheiros deste tipo. Esta aplica¸cão faz uso da biblioteca gráfica 2D do java para desenhar a pista, utilizando arcos e rectângulos e várias transforma¸cões 2D (escala, transla¸cão e rota¸cão) de forma a atingir o objectivo de desenhar cada uma das seçcões. A aplica¸cão permite interagir com cada seçcão de forma directa, dando a possibilidade de arrastar ou alterar qualquer um dos seus atributos e mostrar o resultado em tempo real.

Figura 3.4: Programa de edi¸c˜ao da pista.

A figura 3.4 mostra este programa de edi¸cão como uma interface dividida em duas regiões. No centro é representada a visualiza¸cão 2D da pista centrada na origem e no painel direito são apresentadas todas as propriedades da seçcão actualmente seleccionada. Para facilitar a constru¸cão da pista cada seçcão possui uma circunferência que indica o ponto de origem e outra que indica o ponto final, isto para a possibilidade de “snap” de seçcões, que consiste em

(42)

fundir o final de uma seçcão com a origem de outra que esteja relativamente perto, facilitando o processo de posicionamento das seçcões sem a existência de lacunas entre estas. A utiliza¸cão de uma cor aleatória para cada seçcão tem como finalidade facilitar a distin¸cão entre seçcões. Para além de permitir construir a pista, o 2o _{objectivo desta aplica¸}_c˜_{ao ´}_{e fornecer ao} sim-ulador uma forma de criar a textura da pista a partir do ficheiro de texto. Desta forma não é necessário estar a criar ficheiros de imagem adicionais, uma vez que a imagem é automati-camente criada em memória quando se lan¸ca o simulador, e posteriormente copiada para o motor 3D para este desenhar a cena 3D.

As regras do FNR especificam que “O chão da pista é preto e absorve infravermelho. As linhas laterais são brancas e reflectem infravermelhos”, contudo isto não é totalmente verdade, uma vez que é usada uma alcatifa preta como pista, que possui um padrão derivado do tecido, o qual se vai degradando ao longo do concurso por causa dos participantes. Isto significa que, de modo a ter um maior realismo, a textura criada a partir do ficheiro de texto terá que emular o ru´ıdo que a pista real apresenta, ru´ıdo este de dois tipos diferentes; um uniforme que afecta toda a pista derivado do tecido da alcatifa, e um aleatório provocado pelas pegadas dos participantes e o desgaste causado pelos robots.

Como o ru´ıdo apresenta um padrão bem definido, não pode ser facilmente emulado por fórmulas matemáticas de ru´ıdo, como por exemplo ru´ıdo Gaussiano. É necessário utilizar representa¸cões em formato de imagem e combiná-las para chegar ao resultado final. Existem várias técnicas eficientes para misturar diferentes texturas com cores e padrões diferentes que conseguem manter o detalhe e criar uma textura única através do uso de zonas de interesse em cada textura e interpola¸cão usando uma distribui¸cão de Poisson[19]. Contudo neste caso estamos a trabalhar com um problema concreto, que consiste em misturar uma textura a tons de cinzento de modo a criar ru´ıdo, em que a textura base é preta e o ru´ıdo é branco. Com isto em mente a solu¸cão encontrada para resolver este problema assenta em duas fases distintas que produzem duas texturas que são posteriormente interpoladas com a textura base.

Ru´ıdo base

Esta fase consiste na adi¸cão de ru´ıdo uniforme à pista de forma a simular o padrão do tecido usado. Para tal são usadas duas amostras de tamanhos diferentes que são replicadas de modo a cobrirem toda a pista. O processo de replica¸cão de apenas uma textura cria um padrão que se repete e que é evidente. Para combater este efeito são utilizadas duas amostras de diferentes tamanhos, onde a interpola¸cão das duas amostras replicadas reduz a probabilidade de ocorrência de padrões, criando uma textura única.

O resultado final da interpola¸cão das duas amostras será aplicado às zonas pretas da textura base, criando assim uma textura mais realista.

(43)

a) b)

Figura 3.5: Ru´ıdo base. a: amostras utilizadas b: resultado do processo de replica¸c˜ao e interpola¸c˜ao.

Ru´ıdo aleat´orio

Ao longo dos dias do FNR a pista está constantemente em uso, os participantes tentam aproveitar ao máximo o tempo que têm antes das provas para fazer testes e afinar os robots, e isto provoca um desgaste na alcatifa que vai piorando ao longo do tempo. Este desgaste é derivado das pegadas deixadas pelos participantes e público que vai assistir, e das rodas dos robots que percorrem a pista. Por forma a simular este desgaste basta espalhar pela textura amostras de imagens que representam este tipo de desgaste, com posi¸cão e rota¸cão aleatória.

a) b)

Figura 3.6: Ru´ıdo aleatório. a: amostras que se assemelham ao desgaste causado pelos participantes e robots b: resultado do processo de coloca¸cão aleatório.

Após estas duas fases combinam-se as 3 imagens, a textura base, o ru´ıdo uniforme e o ru´ıdo aleatório, utilizando uma media aritmética e obtém-se uma textura de elevado detalhe e realismo pronta a ser utilizada. Contudo existe ainda mais um problema. No simulador a pista é simulada por um plano liso, no mundo real a pista é uma alcatifa com relevos e depressões, logo, para atingir o realismo requerido é necessário encontrar uma forma de deformar o plano 3D para que este também apresente relevos e que esses relevos sejam coerentes com a textura. Isto deixa-nos com dois caminhos poss´ıveis, ou se altera a geometria da pista de modo a coincidir com a textura, ou se utiliza ilusões de visualiza¸cão para simular os relevos, mantendo a geometria como está. A primeira op¸cão não é viável, uma vez que o detalhe que a geometria teria de ter seria tão elevado que o impacto na performance seria insuportável. Consequentemente utilizou-se a op¸cão de ilusão para simular os relevos. O jMonkey oferece

(44)

duas técnicas distintas para adicionar detalhe (relevos) a objectos 3D, Parallax Mapping e Normal Mapping. Ambos têm um impacto m´ınimo na performance e baseiam-se na utiliza¸cão de mapas (imagens 2D) que armazenam a deforma¸cão a aplicar ao objecto 3D em causa e utilizam truques de ilumina¸cão para dar a sensa¸cão de profundidade. O Parallax Mapping é uma técnica normalmente usada para representar deforma¸cões profundas como é o caso das pedras numa muralha ou numa cal¸cada, enquanto o Normal Mapping é mais eficaz na representa¸cão de pequenos detalhes, sendo portanto a técnica escolhida para aplicar à pista. A ilumina¸cão de um dado ponto num objecto 3D depende da orienta¸cão da superf´ıcie em rela¸cão à direçcão da fonte luminosa. Uma superf´ıcie que é perpendicular à direçcão da luz é mais iluminada que uma superf´ıcie com igual área mas obl´ıqua. Portanto a ilumina¸cão de uma superf´ıcie é dada pelo ângulo entre os raios luminosos e a orienta¸cão da superf´ıcie, conhecida como normal. A normal é um vector que indica a orienta¸cão de uma dada superf´ıcie, e por defini¸cão, é perpendicular a essa superf´ıcie [20].

Figura 3.7: Cálculo da ilumina¸cão difusa. A ilumina¸cão de uma superf´ıcie é dado pelo ˆ

angulo entre a direçcão da fonte de luz L e a normal à superf´ıcie N.

O Normal Mapping baseia-se na altera¸cão do vector normal de forma a alterar a ilumina¸cão da superf´ıcie, criando zonas mais escuras e outras mais claras, imitando a ilumina¸cão dos relevos. As coordenadas dos vectores normais são armazenadas numa imagem 2D, onde o valor de cada pixel RGB no intervalo [0 - 255] corresponde às coordenadas XYZ no intervalo [-1.0 – 1.0] do vector unitário que representa a normal.

Esta é uma técnica usada muitas vezes na produ¸cão de jogos 3D, onde são criados objectos de elevada qualidade, com um elevado número de superf´ıcies. Em seguida é criado um mapa a partir desse objecto para guardar o detalhe em vectores normais. O objecto é de seguida optimizado de modo a remover a maior parte das superf´ıcies, e no final é utilizado o mapa criado anteriormente neste objecto de reduzida qualidade, restaurando o detalhe e obtendo um resultado final semelhante ao original, mas com uma fraçcão do processamento necessário para o desenhar no ecrã [21].

(45)

a) b) c)

Figura 3.8: Exemplo do uso de Normal Mapping. Usando o mapa b) na esfera a) obtém-se o efeito em c). De referir que apesar dos relevos vis´ıveis, a esfera mantém a mesma forma. Os relevos são apenas ilusões de ilumina¸cão, como se pode verificar pelo contorno da esfera que continua inalterado.

A cria¸cão do mapa RGB para Normal Mapping é baseada na textura da pista com ru´ıdo, assumindo que o relevo da pista é dado pela intensidade de cada pixel, onde o preto significa nenhuma altera¸cão, e o branco a altura máxima. É usado um operador de Sobel em x e em y de modo a calcular a direçcão do gradiente da textura e criar o vector que dará origem `

a componente RGB do mapa. A magnitude x representa a componente R, a magnitude y representa G e B ´e um parˆametro que regula a intensidade geral do relevo.

a) b) c) d)

Figura 3.9: Conversão de uma textura em tons de cinzento para um mapa de NormalMapping. a: textura com ru´ıdo. b: resultado do operador de Sobel em X, onde os contornos verticais são identificados. c: resultado do operador de Sobel em Y, onde os contornos horizontais são identificados. d: resultado da conversão de b) e c) para um mapa normal, convertendo b) para vermelho e c) para verde, mantendo o azul constante.

No final de todo este processo obtém-se uma textura que representa a pista com ru´ıdo realista, e um mapa de relevo que altera a forma como a luz interage com a pista dando a ilusão da existência de relevos e depressões.

(46)

a) b) c)

Figura 3.10: Fases de constru¸cão da textura da pista. a: 1a fase, a textura é constru´ıda com base no ficheiro de configura¸cão. b: 2a fase, é adicionado ru´ıdo à textura. c: 3a fase, adicionado relevos através de Normal Mapping.

3.2.2 Modela¸c˜ao dos elementos

Após ter a pista criada na cena é necessário povoá-la com os restantes elementos que compõem cada uma das provas do FNR. Tal como é o caso da pista, estes elementos também têm um ficheiro de texto que indicam os seus atributos e posi¸cão, tendo como principal diferen¸ca em rela¸cão ao ficheiro de configura¸cão da pista o facto de este ficheiro estar associado a uma pista, uma vez que a posi¸cão dos elementos só faz sentido para uma determinada pista. Isto significa que uma pista pode ter zero ou mais ficheiros de configura¸cão dos elementos que a povoam, que é o que acontece na realidade. Por exemplo, a prova do FNR tem 3 mangas, sendo que em cada uma a pista é igual, mas os elementos são diferentes. A linguagem de configura¸cão dos elementos é a mesma que da pista para manter a compatibilidade com o software do robot e possibilitar a utiliza¸cão no futuro deste ficheiro para oferecer mais informa¸cão ao robot sobre o ambiente que está a percorrer.

Obst´aculo

O obstáculo é simulado por uma caixa r´ıgida, com 1 kg de massa e com uma textura verde de modo a assemelhar-se com os obstáculos usados normalmente na competi¸cão.

(47)

Figura 3.11: Representa¸cão do obstáculo no simulador. 1 Name = S t r i n g; //nome do o b s t á c u l o 2 P o s i t i o n : // p o s i ¸c ã o g l o b a l na p i s t a 3 { 4 X = i n t; // p o s i ¸c ã o X em m i l i m e t r o s 5 Y = i n t; // p o s i ¸c ã o Y em m i l i m e t r o s 6 Z = i n t; // p o s i ¸c ã o Z em m i l i m e t r o s 7 } ; 8 R o t a t i o n : // r o t a ¸c ã o 9 { 10 Yaw = f l o a t; // r o t a ¸c ã o CCW em r a d i a n o s em t o r n o do e i x o X 11 R o l l = f l o a t; // r o t a ¸c ã o CCW em r a d i a n o s em t o r n o do e i x o Y 12 P i t c h = f l o a t; // r o t a ¸c ã o CCW em r a d i a n o s em t o r n o do e i x o Z 13 } ; 14 H a l f E x t e n d s : // dimens ã o 15 { 16 X = i n t; // e x t e n s ã o X em r e l a ¸c ã o ao c e n t r o , em m i l i m e t r o s 17 Y = i n t; // e x t e n s ã o Y em r e l a ¸c ã o ao c e n t r o , em m i l i m e t r o s 18 Z = i n t; // e x t e n s ã o Z em r e l a ¸c ã o ao c e n t r o , em m i l i m e t r o s 19 } ;

Listing 3.3: Linguagem de descri¸c˜ao do obst´aculo. ´

E importante referir que a coloca¸cão de obstáculos deve ter em aten¸cão poss´ıveis colisões, os obstáculos não devem intersectar outros objectos f´ısicos, como por exemplo o chão, tendo como consequência a poss´ıvel instabilidade da simula¸cão. Estes devem ser colocados ligeira-mente acima do chão e, assim que a simula¸cão inicia, a f´ısica toma controlo e o obstáculo cai no chão.

Parque de estacionamento

O parque de estacionamento é um plano que flutua mil´ımetros acima da pista, dando a sensa¸cão de que faz parte da pista e ao mesmo tempo possibilitando a fácil mudan¸ca de

(48)

posi¸cão entre testes, tal como acontece no FNR onde o parque é apenas um peda¸co de alcatifa do mesmo tipo que a da pista, que é alterada de posi¸cão em cada prova.

Figura 3.12: Representa¸c˜ao do parque de estacionamento no simulador.

... 1 Name = S t r i n g; //nome do p a r q u e 2 C o o r d i n a t e s : // c o o r d e n a d a s da p o s i ¸c ã o g l o b a l na p i s t a 3 { 4 X = i n t; // p o s i ¸c ã o X em m i l i m e t r o s 5 Y = i n t; // p o s i ¸c ã o Y em m i l i m e t r o s 6 t h e t a = f l o a t; // r o t a ¸c ã o h o r i z o n t a l em r a d i a n o s 7 } ;

Listing 3.4: Linguagem de descri¸c˜ao do parque de estacionamento.

O parque de estacionamento ´e sempre posicionado `a mesma altura Z.

´

Area de manuten¸c˜ao

A área de manuten¸cão é formada por duas linhas de cones, sendo que cada dois cones consecutivos estão ligados por uma fita. Os cones são representados por um modelo f´ısico que tenta imitar ao máximo a realidade, possuem 0,3 kg de massa e a fita que os liga não tem correspondência f´ısica, sendo apenas algo visual.