Desenvolvimento de um Simulador para um Veículo Autônomo

Universidade Federal de Minas Gerais Curso de Graduação em Engenharia de Controle e Automação Projeto Final de Curso Desenvolvimento de um Simulador para um Veículo Autônomo Guilherme Lage Becker Orientador: Luciano Cunha de Araújo Pimenta Supervisor: Guilherme Augusto Silva Pereira Belo Horizonte Novembro de 2010

Monografia Desenvolvimento de um Simulador para um Veículo Autônomo Monografia submetida à banca examinadora para avaliação curricular da disciplina PFCII, para obtenção do grau de Engenheiro de Controle e Automação. Belo Horizonte, Novembro de 2010

i Resumo Palavras-Chave: Simulação, Veículos Autônomos, Gazebo. O desafio de desenvolver um veículo autônomo envolve uma infinidade de etapas, sendo que em cada uma delas um módulo diferente é desenvolvido, envolvendo a realização de diversos testes. O Grupo de Pesquisa e Desenvolvimento de Veículos Autonômos da Universidade Federal de Minas Gerais tem trabalhado no desenvolvimento de um veículo deste tipo e a construção de um simulador computacional dentro de um ambiente realístico tornaria a realização de testes muito mais segura e barata. Este trabalho descreve todo o projeto e implementação de um modelo para este veículo em questão dentro de um ambiente de simulação. A construção de um modelo realístico deve levar em consideração diversos aspectos como a modelagem dinâmica e cinemática do veículo, a interação deste com um ambiente real e a possibilidade de interação com o usuário. O ambiente de simulação 3D Gazebo que foi usado possui código aberto e possibilita a simulação de vários robôs em um ambiente externo, com suporte a desenvolvimento de sensores e objetos e interação plausível entre os diversos elementos. Utilizando todas estas funcionalidades e os diversos dados já coletados sobre este veículo, é implementado um algoritmo que represente o modelo cinemático do carro juntamente com seus sensores. Feito isto, é criado um ambiente realístico no Gazebo e desenvolvida uma interface para que o usuário possa comandar o veículo. Obtendo um resultado satisfatório, testes passam a ser realizados com mais segurança e eficiência. Ao longo desta monografia, será detalhada a maneira de se desenvolver robôs personalizados, neste caso o veículo, para o ambiente Gazebo e como integrar a estes robôs novos módulos à medida que estes são desenvolvidos. Todo o trabalho deve ser desenvolvido com cuidado para que a simulação fique o mais próximo da realidade. Além disso, serão explicadas as etapas de desenvolvimento de um driver para o veículo e como fazer o uso de uma ferramenta na área de robótica para comandá-lo.

Abstract Keywords: Simulation, Autonomous Vehicles, Gazebo. The challenge of developing an autonomous vehicle involves a variety of steps, and in each one a different module is developed, involving the completion of several tests. The Group of Research and Development of Autonomous Vehicles from the Federal University of Minas Gerais has been developing such a vehicle and the construction of a computational simulator in a realistic environment would make testing much safer and cheaper. This work describes the entire design and implementation of a model for this vehicle in a simulation environment. The construction of a realistic simulator must take into consideration various aspects such as dynamic and kinematic modelling of the vehicle, the interaction with a real environment and the possibility of interaction with the user. The 3D simulation environment Gazebo which was used is open source and allows the simulation of multiple robots in an external environment, supports development of sensors and objects and plausible interaction among the various elements. Using all these features and the various data already collected on this vehicle, an algorithm that represents the entire kinematic model of the car along with their sensors is implemented. After that, a realistic environment in Gazebo is created and an interface is developed so that the user can operate the vehicle. Thus, tests can be performed safely and efficiently. Throughout this work, the development of customized robots, in this case the vehicle, to the environment Gazebo will be detailed and how to integrate the new modules to this robot as they are developed. All the work should be carefully developed to avoid possible errors that can make the simulation unfeasible. The steps to develop a driver for the vehicle and how to use a popular tool in robotics to control it will also be explained.

Agradecimentos Um projeto de engenharia nunca deve ser creditado somente a uma pessoa, mesmo que esta tenha desenvolvido a maior parte dele. A concretização deste projeto não teria sido possível sem a colaboração dos colegas do CORO (Laboratório de Sistemas de Computação e Robótica) e por isto gostaria de agradecer fortemente por todo o apoio e suporte. Agradeço ao meu orientador Luciano e ao meu supervisor Guilherme por todo o conhecimento a mim transmitido e por terem me dado a oportunidade e viabilizado o desenvolvimento deste projeto. Obrigado também ao professor Luiz Themystokliz pelas sugestões e ferramentas para elaboração desta monografia. Em especial gostaria de agradecer à toda minha família e amigos por todo o suporte e motivação que me deram durante este projeto e ao longo de todo o curso. Sem estas pessoas, muito provavelmente não teria atingido meus objetivos.

Sumário Resumo i Abstract ii Agradecimentos iii Lista de Figuras v Lista de Tabelas vi Siglas e Abreviações vii 1 Introdução 1 1.1 Apresentação............................... 1 1.2 A Instituição............................... 3 1.3 Motivação................................. 3 1.4 Objetivos................................. 4 1.5 Escopo do Projeto............................ 5 1.6 Organização do Trabalho......................... 5 iv

SUMÁRIO v 2 Revisão Bibliográfica 6 2.1 Veículos Autônomos........................... 6 2.2 Simulação Robótica............................ 8 2.2.1 O Software Player/Stage/Gazebo................ 9 2.2.2 Outros Simuladores........................ 14 2.2.3 Trabalhos Semelhantes na Área................. 17 3 Descrição do Processo 20 3.1 Sistemas de Atuação e Controle..................... 21 3.2 Implementações Utilizando o Player................... 23 3.2.1 Modelo do Veículo........................ 23 3.2.2 Criação de um Ambiente para o Gazebo............ 25 3.2.3 Interface de comunicação do Player com o Gazebo....... 26 3.2.4 Interface de comunicação do Player com o robô real...... 27 4 Desenvolvimento e Implementação 29 4.1 Modelo Físico do Veículo......................... 29 4.2 Ambiente para Simulação........................ 31 4.3 Desenvolvimento do Driver para o Veículo............... 32 4.3.1 Programa Cliente para Comunicação com o Driver....... 35 5 Testes e Análise de Resultados 37 5.1 Testes sobre o Simulador......................... 37 5.2 Testes no Veículo Autônomo....................... 39 6 Conclusão 42 6.1 Dos Resultados Obtidos......................... 42 6.2 Propostas de Continuidade........................ 43

SUMÁRIO vi A Códigos Fonte XML para o Simulador 44 A.1 Código XML do Modelo Físico...................... 44 A.2 Código XML do Ambiente de Simulação................ 51 Referências Bibliográficas 56

Lista de Figuras 1.1 Imagem do Ambiente de Simulação Gazebo............... 2 2.1 Imagem da parte interna do Chevrolet Astra sendo desenvolvido pelo PDVA com alguns de seus sistemas de controle............. 8 2.2 Diagrama de funcionamento das ferramentas em conjunto [15]..... 12 2.3 Estrutura geral de funcionamento do Gazebo [16]............ 12 2.4 Projeto de um robô de 6 pernas no Gazebo [6].............. 13 2.5 Projeto de engenharia reversa de um Segway utilizando o Gazebo[6].. 14 2.6 Veículo autônomo modelado no Gazebo[19]............... 19 3.1 Arquitetura projetada para controle da posição [21]........... 22 3.2 Implementação de um modelo físico no Gazebo............. 24 3.3 Implementação de juntas no Gazebo................... 24 3.4 Integração de um controlador a um modelo do Gazebo......... 24 3.5 Exemplo de um arquivo para descrição de um ambiente........ 25 3.6 Ligação entre um arquivo do Gazebo com a configuração do Player.. 26 3.7 Estrutura de um programa cliente.................... 27 vii

LISTA DE FIGURAS viii 3.8 Níveis de abstração desde um programa cliente até o robô em si.... 28 4.1 Imagem do veículo projetado para simulação.............. 30 4.2 Uso de um dispositivo laser no veículo.................. 30 4.3 Imagem ilustrativa da física que envolve a junção entre chassi e rodas dianteiras [4]................................ 31 4.4 Imagem ilustrativa do ambiente urbano desenvolvido para simulação. 32 4.5 Visualização de uma outra posição.................... 32 4.6 Estrutura de funcionamento de um driver para o Player.[8]...... 33 5.1 Visualização dos eixos de movimento................... 38 5.2 Visualização física do ambiente incluindo o laser............. 38 5.3 Sequência lógica de teste realizado.................... 40

ix Lista de Tabelas

Siglas e Abreviações PDVA: Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos da Universidade Federal de Minas Gerais CORO: Laboratório de Sistemas de Computação e Robótica da Universidade Federal de Minas Gerais (P/S/G): Player/Stage/Gazebo Project DARPA: Defense Advanced Research Projects Agency IMU: Inertial Measurement Unit GPS: Global Positioning System MRS: Multi-Robot Systems TCP: Transmission Control Protocol

CAPÍTULO 1 Introdução Esta monografia descreve todo o planejamento, execução e conclusão de um simulador para um veículo não-tripulado, sendo parte de um Projeto Final de Curso para graduando em Engenharia de Controle e Automação. Este simulador é desenvolvido em ambiente computacional e consiste em importante contribuição para os testes dos diversos sistemas automáticos presentes no veículo. 1.1 Apresentação O Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos (PDVA) da Universidade Federal de Minas Gerais vem desenvolvendo sistemas de controle automático de maneira a tornar um veículo Chevrolet Astra autônomo. Este grupo é formado por professores e alunos da universidade e é associado a alguns laboratórios que oferecem ferramentas e suporte ao desenvolvimento do veículo. Um destes laboratórios é o CORO - Laboratório de Sistemas de Computação e Robótica que está descrito na Seção 1.2. Dentro do CORO percebeu-se uma necessidade de facilitar a realização de testes sobre os sistemas desenvolvidos para o veículo e a partir disto surgiu a idéia do desenvolvimento de um simulador realístico para este automóvel. 1

