Post on 02-Aug-2020
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>
<u s e t e r r a i n pag i ng >0</u s e t e r r a i n pag i ng>
<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>
< i n e r t i a l >
<pose frame=’ ’>�0.001184 �0.025471 0.026117 0 �0 0</pose>
<mass>103.612</mass>
< i n e r t i a>
<ixx >11.4805</ ixx>
<ixy>�0.00668309</ ixy>
<ixz >0.00744841</ ixz>
<iyy >10.1676</ iyy>
<iyz >�0.104247</ iyz>
<i z z >12.927</ i zz>
</ i n e r t i a>
</ i n e r t i a l >
<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>
<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>
</ c o l l i s i o n >
<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>
< 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>
< l i n k name=’Prop 1 ’>
50
<pose frame= ’ ’>0.22476 �0.30474 0 .0075 1 .5708 �0 2.3562</ pose>
< i n e r t i a l >
<pose frame=’’>2e�06 0.089539 0.036627 0 �0 0</pose>
<mass>0.92073</mass>
< i n e r t i a>
<ixx >0.0047573</ ixx>
<ixy>�1.7726e�08</ixy>
<ixz >�6.1871e�08</ixz>
<iyy >0.0041277</ iyy>
<iyz >�0.0003648</ iyz>
<i z z >0.0020475</ i zz>
</ i n e r t i a>
</ i n e r t i a l >
<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>
<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/>
51
</ f r i c t i o n >
</sur face>
</ c o l l i s i o n >
<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>
<ur i>model : //LUMA/meshes/Prop 1 .STL</ur i>
</mesh>
</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>
< 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>
< l i n k name=’Prop 2 ’>
<pose frame=’ ’>�0.22476 �0.30474 0 .0075 1 .5708 �0 �2.3562</pose>
< i n e r t i a l >
<pose frame=’’>2e�06 0.089539 0.036627 0 �0 0</pose>
<mass>0.92073</mass>
< i n e r t i a>
<ixx >0.0047573</ ixx>
<ixy>�1.7736e�08</ixy>
<ixz >�6.1874e�08</ixz>
<iyy >0.0041277</ iyy>
<iyz >�0.0003648</ iyz>
<i z z >0.0020475</ i zz>
</ i n e r t i a>
</ i n e r t i a l >
<c o l l i s i o n name=’ P r op 2 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 2 .STL</ur i>
</mesh>
</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>
53
<ode/>
</t o r s i o na l>
<ode/>
</ f r i c t i o n >
</sur face>
</ c o l l i s i o n >
<v i s u a l name=’Prop 2 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 2 .STL</ur i>
</mesh>
</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>
< j o i n t name=’Prop 2 revo lute ’ type=’ revo lute ’>
<ch i ld>Prop 2</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>
54
<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>
</axis>
</j o i n t>
< l i n k name=’Prop 3 ’>
<pose frame= ’ ’>0.27976 0.29974 0 .0075 1 .5708 �0 �2.3562</pose>
< i n e r t i a l >
<pose frame=’’>2e�06 0.089539 0.036627 0 �0 0</pose>
<mass>0.92073</mass>
< i n e r t i a>
<ixx >0.0047573</ ixx>
<ixy>�1.7728e�08</ixy>
<ixz >�6.1873e�08</ixz>
<iyy >0.0041277</ iyy>
<iyz >�0.0003648</ iyz>
<i z z >0.0020475</ i zz>
</ i n e r t i a>
</ i n e r t i a l >
<c o l l i s i o n name=’ P r op 3 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 3 .STL</ur i>
</mesh>
</geometry>
<max contacts>10</max contacts>
<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/>
</ f r i c t i o n >
</sur face>
</ c o l l i s i o n >
<v i s u a l name=’Prop 3 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 3 .STL</ur i>
</mesh>
</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>
< j o i n t name=’Prop 3 revo lute ’ type=’ revo lute ’>
<ch i ld>Prop 3</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>
56
</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>
</axis>
</j o i n t>
< l i n k name=’Prop 4 ’>
<pose frame=’ ’>�0.27976 0.29974 0 .0075 1 .5708 �0 2.3562</ pose>
< i n e r t i a l >
<pose frame=’’>2e�06 0.089539 0.036627 0 �0 0</pose>
<mass>0.92073</mass>
< i n e r t i a>
<ixx >0.0047573</ ixx>
<ixy>�1.7726e�08</ixy>
<ixz >�6.1871e�08</ixz>
<iyy >0.0041277</ iyy>
<iyz >�0.0003648</ iyz>
<i z z >0.0020475</ i zz>
</ i n e r t i a>
</ i n e r t i a l >
<c o l l i s i o n name=’ P r op 4 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 4 .STL</ur i>
</mesh>
</geometry>
<max contacts>10</max contacts>
<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/>
</ f r i c t i o n >
</sur face>
</ c o l l i s i o n >
<v i s u a l name=’Prop 4 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 4 .STL</ur i>
</mesh>
</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>
< j o i n t name=’Prop 4 revo lute ’ type=’ revo lute ’>
<ch i ld>Prop 4</ch i ld>
<parent>LUMA</parent>
<axis>
<xyz>0.707103 0.707111 �4e�06</xyz>
<l im i t>
<lower>0</lower>
58
<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>
</axis>
</j o i n t>
< l i n k name=’Prop Central ’>
<pose frame=’’>0 0 0 �1.5708 �0 �1.5708</pose>
< i n e r t i a l >
<pose frame=’ ’>�0.000219 �0.017111 �0.000273 0 �0 0</pose>
<mass>1.6836</mass>
< i n e r t i a>
<ixx >0.010898</ ixx>
<ixy >1.6368e�05</ixy>
<ixz >1.021e�06</ixz>
<iyy >0.0064443</ iyy>
<iyz >5.6826e�05</iyz>
<i z z >0.010894</ i zz>
</ i n e r t i a>
</ i n e r t i a l >
<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>
<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>
</ c o l l i s i o n >
<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>
< 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>
< 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>
<parent>LUMA</parent>
<axis>
60
<xyz>4e�06 0 1</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>
</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>
< i t e r a t i o n s >14</ i t e r a t i o n s>
<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>
< l i n k name=’Prop 1 ’>
<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>
< l i n k name=’Prop 2 ’>
<pose frame= ’ ’>46.0697 68.8587 7 .82863 1 .6985 �0.045996 0.953316</ pose>
<ve l o c i t y >5.75481 0.060331 �1.95432 0.448515 �1.16555 �2.10757</ ve l o c i t y>
<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>
< l i n k name=’Prop 3 ’>
<pose frame= ’ ’>45.6735 68.1798 7 .78358 1 .6985 �0.045996 0.953316</ pose>
<ve l o c i t y >4.56017 0.245138 �2.31367 0.448515 �1.16555 �2.10757</ ve l o c i t y>
<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>
< l i n k name=’Prop 4 ’>
<pose frame= ’ ’>46.2236 68.2767 7 .75144 1.61718 0.127559 �0.611566</pose>
<ve l o c i t y >4.42072 0.253133 �2.3453 0.448525 �1.16548 �2.10756</ ve l o c i t y>
<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>
<ve l o c i t y >5.13602 0.204523 �2.16722 0.448565 �1.1655 �2.10754</ ve l o c i t y>
<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 </p ro j e c t i on type>
</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 ;
mat decouple (1 , N PROPS � 1) = 0 ;
mat decouple (2 , N PROPS � 1) = 1 ;
mat decouple (3 , 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
ForceAxes (1 ) = msg�>data [ 1 ] ;
break ;
d e f au l t : // Not Contro l l ed
ForceAxes (1 ) = 0 ;
break ;
}
switch (msg�>modes [ 2 ] ) // Z
{
case 3 : // Force
ForceAxes (2 ) = msg�>data [ 2 ] ;
break ;
d e f au l t : // Not Contro l l ed
ForceAxes (2 ) = 0 ;
break ;
}
switch (msg�>modes [ 3 ] ) // Yaw
{
case 3 : // Force
67
ForceAxes (3 ) = msg�>data [ 3 ] ;
break ;
case 2 : // Pos i t i on
break ;
d e f au l t : // Not Contro l l ed
ForceAxes (3 ) = 0 ;
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 [ 1 ] . r eque s t . body name = ”LUMA LEVE: : Prop 2 ” ;
wrenchSrv [ 2 ] . r eque s t . body name = ”LUMA LEVE: : Prop 3 ” ;
wrenchSrv [ 3 ] . r eque s t . body name = ”LUMA LEVE: : Prop 4 ” ;
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 [ 1 ] . r eque s t . body name = ”LUMA LEVE: : Prop 2 ” ;
c l e a rS rv [ 2 ] . r eque s t . body name = ”LUMA LEVE: : Prop 3 ” ;
c l e a rS rv [ 3 ] . r eque s t . body name = ”LUMA LEVE: : Prop 4 ” ;
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