Estudo comparativo dos softwares de simulação para carros autônomos CARLA e Udacity

(1)

Universidade Federal Fluminense

Escola de Engenharia

Curso de Gradua¸

c˜

ao em Engenharia de

Telecomunica¸

c˜

oes

Carlos Eduardo de Almeida Bonon

Estudo comparativo dos softwares de simula¸c˜

ao para

carros autˆ

onomos CARLA e Udacity

Niter´

oi – RJ

2019

(2)

1 Carlos Eduardo de Almeida Bonon

Estudo comparativo dos softwares de simula¸c˜ao para carros autˆonomos CARLA e Udacity

Trabalho de Conclusão de Curso apresentado ao Curso de Gradua¸cão em Engenharia de Teleco-munica¸cões da Universidade Federal Fluminense, como requisito parcial para obten¸cão do Grau de Engenheiro de Telecomunica¸cões.

Orientador: Prof. Dr. Jo˜ao Marcos Meirelles da Silva

Niter´oi – RJ 2019

(3)

ii .

(4)

iii Carlos Eduardo de Almeida Bonon

Estudo comparativo dos softwares de simula¸c˜ao para carros autˆonomos CARLA e Udacity

Trabalho de Conclusão de Curso apresentado ao Curso de Gradua¸cão em Engenharia de Teleco-munica¸cões da Universidade Federal Fluminense, como requisito parcial para obten¸cão do Grau de Engenheiro de Telecomunica¸cões.

Aprovada em 25 de Novembro de 2019.

BANCA EXAMINADORA

Prof. Dr. Jo˜ao Marcos Meirelles da Silva - Orientador Universidade Federal Fluminese - UFF

Profa. Dra. Natalia Castro Fernandes Universidade Federal Fluminense - UFF

Prof. Dr. Vitor Hugo Ferreira Universidade Federal Fluminense - UFF

Niter´oi – RJ 2019

(5)

iv

Resumo

A grande maioria dos acidentes de trânsito podem ser evitados, não fosse a imprudência dos condutores. Solu¸cões de automa¸cão, inteligência artificial e IoT para carros autˆ o-nomos já se encontram em estudo e desenvolvimento, como visto nos artigos usados no estudo deste trabalho. Neste trabalho, foram abordados os conceitos de aprendizado de máquina e comunica¸cão entre sensores dentro de duas ferramentas de simula¸cão para ve´ıculos autônomos dispon´ıveis no mercado, CARLA e Udacity. Levando em conta as caracter´ısticas individuais de cada ferramenta, este trabalho abordou os aspectos de pro-cessamento de imagens com técnicas de aprendizado por refor¸co e técnicas de aprendizado supervisionado. A partir das experiências reunidas neste trabalho, foi poss´ıvel elaborar uma s´ıntese dos pontos fortes e fracos de cada ferramenta dentro de suas propostas através da avalia¸cão de desempenho e verifica¸cão da acurácia dos modelos desenvolvidos dentro das ferramentas, juntamente com os resultados obtidos no decorrer no desenvolvimento e teste deste trabalho, formando assim uma tabela de análise resumindo os resultados obtidos dentro de critérios escolhidos para medir performance, com o intuito de ajudar iniciantes em uma aplica¸cão dentro desta área e documentar os resultados e pontos fortes e fracos das análises relativas a cada modelo.

Palavras-chave: Aprendizado de M´aquina. Aprendizado por Refor¸co. Redes Neu-rais Artificiais. Processamento de Imagens. CARLA Simulator. Udacity Simulator. Ve´ıculos Autˆonomos.

(6)

v

Abstract

It is common knowledge that most of car accidents could be avoided if the drivers we-ren’t reckless. Solutions involving automation, machine learning and internet of things in autonomous cars are current studied and in development phase. However, there is still a big gap when it comes to having access to a development tool that may aid in creating those solutions. Besides only existing a few tools, not all of them are accessible or easy to understand and deploy applications. Having a development tool that is self-explanatory and easy to deploy is an ambitious proposal but also a necessary one. In this paper, the goal is to understand and test machine learning solutions and sensor communication in two of tools that are available in the market, CARLA and Udacity. Taking each tool’s characteristics into consideration, image processing and recognition solutions using rein-forcement learning and supervised learning were proposed. Next, a compilation with the experience was created, along with the resultant feedback. Finally, it was possible to create a summary with each tool’s strengths and weaknesses in order to aid those that choose to start to develop an application in this field.

Keywords: Machine Learning. Reinforcement Learning. Artificial Neural Networks. Image Processing. CARLA Simulator. Udacity Simulator. Autonomous Driving

(7)

vi

Dedico este trabalho aos meus pais, os pilares da minha vida.

(8)

vii

Agradecimentos

Agrade¸co primeiramente aos meus pais. Sem vocˆes nada aconteceria. `

A minha companheira, Luisa Jorge Souza, por toda a paciência, disponibilidade e suporte nas horas cr´ıticas, os quais foram essenciais para que esse trabalho ficasse pronto. Ao professor João Marcos, pela incr´ıvel confian¸ca, disponibilidade para passar seus ensinamentos e empolga¸cão em trabalharmos juntos.

Ao meu grande amigo e mentor em an´alise de dados, Hugo Siqueira Gomes, por todo o empenho em me passar seus conhecimentos e sempre estar dispon´ıvel para debater e discutir ideias.

Ao LATELCO por toda a estrutura fornecida.

A todos os professores da UFF, em especial aos professores do departamento de Telecomunica¸cões, Elétrica, Estat´ıstica e Computa¸cão.

`

A banca examinadora: Professores Jo˜ao Marcos Meirelles, Vitor Hugo Ferreira e Natalia Castro Fernandes.

(9)

viii

Lista de Figuras

2.1 Intera¸c˜ao agente-ambiente em uma MDP. Fonte [6] . . . 8

2.2 Representa¸cão Simplificada de um neurônio matemático. Fonte [9] . . . 10

2.3 Exemplos de fun¸c˜oes de ativa¸c˜ao. Fonte [17] . . . 11

2.4 Exemplo de uma rede neural. Fonte [9] . . . 11

2.5 Redes neurais artificiais com uma camada e com m´ultiplas camadas escon-didas. Fonte [9] . . . 13

2.6 Filtro sendo aplicado em uma imagem RGB. Fonte [21] . . . 14

3.1 Imagem gerada pelo sensor do CARLA versus imagem p´os-processamento. 19 3.2 Arquivo gerado com dados sobre angula¸c˜ao do volante e seus quadros cor-respondentes. . . 20

3.3 Histograma com ˆangulos do volante. . . 23

3.4 Imagens das cˆameras central e lateral direita durante uma curva. . . 24

3.5 Histograma com angula¸c˜ao do volante ap´os tratamentos . . . 24

3.6 Arquitetura da rede neural do projeto da NVIDIA. Fonte: [10] . . . 25

3.7 Inspe¸c˜ao de performance em mais de 60 modelos diferentes. . . 26

3.8 Foco nos modelos com menor valor de perda e convergˆencia mais r´apida escolhidos para a fase de teste. . . 26

(10)

ix

Lista de Tabelas

(11)

Lista de Abrevia¸

c˜

oes

V2V Vehicle to Vehicle CARLA Car Learning to Act

API Application Programming Interface CNN Convolutional Neural Networks GPU Graphic Processing Unit

TORCS The Open Racing Car Game MPD Markov Decision Process

FMDP Finite Markov Decision Process RGB Red Green Blue

CSV Comma Separated Value RAM Random Access Memory ReLU Rectified Linear Unit

CUDA Compute Unified Device Architecture

(12)

Sum´

ario

Resumo iv

Abstract v

Agradecimentos vii

Lista de Figuras viii

Lista de Tabelas ix

1 Apresenta¸c˜ao 1

1.1 Introdu¸c˜ao . . . 1

1.2 Motiva¸c˜ao . . . 2

1.3 Objetivos . . . 2

1.4 Revis˜ao Bibliogr´afica . . . 3

2 Conceitos Básicos de Aprendizado de Máquina 5 2.1 Aprendizado de Máquina . . . 5

2.1.1 Aprendizado Supervisionado . . . 6

2.1.2 Aprendizado por Refor¸co . . . 6

2.1.3 Redes Neurais Artificiais . . . 10

2.1.4 Aprendizado Profundo . . . 12

3 Estudos de caso 16 3.1 As ferramentas . . . 16

3.1.1 CARLA . . . 16

3.1.2 Udacity . . . 16

3.2 Aprendizado por refor¸co no CARLA . . . 17 xi

(13)

xii

