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

Transcrição

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
A Códigos Fonte XML para o Simulador
vi
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.
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.
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
. . . . . . . . . . . . . 30
32
Lista de Tabelas
ix
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
1.2
A Instituição
3
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
1.5
Escopo do Projeto
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 GPS1
juntamente com IMU2 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. Ao final do projeto, as melhorias
desenvolvidas foram replicadas ao Segway real.
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
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
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
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
3.1
21
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
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
3.2
23
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
3.2.2
25
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
3.2.3
26
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
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
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
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
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
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
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
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
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
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
5.2
41
poderia ocorrer seria a falha na conexão de algum sistema do carro e com isto não
ser possível o teste de algum comando.
Para testes sobre o veículo, foi desenvolvido um programa cliente bem simples. Neste
programa, inicialmente era enviado um comando para giro das rodas para a esquerda
e em seguida para a direita, tudo isto com velocidade zero. Testado o conjunto de
direção, era enviado um comando de velocidade.
A sequência lógica é a mesma apresentada pela Figura 5.3, porém com alguns passos
extras. Dentro da rotina apresentada, após a conexão entre os sockets haviam
dois passos extras. O primeiro deles é a conexão do programa do carro com seus
respectivos sistemas de controle e o segundo é a inicialização da thread responsável
por realizar o controle de velocidade do veículo.
Tomado os devidos cuidados foram então realizados testes sobre o carro. A primeira
parte, que diz respeito aos comando de direção, funcionou corretamente e a direção
recebeu os comandos com sucesso. A parte do comando de velocidade apresentou
maior dificuldade, porém não por algum problema nos programas, mas sim pela
limitação de espaço para testes. A velocidade utilizada para este controle foi bem
baixa, em torno de sete quilômetros por hora. No entanto, ao receber o comando e
iniciar o controle, o carro demora um pouco a conseguir controlar. Isto ocorre pelo
fato de o veículo ser automático e quando o câmbio está em posição de movimento,
quando se solta o freio, o motor já gera um impulso a frente que resulta em velocidade. Devido a este impulso, o carro leva um tempo maior para conseguir chegar à
uma velocidade mais baixa. Como a reta aonde o veículo pode ser testado não era
muito longa, logo ao seu final, quando a velocidade estava se estabilizando perto da
velocidade comandada, era necessário realizar a frenagem do veículo. Porém, por
um curto espaço de tempo foi verificado o controle de velocidade sendo realizado.
CAPÍTULO
6
Conclusão
Este capítulo tem por objetivo realizar as considerações finais quanto ao trabalho
realizado avaliando os resultados obtidos. Além disso, são apresentadas algumas
sugestões de continuidade para aperfeiçoamento do trabalho desenvolvido.
6.1
Dos Resultados Obtidos
Este trabalho apresentou o desenvolvimento de um simulador para um veículo autônomo fazendo o uso de ferramentas do projeto Player. Os resultados obtidos foram
satisfatórios de maneira que ao final do trabalho obteve-se um simulador capaz de
utilizar as diversas funcionalidades oferecidas pelos softwares do projeto Player.
O veículo desenvolvido para ser simulado dentro do ambiente Gazebo tem características físicas bem semelhantes ao veículo real e os resultados de simulações feitas
utilizando a biblioteca ODE podem trazer resultados que transmitam segurança para
a realização de testes reais. Um dos próximos passos no desenvolvimento do veículo
real é a inclusão do laser para auxílio na navegação. Testes sobre o simulador podem
facilitar no que diz respeito ao posicionamento deste dispositivo. A simulação pode
ainda ser extremamente benéfica para testes de algoritmos de detecção e desvio de
obstáculos se utilizando destes lasers ou câmeras assim como para testes de outros
tipos de sensores.
42
6.2
Propostas de Continuidade
43
O desenvolvimento de um driver para o veículo torna o uso do simulador algo ainda
mais útil de modo que os algoritmos testados sobre o simulador podem ser transferidos diretamente para o carro sem que haja qualquer modificação. Apesar de o
seu desenvolvimento estar ainda em estágio inicial, já forma uma base para futuros
complementos.
Do ponto de vista do aprendizado, o trabalho foi extremamente enriquecedor no
que diz respeito a saber gerenciar o tempo de desenvolvimento de um projeto e a
manter a motivação mesmo diante de dificuldades no desenvolvimento, além de ter
contribuído para novos aprendizados e amadurecimento de conhecimentos.
6.2
Propostas de Continuidade
Como sugestão de continuidade, o driver desenvolvido para o veículo deve ser aprofundado a partir da base já desenvolvida de modo que este seja capaz de retornar
ao programa cliente dados de odometria e incluir o uso do laser. Além disso, fazer
toda a configuração inicial do veículo de maneira automática antes que esse possa
se mover, como conexão aos sistemas, mudança de câmbio e liberação gradativa do
freio.
Com um driver mais completo, se torna interessante também a validação deste simulador. Esta validação poderia ser feita através da comparação entre trajetórias
do veículo simulado e trajetórias do veículo real. Com a leitura de dados de odometria em ambos os casos, uma comparação através de gráficos juntamente com uma
análise das diferenças de posição poderia ser feita.
Outra proposta interessante é a implementação das equações de modelagem dinâmica do veículo quando elas já estiverem sido desenvolvidas por completo. Esta
implementação deve ser feita internamente no código do controlador de posição em
duas dimensões e acabará por gerar fidelidade ainda maior do modelo simulado com
o modelo real.
APÊNDICE
A
Códigos Fonte XML para o Simulador
Este apêndice tem por objetivo apresentar os códigos desenvolvidos tanto para o
modelo do carro quanto para o ambiente de simulação desenvolvido para o Gazebo.
Dentro do código do ambiente de simulação é feita a inclusão de um novo arquivo
chamado ambiente.model que é um complemento da descrição. Nele são descritos
as ruas e meio fios e por ser um arquivo muito extenso não será incluído aqui.
A.1
Código XML do Modelo Físico
<?xml version=" 1 . 0 " ?>
< !−− Car Model −−>
<m o d e l : p h y s i c a l name=" default_car_model "
xmlns:model=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#model "
x m l n s : s e n s o r=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#s e n s o r "
xmlns:body=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#body "
xmlns:geom=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#geom"
x m l n s : j o i n t=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/# j o i n t "
x m l n s : c o n t r o l l e r=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/# c o n t r o l l e r "
x m l n s : i n t e r f a c e=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/# i n t e r f a c e "
x m l n s : v i s u a l=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/# v i s u a l "
>
44
A.1
<xyz>0 0 0 . 0</ xyz>
<rpy>0 . 0 0 . 0 0 . 0</ rpy>
<c a n o n i c a l B o d y>c h a s s i s _ b o d y</ c a n o n i c a l B o d y>
< !−−t o r q u e e q u i v a l e n t e a 200N.m é um v a l o r aproximado e n c o n t r a d o
para motores s e m e l h a n t e s na i n t e r n e t−−>
<c o n t r o l l e r : s t e e r i n g _ p o s i t i o n 2 d name=" a ␣ c a r ">
<wheel>
< j o i n t>l e f t _ f r o n t _ w h e e l _ h i n g e</ j o i n t>
<type>s t e e r</ type>
<t o r q u e>200</ t o r q u e>
<s t e e r T o r q u e>100</ s t e e r T o r q u e>
</ wheel>
<wheel>
< j o i n t>r i g h t _ f r o n t _ w h e e l _ h i n g e</ j o i n t>
<type>s t e e r</ type>
<t o r q u e>200</ t o r q u e>
<s t e e r T o r q u e>100</ s t e e r T o r q u e>
</ wheel>
<wheel>
< j o i n t>l e f t _ r e a r _ w h e e l _ h i n g e</ j o i n t>
<type>d r i v e</ type>
<t o r q u e>200</ t o r q u e>
</ wheel>
<wheel>
< j o i n t>right_rear_wheel_hinge</ j o i n t>
<type>d r i v e</ type>
<t o r q u e>200</ t o r q u e>
</ wheel>
<steerPD>10 0</ steerPD>
<steerMaxAngle>29</ steerMaxAngle>
< !−−<w h e e l S e p a r a t i o n>2 . 0</ w h e e l S e p a r a t i o n>−−>
<wheelDiameter>0 . 6 4</ wheelDiameter>
<damping>0 . 9</ damping>
<s p r i n g>100000</ s p r i n g>
<stepTime>0 . 0 3</ stepTime>
<l e f t O d o m J o i n t>l e f t _ f r o n t _ w h e e l _ h i n g e</ l e f t O d o m J o i n t>
<rightOdomJoint>r i g h t _ f r o n t _ w h e e l _ h i n g e</ rightOdomJoint>