1.1 Apresentação 2 O desenvolvimento de veículos não-tripulados é objeto de pesquisa cada vez mais comum em universidades e centros de pesquisa de todo o mundo. A idéia é fazer com que em algum tempo os carros sejam totalmente automáticos da mesma maneira que outros meios de transporte como trens, aviões e metrôs têm se tornado. Deste modo, os passageiros não teriam de se preocupar com a direção, podendo assim ocupar o seu tempo com outras tarefas, evitar o stress causado pelo tráfego das grandes cidades e o cansaço de longas viagens. Um outro ponto importante e que depende do desenvolvimento bem consolidado destes veículos será tornar o trânsito muito mais seguro e organizado. A idéia de se desenvolver um simulador para este veículo seria diminuir o custo e facilitar a quantidade de testes necessários. Razões mais claras para isto se encontram na Seção 1.3. Feitas algumas pesquisas, concluiu-se que este simulador deveria ser construído com o uso do ambiente de simulação 3D chamado Gazebo que pertence ao projeto Player/Stage/Gazebo (P/S/G) [14]. Este projeto desenvolve software em código aberto que permite a realização de pesquisa sobre robôs e sistemas de sensores. Assim como as razões para o desenvolvimento do simulador, motivos mais claros para a escolha deste projeto se encontram na Seção 1.3. Para efeito de visualização deste ambiente a ser utilizado, foi copiada do site do projeto [6] a Figura 1.1 que mostra dois robôs interagindo com um ambiente e seus respectivos campos de visão sensoriais. Figura 1.1: Imagem do Ambiente de Simulação Gazebo. As etapas para desenvolvimento deste projeto e os resultados esperados podem ser bem entendidos com a leitura da Seção 1.4, uma vez que nela estão descritos os principais passos e como é feita a validação deste simulador.

1.2 A Instituição 3 1.2 A Instituição O projeto é desenvolvido dentro da própria UFMG, mais especificamente no CORO - Laboratório de Sistemas de Computação e Robótica que está vinculado ao Departamento de Engenharia Elétrica da Universidade Federal de Minas Gerais. Neste laboratório são realizadas atividades de pesquisa e desenvolvimento nas áreas de robótica, visão computacional, processamento de imagens digitais, sistemas integrados de hardware e software, sistemas a eventos discretos, instrumentação e controle por computador. O CORO é um dos laboratórios associados ao Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos(PDVA) que constitui o grupo responsável pelo desenvolvimento do veículo autônomo. Diversos trabalhos voltados para o desenvolvimento de módulos que buscam a autonomia do carro foram desenvolvidos neste laboratório e têm tornado viável o objetivo de conceber um veículo totalmente autônomo. Apesar de o laboratório estar vinculado ao Departamento de Engenharia Elétrica, vários de seus membros pertencem ao Departamento de Engenharia Eletrônica e Mecânica. Isto faz com que este laboratório seja multidisciplinar devido a grande interação entre estas áreas. O CORO oferece ainda suporte à parte experimental de disciplinas ministradas para o programa de graduação em Engenharia de Controle e Automação, Engenharia Elétrica e também para o Programa de Pós Graduação em Engenharia Elétrica. 1.3 Motivação O advento de novas tecnologias torna necessário uma grande quantidade de testes quanto à eficácia, qualidade e viabilidade destes novos produtos ou serviços. Testes realizados diretamente sobre o produto em questão podem ser extremamente caros e até mesmo perigosos. Com a evolução do computador e de sua capacidade de processamento, uma maneira encontrada para reduzir o custo e risco destes testes foi o uso de simulações. Elas podem representar algo muito próximo do real e se não chegam a eliminar testes reais, ao menos os reduzem em grande quantidade. O desenvolvimento de um veículo autônomo pelo PDVA é dividido em diversas etapas e diferentes projetos, já que envolve o controle de diferentes sistemas para

1.4 Objetivos 4 tornar o veículo totalmente automático. Logo, como citado acima, uma infinidade de testes sobre o veículo são necessários. Para que estes testes sejam seguros, deve se tomar um grande cuidado, buscando um ambiente que não ofereça riscos às pessoas. Isto sem falar no custo de utilização do veículo e possibilidade de colisão devido a eventuais falhas. Estas questões motivaram a busca por uma maneira de simular este veículo para realização de testes. O ambiente Gazebo para simulação de robôs em 3D vem sendo usado com sucesso e resultados satisfatórios foram obtidos por diferentes projetos ao redor do mundo, por isto, como primeiro passo, foi feita a decisão de utilizá-lo. Um segundo ponto importante é o fato deste ambiente possuir código aberto, o que possibilita modificações necessárias para adaptação ao projeto. Outra questão importante é o fato de haver documentação mostrando como deve ser implementada toda a modelagem física de um robô, seus sensores e até mesmo a criação de ambientes. Para consumar esta escolha leva-se em conta o fato de o ambiente respeitar leis físicas de corpos rígidos para interação entre objetos e robôs. 1.4 Objetivos O desenvolvimento de um simulador para um veículo autônomo envolve três etapas críticas. São elas: Desenvolver um modelo do carro para o ambiente de simulação com controladores e sensores para uma simulação realística; Criar um ambiente de simulação dentro do simulador 3D Gazebo que represente algo próximo do mundo real para que o veículo possa ser corretamente simulado; Criar um driver de modo que um programa cliente possa se comunicar diretamente com os sistemas já desenvolvidos para o veículo autônomo através do software Player. Pelo fato de diversas pesquisas estarem em andamento e outras e já terem sido realizadas sobre este veículo, há uma enorme massa de dados que pode ser utilizada na construção do algoritmo de modelagem física e dinâmica. Espera-se que um usuário possa simular de maneira eficaz um módulo desenvolvido para o veículo. Neste caso, tendo ele obtido um resultado satisfatório, sentirá segurança para realizar testes com o veículo real.

1.5 Escopo do Projeto 5 1.5 Escopo do Projeto Neste trabalho, como se trata do desenvolvimento de um simulador computacional, a maior parte das atividades desenvolvidas é na área de programação/desenvolvimento de software. Desta maneira, conhecimentos de disciplinas como Algoritmos e Estrutura de Dados I e II, Análise Projeto e Programação Orientada a Objeto (A.P.P.O.O) e Automação em Tempo Real são profundamente necessários. O desenvolvimento de um simulador realístico envolve também toda a parte dinâmica de movimento do veículo. Desta maneira, é importante também o conhecimento de toda a modelagem física do veículo e para isto são usados conhecimentos obtidos em disciplinas como Engenharia de Controle e Laboratório de Controle e Automação I. 1.6 Organização do Trabalho O trabalho está dividido em seis capítulos. Este primeiro capítulo apresentou uma introdução ao projeto a ser descrito nesta monografia e o laboratório aonde será desenvolvido. O Capítulo 2 corresponde à revisão bibliográfica, indicando a atual situação do tema abordado e fornecendo uma base para que o leitor compreenda este trabalho. O Capítulo 3 corresponde à descrição do processo, aonde é apresentada a metodologia utilizada para execução do projeto, são feitas análises quanto aos possíveis métodos e soluções e é encerrada a parte de estudos necessários para entendimento do projeto. O Capítulo 4 apresenta as fases de desenvolvimento e implementação aonde são apresentadas soluções utilizadas e tudo que foi feito no decorrer do projeto. O Capítulo 5 corresponde à validação de tudo o que foi desenvolvido uma vez que é feita a apresentação dos testes e análise de resultados. Para finalizar este trabalho tem-se o capítulo de Conclusão. Nele são apresentadas conclusões obtidas a partir da análise dos testes.

CAPÍTULO 2 Revisão Bibliográfica Este capítulo tem como propósito abordar o atual estado de desenvolvimento do tema deste projeto. Para isto será feita uma introdução aos veículos autônomos e em que estágio se encontram as pesquisas dessa área, para em seguida tratar um tema aonde é necessário fazer maior abordagem teórica. Este tema diz respeito à simulação robótica, às ferramentas do projeto Player e à projetos de veículos já desenvolvidos com auxílio de simulação. 2.1 Veículos Autônomos Os veículos autônomos são uma tendência natural no mundo à medida em que os meios de transporte vêm se automatizando cada vez mais. Aviões, trens e metrôs já se encontram num estado de evolução que os permitem trafegar sem ação humana, mas ainda assim as pessoas se sentem inseguras para se locomover em um veículo não tripulado. Porém, a tendência é que este sentimento mude à medida em que a confiança nas novas tecnologias aumente e que esta evolução garanta menor susceptibilidade a erros do que a locomoção em meios de transporte controlados por um ser humano. Os primeiros veículos automotivos autônomos vêm sendo desenvolvidos já a um longo tempo, porém é perceptível que este desenvolvimento deu um grande salto nos 6

