SIMULADOR PARA O ROV LUMA UTILIZANDO GAZEBO Mariana …monografias.poli.ufrj.br/monografias/monopoli10020423.pdf · Obtendo sucesso ao ﬁnal do processo a simula¸c˜ao do ve´ıculo

SIMULADOR PARA O ROV LUMA UTILIZANDO GAZEBO

Mariana Rufino de Andrade

Projeto de Graduacao apresentado ao Curso

de Engenharia Eletronica e de Computacao

da Escola Politecnica, Universidade Federal

do Rio de Janeiro, como parte dos requisitos

necessarios a obtencao do tıtulo de Enge-

nheiro.

Orientador: Eduardo Vieira Leao Nunes

Rio de Janeiro

Fevereiro de 2017

Scanned by CamScanner

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politecnica - Departamento de Eletronica e de Computacao

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitaria

Rio de Janeiro - RJ CEP 21949-900

Este exemplar e de propriedade da Universidade Federal do Rio de Janeiro, que

podera incluı-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

E permitida a mencao, reproducao parcial ou integral e a transmissao entre bibli-

otecas deste trabalho, sem modificacao de seu texto, em qualquer meio que esteja

ou venha a ser fixado, para pesquisa academica, comentarios e citacoes, desde que

sem finalidade comercial e que seja feita a referencia bibliografica completa.

Os conceitos expressos neste trabalho sao de responsabilidade do(s) autor(es).

iv

AGRADECIMENTO

Em primeiro lugar e acima de todas as coisas eu gostaria de agradecer a Deus Pai,

Deus Filho e Deus Espırito Santo que me proporcionou o dom da vida e me iluminou

e abencoou ate este momento. Alem de ter me dado acalento em todos os momentos

de dificuldades, deu-me tambem forca para lutar e alcancar meus objetivos.

De forma especial agradeco a minha famılia,que tem como nucleo minha mae Ana

Lucia, minha mae Elizabete, minha avo Albertina (in memoriam), minhas irmas

Barbara e Gloria e minha sobrinha Maria Luiza, por estarem presentes em todos

os momentos da minha vida e principalmente durante essa jornada, me apoiando

em todas as decisoes e sendo um suporte fundamental para a conclusao desta etapa

tao importante para mim. A voces dedico este trabalho que foi realizado com tanto

carinho e amor e digo mais uma vez obrigada por toda paciencia e abdicacao em

prol deste objetivo. Amo voces mais do que eu poderia dizer.

Agradeco tambem aos meus amigos de faculdade e laboratorio, que participaram

de maneira direta ou indireta na realizacao nao so deste trabalho, bem como de

toda a minha formacao academica. Voces foram essenciais para que eu passasse por

todos os momentos de fraqueza e descrenca de mim mesma, ajudando-me sempre que

possıvel e me proporcionando momentos de descontracao quando eu mais precisei.

Aos amigos que conquistei na escola, no intercambio ou na vida, deixo tambem o

meu muito obrigado por torcerem por mim e me incentivarem a cada instante. A

presenca e o companheirismo de voces foi de suma importancia para mim.

Devo agradecer tambem aos professores que passaram pela minha carreira, em

especial aos professores Case e Brafman, por todo o conhecimento transmitido e

conselhos adquiridos em nossas conversas. Voces me mostraram que o dom de

ensinar vai muito alem da sala de aula.

Para finalizar gostaria de agradecer ao meu orientador, Eduardo Nunes, e meu

coorientador Rodrigo Carneiro por aceitarem caminhar comigo nesse projeto, se

v

mostrando sempre disponıveis a tirar minhas duvidas e a contribuir com a realizacao

deste trabalho de forma exemplar.

vi

RESUMO

Palavras-Chave: Simulacao, robo, projeto, Gazebo.

O Grupo de Simulacao e Controle em Automacao e Robotica (GSCAR) tem traba-

lhado com o desenvolvimento de diferentes robos, inclusive os ROV´s. Para cumprir

o desafio de desenvolver um veıculo desse porte sao necessarias muitas fases diferen-

tes que agrupam cada uma os conceitos que devem ser implementados ao veıculo

alem da realizacao de testes. Nesta ultima etapa a utilizacao de um simulador

realista possibilitaria que os custos do projeto sejam mais baixos e seguros.

Com isso esse trabalho e voltado ao desenvolvimento e implementacao de um

ambiente de simulacao realista para testes do modelo HROV LUMA. O ambiente

escolhido para tal feito foi o Gazebo por ser um software opensource e tratar de

muitos aspectos relevantes ao projeto, como por exemplo o tratamento da hidro-

dinamica e a existencia de sensores complementares a simulacao. A insercao do

modelo real do robo exigiu cuidados especiais em muitas particularidades, como as

dimensoes reais do robo, sua modelagem dinamica e cinematica, e suas interacoes

com o ambiente e o usuario. Com a gama de informacoes pertinentes ao projeto em

pauta foi realizada a importacao do modelo realıstico do robo que incluıa os dados

de centro de massa, de inercia entre outros necessarios a simulacao. Apos este passo

o desenvolvimento do ambiente realista teve inıcio e sua integracao com a interface

desenvolvida anteriormente no GSCAR foi realizada em paralelo atraves do ROS.

Obtendo sucesso ao final do processo a simulacao do veıculo se torna essencial para

garantir maior seguranca do robo.

Sera possıvel notar que durante a realizacao desse projeto final de graduacao a

maior preocupacao era de desenvolver o ambiente de simulacao com o maior grau

de realidade possıvel bem como o robo em questao. E importante ficar atento para

que todas as integracoes sejam realizadas da maneira correta, proporcionando ao

projeto um alto grau de confiabilidade por parte do usuario.

vii

ABSTRACT

Keywords: Simulation, robots, project, Gazebo.

The Simulation and Control Group in Automation and Robotics (GSCAR) has

been working with the development of di↵erent robots, including ROVs. To meet

the challenge of developing a vehicle of this size requires many di↵erent phases

that group each one the concepts that must be implemented to the vehicle besides

performing tests. In this last stage the use of a realistic simulator would allow the

project costs to be lower and safer.

So, this work is focused on the development and implementation of a realistic

simulation environment for HROV LUMA model tests. The environment chosen for

this purpose was the Gazebo because it is an open source software and deal with

many aspects relevant to the project, such as the treatment of hydrodynamics and

the existence of sensors to complement the simulation. The insertion of the real

model of the robot required special care in many particularities, such as the real

dimensions of the robot, its dynamical and kinematic modeling, and its interactions

with the environment and the user.With the range of information pertinent to the

project in question, the import of the realistic model of the robot was carried out,

which included the data of center of mass, of inertia among others necessary for the

simulation. After this step the development of the realistic environment began and

its integration with the interface previously developed in the GSCAR was carried out

in parallel through the ROS. Succeeding at the end of the process, vehicle simulation

becomes essential to ensure greater robot safety.

It will be possible to note that during the realization of this final graduation

project the main concern was to develop the simulation environment with the highest

degree of reality possible as well as the robot worked. It is important to be aware

that all integrations are performed in the right way, giving the project a high degree

of reliability on the part of the user.

viii

SIGLAS

UFRJ - Universidade Federal do Rio de Janeiro

ROV - Remotely Operated Underwater Vehicle

AUV - Autonomous Underwater Vehicle

HROV - Hybrid Remotely Operated Vehicle

PID - Controlador Proporcional, Integral Derivativo

ROS - Robot Operating System

GSCAR - Grupo de Simulacao e Controle em Automacao e Robotica

URDF - Universal Robotic Description Format

BSD - Berkeley Software Distribution

SDF - Solid Description Format

DEM - Digital Elevation Model

SIG - Sistema de Informacao Geografica

ix

Sumario

1 Introducao 1

1.1 Apresentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 A Instituicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 Historico de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . 4

1.6 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.7 Organizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Revisao Bibliografica 7

2.1 Veıculos Subaquaticos Operados Remotamente . . . . . . . . . . . . . 7

2.2 Simuladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Comparacao Entre Simuladores . . . . . . . . . . . . . . . . . 10

2.2.2 Gazebo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.4 Trabalhos na Area . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Metodologia 21

3.1 Pacotes pesquisados no Gazebo . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Construcao de um robo . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2 Construcao de um mundo . . . . . . . . . . . . . . . . . . . . 22

3.1.3 Modelo Digital de Elevacao . . . . . . . . . . . . . . . . . . . 23

3.1.4 Aplicando Forca e Torque . . . . . . . . . . . . . . . . . . . . 24

3.1.5 Plugin de Hidrodinamica . . . . . . . . . . . . . . . . . . . . . 24

3.2 Conexao com ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

x

3.2.1 Integracao Gazebo + ROS . . . . . . . . . . . . . . . . . . . . 25

3.2.2 Combinacao entre as versoes do ROS e do Gazebo . . . . . . . 26

3.2.3 Arquivo URDF no Gazebo . . . . . . . . . . . . . . . . . . . . 26

3.2.4 Comunicacao ROS - Gazebo . . . . . . . . . . . . . . . . . . . 26

3.3 QGIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.1 Quantarctica . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Earth Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Implementacao 29

4.1 Implementacao Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Insercao de um ambiente . . . . . . . . . . . . . . . . . . . . . 29

4.1.2 Insercao de um modelo . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Modelagem do HROV . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Ambiente de Simulacao . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.4 Conexao entre o ROS e o Gazebo . . . . . . . . . . . . . . . . . . . . 36

4.5 Forcas Representadas no Inercial . . . . . . . . . . . . . . . . . . . . 39

5 Conclusao 41

5.1 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Bibliografia 44

A Codigos dos Programas 46

A.0.1 Codigo XML do Mundo . . . . . . . . . . . . . . . . . . . . . 46

A.0.2 Codigo luma control node.cpp . . . . . . . . . . . . . . . . . . 63

A.0.3 Codigo luma control.h . . . . . . . . . . . . . . . . . . . . . . 64

A.0.4 Codigo luma control.cpp . . . . . . . . . . . . . . . . . . . . . 65

xi

Lista de Figuras

1.1 Vista Isometrica LUMA . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 POODLE (foto retirada de www.rebiko↵.org/History/MILESTONES/mileston.html

) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Exemplo de um robo de desenho do RoboDK . . . . . . . . . . . . . . 11

2.3 Exemplo de um robo no V-REP . . . . . . . . . . . . . . . . . . . . . 12

2.4 Comparacao em Relacao as Famılias de Robos Suportadas . . . . . . 13

2.5 Comparacao em Relacao aos Sensores Suportados . . . . . . . . . . . 13

2.6 Arquitetura geral do Gazebo . . . . . . . . . . . . . . . . . . . . . . . 15

2.7 Estrutura de Topicos do ROS . . . . . . . . . . . . . . . . . . . . . . 18

2.8 Estrutura de Servicos do ROS . . . . . . . . . . . . . . . . . . . . . . 18

2.9 Simulador UUV utilizando Gazebo no projeto Swarms . . . . . . . . 20

3.1 Exemplo de arquivo model.config . . . . . . . . . . . . . . . . . . . . 22

3.2 Exemplo de arquivo de modelo . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Parametros Globais Referentes ao Mundo Criado . . . . . . . . . . . 23

3.4 Aplicacao de Forca e Torque no Gazebo . . . . . . . . . . . . . . . . . 24

3.5 Exemplo de plugin de hidrodinamica . . . . . . . . . . . . . . . . . . 25

3.6 Estrutura do pacote gazebo ros pkgs . . . . . . . . . . . . . . . . . . 26

3.7 Codigo de inicializacao da comunicacao . . . . . . . . . . . . . . . . . 27

3.8 Exemplo de um mapa base no Quantarctica . . . . . . . . . . . . . . 28

3.9 Inicializacao de dados no EarthExplorer . . . . . . . . . . . . . . . . 28

4.1 Ambiente Asphalt Plane existente no Gazebo . . . . . . . . . . . . . 30

4.2 Modelo Cubo 20k existente no Gazebo . . . . . . . . . . . . . . . . . 30

4.3 Forca Aplicada no Centro de Massa do Cubo 20k . . . . . . . . . . . 31

4.4 Forca Aplicada na Diagonal do Plano Visualizado . . . . . . . . . . . 31

xii

4.5 Modelagem do Robo LUMA apos Importacao . . . . . . . . . . . . . 33

4.6 Imagem para mostrar o sentido e a direcao da forca na LUMA . . . . 33

