MINISTÉRIO DA DEFESA

EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
SEÇAO DE ENGENHARIA DE COMPUTAÇÃO

RELATÓRIO DE ACOMPANHAMENTO DO TRABALHO DE

INICIAÇÃO CIENTÍFICA

AMON RHANIERY BRITO MACHADO

ANÁLISE E IMPLEMENTAÇÃO DE ALGORITMOS DE

IDENTIFICAÇÃO DE PONTOS DE ACESSO

ORIENTADOR: MAJ ANDERSON FERNANDES PEREIRA DOS

SANTOS

Rio de Janeiro
2017
Conteúdo

1 Introdução 6
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Objetivos e contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Revisão bibliográfica 8
2.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Protocolo MAVLink . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Software in the loop - SITL . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.4 DroneKit-Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Estrutura de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Resultados e discussões 19
3.1 Teste de comunicação sem hardware . . . . . . . . . . . . . . . . . . . . . 19
3.2 Teste de comunicação com hardware . . . . . . . . . . . . . . . . . . . . . 21
3.3 Simulação com QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Dificuldades encontradas 25

5 Conclusão 26

2
Lista de Figuras

1 Protocolo MAVLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Estrutura do protocolo MAVLink . . . . . . . . . . . . . . . . . . . . . . . 9
3 Exemplo de mensagem MAVLink . . . . . . . . . . . . . . . . . . . . . . . 10
4 Arquitetura SITL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5 Trajetória Rn do enésimo VANT . . . . . . . . . . . . . . . . . . . . . . . . 13
6 Raspberry Pi emulado versão gráfica . . . . . . . . . . . . . . . . . . . . . 13
7 Raspberry Pi emulado versão console . . . . . . . . . . . . . . . . . . . . . 14
8 Raspberry Pi 2 Modelo B . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9 Navio 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10 MAVProxy com visão da aeronave simulada . . . . . . . . . . . . . . . . . 20
11 APM Planner em conjunto com MAVProxy . . . . . . . . . . . . . . . . . 20
12 Terminal do MAVProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13 Raspberry Pi e Navio2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14 Instalação de firmware utilizando APMPlanner . . . . . . . . . . . . . . . . 22
15 Instalação completa do firmware no APMPlanner . . . . . . . . . . . . . . 23
16 Seleção de porta para conexão no APMPlanner . . . . . . . . . . . . . . . 23
17 Máquinas virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3
Lista de siglas
ADC Analogic to Digital Converter
API Application Programming Interface
BA Bundle Adjustment
CKA Checksum A
CKB Checksum B
ECS Estação de Controle em Solo
EEPROM Electrically Erasable Programmable Read-Only Memory
GPIO General Purpose Input/Output
GPS Global Positioning System
HDMI High Definition Multimedia Interface
HP Hewlett-Packard
IMU Inertial Measurement Unit
INS Inertial Navigation System
IP Internet Protocol
LTE Long Term Evolution
LTS Long Term Support
LGPL Licença Pública Geral Menor
PPM Pulse Position Modulation
PWM Pulse Width Modulation
SD Secure Digital Card
SITL Software in the Loop
SLAM Simultaneous localization and mapping
UART Universal Asychrounous Receiver Transmiter
UDP User Datagram Protocol
USB Universal Serial Bus
VANT Veículo Aéreo Não Tripulado
XML Extensible Markup Language

4
 Resumo

Veículos aéreos não tripulados tem sido o principal foco de estudo em algumas empresas
civis e militares, as quais buscam otimizar suas aeronaves no quesito computacional e
financeiro. O trabalho propõe a troca de informação entre três VANTs a fim de, em
trabalhos futuros, os localizar por trilateração.
A pesquisa se divide em duas partes: na escolha de hardwares de baixo custo compa-
tíveis com protocolo MAVLink; e na elaboração de um script responsável por comandar as
aeronaves através de rotas pré-definidas. No intuito de evitar que se danifique os hardwares
do experimento, pesquisou-se também simuladores. Priorizou-se elementos com funcio-
nalidade modo plane(VANT asa fixa) e que possuem código aberto. Além disso, foram
utilizados diferentes simuladores para uma diferente quantidade de aeronaves visando
maior compatibilidade do software.
Com o intuito de corroborar com a teoria apresentada, são propostos três testes.
Utilizando apenas uma aeronave, faz-se a constatação da comunicação entre VANT e
ECS através de simuladores. Além disso, propõe a montagem da parte física e verifica o
recebimento de mensagens MAVLink na ECS. Por fim, é atestado a troca de informação
entre três aeronaves simuladas.

5
1 Introdução

O desenvolvimento tecnológico em microprocessadores tem permitido a configuração

de um veículo aéreo não tripulado (VANT) autônomo o qual se sustenta em algoritmos
genéticos e sistema de inferência adaptativo neuro-fuzzy. Sua utilização se dá tanto nos
setores civis quanto militares, na medida em que através de hardwares menores e softwares
menos sofisticados, é possível realizar um sensoriamento remoto.

1.1 Motivação