2.1 Veículos Autônomos 7 últimos anos. A DARPA, Agência de Projetos de Pesquisa em Defesa Avançada, é hoje o principal órgão de pesquisa do Departamento de Defesa dos Estados Unidos e vem organizando desde 2004 uma competição entre veículos autônomos chamada DARPA Grand Challenge [1]. O desafio consiste no desenvolvimento de um veículo autônomo capaz de cumprir um determinado objetivo. Nas primeiras edições, o objetivo foi o de atravessar uma região de deserto numa espécie de desafio offroad e em sua última edição envolveu trafegar em um ambiente urbano, interagindo com semáforos, edifícios, calçadas e outros veículos. A competição é aberta para times e organizações de todo o mundo, podendo envolver grupos de pesquisa de universidades ou até empresas da iniciativa privada mas com um único objetivo: o desenvolvimento de sistemas veiculares automáticos seguros que possam ser usados tanto para aplicações militares quanto comerciais [18]. Este desafio despertou o interesse de diversos órgãos e empresas para a importância do desenvolvimento de veículos não tripulados e a cada evento(2004, 2005 e 2007) tem aumentado o número de inscrições. No primeiro ano de desafio (2004), nenhum dos veículos conseguiu cumprir o desafio proposto, porém um deles atingiu a maior distância e foi considerado vencedor, sendo ele pertencente a um grupo de pesquisa da Universidade de Carnegie Mellon. Já no segundo ano (2005), cinco veículos conseguiram completar o percurso com sucesso, o que mostra um grande avanço em um espaço curto de tempo. O vencedor foi o veículo da universidade de Stanford [22] que completou o percurso proposto no menor intervalo de tempo. Na última edição do evento (2007), que envolveu o desafio de trafegar em um ambiente urbano, venceu novamente o veículo desenvolvido pela Universidade de Carnegie Mellon. Enquanto nas duas primeiras edições o desafio era muito mais o ambiente físico, de modo que os veículos apenas se encontravam em uma tentativa de ultrapassagem, nesta última edição os automóveis tinham de respeitar leis de trânsito e tomar decisões em tempo real baseadas no movimento de outros veículos. Ao longo destes anos, o que se pode ser observado foi uma rápida evolução nos diversos sistemas de controle automáticos presentes nestes veículos. Os modelos mais modernos apresentam hoje redes de sensores interligadas a um conjunto de microcontroladores juntamente com sistemas de localização do tipo GPS. Os sistemas básicos necessários para que um veículo autônomo possa trafegar com segurança são os de aceleração e frenagem do veículo, de localização e interação com o ambiente externo. O veículo Chevrolet Astra que vem sendo modificado pelo PDVA para se tornar

2.2 Simulação Robótica 8 autônomo já possui toda esta parte essencial de controle desenvolvida para que possa se locomover. Pode-se ver na Figura 2.1, adaptada de [23], alguns dos sistemas já desenvolvidos para este veículo. Dentre eles se encontram o sistema de aceleração, frenagem, câmbio e direção, além de um computador acoplado e um joystick pelo qual pode-se guiar o veículo. Além disso já foram implementados sistemas de GPS 1 juntamente com IMU 2 para localização. Todos os módulos citados e apresentados na figura já foram testados com sucesso, de modo que o veículo já tem capacidade de se mover de maneira independente. Figura 2.1: Imagem da parte interna do Chevrolet Astra sendo desenvolvido pelo PDVA com alguns de seus sistemas de controle. 2.2 Simulação Robótica Uma outra maneira de classificar veículos autônomos é considerá-los robôs, o que envolve uma imensa área de pesquisa que é a robótica. A capacidade de programação da locomoção do veículo sem o controle de um ser humano ou o seu comando à distância o coloca na mesma posição de robôs equipados com sensores e capazes de agir de maneira autônoma. 1 GPS - Global Positioning System - Sistema de posicionamento global baseado em satélites com localização dada por coordenadas geográficas. 2 IMU - Inertial Measurement Unit - Dispositivo eletrônico capaz de medir velocidade, orientação e forças gravitacionais baseado em acelerômetros.

2.2 O Software Player/Stage/Gazebo 9 Para diminuir o custo e o tempo de pesquisa no desenvolvimento de robôs, grupos de pesquisa têm investido em maneiras de criar aplicações embarcadas para um robô sem depender fisicamente dele. A maneira mais usual de fazer isso é por meio de simulações computacionais. Muitas vezes, as aplicações desenvolvidas em um ambiente de simulação podem ser transferidas diretamente ao robô real com mínimas modificações. 2.2.1 O Software Player/Stage/Gazebo O projeto Player, mais conhecido pelo seu nome em língua inglesa The Player Project, é o nome dado a um projeto de desenvolvimento de ferramentas que auxiliam na pesquisa de sistemas robóticos e de sensores. Segundo [14], este projeto começou na University of Southern California(USC) em 1999 devido a uma necessidade interna de interfacear e simular sistemas multi-robôs (MRS). De acordo com [17], todo o código desenvolvido foi movido para a comunidade de código aberto para facilitar a propagação e adaptação do programa a diferentes necessidades. Estas ferramentas auxiliam na programação e simulação de robôs por possibilitar o desenvolvimento de aplicações para um robô sem depender fisicamente dele. Os programas já desenvolvidos pelo projeto podem ser divididos em três partes básicas. O programa Player que se encontra na versão 3.0.1, o plugin de simulação 2D Stage que está na versão 3.2.2 e o plugin de simulação 3D Gazebo que é o membro mais recente e se encontra na versão 0.10.0. Uma questão importante é o fato de o Stage e o Gazebo só funcionarem em sistemas operacionais do tipo POSIX que são aqueles baseados em Unix como Linux, Solaris e Mac OSX. O Player tinha a mesma restrição até pouco tempo atrás quando foi lançada uma versão para Windows. O Player O programa Player é uma espécie de servidor desenvolvido para rodar em um robô real que fornece uma interface simples para todos os sensores e atuadores do robô via rede. Ou seja, seu modelo permite que programas para controle de robôs rodando em uma máquina qualquer se comuniquem com o robô de acordo com o modelo Cliente/Servidor, que é consagrado no mundo da computação. Segundo [6], os programas cliente se comunicam com o Player através de sockets na camada TCP - Transmission Control Protocol. Isto permite que os programas cliente sejam desenvolvidos praticamente em qualquer linguagem, uma vez que a

2.2 O Stage 10 grande maioria delas oferece suporte a este tipo de comunicação. A ideia básica dos programas cliente desenvolvidos é enviar comandos para atuadores e ler dados de sensores para realizar controle sobre os robôs de uma maneira limpa e simples, além de possibilitar a configuração de dispositivos durante o uso. O Player já oferece suporte a uma grande variedade de dispositivos de hardware para robôs, sendo ele feito através do desenvolvimento de drivers para comunicação entre o Player e o dispositivo. Além disso, possui implementações sofisticadas de algoritmos comuns necessários como os de rastreamento e localização. É possível também que novos algoritmos sejam desenvolvidos de acordo com a necessidade para tornar o Player ainda mais customizado em função de determinados interesses, assim como novos drivers para se incluir a comunicação com novos dispositivos. Outro aspecto importante do Player é o fato de este permitir o acesso de diversos programas cliente de maneira simultânea. Isto permite que diversos clientes enviem comandos a um mesmo servidor Player de diferentes localidades. De acordo com [14], não existe implementado nenhum tipo de sincronização para este caso, de modo que não existe uma fila de comandos e o último comando enviado sobrescreverá o anterior. Isto foi feito para dar maior flexibilidade aos programas cliente. Outro aspecto também é a suposição de que programas clientes diferentes são colaborativos, ou seja, se múltiplos programas comandam um único dispositivo, estes clientes devem estar ajudando uns aos outros. O Stage O Stage é um ambiente para simulação de robôs em duas dimensões que suporta múltiplos robôs, sensores e objetos sendo altamente configurável. Este ambiente tem como objetivo possibilitar o rápido desenvolvimento de controladores que eventualmente funcionarão em robôs reais e possibilitar experimentações sem acessar o objeto real, ou seja, simulações. Os softwares Player e Stage são totalmente compatíveis, de modo que um programa cliente desenvolvido pode comunicar tanto com o um robô real quanto com o Stage sem nenhuma modificação de código via servidor Player. Este fator possibilita o que tanto se busca com a simulação robótica conforme citado na Seção 2.2. Um aspecto importante é que o Stage é capaz de simular uma quantidade enorme de robôs chegando ao número de centenas, o que é interessante quando se deseja analisar a interação entre vários robôs. Esta é a grande diferença dele para o ambiente Gazebo, que será apresentado na tópico a seguir. Neste texto se dará maior enfoque

2.2 O Gazebo 11 ao Gazebo pelo fato de o simulador a ser desenvolvido contemplar um único robô que é o veículo autônomo. Porém, ambos os ambientes desempenham papel equivalente e a maioria dos conceitos se aplica de maneira semelhante aos dois. O Gazebo O Gazebo, assim como o Stage, é um ambiente de simulação de robôs, porém em três dimensões levando em conta a dinâmica dos objetos simulados. Isto possibilita simulações com grau de fidelidade bem maior que as do Stage. No entanto, este fator gera maior complexidade na simulação, o que é computacionalmente mais caro e impossibilita a simulação com um número tão grande de robôs, a não ser que eles sejam extremamente simples e sem muitas funcionalidades. Assim, em geral, a simulação é feita com até vinte robôs. No entanto, em uma visão global, o objetivo do Gazebo é o mesmo que o do Stage: possibilitar ao usuário o desenvolvimento de controladores que eventualmente funcionarão em robôs reais podendo testá-los anteriormente em um ambiente de simulação. O Gazebo também é totalmente compatível com o Player podendo um mesmo programa cliente se comunicar com o Gazebo ou com o robô real via servidor Player. Para melhor entendimento do funcionamento destas ferramentas em conjunto, foi copiada do tutorial de um dos usuários do ambiente e estudante de pós-graduação da universidade aonde se iniciou o projeto [15] a Figura 2.2 que mostra a estrutura de funcionamento. Como pode ser visto, o programa cliente recebe dados ou envia comandos através de comunicação TCP. O servidor Player usando a mesma comunicação do tipo TCP conversa tanto com o ambiente de simulação Stage quanto com o hardware real, que no caso seria um robô. Já o Gazebo se comunica com o Player por memória compartilhada para garantir melhor velocidade e eficiência. Para melhor examinar o caso de interesse neste projeto, pode-se utilizar a estrutura geral dos componentes do Gazebo mostrada na Figura 2.3 de acordo com [16]. Como pode-se ver, o programa cliente desenvolvido se comunica com o Gazebo por memória compartilhada utilizando uma interface. A interface é ligada a um modelo que se subdivide em duas partes principais: o ambiente em si aonde o robô em questão será simulado e o próprio robô ou robôs. Os robôs podem ainda ser divididos em três partes que são: O corpo físico e suas características; Os sensores responsáveis pelo envio de dados;