4.7 Imagem para mostrar o sentido e a direcao da forca no propulsor 2 . 34

4.8 Imagem da captura da regiao da Baıa do Almarintado . . . . . . . . . 34

4.9 Imagem do Primeiro Terreno Gerado no QGIS . . . . . . . . . . . . . 35

4.10 Diferentes Configuracoes de Terrenos Testadas . . . . . . . . . . . . . 35

4.11 Ambiente de Simulacao . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.12 Interface Grafica RobotPS . . . . . . . . . . . . . . . . . . . . . . . . 37

4.13 Diagrama de conexao entre os softwares . . . . . . . . . . . . . . . . . 37

4.14 Pasta Onde os Codigos Ficam Alocados . . . . . . . . . . . . . . . . . 38

4.15 Equacao de Modelagem da LUMA . . . . . . . . . . . . . . . . . . . 39

4.16 Matriz de Desacoplamento . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1 Imagem ilustrando o resultado de uma simulacao . . . . . . . . . . . 42

5.2 Imagem ilustrando o resultado de uma simulacao vista lateral . . . . 42

xiii

Capıtulo 1

Introducao

1.1 Apresentacao

O desenvolvimento de ROV´s vem se tornando cada dia mais importante por

estes veıculos serem pequenos e permitirem a realizacao de movimentos precisos

ao navegarem pelo fundo do mar, podendo chegar onde os homens nao poderiam

(devido a limitacoes tecnicas), e locais em que o espaco e restrito, como tubulacoes

e partes de navios naufragados [1].

Com estes fatores citados acima o desenvolvimento de um simulador se tornou

fundamental para a reducao dos custos dos testes a serem realizados. Alem disso

fatores de risco ao ambiente real tambem sao reduzidos e acidentes podem ser evita-

dos. Apos um levantamento bibliografico, decidiu-se desenvolver o simulador atraves

do ambiente chamado Gazebo.

O Grupo de Simulacao e Controle em Automacao e Robotica (GSCAR) tem suas

atividades voltadas aos sistemas de controle, automacao e robotica formado por

professores e alunos das areas de engenharia Eletrica, Eletronica e Controle e Au-

tomacao da Universidade Federal do Rio de Janeiro contando com dois laboratorios

de pesquisas associados. Dentre esses laboratorios esta o LEAD - Laboratorio de

Controle e Automacao, Engenharia de Aplicacao e Desenvolvimento, que sera me-

lhor descrito na proxima secao.

1

Durante o desenvolvimento e implementacao do projeto do HROV LUMA(veıculo

subaquatico hıbrido) percebeu-se a necessidade da implementacao de um simulador

de realidade virtual. As fases para a evolucao deste projeto e os resultados desejados

podem ser melhor entendidos na Secao 1.4, ja que nela estao descritos os principais

passos e como e feita a validacao deste simulador.

1.2 Objetivos

O objetivo geral do projeto e de desenvolver um simulador para testes de robos

submarinos. Os teste sao feitos no robo LUMA desenvolvido pelo LEAD. Primei-

ramente sera realizada uma revisao de literatura, a fim de conhecer os diferentes

simuladores que se mostraram eficientes em HROV’s e em seguida implementar um

novo simulador.

1.3 A Instituicao

O projeto a ser descrito foi realizado na UFRJ, mais especificamente no LEAD,

que esta vinculado a COPPE - Instituto Alberto Luiz Coimbra de Pos-Graduacao

e Pesquisa de Engenharia, da Universidade Federal do Rio de Janeiro. Neste la-

boratorio visa-se o desenvolvimento de novas tecnologias na area de Automacao e

Controle.

Como os projetos desenvolvidos sao nas areas de Controle, Automacao e Robotica

o laboratorio conta com uma equipe interdisciplinar. Cada projeto e dividido em

equipes de Engenharia Eletronica, Engenharia Mecanica, Engenharia de Controle

dentre outras, que trabalhando em conjunto possibilitam o desenvolvimento de

veıculos complexos bem como a proposta de novas solucoes aos problemas existentes.

1.4 Justificativa

Embora ambientes de simulacao nao sejam o mesmo que os ambientes reais, por

causa das incertezas existentes, a simulacao de robos e uma ferramente muito impor-

tante nos projetos atuais. Ela possibilita verificar o desempenho de algoritmos de

2

controle antes de implementa-los no mundo real. O mesmo pode acontecer com os

algoritmos de aprendizagem, onde sao necessarios alguns testes de tentativa e erro.

Portanto, ter um ambiente virtual para acelerar o processo de aprendizagem, torna

o projeto mais seguro, nao so para o equipamento como tambem para o ambiente,

e torna o conhecimento adquirido no mundo virtual aplicavel no mundo real.

Um exemplo claro de robos que necessitam da utilizacao de simuladores com o

intuito de diminuir a quantidade de testes reais sao os ROV’s. Esses veıculos de

operacao remota sao minissubmarinos equipados com cameras de vıdeo e sensores,

para observacao do fundo do mar a distancia e que sao operados remotamente. Eles

tem sido muito utilizados para diversos tipos de atividades, sejam elas cientıficas ou

comerciais. O projeto LUMA consiste em um ROV que foi desenvolvido inicialmente

para inspecao de tuneis subaquaticos de usinas hidreletricas [2]. A partir do interesse

de um grupo de biologia marinha da UFRJ, o mesmo comecou a ser utilizado para

a exploracao de vida marinha na Antartica, captura de imagens do solo oceanico e

medida de sua geomorfologia ate uma profundidade de 300 metros (Fig. 1.1).

Apos sua primeira expedicao a Baıa do Almirantado, observou-se que as missoes

do robo seriam melhor executadas por um robo submarino autonomo (AUV), ou seja,

um veıculo sem a necessidade de um controle remoto ou piloto. Neste sentido um

novo projeto da arquitetura eletronica do robo foi realizada, de forma a aumentar o

seu poder computacional e transforma-lo em um robo hıbrido (autonomo e remoto)

[3]. Alem do novo projeto eletronico e mecanico do robo, um novo projeto de controle

tambem foi realizado. Para validar os algoritmos de controle mostrou-se necessario

o desenvolvimento do simulador.

3

Figura 1.1: Vista Isometrica LUMA

1.5 Historico de Desenvolvimento

O primeiro ROV(veıculo de operacao remota) foi criado em meados da decada

de 50 por Dimitri Rebiko↵ [4]. Ja na decada de 60 um ROV chamado CURV rea-

lizou um importante trabalho ao recuperar bombas atomicas no fundo do mar da

costa espanhola. Com isso nas decadas seguintes, os ROV’s se tornaram uma im-

portante ferramenta de trabalho nas industrias de Petroleo e Gas ate se tornarem

indispensaveis as mesmas por realizarem operacoes a mais de 200 metros de profun-

didade. A partir dos anos 2000 com o avanco das tecnologias empregadas nos robos,

a percepcao do mundo, a tomada de decisoes de acordo com essas percepcoes e a

navegacao no ambiente marinho se tornaram fundamentais para o prosseguimento

das pesquisas realizadas em ambientes muito profundos e por vezes desconhecidos

[5]. Sendo assim passou a ser necessario uma grande quantidade de testes quanto a

eficacia, qualidade e viabilidade destes veıculos. Se os testes fossem realizados dire-

tamente sobre o robo eles poderiam ser extremamente caros e ate mesmo perigosos.

1.6 Metodologia

Este trabalho, a princıpio, visa o estudo e a implementacao de um simulador

robotico em um ambiente de realidade virtual capaz de representar o movimento

4

de um HROV no fundo do mar. Seus parametros hidrodinamicos serao analisados

para que a partir de uma modelagem dada seja possıvel aplicar algumas tecnicas

de controle. Para que isso ocorra e necessario realizar alguns passos previamente ao

projeto dos controladores em si.

O primeiro deles e o estudo dos simuladores de vida marinha ja existentes alem

de uma pesquisa sobre os tipos de controle utilizados em HROV’s. A escolha do

simulador sera baseada na adequacao a alguns pre-requisitos necessarios para o bom

desenvolvimento do projeto. O primeiro deles e a de que o simulador deve ser com-

patıvel a integracao ROS(Robot Operating System). Esse pre-requisito se deve ao

fato de que o laboratorio desenvolvedor tem a intencao de padronizar todos os traba-

lhos com a utilizacao do ROS. O software em questao e uma plataforma colaborativa

de desenvolvimento robotico, na sessao 2.2.3 sera realizada uma descricao mais de-

talhada sobre o ROS. Apos isso sera utilizado o software opensource Gazebo para

implementar o novo simulador. O Gazebo simula de forma precisa e eficiente,em

ambientes complexos interiores e exteriores, populacoes de robos, alem de possuir

um motor de fısica robusta, graficos de alta e ser gratuito. Nele software ja se encon-

tra disponıvel um plugin chamado BuoyancyPlugin que sera utilizado para tratar

dos efeitos hidrodinamicos decorrentes da imersao do robo na agua.

Apos esta etapa o ambiente de simulacao sera integrado com ROS (Robot Ope-

rating System) e o controle sera realizado. E importante ressaltar que ambos os

softwares foram desenvolvidos para o sistema operacional Linux.

1.7 Organizacao

Este projeto sera elaborado em 5 capıtulos, onde no o capıtulo 1 consiste na

introducao e objetivos do projeto. No capıtulo 2 sera realizada uma revisao bibli-

ografica do tema principal do projeto, deixando para o leitor uma boa compreensao

do trabalho.

O capıtulo 3 tem a finalidade de apresentar todo o conjunto de ferramentas pes-

quisado para a evolucao do projeto como um todo. A escolha das ferramentas

5

adequadas e a implementacao do simulador estarao contidas no capıtulo 4. Nele

sera possıvel identificar alguns fatores decisivos para o sucesso do projeto. E final-

mente no capıtulo 5 estarao presentes a conclusao e os resultados finais, alem de

propostas para trabalhos futuros.

6

Capıtulo 2

Revisao Bibliografica

Este capıtulo ira abordar a progressao do desenvolvimento de simuladores como o

que sera tema deste trabalho. Nesse sentido havera uma introducao aos veıculos su-

baquaticos autonomos e em que momento se encontram suas pesquisas. Em seguida

um historico sobre os simuladores sera apresentado e alguns trabalhos realizados an-

teriormente serao retratados para ilustrar a boa execucao e utilidade dos simuladores

no contexto citado.

2.1 Veıculos Subaquaticos Operados Remotamente

A automacao de tarefas submarinas tem uma grande parcela de sua pesquisa vol-

tada para a industria o↵shore, e vem se tornando cada dia mais util na exploracao

do ambiente marinho com o objetivo de preserva-lo. Esses veıculos permitem que

espacos nunca antes observados sejam percorridos e analisados com uma certa pre-

cisao de detalhes.

Os veıculos subaquaticos operados remotamente podem ser vistos atualmente

como a melhor solucao para a realizacao de tarefas complexas. Este tipo de veıculo

tem uma retrospectiva temporal relativamente grande, por volta de 70 anos, porem

o salto do seu avanco tecnologico e atuacao na industria ocorreu nas ultimas tres

decadas. O primeiro ROV documentado na literatura foi o POODLE (Fig. 2.1).

Este robo foi desenvolvido e implementado pelo frances Dimitri Rebiko↵ em 1953

com o intuito de realizar pesquisas de arqueologia marinha em altas profundidades

7

do Mediterraneo [4]. Como a capacidade tecnica dos mergulhadores nao permitia a

pesquisa, o frances instalou uma camera em uma caixa resistente a pressao acres-

centando uma lente de agua e montando-a em um veıculo ligado a superfıcie por

meio de um cabo. O POODLE nao ficou por muito tempo em utilidade por ter

capacidades limitadas, porem foi fundamental para atrair a atencao de engenheiros

e das marinhas de todo o mundo.

Figura 2.1: POODLE (foto retirada de www.rebiko↵.org/History/MILESTONES/mileston.html

)

Em consequencia deste primeiro produto, no ano de 1960 a marinha americana

comecou a desenvolver o CURV (cable-controlled underwater recovery vehicle pro-

ject), que renovou a tecnologia dos ROV´s. A intencao deste robo era a de recuperar

submarinos naufragados e bombas atomicas nucleares na ilha Sao Clemente - Ca-

lifornia. O CURV ganhou fama em 1966 quando recuperou uma bomba de hidrogenio

do solo do Mar Mediterraneo, em sua parte localizada na costa da Espanha, proveni-

