School Work, android e ros">
TCC - Desenvolvimento Aplicativo para o ROS (Robotic Operating System)
TCC - Desenvolvimento Aplicativo para o ROS (Robotic Operating System)
TCC - Desenvolvimento Aplicativo para o ROS (Robotic Operating System)
Diamantina
2018
Caio Teixeira de Farias
Diamantina
2018
Scanned by CamScanner
Dedico aos meus pais, irmãos, amigos e mestres, que me deram base e suporte para concluir
esse trabalho.
AGRADECIMENTOS
Agradeço, primeiramente, a deus pela minha vida, a minha famı́lia que me propor-
cionou estrutura suficiente durante esses anos de graduação, para que chegasse ao objetivo final.
Ao meu orientador Rafael Santin pela dedicação, confiança e generosidade. A todos os profes-
sores, técnicos e funcionários da Universidade Federal dos Vales do Jequitinhonha e Mucuri,
que se dedicaram sempre em proporcionar o melhor ensino para nós estudantes. A cidade de
Diamantina e aos amigos que a que fiz, em especial aos da República Rabo de Vaca, que torna-
ram essa caminhada mais agradável e me ajudaram a concluir essa etapa importante na minha
vida.
Se valorizamos a nossa liberdade, podemos mantê-la e defendê-la. (Richard Stallman)
RESUMO
Na teleoperação de robôs móveis, um robô pode ser controlado remotamente para executar ta-
refas especı́ficas. A teleoperação é útil quando o ambiente operacional é perigoso, impraticável
ou economicamente inviável. Para operar à distância um robô móvel de maneira eficiente, é
importante que o sistema de teleoperação permita que o operador esteja ciente do ambiente de
navegação e possa dar instruções precisas ao robô. Técnicas de mapeamento, como o SLAM,
auxiliam veı́culos autônomos e sistemas de teleoperação a obter informações sobre o ambiente
de navegação do robô. Sistemas operacionais para robôs, fornecem abstração de hardware e
outras ferramentas que auxiliam no desenvolvimento de softwares para robótica. O presente
trabalho consiste no desenvolvimento de uma aplicação para dispositivos móveis, com Sistema
Operacional Android, para teleoperação e interação com a técnica SLAM em um Quadrotor
(simulado) utilizando o ROS (Robot Operating System). A principal motivação deste trabalho,
foi a expansão do uso de robôs em conjunto com smartphones, aproveitando a popularidade
desses dispositivos e seus recursos computacionais. Para o desenvolvimento da aplicação, foi
necessário o entendimento, principalmente, do framework ROS, da plataforma Android e da
linguagem de programação Java. Ao final deste trabalho, foi possı́vel obter uma ferramenta que
permite controlar remotamente um drone de maneira assistida, em ambientes conhecidos ou
desconhecidos, e obter um mapa do espaço de navegação.
Palavras-chave: Robótica Móvel. Dispositivos Móveis. Android. ROS (Robot Operating Sys-
tem). SLAM.
ABSTRACT
In mobile robot teleoperation, a robot can be controlled remotely to perform specific tasks. Te-
leoperation is useful when the operating environment is dangerous, impractical or economically
unfeasible. To remotely operate a mobile robot efficiently, it is important that the teleoperation
system allows the operator to be aware of the navigation environment and can give precise
instructions to the robot. Mapping techniques, such as SLAM, assist autonomous vehicles and
teleoperation systems to obtain information about the robot’s navigational environment. Robot
operating systems provide hardware abstraction and other tools that aid in the development of
software for robotics. The present work consists in the development of an application for mo-
bile devices, with Android Operating System, for teleoperation and interaction with the SLAM
technique in a Quadrotor (simulated) using ROS (Robot Operating System). The main moti-
vation of this work, was the expansion of the use of robots in conjunction with smartphones,
taking advantage of the popularity of these devices and their computational resources. For the
development of the application, it was necessary to understand, mainly, the framework, the An-
droid platform and the Java programming language. At the end of this work, it was possible to
obtain a tool that allows remote control of a drone in an assisted way in known or unknown
environments, and to obtain a navigation space map.
Keywords: Mobile Robotics. Mobile devices. Android. ROS (Robot Operating System). SLAM.
LISTA DE ILUSTRAÇÕES
Tabela 1 –
Métodos do ciclo de vida de uma Atividade Android . . . . . . . . . . . . . 33
Tabela 2 –
Ferramenta rosnode do ROS . . . . . . . . . . . . . . . . . . . . . . . . . 40
Tabela 3 –
Ferramenta rosmsg do ROS . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Tabela 4 –
Principais mensagens do ROS . . . . . . . . . . . . . . . . . . . . . . . . . 43
Tabela 5 –
Ferramenta rostopic do ROS . . . . . . . . . . . . . . . . . . . . . . . . 44
Tabela 6 Pacotes do hector quadrotor . . . . . . . . . . . . . . . . . . . . . . . .
– 59
Tabela 7 –
Pacotes do hector slam . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Tabela 8 –
Variáveis da classe JoyStickClass definidas para as posições da alavanca do
joystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Tabela 9 – Componentes da interfce do usuário . . . . . . . . . . . . . . . . . . . . . 67
LISTA DE ABREVIATURAS E SIGLAS
GB – Gigabytes
GHz – Gigahertz
IP – Internet Protocol
SO – Sistema Operacional
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.1.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.1.1.1 Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.2 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . 29
2.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.2 Elementos básicos de um projeto Android . . . . . . . . . . . . . . . . . 31
2.1.2.1 AndroidManifest.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.2.2 Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.2.3 Atividade (Activity) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.2.4 Arquivos XML de Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1.3 Sensor Acelerômetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1 Sistemas de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.2 Grafo de Computação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.2.1 Nós . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.2.2 Mestre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.2.3 Servidor de parâmetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.2.4 Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.2.5 Tópicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.2.6 Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.2.2.7 Bolsas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.2.2.8 Visualizando o grafo ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.2.3 Comunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2.4 Rosjava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.2.5 Outros conceitos ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.2.5.1 Catkin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.2.5.2 Variáveis de ambiente ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.5.3 roscore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.5.4 rosrun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.5.5 roslaunch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.5.6 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.2.5.7 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3 SLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.4 Robótica móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.1 Drones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4.1.1 Quadrotores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.5 Simulação robótica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.1 Trabalhos relacionados e proposta . . . . . . . . . . . . . . . . . . . . . 55
3.2 Ferramentas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.2 ROS Kinetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.3 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.4 Gazebo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.5 Linguagens de programação . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.5.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.5.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.6 android core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.7 Hector ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.8 Android Joystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.1 Classe MainActivity.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.2 Classe SystemCommands.java . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.3 Classe JoyStickClass.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.4 Classe NodeControle.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1 Executando o ROS/Gazebo no computador . . . . . . . . . . . . . . . . 68
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B CÓDIGO FONTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.1 Classe MainActivity.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.2 Classe NodeControle.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.3 Classe SystemCommands.java . . . . . . . . . . . . . . . . . . . . . . . . 98
27
1 INTRODUÇÃO
Robôs estão sendo usados para uma série de tarefas, incluindo as impraticáveis e
perigosas para o ser humano. No setor de mineração por exemplo, veı́culos aéreos não tri-
pulados (VANTs) com sensores infravermelhos e zoom telescópico podem sobrevoar minas e
ajudar a mostrar quando uma área de detonação foi totalmente evacuada de pessoas e equipa-
mentos (ALMEIDA, 2016). Ainda no âmbito da mineração, sistemas robóticos teleoperados,
onde robôs são controlados remotamente por um operador humano, são usados para não expor
o operador a um ambiente hostil de operação e para aumentar a produtividade, pois ao inserir
o operador virtualmente em um ambiente de trabalho, evita-se os deslocamentos aos locais de
operação (COTA et al., 2017). Na produção cinematográfica, os VANTs também estão revoluci-
onando o setor. Capturar imagens, antes impossı́veis fisicamente ou economicamente inviáveis,
são cada vez mais fáceis devido as caracterı́sticas desses veı́culos aéreos, que são pequenos, le-
ves e possuem um custo bem inferior em relação a outros meios de captação de imagens aéreas
(BARBOSA, 2016).
O mapeamento de áreas também é uma atividade relevante que vem sendo usada em
conjunto com sistemas robóticos. Robôs autônomos, utilizam-se de técnicas de mapeamento
através de sensores acoplados para se localizarem e navegarem em diversos tipos de ambien-
tes. Técnicas de mapeamento também vêm sendo utilizadas juntamente com robôs para obter
informações sobre ambientes desconhecidos, e ajudar, por exemplo, equipes em atividades de
busca e salvamento (SILVA; YEPES, 2016).
Objetivos
Objetivo geral
Objetivos especı́ficos
• Criar uma base de estudos para integração do sistema ROS com dispositivos Android.
Organização do trabalho
2 FUNDAMENTAÇÃO TEÓRICA
Android
Arquitetura
• Camada de abstração de hardware (HAL): Essa camada fornece interfaces para os re-
cursos de hardware, como câmera e sensores do dispositivo, para a estrutura da Java API.
Quando uma Framework API necessita de um desses recursos, ela faz uma chamada para
o sistema Android que carrega o módulo da biblioteca para o componente de hardware
especı́fico (DEVELOPER, 2018a).
1 Consórcio de grandes empresas de tecnologia como Google, Samsung, Sony, Qualcomm e HTC
2 Grupo de programas que trabalham em conjunto para produzir um resultado ou atingir um objetivo comum.
30
(DEVELOPER, 2018a).
• Java API Framework: Fornece as classes usadas para criar aplicativos Android. A Java
API Framework também fornece uma abstração genérica para acesso ao hardware e ge-
rencia a interface do usuário, bem como os recursos do aplicativo.
AndroidManifest.xml
Gradle
Atividade (Activity)
Cada tela de uma aplicação onde o usuário interage e executa alguma tarefa es-
pecı́fica é chamada de Activity. Um aplicativo pode conter várias atividades (Activities), onde
estão localizadas todos os componentes visuais e interativos do aplicativo, como botões, textos e
32
imagens. Os recursos fornecidos pelo Android para as Activities são acessados através da classe
Activity. Através dela, podemos exibir a interface do usuário, alocar memória para os objetos
dessa interface e criar um novo processo (POUDEL, 2013). Estendemos a classe Activity, ou
alguma de suas subclasses do pacote android.app, para criarmos as atividades. Essa classe
fornece todas as especificações caracterı́sticas de uma atividade.
Normalmente, uma atividade em um aplicativo é especificada como a atividade
principal, sendo essa a primeira tela a ser exibida quando o usuário inicia o aplicativo. Cada
atividade pode então iniciar outra atividade para realizar ações diferentes. Por exemplo, a ativi-
dade principal em um aplicativo simples de e-mail, pode fornecer a tela que mostra uma caixa de
entrada de e-mail. A partir daı́, a atividade principal pode iniciar outras atividades que fornecem
telas para tarefas como escrever e-mails e abrir e-mails individuais (DEVELOPER, 2018d).
Quando uma nova Activity é iniciada, a atividade anterior é interrompida e colocada
em uma “pilha de retorno” que segue o funcionamento básico de uma pilha (LIFO3 ). Esse
mecanismo permite que uma atividade possa ser preservada quando novas são executadas. Por
exemplo, quando o usuário inicia uma nova atividade ele pode, através do boltão voltar, retomar
a Activity anterior que foi colocada na pilha, fazendo com que a atividade atual seja então
destruı́da (DEVELOPER, 2018b). Para poder desenvolver uma aplicação Android é preciso
compreender os conceitos básicos desse ciclo de vida das atividades. A Figura 2 mostra um
diagrama dos métodos que controlam esse ciclo e a descrição de cada um deles é mostrada na
Tabela 1.
Figura 2 – Ciclo de vida de uma Atividade Android
3 Last In, First Out - O último que entra é o primeiro que sai
33
Método Descrição
onCreate ( ) Chamado quando a atividade é criada pela primeira vez. É onde se deve fazer
toda a configuração estática normal — criar exibições, vincular dados a listas,
etc. Sempre seguido de onStart();
onRestart () Chamado depois que atividade tiver sido interrompida, logo antes de ser reini-
ciada. Sempre seguido de onStart();
onStart () Chamado logo antes de a atividade se tornar visı́vel ao usuário. Seguido de
onResume() se a atividade for para segundo plano ou onStop() se ficar
oculta;
onResume ( ) Chamado logo antes de a atividade iniciar a interação com o usuário. Nesse
ponto, a atividade estará no topo da pilha de atividades com a entrada do
usuário direcionada a ela. Sempre seguido de onPause();
onPause ( ) Chamado quando o sistema está prestes a retomar outra atividade. Esse método
precisa salvar rapidamente dados não confirmados e interromper o trabalho
intensivo da CPU, para preparar a Atividade para perder o foco e ir para o
segundo plano. Seguido de onResume(), se a atividade retornar para a frente,
ou de onStop() se ficar invisı́vel ao usuário;
onStop ( ) Chamado quando a atividade não está mais visı́vel para o usuário. Isso pode
acontecer porque a atividade está sendo destruı́da, uma nova atividade está
sendo iniciada ou uma atividade existente está sendo retomada e cobrindo a
atividade interrompida. Em todos esses casos, a atividade interrompida não
é mais visı́vel. Seguido de onRestart(), se a atividade estiver voltando a
interagir com o usuário, ou onDestroy() se estiver saindo;
onDestroy ( ) Chamado antes de a atividade ser destruı́da. É a última chamada que a ativi-
dade receberá. Pode ser chamado porque a atividade está finalizando ou por-
que o sistema está destruindo temporariamente essa instância da atividade para
poupar espaço.
Fonte: Developer (2018b)
Sensor Acelerômetro
A maioria dos dispositivos com Android possui sensores integrados que medem
movimento, orientação e várias condições ambientais. Esses sensores são capazes de fornecer
dados brutos com alta precisão e são úteis quando deseja-se monitorar o movimento ou o posi-
cionamento tridimensional do dispositivo, ou ainda monitorar alterações no ambiente ambiente
próximo a um dispositivo. Um exemplo da utilização desses sensores, pode ser facilmente vista
34
ROS
Antes dos sistemas operacionais para robôs, era necessário que cada pesquisador
projetasse o software para incorporar ao seu robô, o que exigia habilidades em múltiplos cam-
pos do conhecimento, como engenharia mecânica, eletrônica e programação embutida (MAZ-
ZARI, 2016). Deste modo, grande parte do tempo dos projetos de robótica ficava a cargo do
desenvolvimento do software embutido nos robôs. A ideia principal dos sistemas operacionais
para robôs é fornecer aos projetistas e pesquisadores funcionalidades padronizadas, de forma
que os desenvolvedores não precisem “reinventar a roda” em seus projetos (NYRO, 2017).
O ROS é um metassistema operacional de código aberto para robôs que fornece
serviços que se espera de um sistema operacional convencional, como abstração de hardware,
controle de dispositivo de baixo nı́vel, implementação de funcionalidades, passagem de mensa-
gens entre processos e gerenciamento de pacotes. Ele também fornece ferramentas e bibliote-
cas para obter, criar, gravar e executar código em vários computadores (DOCUMENTATION,
2018).
O ROS foi originalmente desenvolvido em 2007, com o nome de Switchyard, pelo
Laboratório de Inteligência Artificial da Universidade de Stanford e posteriormente aperfeiçoado
no laboratório de pesquisa em robótica Willow Garage, com contribuições de todo o mundo.
Atualmente é executado em plataformas baseada no Unix, testado principalmente nos sistemas
Ubuntu e Mac OS X. A comunidade ROS tem contribuı́do com suporte para outras plataformas
Linux e uma versão para o Microsoft Windows também está atualmente em desenvolvimento,
mas ainda em fase experimental (DIFFOUO, 2013).
Uma distribuição ROS (WOODALL, 2018) é um conjunto versionado de pacotes
ROS. As distribuições são semelhantes as do Linux, e o objetivo é permitir que os desenvol-
vedores trabalhem em uma base de código relativamente estável até que estejam prontos para
36
avançar. Uma vez que uma distribuição é lançada, mudanças ocorrem com correções de bugs e
melhorias sem quebra para os pacotes principais. As Regras de liberação das distribuições são:
Sistemas de Arquivos
• Packages (pacotes): os pacotes são a unidade principal para organizar o software no ROS.
Um pacote pode conter processos executáveis (nós), uma biblioteca dependente do ROS,
conjuntos de dados, arquivos de configuração ou qualquer outra coisa que seja organizada
de maneira útil (ROMERO, 2014).
Estrutura de um pacote ROS (LAGES, 2017):
catkin ws
build
nome do pacote ...................................T EMPOR ÁRIOS
devel
lib ..............................................B IBLIOTECAS
src
nome do pacote
src .........................................C ÓDIGOS - FONTE
• Tipos de mensagem: são arquivos .msg que definem as estruturas de dados das mensa-
gens enviadas no ROS (THOMAS, 2017).
• Serviços: são arquivos .srv, localizados no subdiretório srv/ de um pacote, que descre-
vem os serviços no ROS (SAITO, 2017b).
Grafo de Computação
Nós
Comando Descrição
Mestre
O mestre ROS (ROS Master) fornece serviços de nomeação e registro para o restante
dos nós no sistema ROS. A função do mestre é permitir que os nós ROS individuais se localizem
entre si. Uma vez que esses nós se localizam, eles se comunicam peer-to-peer (WU, 2018).
O mestre ROS funciona de forma parecida com um servidor DNS. Quando qualquer
nó iniciar no sistema ROS, ele começará a procurar pelo ROS Master e registrará o nome do
nó nele (JOSEPH, 2017). O mestre possui todos os detalhes sobre todos os nós em execução
no ambiente do ROS. Ele trocará detalhes de um nó com outro para estabelecer uma conexão
entre eles. Depois de trocar as informações, a comunicação será iniciada entre os dois nós
ROS (MARTINEZ; FERNáNDEZ, 2013). O mestre também fornece o Servidor de parâmetros,
que será abordado posteriormente. O mestre é mais comumente executado usando o comando
roscore, que carrega o mestre ROS juntamente com outros componentes essenciais (JOSEPH,
2015).
5 Endereço de um recurso disponı́vel em uma rede
41
Figura 9 – Comunicação entre um nó publisher (a) e um subscriber (b) pelo ROS Master
Servidor de parâmetros
Além das mensagens, o ROS fornece outro mecanismo chamado parâmetros para
obter informações para os nós. A ideia é que um servidor de parâmetros centralizado rastreie
uma coleção de valores, permitindo que dados possam ser armazenados por chaves em um único
local (FERREIRA, 2015). Esse servidor, como dito na subseção 2.2.2.2, é fornecido pelo mestre
ROS. Os nós podem armazenar dados estáticos, como parâmetros de configuração, acessı́veis
pela rede ROS. Tipos de dados suportados incluem estrutura de dados e tipos primitivos co-
muns (MATHWORKS, 2018). Se o parâmetro de um nó tiver um escopo global, ele poderá ser
acessado por todos os outros nós em tempo de execução.
Mensagens
um processo passa para outro. As mensagens são estruturas de dados comuns, suportando tipos
primitivos de dados padrões (inteiro, ponto flutuante, booleano). Mensagens são armazenadas
em arquivos .msg que ficam em um subdiretório de um pacote. Nós podemos observar os deta-
lhes de uma mensagem com a ferramenta de linha de comando rosmsg. A Tabela 3 mostra as
descrições dos comandos suportados por essa ferramenta (SAITO, 2017a).
Comando Descrição
Tópicos
Um dos métodos para se comunicar e trocar mensagens ROS entre dois nós é cha-
mado de tópicos ROS. Cada tópico tem um nome exclusivo e qualquer nó pode acessar esse
tópico e enviar dados por meio dele, desde que tenham o tipo de mensagem correto (JOSEPH,
2017). Assim, os tópicos são fortemente tipados pelo tipo de mensagem ROS. Quando um nó
envia uma mensagem através de um tópico, dizemos que o nó está publicando (publishing) um
tópico. Quando um nó recebe uma mensagem através de um tópico, podemos dizer que o nó
está assinando ou se inscrevendo (subscribing) em um tópico.
Os nós ROS não estão interessados em saber qual nó está publicando ou assinando
o tópico, ele procura apenas o nome do tópico e se os tipos de mensagem estão correspondentes.
Os tópicos são destinados para comunicação unidirecional de fluxo contı́nuo, para implementar
chamadas de procedimento remoto como comunicação, é preciso usar os Serviços ROS (FO-
ROUHER, 2014).
Como os tópicos são unidirecionais e permanecem conectados para enviar ou rece-
ber mensagens continuamente, esta comunicação é adequada para a transmissão dos dados de
sensores, que exigem a publicação periódica de mensagens. Além disso, múltiplos os assinantes
44
podem receber mensagens de um publicador e vice-versa, o que facilita que um sensor possa
ser acessado ao mesmo tempo por diferentes nós (PYO et al., 2017).
Figura 11 – Comunicação de mensagens ROS por tópicos
Comando Descrição
Serviços
Semelhante às definições de mensagem usando o arquivo .msg, temos que definir
os serviços em outro arquivo chamado .srv, que deve ser mantido dentro do subdiretório /srv
do pacote (JOSEPH, 2015). Um servidor de serviço ROS, por exemplo um nó que informa a
hora atual (Figura 12), responde apenas quando há uma solicitação de um cliente de serviço.
Esse pode enviar solicitações, bem como receber respostas. O nó cliente deve esperar até que
o servidor responda com os resultados. Quando a solicitação e a resposta do serviço forem
concluı́das, a conexão entre os dois nós será encerrada. (PYO et al., 2017).
Como explicado anteriormente, chamadas de serviço são bidirecionais. Um nó envia
informações para outro nó e aguarda uma resposta. A informação flui em ambas as direções.
Ao contrário de uma mensagem, que é publicada e não há nenhum conceito de resposta e nem
garantia de que alguém esteja se inscrevendo nessas mensagens (O’KANE, 2014).
Como o serviço não mantém a conexão, ele é útil para reduzir a carga da rede em
comparação com os tópicos que mantêm a transmissão constantemente. Um serviço é frequen-
temente usado para comandar um robô para executar uma ação especı́fica ou nós para executar
determinados eventos com uma condição especı́fica (PYO et al., 2017).
Bolsas
Comunidade
Os conceitos do nı́vel da comunidade ROS são recursos ROS que permitem que
comunidades separadas troquem software e conhecimento. Esses recursos incluem (ROMERO,
2014):
• Distribuições: Distribuições ROS são coleções versionadas de pacotes ROS, como distribuições
Linux. As distribuições ROS facilitam a instalação de uma coleção de softwares e também
mantêm versões consistentes através de um conjunto de softwares(MARTINEZ; FERNáNDEZ,
2013).
• Repositórios: O ROS conta com uma rede de repositórios de código, onde diferentes
instituições podem desenvolver e liberar seus próprios componentes de software do robô
(ROMERO, 2014).
• Wiki ROS: Centro de conhecimento do ROS, no qual qualquer pessoa pode criar documentação
para seus pacotes. Pode-se encontrar documentação padrão e tutoriais sobre o ROS no
Wiki ROS (JOSEPH, 2017).
48
• Bug ticket system: Recurso utilizado para relatar erros encontrados no sistema ou adicio-
nar um novo recurso (JOSEPH, 2015).
• Lista de discussão: Principal canal de comunicação sobre novas atualizações para o ROS,
bem como um fórum para fazer perguntas sobre o software ROS (ROMERO, 2014).
• ROS Answers: Site onde os usuários podem fazer perguntas sobre ROS e áreas relacio-
nadas hhttps://answers.ros.org/i (ROMERO, 2014).
• Blog ROS: O blog do ROS fornece atualizações regulares sobre a comunidade ROS com
fotos e vı́deos hhttp://www.ros.org/newsi (JOSEPH, 2017).
Rosjava
Rosjava é uma implementação pura de Java para o ROS, criada e mantida pelo
Google e pela Willow Garage7 , inicialmente. Em vez de ter uma biblioteca cliente em Java
dando acesso ao núcleo do ROS, que é escrito em C++, o projeto Rosjava reescreveu totalmente
o núcleo do ROS em Java. O objetivo do Google é ter uma versão do ROS totalmente compatı́vel
com o Android (MAZZARI, 2016).
Essa interface entre o Android e o ROS possibilitou que dispositivos móveis pudes-
sem integrar a rede ROS com maior facilidade e suporte. Os dispositivos móveis atuais possuem
poderosos recursos de processamento e sensoriamento. Assim, foi possı́vel aproveitar esses re-
cursos na rede ROS para, por exemplo, processar dados recebidos de um robô e aproveitar os
sensores integrados dos smartphones ou tablets para executar funcionalidades como controle,
mapeamento e localização.
Outros conceitos do ROS também são pertinentes para trabalhar com o sistema,
sendo necessário pelo menos um entendimento básico deles. A seguir é dada a descrição de
alguns dos mais importantes.
Catkin
Existem muitas variáveis de ambiente que podem ser definidas para afetar o com-
portamento do ROS. Destas, as mais importantes são ROS MASTER URI, ROS ROOT, ROS IP e
ROS HOSTNAME (ROS, 2016).
• ROS MASTER URI - Essa variável de ambiente contém o IP e a porta do ROS Master.
Usando essa variável, os nós ROS podem localizar o mestre. Se esta variável estiver
errada, a comunicação entre os nós não ocorrerá.
• ROS ROOT - Define o local onde os pacotes principais do ROS estão instalados.
• ROS IP/ROS HOSTNAME - O ROS precisa saber o nome de cada máquina em que está sendo
executado. Isso é feito configurando a variável de ambiente ROS IP ou ROS HOSTNAME
de cada máquina com seu próprio endereço IP ou nome. As opções são mutuamente
exclusivas, se ambas forem configuradas, ROS HOSTNAME terá precedência.
roscore
rosrun
roslaunch
Names
Nós, parâmetros, tópicos e serviços, todos têm nomes. Esses nomes são registrados
no mestre e buscados para transferir mensagens ao usar os parâmetros, tópicos e serviços de
cada nó. Os nomes são flexı́veis porque podem ser alterados ao serem executados e diferentes
nomes podem ser atribuı́dos ao executar nós, parâmetros, tópicos e serviços idênticos várias ve-
zes. O uso de nomes torna o ROS adequado para projetos de grande escala e sistemas complexos
(PYO et al., 2017).
Namespaces
Um namespace pode ser visto como um diretório cujo conteúdo é um item de nome
diferente. Esses itens podem ser nós, tópicos ou até mesmo outros namespaces. Namespaces
podem ser organizados em hierarquias. Na Figura 15 por exemplo, existe o namespace raiz,
referido por uma barra “/”. O namespace raiz da Figura 15 inclui quatro itens. Três deles são nós
(draw square, turtlesim e turtlesim2), enquanto o quarto é o namespace turtle1. O namespace
turtle1 inclui dois itens que são os dois tópicos: command velocity e pose (NOOTRIX, 2018).
SLAM
Robótica móvel
Segundo Santos (2008), um robô é um sistema autônomo que pode ser capaz de
sentir seu ambiente e agir para atingir objetivos. Um robô móvel acrescenta o fato de que não
está confinado a um local especı́fico, pois tem a capacidade de se mover em seu ambiente.
A principal caracterı́stica que define um robô autônomo é a capacidade de agir com base em
52
suas próprias decisões, e não através do controle de um humano. No entanto, há ainda um
limite na complexidade das tarefas que os robôs podem executar de forma autônoma. Às vezes,
é vital que um ser humano seja capaz de controlar o robô de uma distância. Isto levou ao
desenvolvimento de robôs teleoperados, onde um operador humano emite comandos para o robô
enquanto tem acesso perceptivo ao espaço de trabalho. Algumas das áreas de aplicação mais
comuns de teleoperação são: exploração espacial, veı́culos submarinos, mineração, agricultura,
vigilância, resgate, cirurgia e entretenimento (GLOVER et al., 2009).
Drones
Quadrotores
Simulação robótica
Figura 17 – Quadrotor
possı́vel encontrar diversos softwares gratuitos para simulação robótica, dentre esses destacam-
se o V-Rep, MORSE, ARS e Gazebo, sendo o último utilizado no desenvolvimento da aplicação
desse trabalho e abordado de forma mais detalhada posteriormente.
Dentre diversas vantagens como redução de custo e riscos para integridade fı́sica
de desenvolvedores, os softwares de simulação de robôs garantem que possı́veis falhas não
sejam projetadas no sistema desenvolvido e que o sistema robótico funcione exatamente como
previsto. Uma vez que a simulação é concluı́da, o resultado final é apenas um carregamento do
sistema desenvolvido para a aplicação robótica real. Desta forma, o sistema real irá corresponder
exatamente à simulação.
3 METODOLOGIA
tipo de plataforma robótica, de forma que o controle de outros modelos de robôs, como no caso
dos Quadrotores, se torna inviável. Assim, a aplicação desse presente trabalho propõe compor
a visualização de sensores de robôs na interface de operação, também para um Quadrotor ROS.
Figueiredo (2016) propõe uma aplicação Android voltada para a teleoperação de
Quadrotores. A aplicação permite controlar esse modelo de robô remotamente e visualizar o
ambiente remoto na mesma interface. O aplicativo fornece ao usuário funcionalidades para o
controle completo do quadrotor e exibe na mesma interface a imagem da câmera acoplada
no robô. O aplicativo desenvolvido nesse presente trabalho, propõe utilizar a mesma ideia de
percepção do espaço de navegação através do sensor da câmera do robô, proposta por Figuei-
redo (2016), e aprimorar as funcionalidades de controle do drone. Através de dois controles
virtuais Joystick e do uso do sensor acelerômetro do smartphone, foi proposto uma operação
mais natural e intuitiva do robô, em relação ao uso de botões feito na aplicação desenvolvida por
Figueiredo (2016). Para fornecer mais informações espaciais ao operador, foi colocado também
uma opção de visualização, em tempo de execução, do mapa do ambiente de navegação do
drone, construı́do através do SLAM. Sendo possı́vel também, salvar esse mapa construı́do no
formato digital de imagens GeoTiff.
Ferramentas utilizadas
Hardware
• Motorola Moto G2 : processador Quad Core com 1.2GHz de velocidade, 1GB de memória
RAM, 8GB de memória interna e tela de 5 polegadas.
• Notebook Evolute SPX-65: processador Intel Core i5-2520M com 2,50GHz de veloci-
dade, 8GB de memória RAM e placa gráfica Intel HD Graphics 3000.
ROS Kinetic
O uso do ROS nesse trabalho se deu devido as vantagens já apresentadas na seção 2.2,
ao grande crescimento desse sistema nos últimos anos e o fato desse possuir uma licença de
código aberto que traz, entre outros benefı́cios, um alto e crescente número de colaboradores em
todo mundo. A utilização do ROS ainda proporciona um bom ambiente integrado de simulação
para desenvolvimento e torna fácil a transposição do ambiente simulado para o concreto, de
modo que o sistema desenvolvido nesse trabalho pode ser tanto utilizado no simulador quanto
57
no robô real. A distribuição do ROS usada no desenvolvimento da aplicação foi a Kinetic, uma
versão LTS que possui, assim, maior suporte aos principais pacotes ROS e vasta documentação
frente as outras versões.
Android Studio
Gazebo
Linguagens de programação
Java
Aplicações nativas Android podem ser escritas utilizando as linguagens C/C++, Ko-
tlin ou Java. A mais comumente usada é o Java. Java é uma popular linguagem de programação
orientada a objetos desenvolvida pela Sun Microsystems. Um dos principais objetivos dessa lin-
guagem é poder escrever programas que serão executados em uma grande variedade de sistemas
de computadores e dispositivos. Programas escritos em Java são convertidos para os chamados
Bytecodes que são executados pela JVM, a máquina virtual do Java. Os códigos de bytecodes
são independentes de plataforma, eles não dependem de uma plataforma de hardware especı́fica.
1 Ambiente de desenvolvimento integrado (IDE) Java para desenvolvimento de software.
58
Assim, os bytecodes do Java são portáveis, sem recompilar o código-fonte, os mesmos byteco-
des podem ser executados em qualquer plataforma que contenha uma JVM que entenda a versão
do Java na qual os bytecodes foram compilados (DEITEL; DEITEL, 2012).
Para poder desenvolver as aplicações Android em Java é necessário a instalação do
JDK (Kit de Desenvolvimento Java). O JDK inclui ferramentas úteis para desenvolver e testar
programas escritos na linguagem de programação Java e em execução na plataforma Java.
XML
android core
Hector ROS
Pacote Descrição
hector quadrotor description Fornece um modelo URDF2 de quadrotor genérico, bem como
variantes com vários sensores;
hector quadrotor gazebo Contém os arquivos de inicialização necessários e as
informações de dependência para simulação do modelo de
quadrotor no Gazebo;
hector quadrotor teleop Contém um nó que permite controlar o quadrotor usando um
gamepad;
hector quadrotor gazebo plugins Fornece plugins que são especı́ficos para a simulação de qua-
drotores no Gazebo.
hector quadrotor demo Fornece arquivos .launch e dependências necessárias para
demonstração do hector quadrotor no Gazebo.
Fonte: ROS (2014a)
Pacote Descrição
hector mapping Nó do SLAM;
hector geotiff Fornece um nó que pode ser usado para salvar mapas de grade
de ocupação, trajetória de robô e dados de objeto de interesse
para imagens no formato GeoTiff ;
hector trajectory server Controla as trajetórias extraı́das dos dados e torna esses dados
acessı́veis através de um serviço e tópico.
Fonte: ROS (2014b)
Android Joystick
do Joystick desejado para sua aplicação. A Figura 19 mostra a execução desse controle num dis-
positivo Android, onde o cı́rculo amarelo define o escopo do joystick e o vermelho a alavanca
desse. Todos os detalhes de como utilizar esse Joystick nas aplicações podem ser encontrados
no site do desenvolvedor 3 .
Implementação
Classe MainActivity.java
visualização do mapa sendo construı́do pelo SLAM, é necessário instanciar a classe Visualiza-
tionView. O objeto dessa classe recebe quatro camadas (Layer), necessárias para visualização e
manipulação do mapa na aplicação. São elas:
Variável Especificação
Classe SystemCommands.java
A classe SystemCommands é fornecida pelo pacote android core, e não foi alte-
rada. Ela define o nó responsável por executar as funções de limpar e salvar o mapa. O método
reset() dessa classe, é chamado no onClearMapButtonClicked() da classe MainActivity, através
do objeto systemCommands, para fazer o reset do mapa. O método saveGeotiff() é chamado den-
tro do onSaveMapButtonClicked(), também através do objeto systemCommands, para executar a
gravação do mapa construı́do pelo SLAM. Esses dois métodos, reset() e saveGeotiff(), definem
a mensagem publicada no tópico /syscommand, que recebe mensagens do tipo std msgs/String.
Sendo a string “reset” definindo a mensagem utilizada para limpar o mapa e a string “savegeo-
tiff ” a mensagem para gravar o mapa.
Classe JoyStickClass.java
4 http://www.akexorcist.com/2012/10/android-code-joystick-controller.html
63
Classe NodeControle.java
4 RESULTADOS
Fonte – Captura de Tela App “Teleoperação Quadrotor ROS” - Master Chooser Rosjava
66
Componente Funcionalidade
putador onde está sendo executado o ROS e o Gazebo. O mapa construı́do pelo SLAM na
aplicação é do tipo grade de ocupação. A ideia básica da grade de ocupação é representar um
mapa do ambiente como um conjunto de células, cada uma representando uma área ocupada
ou não no ambiente. A parte branca do mapa representa a área mapeada, sendo as linhas azuis
a parte ocupada no ambiente. O espaço cinza quadriculado, representa a área não mapeada e a
linha roxa mostra o trajeto feito pelo quadrotor durante a navegação.
Para que se estabeleça a conexão entre a aplicação executada no Android e o robô si-
mulado, devemos inicialmente configurar as variáveis de ambiente ROS IP e ROS MASTER URI.
A variável ROS IP deve ser configurada com o IP da máquina onde estão sendo executadas
os nós que desejamos nos conectar. A variável ROS MASTER URI deve ser configurada com o
endereço URI de onde será executado o ROS Master. Ambas configurações dessas variáveis po-
dem ser feitas no terminal do Linux com os comandos dados a seguir, sendo o IP 192.168.1.15
definido apenas como exemplo.
$ export ROS_IP =192.168.1.15
$ export ROS_MASTER_URI = http : // 19 2.1 68 .1 .15 :1 13 11/
que executa um arquivo .launch disponibilizado pelo pacote hector quadrotor demo. Nesse
arquivo estão as configurações do ambiente de simulação do Gazebo, do quadrotor, do SLAM
e de todos os nós necessários para a simulação do robô. O ambiente virtual ou o “mundo” do
Gazebo utilizado nessa aplicação é denominado willow garage. Nesse ambiente é simulado um
voo do Hector Quadrotor em um local interno (indoor), como uma casa. Executamos o arquivo
.launch do hector quadrotor demo para esse ambiente através do comando:
$ roslaunch hect or_q uadro tor_ demo indoor_slam_gazebo . launch
Na versão Kinetic do ROS, é necessário ainda ativar os motores do robô para iniciar
o voo. Essa ativação pode ser feita chamando um serviço ROS através do comando:
$ rosservice call \ enable_motors true
computador com o SO Ubuntu, passa informações a aplicação Android através de uma conexão
Wi-Fi. O fluxo de informações inverso é feito da mesma forma, de modo que o aplicativo desen-
volvido transmite informações ao computador onde está sendo executado o ROS e o Gazebo,
através da mesma conexão Wi-Fi.
71
5 CONCLUSÃO
Como conclusões, podemos dizer que objetivo principal foi cumprido, sendo possı́vel
criar a ferramenta proposta utilizando as tecnologias e conceitos apresentados no projeto. O es-
tudo da plataforma Android e do framework ROS possibilitou criar uma base de estudos para o
desenvolvimento de aplicações para dispositivos móveis voltadas para robótica. A apresentação
da técnica SLAM, viabilizou demonstrar uma solução para navegação de robôs em espaços
imprevisı́veis e o mapeamento desses tipos de ambientes.
74
Trabalhos futuros
REFERÊNCIAS
CARLSON, C.; CHEN, T.; CRUZ, J.; MAGHSOUDI, J.; ZHAO, H.; MONACO, J. V.
User Authentication with Android Accelerometer and Gyroscope Sensors. 2015. Dis-
ponı́vel em: hhttps://pdfs.semanticscholar.org/5b4c/ef41b056013c4ea20356a896ad9834ea3f2e.
pdfi. Acesso em: 17.06.2018.
COTA, E.; TORRE, M. P.; FERREIRA, J. A. T.; FIDêNCIO, A. X.; RODRIGUES, G. B.;
ROCHA, F. A. S.; AZPúRUA, H.; FREITAS, G. M.; MIOLA, W. ROBÓTICA NA
MINERAÇÃO. 2017. Disponı́vel em: hhttps://www.researchgate.net/publication/320725502
ROBOTICA NA MINERACAOi. Acesso em: 16.07.2018.
IRVS. how to configure rosjava apps with gradle. 2016. Disponı́vel em: hhttps://github.com/
irvs/ros tms/wiki/how-to-configure-rosjava-apps-with-gradlei.
JOSEPH, L. Mastering ROS for Robotics Programming. Birmingham: Packt Publishing,
2015.
JOSEPH, L. ROS Robotics Projects. Birmingham: Packt Publishing, 2017.
KOUBAA, A. (Ed.). Robot Operating System (ROS) - The Complete Reference (Volume
1). [S.l.]: Springer, 2016.
KRAJCI, I.; CUMMINGS, D. Android on x86: An Introduction to Optimizing for Intel
Architecture. [S.l.]: Apress, 2013.
LAGES, W. F. Robot Operating System (ROS) - Introdução e Implementação de Controla-
dores. 2017. Disponı́vel em: hhttp://www.ece.ufrgs.br/∼fetter/sbai2017-ros/intro.pdfi. Acesso
em: 30.05.2018.
MARTINEZ, A.; FERNáNDEZ, E. Learning ROS for Robotics Programming. [S.l.]: Packt
Publishing, 2013.
MATHWORKS. Access the ROS Parameter Server. 2018. Disponı́vel em: hhttps:
//www.mathworks.com/help/robotics/examples/access-the-ros-parameter-server.htmli. Acesso
em: 05.06.2018.
MAZZARI, V. ROS – Robot Operating System. 2016. Disponı́vel em: hhttps:
//www.generationrobots.com/blog/en/2016/03/ros-robot-operating-system-2/i. Acesso em:
27.05.2018.
NOOTRIX. ROS Naming and Namespaces. 2018. Disponı́vel em: hhttps://nootrix.com/
diy-tutos/ros-namespaces/i. Acesso em: 25.06.2018.
NYRO. How to learn robotics with ROS. 2017. Disponı́vel em: hhttps://niryo.com/2017/03/
09/learn-robotics-ros/i. Acesso em: 27.05.2018.
O’HORA, K. Lights, Camera, Quadrotors! 2017. Disponı́vel em: hhttp://amt-lab.org/blog/
2017/5/lights-camera-quadrotorsi. Acesso em: 22.06.2018.
O’KANE, J. M. A Gentle Introduction to ROS. 2014. Disponı́vel em: hhttps://www.cse.sc.
edu/∼jokane/agitr/agitr-letter.pdfi.
POUDEL, A. MOBILE APPLICATION DEVELOPMENT FOR ANDROID OPE-
RATING SYSTEM. 2013. Disponı́vel em: hhttps://www.theseus.fi/bitstream/handle/10024/
64719/Poudel Amrit.pdfi. Acesso em: 17.06.2018.
PYO, Y.; CHO, H.; JUNG, R.; LIM, T. ROS Robot Programming. [S.l.]: ROBOTIS Co.,Ltd.,
2017.
RIISGAARD, S.; BLAS, M. R. SLAM for Dummies: A Tutorial Approach to Si-
multaneous Localization and Mapping. 2005. Disponı́vel em: hhttps://ocw.mit.edu/
courses/aeronautics-and-astronautics/16-412j-cognitive-robotics-spring-2005/projects/
1aslam blas repo.pdfi. Acesso em: 19.06.2018.
ROBOTICS, C. HUSKY. 2018. Disponı́vel em: hhttps://www.clearpathrobotics.com/
husky-unmanned-ground-vehicle-robot/i. Acesso em: 23.06.2018.
78
ROS, W. hector slam. 2014. Disponı́vel em: hhttp://wiki.ros.org/hector slami. Acesso em:
24.06.2018.
STRATOM. rosjava, Android Studio and Windows. 2016. Disponı́vel em: hhttp://www.
stratom.com/blog/2016/02/23/rosjava-android-studio-and-windows/#codesyntax 2i.
Gradle
Por fim, é preciso editar o arquivo META-INF que contém informações do An-
droid. Isso é necessário para evitar erros durante o empacotamento do APK, pois o pacote an-
droid core contém arquivos com nomes duplicados que poderão gerar conflitos com arquivos
criados durante a compilação do projeto (STRATOM, 2016). O Código A.3 excluı́ esses arqui-
vos com nomes duplicados, que serão substituı́dos pelos pertencentes ao pacote android core,
e deve ser declarado no arquivo build.gradle (Module: app).
AndroidManifest
O pacote android core contém seu próprio ı́cone de aplicativo (STRATOM, 2016),
dessa forma o Android Studio acusará um erro de conflito após a sincronização do projeto. Para
corrigir esse erro, é necessário editar o arquivo AndroidManifest.xml, adicionando as linhas 3
e 6 do Código A.4, para que então, a ferramenta Rebuild Project do Android Studio possa ser
executada sem nenhum erro de conflito.
Classe MainActivity.java
98
99 NodeConfiguration nodeConfiguration = NodeConfiguration . newPublic (
InetAddressFactory . newNonLoopback () . getHostAddress () , getMasterUri ()
);
100
101 nodeMainExecutor . execute ( nodeControle , nodeConfiguration ) ;
102 nodeMainExecutor . execute ( rosImageView , nodeConfiguration ) ;
103
104 visualizationView . init ( nodeMainExecutor ) ;
105 cameraControlLayer . addListener ( new Came raCon trol Liste ner () {
106 @Override
107 public void onZoom ( float focusX , float focusY , float factor ) {
108 disableFollowMe () ;
109 }
110
111 @Override
112 public void onTranslate ( float distanceX , float distanceY ) {
113 disableFollowMe () ;
114 }
115
116 @Override
117 public void onRotate ( float focusX , float focusY , double deltaAngle )
{
118 disableFollowMe () ;
119 }
120
121 @Override
122 public void onDoubleTap ( float x , float y ) {
123 }
124 }) ;
125
126 nodeMainExecutor . execute ( visualizationView , nodeConfiguration ) ;
127 nodeMainExecutor . execute ( systemCommands , nodeConfiguration ) ;
128
129 }
130
131 public void on Cl e ar M ap Bu t to n Cl ic k ed ( View view ) {
132 toast (" Limpando mapa ...") ;
133 systemCommands . reset () ;
134 enableFollowMe () ;
135 }
136
137 public void o nS av eMa pB ut ton Cl ic ked ( View view ) {
138 toast (" Salvando mapa ...") ;
139 systemCommands . saveGeotiff () ;
140 }
141
142 private void toast ( final String text ) {
143 runOnUiThread ( new Runnable () {
144 @Override
145 public void run () {
146 Toast toast = Toast . makeText ( MainActivity . this , text , Toast .
LENGTH_SHORT ) ;
147 toast . show () ;
148 }
149 }) ;
150 }
88
151
152 public void o n F o l l o w M e T o g g l e B u t t o n C l i c k e d ( View view ) {
153 boolean on = (( ToggleButton ) view ) . isChecked () ;
154 if ( on ) {
155 enableFollowMe () ;
156 } else {
157 disableFollowMe () ;
158 }
159 }
160
161 private void enableFollowMe () {
162 Preconditions . checkNotNull ( visualizationView ) ;
163 Preconditions . checkNotNull ( followMeToggleButton ) ;
164 runOnUiThread ( new Runnable () {
165 @Override
166 public void run () {
167 visualizationView . getCamera () . jumpToFrame ( ROBOT_FRAME ) ;
168 followMeToggleButton . setChecked ( true ) ;
169 }
170 }) ;
171 }
172
173 private void disableFollowMe () {
174 Preconditions . checkNotNull ( visualizationView ) ;
175 Preconditions . checkNotNull ( followMeToggleButton ) ;
176 runOnUiThread ( new Runnable () {
177 @Override
178 public void run () {
179 visualizationView . getCamera () . setFrame ( MAP_FRAME ) ;
180 followMeToggleButton . setChecked ( false ) ;
181 }
182 }) ;
183 }
184
185 public void onMapButtonClicked ( View view ) {
186 boolean on = (( ToggleButton ) view ) . isChecked () ;
187 if ( on ) {
188 constraintMap . setVisibility ( View . VISIBLE ) ;
189 linearLayoutMap . setVisibility ( View . VISIBLE ) ;
190 } else {
191 constraintMap . setVisibility ( View . GONE ) ;
192 linearLayoutMap . setVisibility ( View . GONE ) ;
193 }
194 }
195
196 }
89
Classe NodeControle.java
109 @Override
110 public void onAccuracyChanged ( Sensor sensor , int accuracy ) {
111
112 }
113 };
114
115 js = new JoyStickClass ( activity . ge tAppl icat ionCo ntex t ()
116 , layout_joystick , R . drawable . image_button ) ;
117 js . setStickSize (65 , 65) ;
118 js . setLayoutSize (205 , 205) ;
119 js . setLayoutAlpha (35) ;
120 js . setStickAlpha (20) ;
121 js . setOffset (45) ;
122 js . setMinimumDistance (50) ;
123
124 js2 = new JoyStickClass ( activity . g etAp plica tion Conte xt ()
125 , layout_joystick2 , R . drawable . image_button ) ;
126 js2 . setStickSize (65 , 65) ;
127 js2 . setLayoutSize (205 , 205) ;
128 js2 . setLayoutAlpha (35) ;
129 js2 . setStickAlpha (20) ;
130 js2 . setOffset (45) ;
131 js2 . setMinimumDistance (50) ;
132
133 botaoAcelerometro . setChecked ( false ) ;
134 if (! botaoAcelerometro . isChecked () ) {
135 mSensorManager . unregisterListener ( sensorEventListener ,
mAccelerometer ) ;
136
137 layout_joystick . setOnTouchListener ( new View . OnTouchListener
() {
138 public boolean onTouch ( View arg0 , MotionEvent arg1 ) {
139 js . drawStick ( arg1 ) ;
140 if ( arg1 . getAction () == MotionEvent . ACTION_DOWN
141 || arg1 . getAction () == MotionEvent .
ACTION_MOVE ) {
142 int direction = js . get8Direction () ;
143 if ( direction == JoyStickClass . STICK_UP ) {
144 cmdVelCorrente . getLinear () . setZ (1.0) ;
145 cmdVelCorrente . getAngular () . setZ (0) ;
146 } else if ( direction == JoyStickClass .
STICK_UPRIGHT ) {
147 cmdVelCorrente . getLinear () . setZ (1.0) ;
148 cmdVelCorrente . getAngular () . setZ ( -1.0) ;
149 } else if ( direction == JoyStickClass .
STICK_RIGHT ) {
150 cmdVelCorrente . getAngular () . setZ ( -1.0) ;
151 cmdVelCorrente . getLinear () . setZ (0) ;
152 } else if ( direction == JoyStickClass .
STICK_DOWNRIGHT ) {
153 cmdVelCorrente . getLinear () . setZ ( -1.0) ;
154 cmdVelCorrente . getAngular () . setZ ( -1.0) ;
155 } else if ( direction == JoyStickClass . STICK_DOWN
) {
156 cmdVelCorrente . getLinear () . setZ ( -1.0) ;
157 cmdVelCorrente . getAngular () . setZ (0) ;
92
Classe SystemCommands.java