O sensoriamento remoto em locais de difícil acesso, inclusive com fins de segurança, pode
ser solucionado através de VANTs. Por consequência, é uma área da engenharia na qual há
espaço para desenvolvimento otimizando estas aeronaves para suas respectivas finalidades.
DE CARVALHO RODRIGUES (2015) busca desenvolver um sistema robótico aéreo com
baixo custo e tamanho reduzido visando de trabalhar com simultaneous localization and
mapping (SLAM), bundle adjustment (BA) e navegação. DA SILVA et al. (2014) visa
desenvolver um hardware para um controle autônomo embarcado de um quadricóptero.
LEITE (2015) se compromete em solucionar o problema de controlar múltiplos VANTs
simultaneamente. MEIER et al. (2012) tem por objetivo realizar um voo controlado
baseado em visão computacional e detecção de obstáculos por visão computacional estéreo
simultaneamente em um sistema embarcado.

1.2 Objetivos e contribuições

O presente trabalho apresenta um estudo de comunicação entre um VANT e sua res-

pectiva estação de controle em solo através do protocolo MAVLink. Tem por objetivo a
construção de um script cuja responsabilidade é coletar informações, enquanto a aeronave
percorre um trajeto pré-definido, na medida em que propõe-se o seu posicionamento por
trilateração.
Desta forma, assiste-se com a construção de um VANT, desde a escolha dos hardwares
até os softwares empregados no manuseio do aparelho. Na ausência da parte física da ae-
ronave, colabora-se também com uma estrutura de programas e simuladores responsáveis
por emular testes com a parte lógica do problema. Por outro lado, contribui-se com uma
aplicação em python capaz de tornar o voo autônomo.

6
1.3 Estrutura da dissertação

Na revisão bibliográfica é feita uma análise do motivo de escolha dos sistemas utilizados
- protocolo, piloto automático e estação de controle em solo - assim como são apresentados
os hardwares compatíveis. Preferiu-se a programas que possuem código aberto a fim de
promover a pesquisa e o desenvolvimento pela comunidade científica.
Nos resultados e discussões são apresentados os testes de comunicação realizados no
Laboratório de Robótica do Instituto Militar de Engenharia assim como o desenvolvimento
do código responsável pelo trajeto e teste da localização do VANT por trilateração. E,
por fim, são relatadas as dificuldades encontradas no experimento.

7
2 Revisão bibliográfica

É apresentado um estudo da arquitetura de hardware (microcontrolador e piloto au-

tomático) e software utilizados no experimento (estações de controle em solo, máquinas
virtuais, assim como o mecanismo de comunicação entre a aeronave e o computador).

2.1 Software

Como mecanismo de comunicação entre o sistema embarcado e a estação de controle

em solo (ECS) será apresentado o protocolo MAVLink, e posteriormente, o processo de si-
mulação utilizando somente software. Consiste em testar algoritmos e planos de voo antes
de se colocar a aeronave no ar. Será aferida a comunicação entre o VANT e a ECS, assim
como entre três VANTs - necessário para testar o conceito de trilateração proposto. A
primeira será feita através da ECS MAVProxy emulando apenas uma aeronave, enquanto
o QEMU (Quick Emulator ) elaborará a segunda.

2.1.1 Protocolo MAVLink

MAVLink (Micro Air Vehicle Communication Protocol ) é um protocolo de código livre

utilizado na comunicação de veículos aéreos não tripulados com a estação de controle em
solo. Foi desenvolvido em 2009 através da licença LGPL (Licença Pública Geral Menor)
por Lorenz Meler (LEITE, 2015). É leve e otimizado, tornando-o ideal para aplicações
robóticas as quais possuam restrições de desempenho. Além disso, é capaz de ser execu-
tado em microcontroladores e utilizado tanto em voos reais quanto em simulações (DE
CARVALHO RODRIGUES, 2015). Também permite, através de um baixo custo com-
putacional, que mensagens possam trafegar utilizando UDP (User Datagram Protocol –
protocolo simples da camada de transporte) e UART (Universal Asychrounous Receiver
Transmiter ) (MEIER et al. 2011). UDP consiste no protocolo cuja transmissão de dados
ocorre com maior desempenho possível, sem checagem dos dados. Caso estejam corrom-
pidos, são descartados. UART tem a finalidade de possibilitar a transmissão e recepção
de dados na forma paralela.
A vantagem de se utilizar o protocolo MAVLink consiste em minimizar a complexidade
do sistema e aumentar a velocidade de transmissão. Por exemplo, a transmissão de
imagens da câmera para a memória principal via USB demora de 16 a 19 micro segundos
aproximadamente, enquanto utilizando MAVLink, 0.1 a 2 micro segundos são o suficiente

8
- como especificado em MEIER et al. (2012).

Figura 1: Protocolo MAVLink

Essas mensagens são responsáveis pelo controle do VANT e seu acompanhamento em