ente do incidente de Palomares [6]. Alem deste grande feito, seu sucessor, o CURV

III, teve sua importancia mundialmente reconhecida quando ajudou a resgatar a

8

tripulacao, constituıda por dois homens, de um submersıvel preso no fundo do mar

da costa da Irlanda em setembro de 1973.

A partir de 1974 a primeira classe de ROV’s comerciais comecou a ser fabricada

pela empresa americana HydroProducts [7]. O RCV255 e o RCV150 eram especies

de olhos do mar, capazes de identificar falhas e vazamentos nos tubos de petroleo.

Sendo assim eles foram muito importantes para o desenvolvimento da industria de

oleo e gas na decada de 70.

Ja na decada de 80 o aparecimento dos chamados ROV’s de baixo custo, ou

LCROV’s, trouxe uma nova dinamica ao mercado existente. Para serem classificados

de tal maneira os ROV’s deveriam ter um custo inferior a 50.000 dolares e serem

capazes de atingir ate 200 metros de profundidade. Porem por serem bem menores

e mais leves, os LCROV’s tinham funcoes limitadas em relacao a trabalhos fısicos e

sua utilidade era voltada para a observacao do ambiente marinho.

Com o avanco das pesquisas de desenvolvimento de ROV’s por todo o mundo,

os mesmos conseguiram superar cada vez mais suas limitacoes e aumentaram sua

profundidade. Um dos exemplos de inovacao foram as fontes de alimentacao, que

inicialmente eram realizadas por meio de baterias de chumbo (muito pesadas) que

com os avancos na industria quımica passaram para nıquel metal-hidreto (NiMH)

e oxido de alumınio, ate chegarem as baterias a base de lıtio (extremamente leve).

Com essa troca as fontes de energia alem de mais leves se tornaram muito mais

eficientes.

Ainda hoje grande parte dos ROV’s sao utilizados em pesquisas academicas e

cientıficas. Uma dessas pesquisas comecou em 2002 quando a empresa de ener-

gia eletrica AMPLA propos desenvolver, em parceria com o Grupo de Simulacao e

Controle em Automacao e Robotica (GSCAR), um ROV, posteriormente nomeado

LUMA, e teria intuito de realizar a inspecao em tuneis de aducao em barragens de

usinas hidreletricas [5]. Apos ser testado com sucesso em campo, o projeto despertou

o interesse do grupo de biologia marinha da UFRJ e sofreu modificacoes no ano de

2007 para que pudesse realizar expedicoes na Antartida. Desde entao novas versoes

9

da LUMA sao desenvolvidas a fim de aumentar sua eficiencia.

2.2 Simuladores

De modo geral podemos dizer que a simulacao foi fortemente impulsionada na

Segunda Guerra Mundial, quando computadores como o Mark I da marinha e o

ENIAC do exercito norte-americano foram utilizados para simular o lancamento de

mısseis e fazer calculos de balıstica. Por serem extremamente caros, os simuladores

permaneceram por muitos anos apenas em projetos militares. Apenas no final dos

anos 70 que linhas de montagem de automoveis passaram a elaborar simulacoes para

resolver problemas de seguranca e aprimorar sua producao [8]. Na decada de 90, a

utilizacao de simuladores se difundiu gracas a reducao do custo dos equipamentos,

do aumento da velocidade de processamento e pela facilitacao dos metodos de de-

senvolvimento. Assim a simulacao propagava-se na execucao de projetos, pesquisas,

e em muitas outras aplicacoes, tornando-se um caminho eficiente para as mesmas.

Com um simulador bem projetado e possıvel rapidamente algoritmos, projetar

robos, realizar testes de regressao e treinar o sistema AI usando cenarios realistas.

2.2.1 Comparacao Entre Simuladores

Novas versoes de softwares de simulacao tem oferecido uma alta gama de carac-

terısticas que facilitam a criacao de projetos realistas de grande precisao. A maior

parte das ferramentas disponıveis sao compatıveis com diferentes linguagens como

C++, Python, Java, MATLAB e etc, que oferecem diversos conjuntos de recur-

sos dependendo da sua aplicacao ou area de foco. Dentre os muitos simuladores

existentes atualmente no mercado dois deles serao citados: o RoboDK e o V-REP.

A comparacao poderia ter sido realizada com outros simuladores como o ARS, o

MORSE, SimSpark, Webots e etc.

RoboDK

ORoboDK e uma ferramenta de programacao o✏ine para robos industriais lancada

em Janeiro de 2015. A criacao do RoboDK se deu pelo sucesso do simulador robotico

10

RoKiSim desenvolvido na Ecole de Technologie Superieure (ETS) em Montreal, Ca-

nada [9]. Assim seu desenvolvedor, o Ph.D. Albert Nubiola, decidiu fundar um

produto comercial mais refinado para desenvolvedores de sistemas roboticos de todo

o mundo. Seu funcionamento e realizado atraves da utilizacao de scripts em Python

ou criando os programas visualmente atraves do ambiente de simulacao 3D integrado

ao sistema. O RoboDK funciona nos sistemas operacionais Windows, Mac OS X,

Linux e Android. Todos os programas realizados sao convertidos para linguagem

especıfica de robo antes de de irem para o robo fısico. A biblioteca disponıvel oferece

modelos 3D para mais de 200 robos industriais e ferramentas como ABB, KUKA e

etc.

O RoboDK tambem oferece varios recursos de desenvolvimento como a geracao

de alertas quando sao detectadas singularidades nos robos ou possıveis colisoes,

representacao grafica do espaco de trabalho do robo e tambem permite ao usuario

ter uma visao geral de todo o programa. Alem disso, com a API do RoboDK e

possıvel programar e simular robos atraves do Python. A versao do Python 3.4.1 e

instalada automaticamente com o instalador padrao. A API RoboDK tambem esta

disponıvel para C# e Matlab. Atualmente o RoboDK esta disponıvel gratuitamente

por um perıodo de testes ou para projetos educacionais.

Figura 2.2: Exemplo de um robo de desenho do RoboDK

V-REP

11

O simulador robotico V-REP desenvolvido pela Coppelia Robotics que possui um

ambiente de desenvolvimento integrado baseado em uma arquitetura de controle

distribuıdo [10], ou seja, cada objeto ou modelo pode ser controlado individualmente

atraves de um script, um plugin, um no ROS, um API remoto ou uma solucao

personalizada. Os controladores implementados podem ser escritos em C/C++,

Python, Java, Lua, Matlab, Octave ou Urbi. O V-REP possui uma gama ampla de

aplicacoes sendo utilizado para o desenvolvimento rapido de algoritmos, simulacoes

de automacao industrial, prototipagem, educacao robotica, monitoramento remoto,

verificacao de seguranca, etc [11].

Com mais de 400 diferentes funcoes API, 4 motores de fısica (ODE, Bullet, Vortex,

Newton), 100 servicos ROS, planejamento de trajetoria, sensores de visao e muitas

outras funcoes, o V-REP pode ser considerado um simulador bastante versatil.

Figura 2.3: Exemplo de um robo no V-REP

Comparacao

Apos a breve apresentacao das caracterısticas de dois simuladores roboticos, serao

exibidas abaixo duas tabelas comparativas entre os simuladores mais recentes.

12

Figura 2.4: Comparacao em Relacao as Famılias de Robos Suportadas

Figura 2.5: Comparacao em Relacao aos Sensores Suportados

Apos essa comparacao e possıvel verificar que o Gazebo e o Webots sao as me-

lhores opcoes. Eles apresentarem todas as caracterısticas adequadas para simular

um ROV e os sensores contidos no mesmo. A escolha do Gazebo foi feita devido a

grande disponibilidade da documentacao encontrada e por haver alguns trabalhos

desenvolvidos com ele no ramo de ROV´s, por exemplo, o projeto SWARMs [12].

Assim ele se tornou o simulador adequado para o trabalho em questao.

2.2.2 Gazebo

Por causa da dificuldade de realizar uma simulacao robotica em ambientes abertos

e sob condicoes adversas o conceito de simulacao realista foi criado e precursoramente

desenvolvido pelo Dr. Andrew Howard e seu aluno Nate Koenig em meados de

2002. O software de simulacao dinamica 3D originalmente pertencente a University

of Southern California, chamado Gazebo, continuou a ser desenvolvido por Nate

ate o ano de 2009, quando Jonh Hsu, engenheiro senior da empresa Willow Garage,

se interessou pelo projeto e integrou-o ao ROS e ao PR2 [13]. A bem-sucedida

integracao tornou o Gazebo uma das ferramentas mais utilizadas na comunidade

13

ROS e por conseguinte a Willow Garage passou a financiar o projeto em 2011. A

Open Source Robotic Foundation (OSRF) inicialmente integrante da Willow decidiu

pela desfiliacao e passou a comandar o Gazebo de maneira independente. Com essa

nova estruturacao o Virtual Robotics Challenge, parte doDARPA Robotics Challenge

comecou a utilizar o Gazebo como seu simulador oficial.

A escolha do Gazebo foi realizada por causa de um extenso numero de fatores.

Dentre eles oferecer a capacidade de simular com precisao e eficiencia populacoes de

robos em ambientes internos e externos complexos [14], como por exemplo um veıculo

subaquatico autonomo (Fig. 2.2). A seu alcance se encontra um robusto motor de

fısica, graficos de alta qualidade e interfaces programaticas e graficas convenientes.

Alem de todos esse fatores o Gazebo e opensource e possui uma comunidade ativa.

Abaixo serao listadas algumas das caracterısticas do Gazebo.

• Simulacao Dinamica: Acesso a varios motores fısicos de alta performance como

o Open Dynamics Engine (ODE), Bullet, Simbody e Dart.

• Avancados Graficos 3D: Utilizando o OGRE o Gazebo fornece uma rende-

rizacao realista de ambientes, incluindo iluminacao de alta qualidade, sombras

e texturas.

• Sensores:Gerar dados de sensores, opcionalmente com ruıdo, de localizadores

a laser, cameras 2D / 3D, sensores Kinect, sensores de contato, forca-torque e

outros.

• Plugins: Desenvolve plugins personalizados para robos, sensores, e controle

ambiental, fornecendo acesso direto a API do Gazebo.

• Modelos de Robos: Muitos robos sao fornecidos incluindo PR2, Pioneer2 DX,

iRobot Create e TurtleBot, mas tambem e possıvel criar seu proprio modelo

usando o formato Simulation Descript Format (SDF).

• Transporte TCP/IP: Executa a simulacao em servidores remotos, e faz a in-

terface para o Gazebo atraves de mensagens socket-based usando o Google

Protobufs.

14

• Integracao ROS: Um dos benefıcios de utilizar o Gazebo com o ROS e a faci-

lidade de alternar entre o mundo real e o simulado.

Figura 2.6: Arquitetura geral do Gazebo

2.2.3 ROS

O sistema operacional robotico (ROS) e um framework que escreve softwares

roboticos. Ele e constituıdo por um conjunto de ferramentas, bibliotecas (C++,

Python, LISP) e convencoes que simplificam a criacao de robos com comportamento

complexo e robusto atraves de uma enorme variedade de plataformas roboticas.

Sua motivacao foi criar uma estrutura de colaboracao aberta desejada por muitos

usuarios da comunidade de pesquisa robotica.

Sua historia teve inıcio em meados da decada de 2000 na Universidade de Stanford

quando o Stanford AI Robot (STAIR) e o Personal Robots (PR), criaram prototipos

internos de sistemas de software flexıveis e dinamicos para uso robotico. Assim como

no Gazebo a Willow Garage tambem forneceu recursos para o desenvolvimento do

ROS entre 2007 e 2013 [15]. Com isso inumeros pesquisadores contribuıram com seu

tempo e experiencia para que as principais ideias e pacotes de software indispensaveis

fossem desenvolvidos.

15

Desde o inıcio, o ROS foi desenvolvido por diversas instituicoes e para diferentes

aplicacoes roboticas. Um diferencial do projeto e que qualquer grupo tem permissao

livre para iniciar seu proprio repositorio de codigo ROS em seus proprios servidores,

e manterem total posse e controle deles. Alem disso, a opcao de tornar o repositorio

publico e segura e tem reconhecimento e credito por suas realizacoes. Ademais seus

usuarios beneficiam-se de feedback tecnico especıfico e melhorias.

O ROS-Industrial e um conjunto de ferramentas para estender o ROS para um am-