</ c o n t r o l l e r : s t e e r i n g _ p o s i t i o n 2 d>
<body:box name=" c h a s s i s _ b o d y ">
< s t a t i c>t r u e</ s t a t i c>
45
A.1
<geom:box name=" chassis_geom ">
< s i z e>4 . 0 1 . 1 7 0 . 1</ s i z e>
<mass>200</ mass>
<v i s u a l>
<s c a l e>4 . 0 1 . 1 7 0 . 1</ s c a l e>
<mesh>unit_box</mesh>
<m a t e r i a l>Gazebo /Red</ m a t e r i a l>
<castShadows>0</ castShadows>
</ v i s u a l>
</ geom:box>
<geom:box name=" r e t a n g u l o _ a p o i o ">
<xyz>0 0 . 0 0 . 3 5</ xyz>
< s i z e>1 . 6 1 . 5 7 0 . 6</ s i z e>
<mass>200</ mass>
<v i s u a l>
<s c a l e>1 . 6 1 . 5 7 0 . 6</ s c a l e>
<m a t e r i a l>Gazebo / Black</ m a t e r i a l>
</ v i s u a l>
</ geom:box>
<geom:box name=" r e t a n g u l o _ d i a n t e i r o ">
<xyz>1 . 4 0 . 0 0 . 3 5</ xyz>
< s i z e>1 . 2 1 . 1 7 0 . 6</ s i z e>
<mass>150</ mass>
<v i s u a l>
<s c a l e>1 . 2 1 . 1 7 0 . 6</ s c a l e>
<m a t e r i a l>Gazebo / White</ m a t e r i a l>
</ v i s u a l>
</ geom:box>
<geom:box name=" r e t a n g u l o _ t r a s e i r o ">
<xyz>−1.4 0 . 0 0 . 3 5</ xyz>
< s i z e>1 . 2 1 . 1 7 0 . 6</ s i z e>
<mass>150</ mass>
<v i s u a l>
<s c a l e>1 . 2 1 . 1 7 0 . 6</ s c a l e>
<m a t e r i a l>Gazebo / White</ m a t e r i a l>
</ v i s u a l>
46
A.1
</ geom:box>
<geom:box name=" r e t a n g u l o _ s u p e r i o r ">
<xyz>0 . 0 0 . 0 0 . 7</ xyz>
< s i z e>4 . 0 1 . 5 7 0 . 1 8</ s i z e>
<mass>100</ mass>
<v i s u a l>
<s c a l e>4 . 0 1 . 5 7 0 . 1 8</ s c a l e>
<m a t e r i a l>Gazebo /Red</ m a t e r i a l>
</ v i s u a l>
</ geom:box>
<geom:box name=" t e t o ">
<xyz>−0.15 0 . 0 1 . 0 4</ xyz>
< s i z e>2 . 5 1 . 5 7 0 . 5</ s i z e>
<mass>200</ mass>
<v i s u a l>
<s c a l e>2 . 5 1 . 5 7 0 . 5</ s c a l e>
<m a t e r i a l>Gazebo / Yellow</ m a t e r i a l>
</ v i s u a l>
</ geom:box>
<geom:box name=" p a r a c h o q u e _ t r a s e i r o ">
<xyz>−2.05 0 . 0 0 . 3 5</ xyz>
< s i z e>0 . 1 1 . 5 7 0 . 6</ s i z e>
<mass>30</ mass>
<v i s u a l>
<s c a l e>0 . 1 1 . 5 7 0 . 6</ s c a l e>
</ v i s u a l>
</ geom:box>
<geom:box name=" p a r a c h o q u e _ d i a n t e i r o ">
<xyz>2 . 0 5 0 . 0 0 . 3 5</ xyz>
< s i z e>0 . 1 1 . 5 7 0 . 6</ s i z e>
<mass>30</ mass>
<v i s u a l>
<s c a l e>0 . 1 1 . 5 7 0 . 6</ s c a l e>
47
A.1
</ v i s u a l>
</ geom:box>
</ body:box>