solo, transmitindo dados como posição e orientação. São responsáveis pelo roteamento
inter e intrassistemas (DE CARVALHO RODRIGUES, 2015). Por outro lado, são feitas
em pacotes e definidas em uma estrutura XML, facilitando a compatibilidade com as
mais diversas linguagens. Na figura abaixo tem-se a estrutura do protocolo. O tamanho
mínimo de um pacote MAVLink é 8 bytes, sem payload, e o máximo é de 263, full payload
(MARTY, 2013).
O MAVLink usa um pacote de sinal inicial para sincronizar o início da mensagem. A
partir daí, o tamanho do payload (LEN) é lido e depois dos n bytes o checksum (CKA
e CKB) é verificado. Checksum é um campo colocado a fim de garantir a integridade
da mensagem e o tipo de dado o qual esta sendo transferido. É recalculado na recepção
e comparado com o recebido. Havendo discrepância, a mensagem é descartada. Caso
contrário, espera-se pelo próximo sinal de início. O protocolo ainda utiliza uma sequência
numéria (SEQ) para cada pacote como forma de proteção a fim de monitorar a detecção
de perda de pacotes. Caso haja um número significante de perdas, o piloto pode comandar
o VANT a retornar.

Figura 2: Estrutura do protocolo MAVLink

Por fim, os campos SYS, COMP e MSG são responsáveis pela identificação do emissor,

9
remetente e da mensagem respectivamente. A identificação da mensagem é importante
pois existem dezoito tipos de mensagens além de noventa e uma pré definidas, responsáveis
pela arquitetura, configurações, comandos etc (MARTY, 2013). Portanto, está localizado
no primeiro campo da mensagem com o intuito de que os dados obtidos possam ser decodi-
ficados corretamente. Somente são processados os conteúdos MAVLink cujo identificador
destino único estiver endereçado.
Caso algumas dessas mensagens não cumpram o objetivo desejado, pode-se acrescen-
tar outras seguindo o padrão descrito na figura 3 através de um arquivo XML. As novas
definições devem ser realizadas no intervalo de 150-240 bytes, estando o restante já re-
servado para as pré-definidas (LEITE, 2015). A mais comum é o heartbeat (message ID
= 0) responsável por verificar a conexão entre a ECS e a aeronave. As demais mensa-
gens podem ser encontradas na documentação MAVLink presente no GitHub (GITHUB,
2016).

Figura 3: Exemplo de mensagem MAVLink

O protocolo MAVLink possui definido diversas mensagens de comandos durante a

rota do aeromodelo, envidas com o padrão “MAVLin_mission_item_message”. A estação
de controle em solo, ArduPilot, possui suporte a tais mensagens, as quais abrangem os
modelos como Plane, Rover e Copter. O presente trabalho não envolve os dois últimos
citados, portanto, certos parâmetros não são relevantes. Além disso, por haver um número
limite no tamanho das mensagens, alguns comandos não são suportados.
Nas missões, caracteriza-se estas instruções. As de navegação (NAV) são responsáveis
por controlar o movimento da aeronave, desde a partida até o pouso. Comandos DO são
aqueles os quais controlarão as funções auxiliares, tais como configurar a câmera ou os
valores servo. E por fim, os de condição (CONDITION) são usados para atrasar as
funções auxiliares até algum pré-requisito ser atingido, por exemplo, até o aeromodelo

10
ter alcançado certa altitude. Contudo, apenas um comando NAV e DO ou CONDITION
podem ser executados ao mesmo tempo, sendo que estes devem ser executados antes do
NAV (ARDUPLANE, 2016).
A fim de se executar as instruções de navegação, é necessário a definição de um sistema
de referência para a localização do VANT. Este pode ser o sistema de coordendas WGS84,
no qual define a latitude-longitude como as coordendas globais e a altitude relativa ao nível
do mar; ou a altitude pode ser definida a partir do ponto ajustado como home position.
O tipo Plane também pode definir a altitude a partir da altura do solo (ARDUPLANE,
2016).

2.1.2 Software in the loop - SITL

Figura 4: Arquitetura SITL

Na execução do projeto, será utilizado o software ArduPilot, APMPlane, como piloto

automático e APMPlanner como a estação de controle em solo, sendo o protocolo MA-
VLink responsável por sua comunicação. Foram escolhidos devido a funcionalidade no
modo Plane com suporte a centenas de pontos de acesso, decolagem e pouso automático,
assim como por ser compatível com os mais diversos sistemas operacionais e ser suportado
pelo Raspberry Pi e Navio2, hardwares utilizados nos experimentos.

11
 Para simulação e testes é preciso implementar uma arquitetura de Software In The
Loop (SITL), capaz de executar o projeto sem hardware, um benefício visto que não
há necessidade de realizar um vôo apenas para verificar as comunicações. Consiste em
um executável de um compilador de C++. Compõe-se de um simulador MAVProxy em
python e no FlightGear, responsável por exibir a simulação.
MAVProxy é um aplicativo baseado em console de linhas de comando, cujo objetivo
consiste em servir como estação de controle em solo bem simples a qual suporta o protocolo
MAVLink. Compatível com os sistemas operacionais mais comuns, é também capaz de
ter uma interface gráfica básica através de certos plugins, além de permitir conexão com
outros computadores. FlightGear é um software de código aberto que conta com um
banco de dados online, além de um modelo de céu preciso e detalhado. As dinâmicas de
voo serão gerenciadas pelo JSBSim, conforme a figura 4.