3.2.1 Aquisi¸c˜ao de dados . . . 17

3.2.2 Atua¸c˜ao do agente . . . 19

3.2.3 Resultados . . . 21

3.3 Aprendizado Supervisionado na Udacity . . . 22

3.3.1 Aquisi¸c˜ao de dados . . . 22

3.3.2 Prepara¸c˜ao dos dados . . . 23

3.3.3 Escolha do modelo e treinamento . . . 24

3.3.4 Resultados . . . 27

3.4 Compara¸c˜ao dos Resultados . . . 28

3.4.1 Descri¸c˜ao das Pontua¸c˜oes . . . 29

4 Conclus˜ao 31

5 Sugest˜oes para trabalhos futuros 33

(14)

Cap´ıtulo 1

Apresenta¸

c˜

ao

1.1 Introdu¸

c˜

ao

O número de mortes decorridas de acidentes no trânsito é um problema alarmante não só no Brasil como no restante do mundo. Desde que os automóveis se tornaram bens de consumo mais populares, o número de usuários cresceu abruptamente, juntamente com o número de acidentes fatais e não-fatais ocorridos com automóveis. De acordo com o Conselho Federal de Medicina, a cada uma hora, cinco pessoas morrem em acidentes de trânsito no Brasil [1].

Em 2017, o Brasil alcan¸cou a marca de um automóvel para cada quatro habitantes e, no presente, o automóvel se mantém como escolha principal de meio de transporte dos brasileiros [2].

Uma proposta que se apresenta como a grande solucionadora para o número alto de acidentes de trânsito é o carro autônomo. Ao introduzir esse novo conceito, é poss´ıvel eliminar alguns fatores, tais como: imprudência no trânsito, condu¸cão sob influência de entorpecentes, dentre outros.

´

E poss´ıvel descrever um carro autônomo como a combina¸cão de tecnologias como Internet das Coisas, Inteligência Artificial e Automa¸cão.

A grande atua¸cão de algoritmos de aprendizado de máquina em carros autônomos se encontra principalmente no reconhecimento de imagens e na deteçcão de anomalias [3]. Em paralelo aos avan¸cos obtidos em carros autônomos, um paradigma de aprendi-zado de máquina ganhou importância atualmente e se mostra como uma nova abordagem de solu¸cão de problemas: o aprendizado por refor¸co.

(15)

Com o seu método caracter´ıstico de intera¸cão de um agente com o meio ambiente, esse paradigma se tornou disruptivo e se mostrou capaz de ressaltar solu¸cões inusitadas, muitas vezes não percebidas pelo programador quando aplicado à um problema. [7]

1.2 Motiva¸

c˜

ao

O reconhecimento de imagens em tempo real é uma tarefa complexa, mas também extre-mamente importante em um ve´ıculo autônomo. O mesmo pode ser dito sobre a neces-sidade de um software que simule as condi¸cões de um ve´ıculo deste tipo e que permita o teste de inova¸cões em um ambiente controlado e que represente com maior fidelidade poss´ıvel o cenário verdadeiro.

O teste de novas solu¸cões, como por exemplo o aprendizado por refor¸co, e também a coleta de dados para análise são processos demorados e de dif´ıcil implementa¸cão em um carro real, podendo inclusive oferecer risco à indiv´ıduos que estiverem localizados perto do ve´ıculo.

´

E evidente a necessidade de um software que permita uma fácil implementa¸cão e que permita que engenheiros e programadores analisem suas solu¸cões, sejam de automa-¸cão, aprendizado de máquina ou comunica¸cão entre ve´ıculos.

1.3 Objetivos

Com o intuito de gerar um documento de avalia¸cão para a comunidade de engenheiros e programadores sobre o desenvolvimento de aplica¸cões de carros autônomos e IoT, este trabalho propõe fazer uma análise técnica de dois softwares de simula¸cão presentes no mercado. Além disso, este trabalho também propõe realizar uma aplica¸cão de aprendizado de máquina dentro de cada software para observar os resultados.

A proposta foi primeiramente fornecer um entendimento mais profundo sobre os softwares de simula¸c˜ao, documentar esse entendimento e em seguida aplicar um algoritmo dentro da plataforma.

O in´ıcio da an´alise deu-se no software CARLA, Car Learning to Act, na qual o ambiente para um algoritmo de aprendizado por refor¸co foi elaborado [4].

Na segunda parte da an´alise, o software de simula¸c˜ao da Udacity foi utilizado. Nesta parte, um algoritmo de aprendizado supervisionado foi testado na plataforma.

(16)

3 Em todo o desenvolvimento do projeto, a preocupa¸cão com a aplicabilidade, fa-cilidade de implementa¸cão e fidelidade com a realidade foram sempre levadas em conta. Buscou-se o melhor resultado de modo que estudos futuros e aplica¸cões V2V fossem pos-s´ıveis de aplicar.

1.4 Revis˜

ao Bibliogr´

afica

De modo a entender e avaliar solu¸cões usando inteligência artificial em ve´ıculos autônomos, diversos autores conduziram pesquisas e experimentos e documentaram seus resultados.

Em [13], os autores desenvolveram um ambiente de testes próprio utilizando o software Unity para que fosse poss´ıvel modelar um ve´ıculo autônomo em um ambiente urbano com demais ve´ıculos. Para a análise, foram utilizados agregados de 4 quadros de uma câmera frontal e um sensor laser acoplado na frente do ve´ıculo. Os autores fizeram uso da técnica de experience replay e forneceram esses dados como entrada para uma Deep Q-Network. O agente possu´ıa 5 op¸cões de a¸cões a serem realizadas: Seguir em frente, ir para a esquerda, ir para a direita, acelerar positivamente e acelerar negativamente. Após o treinamento, foi poss´ıvel observar que a rede neural profunda era capaz de fornecer como sa´ıda as a¸cões corretas, evitando colisões na rodovia.

Em [14], os autores utilizaram 1237 imagens diurnas de semáforos de subúrbios na Índia de modo a fornecer como entrada para um algortimo de Deep Learning para reco-nhecimento e deteçcão. Os semáforos indianos possuem 5 estados diferentes e o objetivo do modelo era, de forma confiável, de corretamente detectar o tipo de semáforo de uma imagem. Além de usar uma rede neural convolucional, os autores fizeram uso da técnica de transfer learning para acelerar o treinamento do algoritmo e aumentar sua acurácia. Após o treinamento de aproximadamente 12 horas, o modelo apresentou um erro de 0,01, o que cumpria com o objetivo dos autores de atingir uma perda menor do que 0,05.

Em [15], os autores fizeram uso de uma variante da rede neural convolucional, denominada Region-Based CNN com o objetivo de detectar e classificar obstáculos pre-sentes em rodovias. O treinamento do algoritmo ocorreu em uma GPU TITAN X. Apesar de terem obtido um frame rate acima de 10 frames popr segundo no processamento de v´ıdeos, os autores constataram que o algoritmo não foi capaz de detectar ve´ıculos comuns em ruas da Índia, mas que não estiveram presentes na base de dados PASCAL usado para

(17)

4 treinamento do modelo.

Em [16], os autores fizeram uso da plataforma de jogos TORCS (The Open Racing Car Game Simulator ) para um sistema end-to-end de ve´ıculo autônomo usando Deep Reinforcement Learning. O modelo utilizado foi o de Deep Deterministic Policy Gradient para mapear continuamente estados em a¸cões. Após o treinamento em 320.000 amostras e usando experience replay de 100.000 amostras, os autores constataram que o modelo foi capaz de tomar as decisões corretas no cenário de dire¸cão. Os autores também fizeram um estudo visualizando o agente graficamente e analisaram quais estados contribu´ıam para os tipos de decisão.

Em [18], os autores usaram uma variante do Deep Q-Learning, denominada Double Deep Q-Learning, a qual consiste em 2 estimadores separados para o fun¸cão Q. O objetivo do estudo foi aplicar este algoritmo ao problema de controlar a velocidade de um ve´ıculo autônomo. Os autores utilizaram uma nova abordagem chamada Naturalistic Driving, que consiste em dados de dire¸cão gerados a partir de longas observa¸cões de condutores sob uma condi¸cão natural de pilotagem e dados do ve´ıculo e do seu redor, por exemplo: movimenta¸cão das mãos do condutor, velocidade do ve´ıculo e densidade do tráfego do ambiente em que o agente se encontra. Durante o treinamento, a técnica de replay memory foi utilizada com um buffer de 2000 experiências. Os autores observaram nos resultados que o modelo de Double Deep Q-Learning teve uma acurácia 271,73 % maior do que o modelo de Deep Q-Learning.