<xyz>−1.31 0 . 6 8 5 0 . 1</ xyz>
<rpy>0 90 90</ rpy>
<g e o m : c y l i n d e r name=" left_rear_wheel_geom ">
< s i z e>0 . 3 2 0 . 2</ s i z e>
<mass>50</ mass>
<v i s u a l>
<mesh>P i o n e e r 2 a t / t i r e . mesh</mesh>
<rpy>−90 0 0</ rpy>
< s i z e>0 . 6 4 0 . 2 0 . 6 4</ s i z e>
</ v i s u a l>
<v i s u a l>
<mesh>P i o n e e r 2 a t / wheel . mesh</mesh>
<rpy>−90 0 0</ rpy>
< s i z e>0 . 3 2 0 . 2 0 . 3 2</ s i z e>
<m a t e r i a l>Gazebo / Gold</ m a t e r i a l>
</ v i s u a l>
<v i s u a l>
<xyz>0 0 −0.015</ xyz>
< s i z e>0 . 6 4 0 . 6 4 0 . 1</ s i z e>
<mesh>u n i t _ c y l i n d e r</mesh>
</ v i s u a l>
</ g e o m : c y l i n d e r>


<xyz>−1.31 −0.685 0 . 1</ xyz>
<rpy>0 90 90</ rpy>
<g e o m : c y l i n d e r name=" right_rear_wheel_geom ">
< s i z e>0 . 3 2 0 . 2</ s i z e>
<mass>50</ mass>
<v i s u a l>
<rpy>−90 0 0</ rpy>
< s i z e>0 . 6 4 0 . 2 0 . 6 4</ s i z e>
</ v i s u a l>
48
A.1
<v i s u a l>
<rpy>−90 0 0</ rpy>
< s i z e>0 . 3 2 0 . 2 0 . 3 2</ s i z e>
</ v i s u a l>
<v i s u a l>
<xyz>0 0 −0.015</ xyz>
< s i z e>0 . 6 4 0 . 6 4 0 . 1</ s i z e>
</ v i s u a l>