2.1.3 QEMU

Um método de localização da aeronave consiste na trilateração, o cálculo baseado na po-

sição de outros pontos conhecidos e a distância relativa entre eles. Pode ser utilizado para
operar em ambientes estruturados com balizadores ativos e também visão computacional
(BÓ, 2007). No presente trabalho, estes pontos serão outros VANTs.
Para que haja sucesso na execução da trilateração, os dados recebidos tem de estar
sincronizados em data e hora a fim de que os cálculos sejam precisos. Para tanto, é
proposto um teste no qual o sistema de cada aeronave salve data, hora e localização
(baseado em uma access point) em um arquivo. A figura 5 demonstra um exemplo de
trajetos-testes de três aeronaves. Ri é o trajeto percorrido pelo i-ésimo VANT a fim de
verificar a troca de informações no sistema.
A fim de testar estes trajetos, é necessária a utilização de um simulador capaz de
emular um sistema baseado em processadores ARM (Advanced RISC [reduced instruction
set computing] Machines). Para tanto, propõe-se o QEMU. As figuras 6 e 7 demonstram
um Raspberry Pi com sistema operacional Raspbian emulado - versões gráficas e de console
respectivamente.

12
 Figura 5: Trajetória Rn do enésimo VANT

Figura 6: Raspberry Pi emulado versão gráfica

2.1.4 DroneKit-Python

Além dos softwares apresentado nesta seção, utiliza-se o DroneKit-Python, responsável

por auxiliar na confecção de aplicativos os quais serão executados no Raspberry Pi. Os
códigos são apresentados nessa seção. Têm por funções obter dados telemétricos dos
VANTs, assim como os guiar através das rotas presentes na figura 5.
A API é compatível com veículos os quais se comunicam através de protocolos MA-

13
 Figura 7: Raspberry Pi emulado versão console

VLink. Contudo, há de ressaltar que o protocolo não é sem perdas. Comandos podem não
chegar ao destino. Por outro lado, podem ser ignorados silenciosamente caso não estejam
aptos a serem executados (DRONEKIT, 2017). Medidas responsáveis por prevenir estes
casos são adotadas durante o código, tais como uso de clear e vehicle.is_armable.

Código 1: rota1.py
from d r o n e k i t import c o n n e c t , VehicleMode , Command , L o c a t i o n G l o b a l ,
LocationGlobalRelative
import time
from pymavlink import m a v u t i l
v e h i c l e = c o n n e c t ( ’ 1 2 7 . 0 . 0 . 1 : 1 4 5 5 0 ’ , wait_ready=True )

except s o c k e t . e r r o r :
print ’ S e r v i d o r nã o e x i s t e ! ’
except e x c e p t i o n s . OSError a s e :
print ’ S e r i a l nã o e x i s t e ! ’
except d r o n e k i t . APIException :
print ’ Tempo e s g o t a d o ! ’
except :
print ’ Erro ! ’

14
cmds=v e h i c l e . commands
print ( " L i b e r a n d o comandos e x i s t e n t e s . " )
cmds . c l e a r ( )

print ( " Decolagem : " )

cmds . add (Command( 0 , 0 , 0 , m a v u t i l . mavlink .MAV_FRAME_GLOBAL_RELATIVE_ALT, m a v u t i l
. mavlink .MAV_CMD_NAV_TAKEOFF, 0 , 0 , 1 3 , 0 , 0 , 0 , 0 , 0 , 4 0 ) )
cmds . add (Command( 0 , 0 , 0 , m a v u t i l . mavlink .MAV_FRAME_GLOBAL_RELATIVE_ALT, m a v u t i l
. mavlink .MAV_CMD_NAV_WAYPOINT, 0 , 0 , 0 , 1 , 0 , 0 , −22.955117 , −43.166530 , 1 1 ) )
cmds . add (Command( 0 , 0 , 0 , m a v u t i l . mavlink .MAV_FRAME_GLOBAL_RELATIVE_ALT, m a v u t i l
. mavlink .MAV_CMD_NAV_WAYPOINT, 0 , 0 , 0 , 1 , 0 , 0 , −22.954944 , −43.166443 , 1 1 ) )
cmds . add (Command( 0 , 0 , 0 , m a v u t i l . mavlink .MAV_FRAME_GLOBAL_RELATIVE_ALT, m a v u t i l
. mavlink .MAV_CMD_NAV_WAYPOINT, 0 , 0 , 0 , 1 , 0 , 0 , −22.954771 , −43.166356 , 1 1 ) )
cmds . add (Command( 0 , 0 , 0 , m a v u t i l . mavlink .MAV_FRAME_GLOBAL_RELATIVE_ALT, m a v u t i l
. mavlink .MAV_CMD_NAV_WAYPOINT, 0 , 0 , 0 , 1 , 0 , 0 , −22.954598 , −43.166269 , 1 1 ) )

cmds . u pl oa d ( )
cmds . wait_ready ( )