2.2 O Gazebo 12 Figura 2.2: Diagrama de funcionamento das ferramentas em conjunto [15]. Os atuadores que recebem os comandos. Figura 2.3: Estrutura geral de funcionamento do Gazebo [16]. Pode-se ver ainda na Figura 2.3 uma parte ligada à estrutura do Gazebo chamada de Open Dynamics Engine (ODE). Esta é uma biblioteca para física de objetos muito usada na comunidade de código aberto que foi desenvolvida por Russel Smith [4]. Ela é usada para simular a dinâmica e os movimentos associados a corpos rígidos articulados que é o caso de robôs. Para auxiliar o funcionamento do Gazebo é utilizado ainda o GLUT (OpenGL Utility Toolkit) [5] que corresponde a uma

2.2 O Gazebo 13 ferramenta para visualização de aplicações gráficas que fazem o uso da biblioteca OpenGL. Segundo [16], apesar de ainda ser um software bem recente, o Gazebo já foi usado para várias diferentes metodologias de projeto que não seriam possíveis em outros simuladores. Um dos projetos citados possui questões de morfologia e controle. Desenvolver arquiteturas robóticas envolve questões como a do ovo e da galinha: Seria melhor desenvolver um sistema de controle compatível com o hardware ou o hardware compatível com o controle necessário? A solução é a prototipação aonde ambas as soluções são desenvolvidas de maneira simultânea e em partes com testes intermediários. Utilizando este princípio de projeto foi desenvolvido na USC um robô andante de seis pernas como pode visto na Figura 2.4 obtida do site do projeto Player [6]. A construção do hardware teria tomado um tempo enorme porém, a simulação e testes em várias etapas agilizou o processo. Figura 2.4: Projeto de um robô de 6 pernas no Gazebo [6]. Um outro exemplo citado por Koenig e Howard em [16] foi o uso de engenharia reversa para melhor entendimento e sintonização do controle de um equipamento. Trata-se de um Segway, que é um objeto físico desenvolvido para o transporte de pessoas que seria algo como um patinete motorizado. Este meio de transporte tem a dinâmica muito similar a de um pêndulo invertido e testar modificações pode ser extremamente perigoso devido à sua instabilidade. Logo, para isso foi criado o modelo de um Segway no Gazebo como pode ser visto na Figura 2.5 obtida do site do projeto Player [6]. O controle usado no hardware real foi transferido para o modelo de simulação e com isso foi possível sintonizar melhor o controlador e realizar

2.2 Outros Simuladores 14 testes para diversas condições com segurança. desenvolvidas foram replicadas ao Segway real. Ao final do projeto, as melhorias Figura 2.5: Projeto de engenharia reversa de um Segway utilizando o Gazebo[6]. Além desses, diversos outros tipos de projetos com diferentes objetivos podem ser desenvolvidos no Gazebo. Existem ainda projetos para melhoria de algoritmos ou até mesmo para simulação de um robô dentro de um novo ambiente. Isto mostra a flexibilidade desta ferramenta quando se envolve simulação robótica. Como todo simulador, o Gazebo também possui algumas limitações importantes. Por ser um simulador desenvolvido para ambientes externos, possui algumas questões que não estão implementadas como os modelos físicos de um solo, areia ou grama que fogem do escopo do projeto. Além disso, o ambiente não contempla ainda objetos deformáveis e fenômenos de termodinâmica e dinâmica dos fluidos devido à alta complexidade computacional. Porém, alguns destes itens citados podem ser incluídos à medida em que se verifique sua necessidade. 2.2.2 Outros Simuladores Apesar de os softwares do projeto Player terem sido tratados com maior detalhe pelo fato de serem a ferramenta utilizada neste projeto, existem ainda outros simuladores para a área da robótica. Dentre eles se encontram alguns com código aberto, nenhum deles tão completo e desenvolvido quanto o Gazebo, e vários outros comerciais. Serão abordados neste texto dois dos simuladores comerciais mais utilizados que são o

2.2 Webots 15 Webots desenvolvido pela Cyberbotics Ltd e o Microsoft Robotics Developer Studio que como seu nome já diz é desenvolvido pela Microsoft. Os motivos para a escolha dos softwares do projeto Player em detrimento dos outros que serão apresentados abaixo são: Os softwares do Player possuem código aberto, o que possibilita adaptações no código caso necessário; As ferramentas são gratuitas não sendo necessário nenhum tipo de licença; Os softwares rodam em um sistema operacional gratuito de larga escala que é o Linux; Diversos projetos já foram desenvolvidos no mundo fazendo o uso destas ferramentas com sucesso; Grande comunidade desenvolvedora oferecendo suporte; Experiências prévias de pesquisadores integrantes do laboratório CORO. Webots O Webots, assim como o Gazebo, é um simulador robótico profissional usado largamente para propósitos comerciais e educacionais. O projeto Webots teve início em 1996 no Swiss Federal Institute of Technology em Lausanne na Suiça. Anos depois, com o sucesso do projeto, este software passou a ser desenvolvido comercialmente e hoje é controlado pela Cyberbotics Ltd. As semelhanças com o Gazebo são muitas. De acordo com [9], o Webots inclui um conjunto de sensores e atuadores frequentemente usados em experimentos robóticos e também um conjunto de modelos de robôs que podem ser livremente modificados. É possível ainda utilizar o Webots para construir novos modelos aonde se define suas propriedades gráficas que incluem o formato, dimensões, cores e texturas e suas propriedades físicas que consistem em massa, fatores de fricção e até mesmo constantes de mola e amortecimento. Além disso, o Webots faz uso também da Open Dynamics Engine (ODE) [4] para simular a dinâmica de corpos rígidos. Os programas para controle de robôs que se comunicam com o Webots podem ser escritos em uma variedade de linguagens de programação como C, C++, Java e MATLAB e o Webots funciona nos sistemas operacionais mais comuns da atualidade incluindo aí o Windows, Mac OS X e Linux.

2.2 Microsoft Robotics Developer Studio 16 A maior desvantagem do Webots é o fato de este ser um software pago de alto custo. Ele é vendido hoje em dia em duas versões, sendo uma educacional dedicada ao ensino de robótica em salas de aula e uma versão profissional mais completa dedicada ao desenvolvimento com intuito comercial. O Webots possibilita também a transferência de programas de controle a um robô real. Neste caso, o programa de controle deve rodar em um computador enviando comandos e lendo dados do robô real ao invés do robô simulado. Para atingir isto, é necessário que o usuário escreva sua própria implementação da Application Programming Interface (API) de funções do Webots como uma pequena biblioteca. Alguns projetos já foram desenvolvidos com o auxílio do Webots. A título de exemplo podemos citar o projeto de desenvolvimento de um robô usado como aspirador de pó e outro como cortador de grama. Em [13] Ganapathy e Lui mostram como isso foi feito e como o Webots auxilia de modo a facilitar este desenvolvimento. Um outro exemplo interessante é a chamada RobotStadium que consiste numa competição online de futebol de robôs baseada no simulador Webots. Seu objetivo é uma simulação prévia de modo a auxiliar times que participarão da RoboCup, uma competição de robôs reais que envolve a disputa de um jogo de futebol. Microsoft Robotics Developer Studio O Microsoft Robotics Developer Studio, muito conhecido por sua sigla MRDS, é um ambiente para controle e simulação de robôs totalmente baseado na plataforma Windows. De acordo com [2], o MRDS faz uso da Concurrent and Coordination Runtime (CCR), uma biblioteca de programação concorrente baseada na plataforma.net da Microsoft. Esta biblioteca faz o controle de tarefas paralelas usando troca de mensagens o que possibilita a coordenação de múltiplos serviços para atingir comportamentos complexos como são os dos robôs. O MRDS inclui uma ferramenta de programação visual usada para criar e depurar aplicações para robôs, interfaces baseadas em Windows e web, simulação em três dimensões e acesso simples a sensores e atuadores. Estas são características em geral comuns a todos as ferramentas de desenvolvimento de robôs existentes. Porém, diferentemente do Webots e do Gazebo, o MRDS faz uso da biblioteca chamada PhysX [3] para simulação da dinâmica de corpos rígidos. Apesar de diversos projetos interessantes terem sido desenvolvidos a partir do MRDS, o programa não foi o sucesso que a Microsoft esperava. Em um movimento com o objetivo de expandir a base de usuários e estabelecer vínculos, a companhia tomou