biente industrial licenciado pela Berkeley Software Distribution (BSD). Dentre mui-

tos ferramentas existentes o textitUniversal Robotic Description Format (URDF)

para robos industriais e o que mais chama atencao para a realizacao do projeto

atual.

Assim fica notoria a importancia da utilizacao do ROS para que tarefas comuns

para os seres humanos porem complexas na perspectiva de robos (ex:mover os dedos)

sejam realizadas de maneira mais simples. Esse objetivo e atingido pois o ROS

e uma plataforma de desenvolvimento colaborativo de software robotico. Sendo

assim laboratorios de todo o mundo contribuem com a comunidade atraves de seus

conhecimentos especıficos em diversos ramos, como por exemplo, mapeamento de

ambientes internos, reconhecimento de objetos e etc.

2.2.3.1 Conceito

O ROS tem tres nıveis de conceito: o Filesystem, o Computation Graph e o

Community.

O nıvel filesystem cobre basicamente os recursos ROS que encontram-se no disco.

Um exemplo classico e o pacote. Um pacote e essencialmente uma unidade de

organizacao do software em ROS. Essa unidade pode conter processos de execucao

(nos), bibliotecas dependentes de ROS, arquivos de configuracao ou qualquer coisa

que seja util ao ser organizada junto.

Computer Graph e a rede peer-to-peer de processos ROS que estao processando da-

dos juntos. Os conceitos basicos do Grafico sao nos, mestre, servidor de parametros,

16

mensagens, servicos, topicos e sacos, todos fornecendo dados ao grafico de diferentes

maneiras. Esses conceitos sao implementados no repositorio roscomm.

• textitNodes: Sao processos performam a computacao. ROS e designado para

ser modular em uma escala refinada. Um sistema de controle robotico normal-

mente utiliza muitos nos. E importante dizer que um no e escrito com o uso

da biblioteca cliente do ROS, como roscpp ou rospy.

• textitMaster: O ROS mestre cria um nome de registro e procura pelo res-

tante no Computation Graph. Sem o master nao seria possıvel que os nos se

encontrassem, trocassem mensagens ou pedissem servicos mutuamente.

• textitMessages: Os nos comunicam-se entre si por meio de transmissao de

mensagens. Uma mensagem e sobretudo uma estrutura de dados, com campos

digitados. Padroes primitivos como float, boolean e int sao aceitos assim como

arrays.

• textitTopics: As mensagens sao enviadas via sistema de transporte com semantica

de publicacao/subscricao. Um no envia uma mensagem publicando-a para

um determinado topico. O topico e um nome que e usado para identificar

o conteudo da mensagem. Um no que esta interessado em um determinado

tipo de dado ira subscrever o topico apropriado. Um exemplo de estrutura de

topicos e mostrado na figura 2.4.

• textitServices: O modelo publicado/subscrito e uma norma de comunicacao

muito flexıvel, porem seu transporte de sentido unico nao e apropriado para

solicitacao/resposta de interacoes, que sao muitas vezes necessarias em um

sistema distribuıdo. A solicitacao/resposta e feita atraves de servicos, que

sao definidos por um par de estruturas de mensagem: uma para a solicitacao

e outra para a resposta. A biblioteca cliente ROS geralmente apresenta es-

sas iteracoes ao programados como se fossem um procedimento de chamada

remoto. E possıvel visualizar uma estrutura base na figura 2.5.

• textitBags: Sao um formato para salvar e acessar dados de mensagem ROS.

Eles sao um importante mecanismo de armazenamento de dados, como dados

17

de sensores, que dificilmente podem ser coletados, mas sao necessarios para o

desenvolvimento e testes de algoritmos.

O mestre atua como um servico no Computation Graph do ROS. Assim ele ar-

mazena informacoes de registro de topicos e servicos para os nos, e esses nos se

comunicam com o master para reportar sua informacao de registro. Por causa dessa

comunicacao eles podem receber informacoes sobre outros nos registrados e realizar

conexoes apropriadamente.

Figura 2.7: Estrutura de Topicos do ROS

Figura 2.8: Estrutura de Servicos do ROS

Community : Os conceitos do ROS Community sao as pesquisas de ROS que sao

habilitadas para separar comunidades para fazerem trocas de software e conheci-

mento, como pro exemplo um repositorio, ROS Wiki e etc.

ROS Application Programming Interface (API) Plugin: Esse plugin inicializa um

no chamado gazebo e entao integra o escalonador de retorno de chamada ROS com

o escalonador interno do Gazebo. Esse ROS API habilita o usuario a manipular as

18

propriedades do ambiente de simulacao do ROS, assim como se espalha e retrai no

estado dos modelos no ambiente.

2.2.4 Trabalhos na Area

Com o avanco da tecnologia muitos projetos de ROV’s foram desenvolvidos, prin-

cipalmente para uso da industria o↵shore. Ja no meio cientıfico ao realizarmos uma

busca para saber quais obtiveram maior destaque na area e possıvel citar um trabalho

recente bastante relevante que e o projeto Smart and Networking Underwater Ro-

bots in Cooperation Meshes (SWARMs). O principal objetivo do projeto SWARMs

e facilitar a criacao, o planejamento e execucao de operacoes marıtimas com o uso

de AUV’s e ROV’s. A finalidade deste projeto e de tornar as missoes mais rentaveis

e seguras.

O sistema proposto no projeto SWARMs permite a integracao de robos de diferen-

tes fabricantes, aumentando assim a rentabilidade dos AUV’s e ROV’s, assim como

torna-os acessıveis para outras industrias com menos recursos financeiros. Alguns

objetivos especıficos foram definidos ao projeto para que a principal finalidade fosse

alcancada. Esses objetivos sao:

• Permitir que os ROV’s trabalhem em uma malha cooperativa abrindo as-

sim novas aplicacoes, assegurando sua reutilizacao, promovendo veıculos he-

terogeneos padronizados que podem combinar as suas capacidades, em detri-

mento de outros veıculos especializados caros.

• Aumentar a autonomia dos AUVs e melhorar a usabilidade dos ROVs para a

execucao de tarefas simples e complexas, contribuindo para a sofisticacao das

operacoes da missao.

Para tanto o projeto de criacao de uma plataforma de simulacao robotica de

uso geral para ambientes subaquaticos foi desenvolvido. Esta plataforma e capaz de

simular multiplos robos subaquaticos e tarefas de intervencao usando manipuladores.

Esta finalidade so e alcancada por causa de um conjuntos de plugins que foram

implementados para modelar efeitos hidrostaticos e hidrodinamicos, propulsores,

19

sensores e disturbios externos. O grande diferencial desse projeto e a possibilidade

de reutilizacao da plataforma.

Figura 2.9: Simulador UUV utilizando Gazebo no projeto Swarms

Muitos dos conceitos citados acima foram utilizados na realizacao deste trabalho.

Alem de ter sido desenvolvido a partir do Gazebo, os conceitos dos efeitos hidro-

dinamicos tambem foram empregados. Tambem vale lembrar que a LUMA e um

HROV, ou seja, uma nova maneira de unir ROV e AUV em um unico veıculo.

20

Capıtulo 3

Metodologia

Este capıtulo mostrara todos os pacotes e plugins pesquisados e necessarios para

a realizacao de um simulador em ambiente subaquatico, bem como a integracao do

mesmo com algum tipo de interface.

3.1 Pacotes pesquisados no Gazebo

3.1.1 Construcao de um robo

Os modelos existentes no Gazebo tem caracterısticas definidas por uma entidade

fısica que possui propriedades dinamicas, cinematicas e visuais. Alem disso, um

modelo pode ter um ou mais plugins, que afetam o seu comportamento. Um banco

de dados de um modelo deve respeitar a estrutura de arquivos de um diretorio

especıfico. A raiz desse banco de dados possui um diretorio para cada modelo e

um arquivo database.config que contem as informacoes sobre ele. Nesse diretorio

tambem e possıvel encontrar um arquivo model.config, que contem os metadados do

modelo, e o arquivo SDF que descreve os materiais, malhas e plugins do mesmo.

21

Figura 3.1: Exemplo de arquivo model.config

Os modelos SDF podem variar de formas simples a robos complexos. O arquivo

SDF e essencialmente uma colecao de elos, juntas, objetos de colisao, recursos visuais

e plugins. Para mais informacoes sobre como criar os modelos basta acessar o site

do Gazebo que consta com uma vasta quantidade de tutoriais a respeito.

Figura 3.2: Exemplo de arquivo de modelo

3.1.2 Construcao de um mundo

Os mundos ja existentes ou que possam ser gerados no Gazebo sao arquivos de

extensao .world que descrevem uma colecao de robos e objetos, e parametros globais,

incluindo o ceu, luz ambiente e propriedades fısicas. Ou seja, possuem informacoes a

respeito do ambiente, da organizacao fısica desse ambiente e dos modelos que serao

inseridos no mesmo.

A posicao, rotacao, translacao e escala dos modelos tambem podem ser alteradas,

assim como a adicao ou retirada dos mesmos no mundo que esta em construcao. As

propriedades globais de cenario (como cores do ceu, do chao e texturas dos objetos),

22

e fısicas (como forca de gravidade e velocidades dos objetos) sao alteraveis para a

finalidade desejada.

Figura 3.3: Parametros Globais Referentes ao Mundo Criado

3.1.3 Modelo Digital de Elevacao

Um Digital Elevation Model (DEM) e uma representacao 3D da superfıcie de um

terreno que nao inclui objetos alem do proprio terreno. Os DEMs sao criados usando

uma combinacao de sensores, como LIDAR, radar ou cameras. As elevacoes do ter-

reno para as posicoes no solo sao amostradas em intervalos horizontais regularmente

espacados. Uma DEM pode ser representada como uma grade de elevacoes (raster)

(tambem conhecido como um heightmap ao representar elevacoes) ou como uma rede

irregular triangular baseada em vetores (TIN). A motivacao para utilizar DEMs no

Gazebo e a capacidade de simular um terreno realista.

Existem muitas organizacoes que fornecem arquivos DEM. Normalmente esses

arquivos possuem alta resolucao e nao tem suporte no Gazebo. Assim e preciso

ajustar a resolucao do arquivo, afim de importa-lo no Gazebo, que ira detectar

automaticamente o arquivo como uma imagem plana ou uma DEM. Para trabalhar

com arquivos DEM e necessario instalar a biblioteca GDAL. Ela e uma biblioteca

computacional para leitura e escrita de dados raster e vetores geoespaciais.

23

3.1.4 Aplicando Forca e Torque

E possıvel aplicar forcas e torques no corpo do modelo ou em suas juntas direta-

mente pela interface do Gazebo, mesmo durante execucao de um modelo. As forcas

e torques podem ser aplicadas nos tres eixos do link desejado, alem de definirem o

centro de massa como ponto de aplicacao da forca se assim for desejado. Para isso

basta clicar com o botao direito do mouse sobre o modelo e selecionar a opcao Apply

Force and Torque.

Figura 3.4: Aplicacao de Forca e Torque no Gazebo

3.1.5 Plugin de Hidrodinamica

O Gazebo permite que o usuario crie plugins ou utilize os ja existentes para

controlar modelos, sensores, propriedades do mundo e ate mesmo o jeito que o

Gazebo funciona. Dentre os ja contidos no Gazebo existe o BuoyancyPlugin que

simula o comportamento de objetos submersos. Esse plugin baseia-se no Princıpio

de Arquimedes que diz que a forca de empuxo exercida sobre um objeto sumerso

em um fluido e igual ao peso do fluido deslocado pelo objeto. Para saber essa forca

e preciso conhecer o volume do objeto, a densidade do fluido e a gravidade. Esse

plugin calcula a forca de empuxo para cada link do modelo e aplica a forca no centro

de volume do link.

24

Figura 3.5: Exemplo de plugin de hidrodinamica

3.2 Conexao com ROS

3.2.1 Integracao Gazebo + ROS

Para conseguir a integracao do ROS com o Gazebo, um conjunto de pacotes ROS

denominados gazebo ros pkgs fornece envoltorios em torno do Gazebo autonomo.

Eles fornecem as interfaces necessarias para simular um robo no Gazebo utilizando

mensagens ROS, servicos e reconfiguracao dinamica. Algumas caracterısticas desse

pacote sao:

• Suporta uma dependencia de sistema independente do Gazebo, que nao tem

ligacoes ROS por conta propria.

• Constroi com catkin.