<xyz>1 . 3 1 0 . 6 8 5 0 . 1</ xyz>
<rpy>0 90 90</ rpy>
<g e o m : c y l i n d e r name=" left_front_wheel_geom ">
< s i z e>0 . 3 2 0 . 2</ s i z e>
<mass>50</ mass>
<v i s u a l>
<rpy>−90 0 0</ rpy>
< s i z e>0 . 6 4 0 . 2 0 . 6 4</ s i z e>
</ v i s u a l>
<v i s u a l>
<rpy>−90 0 0</ rpy>
< s i z e>0 . 3 2 0 . 2 0 . 3 2</ s i z e>
</ v i s u a l>
<v i s u a l>
<xyz>0 0 −0.015</ xyz>
< s i z e>0 . 6 4 0 . 6 4 0 . 1</ s i z e>
</ v i s u a l>

<xyz>1 . 3 1 −0.685 0 . 1</ xyz>
49
A.1
<rpy>0 90 90</ rpy>
<g e o m : c y l i n d e r name=" right_front_wheel_geom ">
< s i z e>0 . 3 2 0 . 2</ s i z e>
<mass>50</ mass>
<v i s u a l>
<rpy>−90 0 0</ rpy>
< s i z e>0 . 6 4 0 . 2 0 . 6 4</ s i z e>
</ v i s u a l>
<v i s u a l>
<rpy>−90 0 0</ rpy>
< s i z e>0 . 3 2 0 . 2 0 . 3 2</ s i z e>
</ v i s u a l>
<v i s u a l>
<xyz>0 0 −0.015</ xyz>
< s i z e>0 . 6 4 0 . 6 4 0 . 1</ s i z e>
</ v i s u a l>
<j o i n t : h i n g e 2 name=" l e f t _ f r o n t _ w h e e l _ h i n g e ">
<body1>c h a s s i s _ b o d y</ body1>
<body2>l e f t _ f r o n t _ w h e e l</ body2>
<anchor>l e f t _ f r o n t _ w h e e l</ anchor>
<a n c h o r O f f s e t>0 0 . 0 0</ a n c h o r O f f s e t>
<a x i s 1>0 0 1</ a x i s 1>
<a x i s 2>0 1 0</ a x i s 2>
<e r p>0 . 8</ e r p>
<cfm>10 e−5</ cfm>
< !−−<suspensionCfm>10 e−5</ suspensionCfm>−−>
</ j o i n t : h i n g e 2>
< j o i n t : h i n g e name=" l e f t _ r e a r _ w h e e l _ h i n g e ">
<body1>l e f t _ r e a r _ w h e e l</ body1>
<anchor>l e f t _ r e a r _ w h e e l</ anchor>
<a n c h o r O f f s e t>0 0 . 0 0</ a n c h o r O f f s e t>
<a x i s>0 1 0</ a x i s>
<e r p>0 . 8</ e r p>
<cfm>10 e−5</ cfm>
50
A.2
Código XML do Ambiente de Simulação
51
</ j o i n t : h i n g e>
<j o i n t : h i n g e 2 name=" r i g h t _ f r o n t _ w h e e l _ h i n g e ">
<body2>r i g h t _ f r o n t _ w h e e l</ body2>
<anchor>r i g h t _ f r o n t _ w h e e l</ anchor>
<a n c h o r O f f s e t>0 −0.0 0</ a n c h o r O f f s e t>
<a x i s 1>0 0 1</ a x i s 1>
<a x i s 2>0 1 0</ a x i s 2>
<e r p>0 . 8</ e r p>
<cfm>10 e−5</ cfm>
< !−−<suspensionCfm>10 e−5</ suspensionCfm>−−>
</ j o i n t : h i n g e 2>
< j o i n t : h i n g e name=" right_rear_wheel_hinge ">
<body1>r i g h t _ r e a r _ w h e e l</ body1>
<anchor>r i g h t _ r e a r _ w h e e l</ anchor>
<a n c h o r O f f s e t>0 −0.0 0</ a n c h o r O f f s e t>
<a x i s>0 1 0</ a x i s>
<e r p>0 . 8</ e r p>
<cfm>10 e−5</ cfm>
</ j o i n t : h i n g e>
</ m o d e l : p h y s i c a l>
A.2
<?xml version=" 1 . 0 " ?>
<g a z e b o : w o r l d
x m l n s : x i=" h t t p : //www. w3 . o r g /2001/ XInclude "
x m l n s : g a z e b o=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#gz "
xmlns:model=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#model "
x m l n s : s e n s o r=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#s e n s o r "
xmlns:window=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#window"
xmlns:param=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#param"
xmlns:body=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#body "
xmlns:geom=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#geom"
x m l n s : j o i n t=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/# j o i n t "
x m l n s : i n t e r f a c e=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/# i n t e r f a c e "
x m l n s : u i=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#u i "
x m l n s : r e n d e r i n g=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#r e n d e r i n g "
x m l n s : c o n t r o l l e r=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/# c o n t r o l l e r "
A.2
52
x m l n s : p h y s i c s=" h t t p : // p l a y e r s t a g e . s o u r c e f o r g e . n e t / gazebo / xmlschema/#p h y s i c s " >
<v e r b o s i t y>5</ v e r b o s i t y>