2.2 Trabalhos Semelhantes na Área 17 uma atitude que pode ser chamada de inesperada para uma companhia como ela. A partir de 2008, o MRDS deixou de ser vendido e o seu download pode ser feito diretamente do site da oficial da Microsoft. Isto deve tornar esta ferramenta cada vez mais utilizada devido a todo o suporte que a companhia fornece. Porém, ainda há uma grande limitação em relação ao Gazebo: o fato de não possuir código aberto impossibilita a modificação de código, que é muitas vezes necessário para adaptações de projeto. Dentre projetos desenvolvidos com o auxílio do MRDS, encontram-se diversos projetos de robôs menores, porém há um projeto que se destaca no campo de interesse desta monografia que corresponde ao veículo desenvolvido pela universidade de Princeton para o desafio DARPA que será descrito com mais clareza na próxima seção. 2.2.3 Trabalhos Semelhantes na Área Após uma grande busca por projetos semelhantes aos que envolvem o tema desta monografia, alguns trabalhos foram encontrados no que diz respeito ao uso de uma ferramenta com interface de simulação para o desenvolvimento de veículos autônomos. Em geral os projetos encontrados com desenvolvimento utilizando simulação dizem respeito à robôs menores, porém dois trabalhos se mostraram bastante interessantes por apresentarem o uso de simulação no auxílio ao desenvolvimento de veículos para o desafio DARPA. Ambos os trabalhos encontrados dizem respeito a veículos desenvolvidos para a versão urbana do desafio DARPA Grand Urban Challenge no ano de 2007. Este desafio foi citado na Seção 2.1 como um dos principais alavancadores de pesquisa e desenvolvimento de veículos autônomos. Um dos projetos pertence a Universidade de Princeton nos Estados Unidos que através do Princeton Autonomous Vehicle Engineering (PAVE), que corresponde ao seu grupo de desenvolvimento de veículos autônomos, desenvolveu um dos veículos participantes do desafio. De acordo com [7], a universidade participou do desafio urbano fazendo o uso de um veículo Ford Escape modelo 2005 equipado com sistema de aceleração eletrônico, direção controlada por potência eletrônica e sistema de frenagem regenerativo também eletronicamente controlado. Neste projeto, ao invés de construir atuadores para este sistema, a universidade optou por interfacear diretamente com os sistemas eletrônicos presentes, diferentemente do veículo sendo desenvolvido pelo PDVA, aonde apenas a aceleração é controlada desta maneira.

2.2 Trabalhos Semelhantes na Área 18 O processamento necessário para comando do veículo é feito por quatro servidores independentes interligados aos sistemas do veículo. Todas as câmeras e sensores também estão ligados a estes servidores para que leitura e interpretação dos dados possa ser feita de modo a enviar os comandos calculados aos sistemas eletrônicos citados. Além disso, os servidores possuem conexão com a internet possibilitando comandos de maneira remota. Todos os servidores presentes rodam o sistema operacional Microsoft Windows Server 2003 equipados com a ferramenta de auxílio a desenvolvimento de programas robóticos Microsoft Robotics Developer Studio. A capacidade do MRDS de tratar diversos serviços concorrentemente funcionou de forma satisfatória. Anteriormente a toda esta aplicação do MRDS para tratar os diversos serviços necessários para comando do veículo, foi feita uma simulação utilizando a interface em 3D para verificar possíveis problemas a serem enfrentados e situações de risco. Atingindo os objetivos satisfatoriamente, todo o código desenvolvido pôde ser movido diretamente para o veículo sem a necessidade de modificação. Já o outro trabalho encontrado pertence a Ohio State University também nos Estados Unidos e se mostra ainda mais interessante por fazer o uso dos softwares do projeto Player para auxílio no desenvolvimento. Através de seu grupo de pesquisa e desenvolvimento de veículos autônomos conhecido como Autonomous City Transport, a universidade escolheu um Toyota Highlander do tipo híbrido. Este veículo apresenta diversas facilidades no que diz respeito a torná-lo autônomo. Tanto o seu sistema de aceleração, quanto o de frenagem e o de transmissão podem ser controlados eletronicamente, o que agiliza bastante o processo e facilita o controle por não ter de envolver atuadores externos. Por se tratar de um veículo para um desafio urbano, as dificuldades são muito maiores já que envolvem a interação com diversos outros veículos e obstáculos e o fato de ter que passar por cruzamentos, semáforos e até mesmo situações de estacionamento. Por estes motivos o uso de simulação para se avaliar diversas situações possíveis se mostrou interessante. De acordo com [19] os ciclos de desenvolvimento e testes do carro fazendo uso do Gazebo podem ser divididos em duas partes. A primeira trata da representação realística do modelo do veículo. Tanto as características físicas do veículo como forma, peso e tamanho quanto as características dinâmicas como comportamento de aceleração, frenagem e direção estão incluídas no modelo utilizado. Um grande número de sensores, tais como receptores GPS e lasers também estão inclusos no modelo para que se possa simular toda a parte de fusão de sensores para tomada de decisão.

2.2 Trabalhos Semelhantes na Área 19 A segunda parte diz respeito ao ambiente aonde será simulado este veículo e contêm características de gravidade e fricção assim como possibilita a criação de objetos e situações customizadas. A Figura 2.6 retirada de [19] apresenta uma situação aonde o veículo em questão deve enfrentar um cruzamento interagindo com um outro veículo. Figura 2.6: Veículo autônomo modelado no Gazebo[19]. Maiores detalhes quanto ao uso de simulação neste projeto e quanto a transposição do código desenvolvido para o veículo real não foram citados, porém o uso da simulação se mostrou um facilitador nos testes do veículo.

CAPÍTULO 3 Descrição do Processo Este capítulo fará uma breve apresentação dos sistemas de atuação presentes no veículo juntamente com seu modelo cinemático e como foi o desenvolvimento deste modelo para o Gazebo. Em seguida é apresentada a construção de um ambiente dentro do Gazebo para finalmente ser feita uma apresentação de como será feita a interface entre o Player e o Gazebo ou entre o Player e os sistemas de atuação presentes no veículo. O veículo de passeio sobre o qual este trabalho foi desenvolvido é um Chevrolet Astra. Este carro possui motor 2.4 com 16 válvulas e 130 cavalos de potência. Dentre algumas características importantes do veículo estão câmbio automático, direção hidráulica e sistema eletrônico de aceleração. Em seu atual estágio de desenvolvimento acredita-se que este veículo possua instrumentação suficiente para transitar de maneira autônoma em ambientes aonde não haja trânsito de outros carros e pessoas, uma vez que os sistemas de detecção e desvio de obstáculos e de interação com outros objetos ainda se encontram em desenvolvimento. 20

3.1 Sistemas de Atuação e Controle 21 3.1 Sistemas de Atuação e Controle Segundo Sabbagh[20] dentre os sistemas de atuação que já se encontram automatizados estão os quatro mecanismos básicos para condução do veículo. São eles: Sistema de câmbio; Sistema de frenagem; Sistema de aceleração; Sistema de direção. Eles correspondem ao primeiro passo quando se deseja desenvolver um veículo autônomo e foram apresentados na Figura 2.1. Dentre esses mecanismos, o câmbio, o freio e a direção são comandados por atuadores eletromecânicos e o acelerador é controlado diretamente de maneira eletrônica em função da presença de um sistema de aceleração eletrônico no veículo. Todos estes sistemas são controlados por microcontroladores embarcados no carro que estão ligados a um computador via porta USB, ou seja, é possível operar todos eles via software. O sistema de câmbio teve maior facilidade de ser desenvolvido pelo fato de o veículo possuir câmbio automático. Deste modo, não é necessário se preocupar com o acionamento da embreagem e nem mesmo com a troca da primeira até a quinta marcha. Com isso, toda a atuação necessária é feita com o movimento de um braço robótico para frente ou para trás entre os modos de estacionamento, ponto morto, condução em marcha ré e condução convencional para a frente. Controlado por um microcontrolador, o braço é capaz de fazer a mudança entre os diferentes modos. O sistema de aceleração tem um detalhe interessante que é o fato de seu comando já ser eletrônico, ou seja, o veículo possui um módulo eletrônico interno responsável por transformar a atuação sobre o acelerador em um comando eletrônico mais preciso e eficiente. Deste modo, atuando diretamente sobre este módulo, foi possível criar uma maneira de se chavear entre o modo manual da aceleração, feito através do pedal e o modo automático, controlado via software. Quando comandado em modo automático, o acionamento da velocidade desejada é feito através de um sinal PWM - Pulse Width Modulation(Modulação por Largura de Pulso) correspondente enviado diretamente ao módulo eletrônico que controla a aceleração. O sistema de frenagem do veículo foi desenvolvido como um Projeto Final de Curso de Engenharia de Controle e Automação pelo aluno Tiago Mendonça da Silva [11].

3.1 Sistemas de Atuação e Controle 22 Inicialmente um motor de corrente contínua acoplado à uma caixa de redução e a uma alavanca são responsáveis por transmitir ao pedal de freio o torque desejado. O controlador implementado faz o controle do torque que se deseja aplicar ao pedal e possui também uma interface com o sistema de emergência do veículo para situações aonde seja necessário frear bruscamente. Mais tarde, o sistema de freio foi aprimorado como parte de um Trabalho de Conclusão de Curso de um aluno de Engenharia Elétrica chamado Maurício F. Baleeiro[10]. Nesta melhoria foi acoplado ao carro um atuador linear microcontrolado para fazer o acionamento do freio. Para encerrar a descrição dos sistemas básicos presentes tem-se o sistema de direção. Para controle da direção das rodas dianteiras, foi usado um motor de corrente contínua acoplado a uma caixa de redução. O motor recebe comandos de um microcontrolador capaz de controlar sua posição, velocidade e corrente. Deste modo, quando acionado, este sistema faz com que a direção gire para a posição desejada. Além destes importantes sistemas já implementados, há ainda um importante sistema de controle de posição e atitude. Este foi desenvolvido também por uma aluna de mestrado chamada Michelle Mendes Santos[21] e reúne a informação proveniente de diversos sensores para calcular a ação a ser tomada pelo veículo. Dentre esses sensores se encontra um GPS e uma IMU juntamente com um sensor de orientação das rodas dianteiras e um sensor de velocidade das rodas. Os sinais provenientes destes sensores são reunidos por meio de fusão sensorial para que o software seja capaz de calcular os comandos necessários aos sistemas básicos do veículo como mostrado na Figura 3.1. Com o uso deste sistema, um aluno de Projeto Final de Curso em Engenharia de Controle e Automação[20] desenvolveu um projeto para que fosse possível programar uma trajetória para o veículo através da marcação de coordenadas com o sistema de GPS por exemplo. Figura 3.1: Arquitetura projetada para controle da posição [21].