(18)

Cap´ıtulo 2

Conceitos B´

asicos de Aprendizado

de M´

aquina

Nesta se¸cão, serão apresentados os principais conhecimentos teóricos acerca de aprendi-zado de máquina, mais especificamente aprendizado supervisionado e aprendizado por refor¸co, utilizados em fundamentos deste trabalho.

2.1 Aprendizado de M´

aquina

O aprendizado de máquina é um método de análise de dados que automatiza a constru¸cão de modelos anal´ıticos. E um ramo da inteligˆ´ encia artificial baseado na ideia de que sistemas podem aprender com dados, identificar padrões e tomar decisões com o m´ınimo de interven¸cão humana [19].

Existem três passos comuns à aplica¸cão de solu¸cões de aprendizado de máquina: análise exploratória dos dados, cria¸cão de um modelo e valida¸cão do modelo.

Análise exploratória: Consiste na etapa de adquirir dados e tratá-los com um prop´ o-sito. É nesta etapa que outliers são eliminados, processamentos são executados e valores faltantes são preenchidos, em outras palavras, realizar Feature Engineering, para que assim sejam extra´ıdas informa¸cões úteis sobre o problema.

Cria¸cão do Modelo: Etapa na qual é pensado um algoritmo de aprendizado e uma fun¸cão erro que modele a acurácia do algoritmo. Durante a fase de treinamento, os parâmetros do modelo são ajustados de modo a minimizar a fun¸cão erro.

(19)

6 Valida¸cão do Modelo: É nesta etapa que o modelo é testado com uma parte da amos-tra dos dados que não esteja enviesada, ou seja, que não participou da etapa de treinamento e ajuste de parâmetros. Dessa forma, é poss´ıvel estimar a capacidade de generaliza¸cão do algoritmo.

Existem atualmente diversas técnicas e varia¸cões de algoritmos de aprendizado de máquina, porém, apenas dois paradigmas são abordados neste trabalho.

2.1.1 Aprendizado Supervisionado

Aprendizado supervisionado consiste em fornecer ao algoritmo dados rotulados, na qual a sa´ıda esperada do algoritmo ´e conhecida previamente.

Para cada par pr´e-estabelecido (xi, yi), x representa um conjunto de caracter´ısticas

e y representa a sa´ıda decorrente da combina¸c˜ao das caracter´ısticas em x. O objetivo do algoritmo ´e tornar poss´ıvel o mapeamento de valores de x nos valores correspondentes de y.

Matematicamente, a fun¸c˜ao de mapeamento h(x) deve ser otimizada at´e que h(xi) ≈

yi. Sendo assim, essa otimiza¸cão é relacionada a uma fun¸cão erro, por exemplo, o erro

m´edio quadr´atico 2.1.

J (w) = 1 N

X

i

(yi− h(xi, w))2 (2.1)

2.1.2 Aprendizado por Refor¸

co

Aprendizado por refor¸co é um ramo estudado na estat´ıstica, psicologia, neurociência e computa¸cão. É um método de programa¸cão que consiste na cria¸cão de agentes e modela-gem da intera¸cão desse agente com o meio que o mesmo se encontra. Isso ocorre através de um sistema de recompensas e puni¸cões, de acordo com as a¸cões tomadas pelo agente, não sendo necessário especificar como uma determinada tarefa deva ser realizada, isso cabe ao agente descobrir [6].

Aprendizado por refor¸co é um problema que consiste em otimizar o controlador de um sistema, ou seja, otimizar seu comportamento em um ambiente, de modo que seja alcan¸cado um valor numérico máximo, representado por uma fun¸cão objetivo de longo prazo.

(20)

7 A cada instante de tempo, o agente recebe uma observa¸cão como input, s, o agente então escolhe uma a¸cão a ser realizada, a, e, após interagir com o ambiente através da a¸cão escolhida, recebe uma recompensa, simbolizada por um valor númerico, R.

O próposito do aprendizado por refor¸co é propor algoritmos que aprendam a per-formar de maneira ótima. O agente deve otimizar uma fun¸cão comportamento, π(s), que mapeia um estado s a uma a¸cão a. O agente deve, então, encontrar o comportamento ´

otimo π∗(s). O ambiente é considerado não-determin´ıstico, o que implica que, para um mesmo estado, realizar uma determinada a¸cão poderá levar para lugares diferentes em ocasiões distintas.

Vπ(s) = Eπ( ∞

X

t=0

(γi−1ri)), ∀s ∈ S. (2.2)

De forma que seja poss´ıvel modelar o ambiente, é necessário levar em conta o quanto o agente olhará para o futuro para determinar a melhor a¸cão em um determinado instante. Como o ambiente em questão é modelado como não-determin´ıstico, nunca terá certeza que a recompensa se manterá a mesma na próxima vez que estiver em um par estado-a¸cão. Sendo assim, através da Equa¸cão 2.2, é poss´ıvel definir o valor de um estado s, denominado V (s), na qual r é a recompensa imediata, γ é o fator de desconto e s é o estado. A equa¸cão retorna um valor númerico associado a um determinado estado e pode ser interpretada como a recompensa total esperada tomando como in´ıcio esse estado. O valor númerico do estado depende do comportamento π seguido pelo agente. Através do parâmetro γ ∈ [0, 1], é poss´ıvel determinar o quanto o futuro vai afetar o valor de um determinado estado.

∀s ∈ S : π∗(s) = argmaxπ Vπ(s) (2.3)

Sendo assim, como o objetivo do agente é encontrar o maior valor númerico de recompensa, ou seja, o melhor comportamento a ser seguido, através da equa¸cão 2.3 é poss´ıvel descrever o comportamento ótimo, retornando o valor máximo esperado de recompensa.

Existem diferentes métodos para a resolu¸cão de problemas de aprendizado por refor¸co, alguns inclusive, como por exemplo algoritmos genéticos, que não fazem uso da concep¸cão de uma fun¸cão númerica de valor. Para o escopo deste trabalho, no entanto, o foco é em algoritmos baseados em fun¸cões de valor. Para tais, se é necessário existir um

(21)

8

Figura 2.1: Intera¸c˜ao agente-ambiente em uma MDP. Fonte [6] Processo de Decis˜ao de Markov (MDP) que modele o problema proposto.

Como visto na Figura 2.1, uma MDP consiste de: Um conjunto de estados, S, um conjunto de a¸cões poss´ıveis a serem tomadas em um determinado estado s, A(s), uma fun¸cão de transi¸cão que explicita a probabilidade de chegar no estado s0 se a a¸cão a for tomada no estado s, T (s, a, s0), e uma recompensa dessa intera¸cão, R(s, a, s0) [6].

Uma propriedade importante de uma MDP é sua despreocupa¸cão com os estados passados. A probabilidade de transi¸cão de um estado para outro depende apenas do estado atual e da a¸cão tomada, e não da sequência de estados que precederam o estado atual.

Um episódio, 2.4, pode ser descrito como uma sequência finita de estados, a¸cões e recompensas.

s0, a0, r1, s1, a1, r2, ..., sn−1, an−1, rn, sn (2.4)

Solucionar uma MDP significa encontrar o comportamento ´otimo π∗(s) que mapeie cada s ∈ S em uma a¸c˜ao a ∈ A.

Q-Learning

Q-Learning é um algoritmo model-free de aprendizado por refor¸co. O objetivo do Q-learning é achar o comportamento ótimo, mas sem necessitar de um modelo do ambiente onde o agente se encontra. Q-learning é apto a lidar também em problemas com transi¸cões e recompensas estocásticas [11].

Para qualquer FMDP (Finite Markov Decision Process), Q-Learning acha o com-portamento ótimo no sentido de maximizar o valor númerico esperado de recompensa. A fun¸cão Q(s, a) retorna o valor de realizar uma a¸cão a em um determinado estado s.

(22)

9 Sendo assim, podemos descrever o comportamento do algoritmo one-step Q-learning de uma forma recursiva como a Equa¸c˜ao 2.5.

Q(s, a) = r + γ ∗ maxa0 Q(s0, a0) (2.5)

Esses valores são então armazenados em uma tabela em memória, com dimensão de (S x A).

Replay Memory

Replay Memory é uma técnica usada em aprendizado por refor¸co que consiste em ar-mazenar experiências para que o algoritmo inicie tendo acesso à valores de experiências passadas, de modo que essas experiências sejam utilizadas como entrada para treinar o algoritmo. Sendo assim, torna-se mais dif´ıcil do agente desconsiderar experiências mais antigas e também, como as experiências são aleatórias ao iniciar o treinamento, isso per-mite eliminar a correla¸cão entre estados (o quanto um estado s afeta na probabilidade de atingir um estado s0).