while not v e h i c l e . i s _ a r m a b l e :
print ( " Aguardando i n i c i a l i z a ç ã o do ve í c u l o . " )
time . s l e e p ( 1 )

print ( "Armando m ot or es . " )

v e h i c l e . armed = True

while not v e h i c l e . armed :

print ( " Aguardando armar o motor . " )
time . s l e e p ( 1 )

cmds . download ( )
cmds . wait_ready ( )
print ( " L o c a l i z a ç ã o do ponto i n i c i a l {} " . format ( v e h i c l e . home_location ) )

v e h i c l e . mode = VehicleMode ( "AUTO" )

v e h i c l e . commands . next=0

while True :
print ( " A l t i t u d e : {} " . format ( v e h i c l e . l o c a t i o n . g l o b a l _ r e l a t i v e _ f r a m e . a l t ) )
i f v e h i c l e . l o c a t i o n . g l o b a l _ r e l a t i v e _ f r a m e . a l t >=40∗0.95: #T r i g g e r j u s t b e l o w
target alt .
print " A l t i t u d e a l c a n ç ada . "
break
time . s l e e p ( 1 )

while True :
n e x t w a y p o i n t=v e h i c l e . commands . next
#p r i n t ’ D i s t â n c i a para w a y p o i n t (%s ) : %s ’ % ( n e x t w a y p o i n t ,

15
 distance_to_current_waypoint () )
print ( " A l t i t u d e {} " . format ( v e h i c l e . l o c a t i o n . g l o b a l _ r e l a t i v e _ f r a m e ) )

i f n e x t w a y p o i n t ==4:
print " Sa in do da m i s s ã o quando a t i n g i d o ponto f i n a l . "
break ;
time . s l e e p ( 1 )

print ( ’ R e t o r n a r para l a n ç amento . ’ )

v e h i c l e . mode = VehicleMode ( "RTL" )

print ( " Sa in do da a p l i c a ç ã o . " )

vehicle . close ()

As mensagens MAVLink, como demonstradas no código acima, são as responsáveis

por definir comandos, parâmetros e telemetria da aeronave. Faz-se uso das bibliotecas
dronekit e pymavlink a fim de se criar um objeto do tipo vehicle e, então, acessar seus
waypoints (representados por cmds). A aeronave é acessada através de um endereço IP
e uma porta, parâmetros de connect. A chamada de connect pode originar uma exceção,
amparada pelo bloco try-catch. O modo de vôo é definido como AUTO na medida em
que temos waypoints pré-definidos a serem seguidos. O atributo next indica o número do
waypoint atualmente ativo, setado como 0 no código a fim de se iniciar no primeiro ponto.

2.2 Estrutura de Hardware

O protocolo MAVLink é responsável por integrar as informações do IMU (Intertial

Measurement Unit) e a estação de controle. Para isso, precisa-se dispor de uma estrutura
eletrônica a qual irá fornecer os dados necessários.
Para processar os dados da atividade, analisa-se o Raspberry Pi 2. No modelo B,
há um processador ARMv7 de 900Hz com 1 GB de memória RAM e SD de 8 GB. Além
disso possui saída para vídeo, áudio, câmera e monitor. Conta com VideoCore IV 3D
graphics core, 40 pinos de propósitos gerais (GPIO - General purpose input/output),
4 portas de barramento serial universal e 1 saída HDMI (High-Definition Multimedia
Interface). Contudo, já está disponível no mercado o modelo 3, cuja diferença consiste
em um processador ARMv8 de 1.2 GHz 64bits, Bluetooth 4.1 e Bluetooth Low Energy
(BLE), assim como Wireless LAN 802.11n (RASPBERRY PI, 2016).
Há um algoritmo cuja função é de analisar as informações recebidas dos sensores
de GPS e INS (inertial navigation system). Para o INS compatível com Raspberry Pi,

16
 Figura 8: Raspberry Pi 2 Modelo B

analisa-se o Navio2. Este opera em diferentes modos de voo, como manual, estável,
automático e “siga-me”, além de contar com transmissão e recepção assíncrona universal
(UART), circuito inter integrado (I2C) e conversor analógico para digital (ADC). Por
outro lado, tem dois IMUs, com acelerômetro, giroscópio e magnetômetro nos três eixos,
barômetro, GPS, modulação de largura de pulso (PWM – Pulse Width Modulation) e
modulação de posição de pulso (PPM – Pulse Position Modulation). Tem por vantagem
o fato de poder monitorar e executar comandos e scripts ainda em vôo. A telemetria é
transmitida através de Wi-Fi, LTE, Bluetooth ou qualquer outro modem. Além do que,
é compatível com diversas estações de controle e suporta MAVLink, mecanismo pelo qual
os dados serão transmitidos após sua previsão (EMLID, 2016).

Figura 9: Navio 2

17
 Por fim, acopla-se o Navio2 ao Raspberry juntamente com componentes importantes