3.2 Implementações Utilizando o Player 23 3.2 Implementações Utilizando o Player Esta seção apresenta a maneira como são feitas as implementações visando o desenvolvimento de um simulador utilizando as ferramentas do projeto Player. Isto deve passar pela criação do modelo físico e dinâmico do carro, pela criação de um ambiente de simulação e pelo desenvolvimento de uma interface entre o servidor Player e os comandos presentes nos módulos do veículo. 3.2.1 Modelo do Veículo A modelagem de um robô qualquer dentro do Gazebo contém algumas propriedades chave. São elas a presença física e a interface. A interface em si será abordada na seção 3.2.3. A presença física do robô envolve os seguintes itens: Corpo - uma esfera, uma caixa ou uma composição de formas; Cinemática - as juntas e velocidades; Dinâmica - a massa, fricção e forças envolvidas; Aparência - cor e textura. O primeiro passo para criação de um robô envolve a descrição de sua parte física. Isto é feito através de um arquivo do tipo XML com a extensão *.model. É possível criar corpos com múltiplas geometrias nesta estrutura como mostra a Figura 3.2. Neste caso, está se tratando da composição de dois corpos sendo o principal um cilindro e o secundário mais interno que está acoplado ao cilindro uma peça retangular. As diferentes tags do arquivo dizem respeito às características como rotação, tamanho, densidade e material. Muitas vezes torna se necessária a criação de juntas entre diferentes objetos. Isto também é possível de ser feito através de código XML. Diferentes tipos de juntas podem ser criadas, desde juntas simplesmente físicas sem movimento algum a juntas como dobradiças que tem movimento limitado ou juntas esféricas que tem movimento ilimitado. A junta de uma roda ao chassi de um veículo poderia ser descrita pelo código apresentado na Figura 3.3. As tags deste tipo de descrição dizem respeito a detalhes como o quanto uma dobradiça pode dobrar e aonde os corpos sendo conectados.

3.2 Modelo do Veículo 24 Figura 3.2: Implementação de um modelo físico no Gazebo. Figura 3.3: Implementação de juntas no Gazebo. Muitos modelos dentro do Gazebo requerem a necessidade de movimento e de leitura de dados de sensores como é o caso do veículo autônomo. A integração de controladores a modelos é também feita através de código XML apesar de o código propriamente dito destes controladores não estar implementado neste tipo de linguagem. Controladores são compilados e integrados a modelos do Gazebo como apresenta o código da Figura 3.4. Neste exemplo é feita a integração de um controlador de posição a um robô chamado Pioneer2dx. Os dois primeiros filhos do arquivo XML correspondem às rodas do veículo que são os parâmetros sobre os quais será feito o controle e o último filho define a interface sobre a qual o controlador irá ler dados e escrever comandos. Este detalhe será melhor explicado na Seção 3.2.3. Figura 3.4: Integração de um controlador a um modelo do Gazebo. Estes constituem os passos básicos na criação de um modelo para o Gazebo. Há ainda alguns detalhes importantes do tipo como se criar um novo sensor ou atuador para o Gazebo, porém estes não serão abordados neste trabalho e maiores informações podem ser obtidas no site do projeto [6].

3.2 Criação de um Ambiente para o Gazebo 25 3.2.2 Criação de um Ambiente para o Gazebo Para rodar o ambiente de simulação Gazebo é necessário o uso de um arquivo com extensão*.world. Este arquivo é do tipo XML e contém informações a respeito dos itens que compõem o ambiente, da organização física do ambiente e dos modelos que devem ser carregados para o ambiente. Modelos podem ainda estar integrados, ou seja, um robô constitui um modelo e um sensor é também um modelo. Neste caso, este arquivo também especifica como modelos que devem estar integrados estão conectados fisicamente. A figura 3.5 apresenta um exemplo de como seria a descrição destes modelos em um arquivo. Figura 3.5: Exemplo de um arquivo para descrição de um ambiente. Este código possui a descrição de um modelo de robô simples chamado Pioneer2AT composto de um dispositivo laser ligado à ele. As coordenadas <xyz> dizem respeito à posição relativa do laser em relação ao robô. Dentre outros parâmetros globais que podem ser descritos no arquivo *.world encontrase também a força da gravidade, a cor do céu e texturas de objetos. Devido a grande quantidade de desenvolvedores para este ambiente de simulação atualmente, o Gazebo já possui implementado uma infinidade de modelos tanto de objetos sólidos como de terrenos, sensores e atuadores disponibilizados por colaboradores. Um outro detalhe interessante é a possibilidade de chamar um arquivo do tipo *.inc dentro do arquivo *.world. Este tipo de arquivo contém exatamente o mesmo conteúdo e facilita a replicação de um mesmo código a diversos ambientes. Por exemplo, quando se usa composições equivalentes de modelos dentro de vários ambientes, caso seja feita uma mudança na composição, esta não precisa ser replicada a todos os arquivos.

3.2 Interface de comunicação do Player com o Gazebo 26 3.2.3 Interface de comunicação do Player com o Gazebo Esta subseção diz respeito à maneira como o Player se comunica com o Gazebo. O Player é um programa à parte que funciona como um servidor e deve rodar separadamente, porém deve apontar para uma instância do Gazebo. O Player possui já implementados um grande número de interfaces e controladores que podem ser usados para comunicação com os modelos do Gazebo. É importante que o Player saiba quais sensores e atuadores o Gazebo está usando e isto é feito através da indicação por um arquivo *.cfg ao Player quando este for inicializado. Este arquivo corresponde ao arquivo *.world do Gazebo para o Player e estão ligados como apresentado na Figura 3.6. Figura 3.6: Ligação entre um arquivo do Gazebo com a configuração do Player. Feita esta ligação implementada entre o Player e o Gazebo, torna se possível rodar um programa cliente desenvolvido que enviará comandos ao Player através de interfaces para que estes sejam enviados ao robô simulado. O programa cliente é responsável por fazer o controle dos dados lidos e enviados ao robô. O fato de utilizar comunicação via protocolo TCP dá ao usuário uma grande liberdade na hora de escolher a linguagem na qual deseja desenvolver seu programa cliente uma vez que praticamente todas as linguagens fornecem suporte a este tipo de comunicação. Programas em geral desenvolvidos para comunicação com o Player possuem a estrutura apresentada pela Figura 3.7. Com a leitura de dados provenientes de sensores é possível desenvolver algoritmos de controle para enviar os comandos desejados a atuadores. Com isto torna se possível no caso de um veículo, aplicar algoritmos de controle de posição, velocidade, detecção de obstáculos, dentre outros. Para isto, estes programas devem instanciar um certo modelo de robô e sensores e atuadores ligados à este. Através dos métodos fornecidos pelas interfaces dos senso-

3.2 Interface de comunicação do Player com o robô real 27 Figura 3.7: Estrutura de um programa cliente. res e atuadores realizar o controle da maneira desejada. Estas interfaces presentes são exatamente as que foram citadas na seção 3.2.1 no que diz respeito à designação de controladores a um certo modelo. 3.2.4 Interface de comunicação do Player com o robô real Esta seção trata aquele que talvez seja o maior motivo de sucesso da plataforma P/S/G que consiste no fato de um programa cliente ter a possibilidade de comunicar com o servidor Player e este tratar da comunicação com o robô real ou com o Gazebo. Deste modo, o programa cliente que for testado sobre o Gazebo, poderá ser diretamente replicado para rodar no veículo. A comunicação do servidor Player com dispositivos de hardware deve ser feita através de um driver, que fará o link e a comunicação entre a interface chamada pelo programa cliente e o robô real. Alguns dispositivos comuns já possuem drivers implementados, o que não é o caso do veículo autônomo em questão. Logo, foi necessária a construção de um programa como esse para fazer a ponte entre o Player e o veículo. A Figura 3.8 demonstra com mais clareza a necessidade deste driver. Como pode ser visto, acima de tudo existe um programa cliente que possui uma lógica desenvolvida para controle do robô. Logo abaixo, chamada de proxy, está a interface que receberá os comandos do programa cliente e enviá-los da maneira correta ao servidor Player ou receberá requisições de dados que deverão ser buscados para ser retornados. O Player será o responsável pela comunicação ou com o Gazebo ou com o robô real, como no caso desta figura. Entre ele e o robô deverá ainda

3.2 Interface de comunicação do Player com o robô real 28 Figura 3.8: Níveis de abstração desde um programa cliente até o robô em si. existir um driver que fará a comunicação entre a interface e os dispositivos. Isto é,corresponde a tradução de uma linguagem simples na interface para uma que os dispositivos entendam.

CAPÍTULO 4 Desenvolvimento e Implementação Este capítulo irá tratar o desenvolvimento das etapas já citadas para correto funcionamento do simulador. Nele serão apontados maiores detalhes de como foram feitas algumas coisas e algumas das dificuldades encontradas durante o desenvolvimento. 4.1 Modelo Físico do Veículo O primeiro passo durante o desenvolvimento do projeto foi desenvolver um modelo físico do veículo para o Gazebo que correspondesse com as características físicas do veículo real. Para isto foi necessário uma grande quantidade de detalhes do veículo que incluem comprimento, largura, peso, diâmetro das rodas, distância entre eixos, dentre outros. Estes dados foram replicados a um código XML como apresentado na Seção 3.2.1 para dar uma forma ao veículo condizente com sua representação real. Obviamente o Gazebo possui algumas limitações e é impossível fazer isto com perfeição por detalhes como a presença unicamente das formas esféricas, cilíndricas e retangulares. Duas imagens do veículo projetado podem ser vistas nas Figuras 4.1 e 4.2. Como citado anteriormente, não há uma riqueza grande de formas no Gazebo e o veículo tem uma aparência quadrada. Um detalhe importante que também se encontra no 29