Algoritmo 1: Replay Memory Entrada: s, s0, R

Sa´ıda: Buffer com experiˆencias armazenadas

1 in´ıcio

2 iniciar dicion´ario vazio 3 repita

4 iniciar epis´odio 5 repita

6 escolher a¸c˜ao aleatoriamente 7 dict[s] ← s0, R

8 s ← s0

9 at´e s’ ser estado terminal ; 10 at´e dict full ;

11 fim

(23)

10

2.1.3 Redes Neurais Artificiais

Redes neurais são sistemas de computa¸cão com nós interconectados que funcionam como os neurônios do cérebro biológico. Usando algoritmos de aprendizado de máquina, elas são capazes de reconhecer padrões escondidos e correla¸cões em dados brutos, agrupá-los e classificá-los. [20]

Figura 2.2: Representa¸cão Simplificada de um neurônio matemático. Fonte [9]

O neurônio matemático é um modelo simplificado do neurônio biológico. Tais modelos foram inspirados a partir da análise da gera¸cão e propaga¸cão de impulsos elétricos pela membrana celular dos neurônios. O neurônio matemático, representado na Figura 2.2, recebe um ou mais sinais de entrada, um sinal de bias e devolve um único sinal de sa´ıda, que pode ser distribu´ıdo como sinal de sa´ıda da rede, ou como sinal de entrada para um ou vários outros neurônios da camada posterior. Os dendritos e axônios são representados matematicamente apenas pelas sinapses, e a intensidade da liga¸cão é representada por uma grandeza denominada peso, w. Quando as entradas, x, são apresentadas ao neurônio, elas são multiplicadas pelos pesos correspondentes, gerando as entradas ponderadas, ou seja, x1 que multiplica w1, ..., xn−1 que multiplica wn−1. Por fim, essa sa´ıda é passada como

argumento para uma fun¸cão de ativa¸cão, normalmente não-linear. Isso descreve a base matemática do funcionamento de uma rede neural artificial.

O treinamento de uma rede neural padr˜ao consiste em 2 passos: forward pass, que consiste em propagar as entradas atrav´es das camadas da rede, ou seja, multiplicar as

(24)

11

Figura 2.3: Exemplos de fun¸c˜oes de ativa¸c˜ao. Fonte [17]

Figura 2.4: Exemplo de uma rede neural. Fonte [9]

matrizes de entradas, pesos, bias e aplicar às fun¸cões de ativa¸cão e backpropagation, que consiste em otimizar os pesos da rede, de modo a minimizar a fun¸cão de perda, J (w), escolhida.

y1 = act(w1 ∗ input) (2.6)

y2 = act(w2 ∗ y1) (2.7)

(25)

12 error = J (w) = output − y0 (2.9) w1 ← w1 − η(∂J (w) ∂w1 ) (2.10) w2 ← w2 − η(∂J (w) ∂w2 ) (2.11) w3 ← w3 − η(∂J (w) ∂w3 ) (2.12)

Usando as Figuras 2.3 e 2.4 como referência, é poss´ıvel demonstrar as etapas de forwardpass 2.6, 2.7 e 2.8 e backpropagation 2.10, 2.11 e 2.12 em uma rede neural simples, na qual η é a taxa de aprendizado do algoritmo, y0 é o valor de supervisão correto,

∂J (w)

∂wij ´e a derivada parcial do erro com rela¸c˜ao a um determinado peso, que pode ser

calculada através da regra da cadeia, pois, como visto acima nas equa¸cões 2.6 até 2.9, toda sa´ıda de uma camada superior pode ser escrita em fun¸cão dos pesos e ativa¸cão de camadas anteriores e act() é fun¸cão de ativa¸cão diferenciável escolhida para uma camada de neurônios.

2.1.4 Aprendizado Profundo

Aprendizagem Profunda, ou Deep Learning, é uma subárea da Aprendizagem de Máquina, que emprega algoritmos para processar dados e imitar o processamento feito pelo cérebro humano.

Deep Learning usa camadas de neurônios matemáticos para processar dados, com-preender a fala humana ou reconhecer objetos visualmente. A informa¸cão é passada atra-vés de cada camada, com a sa´ıda da camada anterior fornecendo entrada para a próxima camada. A primeira camada em uma rede é chamada de camada de entrada, enquanto a ´

ultima é chamada de camada de sa´ıda. Todas as camadas entre as duas são referidas como camadas ocultas. Cada camada é tipicamente um algoritmo simples e uniforme contendo um tipo de fun¸cão de ativa¸cão, das quais a Figura 2.3 contém exemplos [9].

A grande inova¸cão do aprendizado profundo consistiu em abstrair do programador o modo como o algoritmo processa os dados. Através das camadas ocultas presentes, o modelo é capaz de criar n´ıveis mais aprofundados de hierarquia entre as entradas do

(26)

13

Figura 2.5: Redes neurais artificiais com uma camada e com m´ultiplas camadas escondi-das. Fonte [9]

algoritmo, mas com isso tornando abstrata sua rela¸cão com a entrada fornecida. Pode-se dizer que as redes neurais profundas possuem uma extra¸cão de recursos automática gra¸cas `

as camadas profundas a mais que s˜ao adicionadas ao modelo, como visto na Figura 2.5, possibilitando encontrar padr˜oes dificilmente encontrados por humanos.

Redes Neurais Convolucionais

Uma Rede Neural Convolucional é um algoritmo de aprendizado profundo que permite captar uma imagem de entrada, atribuir importância (pesos e vieses que podem ser apren-didos) a diferentes aspectos da imagem e ser capaz de diferenciar um do outro. O pr´ e-processamento exigido em uma CNN é muito menor em compara¸cão com outros algorit-mos de classifica¸cão. Enquanto nos métodos primitivos os filtros são feitos à mão, com treinamento suficiente, as CNNs têm a capacidade de aprender esses filtros caracter´ısticos. [9]

Matematicamente, uma convolu¸cão é uma opera¸cão linear que a partir de duas fun¸cões, gera uma terceira. No contexto de imagens, podemos entender esse processo como um filtro que transforma uma imagem de entrada.

Um filtro é uma matriz utilizada para a opera¸cão de multiplica¸cão de matrizes. Esta opera¸cão é aplicada diversas vezes em diferentes regiões da imagem. A cada aplica¸cão, a região é alterada por um parâmetro conhecido como passo. Normalmente o passo possui o valor 1, o que significa que a transforma¸cão será aplicada em todos os pixels da imagem. Por exemplo, como visto na figura 2.6, em uma imagem com dimensões (6 x 6 x

(27)

14

Figura 2.6: Filtro sendo aplicado em uma imagem RGB. Fonte [21]

3) e um filtro de tamanho (3 x 3) com passo de 1 pixel, o filtro passar´a pela imagem por completa, por cada um dos canais, tendo como resultado uma matriz de dimens˜oes (4 x 4 x 1).

Deep Q-Learning

A abordagem naive apresentada no Q-Learning é válida somente para ambientes de com-plexidade pequena. Quando o conjunto de estados poss´ıveis no ambiente de estudo se torna ilimitado, como no caso de imagens em um ve´ıculo autônomo, armazenar os valores em uma tabela na memória não é mais uma solu¸cão adequada.

Sendo assim, Deep Q-Learning faz uso de uma rede neural para mapear estados em a¸cões. Pode-se descrever seu comportamento através da equa¸cão 2.13, na qual os valores para cada par (estado, a¸cão) são inicializados arbitrariamente e conforme o algoritmo é treinado, são ajustados. Os parâmetros da equa¸cão simbolizam os mesmos parâmetros vistos na abordagem de Q-Learning

Q(st, at) ← Q(st, at) + α[Rt+1+ γ ∗ max Q(st+1, a) − Q(st, at)] (2.13)

(28)

15 O valor de uma tupla (s, a) será estimado por uma rede neural, a qual tentará aproximar o valor de executar a a¸cão a no estado s. Após executada a a¸cão, os valores de recompensa e estado novo são usados para treinar a rede através do backpropagation, usando o target como sa´ıda esperada da rede.

(29)

Cap´ıtulo 3

Estudos de caso

3.1 As ferramentas

3.1.1 CARLA

O simulador CARLA (Car Learning to Act ) é um aplicativo open-source que foi desenvol-vido com o propósito de auxiliar no desenvolvimento, treinamento e valida¸cão de modelos de ve´ıculos autônomos. [4]

O CARLA possui um conjunto de acessórios como arranjos de mapas, constru¸cões, ve´ıculos e pedestres que podem ser usados. No momento de execu¸cão deste trabalho, existem cinco versões de mapas poss´ıveis para escolha do usuário. É poss´ıvel também ex-portar mapas criados pelo usuário para dentro do CARLA utilizando ferramentas externas pagas.

Além disso, a aplica¸cão também possui diversas classes de sensores que podem ser usadas para obter a telemetria e rea¸cões f´ısicas do ve´ıculo em um determinado instante. No momento de execu¸cão deste trabalho, existem mais de seis tipos de sensores poss´ıveis para escolha do usuário. É importante ressaltar também que o software possui uma API em Python consideravelmente flex´ıvel, o que permite compatibilidade com bibliotecas de aprendizado de máquina em Python.

3.1.2 Udacity

O simulador da Udacity foi inicialmente desenvolvido com o prop´osito de ajudar estu-dantes a treinar seus modelos de ve´ıculos autˆonomos ao longo do programa de ensino

(30)

17 Udacity’s Self-Driving Car Nanodegree.

Atualmente, o software encontra-se dispon´ıvel como ferramenta gratuita.

Devido ao vasto conjunto de sensores dispon´ıveis no software CARLA, de modo que ´e poss´ıvel obter facilmente atributos f´ısicos e espaciais do ve´ıculo em tempo real, foi escolhida a abordagem de aprendizado por refor¸co para fazer uma an´alise cr´ıtica em cima desta ferramenta.

Para o software da Udacity, devido `a sua estrutura menos flex´ıvel, foi escolhida a abordagem de aprendizado supervisionado para fazer uma an´alise cr´ıtica da ferramenta.