tais como antenas para recepção do sinal GPS, rádios para telemetria do dispositivo e
baterias que alimentam toda a estrutura embarcada. A fim de controlar manualmente
o aeromodelo, é necessário também um rádio do tipo FlySky. Do hardware necessário
para funcionamento da aeronave em si, temos o motor Brushless e seu controlador de
velocidade. Este tipo de motor é vantajoso em relação aos demais pois possui maior
vida útil, maior torque, alta eficiência e menor peso (DA SILVA, 2014). O controlador de
velocidade (ESC – Eletronic Speed Control ) ajusta a velocidade de giro do motor variando
a frequência das correntes entre suas fases.

18
3 Resultados e discussões

Propõe-se testar o sistema apresentado neste trabalho. De início, estuda-se a troca de

mensagens simples entre o piloto automático e a estação de controle em solo usando o
protocolo MAVLink. Pode ser realizado dois tipos de teste. O primeiro consiste em fazer
a transmissão de dados com o hardware apresentado em um notebook - HP Pavilion Intel
i7 com 8GB de memória RAM e HD de 500GB cujo sistema operacional é o Linux Ubuntu
16.04 LTS - sendo o destino final a placa de Raspberry Pi. Contudo, é possível realizar a
comunicação utilizando apenas uma simulação no computador - SITL apresentado.
Obter dados de telemetria, juntamente com a data e a hora, é importante para ve-
rificar a simultaneidade das informações recebidas. Dado que, no presente trabalho, a
trilateração será aplicada através de três aeronaves as quais farão uso da troca de in-
formação, propõe-se outro teste: emular máquinas virtuais de Raspberry Pi através do
QEMU e realizar a troca de informação entre elas.

3.1 Teste de comunicação sem hardware

Será tratado inicialmente o SITL. No processo de instalação da estação de controle,

é preciso primeiro clonar o repositório git do ardupilot, e o iniciar. Os comandos desta
operação estão descritos em anexo.
Como a simulação será feita através de asas fixas, é necessário também a instalação
do JSBSim para dinâmica de vôo. Desta forma, é preciso instalar o Libtool, um script de
suporte de uma biblioteca genérica. Além disso, alguns pacotes também são necessários,
como “python-matplotlib”, “python-serial”, “python-wxgtk2.8”, “python-wxtools”, “python-
lxml”, “python-scipy”, “python-opencv”, “ccache”, “gawk”, “git”, “python-pip” e “python-
pexpect”. Sendo a simulação realizada através do FlightGear, este também deve ser
instalado.
Por outro lado, é preciso acrescentar alguns diretórios ao arquivo .bashrc no diretório
home do computador. Os diretórios também são descritos em anexo.
Terminados estes procedimentos, pode-se iniciar o SITL. Na pasta ArduPlane dentro
de ardupilot inicia-se a simulação, quando for executado pela primeira vez,limpando a
memória EEPROM. O próximo passo consiste em cancelar esta ação e executar o simula-
dor normalmente. Foi executado, então, uma missão teste a qual consiste em um loop ao
redor do local de vôo. Visualiza-se nas figuras abaixo a simulação executada utilizando o

19
Software in the Loop proposto.

Figura 10: MAVProxy com visão da aeronave simulada

Figura 11: APM Planner em conjunto com MAVProxy

Com o MAVProxy é possível se comunicar com a aeronave simulada através de pro-

tocolos MAVLink, basta que seja digitado códigos previamente definidos nesta ECS. Por
exemplo, para decolagem, foi definido modo automático, após isto, ao digitar mode gui-
ded recebe a mensagem de confirmação da mudança de modo de voo, podendo agora

20
 Figura 12: Terminal do MAVProxy

alterar a rota da aeronave. Desta forma, na figura 12, confirma-se a transmissão de dados
utilizando o protocolo.

3.2 Teste de comunicação com hardware

Em uma primeira configuração dos equipamentos, é necessário acoplar o Navio2 ao

Raspberry Pi, como mostra a figura 14. Para isso utiliza-se de espaçadores e parafusos.
Com a finalidade de testar o sistema, liga-se o Raspberry Pi a um adaptador de 5V e 1A a
fim de fornecer energia à placa de piloto automático, o qual possui três fontes de energia.
É importante ressaltar que uma fonte de energia fora da faixa de 4,8-5,3V poderá danificar
o aparato. Caso o módulo de energia falhe, o Navio se alimenta do servo rail. Ainda,
o Raspberry Pi necessita também de Wi-Fi dongle a fim de realizar a comunicação; foi
utilizado CanaKitT M .
Em seguida, é preciso instalar o firmware do piloto automático. Conecta-se o piloto
automático com o computador através do USB e, utiliza o APM Planner para o instalar
conforme mostra as figuras 15 e 16.
É utilizado, então, um rádio 3DR para a comunicação entre o piloto automático e o
computador a fim de se testar a transmissão das mensagens. No software APM Planner,
seleciona-se a porta utilizada e clica em conectar (figura 17). Importante ressaltar que o
piloto automático deve estar desconectado pelo MAVLink para instalação do firmware.

21
 Figura 13: Raspberry Pi e Navio2

Figura 14: Instalação de firmware utilizando APMPlanner

22
 Figura 15: Instalação completa do firmware no APMPlanner