• Trata URDF e SDF da forma mais equivalente possıvel.

• Reduz a duplicacao de codigo com o Gazebo.

• Melhora o suporte para controladores usando roscontrol.

• Integra melhorias de eficiencia em tempo real do controlador do DARPA Ro-

botics Challenge.

• Limpa o codigo antigo das versoes anteriores do ROS e do Gazebo.

25

Figura 3.6: Estrutura do pacote gazebo ros pkgs

3.2.2 Combinacao entre as versoes do ROS e do Gazebo

Existem tres versoes disponıveis do ROS compatıveis com o Gazebo que sao:

Kinetic para os pacotes 7.x do Gazebo, Jade para os pacotes 5.x e Indigo para os

pacotes 2.x.

3.2.3 Arquivo URDF no Gazebo

Os arquivos URDF´s sao muito utilizados no ROS para descrever todos os ele-

mentos de um robo, porem nao sao capazes de identificar a posicao do robo em um

ambiente, a forca de atrito ou a uniao entre as juntas. Sendo assim e necessario

adicionar algumas tags ao modelo URDF para que ele funcione apropriadamente no

Gazebo. Um exemplo e a inercia de cada que deve ser configurada para que a engine

de fısica do Gazebo execute corretamente.

3.2.4 Comunicacao ROS - Gazebo

Atraves dos pacotes gazebo ros pkgs, que realiza a integracao entre o ROS e o Ga-

zebo e possivel acessar diversos aspectos do mundo simulado. Para que isso aconteca

e necessario que o ROS esteja sendo executado e que o Gazebo seja inicializado a

partir do ROS.

26

Figura 3.7: Codigo de inicializacao da comunicacao

Com a comunicacao sendo realizada e possıvel acessar a posicao e orientacao (pose)

do robo assim como sua velocidade (twist) a partir da terminologia (link states). Da

mesma maneira pode-se ter acesso a massa e a tracao do robo pela terminologia

(properties) entre outros que sao melhor explicados no site nos tutoriais do Gazebo.

3.3 QGIS

O QGIS e um Sistema de Informacao Geografica (SIG) opensource, licenciado

pela GNU General Public License. O sistema suporta diversos formatos vetoriais,

raster, banco de dados entre outros, e esta disponıvel para Linux, Unix, Mac OSX

,Windows e Android [16]. Com ele e possıvel visualizar, gerenciar, editar, analisar

os dados e compor mapas.

3.3.1 Quantarctica

O Quantarctica (Quantum GIS + Antarctica) foi criado com a finalidade de obter

um conjunto de dados antarticos essenciais aos glaciologos, que fosse de baixo custo,

facil manuseio e completo. Foi desenvolvido a principio pelo Instituto Polar Noru-

egues para uso interno, mas desde sua primeira versao publica, lancada em 2013,

conta com colaboradores de todo o mundo. O Quantarctica e gratuito e utilizado

para fins nao-comerciais, como pesquisa, educacao e operacao na Antartida [17].

Sua colecao de dados compreende dados geograficos antarticos de centros de dados

mundiais, como imagens de satelite, glaciologia, informacoes geofısicas, mapas base

(como na figura 3.7) e etc.

27

Figura 3.8: Exemplo de um mapa base no Quantarctica

3.4 Earth Explorer

A ferramenta online EarthExplorer (EE) permite a pesquisa, consulta, enco-

menda, e descoberta de imagens de satelite, fotografias aereas, produtos cartograficos

e sensoriamento remoto de varias fontes. Foi desenvolvido pelo United States Geo-

logical Survey (USGS). Possui dados das missoes Landsat, MODIS, Aqua, alem de

diversos outros recursos.

Figura 3.9: Inicializacao de dados no EarthExplorer

Neste trabalho essa plataforma foi utilizada para capturar o modelo de elevacao

digital da Baıa do Almarintado.

28

Capıtulo 4

Implementacao

Neste capıtulo sera detalhado todo o processo de desenvolvimento deste trabalho.

Inicialmente sera apresentado um exemplo de como realizar os procedimentos com

modelos ja existentes no Gazebo. Apos esta exemplificacao o projeto LUMA sera

detalhado desde a importacao do modelo do robo no Gazebo, passando pela criacao

do ambiente marinho Antartico ate a utilizacao do software ROS para que as tecnicas

de controle sejam validadas e o objetivo final seja alcancado.

4.1 Implementacao Teste

Para efeito de melhor entendimento de como se da o funcionamento do Gazebo,

um exemplo de teste foi criado. A partir desse exemplo e possıvel verificar a gama

de funcoes disponıveis no Gazebo, bem como todos os erros que podem ser gerados

no trabalho como um todo.

4.1.1 Insercao de um ambiente

No software Gazebo e possıvel realizar simulacoes com uma infinidades de modelos

diferentes. Inclusive alguns exemplos de modelos de objetos e robos, alem de dife-

rentes ambientes sao encontrados na aba textitInsert localizada no canto superior

esquerdo do programa.

Analisando os modelos disponibilizados no arquivo padrao do Gazebo foi possıvel

verificar a existencia de alguns que simulam terrenos irregulares, e que portanto

29

provocam atrito ao entrarem em contato com algum objeto em movimento. Nesse

intuito o ambiente textitAsphalt Plane foi escolhido para participar do desenvolvi-

mento do teste.

Figura 4.1: Ambiente Asphalt Plane existente no Gazebo

4.1.2 Insercao de um modelo

Pensando em uma forma geometrica que pudesse representar a LUMA, o modelo

de um cubo chamado Cubo 20k de, 0,5m x 0,5m x 0,5m e com peso de 1kg, ja

existente do Gazebo foi escolhido para efetuar os testes do exemplo.

Figura 4.2: Modelo Cubo 20k existente no Gazebo

30

Como ja havia sido citado anteriormente no Gazebo e possıvel aplicar uma forca

ou um toque no centro de massa do modelo ou de uma de suas juntas. No modelo

deste cubo nenhuma junta foi criada e portanto a forca sera aplicada no seu centro

de massa.

Figura 4.3: Forca Aplicada no Centro de Massa do Cubo 20k

Neste exemplo sera aplicada uma forca de 800N que sera dividida nos eixos X e

Y para que o modelo se mova na diagonal do plano visualizado.

Figura 4.4: Forca Aplicada na Diagonal do Plano Visualizado

31

4.2 Modelagem do HROV

Com o intuito de tornar o trabalho o mais realista possıvel houve o desejo de intro-

duzir no Gazebo a modelagem da LUMA criada no software SolidWorks que contem

todas as dimensoes e caracterısticas reais detalhadas do robo, inclusive massa, cen-

tros de inercia e volume. Para que essa precisao pudesse ser alcancada foi necessario

utilizar um plugin de importacao acessıvel aos usuarios do SolidWorks, chamado

SW2URDF que exporta o modelo em um arquivo URDF. Este tipo de arquivo

XML e usado frequentemente em ROS para simulacao e testes. O arquivo e uma

estrutura em arvore de links chamados child (como rodas e bracos) conectados aos

links parent (como a engranagem central) por uma serie de articulacoes. Este ar-

quivo e a descricao de como seu sistema se move internamente e isso determinara

como ele pode interagir com o ambiente. Apesar disso, as capacidades do arquivo sao

limitadas em comparacao com o formato de descricao SDF utilizado no simulador .

Sendo assim, o primeiro passo para realizar a exportacao do modelo e a instalacao

do plugin SW2URDF no SolidWorks. Com o modelo da LUMA criado no software

e o plugin corretamente instalado, e necessario comecar a exportacao. A partir

deste passo deve-se definir quais sao as juntas do robo e de que tipo elas sao. As

possibilidades para essa definicao sao: Fixa, revoluta, prismatica e contınua. Para

esta realizacao cada um dos 5 propulsores existentes na LUMA foram definidos como

juntas revolutas. Como o Gazebo nao da suporte a juntas fixas foi necessario definir

como juntas revolutas, ou seja, que tem 1 grau de liberdade permitindo a rotacao em

torno de um unico eixo, que deve ser demarcado no modelo, e com limites inferior e

superior iguais a zero.

Apos todas as definicoes realizadas basta seguir com a exportacao do modelo. A

exportacao gera uma pasta que contem um arquivo URDF, alem dos meshes, launch

e textures. Essa pasta gerada e inserida no .models do Gazebo para integra-lo ao

conteudo do programa.

Abaixo se encontra a imagem do robo sem nenhum ambiente pre-definido no

Gazebo, apenas para fins de uma visualizacao mais detalhada do modelo apos sua

exportacao. No Apendice A esta disponıvel o codigo XML do modelo do robo. Nele

32

e possıvel verificar a existencia o parent link LUMA contendo a pose, a colision e o

visual do robo, alem dos child links que sao cada um dos 5 propulsores contendo os

mesmos tipos de informacoes que a LUMA.

Figura 4.5: Modelagem do Robo LUMA apos Importacao

Ainda no contexto do modelo fısico exportado e importante salientar que no Ga-

zebo e possıvel aplicar no robo uma forca e/ou um torque a cada uma das juntas e

no robo como um todo. Para melhor ilustrar o assunto abordado as figuras 4.2 e 4.3

mostram respectivamente a direcao e o sentido da forca e do torque que podem ser

aplicados a LUMA e ao propulsor 2.

Figura 4.6: Imagem para mostrar o sentido e a direcao da forca na LUMA

33

Figura 4.7: Imagem para mostrar o sentido e a direcao da forca no propulsor 2

4.3 Ambiente de Simulacao

Apos as pesquisas sobre como criar uma DEM que fosse compatıvel com o Gazebo,

a conclusao foi que seria necessario gerar um arquivo TIFF a partir do EarthExplorer

para posterior tratamento no QGIS. Essa decisao foi tomada pois os bancos de dados

do EarthExplorer sao atualizados constantemente e possuem uma resolucao mais

adequada para o proposito final. Para tanto foram escolhidos 4 pontos no mapa

geografico, que delimitavam uma regiao de 200x200 metros quadrados da Baıa do

Almarintado como e mostrado na figura abaixo.

Figura 4.8: Imagem da captura da regiao da Baıa do Almarintado

34

O arquivo TIFF gerado apresenta diferentes tonalidades de cores que representam

as elevacoes do terreno. Afim de ajudar o entendimento do leitor abaixo se encontra a

primeira imagem gerada no QGIS, onde os tons mais escuros representam uma maior

profundidade do solo, enquanto os mais claros representam menor profundidade.

Figura 4.9: Imagem do Primeiro Terreno Gerado no QGIS

Com o arquivo TIFF criado, e fundamental realizar a mudanca de alguns parametros

como cor, brilho, contraste e texturas do terreno. Neste trabalho foi verificado que

a criacao do terreno deveria acontecer em escala de cinza para que o Gazebo inter-

pretasse as elevacoes com clareza e o ambiente se tornasse fiel ao idealizado. Para

o leitor que tem desejo de realizar projetos com o mesmo perfil e valida a leitura de

um tutorial [18] a respeito de como configurar um bom mapa no QGIS.

Figura 4.10: Diferentes Configuracoes de Terrenos Testadas

35

Com o terreno devidamente modificado para os interesses da pesquisa, basta sal-

var a imagem como uma imagem png e adiciona-la no .textures da pasta Gazebo

existente no sistema.

Com o terreno devidamente inserido no Gazebo e o modelo do robo conjuntamente,

foram alteradas as tonalidades do ground e do ambient para se assemelharem ao

fundo do mar. Apos todas os ajustes o mundo foi salvo para que entao a bridge

entre o ROS e o simulador fosse criada. Abaixo se encontra a imagem do ambiente

de simulacao. No Apendice A tambem e possıvel identificar todos os parametros do

ambiente de simulacao.

Figura 4.11: Ambiente de Simulacao

4.4 Conexao entre o ROS e o Gazebo

Para poder explicitar todo o desenvolvimento do projeto e necessario primeira-

mente dizer que uma interface grafica chamada RobotPS foi utilizada para enviar

mensagens de controle ao ROS. Essa ferramenta vem sendo utilizada para controlar

a LUMA nos testes realizados no LEAD e se mostrou adequada para o trabalho

atual.

36

Figura 4.12: Interface Grafica RobotPS

Para realizar a conexao entre o ROS e o Gazebo foi necessario inicialmente saber

quais tipos de mensagens o Gazebo fornecia como resposta aos estımulos, assim como