3.2 Aprendizado por refor¸

co no CARLA

A modelagem do problema se iniciou ao escolher um algoritmo dentre as op¸c˜oes de t´ecnicas dentro da categoria de aprendizado por refor¸co, para que assim o problema pudesse ser modelado de acordo com essa escolha.

Ap´os analisar publica¸c˜oes recentes, [13] [16] [18], o algoritmo de Deep Q-Learning foi escolhido baseado nos resultados promissores observados.

Utilizando o algoritmo de Deep Q-Learning, o próximo passo foi determinar um sistema de recompensas nas intera¸cões do agente com o meio. Por não existir um diretriz sobre qual valor usar, foram escolhidos valores através de pesquisa e observa¸cão de quais valores eram utilizados nos artigos referentes à aprendizado por refor¸co em carros autˆ o-nomos. Foram então estabelecidos os valores de -1 a cada instante sem colisão, -100 caso houvesse colisão ou invasão de pista de sentido contrário e +200 caso o tempo máximo de episódio proposto fosse alcan¸cado.

Foi estabelecido também que o ajuste de velocidade não faria parte do escopo deste trabalho, sendo o foco somente em controlar a sa´ıda correspondente ao ângulo do volante. Sendo assim, a velocidade foi estabelecida na mesma velocidade fornecida pelo modo piloto automático do CARLA.

3.2.1 Aquisi¸

c˜

ao de dados

De modo a se ater às práticas comuns do conceito de aprendizado por refor¸co apresentadas nos materias de referência, [13] [15] [16], fazendo com isso com que o algoritmo tenha uma maior chance de convergência, foi utilizada a técnica de experience replay. Sendo assim,

(31)

18 foi necessário realizar uma aquisi¸cão prévia de dados, afim de gerar uma base de dados inicial contendo estado, recompensa atribu´ıda e estado seguinte.

Observou-se também que outra técnica apresentada, agregado de quadros, se mos-trou necessária no escopo deste trabalho. Ao observar a imagem gerada pelo sensor do CARLA 3.1, não é poss´ıvel afirmar com certeza se o ve´ıculo se encontra parado, se está movendo para trás ou se está movendo para frente. Com o intuito de solucionar este pro-blema, um estado s deixou de ser composto apenas por um frame individual, mas agora por um conjunto de quatro quadros em sequência. Desta forma, é poss´ıvel estabelecer uma dire¸cão na qual o ve´ıculo se movimenta.

Através de métodos já existentes na API em Python do CARLA, foi poss´ıvel obter constantemente os valores de velocidade, frame atual, angula¸cão do volante do ve´ıculo neste frame espec´ıfico e sa´ıda dos sensores escolhidos. Com isso, esses dados passavam por uma fun¸cão que agregava os quadros e determinava a recompensa associada e o quadro seguinte, que em seguida eram anexados à base de dados do experience replay. [5]

Dentre os sensores dispon´ıveis no CARLA, foram escolhidos dois para modelar o problema.

O primeiro sensor escolhido foi o de uma cˆamera RGB. Como o trabalho se prop˜oe a resolver um problema de reconhecimento e processamento de imagens, era imprescind´ıvel a presen¸ca deste sensor.

A API do CARLA permite escolher em qual posi¸cão do carro a câmera será posi-cionada, quantos frames serão obtidos por segundo e qual o tamanho da imagem gerada na sa´ıda do sensor. Sendo assim, foi escolhido que a câmera estaria acoplada na parte central superior do ve´ıculo, captando dados no menor intervalo poss´ıvel dispon´ıvel para o CARLA e fornecendo como sa´ıda imagens de dimensão (350 x 256) pixels.

O segundo sensor escolhido foi pensado em sua intera¸cão com a fase de atribui¸cão de recompensas para o agente. Para isto, foi observado que o sensor de invasão de pista seria o melhor para cumprir este propósito.

O sensor other lane invasion gera sa´ıdas nulas constantemente. O único momento que o sensor gera sa´ıdas não-nulas é quando o ve´ıculo sendo usado como agente invade a pista na contra-mão ou quando avan¸ca em uma cal¸cada, por exemplo. Sendo assim, quando o sensor de invasão de pista gerava uma sa´ıda não-nula, o episódio era terminado, uma recompensa negativa era atribu´ıda e um novo episódio era iniciado.

(32)

19 Os sensores do CARLA funcionam como threads dentro do programa. Cada vez que um sensor é instanciado, uma fun¸cão é passada como argumento ao método gerador de sensores, de modo que a sa´ıda desse sensor, sendo executado no plano de fundo, seja direcionada para essa fun¸cão argumento. A fun¸cão pode ser um processamento de imagem, gera¸cão de recompensa, verifica¸cão de estado terminal do agente ou apenas registro em disco dos dados obtidos, por exemplo.

3.2.2 Atua¸

c˜

ao do agente

Usando métodos da API do CARLA, é poss´ıvel enviar comandos através da interface servidor-cliente de modo a controlar a angula¸cão do volante do ve´ıculo e sua velocidade e acelera¸cão.

De modo que o problema pudesse ser modelado dentro da abordagem do Q-Learning, as a¸cões poss´ıveis para serem executadas pelo agente foram discretizadas, de modo que a camada final da rede neural possu´ısse três neurônios. Sendo assim, o agente pode decidir entre três a¸cões: virar para esquerda, virar para direita ou manter o volante reto.

A a¸cão de virar para a esquerda foi discretizada como uma angula¸cão de -0,3 graus, a a¸cão de virar para a direita como uma angula¸cão de 0,3 graus e manter o volante reto como uma angula¸cão de 0 graus.

Figura 3.1: Imagem gerada pelo sensor do CARLA versus imagem p´os-processamento.

Cada frame gerado pelo agente era fornecido como entrada para uma fun¸c˜ao que o processava, cortando a imagem nos locais que eram mais importantes para a dete¸c˜ao de pontos cr´ıticos, em seguida passava a imagem para escala de cinza, de modo a diminuir processamento na rede neural e fazia agrupamentos de quatro frames 3.1.

(33)

20

Figura 3.2: Arquivo gerado com dados sobre angula¸c˜ao do volante e seus quadros corres-pondentes.

de extensão CSV, contendo ângula¸cão do volante, e matrizes correspondendo aos pixels relativos ao agregado de frames relacionados à angula¸cão previamente dita, como visto na Figura 3.2. De modo que o agente fosse capaz de percorrer estados pouco comuns durante o processo de gerar o experience replay, as a¸cões executadas pelo agente era escolhidas aleatoriamente.

Após montado o experience replay, o agente pôde come¸car a atuar tendo dispon´ıvel um sele¸cão de experiências passadas com as quais pode ser treinado. O tamanho escolhido para o experience replay foi de 1000 experiências. Não existe um número concreto para ser usado como tamanho do buffer, os valores são determinados na literatura através de tentativa e erro.