<stepTime>0 . 0 3</ stepTime>
<g r a v i t y>0 0 −9.8</ g r a v i t y>
<cfm>10 e−5</ cfm>
<e r p>0 . 8</ e r p>
<updateRate>−1</ updateRate>

<r e n d e r i n g : g u i>
<type> f l t k</ type>
< s i z e>640 480</ s i z e>
<pos>0 0</ pos>
</ r e n d e r i n g : g u i>
<r e n d e r i n g : o g r e>
<ambient>0 . 4 0 . 4 0 . 4 1 . 0</ ambient>
<sky>
<m a t e r i a l>Gazebo / CloudySky</ m a t e r i a l>
</ sky>
</ r e n d e r i n g : o g r e>
< !−− Ground Plane −−>
<m o d e l : p h y s i c a l name=" plane1_model ">
<xyz>0 0 0</ xyz>
<rpy>0 0 0</ rpy>

<g e o m : p l a n e name=" plane1_geom ">
<normal>0 0 1</ normal>
< s i z e>2000 2000</ s i z e>
<segments>10 10</ segments>
100 100
<m a t e r i a l>Gazebo / G r a s s F l o o r</ m a t e r i a l>
</ g e o m : p l a n e>

< !−− A random camera −−>
< !−−<m o d e l : p h y s i c a l name="cam1_model">
<xyz>−3 −4.5 2</ xyz>
A.2
53
<rpy>0 14 50</ rpy>
<body:empty name="cam1_body">
<s e n s o r : c a m e r a name=" cam1_sensor ">
640 480
<h f o v>60</ h f o v>
<n e a r C l i p>0 . 1</ n e a r C l i p>
<f a r C l i p>100</ f a r C l i p>
<c o n t r o l l e r : g e n e r i c _ c a m e r a name=" c a m 1 _ c o n t r o l l e r ">

