Hardware

Nesta sess˜ao s˜ao apresentados os componentes utilizados para montar o quadri- c´optero utilizado para efetuar os testes pr´aticos. Tamb´em ´e explicado o motivo da escolha de cada componente. Na tabela 3.1 encontra-se a lista dos componentes.

A escolha do frame (corpo de sustenta¸c˜ao do VANT) levou dois fatores em con- sidera¸c˜ao, seu peso e a finalidade para qual o quadric´optero seria usado. Optou-se por um frame de fibra de carbono pelo seu baixo peso e alta resistˆencia, e porque o modelo escolhido j´a possui um suporte para gimbal e trens de pouso altos para evitar que o gimbal encoste no ch˜ao. Os motores usados possuem uma rota¸c˜ao mais baixa por´em oferecem um torque maior, o que permite levantar mais peso. Os f´oruns especializados recomendam que os motores para quadric´opteros com gimbal possuam um KV menor que 1000. O KV indica o n´umero de rota¸c˜oes por Volt que o motor produz. O ESC (Eletronic Speed Controller) deve ser escolhido de acordo com o motor utilizado pois deve suportar a cor- rente m´axima exigida pelo motor. O ESC utilizado possui um circuito opto-acoplado para receber o sinal PWM gerado pela controladora. Nem todos os ESCs s˜ao opto-acoplados. Este recurso traz uma seguran¸ca a mais caso ocorra um defeito em um ESC uma vez que isola os circuitos de alimenta¸c˜ao dos motores da controladora, pois enquanto os motores trabalham com tens˜oes de at´e 16V a controladora trabalha com 5V. As h´elices devem respeitar o tamanho m´aximo especificado pelo fabricante dos motores. Cada fabricante divulga o empuxo que cada tamanho de h´elice fornece dado o tipo de bateria utilizado. A tabela da figura 3.1 foi utilizada como referˆencia para calcular o empuxo gerado. Fo- ram usadas h´elices de fibra de carbono pois, segundo coment´arios de pilotos nos f´oruns especializados, por serem mais r´ıgidas, transmitem menos vibra¸c˜ao para a cˆamera em compara¸c˜ao `as h´elices de pl´astico.

Figura 3.1: Tabela do fornecedor do Motor Brushless

Fonte: http://rctimer.com/product-1188.html

Uma vez escolhido o Ardupilot para ser o piloto autom´atico do quadric´optero, foram procuradas as controladoras compat´ıveis com este c´odigo. Levou-se em considera- ¸c˜ao o pre¸co e a facilidade de adquirir o hardware necess´ario que deveria ser importado, uma vez que n˜ao existem controladoras produzidas em territ´orio nacional. O PXFmini ´e um shield open source para Raspberry Pi contendo todos os sensores essenciais para o desenvolvimento de um drone (figura 3.2). O shield ´e uma placa de hardware feita para adicionar funcionalidades ao ser acoplada no hardware existente. Neste shield est˜ao pre- sentes um acelerˆometro e um girosc´opio de 3 eixos, uma b´ussola digital, um barˆometro, um sensor de temperatura e um conversor ADC para medi¸c˜ao do n´ıvel da bateria. Ele ainda fornece duas portas I2C e uma UART onde pode ser conectado um GPS ou outro dispositivo de interesse. Desenvolvido pela Erle Robotics, possui suporte ao Ardupilot e ao PX4 (ROBOTICS, 2017). A Erle Robotics tamb´em fornece uma imagem do Sis- tema Operacional Debian adaptado para usar o Raspberry Pi com o shield PXFMini. A instala¸c˜ao ´e facilitada para que a maior preocupa¸c˜ao seja o desenvolvimento do c´odigo espec´ıfico do controle do ve´ıculo.

Figura 3.2: PXFmini

Fonte: http://erlerobotics.com/blog/product/pxfmini/

Junto com a importa¸c˜ao do PXFmini, importou-se o GPS e o Power Module dispon´ıveis no site da Erle Robotics. O GPS possui uma precis˜ao de at´e 2M e o Power Module permite informar ao Ardupilot a tens˜ao da bateria durante o voo.

Foi necess´ario que o R´adio Controle utilizado possu´ısse ao menos 6 canais. Os quatro primeiros canais s˜ao utilizados para throttle, pitch, roll e yaw, sobrando dois canais que foram utilizados para alternar entre os modos de voo e ativar ou desativar a cˆamera autˆonoma. Atendendo estas caracter´ısticas o modelo do r´adio se torna mais uma escolha pessoal de cada piloto.

A maioria dos receivers de r´adio controle gera um sinal de Pulse Width Modu- lation (PWM) para cada canal. Isso significa que ´e necess´ario um cabo por canal entre receiver e a placa controladora. As controladoras do projeto Ardupilot utilizam um ´unico sinal para comunicar os comandos recebidos do R´adio Controle (RC). O PXFmini aceita somente o signal PPM-SUM que consiste em um sinal contendo o Position-Pulse Modu- lation (PPM) de todos os canais recebidos. O PPM ´e uma t´ecnica de modula¸c˜ao que utiliza o tempo de offset at´e o acontecimento do pulso para determinar o valor que ele representa. Assim como no PWM, o per´ıodo do sinal ´e de 20 milissegundos. O valor do sinal ´e atribu´ıdo dependendo de quantos milissegundos se passam at´e que o pulso seja lido. Na figura figura 3.3 podemos observar como o mesmo valor de um sinal PWM ´e representado em PPM. Enquanto o PWM leva em conta o tempo que o sinal encontra-se em n´ıvel alto, o PPM considera um ´unico pulso de 1ms separando o sinal em n´ıvel alto

do n´ıvel baixo. (FUJIWARA, 2013)

Figura 3.3: PWM vs PPM

Fonte: Autoria Pr´opria

O PPM-SUM envia uma sequˆencia de pulsos onde o intervalo de tempo entre eles ´e o valor do PWM em n´ıvel alto do canal como mostra a figura 3.4. Assim o PPM-SUM desconsidera o tempo em que o sinal permaneceu em n´ıvel baixo. Como os sinais PWM utilizados variam de 1 a 2 ms em n´ıvel alto, o PPM-SUM consegue enviar o sinal de at´e 8 canais PWM em um intervalo de 20 ms sem perdas, considerando o maior tempo em todos os canais.

O encoder utilizado pode ser encontrado no Ardupilot.org que possui um projeto chamado ArduPPM baseado no processador ATMEGA328 para este fim1. Utilizou-se um Arduino Uno e o c´odigo do ArduPPM disponibilzado no github2 para converter os 6 canais do r´adio controle em um sinal PPM-SUM.

1_{Encoder PPM: http://ardupilot.org/copter/docs/common-ppm-encoder.html}

Figura 3.4: PPM SUM

Fonte: Autoria Pr´opria

O gimbal necessita de somente dois eixos de movimenta¸c˜ao, um para manter a cˆamera est´avel no eixo horizontal enquanto o quadric´optero se desloca, e outro para controlar o ˆangulo de inclina¸c˜ao da cˆamera para manter o objeto no centro da imagem capturada conforme a altura de voo varia. Foi escolhido um gimbal que fosse leve e cujo tamanho fosse compat´ıvel com a cˆamera utilizada. Existem in´umeras op¸c˜oes de cˆamera destinadas ao uso em VANTs. Esta se torna outra escolha que varia conforme a preferˆencia pessoal. A ´unica restri¸c˜ao ´e o peso, pois uma cˆamera muito pesada ir´a exigir um motor maior ou at´e mesmo mais motores.

A cama anti-vibra¸c˜ao ´e essencial para isolar a vibra¸c˜ao gerada pela rota¸c˜ao dos motores dos sensores acelerˆometros. Inicialmente ela n˜ao havia sido utilizada e nos resul- tados pudemos observar a diferen¸ca obtida com sua adi¸c˜ao.

Foram utilizadas dois tipos de bateria, uma de 2200mAh e outra de 5200mAh. Recomenda-se utilizar a ´ultima pois sua capacidade influencia no tempo de voo final e o peso adicional da cˆamera faz com que mais corrente seja utilizada pelos motores, reduzindo o tempo de voo total poss´ıvel.

Componente Quantidade Frame S500 em vibra de carbono com suporte para gimbal 1

Motor Brushless RCTimer 2830 - 850KV 4

ESC RCTimer de 30A 4

H´elice RCTimer 10x4,6 de fibra de carbono 4

Raspberry Pi B+ 1

PXFmini 1

GPS uBlox Neo 8M 1

Power Module 1

R´adio Controle Spektrum DX6i de 6 canais 1

Encoder PPM 1

Gimbal BGC 2-Eixos 1

Cˆamera Xiaomi Yi 1

Cama Anti-Vibra¸c˜ao 1

Base em Acr´ılico feita sob-medida 1

Bateria LiPo 5000mAh 1

Bateria LiPo 2000mAh 1

Tabela 3.1: Lista de Componentes

A figura 3.5 mostra o resultado ap´os todos os componentes serem instalados no frame.

Figura 3.5: Foto do quadric´optero montado

Fonte: Autoria Pr´opria

3.2.2 SOFTWARE

Procurou-se utilizar apenas softwares de c´odigo livre ou de uso gratuito visando tornar o projeto o mais acess´ıvel poss´ıvel.

• Ardupilot: Piloto autom´atico pra VANTs que inclui uma s´erie de ferramentas para desenvolvimento e teste do seu c´odigo inclusive um simulador chamado de Software In The Loop (SITL).

• Mision Planner, APM Planner2: Ground Control Station (GCS) que funciona como uma central de controle em terra para facilitar a configura¸c˜ao do VANT, foram utilizado para calibrar e obter os logs de voo do Ardupilot;

• Putty: Software utilizado para acesso remoto ao Raspberry Pi usando SSH, ´e atrav´es dele que o arquivo compilado do Ardupilot ´e enviado ao Raspberry Pi e a configu- ra¸c˜ao do sistema operacional ´e feita;

• Octave: Software para solu¸c˜ao de problemas num´ericos utilizado pra efetuar as valida¸c˜oes e an´alises do log de voo;

• GIMP, Inkscape: Softwares de edi¸c˜ao de imagem utilizados para fazer as imagens ilustrativas;

• Visual Studio Comunity: Ambiente de Desenvolvimento Integrado (IDE) utilizada para estudo do c´odigo do Mission Planner;

• Eclipse Neon: IDE utilizada para estudo e desenvolvimento do c´odigo Ardupilot;

• Git: Software utilizado pra o controle de vers˜ao do c´odigo;

• Linux Ubuntu: Utilizado para compilar o c´odigo do Ardupilot;

3.3 ARDUPILOT

O projeto Ardupilot come¸cou em 2007 na comunidade DIYDrones.com que ´e uma comunidade online dedicada `a cultura do “fa¸ca vocˆe mesmo” focada na constru¸c˜ao de drones. Com o tempo, v´arios projetos foram integrados at´e que em 2010 a primeira placa dedicada ao Ardupilot foi lan¸cada pela 3D Robotics. Em 2013, o c´odigo que se encontrava no Google Code passa para o Github. Em 2014 o primeiro voo feito em uma controladora com um SO em Linux ´e feito, e no final do mesmo ano ´e criada a funda¸c˜ao DroneCode com o objetivo de incentivar o compartilhamento de c´odigo aberto entre desenvolvedores de drones. Em 2015 a Erle Robotics lan¸ca kits de desenvolvimento para Linux. Em mar¸co de 2016 ´e criada a organiza¸c˜ao ardupilot.org e o novo website. Desde mar¸co de 2016 o Ardupilot recebe mais de uma atualiza¸c˜ao por semana adicionando novas funcionalidades e expandindo a sua compatibilidade com sensores e atuadores3.