Figura 16: Seleção de porta para conexão no APMPlanner

3.3 Simulação com QEMU

Testar algoritmos em tempo real não é viável uma vez que há o risco de danificar o
material. Desta forma, a fim de se concretizar a ideia inicial do trabalho de se traba-

23
lhar com três equipamentos, é necessário tratar primeiro com simulações. O QEMU é o
software responsável por criar uma máquina virtual na qual rodará o Raspbian, sistema
operacional embarcado no VANT.
Propõe-se uma tarefa simples de início a fim de verificar a viabilidade das simulações
- emular dois equipamentos e realizar uma simples troca de informação entre eles. Para
isso, foi desenvolvido códigos que permitem uma conexão UDP. Sendo um destinado ao
cliente, e outro, ao servidor.
Por outro lado, para que as máquinas possam se comunicar, é primordial a existência
de uma rede. Em razão do sistema ser virtual, não há placa de rede física, sendo, portanto,
necessário sua simulação. Contudo, ao utilizar adaptadores TAP, a rede não foi capaz de
realizar o ping do IP das máquinas. Acredita-se que o problema venha da composição do
QEMU em si.
Como solução, será prosseguido o teste utilizando máquinas virtuais com o sistema
operacional Ubuntu. Na figura 17, comprova-se uma simples troca de mensagem "Hello
World"entre as máquinas virtuais. Os códigos foram desenvolvidos em python - estão em
anexo - utilizando socket (Python Wiki, 2017).

Figura 17: Máquinas virtuais

24
4 Dificuldades encontradas

Não foi possível realizar o experimento de comunicação com o hardware do VANT e a

ECS na medida em que os rádios 3DR do laboratório estão em uso em projetos paralelos.
Contudo, o teste pode ser feito apenas via software como exemplificado neste relatório.
Além disso, o teste proposto através do QEMU não foi realizado, na medida em que
o simulador utilizado para o trabalho não possui configurações de rede as quais suportam
o objetivo proposto. Contudo, lidou-se com máquinas virtuais linux para a troca de
informações.

25
5 Conclusão

A presente pesquisa é baseada em trabalhos cujo objetivo consta de projetar um VANT

capaz de se comunicar com uma estação de controle em solo de forma eficiente e acessível.
Está sendo feita em etapas. Atualmente, um estudo criterioso do protocolo MAVLink é
feito a fim de se entender os mecanismos necessários para a criação de uma interface na
ECS. Foi apresentado, portanto, as especificações de um protocolo MAVLink assim como
as motivações que levaram às escolhas da arquitetura de hardware e software.
Ao apresentar o protocolo MAVLink - responsável por transmitir os comandos e da-
dos de telemetria - foi estudado a estrutura da mensagem e sua compatibilidade com
diversas linguagens de programação, assim como, a verificação de conteúdos corrompi-
dos. A escolha do MAVLink visou as suas noventa e uma mensagens predefinidas assim
como a capacidade de acrescentar comandos os quais atendam ao trabalho. As instruções
foram separadas entre as de navegação, condição e execução a fim de melhor controle.
Importante notar que o fato do projeto ArduPilot, em conjunto com o protocolo, possuir
compatibilidade com outras aeronaves do tipo Rover e Copter auxiliou na definição de
novos comandos.
O suporte à aeronave contou com duas estações de controle em solo, piloto auto-
mático, simulador de voo e um utilitário para calcular as dinâmicas de voo. Procurou-se
utilizar programas de código aberto visando o contínuo desenvolvimento destes aplicativos
pela comunidade científica. Por outro lado, são compatíveis com o sistema operacional
escolhido e são suportados pela placa de Raspberry Pi e Navio, hardwares de peso leve e
baixo custo computacional.
Testar o algoritmo proposto em voos reais é dispendioso na medida em que a estru-
tura pode ser danificada impedindo assim o prosseguimento do trabalho, além de toda
a logística e burocracia necessária. Tendo em vista estes fatores, foi apresentado meios
de se testar através de simulações utilizando apenas software. Neste quesito, o papel do
MAVProxy foi de suma importância servindo de suporte ao piloto automático simulado,
assim como o QEMU para dar suporte à ideia de trilateração.
Por fim, foram propostos três testes a fim de obter dados de telemetria e constatar
a troca de mensagens MAVLink. Inicialmente seria realizado somente entre a placa do
piloto automático e a estação de controle em solo. Contudo, o laboratório do Instituto
Militar de Engenharia estava com outros projetos em andamento o que impossibilitou

26
o uso do rádio 3DR. Foi proposto, então, o teste de simulação utilizando o MAVProxy.
Neste, foi possível avaliar o recebimento das instruções MAVLink assim como testar um
plano de voo já pré-definido pelo piloto automático. Ainda em andamento, está a troca
de informações entre duas placas de Raspberry Pi emuladas através do QEMU.

27
Referências

[1] RASPBERRY PI. Disponível em <http://raspberrrypi.org>. Acessado em 22 de Se-

tembro de 2016.

[2] EMLID. Disponível em <http://emlid.com>. Acessado em 22 de Setembro de 2016.