quais informacoes eram relevantes ao ROS para fazer o processamento adequado.

Ao pesquisar no Gazebo foi possıvel verificar que existem mensagens como LinkS-

tates, ApplyBodyWrench, BodyRequest e outras. No projeto em questao as tres

mensagens sao importantes, sendo que a primeira contem as posicoes e velocidades

atuais de todas as juntas se tornando assim essencial ao programa. O objetivo do

programa sera entao de ler a mensagem de controle dada pela interface grafica, ler

os estados de cada uma das juntas que e proveniente do Gazebo, e transformar es-

sas informacoes em uma mensagem de forca para a LUMA. Sendo assim a figura

4.13 tem o intuito de mostrar uma visao global do funcionamento da bridge ente

os 3 softwares, e a figura 4.8 de dar ao leitor uma melhor compreensao de quais

mensagens e servicos foram utilizados no projeto.

Figura 4.13: Diagrama de conexao entre os softwares

37

Como pode ser visto acima a interface grafica chama uma funcao e nessa funcao

e publicada uma mensagem que envia ao ROS a informacao de controle que deve

ser aplicada ao corpo rıgido. Essa mensagem de controle da a opcao de controlar os

eixos x e y por forca, e z e yaw por forca ou posicao (profundidade e orientacao em

relacao ao Norte) com valores que variam de -1 a 1. Neste trabalho em particular

foi realizado apenas o controle por forca.

O Gazebo envia uma mensagem ao ROS que contem as informacoes de posicao

e velocidade de cada uma das juntas. Ele tambem possui um servico para enviar

forcas e torques nos elos do corpo (ApplyBodyWrench) alem de outro servico que

zera essas informacoes no corpo (ClearBodyWrench). O ROS por sua vez chama

esses servicos, assim como produz os callbacks, ou seja, funcoes executadas quando

chegam mensagens de ROS. Sendo assim tambem e possıvel ratificar a ideia de que

mensagens de ROS sao unilaterais assim como servicos sao bilaterais.

No pacote ROS acima o construtor da classe LumaControl se encontra em luma control.cpp

e em luma control.h. Esse construtor tem a funcao de executar os callbacks no Luma-

Control ao receber alguma mensagem da interface grafica ou do Gazebo. O callback

dos LinkStates atualiza uma variavel da classe e o callback do controle usara a

posicao atual do robo e os dados de controle para gerar as forcas dos propulsores

que serao enviados para o Gazebo por um servico.

Falando sobre a construcao dos arquivos citados acima e necessario dizer que todos

os codigos criados foram alocados numa pasta chamada textitRobotPS criada em

textitcatkin dentro da pasta textitsrc da maquina.

Figura 4.14: Pasta Onde os Codigos Ficam Alocados

38

No Apendice A e possıvel verificar toda a construcao do codigo realizado para a

conexao do ROS ao Gazebo e ao RobotPS.

4.5 Forcas Representadas no Inercial

Para a criacao de um simulador com qualquer tipo de objeto ou robo que venha a

ser movimentado e necessario realizar a modelagem do modelo, afim de descrever ao

simulador onde as forcas devem ser aplicadas e que tipos de forcas sao essas. Para

um corpo rıgido, como e a LUMA, a equacao da modelagem nada mais e do que a

aplicacao da lei de Newton, que diz que o somatorio das forcas e igual a massa vezes

a aceleracao.

Figura 4.15: Equacao de Modelagem da LUMA

Onde:

• M - Matriz de inercias do corpo rıgido.

• C - Matriz das forcas centrıpetas e de Coriolis.

• D - Matriz devido as forcas de atrito.

• G - Matriz das forcas restauradoras e gravitacionais.

• v- E a aceleracao referenciada ao proprio corpo.

• v - E a velocidade referenciada ao proprio veıculo.

• ⌘2 - Posicao referenciada ao sistema fısico.

• ⌧ - Vetor de forcas que atuam no HROV, como a propulsao.

No software utilizado o robo se movimenta atraves de forcas nos propulsores,

porem seu controle so enxerga essa forca no centro de massa. Com a informacao

de que o Gazebo possui um referencial proprio para cada uma das juntas torna-se

39

necessario ao desenvolvedor realizar uma matriz de desacomplamento e uma matriz

de rotacao para levar o referencial inercial ao referencial de cada propulsor dado

pelo Gazebo. No Apencice A.0.4 se encontram as funcoes que realizaram essa trans-

formacao.

Para esclarecimentos gerais, a matriz de desacoplamento tem a funcao de trans-

formar a informacao de forca aplicada em cada eixo, proveniente da interface, em

forcas separadas para cada um dos propulsores. Em seguida a matriz de rotacao

transformara essa informacao de forca em uma informacao 3D que sera enviada ao

Gazebo. Cabe lembrar de que o uso de quaternions na funcao foi preciso para que o

ROS compreendesse a mensagem de maneira correta. Abaixo se encontra a matriz

de desacoplamento utilizada no projeto.

Figura 4.16: Matriz de Desacoplamento

Onde:

Ressalta-se ainda o fato de que nao era obrigatorio o uso da matriz de desacopla-

mento no programa, mas que a mesma melhora a precisao dos resultados. Isso se

deve ao fato de que o Gazebo possui uma modelagem interna, diferente da realizada

pelo desenvolvedor, que e capaz de realizar a conexao das mensagens de aplicacao

de forca. Neste caso seria possıvel enviar o dado da forca diretamente sobre o corpo

rıgido no Gazebo, deixando o programa com menor complexidade.

40

Capıtulo 5

Conclusao

Este capıtulo tem a funcao de mostrar os resultados obtidos a partir do trabalho

elaborado. Alem disso tambem serao apresentadas propostas de continuidade que

podem ser realizadas para conquistar melhorias no sistema como um todo.

5.1 Testes

Como o objetivo do projeto era criar um simulador, os testes se tornaram em geral

bem mais simples do que seriam os testes sobre corpos rıgidos. Essa afirmacao e

feita pois o simulador nao e dependente do corpo, sendo assim os riscos sao pequenos

e o codigo e passıvel de mudanca constante com certa facilidade.

Com o ambiente realista e a importacao do corpo feita de modo correto, foi im-

plementada uma funcao chamada bypass thruster, para verificar se as mensagens

chegavam ao ROS e ao simulador. Esse teste foi realizado com sucesso e comprovou

a boa comunicacao entre os softwares.

Outro teste realizado eficientemente foi o de verificar qual seria a reacao do robo

ao receber uma forca em um dos eixos possıveis. Como o desenvolvimento deste

projeto nao considerava a leitura de dados nao e possıvel validar o simulador atraves

de controle de trajetorias. Assim, a avaliacao dos resultados a respeito da qualidade

do simulador foi feita de maneira visual.

41

Figura 5.1: Imagem ilustrando o resultado de uma simulacao

Figura 5.2: Imagem ilustrando o resultado de uma simulacao vista lateral

5.2 Resultados

O trabalho em questao teve retratou o progresso do desenvolvimento de um simu-

lador para um veıculo hıbrido utilizando a ferramenta ROS. Os resultados alcancados

foram suficientes ao proposto a princıpio. Ao final do trabalho conquistou-se um

simulador capaz de utilizar as diversas funcoes oferecidas pelo Gazebo.

O robo desenvolvido para a simulacao tem caracterısticas fısicas iguais ao veıculo

real e as simulacoes realizadas trouxeram maior seguranca para a realizacao de testes

reais.

42

A utilizacao da interface RobotPS no projeto tornou o simulador ainda mais util,

ja que o LEAD utiliza essa interface em todos os seus robos em desenvolvimento.

Assim os metodos utilizados e testados sobre o simulador podem ser realizados

com outros robos alem da LUMA. Apesar de este ser o primeiro trabalho sobre o

simulador ja e possıvel pensa no mesmo como uma base para futuros complementos.

Em relacao ao conhecimento, o trabalho foi extremamente engrandecedor no que-

sito de organizacao temporal de projetos e na motivacao de seguir adiante ainda que

com grandes obstaculos. Alem disso o projeto possibilitou um enorme aprendizado

em relacao a novas tecnicas de desenvolvimento robotico e no amadurecimento do

conhecimento adquirido anteriormente.

5.3 Trabalhos Futuros

Como sugestao de continuidade ao projeto, programa desenvolvido para o robo

deve ser aprofundado para incluir a resistencia da agua como parametro do ambiente.

Com essa adicao o simulador sera capaz de mostrar quais sao as forcas que deixam

o corpo rıgido em equilıbrio no momento inicial, ou seja, uma estabilizacao do robo.

Para um melhor aproveitamento da escolha do Gazebo neste projeto e interessante

que outros plugins como o LiftDragPlugin, ou sensores como cameras, lasers, entre

outros sejam explorados.

Com estes primeiros aspectos resolvidos e possıvel pensar no controle de pro-

fundidade e orientacao ainda nao desenvolvidos no projeto, bem como o estudo e

implementacao de tecnicas de controle (PID+ feedfoward, PPI, etc) e controle de

trajetoria.

43

Referencias Bibliograficas

[1] FEDERAL, U., GERAIS, D. M., CURSO, P. F. D., et al., “Desenvolvimento

de um Simulador para um VeAculo AutA´nomo”, 2010.

[2] CARNEIRO, R. F., L. A. C. P. A. J. G. C. C. R. R. L. F. . H. L. ., “Underwater

robot for tunnel inspection: design and control”. In: Proc. of the 12th Latin-

American Congress on Automatic Control (CLCA), 2006.

[3] CARNEIRO, R. F., A learning algorithm to replan and adapt the mission of

an autonomous underwater vehicle. Ph.D. dissertation, UFRJ/COPPE, 2016.

[4] MARZBANRAD, A., SHARAFI, J., EGHTESAD, M., et al., “Design, cons-

truction and control of a remotely operated vehicle (ROV)”, International Me-

chanical Engineering Congress and Exposition, , n. November, pp. 1295 – 1304,

2011.

[5] GOULART, C., Modelagem, Simulacao E Controle De Um Veıculo Submarino

De Operacao Remota. Ph.D. dissertation, UFRJ, 2014.

[6] MICHEL, D., M. T. S. D. Z. J., “Remotely Operated Vehicles (ROVs)”. In:

KNOWLEDGE AND SKILL GUIDELINES FOR MARINE SCIENCE AND

TECHNOLOGY, volume 3, 2011.

[7] http://www.rov.org/rov_history.cf.

[8] BALADEZ, F., “O passado, o presente e o futuro dos simuladores”. In: Fasci-

Tech Periodico Eletronico da FATEC-Sao Caetano do Sul, Sao Caetano do Sul,

v.1, n. 1, pp. 29–40, 2009.

[9] http://www.robodk.com/.

44

[10] NOGUEIRA, L., “Comparative Analysis Between Gazebo and V-REP Robotic

Simulators”, .

[11]

[12] MANHA£ES, M. M. M., SCHERER, S. A., VOSS, M., et al., “UUV Simu-

lator: A Gazebo-based package for underwater intervention and multi-robot

simulation”. In: OCEANS 2016 MTS/IEEE Monterey, pp. 1–8, Sept 2016.

[13] http://gazebosim.org/.

[14] KOENIG, N., HOWARD, A., “Design and Use Paradigms for Gazebo, An

Open-Source Multi-Robot Simulator”. In: In IEEE/RSJ International Confe-

rence on Intelligent Robots and Systems, pp. 2149–2154, 2004.

[15] http://www.ros.org/history/.

[16] http://qgisbrasil.org/.

[17] http://quantarctica.npolar.no/.

[18]

45

Apendice A

Codigos dos Programas

Este apendice contem o codigo do mundo, criado a partir do ambiente de simulacao

e da importacao do modelo do robo.

A.0.1 Codigo XML do Mundo

<?xml ve r s i on =”1.0” ?>

<sd f v e r s i on = ’1.6 ’>

<world name=’ de fau l t ’>

< l i g h t name=’sun ’ type=’ d i r e c t i o n a l ’>

<cast shadows>1</cast shadows>

<pose frame=’’>0 0 10 0 �0 0</pose>

<d i f f u s e >0.8 0 . 8 0 . 8 1</d i f f u s e>

<specu lar >0.1 0 . 1 0 . 1 1</specu la r>

<attenuat ion>

<range>1000</range>

<constant >0.9</constant>

< l i n e a r >0.01</ l i n e a r>

<quadrat ic >0.001</ quadrat ic>

</attenuat ion>