4.1 Modelo Físico do Veículo 30 código XML do veículo é a descrição da interface a ser utilizada para comunicação com o Player que corresponde a uma interface de controle de posição em duas dimensões. Ainda no código XML está a descrição do controlador que fará a atuação sobre o robô, que corresponde a um controlador para um veículo não holonômico. Juntamente com esta descrição, se encontram valores importantes para construção desta interface como o ângulo máximo de giro das rodas, quais as rodas que tracionam, quais rodas podem girar e o torque de cada uma delas. Figura 4.1: Imagem do veículo projetado para simulação. Figura 4.2: Uso de um dispositivo laser no veículo. Como pode ser visto na figura, de acordo com os padrões possíveis pela biblioteca que faz toda a simulação da dinâmica física, o carro é composto de partes retangulares juntamente com rodas no formato de cilindro. Para as rodas dianteiras, a junção com o chassi é feita por uma junta do tipo Hinge2 disponibilizada pela biblioteca. Esta junta é a mais aconselhável para casos como o da roda de um carro aonde devem haver dois eixos sendo um possibilitando a roda girar para a frente e outro possibilitando movimento da roda para esquerda e para a direita. A Figura 4.3 retirada de [4] apresenta a estrutura física simulada pela biblioteca. Já as rodas traseiras, podem ser ligadas ao chassi fazendo o uso de uma junta comum do tipo Hinge que é mais simples e não permite que as rodas se movam lateralmente. Para utilização das juntas citada, existem diversos parâmetros para os quais deve se atentar. Estes parâmetros são também incluídos no arquivo XML e podem afetar toda a dinâmica da simulação. Dentre eles existem dois que são bastante importantes e geraram alguns problemas durante a simulação. Eles dizem respeito a interação de um corpo com outro, algo como uma constante de rigidez e no caso do veículo seria algo como a constante de mola da suspensão. Inicialmente o veículo estava balançando demais mesmo que em movimento retilíneo durante a simulação. Porém, com alguns ajustes nestes parâmetros se tornou possível a estabilização do veículo.

4.2 Ambiente para Simulação 31 Figura 4.3: Imagem ilustrativa da física que envolve a junção entre chassi e rodas dianteiras [4]. 4.2 Ambiente para Simulação O ambiente desenvolvido para a simulação buscou simular uma região urbana. Nada impede que diversos outros possíveis ambientes possam ser criados posteriormente se surgir a necessidade, porém o ambiente desenvolvido já abre possibilidade para simulação de uma diversidade de coisas como cruzamento de veículos, cálculo de curvas, detecção e desvio de obstáculos como o meio fio ou objetos que podem ser colocados. Com a adição do veículo ao programa cliente, se torna possível a construção de programas clientes que comandem os movimentos do carro e o teste de algoritmos com diferentes funções. Com o driver rodando sobre o veículo, estes mesmos algoritmos testados sobre o ambiente de simulação poderão posteriormente rodar no veículo com segurança. O arquivo XML de descrição do ambiente descreve juntamente com a inclusão do veículo, a inclusão de dois dispositivos muito interessantes. Um deles é um laser, que consiste em um dispositivo muito usado em veículos autônomos e que facilita bastante o desenvolvimento de algoritmos de detecção de obstáculos e tomada de decisão. O outro dispositivo é um rastreador que retorna a posição do veículo no ambiente de simulação similar a um odômetro real. Estes dois dispositivos fazem o uso de duas diferentes interfaces do Player para disponibilizarem seus comandos específicos para programas clientes. O laser posicionado sobre o veículo possui diversas configurações quanto ao seu posicionamento, logo a realização de testes para diversas posições permite que se possa encontrar a posição ideal para instalação deste dispositivo no carro. Através da configuração no arquivo XML, podemos posicioná-lo sobre o capô do veículo ou acima do parabrisa e ainda regular o seu ângulo no que diz respeito ao direcionamento ao

4.3 Desenvolvimento do Driver para o Veículo 32 chão. As Figuras 4.4 e 4.5 apresentam um trecho deste ambiente aonde podemos ver as ruas com cruzamentos, os meio-fios e também alguns objetos. Figura 4.4: Imagem ilustrativa do ambiente urbano desenvolvido para simulação. Figura 4.5: Visualização de uma outra posição. Para efeito de testes, foi desenvolvido um programa cliente simples para movimento do veículo dentro deste ambiente urbano. Este programa se mostra interessante para que futuros usuários do simulador tenham uma noção de como usar os comandos mais básicos permitidos pelas interfaces do Player sendo utilizadas. Este programa cliente apresenta o uso dos comandos de velocidade e direção do veículo, o uso de comandos do laser e também o uso de comandos do tracker que retornam ao usuário posições de objetos dentro do ambiente e funciona como um odômetro simulado para o veículo. O arquivo de configuração do Player desenvolvido para este ambiente faz a especificação de todas as interfaces sendo usadas para a simulação. 4.3 Desenvolvimento do Driver para o Veículo Para que se possa aproveitar por completo tudo aquilo que foi desenvolvido para simulação no Gazebo, se torna muito interessante o desenvolvimento de um driver para o veículo autônomo. Deste modo, aqueles códigos de programas clientes já desenvolvidos e devidamente testados sobre o carro simulado poderão comandar diretamente o veículo sem modificações. A hierarquia das diferentes ferramentas do projeto Player foram explicadas na Seção 3.8 e nos facilitam entender a necessidade do desenvolvimento de um driver. A primeira dificuldade nesta etapa se deu pelo fato de o programa que faz todo o controle do veículo ter sido desenvolvido em ambiente Windows. Os ambientes

4.3 Desenvolvimento do Driver para o Veículo 33 de simulação que rodam como plugins para o Player não funcionam am ambiente Windows, mas felizmente, recentemente foi lançada uma versão do Player que roda neste ambiente. A dificuldade, porém, ocorre devido a pouquíssima documentação detalhando o uso do Player em ambiente Windows, como compilar um driver desenvolvido ou como rodar um programa cliente. Alguns erros surgiram e tomaram grande tempo de desenvolvimento e teriam sido de simples resolução caso houvesse melhor documentação ou pessoas com maior experiência no desenvolvimento para este ambiente. Além disso, deve se atentar bastante para a instalação de algumas bibliotecas e como incluir seus caminhos às variáveis de ambiente do Windows. O ambiente escolhido para desenvolvimento do driver dentro do Windows foi o Microsoft Visual Studio 9. Utilizando um programa chamado CMAKE GUI, desenvolvido exclusivamente para Windows, a partir de um programa base para desenvolvimento de um driver disponibilizado pelo próprio projeto Player é gerado um projeto no Visual Studio fazendo grande parte das ligações necessárias com outras bibliotecas. Este projeto quando compilado corretamente gera uma biblioteca do tipo.dll que corresponderá ao driver desenvolvido e que poderá ser chamado pelo Player. Todo driver desenvolvido para o Player deve ser uma classe filha da classe Driver e com isso implementar obrigatoriamente algumas funções. Este modelo acaba por padronizar os drivers desenvolvidos e garante que eles sigam uma mesma estrutura básica. A Figura 4.6 retirada de [8] nos dá uma visão global do funcionamento padrão de um driver. Figura 4.6: Estrutura de funcionamento de um driver para o Player.[8] Como pode ser visto na figura, ao ser instaciado pelo Player através do arquivo de configuração, o driver entra em seu método de construção e logo em seguida no método de configuração. O método de construção é onde são instaciadas as interfaces a serem usadas, já no método de configuração deve-se iniciar qualquer

4.3 Desenvolvimento do Driver para o Veículo 34 tipo de conexão a ser feita com o robô real antes que o programa atinja o loop principal de troca de mensagens e comunicação. Devido ao atual estágio de desenvolvimento do veículo e o curto tempo para desenvolvimento, o driver desenvolvido é ainda um pouco limitado mas constitui uma excelente base para ser complementado posteriormente. A única interface utilizada é a de controle de posição em duas dimensões e possibilita ao programa cliente fornecer comandos de velocidade e direção. Posteriormente, poderão ser incluídos no driver também requisições de posição pelo programa cliente, uma vez que o programa do carro já possui medições de odometria. Um detalhe interessante é que o laser a ser utilizado sobre o veículo em um futuro próximo no carro já possui um driver desenvolvido que poderá ser utilizado quando este estiver instalado. Na função Setup(), como citado acima, é aonde deve-se estabelecer comunicação com os dispositivos do veículo. No caso do driver desenvolvido, é estabelecida uma conexão via socket local com o programa que faz todo o controle do veículo. Neste programa, foi incluída uma classe que executa uma thread em paralelo recebendo comandos do driver e enviando-os ao veículo. Seguindo o que apresenta a Figura 4.6, após as configurações o driver executa o seu loop principal. Dentro desta função Main, é executado um loop infinito uma vez que é aonde o robô, no caso o carro, irá receber comandos e enviar dados ao driver. Dentro deste loop infinito, inicialmente é verificado se o driver não foi encerrado. Em seguida, é acessada uma função que fará a verificação de mensagens, ou seja, ela irá verificar se o programa cliente está enviando alguma mensagem e identificará o seu tipo, seja de comando ou requisição. Com a mensagem identificada, é possível realizar as ações necessárias e no caso de uma requisição, verificar e publicar dados ao programa cliente. No caso do veículo, o driver desenvolvido trata as mensagens de comando de direção e de velocidade e futuros trabalhos devem envolver o tratamento de outras. Ao final de cada execução do loop, é interessante que haja um tempo de retardo para que a thread não fique sobrecarregada e para que o veículo execute suas devidas ações antes da chegada de uma nova mensagem. Ao receber uma mensagem de comando de velocidade ou direção, o driver faz o tratamento com a identificação dos valores do comando e codificação desta mensagem para envio via socket para o programa que faz os comandos do veículo. O programa, ao recebê-la, fará a decodificação identificando o tipo de comando recebido e em seguida lendo os valores. Para estas mensagens foi criado um simples protocolo aonde o tipo de comando e os valores são separados por um símbolo do tipo @. O driver fica então responsável por montar a mensagem respeitando o protocolo e o programa