Os dados contidos no arquivo CSV gerados seria ent˜ao passados a uma rede neural convolucional que tentaria estimar o valor de cada a¸c˜ao estando dentro de um determinado estado e a sa´ıda desse algoritmo seria enviada para o servidor do CARLA.

O algoritmo teria uma probabilidade de realizar uma a¸cão aleatória e uma pro-babilidade 1 − de usar a fun¸cão Q(s, a) mapeada pela rede neural para tomar a decisão, de modo a abrangir o dilema explore X exploit, onde o agente não fica preso em estados mais comuns.

(34)

21 Entretanto, um problema foi descoberto ao tentar manter um sincronismo entre os sensores. Ao observar os dados gerados, constatou-se que, mesmo o timestamp de ativa¸cão de um sensor sendo condizente com o do outro, devido a atrasos de computa¸cão do CARLA, ocorria um conflito de informa¸cões. Isso fez com que a imagem correspondente ao momento que o agente invadia a cal¸cada, por exemplo, não era a imagem correta, e sim uma imagem correspondente a segundos depois, o que representou um erro crucial para o problema proposto. Foi necessário, então, testar solu¸cões e observar o desempenho. A solu¸cão pensada foi de manter armazenado junto com os dados o timestamp de cada um. Sendo assim, no momento que o sensor de invasão de pista era acionado, esse timestamp era armazenado e fornecido a uma fun¸cão que percorria os dados gerados pela câmera e apagava quaisquer dados relativos a timestamps seguintes antes de um novo episódio ser iniciado.

Outro problema foi observado ao dar continuidade na atua¸cão do agente. Os sensores permitem escolher o intervalo de tempo no qual dados serão capturados. Dentre essas op¸cões, no entanto, existe uma que permite captar dados o mais rápido poss´ıvel. Essa op¸cão, apesar de ser a mais interessante e fornecida pela própria API do CARLA, causou problemas de congelamento do software devido ao excesso de processamento e requisi¸cões cliente-servidor. Sendo assim, foi necessário atentar para a quantidade de requisi¸cões feitas dentro de um intervalo de tempo.

Enquanto era pensada uma solu¸c˜ao para este problema, os desenvolvedores do CARLA lan¸caram uma nova vers˜ao atualizada que continha um modo de sincronismo dispon´ıvel para ser utilizado pela API.

Para que fosse obtido então sincronismo entre o cliente, processando dados e com-putando recompensas e agrupamentos de frames e o servidor, foi necessário usar esse novo método dispon´ıvel na API do CARLA. Desse modo, o servidor fica ausente e o cliente pode processar o dados o quanto for necessário. Quando finalizado o processamento, o cliente sinaliza ao servidor que pode avan¸car para o próximo estado.

3.2.3 Resultados

Mesmo com o modo de sincronismo do CARLA ativado e com os timestamps monitorados, ao ser realizada a aquisi¸c˜ao de dados, observou-se que ainda estava havendo perda de sincronismo.

(35)

22 Parte dos frames no quais o agente invadia a pista na contra-mão e o sensor de invasão de pista disparava valores não-nulos possu´ıam recompensa zero, o que não deveria acontecer. O episódio, então,itor reiniciava e os frames seguintes recebiam a recompensa de -100, o que indica uma falha no sincronismo entre o algoritmo e o servidor.

Após tentativas de resolver o problema de sincronismo entre o algoritmo e o servidor terem sido realizadas, constatou-se que o problema era mais cr´ıtico, sendo necessário abordar com maior detalhamento o código fonte do software CARLA, o que significaria se distanciar do escopo deste trabalho. Sendo assim, foi tomada a decisão de encerrar a análise do CARLA nesta etapa.

Outro problema importante a ser ressaltado é que o CARLA requer um hardware m´ınimo a ser utilizado. Este trabalho foi iniciado em um notebook Dell Inspiron 5558 com processador Intel I5, sem placa de v´ıdeo dedicada e com 8GB de RAM. Porém, mesmo tentando operar no modo sem renderiza¸cão do CARLA, esse hardware não foi suficiente para rodar o simulador, sendo então necessário adquirir um novo hardware e esperar que o mesmo fosse entregue.

Os novos componentes de hardware consistiram em um gabinete com processador Intel I7, uma placa de v´ıdeo dedicada NVIDIA GTX 1060 Ti e 8GB de RAM. Com essa nova composi¸cão, foi poss´ıvel rodar o simulador tanto no modo sem renderiza¸cão quanto com renderiza¸cão.

3.3 Aprendizado Supervisionado na Udacity

O in´ıcio da modelagem come¸cou ao ser escolhida uma dentre as duas pistas dispon´ıveis para o usuário. A primeira pista foi escolhida devido a sua simplicidade e ausência de eleva¸cão do trajeto ao longo do percurso.

3.3.1 Aquisi¸

c˜

ao de dados

Com o objetivo de formar uma base suficientemente grande para treinar o algoritmo, foi iniciada a etapa de obten¸cão de dados.Para isto, foi utilizado o modo de dire¸cão manual da Udacity, sendo poss´ıvel controlar o ve´ıculo manualmente pelo tempo que for necessário. Fazendo uso da facilidade do software da Udacity, no momento em que o usuário indica que o per´ıodo de obten¸cão de dados foi conclu´ıdo, o software automaticamente gera

(36)

23 um arquivo com extens˜ao CSV contendo os dados relativos ao percurso feito.

Dentro deste arquivo é poss´ıvel encontrar dados de velocidade, angula¸cão do volante e três frames, um relativo a uma câmera acoplada na parte esquerda do ve´ıculo, uma acoplada na parte central do ve´ıculo e a outra acoplada na parte direita do ve´ıculo. Mantendo o padrão de análise realizado no CARLA, o controle de velocidade não entrou no escopo deste trabalho, sendo então desconsiderado como entrada para o algoritmo.

3.3.2 Prepara¸

c˜

ao dos dados

Ao iniciar uma análise exploratória sobre os dados obtidos em três voltas ao redor da pista número 1 da Udacity, alguns problemas foram observados.

O primeiro problema foi que, como a pista tem uma predominância maior de curvas suaves para a esquerda, a grande maioria dos ângulos obtidos para análise se encontravam dentro do intervalo de -0,2 e 0. Isso pode ser visto na Figura 3.3

Figura 3.3: Histograma com ˆangulos do volante.

O segundo problema foi que, por estarem deslocadas em rela¸cão ao eixo do carro, as câmeras laterais não poderiam ser usadas no mesmo algoritmo sem terem recebido o devido processamento. Caso não feito tal processamento, estaria sendo perdidos dados ´

uteis para o treinamento do algoritmo. Isso pode ser observado na Figura 3.4.

Para resolver o primeiro problema, a seguinte técnica de processamento de imagens foi utilizada: cada frame central processado relativo à curvas para a esquerda tinha trinta por cento de chance de ser espelhado e ter sua angula¸cão do volante correspondente mul-tiplicada por −1. Sendo assim, após realizada uma subamostragem, foi poss´ıvel ampliar

(37)

24

Figura 3.4: Imagens das câmeras central e lateral direita durante uma curva. consideravelmente o número de amostras correspondentes a virar para a direita, deixando a base de dados mais heterogênea.

Para resolver o segundo problema, a seguinte técnica de processamento de imagens foi utilizada: Cada frame lateral processado tinha dez por cento de chance de ser deslocado 0,2 graus no valor de angula¸cão, caso fosse um frame lateral esquerdo, ou -0,2 caso fosse um frame lateral direito. Sendo assim, o número de amostras dispon´ıveis para treinamento do algoritmo pôde ser aumentada.

Figura 3.5: Histograma com angula¸c˜ao do volante ap´os tratamentos

Foi poss´ıvel observar que, após todo o tratamento dos dados, a disposi¸cão de an-gula¸cão do volante ao longo do percurso se tornou mais heterogênea e se aproximou de uma distribui¸cão normal, o que permite que o treinamento do algoritmo tenha maiores chances de sucesso, ao invés de ser enviesado por uma classe majoritária nas amostras.

3.3.3 Escolha do modelo e treinamento

A NVIDIA tornou dispon´ıvel a arquitetura da rede usada para treinar o carro autˆonomo usado em seu projeto de carros autˆonomos utilizando reconhecimento de imagens [10].

(38)

25

Figura 3.6: Arquitetura da rede neural do projeto da NVIDIA. Fonte: [10] Essa arquitetura se encontra representada na Figura 3.6.