<d i r e c t i on >�0.5 0 . 5 �1</d i r e c t i on>

</ l i gh t>

<model name=’heightmap ’>

<s t a t i c >1</s t a t i c>

46

< l i n k name=’ l ink ’>

<c o l l i s i o n name=’ c o l l i s i o n ’>

<geometry>

<heightmap>

<ur i>

f i l e : // media/mat e r i a l s / t ex tu r e s /Antarc t i ca . png</ur i>

<s i z e >200 200 10</ s i z e>

<pos>0 0 0</pos>

<texture>

<s i z e >10</s i z e>

<d i f f u s e> d e f a u l t </d i f f u s e>

<normal> d e f a u l t </normal>

</texture>

<blend>

<min height>0</min height>

<f a d e d i s t >0</ f ad e d i s t>

</blend>

</heightmap>

</geometry>

<max contacts>10</max contacts>

<su r face>

<contact>

<ode/>

</contact>

<bounce/>

< f r i c t i o n >

<t o r s i o na l>

<ode/>

</t o r s i o na l>

<ode/>

</ f r i c t i o n >

</sur face>

47

</ c o l l i s i o n >

<v i s u a l name=’ v i sua l abc ed f ’>

<geometry>

<heightmap>

0

<texture>

<d i f f u s e> f i l e : // media/mat e r i a l s / t ex tu r e s / d i r t d i f f u s e s p e c u l a r . png</d i f f u s e>

<normal> f i l e : // media/mat e r i a l s / t ex tu r e s / f l a t no rma l . png</normal>

<s i z e >1</s i z e>

</texture>

<ur i> f i l e : // media/mat e r i a l s / t ex tu r e s /Antarct i ca . png</ur i>

<s i z e >200 200 10</ s i z e>

<pos>0 0 0</pos>

<blend>

<min height>0</min height>

<f a d e d i s t >0</ f ad e d i s t>

</blend>

</heightmap>

</geometry>

</v i sua l>

< s e l f c o l l i d e >0</ s e l f c o l l i d e >

<kinematic>0</kinematic>

<grav i ty>1</grav i ty>

</l ink>

</model>

<grav i ty>0 0 �9.8</grav i ty>

<magne t i c f i e l d >6e�06 2 .3 e�05 �4.2e�05</magne t i c f i e l d>

<atmosphere type=’ ad iabat i c ’/>

<phys i c s name=’ d e f au l t phy s i c s ’ d e f au l t = ’0 ’ type=’ode ’>

<max step s i ze >0.001</max step s i ze>

<r e a l t im e f a c t o r >1</r e a l t im e f a c t o r>

<r e a l t ime upda t e r a t e >1000</ r e a l t ime upda t e r a t e>

48

</phys ics>

<scene>

<ambient>0.4 0 . 4 0 . 4 1</ambient>

<background>0.7 0 . 7 0 . 7 1</background>

<shadows>1</shadows>

</scene>

<s ph e r i c a l c o o r d i n a t e s>

<sur face mode l>EARTHWGS84</sur face mode l>

<l a t i t ude deg >0</l a t i t ude deg>

<l ong i tude deg>0</long i tude deg>

<e l eva t i on >0</e l eva t i on>

<heading deg>0</heading deg>

</s ph e r i c a l c o o r d i n a t e s>

<model name=’LUMA’>

< l i n k name=’LUMA’>

<pose frame=’’>0 0 0 0 �0 0</pose>



<pose frame=’ ’>�0.001184 �0.025471 0.026117 0 �0 0</pose>

<mass>103.612</mass>



<ixx >11.4805</ ixx>

<ixy>�0.00668309</ ixy>

<ixz >0.00744841</ ixz>

<iyy >10.1676</ iyy>

<iyz >�0.104247</ iyz>

12.927





<c o l l i s i o n name=’LUMA coll ision ’>

<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

49

<s ca l e >1 1 1</ s ca l e>

<ur i>model : //LUMA/meshes/LUMA.STL</ur i>

</mesh>

</geometry>


<su r face>

<contact>

<ode/>

</contact>

<bounce/>

< f r i c t i o n >

<t o r s i o na l>

<ode/>

</t o r s i o na l>

<ode/>


</sur face>


<v i s u a l name=’LUMA visual ’>

<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>

<ur i>model : //LUMA/meshes/LUMA.STL</ur i>

</mesh>

</geometry>

</v i sua l>




</l ink>

< l i n k name=’Prop 1 ’>

50

<pose frame= ’ ’>0.22476 �0.30474 0 .0075 1 .5708 �0 2.3562</ pose>



<pose frame=’’>2e�06 0.089539 0.036627 0 �0 0</pose>




<ixx >0.0047573</ ixx>

<ixy>�1.7726e�08</ixy>

<ixz >�6.1871e�08</ixz>

<iyy >0.0041277</ iyy>

<iyz >�0.0003648</ iyz>

0.0020475




<c o l l i s i o n name=’ P r op 1 c o l l i s i o n ’>

<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>

<ur i>model : //LUMA/meshes/Prop 1 .STL</ur i>

</mesh>

</geometry>


<su r face>

<contact>

<ode/>

</contact>

<bounce/>

< f r i c t i o n >

<t o r s i o na l>

<ode/>

</t o r s i o na l>

<ode/>

51


</sur face>


<v i s u a l name=’Prop 1 v i sua l ’>

<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>


</mesh>

</geometry>

</v i sua l>




</l ink>

< j o i n t name=’Prop 1 revo lute ’ type=’ revo lute ’>

<ch i ld>Prop 1</ch i ld>

<parent>LUMA</parent>

<axis>

<xyz>�0.707103 �0.707111 4e�06</xyz>

<l im i t>

<lower>0</lower>

<upper>0</upper>

<e f f o r t >0</e f f o r t>

<ve l o c i t y >0</ve l o c i t y>

</l im i t>

<dynamics>

<s p r i n g r e f e r e n c e >0</s p r i n g r e f e r e n c e>

<s p r i n g s t i f f n e s s >0</ s p r i n g s t i f f n e s s >

</dynamics>

<use parent model f rame>1</use parent model f rame>

52

</axis>

</j o i n t>


<pose frame=’ ’>�0.22476 �0.30474 0 .0075 1 .5708 �0 �2.3562</pose>



<pose frame=’’>2e�06 0.089539 0.036627 0 �0 0</pose>




<ixx >0.0047573</ ixx>

<ixy>�1.7736e�08</ixy>

<ixz >�6.1874e�08</ixz>

<iyy >0.0041277</ iyy>

<iyz >�0.0003648</ iyz>

0.0020475





<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>


</mesh>

</geometry>


<su r face>

<contact>

<ode/>

</contact>

<bounce/>

< f r i c t i o n >

<t o r s i o na l>

53

<ode/>

</t o r s i o na l>

<ode/>


</sur face>



<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>


</mesh>

</geometry>

</v i sua l>




</l ink>




<axis>

<xyz>0.707103 �0.707111 4e�06</xyz>

<l im i t>

<lower>0</lower>

<upper>0</upper>



</l im i t>

<dynamics>


54


</dynamics>


</axis>

</j o i n t>


<pose frame= ’ ’>0.27976 0.29974 0 .0075 1 .5708 �0 �2.3562</pose>



<pose frame=’’>2e�06 0.089539 0.036627 0 �0 0</pose>




<ixx >0.0047573</ ixx>

<ixy>�1.7728e�08</ixy>

<ixz >�6.1873e�08</ixz>

<iyy >0.0041277</ iyy>

<iyz >�0.0003648</ iyz>

0.0020475





<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>


</mesh>

</geometry>


<su r face>

<contact>

<ode/>

</contact>

55

<bounce/>

< f r i c t i o n >

<t o r s i o na l>

<ode/>

</t o r s i o na l>

<ode/>


</sur face>



<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>


</mesh>

</geometry>

</v i sua l>




</l ink>




<axis>

<xyz>0.707103 �0.707111 4e�06</xyz>

<l im i t>

<lower>0</lower>

<upper>0</upper>



56

</l im i t>

<dynamics>



</dynamics>


</axis>

</j o i n t>


<pose frame=’ ’>�0.27976 0.29974 0 .0075 1 .5708 �0 2.3562</ pose>



<pose frame=’’>2e�06 0.089539 0.036627 0 �0 0</pose>




<ixx >0.0047573</ ixx>

<ixy>�1.7726e�08</ixy>

<ixz >�6.1871e�08</ixz>

<iyy >0.0041277</ iyy>

<iyz >�0.0003648</ iyz>

0.0020475





<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>


</mesh>

</geometry>


<su r face>

57

<contact>

<ode/>

</contact>

<bounce/>

< f r i c t i o n >

<t o r s i o na l>

<ode/>

</t o r s i o na l>

<ode/>


</sur face>



<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>


</mesh>

</geometry>

</v i sua l>




</l ink>




<axis>

<xyz>0.707103 0.707111 �4e�06</xyz>

<l im i t>

<lower>0</lower>

58

<upper>0</upper>



</l im i t>

<dynamics>



</dynamics>


</axis>

</j o i n t>

< l i n k name=’Prop Central ’>

<pose frame=’’>0 0 0 �1.5708 �0 �1.5708</pose>



<pose frame=’ ’>�0.000219 �0.017111 �0.000273 0 �0 0</pose>

<mass>1.6836</mass>



<ixx >0.010898</ ixx>

<ixy >1.6368e�05</ixy>

<ixz >1.021e�06</ixz>

<iyy >0.0064443</ iyy>

<iyz >5.6826e�05</iyz>

0.010894




<c o l l i s i o n name=’ P r op Cen t r a l c o l l i s i o n ’>

<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>

<ur i>model : //LUMA/meshes/Prop Centra l . STL</ur i>

</mesh>

59

</geometry>


<su r face>

<contact>

<ode/>

</contact>

<bounce/>

< f r i c t i o n >

<t o r s i o na l>

<ode/>

</t o r s i o na l>

<ode/>


</sur face>


<v i s u a l name=’Prop Cent ra l v i sua l ’>

<pose frame=’’>0 0 0 0 �0 0</pose>

<geometry>

<mesh>

<s ca l e >1 1 1</ s ca l e>

<ur i>model : //LUMA/meshes/Prop Centra l . STL</ur i>

</mesh>

</geometry>

</v i sua l>




</l ink>

< j o i n t name=’Prop Cent ra l r evo lu te ’ type=’ revo lute ’>

<ch i ld>Prop Central</ch i ld>


<axis>

60

<xyz>4e�06 0 1</xyz>

<l im i t>

<lower>0</lower>

<upper>0</upper>



</l im i t>

<dynamics>



</dynamics>


</axis>

</j o i n t>

<pose frame=’ ’>�15.1012 17.2293 0 0 �0 0</pose>

</model>

<s t a t e world name=’ de fau l t ’>

<sim time>73 951000000</ sim time>

<r ea l t ime >14 547253430</ r ea l t ime>

<wal l t ime >1483445326 659143888</ wal l t ime>

14

<model name=’LUMA’>

<pose frame= ’ ’>45.8985 68.5224 7 .79678 �0.122979 �0.057472 �2.96719</pose>

<s ca l e >1 1 1</ s ca l e>

< l i n k name=’LUMA’>

<pose frame= ’ ’>45.8985 68.5224 7 .79678 �0.122979 �0.057472 �2.96719</pose>

<ve l o c i t y >5.14883 0.173078 �2.14711 0.448524 �1.16551 �2.1076</ ve l o c i t y>

<a c c e l e r a t i on >0.005058 �0.012318 �9.79132 �0.51707 �0.176837 �0.016979</ a c c e l e r a t i on>

<wrench>0.52409 �1.27629 �1014.5 0 �0 0</wrench>

</l ink>


<pose frame= ’ ’>45.6277 68.7809 7 .85445 1.61718 0.127559 �0.611566</pose>

61

<ve l o c i t y >5.93846 �0.157594 �1.79706 0.448525 �1.16548 �2.10756</ ve l o c i t y>

<a c c e l e r a t i on >�1.06049 �1.38767 �9.00989 �0.079627 0.982697 �0.255197</ a c c e l e r a t i on>

<wrench>�0.976422 �1.27767 �8.29567 0 �0 0</wrench>

</l ink>


<pose frame= ’ ’>46.0697 68.8587 7 .82863 1 .6985 �0.045996 0.953316</ pose>