4.3 Programa Cliente para Comunicação com o Driver 35 do carro por desfragmentar a mensagem pelo caractere símbolo, identificar o tipo de mensagem, para em seguida ler possíveis valores de acordo com o comando ou requisição recebida. Como já citado, tem-se implementado neste sistema os comandos de direção e velocidade. O modo como é acionado o comando de direção foi explicado na seção 3.4. Logo, caso o programa do carro identifique um comando que corresponda uma mudança na direção do veículo, é chamada uma função que enviará comandos ao motor que fará o giro da direção para a posição desejada. Entretanto, para tratar comandos de velocidade a lógica é um tanto mais complicada. Em um trabalho anterior sobre o veículo, Freitas[12] implementou fazendo o uso dos sistemas automáticos presentes, um controle longitudinal de velocidade. O controle é baseado em lógica fuzzy e em malha fechada fazendo o uso dos dados de odometria e da IMU como sensores e utilizando os sistemas de aceleração e frenagem como atuadores. No programa que controla o veículo há uma thread responsável unicamente por este controle, bastando que o usuário envie um valor de setpoint. Portanto, ao identificar um comando de velocidade recebido pelo programa cliente via driver, o que é feito internamente dentro do programa cliente é uma atualização do valor de setpoint. Um detalhe importante é um tratamento que é feito para que não haja trancos gerados por acelerações bruscas. Para isto, foi tomado o cuidado para que ao enviar um comando de setpoint de velocidade, anteriormente seja verificado o valor anterior de setpoint. No caso de a variação ser maior que 7 Km/h, a alteração do setpoint é feita de maneira gradativa com pequenos intervalos até que se chegue ao valor desejado. No caso de o driver receber um comando para finalizar, ele encerrará automaticamente a execução de seu loop principal e partirá para sua finalização. Neste momento sua conexão via socket com o programa que comanda o veículo é encerrada e a execução chega ao fim. 4.3.1 Programa Cliente para Comunicação com o Driver Para construção de um programa cliente para comunicar com um driver em ambiente Windows, o procedimento foi bem similar ao de desenvolvimento de um driver como citado na seção 4.3. Usando o programa CMAKE GUI, foi gerado um projeto para o Microsoft Visual Studio 9 contendo ligações com as bibliotecas necessárias. A

4.3 Programa Cliente para Comunicação com o Driver 36 elaboração de um programa cliente em si é bem simples e basta fazer o uso dos comandos da interface sendo utilizada. No caso do programa para se comunicar com o driver, algo bem simples foi desenvolvido com alguns comandos dentre aqueles implementados para efeito de testes. A maior dificuldade e algo que gerou grande perda de tempo foi um problema de conexão do programa cliente com o driver. Para correto funcionamento, o programa cliente deve rodar em modo release no Microsoft Visual Studio. A falta de documentação a respeito gerou atraso tentando resolver este problema de conexão por um detalhe tão simples, uma vez que os erros gerados não levavam a uma conclusão.

CAPÍTULO 5 Testes e Análise de Resultados Este capítulo irá tratar os testes realizados sobre o simulador e também sobre o driver no veículo real. Serão apresentadas as dificuldades encontradas e os resultados obtidos. 5.1 Testes sobre o Simulador Os testes do simulador em geral são bem mais simples do que os testes sobre o carro. Isto porque não dependem do uso do veículo, não há riscos e mudanças podem ser feitas o tempo todo com bastante facilidade. Deste modo, à medida que os códigos foram sendo desenvolvidos, testes eram realizados simultaneamente. Assim que o primeiro esboço do veículo sobre o Gazebo ficou pronto, pequenos programas cliente já foram feitos para realizar comandos sobre o carro e avaliar seu movimento. Inicialmente, o veículo desenvolvido foi mais como um aprendizado de como se fazer uso das juntas disponibilizadas para integrar partes do carro, como ajustar os parâmetros de tamanho e rotação e como integrar um modelo a um outro modelo, ou seja, fazer o uso de modelos aninhados. Deste modo, o primeiro veículo foi desenvolvido com valores que não representavam as dimensões reais do carro, apenas davam um formato próximo ao esperado. Os primeiros testes foram realizados em um ambiente simples do Gazebo com apenas uma região plana e 37

5.1 Testes sobre o Simulador 38 comandos simples de movimento. Com o funcionamento próximo ao esperado deste primeiro esboço, o próximo passo foi a fidelização do veículo com medidas reais. Medições foram feitas sobre o veículo e os dados obtidos aplicados ao veículo para simulação. Assim como para o primeiro esboço, testes simples de movimento foram feitos para esta versão fidelizada com sucesso. O próximo passo então foi o desenvolvimento do ambiente que se assemelhasse a uma região urbana para finalizar os testes do veículo simulado. Desenvolvido este ambiente como apresentado na Seção 4.2, uma gama maior de testes pode ser feito. Neste momento, foi detectado um balanço não esperado para o veículo que se mostrava mexendo demais para os lados quando em movimento. Isto foi solucionado com o ajuste de constantes como citado na Seção 4.1. O Gazebo oferece ainda uma ferramenta interessante que permite visualizar os eixos de rotação presentes na simulação para ver se isto condiz com o resultado esperado para os códigos desenvolvidos. Este tipo de visualização está presente nas Figuras 5.1 e 5.2. Figura 5.1: Visualização dos eixos de movimento. Figura 5.2: Visualização física do ambiente incluindo o laser. A figura explicita todos aqueles eixos que podem ter movimento físico, ou seja, na simulação, os objetos marcados com os eixos podem girar sobre os mesmos. É importante citar que alguns movimentos podem ter também limitações como o giro das rodas para esquerda e direita. O fato de o driver desenvolvido não contemplar a leitura de dados impossibilita uma validação deste simulador através da comparação de trajetórias. Deste modo, a avaliação feita sobre a qualidade do simulador tende a ser muito mais visual e por sentimento do que pela comparação de valores. Inicialmente, há um detalhe que impossibilita que o movimento do veículo no simulador seja totalmente equivalente ao

5.2 Testes no Veículo Autônomo 39 do veículo real que é a ausência de equações dinâmicas no controlador utilizado no Gazebo. Essas equações são difíceis de se obter e se encontram ainda em desenvolvimento e por isto não foram incluídas. Estes detalhes são tratados como sugestões de melhoria na Seção 6.2. Salvas essas considerações, o movimento do veículo simulado se assemelha bastante ao movimento do veículo real. Quando se trata por exemplo do movimento do carro partindo de velocidade zero até atingir certa velocidade, o fato de parâmetros de torque e massa do veículo estarem sendo usados torna o tempo até atingir a velocidade realístico. Outro detalhe é o fato de a altura da suspensão variar quando alterados seus parâmetros no modelo para o Gazebo. Caso se ajuste o valor da constante de mola para um número muito baixo, observa-se esta suspensão ficando rebaixada. Além disso, quando realizada uma curva, o movimento do carro simulado se assemelha muito ao do veículo real graças a valores corretos de comprimento e distância entre-eixos. O fato destes movimentos serem todos simulados por uma biblioteca de dinâmica física consagrada como a ODE gera grande confiabilidade. Portanto, como foram usados parâmetros e dimensões equivalentes às do veículo real, a simulação mostrou ter boa qualidade. 5.2 Testes no Veículo Autônomo Com a parte de simulação pronta e devidamente testada no Gazebo, o próximo passo foi o desenvolvimento do driver para rodar no veículo. A construção do código e as dificuldades nesta fase foram apresentadas no capítulo anterior de desenvolvimento. Com o driver já construído, a primeira fase de testes foi realizada de maneira remota, ou seja, foi feita sem o uso do carro apenas com a avaliação das conexões e do envio de mensagens. Isso torna os testes mais seguros e garante ao menos que o funcionamento do driver esteja correto e que este esteja enviando os devidos comandos ao carro. Dentre as conferências feitas durante estes testes iniciais, a primeira delas foi a verificação se o driver está recebendo corretamente os comandos vindos do programa cliente e processando-os de maneira correta. Quanto a esta comunicação não houve maiores problemas e o driver mostrou receber os comandos corretamente. A segunda conferência foi verificar se tanto o driver quanto o programa que comando o veículo estavam iniciando seus sockets corretamente e se conectando. Os primeiros testes mostraram uma dificuldade pois o driver não inicializava o socket enquanto o programa cliente não se conectava a ele, ou seja, ele só rodava o método

5.2 Testes no Veículo Autônomo 40 de configuração após a conexão do programa cliente. Porém, após alguma pesquisa verificou-se que é possível que este método seja acionado antes desta conexão. Para isto, basta que se altere um parâmetro no arquivo de configuração *.cfg chamado ao rodar o driver. Esta opção se mostrou interessante pelo fato de que se este método só fosse acionado quando o programa cliente se conectasse corretamente à ele, seria necessário algum modo de interrupção no programa cliente para que o socket do driver inicialize e se conectasse ao programa do carro antes mesmo de receber comandos. Após esta alteração, as conexão entre os sockets ocorreu da maneira esperada. Com o funcionamento correto desta conexão, tornou se possível realizar um teste completo da solução. A rotina deste teste consistiu na inicialização do Player rodando o driver, em seguida a inicialização do programa do carro e a conexão entre os sockets e posteriormente a inicialização do programa cliente com alguns comandos básicos. A Figura 5.3 apresenta a sequência lógica do teste. Figura 5.3: Sequência lógica de teste realizado. Os testes seguindo esta rotina apresentaram o resultado esperado e toda a comunicação funcionou corretamente. Com mais esta etapa concluída, o próximo passo foi testar este conjunto no veículo. Com as conexões devidamente testadas e funcionando, havia bastante segurança para este teste final. O único problema que