</ c o n t r o l l e r : g e n e r i c _ c a m e r a>
</ s e n s o r : c a m e r a>
</ body:empty>
</ m o d e l : p h y s i c a l>−−>
< !−−Modelo c o r r e s p o n d e n t e ao ambiente c r i a d o−−>
<m o d e l : p h y s i c a l name="random_road">

< x i : i n c l u d e h r e f=" models / ambiente . model " />

<m o d e l : p h y s i c a l name=" cadu_model ">
<xyz>0 −3 0 . 2 8</ xyz>
<rpy>0 0 . 0 0 . 0</ rpy>
< !−−
The i n c l u d e s h o u l d be l a s t w i t h i n a model . A l l p r e v i o u s s t a t e m e n t s
w i l l override those in the included f i l e
−−>
< !−−I n c l u s a o do modelo do v e i c u l o j u n t a m e n t e com l a s e r e câmera −−>
< x i : i n c l u d e h r e f=" models /cadu_PFC . model " />

< !−− Embedded l a s e r model −−>
<m o d e l : p h y s i c a l name=" sick200lms_model ">
<xyz>2 . 0 0 0 . 8 9</ xyz>
<rpy>0 . 0 1 0 . 0 0 . 0</ rpy>
< x i : i n c l u d e h r e f=" models / s i c k l m s 2 0 0 . model " />

< !−− Embedded s t e r e o camera −−>
< !−−
<m o d e l : p h y s i c a l name="cam1_model">
<xyz>0 . 9 0 1 . 4</ xyz>
A.2
<rpy>0 6 . 0 0</ rpy>
<body:empty name="cam1_body">
<s e n s o r : s t e r e o c a m e r a name=" cam1_sensor ">
320 240
<h f o v>60</ h f o v>
<n e a r C l i p>0 . 1</ n e a r C l i p>
<f a r C l i p>10</ f a r C l i p>
<saveFrames> f a l s e</ saveFrames>
<saveFramePath>frames</ saveFramePath>
0 . 2
<c o n t r o l l e r : s t e r e o c a m e r a name=" s t e r e o _ c a m e r a _ c o n t r o l l e r ">



<l e f t c a m e r a>camera_iface_0</ l e f t c a m e r a>
<r i g h t c a m e r a>camera_iface_1</ r i g h t c a m e r a>
</ c o n t r o l l e r : s t e r e o c a m e r a>
</ s e n s o r : s t e r e o c a m e r a>
</ body:empty>
</ m o d e l : p h y s i c a l> −−>
<m o d e l : p h y s i c a l name=" stereo_camera_model ">
<xyz>0 . 9 8 0 1 . 2 8</ xyz>
<rpy>0 . 0 0 . 0 0 . 0</ rpy>
< x i : i n c l u d e h r e f=" models / stereo_camera . model " />