3.3.1 VIS ˜AO GERAL

O Ardupilot pode ser acessado pelo seu reposit´orio no github4. Nele s˜ao disponi- bilizadas todas as atualiza¸c˜oes, tanto no seu funcionamento b´asico como nas bibliotecas e novos drivers para novas controladoras. Por ser um projeto utilizando v´arias plataformas o seu c´odigo possui n´ıveis de abstra¸c˜ao para que altera¸c˜oes em seu n´ucleo sejam imedi- atamente compat´ıveis com os v´arios tipos de hardware suportados. A figura 3.6 mostra como sua arquitetura est´a organizada. Ele ´e feito sobre a arquitetura baseada em Linux e

3_{Fonte: http://ardupilot.org/ardupilot/docs/common-history-of-ardupilot.html} 4_{Reposit´orio Ardupilot: https://github.com/ArduPilot/ardupilot}

pode ser executado em teoricamente qualquer placa controladora que rode alguma vers˜ao ou varia¸c˜ao deste sistema operacional, dado que os drivers necess´arios estejam dispon´ıveis para ela e possam ser incorporados na biblioteca do Ardupilot.

Figura 3.6: Arquitetura Ardupilot

Fonte: http://ardupilot.org

3.3.2 VE´ICULOS

Cada tipo de ve´ıculo a ser controlado pelo Ardupilot requer um c´odigo espec´ıfico. O comportamento de um ve´ıculo terrestre n˜ao ´e o mesmo que um ve´ıculo a´ereo ou aqu´atico. Por este motivo o Ardupilot ´e subdividido em quatro categorias principais de ve´ıculos. S˜ao elas Copter (quadrotores), Plane (aeromodelos de asa fixa), Rover (ve´ıculos terrestres) e Sub (ve´ıculos subaqu´aticos). Apesar da subdivis˜ao as quatro categorias usam a mesma biblioteca para efetuar a leitura de sensores e o controle de atuadores. Assim, ao compilar o c´odigo para um ve´ıculo em espec´ıfico, ´e necess´ario compilar o projeto Ardupilot como um todo. O ve´ıculo para o qual se deseja o c´odigo ´e especificado na hora da compila¸c˜ao. Quando se refere ao ArduCopter, est´a se referindo especificamente ao c´odigo respons´avel pelo comportamento de ve´ıculos quadrotores. Cada tipo possui uma pasta com seu nome

com seus c´odigos individuais. O tipo de ve´ıculo e a controladora s˜ao especificados na linha de comando na hora de compilar o c´odigo.

3.3.3 MODOS DE VOO

O comportamento do ve´ıculo durante o voo depende do modo de voo ativo. O ArduCopter possui alguns modos b´asicos de voo e outros com comportamentos bem espe- c´ıficos. Esses modos s˜ao divididos em duas categorias: a primeira fornece modos de voos que n˜ao requerem o GPS e a segunda os modos de voo que n˜ao funcionam sem ele. A documenta¸c˜ao do ardupilot recomenda 5 modos de voo que fornecem as funcionalidades b´asicas:

• Stabilize: O piloto tem controle total do ve´ıculo enquanto o ArduCopter fica respon- s´avel somente por estabiliz´a-lo e garantir que seu ˆangulo de inclina¸c˜ao n˜ao ultrapasse um valor m´aximo definido nos parˆametros de configura¸c˜ao;

• Alt Hold : Mesmo que o modo Stabilize com o adicional que o ArduCopter mant´em o ve´ıculo na mesma altura, evitando que o mesmo perca altitude durante o voo;

• Loiter : Neste modo o ArduCopter tenta manter a posi¸c˜ao atual do ve´ıculo assim como a dire¸c˜ao para a qual ele se encontra. Deslocamentos devido ao vento ou qualquer outro fator que n˜ao tenha sido causado por um comando do piloto s˜ao compensados para que o ve´ıculo mantenha sua posi¸c˜ao;

• Return To Launch (RTL): Este modo ´e ativado automaticamente quando o ve´ıculo perde comunica¸c˜ao com o r´adio controle. Ele tamb´em pode ser ativado manualmente pelo piloto e far´a com que o piloto autom´atico assuma controle e retorne o ve´ıculo para a posi¸c˜ao na qual os motores foram armados antes de decolar.

• Auto: Um dos modos mais atrativos do ArduPilot pois permite que o ve´ıculo execute autonomamente um plano de voo previamente estipulado. Pode-se realizar um voo completo neste modo sem que nenhuma a¸c˜ao do piloto seja necess´aria.

Esses s˜ao os modos mais usados e s˜ao o suficiente para realizar a maioria das a¸c˜oes poss´ıveis. Outro fator importante ´e que destes 5 modos, apenas Stabilize e Alt Hold n˜ao requerem GPS. Assim n˜ao existem muitos modos de voo que podem ser utilizados em ambientes fechados.

Um modo de voo ´e composto por duas fun¸c˜oes b´asicas em c´odigo C++ respons´a- veis por iniciar o modo de voo e manter o modo de voo ativo. O projeto adota por padr˜ao

que o nome destas fun¸c˜oes deve seguir a regra “X init()” e “X run()” sendo X o nome do modo ao qual pertencem. A fun¸c˜ao init() ´e respons´avel por verificar se as condi¸c˜oes necess´arias para se iniciar o modo s˜ao satisfat´orias e, caso sejam, inicia as vari´avel que seja de interesse. ´E esta fun¸c˜ao que deve impedir que o modo seja ativado no caso dele exigir um sinal de GPS que n˜ao esteja presente, assim como a falta de qualquer outro sen- sor essencial para o funcionamento esperado modo de voo. Caso as condi¸c˜oes n˜ao sejam encontradas o modo de voo atual ´e mantido. A fun¸c˜ao run() tem como principal objetivo ler os sensores necess´arios e fazer a corre¸c˜ao adequada no comportamento de voo. ´E nela tamb´em que s˜ao feitas as leituras dos comandos recebidos pelo RC em rela¸c˜ao ao throttle, pitch, roll e yaw que depois s˜ao processados adequadamente. Atrav´es da bibliotecas dis- pon´ıveis do Ardupilot, a informa¸c˜ao do comportamento desejado ´e ent˜ao passada para a camada de abstra¸c˜ao de hardware, que, por sua vez, ´e traduzido em comandos de atua¸c˜ao para aos motores do ve´ıculo. Est´a fun¸c˜ao ´e chamada no m´ınimo 100 vezes por segundo para manter o comportamento de voo desejado5.