Acreditou-se ser um bom ponto de referência come¸car pelo modelo sugerido pela NVIDIA. Sendo assim, foi realizada uma avalia¸cão da perfomance do algoritmo com estru-turas similares à sugerida pelo artigo da NVIDIA 3.7, utilizando a ferramenta Tensorboard disponibilizada pelo Tensorflow, de modo a investigar o melhor modelo a ser usado no pro-blema em questão. Através da Figura, é poss´ıvel observar o desempenho dos diferentes tipos de arquitetura ao longo de dez épocas. Os parâmetros testados no Tensorboard foram número de camadas profundas, número de neurônio por camadas e número de camadas convolucionais. [12]

Usando 6.018 amostras, divididas entre 4.212 para treinamento e 1.806 para vali-da¸cão de parâmetros, seguindo o padrão geral da liteturatura de dividir 60% para trei-namento e 40% para teste, a rede neural foi treinada durante 10 épocas com taxa de aprendizado 0,001.

Após a análise no Tensorboard, foi poss´ıvel observar quais arquiteturas de rede eram as mais promissoras e com menor valor de perda durante o treinamento, e estas foram escolhidas para avan¸car para a etapa de teste. Na Figura 3.8, estão ampliados os modelos que obtiveram a menor perda, ou seja, os que obtiveram menor erro médio entre

(39)

26

Figura 3.7: Inspe¸c˜ao de performance em mais de 60 modelos diferentes.

valor de predi¸cão e valor real, após o treinamento de dez épocas. Esses foram os modelos mais interessantes a serem levados para fase de testes.

Não foram separadas amostras para a fase de teste, a qual consiste em avaliar se o modelo é capaz de generalizar para amostras não enviesadas pelo treinamento. No entanto, optou-se por manter a base de amostras e realizar a fase de teste por inspe¸cão prática da performance de cada arquitetura no próprio simulador, de forma a observar os resultados.

Figura 3.8: Foco nos modelos com menor valor de perda e convergˆencia mais r´apida escolhidos para a fase de teste.

(40)

27 O método de otimiza¸cão escolhido foi o Adaptive Moment Estimation Algorithm, a fun¸cão erro escolhida foi o erro médio quadrático, a fun¸cão de ativa¸cão nas camadas foi a fun¸cão ReLU e o treinamento da rede foi realizado em uma GPU com 1.280 CU DA cores.

3.3.4 Resultados

O objetivo do teste era conseguir obter um modelo que fosse capaz de guiar o carro ao longo da pista durante uma volta sem qualquer tipo de colis˜ao e a com a maior estabilidade poss´ıvel.

Após treinada a rede, foi ativado o modo autônomo disponibilizado pelo próprio software na interface do usuário, no qual a ferramenta habilita o modo servidor e é poss´ıvel que o usuário se conecte e utilize um modelo treinado para ser utilizado.

Fornecendo como entrada os modelos selecionados para o teste de campo, os quais se encontram na Figura 3.8, em apenas dois modelos foi poss´ıvel observar o ve´ıculo andar corretamente pela pista, durante uma volta, sem colidir com nenhum objeto ou parede, mostrando que esta arquitetura de rede neural conseguiu ajustar os pesos de modo a generalizar suficientemente e permitir guiar pela pista sem acidentes. Foram estes: modelo de 4 camadas convolucionais, 3 camadas densas e tamanho de camada 64 e modelo de 3 camadas convolucionais, 2 camadas densas e tamanho de camada 64. Os tamanhos de passo e tamanho do filtro foram mantidos iguais ao modelo NVIDIA.

O modelo de 4 camadas convolucionais, 3 camadas densas e tamanho de camada 64 foi escolhido como o modelo de resultado final, devido a sua capacidade de guiar o carro com maior seguran¸ca e estabilidade.

Tamb´em ´e importante ressaltar que durante todo o processo com o simulador da Udacity, exceto o treinamento da rede, foi utilizado um notebook Inspiron 5558, com processador I5, 8GB de RAM e sem placa de v´ıdeo dedicada.

´

E poss´ıvel usar o software Unity para criar pistas espec´ıficas a serem usadas no estudo, porém foi visto que isto sairia do escopo do projeto, já que a pista número um foi suficiente para testar o algoritmo.

(41)

28

3.4 Compara¸

c˜

ao dos Resultados

Os crit´erios utilizados para comparar as ferramentas, sendo avaliados em notas de 0 a 5, a nota 1 (um) representando um desempenho ruim e a nota 5 (cinco) representando um desempenho ´otimo, foram os seguintes:

Interface de uso: O quanto amigável é a interface dispon´ıvel para o usuário.

Realismo: O quanto a ferramenta se ateve às leis da f´ısica que regem um cenário de transporte veicular e também à fidelidade dos dados gerados pelos sensores. Pode-se citar como exemplo: velocidade, acelara¸cão, for¸cas laterais, comportamento de colisão, qualidade da imagem gerada, entre outros.

Requisitos de Hardware: Neste critério foi avaliada a composi¸cão necessária de equi-pamentos para que fosse poss´ıvel utilizar a ferramenta. Uma pontua¸cão alta simbo-liza a op¸cão de usar componentes de hardware mais simples e mais baratos.

Compatibilidade com aplica¸cões IoT: Avaliou-se o quanto era poss´ıvel implementar solu¸cões que também envolvessem IoT. Sensores semafóricos, sensores de pedestres, sensores veiculares e ambiente compartilhado entre múltiplos agentes foram quesitos levados em conta neste critério.

Facilidade de uso: Foi avaliado a facilidade de implementa¸cão de uma solu¸cão end-to-end na ferramenta. Levou-se em conta os passos de instala¸cão e acesso até visuali-za¸cão e valida¸cão de resultados.

Escalabilidade: Este critério avaliou a capacidade que cada ferramenta tinha em adici-onar novos aspectos a um problema já modelado em produ¸cão e a capacidade das ferramentas em crescer para um problema maior.

State-of-the-art Benchmarking : Foi realizada uma avalia¸cão de documentos e pes-quisas dispon´ıveis para acesso, nos quais solu¸cões são propostas utilizando as ferra-mentas, de forma que seja poss´ıvel usar estes documentos como base de compara¸cão e avalia¸cão de resultados.

(42)

29 Tabela 3.1: Compara¸c˜ao dos Resultados

Crit´erio CARLA Udacity Interface 2 5

Realismo 5 2

Requisito de Hardware 1 4 Compatibilidade com aplica¸c˜oes IoT 4 1 Facilidade de uso 3 3 Escalabilidade 4 2 State-of-the-art benchmarking 2 3

3.4.1 Descri¸

c˜

ao das Pontua¸

c˜

oes

Interface de uso: O simulador da Udacity recebeu nota máxima por possuir uma in-terface embutida para in´ıcio da simula¸cão, com atalhos para grava¸cão de percursos e sendo poss´ıvel controlar o ve´ıculo através de atalhos no teclado. O CARLA, por outro lado, não possui interface de uso, sendo todos os passos realizados através do terminal de comando, além disso, o CARLA possui apenas compatibilidade com sistemas Linux, a compatibilidade com sistemas Windows ainda está em fase de testes.

Realismo: O CARLA recebeu nota máxima devido ao fato de possuir dados relativos a modelagem f´ısica de ve´ıculos como, por exemplo, o valor de sa´ıda de um sensor de colisão ter valores condizentes com a velocidade que o ve´ıculo estava sendo con-duzido. Além disso, o modo que o ve´ıculo se comporta em situa¸cões de estresse também foi levado em conta. O simulador da Udacity, por outro lado, não possui acesso a informa¸cões f´ısicas relativas ao ve´ıculo e não permite, por exemplo, uso de semáforos e pedestres.

Requisitos de Hardware: O CARLA recebeu uma pontua¸cão baixa por necessitar de uma placa de v´ıdeo dedicada e um processador acima de média para funcionar. Já o simulador da Udacity foi capaz de ser utilizado em um hardware mediano.

Compatibilidade com aplica¸cões IoT: Grande parte dos estudos recentes em aplica-¸cões IoT reside em comunica¸cões V2V e controle de tráfego, por exemplo. O CARLA

(43)

30 permite ter controle de diversos sem´aforos e ve´ıculos e obter dados sobre todos eles. O simulador da Udacity, no entanto, n˜ao possui nenhum tipo de compatibilidade deste tipo.

Facilidade de uso: Apesar do fato de não possuir uma interface, a API em Python do CARLA é consideravelmente completa e possui métodos integrados que abstraem do programador a necessidade de fugir do escopo de seu trabalho. Pode-se citar como exemplo a existência de um método cuja fun¸cão é estabelecer a conexão cliente-servidor com o simulador. Essa mesma funcionalidade, porém, no simulador da Udacity fica sob encargo do programador desenvoler. Um ponto que é relativa-mente fraco em ambas as ferramentas é a ausência de uma documenta¸cão concreta e facilmente dispon´ıvel.