[3] ARDUPLANE. ArduPilot. Disponível em <http://ardupilot.org/plane/>. Acessado

em 22 de Setembro de 2016.

[4] MEIER, Lorenz. TANSKANEN, Petri. FRAUNDORFER, Friedrich. POLLEFEYS,

Marc. PIXHAWK: A system for Autonomous Flight using Onboard Computer Vision.
IEEE International Conference on Robotics and Automation. (2011)

[5] MARTY, Joseph A. Vulnerability Analysis of the MAVLink Protocol for Command
and Control of Unmanned Aircraft. Air Force Institute of technology Wright-Patterson
AFB OH Graduate School of Engineering and Management. (2013).

[6] DA SILVA, Kleber Lima. MORAIS, Aniel Silva. Hardware para controle avançado de
veículo aéreo não tripulado do tipo quadricóptero. (2014)

[7] FLIGHTGEAR. Disponível em <http://www.br.flightgear.org/>. Acessado em 12 de

Outubro de 2016.

[8] GITHUB, MAVLink. Disponível em <mavlink/mes-

sage_definitions/v1.0/common.xml>. Acessado em 21 de Outubro de 2016.

[9] DE CARVALHO RODRIGUES, A. C. Fusão de sensores para um VANT via suaviza-

ção incremental baseada em grafos-fatores. 2015. 133 f. Dissertação (Mestrado em Siste-
mas e Computação) – Instituto Militar de Engenharia, Rio de Janeiro, 2015. Disponível
em: <http://www.comp.ime.eb.br/pos/arquivos/publicacoes/dissertacoes/2015/2015-
Anderson.pdf>. Acessado em 11 de Outubro de 2016.

[10] LEITE, Carlos Eduardo Tussi. Plataforma de controle para Múltiplos Veículos Aéreos
Não Tripulados (VANTs).(2015)

[11] MAVLINK. Documentação do protocolo MAVLink. Disponível em:

<http://qgroundcontrol.org/mavlink/start> Acessado em 17 de Novembro de
2015.

[12] MEIER, Lorenz. TANSKANEN, Petri. HENG, Lionel. LEE, Gim Hee. FRAUNDOR-
FER, Friedrich. POLLEFEYS, Marc. PIXHAWK: A micro aerial vehicle design for au-

28
 tonomous flight using onboard computer vision. In Auton Robot (2012) 33:21-39. doi:
10.1007/s10514-012-9281-4.

[13] BÓ, Antônio Padilha Lanari. Desenvolvimento de um sistema de localização 3D para

aplicação em robôs aéreos. 137 f. 2007. Dissertação (Mestrado em Engenharia Elétrica)-
Universidade de Brasília, Brasília, 2007.

[14] LAKHANI, Aamir. MUNIZ, Joseph. Penetration testing with Raspberry Pi. Packt
Publishing. Birmingham: 2015.

[15] DRONEKIT. Disponível em <http://python.dronekit.io/>. Acessado em 05 de maio

de 2017.

[16] PYTHON WIKI. Disponível em <https://wiki.python.org/. Acessado em 07 de junho

de 2017.

29
Anexos

Comando utilizados no terminal a fim de se instalar o SITL proposto na seção 3.1.

git clone git://github.com/ArduPilot/ardupilot.git

cd ardupilot

git submodule update –init –recursive

sudo apt-get install python-matplotlib python-serial python-wxgtk2.8 python-wxtools python-lxml

sudo apt-get install python-scipy python-opencv ccache gawk git python-pip python-pexpect

sudo pip install future pymavlink MAVProxy

export PATH=$PATH:$HOME/jsbsim/src
export PATH=$PATH:$HOME/ardupilot/Tools/autotest

export PATH=/usr/lib/ccache:$PATH

sim vehicle.py -w

sim vehicle.py –console –map –aircraft test

wp load ../Tools/autotest/ArduPlane-Missions/CMAC-toff-loop.txt
arm throttle

mode auto

Códigos utilizados em python para transmissão de mensagens.

Código 2: Enviando.py
import s o c k e t

UDP_IP=" 1 9 2 . 1 6 8 . 5 6 . 1 0 2 "
UDP_PORT=5005
MESSAGE= " H e l l o , World ! "

print "UDP t a r g e t IP : " , UDP_IP

print "UDP t a r g e t p o r t : " , UDP_PORT
print " message : " , MESSAGE

s o c k=s o c k e t . s o c k e t ( s o c k e t . AF_INET, s o c k e t .SOCK_DGRAM)

s o c k . s e n d t o (MESSAGE, (UDP_IP,UDP_PORT) )

Código 3: Recebendo.py
import s o c k e t

UDP_IP=" 1 9 2 . 1 6 8 . 5 6 . 1 0 2 "

30
UDP_PORT=5005

s o c k=s o c k e t . s o c k e t ( s o c k e t . AF_INET, s o c k e t .SOCK_DGRAM)

s o c k . bind ( (UDP_IP,UDP_PORT) )
while True :
data , addr=s o c k . r e c v f r o m ( 1 0 2 4 )
print " r e c e i v e d message : " , data

31