< !−− I n c l u s a o do r a s t r e a d o r de p o s i c a o −−>
<m o d e l : p h y s i c a l name=" t r a c k e r ">
<xyz>0 . 0 0 . 0 0 . 0</ xyz>
< c o n t r o l l e r : t r a c k e r name=" f i d u c i a l ">
<models>
<t r a c k name=" cadu_model " i d=" 0 " />
</ models>
<n o i s e
l i n e a r=" 0 . 0 1 ␣ 0 . 0 1 ␣ 0 . 0 2 "
a n g u l a r=" 0 . 0 0 0 1 ␣ 0 . 0 0 0 1 ␣ 0 . 0 0 0 1 "
54
A.2
/>
<updateRate>15</ updateRate>

</ c o n t r o l l e r : t r a c k e r>
< !−− White P o i n t l i g h t −−>
<m o d e l : r e n d e r a b l e name=" point_white ">
<xyz>0 0 500</ xyz>
< l i g h t>
<type> d i r e c t i o n a l</ type>
<r a n g e>100</ r a n g e>
< !−− Constant (0 −1) L i n e a r (0 −1) Q u a d r a t i c −−>
<a t t e n u a t i o n>0 . 5 0 . 0 1 0</ a t t e n u a t i o n>
</ l i g h t>
</ m o d e l : r e n d e r a b l e>
< !−−O b s t a c u l o−−>
<m o d e l : p h y s i c a l name=" u s e r _ c y l i n d e r 0 ">
<xyz>3 0 . 0 3 0 . 5</ xyz>
<rpy>0 0 0</ rpy>
<e n a b l e G r a v i t y>1</ e n a b l e G r a v i t y>
<e n a b l e F r i c t i o n>1</ e n a b l e F r i c t i o n>
< c o l l i d e> a l l</ c o l l i d e>
< s t a t i c>0</ s t a t i c>
<body name=" body ">
<xyz>0 0 0</ xyz>
<rpy>0 0 0</ rpy>
<g e o m : c y l i n d e r name="geom">
<xyz>0 0 0</ xyz>
<rpy>0 −0 0</ rpy>
< s i z e>1 . 0 0 . 7 5</ s i z e>
<mass>0 . 5</ mass>
<v i s u a l>
<xyz>0 0 0</ xyz>
<rpy>0 −0 0</ rpy>
<m a t e r i a l>Gazebo / Grey</ m a t e r i a l>
<s c a l e>2 2 0 . 7 5</ s c a l e>
</ v i s u a l>
</ body>
55
Referências Bibliográficas
[1] Darpa grand challenge official website. http://www.darpa.mil/grandchallenge/
index.asp, April 2010.
[2] Microsoft robotics developer studio. http://www.microsoft.com/robotics/, May
2010.
[3] Nvidia physx for developers. http://developer.nvidia.com/object/physx.html,
May 2010.
[4] Open dynamics engine website. http://opende.sourceforge.net/, April 2010.
[5] Opengl utility toolkit website.
http://www.opengl.org/resources/libraries/
glut/, April 2010.
[6] The player project.
http://playerstage.sourceforge.net/index.php?src=
gazebo, 2010.
[7] Princeton autonomous vehicle engineering.
http://pave.princeton.edu/about/
projects/urban-challenge, May 2010.
[8] Psu robotics - player/stage drivers. http://www.psurobotics.org/wiki/index.php?
title=Player/Stage_Drivers, November 2010.
[9] Webots - commercial mobile robot simulation software. http://www.cyberbotics.
com, May 2010.
[10] Maurício Ferreira Baleeiro. Sistema de Acionamento Elétrico para Frenagem de um
Veículo Autônomo. Trabalho de Conclusão de Curso (Engenharia Elétrica) - Universidade Federal de Minas Gerais, 2009.
56
REFERÊNCIAS BIBLIOGRÁFICAS
57
[11] Tiago Mendonça da Silva. Controle automático do mecanismo de frenagem de um
veículo não tripulado. Projeto Final de Curso - Universidade Federal de Minas Gerais,
2009.
[12] Elias José de Rezende Freitas. Controle Longitudinal de um Veículo Autônomo. Trabalho de Conclusão de Curso (Engenharia Elétrica) - Universidade Federal de Minas
Gerais, 2010.
[13] V. Ganapathy and W.L.D. Lui. Design and implementation of a simulated robot using
webots software. Proceedings of the International Conference on Control, Instrumentation and Mechatronics Engineering, 28-29 May 2007, Johor Bahru, Malaysia,, pages
850–856.
[14] R. T.; Gerkey, B.; Vaughan and A Howard. The player/stage project: Tools for multirobot and distributed sensor systems. Proceedings of the International Conference on
Advanced Robotics, pages 317–323, 2003.
[15] Nate Koenig. Stage and gazebo - the instant expert’s guide. http://robotics.usc.
edu/~nkoenig/stage_gazebo_tutorial.ppt, April 2010.
[16] Nathan Koenig and Andrew Howard. Design and use paradigms for gazebo, an opensource multi-robot simulator. In IEEE/RSJ International Conference on Intelligent
Robots and Systems, pages 2149–2154. Sendai, Japan, Sep 2004. URL http://cres.
usc.edu/cgi-bin/print_pub_details.pl?pubid=394.
[17] Alexis Maldonado Michael Beetz Matthias Kranz, Radu Bogdan Rusu and Albrecht
Schmidt. A player/stage system for context-aware intelligent environments. Proceedings of the System Support for Ubiquitous Computing Workshop (UbiSys 2006), pages
1–7, September 2006.
[18] J. R. McBride, J. C. Ivan, D. S. Rhode, J. D. Rupp, M. Y. Rupp, J. D. Higgins, D. D.
Turner, and R. M. Eustice. A perspective on emerging automotive safety applications,
derived from lessons learned through participation in the darpa grand challenges. J.
Field Robot., 25(10):808–840, 2008. ISSN 1556-4959.
[19] Umit Ozguner. The ohio state university - autonomous city transport - developed for
the 2007 darpa urban challenge, June 2007.
[20] Vitor Brandão Sabbagh. Desenvolvimento de um Sistema de Controle para um Veículo Autônomo. Projeto Final de Curso (Engenharia de Controle e Automação) Universidade Federal de Minas Gerais, 2009.
[21] Michelle Mendes Santos. Desenvolvimento de um Sistema de Localização para um
Veículo Terrestre. Dissertação (Mestrado em Engenharia de Elétrica) - Universidade
Federal de Minas Gerais, 2009.
REFERÊNCIAS BIBLIOGRÁFICAS
58
[22] Sebastian Thrun, Michael Montemerlo, Hendrik Dahlkamp, David Stavens, Andrei
Aron, James Diebel, Philip Fong, John Gale, Morgan Halpenny, Gabriel Hoffmann,
Kenny Lau, Celia Oakley, Mark Palatucci, Vaughan Pratt, Pascal Stang, Sven Strohband, Cedric Dupont, Lars-Erik Jendrossek, Christian Koelen, Charles Markey, Carlo
Rummel, Joe van Niekerk, Eric Jensen, Philippe Alessandrini, Gary Bradski, Bob Davies, Scott Ettinger, Adrian Kaehler, Ara Nefian, and Pamela Mahoney. Stanley: The
robot that won the darpa grand challenge. Journal of Field Robotics, 23(1):661–692,
June 2006.
[23] M. M. Santos; E. J. R. Freitas; M. N. W. Vinti; P. Iscold; L. A. B. Tôrres; and G. A. S.
Pereira. Automation and localization of a robotic car. Proceedings of the 3rd Applied
Robotics and Collaborative Systems Enginnering (Robocontrol-08), pages 1–7, 2008.

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

Transcrição

Documentos relacionados

Manual Gazebo Dobrável

Veículos automotores modificados

Unidades Móveis: Acessórios

Normas do Sindicato das Empresas de Transporte

IMPORTAÇÃO DE VEÍCULOS USADOS

VOACTIVO

acidentes de trânsito - veículos oficiais com seguro

carros alterado - intranet - desus - crea-pr

PLANO TRUCK IDEAL - Satélite assistência

Jornal Balcão - Belo Horizonte - MG - sicepot-mg