Escalabilidade: Através da API do CARLA, é poss´ıvel adicionar novos agentes no am-biente de estudo, ou então alternar sensores ou mudar o jeito como se comportam. O software da Udacity, no entanto, não permite altera¸cões nos sensores já existentes bem como não permite adicionar novos agentes ao problema estudado. Como o trei-namento dos modelos ocorre fora dos simuladores, ambos não possuem problemas em testar novos parâmetros para os modelos escolhidos.

State-of-the-art Benchmarking : Por ser uma ferramenta recente, existe uma dificul-dade em encontrar solu¸cões aplicadas no CARLA para serem utilizadas em modo comparativo. Para o simulador da Udacity, no entanto, por ser uma ferramenta mais antiga, é poss´ıvel encontrar trabalhos de referência com maior facilidade.

(44)

Cap´ıtulo 4

Conclus˜

ao

Alguns pontos podem discutidos ao avaliar as ferramentas escolhidas para análise neste trabalho. O software CARLA tem uma profundidade que permite que o usuário tenha uma intera¸cão mais personalizada com o ambiente de estudo. Isso, porém, traz consigo uma dificuldade maior ao utilizar a ferramenta e também acaba gerando uma interface menos amigável ao usuário e a quem não possui experiência com desenvolvimento de aplica¸cões.

Outro problema importante é que não é poss´ıvel utilizar este simulador em um notebook com requisitos medianos. É necessário possuir uma composi¸cão de hardware acima da média para que o simulador CARLA funcione corretamente.

´

E importante ressaltar também que o CARLA é uma excelente ferramenta para quem deseja simular ambientes de comunica¸cão V2V, visto que é poss´ıvel instaciar diversos ve´ıculos, pedestres e também obter dados de cada um deles em tempo real e advindos de diversos sensores diferentes.

Grande parte dos problemas encontrados no CARLA no decorrer deste trabalho podem ser abordados em um estudo cujo o escopo seja de foco maior no CARLA. Como por exemplo, a quest˜ao do sincronimo entre cliente e servidor.

Sobre o software da Udacity, é uma ferramenta definitivamente mais amigável ao usuário, de modo que o cliente não precise adentrar em caracter´ısticas de formata¸cão do simulador e pode apenas se dedicar a pesquisa a desenvolver sua solu¸cão. Por ser um software mais antigo no mercado, existe um número maior de solu¸cões já testadas para serem usadas como benchmarking, como por exemplo [8]

(45)

32 da Udacity traz consigo um realismo consideravelmente aqu´em quando comparado ao CARLA, seja na f´ısica do ve´ıculo quanto na gama de dados associados ao agente de interesse.

Por não possibilitar instanciar múltiplos ve´ıculos e pedestres e também não per-mitir ter controle sobre objetos dentro da simula¸cão, como semáforos, projetos de IoT de comunica¸cão V2V, por exemplo, não seriam adequados para esta plataforma.

Sendo assim, com os resultados obtidos neste trabalho, constatou-se que, apesar de haver um déficit de ferramentas que auxiliem os testes de solu¸cões aplicadas a ve´ıculos autônomos, é poss´ıvel observar avan¸cos e um aumento no interesse dos desenvolvedores em criar softwares mais robustos e que representem com fidelidade ambientes urbanos.

Para pesquisadores e engenheiros cuja inten¸cão é montar uma plataforma end-to-end de ve´ıculos autônomos, o CARLA é a recomenda¸cão mais forte. Através das s´ınteses obtidas no escopo deste trabalho, mostra-se o potencial do CARLA para gerar dados em tais aplica¸cões e a fidelidade e realismo dos mesmos.

No entanto, para pesquisadores e engenheiros cuja inten¸cão é se ater em desenvolver algoritmos de aprendizado de máquina e otimizá-los, a ferramenta disponibilizada pela Udacity é uma forte recomenda¸cão para iniciar a pesquisa.

(46)

Cap´ıtulo 5

Sugest˜

oes para trabalhos futuros

Com base no trabalho desenvolvido, diversas vertentes de trabalhos futuros podem ser identificadas.

A primeira seria utilizar o CARLA em projetos de IoT com inteligência artificial, por exemplo, coordena¸cão de trânsito utilizando utilizando os dados advindos de sensores semafóricos e de ve´ıculos criados no mapa.

A segunda é explorar o código fonte do CARLA e tornar poss´ıvel a aquisi¸cão dos dados e sincronismo entre cliente e servidor, de modo que seja poss´ıvel aplicar solu¸cões de aprendizado por refor¸co no CARLA.

A terceira consiste em fazer uso do segundo trajeto presente no software de simu-la¸cão da Udacity. Por ser uma pista com diferentes eleva¸cões, isso traz outras dificuldades para o escopo do problema. Pode-se, inclusive, usar o modelo gerado neste trabalho e realizar compara¸cões.

A quarta e última sugestão é fazer uma valida¸cão inversa das técnicas utilizadas e comparar os resultados com este trabalho, usando nesse caso aprendizado por refor¸co na Udacity e aprendizado supervisionado no CARLA.

(47)

34

Referˆ

encias Bibliogr´

aficas

[1] Artigo Jornal O Globo, https://g1.globo.com/carros/noticia/2019/05/23/a-cada- 1-hora-5-pessoas-morrem-em-acidentes-de-transito-no-brasil-diz-conselho-federal-de-medicina.ghtml. Acesso em 29/10/2019

[2] Artigo da Associa¸c˜ao Nacional dos DETRANS, http://www.and.org.br/brasil-ja-tem-1-carro-a-cada-4-habitantes-diz-denatran. Acesso em 29/10/2019

[3] Machine Learning Algorithms in Autonomous Driving https://iiot-world.com/machine-learning/machine-learning-algorithms-in-autonomous-driving. Acesso em 29/10/2019

[4] Site de apresenta¸c˜ao do CARLA, http://carla.org. Acesso em 29/03/2019

[5] Documenta¸c˜ao do CARLA, https://carla.readthedocs.io/en/latest/. Acesso em 29/03/2019

[6] SUTTON, Richard and BARTO, Andrew. Reinforcement Learning: An Introduction, Andrew Barto, 1992

[7] Artigo sobre IA modelando a brincadeira de pique-esconde e sendo disrup-tivo, https://www.vox.com/future-perfect/2019/9/20/20872672/ai-learn-play-hide-and-seek. Acesso em 29/10/2019

[8] Github do programador Siraj Raval, https://github.com/llSourcell/. Acesso em 02/07/2019

[9] Livro online Deep Learning Book, http://deeplearningbook.com.br. Acesso em 25/04/2019

(48)

35 [10] BOJARSKI, Mariusz and FIRNER, Ben and FLEPP, Beat and JACKEL, Larry and MULLER, Urs and ZIEBA, Karol and DEL TESTA, David, End-to-End Deep Learning for Self-Driving Cars

[11] P´agina da Wikipedia sobre Q-Learning, https://en.wikipedia.org/wiki/Q-learning. Acesso em 31/03/2019

[12] Documenta¸c˜ao sobre Tensorboard, https://www.tensorflow.org/tensorboard/. Acesso em 25/04/2019

[13] FAYJIE, Abdur and HOSSAIN, Sabir and OUALID, Doukhi and LEE, Deok-Jin, Driverless Car: Autonomous Driving Using Deep Reinforcement Learning in Urban Environment

[14] KULKARNI, Ruturaj and DHAVALIKAR, Shruti and BANGAR, Sonal, Traffic Light Detection and Recognition for Self Driving Cars Using Deep Learning

[15] PRABHAKAR, Gowdham and KAILATH, Binsu and NATARAJAN, Sudha and KUMAR, Rajesh, Obstacle detection and classification using deep learning for trac-king in high-speed autonomous driving

[16] ZHANG, Yi and SUN, Ping and YIN, Yuhan and LIN, Lin and WANG, Xuesong Human-like Autonomous Vehicle Speed Control by Deep Reinforcement Learning with Double Q-Learning

[17] SIQUEIRA GOMES, Hugo, Towards Deep Q-Caching

[18] XIA, Wei and LI, Huiyun and LI, Baopu A Control Strategy of Autonomous Vehicles Based on Deep Reinforcement Learning

[19] Artigo Statistical Analysis System, https://www.sas.com/ptb

r/insights/analytics/machine-learning.html. Acesso em 29/10/2019

[20] Artigo Statistical Analysis System, https://www.sas.com/ptb

r/insights/analytics/neural-networks.html. Acesso em 29/10/2019