<a c c e l e r a t i on >�0.45883 �1.0846 �9.64778 0.456898 �1.27655 0.254309</ a c c e l e r a t i on>

<wrench>�0.422459 �0.99862 �8.883 0 �0 0</wrench>

</l ink>


<pose frame= ’ ’>45.6735 68.1798 7 .78358 1 .6985 �0.045996 0.953316</ pose>


<a c c e l e r a t i on >0.261641 1.75236 �10.3973 0.456898 �1.27655 0.254309</ a c c e l e r a t i on>

<wrench>0.240901 1.61345 �9.57307 0 �0 0</wrench>

</l ink>


<pose frame= ’ ’>46.2236 68.2767 7 .75144 1.61718 0.127559 �0.611566</pose>


<a c c e l e r a t i on >0.497586 1 .9143 �11.0537 �0.079627 0.982697 �0.255197</ a c c e l e r a t i on>

<wrench>0.458143 1.76256 �10.1775 0 �0 0</wrench>

</l ink>

< l i n k name=’Prop Central ’>

<pose frame= ’ ’>45.8985 68.5224 7 .79678 �1.51289 �0.122775 1.7381</ pose>


<a c c e l e r a t i on >0.104388 0.104883 �9.83728 1.32295 0.412747 0.027835</ a c c e l e r a t i on>

<wrench>0.175747 0.176581 �16.5621 0 �0 0</wrench>

</l ink>

</model>

<model name=’heightmap ’>

<pose frame=’’>0 0 0 0 �0 0</pose>

<s ca l e >1 1 1</ s ca l e>

62

< l i n k name=’ l ink ’>

<pose frame=’’>0 0 0 0 �0 0</pose>

<ve l o c i t y >0 0 0 0 �0 0</ve l o c i t y>

<a c c e l e r a t i on >0 0 0 0 �0 0</ a c c e l e r a t i on>

<wrench>0 0 0 0 �0 0</wrench>

</l ink>

</model>

< l i g h t name=’sun ’>

<pose frame=’’>0 0 10 0 �0 0</pose>

</ l i gh t>

</s tate>

<gui f u l l s c r e e n =’0’>

<camera name=’user camera ’>

<pose frame= ’ ’>42.8397 70.9206 8 .38634 0 0.11082 �0.740254</pose>

<v i ew con t r o l l e r>orb i t</v i ew con t r o l l e r>

<pro j e c t i on type>per spec t i v e 

</camera>

</gui>

</world>

</sdf>

A.0.2 Codigo luma control node.cpp

#inc lude ” luma contro l . h”

i n t main ( i n t argc , char ⇤⇤ argv )

{

ro s : : i n i t ( argc , argv , ” luma contro l ” ) ;

LumaControl luma contro l ( 5 ) ;

s td : : vector<double> theta = {M PI/4 , �M PI/4 , �M PI/4 , M PI/4 , 0} ;

s td : : vector<double> dx = { 0 .2378 , 0 .2378 , �0.3667 , �0.3667 , 0} ;

s td : : vector<double> dy = {�0.2917 , 0 .2917 , �0.2128 , 0 .2128 , 0} ;

63

l uma contro l . c on f i gu r eThru s t e r s ( theta , dx , dy ) ;

ro s : : sp in ( ) ;

r e turn 0 ;

}

A.0.3 Codigo luma control.h

#inc lude ” ro s / ro s . h”

#inc lude ”RobotPS/GPControl . h”

#inc lude <gazebo msgs / LinkStates . h>

#inc lude <gazebo msgs /ApplyBodyWrench . h>

#inc lude <gazebo msgs /BodyRequest . h>

#inc lude <iostream>

#inc lude <vector>

#inc lude <t f / t f . h>

#inc lude <Eigen/Dense>

c l a s s LumaControl

{

pr i va t e :

ro s : : NodeHandle nodeHandle ;

ro s : : S e r v i c eC l i e n t c o n t r o l s r v c ;

ro s : : S e r v i c eC l i e n t c l e a r s r v c ;

ro s : : Subsc r ibe r c on t r o l sub ;

ro s : : Subsc r ibe r l i n k s t a t e s s u b ;

std : : vector<t f : : Pose> poses ;

s td : : vector<double> prop ang l e s ;

64

const i n t N PROPS;

Eigen : : MatrixXd mat decouple ;

bool bypa s s th ru s t e r s ;

pub l i c :

e x p l i c i t LumaControl ( i n t n props ) ;

˜LumaControl ( ) ;

/⇤⇤

⇤ Usual ang l e s are { pi /4 , 3⇤ pi /4 , p i /4 , 3⇤ pi /4}

⇤/

void con f i gu r eThru s t e r s ( const std : : vector<double> & angles , const std : : vector<double> & dx , const std : : vector<double> & dy ) ;

void Contro lCal lback ( const RobotPS : : GPControl : : ConstPtr & msg ) ;

void L inkStatesCa l lback ( const gazebo msgs : : L inkStates : : ConstPtr & msg ) ;

} ;

A.0.4 Codigo luma control.cpp

#inc lude ” luma contro l . h”

LumaControl : : LumaControl ( i n t n props ) : N PROPS( n props ) , bypa s s th ru s t e r s ( t rue )

{

con t r o l sub = nodeHandle . subsc r ibe<RobotPS : : GPControl>(”luma/MotionControl / Input ” , 1 , &LumaControl : : ControlCal lback , t h i s ) ;

l i n k s t a t e s s u b = nodeHandle . subsc r ibe<gazebo msgs : : L inkStates >(”/gazebo/ l i n k s t a t e s ” , 1 , &LumaControl : : L inkStatesCal lback , t h i s ) ;

c o n t r o l s r v c = nodeHandle . s e r v i c eC l i e n t<gazebo msgs : : ApplyBodyWrench>(”/gazebo/ apply body wrench ” ) ;

c l e a r s r v c = nodeHandle . s e r v i c eC l i e n t<gazebo msgs : : BodyRequest>(”/gazebo/ c lear body wrench ” ) ;

poses . r e s e r v e (N PROPS) ;

65

prop ang l e s . r e s e r v e (N PROPS) ;

mat decouple . r e s i z e (4 , N PROPS) ;

}

void LumaControl : : c on f i gu r eThru s t e r s ( const std : : vector<double> & angles , const std : : vector<double> & dx , const std : : vector<double> & dy)

{

prop ang l e s = ang l e s ;

double d i s tance , gamma ;

f o r ( i n t k = 0 ; k < N PROPS � 1 ; ++k)

{

gamma = std : : atan2 (dy [ k ] , dx [ k ] ) ;

d i s t ance = std : : s q r t ( dy [ k ]⇤ dy [ k ] + dx [ k ]⇤ dx [ k ] ) ;

mat decouple (0 , k ) = std : : cos ( ang l e s [ k ] ) ;

mat decouple (1 , k ) = std : : s i n ( ang l e s [ k ] ) ;

mat decouple (2 , k ) = 0 ;

mat decouple (3 , k ) = d i s t ance ⇤ std : : s i n ( ang l e s [ k ] � gamma) ;

}

mat decouple (0 , N PROPS � 1) = 0 ;




}

void LumaControl : : Contro lCal lback ( const RobotPS : : GPControl : : ConstPtr & msg)

{

Eigen : : VectorXd ForceAxes ( 4 ) ;

Eigen : : VectorXd ForceThruster (N PROPS) ;

t f : : Vector3 ForceThruster3Drot [N PROPS ] ;

// F i l l i n g ForceAxes

switch (msg�>modes [ 0 ] ) // X

66

{

case 3 : // Force

ForceAxes (0 ) = msg�>data [ 0 ] ;

break ;

d e f au l t : // Not Contro l l ed

ForceAxes (0 ) = 0 ;

break ;

}

switch (msg�>modes [ 1 ] ) // Y

{

case 3 : // Force


break ;



break ;

}

switch (msg�>modes [ 2 ] ) // Z

{

case 3 : // Force


break ;



break ;

}

switch (msg�>modes [ 3 ] ) // Yaw

{

case 3 : // Force

67


break ;

case 2 : // Pos i t i on

break ;



break ;

}

i f ( bypa s s th ru s t e r s )

{

gazebo msgs : : ApplyBodyWrench wrenchSrv ;

wrenchSrv . r eque s t . body name = ”LUMA LEVE: :LUMA” ;

gazebo msgs : : BodyRequest c l e a rS rv ;

c l e a rS rv . r eque s t . body name = ”LUMA LEVE: :LUMA” ;

wrenchSrv . r eque s t . durat ion = ros : : Duration (�1);

wrenchSrv . r eque s t . wrench . f o r c e . x = ForceAxes ( 0 ) ;

wrenchSrv . r eque s t . wrench . f o r c e . y = ForceAxes ( 1 ) ;

wrenchSrv . r eque s t . wrench . f o r c e . z = ForceAxes ( 2 ) ;

wrenchSrv . r eque s t . wrench . torque . z = ForceAxes ( 3 ) ;

i f ( ! c l e a r s r v c . c a l l ( c l e a rS rv ) )

std : : cout << ”Cal l to /gazebo/ c lear body wrench f a i l e d ” << std : : endl ;

i f ( ! c o n t r o l s r v c . c a l l ( wrenchSrv ) )

std : : cout << ”Cal l to /gazebo/ apply body wrench f a i l e d ” << std : : endl ;

}

e l s e

{

// Apply Decoupl ing Matrix ( ForceAxes to ForceThruster )

ForceThruster = mat decouple . co lPivHouseholderQr ( ) . s o l v e (10000⇤ForceAxes ) ;

// Rotate ForceThruster ( ForceThruster to ForceThruster3D )

68

t f : : Quaternion qx (0 , 1 , 0 , 0 ) ;

t f : : Quaternion prop ro t ;

f o r ( i n t k = 0 ; k < N PROPS; ++k)

{

prop ro t = poses [ k ] ⇤ qx ;

ForceThruster3Drot [ k ] = � prop ro t . getAxis ( ) ⇤ ForceThruster ( k ) ;

}

gazebo msgs : : ApplyBodyWrench wrenchSrv [ 5 ] ;

wrenchSrv [ 0 ] . r eque s t . body name = ”LUMA LEVE: : Prop 1 ” ;




wrenchSrv [ 4 ] . r eque s t . body name = ”LUMA LEVE: : Prop cent ra l ” ;

gazebo msgs : : BodyRequest c l e a rS rv [ 5 ] ;

c l e a rS rv [ 0 ] . r eque s t . body name = ”LUMA LEVE: : Prop 1 ” ;




c l e a rS rv [ 4 ] . r eque s t . body name = ”LUMA LEVE: : Prop cent ra l ” ;

f o r ( unsigned char i = 0 ; i < 5 ; i++)

{

wrenchSrv [ i ] . r eque s t . durat ion = ros : : Duration ( 5 ) ;

wrenchSrv [ i ] . r eque s t . wrench . f o r c e . x = ForceThruster3Drot [ i ] . getX ( ) ;

wrenchSrv [ i ] . r eque s t . wrench . f o r c e . y = ForceThruster3Drot [ i ] . getY ( ) ;

wrenchSrv [ i ] . r eque s t . wrench . f o r c e . z = ForceThruster3Drot [ i ] . getZ ( ) ;

i f ( ! c l e a r s r v c . c a l l ( c l e a rS rv [ i ] ) )

s td : : cout << ”Cal l to /gazebo/ c lear body wrench f a i l e d ” << std : : endl ;

69

i f ( ! c o n t r o l s r v c . c a l l ( wrenchSrv [ i ] ) )

s td : : cout << ”Cal l to /gazebo/ apply body wrench f a i l e d ” << std : : endl ;

}

}

}

void LumaControl : : L inkStatesCa l lback ( const gazebo msgs : : L inkStates : : ConstPtr & msg)

{

f o r ( i n t i = 0 ; i < msg�>pose . s i z e ( ) && i < N PROPS; i++)

{

t f : : Pose pose ;

t f : : poseMsgToTF(msg�>pose [ i ] , pose ) ;

// quate rn ions [ i ] = msg�>pose [ i ] . o r i e n t a t i o n . x ;

// quate rn ions [ i ] = msg�>pose [ i ] . o r i e n t a t i o n ;

}

}

70

Documents

SIMULADOR PARA O ROV LUMA UTILIZANDO GAZEBO Mariana …monografias.poli.ufrj.br/monografias/monopoli10020423.pdf · Obtendo sucesso ao ﬁnal do processo a simula¸c˜ao do ve´ıculo