QUADRICÓPTERO INVESTIGADOR - dainf.ct.utfpr.edu.brfabro/IF66J/Relatorios_Finais/2013_2... · E.9...

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

DEPARTAMENTO ACADÊMICO DE INFORMÁTICA

DEPARTAMENTO ACADÊMICO DE ELETRÔNICA

ENGENHARIA DE COMPUTAÇÃO

ANDREI RIBEIRO DE SOUZA BALBO

EDUARDO DOMANSKI DOS SANTOS

LEONARDO MESQUITA DA SILVA

MARCELO TEIDER LOPES

QUADRICÓPTERO INVESTIGADOR – QI

MONOGRAFIA

CURITIBA

2014

ANDREI RIBEIRO DE SOUZA BALBO

EDUARDO DOMANSKI DOS SANTOS

LEONARDO MESQUITA DA SILVA

MARCELO TEIDER LOPES

QUADRICÓPTERO INVESTIGADOR – QI

Monografia apresentada à disciplina Oficina de

Integração 3, no curso de Engenharia de

Computação da Universidade Tecnológica

Federal do Paraná, como requisito parcial a

aprovação.

Professores: André Schneider de Oliveira

Guilherme Schneider

MONOGRAFIA

CURITIBA

2014

Resumo

Neste projeto estão os passos adotados para a confecção de um

quadricóptero controlado remotamente através de uma interface gráfica. O

embasamento teórico, a análise das alternativas tecnológicas, o desenvolvimento

prático do projeto e os resultados obtidos são documentados a seguir. As três

principais partes são detalhadas de acordo com o plano de execução estabelecido

pela equipe: sistema de comunicação, sistema embarcado e estação base.

Palavras-chave: quadricóptero, sistema embarcado, comunicação sem fio.

Abstract

This report describes the steps taken for making a quadricopter remotely

controlled via a GUI. The theoretical basis for the analysis of technological

alternatives, the practical development of the project and the results are documented

below. The three main components are detailed in accordance with the implementation

plan set out by the team: communication system, embedded system and base station.

Keywords: quadcopter, embedded system, wireless communication.

LISTA DE FIGURAS

Figura 1 - Visão geral do sistema proposto. .............................................................. 10

Figura 2 - Projeto Helimodelo Quadrotor como Plataforma para Desenvolvimento de

Algoritmos de Controle. ............................................................................ 16

Figura 3 - Projeto DECoRe........................................................................................ 17

Figura 4 - Firefly Quadcopter AirFrame 450 mm. ...................................................... 22

Figura 5 - Estrutura desmontada. .............................................................................. 23

Figura 6 - Estrutura montada com componentes. ..................................................... 24

Figura 7 - Estrutura montada com componentes. ..................................................... 24

Figura 8 - Mini câmera CCTV. ................................................................................... 26

Figura 9 - HC-SR04. .................................................................................................. 27

Figura 10 - Módulo Giroscópio e Acelerômetro MPU-6050. ...................................... 28

Figura 11 - Motor brushless Turnigy 1000KV. ............................................................ 30

Figura 12 - Pitch de uma hélice. ................................................................................ 31

Figura 13 - B-Grade 5000 mAh 3S 25 C Lipoly Battery. ............................................ 34

Figura 14 - Diagrama de casos de uso. .................................................................... 42

Figura 15 - Diagrama de Classes. ............................................................................. 49

Figura 16 - Interface gráfica da estação base. .......................................................... 50

Figura 17 - Painel de conexão. .................................................................................. 51

Figura 18 - Demonstração dos botões. ..................................................................... 51



Figura 21 - Painel de comandos. ............................................................................... 53

Figura 22 - Painel de informações sobre inclinação. ................................................. 54

Figura 23 - Demonstração dos eixos. ........................................................................ 54

Figura 24 - Painel de informação dos sensores. ....................................................... 55

Figura 25 - Diagrama de blocos. ............................................................................... 56

Figura 26 - Diagrama elétrico. ................................................................................... 58

Figura 27 - Diagrama elétrico da ligação entre sonares e Arduino. ........................... 59

Figura 28 - Sinal PPM para o ESC. ........................................................................... 60

Figura 29 - Ângulos medidos usando o acelerômetro. .............................................. 61

Figura 30 - Filtro dos dados obtidos da MPU-6050. .................................................. 62

Figura 31 - Funcionamento dos sonares. .................................................................. 64

Figura 32 - Orientação dos motores. ......................................................................... 66

Figura 33 - Movimentos Roll, Pitch e Yaw. ................................................................ 66

LISTA DE TABELAS

Tabela 1 - Alternativas de comunicação sem fio. ...................................................... 21

Tabela 2 - Comparação de modelos de câmera. ...................................................... 25

Tabela 3 - Comparação sensores de distância. ........................................................ 26

Tabela 4 - Comparação dos modelos de giroscópio e acelerômetro. ....................... 27

Tabela 5 - Comparação entre motores brushless. .................................................... 29

Tabela 6 - Estimativa da massa total do quadricóptero. ............................................ 29

Tabela 7 - Requisitos para o microcontrolador. ......................................................... 31

Tabela 8 - Comparação entre microcontroladores. ................................................... 32

Tabela 9 - Comparação entre o consumo dos microcontroladores. .......................... 32

Tabela 10 - Comparação entre kits de desenvolvimento. ......................................... 33

Tabela 11 - Mensagens da estação base. Fonte: Autoria própria. ............................ 37

Tabela 12 - Mensagens do sistema embarcado. Fonte: Autoria própria. .................. 38

Tabela 13 - Cronograma de entregáveis. Fonte: Autoria própria. ............................. 74

Tabela 14 - Orçamento do projeto. Fonte: Autoria própria. ....................................... 75

Tabela 15 - Custos com recursos humanos. Fonte: Autoria própria. ........................ 76

SUMÁRIO

1 INTRODUÇÃO ..................................................................................................... 9

1.1 TEMA ............................................................................................................. 9

1.2 OBJETIVOS ................................................................................................. 10

1.2.1 Objetivo Geral ........................................................................................... 10

1.2.2 Objetivos específicos ................................................................................ 11

1.3 DELIMITAÇÕES DO PROJETO .................................................................. 11

1.4 PROBLEMA ................................................................................................. 12

1.5 JUSTIFICATIVA ........................................................................................... 12

1.6 METODOLOGIA .......................................................................................... 12

1.7 ESTRUTURA DO TRABALHO ..................................................................... 13

2 TRABALHOS CORRELATOS ........................................................................... 15

2.1 Projeto “Quadricóptero” – 2011 .................................................................... 15

2.2 Projeto “Heliomodelo Quadrotor como Plataforma para Desenvolvimento de

Algoritmos de Controle” – 2013 ............................................................................. 15

2.3 Projeto “Dirigível Explorador Controlado Remotamente – DECoRe” – 2012 16

2.4 Tutorial “Build A Quadcopter From Scratch – Hardware Overview” ............. 17

3 ANÁLISE TECNOLÓGICA ................................................................................. 18

3.1 REQUISITOS ............................................................................................... 18

3.1.1 Requisitos da Estação Base ..................................................................... 18

3.1.2 Requisitos do Sistema de Comunicação................................................... 18

3.1.3 Requisitos do Sistema Embarcado ........................................................... 19

3.2 ALTERNATIVAS TECNOLÓGICAS ............................................................. 19

3.2.1 Estação Base ............................................................................................ 19

3.2.2 Sistema de Comunicação ......................................................................... 20

3.2.3 Sistema Embarcado .................................................................................. 21

4 DESENVOLVIMENTO ........................................................................................ 35

4.1 PROTOCOLO DE COMUNICAÇÃO ............................................................ 35

4.1.1 Módulo Xbee 802.15.4 .............................................................................. 35

4.1.2 Mensagens do Sistema de Comunicação ................................................. 36

4.2 ESTAÇÃO BASE ......................................................................................... 38

4.2.1 Software .................................................................................................... 38

4.2.2 Modelagem UML ....................................................................................... 40

4.3 SISTEMA EMBARCADO ............................................................................. 55

4.3.1 Esquema Elétrico ...................................................................................... 57

4.3.2 Controle de Velocidade dos Motores ........................................................ 59

4.3.3 Aquisição de Dados dos Sensores ........................................................... 60

5 RESULTADOS ................................................................................................... 65

5.1 PROJETO DE CONTROLE ......................................................................... 65

5.1.1 Controle_parado ....................................................................................... 67

5.1.2 Controle_decolagem ................................................................................. 67

5.1.3 Controle_pouso ......................................................................................... 67

5.1.4 Controle_subir ........................................................................................... 68

5.1.5 Controle_descer ........................................................................................ 68

5.1.6 Controle_esquerda_direita ........................................................................ 68

5.1.7 Controle_frente_tras ................................................................................. 68

5.1.8 Controle_gira_horario ............................................................................... 69

5.1.9 Controle_gira_antihorario .......................................................................... 69

6 CONCLUSÃO ..................................................................................................... 70

7 REFERÊNCIAS .................................................................................................. 71

APÊNDICE A - PLANO DE EXECUÇÃO ................................................................. 74

A.1 CRONOGRAMA ........................................................................................... 74

A.2 ORÇAMENTO E GASTOS ........................................................................... 75

A.2.1 Aquisição de Materiais .............................................................................. 75

A.2.2 Recursos Humanos .................................................................................. 76

APÊNDICE B – PLANEJAMENTO DE RESPOSTA AOS RISCOS ......................... 78

APÊNDICE C – DIAGRAMA DE CASOS DE USO .................................................. 90

APÊNDICE D – DIAGRAMA DE CLASSES ............................................................. 91

APÊNDICE E – ALGORITMOS DE CONTROLE ..................................................... 92

E.1 FUNÇÃO CalculaP ....................................................................................... 92

E.2 ALGORITMO DE CONTROLE – PARADO .................................................. 93

E.3 ALGORITMO DE CONTROLE – DECOLAGEM .......................................... 94

E.4 ALGORITMO DE CONTROLE – POUSO .................................................... 95

E.5 ALGORITMO CONTROLE – SUBIR ............................................................ 96

E.6 ALGORITMO DE CONTROLE – DESCER .................................................. 97

E.7 ALGORITMO DE CONTROLE – FRENTE/TRÁS ........................................ 98

E.8 ALGORITMO DE CONTROLE – ESQUERDA/DIREITA .............................. 99

E.9 ALGORITMO DE CONTROLE – GIRAR SENTIDO HORÁRIO ................. 100

E.10 ALGORITMO DE CONTROLE – GIRAR SENTIDO ANTIHORÁRIO ......... 101

APÊNDICE F – DIAGRAMA DE ESTADOS DO SISTEMA EMBARCADO ........... 102

9

1 INTRODUÇÃO

Neste capítulo são abordados os objetivos do projeto, suas delimitações e

aplicações. Ainda, uma breve abordagem teórica sobre o uso de quadricópteros na

atualidade servirá de ponto de partida para o início desta documentação, fornecendo

as informações necessárias para introduzir o tema aos leitores.

1.1 TEMA

Durante a pesquisa sobre a literatura existente, foram encontradas

definições e características importantes sobre o artefato que se pretende obter ao final

deste projeto. Entre elas, é importante ressaltar a classificação do quadricóptero como

um Veículo Aéreo Não Tripulado – VANT’s.

Os VANT’s, ou, do inglês, unmanned aerial vehicles (UAV’s) são definidos

como plataformas de vôo capazes de operar de forma autônoma ou operadas

remotamente (PADILHA; ZAIONS; SPULDARO, 2012).

Na maioria das aplicações desenvolvidas, tais veículos têm sido

concebidos como plataformas para embarcar sensores remotos para obtenção de

imagens e dados da superfície terrestre (LONGHITANO, 2010).

Com respeito aos VANT’s mais pesados que o ar, dois grupos são

diferenciados: os de asas fixas (aviões e planadores) e os de asas rotativas

(helicópteros e quadrotores) (BRANDÃO et al., 2012). O segundo grupo destaca-se

pela manobrabilidade e precisão. Estas características justificam sua aplicação

voltada para inspeções detalhadas (COSTA, 2012).

Neste trabalho, é apresentado o projeto elaborado para a construção de

um quadrotor – aqui denominado como quadricóptero – que atende aos requisitos

estipulados na disciplina de Oficina de Integração 3, sendo eles a presença de uma

estação-base, de um sistema embarcado e de um sistema de comunicação sem fio.

O interesse da equipe pelo projeto se deu principalmente pela possibilidade

de desenvolver um sistema robótico dotado da capacidade de voar. Após breve

levantamento das possíveis dificuldades que seriam encontradas durante suas

etapas, a equipe concluiu que o projeto seria factível e que atenderia aos requisitos

da disciplina.

10

O esquema da figura 1 pode auxiliar na visão geral do sistema, cujos

integrantes são: a estação base, o sistema embarcado e o sistema de comunicação.

Essencialmente, a estação base é a interface para o usuário enviar

comandos ao sistema embarcado, bem como receber informações sobre seus

sensores e câmera. O sistema de comunicação se encarrega da troca de informações

entre estação base e sistema embarcado.

Figura 1 - Visão geral do sistema proposto. Fonte: Autoria própria.

1.2 OBJETIVOS

O objetivo geral deste projeto é desenvolver um quadricóptero para uso em

ambientes indoor e que seja controlado remotamente, permitindo a execução de

movimentos em uma direção por vez.

Com este projeto, pretende-se realizar estudos, ensaios e implementação

de um sistema de controle para que o quadricóptero permaneça estável.

11

O quadricóptero deve ser capaz de se manter parado e estável no ar caso

não sofra nenhum estímulo;

O quadricóptero deve ser capaz de usar os sensores para evitar colisões

com as paredes, o teto e o chão, possivelmente ignorando comandos de

movimento;

Deve ser possível enviar comandos para o quadricóptero se deslocar nas

seis direções;

O quadricóptero deve enviar imagens em tempo real para a estação base;

O quadricóptero deve ter uma autonomia mínima de 10 minutos;

O alcance da comunicação deve ser no mínimo de 20 metros.

1.3 DELIMITAÇÕES DO PROJETO

Não será tripulado;

Não carregará nenhum tipo de carga adicional;

Não usará técnicas de Inteligência Artificial;

Não vai gerar mapeamento de ambientes;

Não será capaz de se recuperar de impactos;

O quadricóptero irá se movimentar em um lugar coberto e livre de

obstáculos;

Será capaz de detectar, de forma garantida, apenas colisões com as

paredes, o teto e o chão.

Não será capaz de desviar de obstáculos;

Não usará informações de imagem da câmera para navegação;

12

1.4 PROBLEMA

Conforme afirmam Pastor, Lopez e Royo (2007), as aplicações civis dos

VANT’s podem ser divididas em quatro grandes grupos: ambientais, segurança,

comunicação e monitoramento.

Neste projeto, o interesse, em especial, é sobre os grupos de

monitoramento e segurança, pois, em determinadas tarefas de inspeção de

materiais/locais podem estar presentes riscos à saúde ou dificuldades referentes ao

acesso.

Outra característica que frequentemente ocorre nas aplicações dos dois

grupos são os cenários indoors. O projeto pressupõe a utilização do aparato em

ambientes fechados, pois assim são minimizados alguns problemas como a

instabilidade causada por possíveis correntes de ar, além de evitar a exposição do

quadricóptero à chuva.

1.5 JUSTIFICATIVA

A presença de uma câmera acoplada à estrutura pode enviar imagens

remotamente, respeitado o alcance da comunicação estipulado para o projeto. Desta

forma, os riscos e dificuldades apresentados nas tarefas de inspeção podem ser

reduzidos ou, ainda, eliminados, uma vez que o usuário pode operar o quadircóptero

a uma distância segura e a manobrabilidade do sistema oferece a possiblidade de

alcançar locais de difícil acesso.

1.6 METODOLOGIA

Nas semanas iniciais da disciplina foi elaborado o plano de projeto que

envolveu análise tecnológica, cronograma (APÊNDICE A), orçamento (APÊNDICE A)

e o plano de resposta aos riscos (APÊNDICE B). O plano de projeto orientou a

definição das metas e dos documentos a serem entregues em quatro parcelas.

Cada uma destas parcelas, chamadas de “entregáveis”, representou o fim

de um ciclo de desenvolvimento do projeto, servindo como marco para a entrega de

13

documentações parciais do projeto aos clientes (professores) e como um momento

de avaliação das decisões tomadas e das metas atingidas. Ao final de cada ciclo

houve um replanejamento das tarefas a serem executadas para o próximo entregável.

O plano de projeto previu, inicialmente, uma análise tecnológica onde se

buscou alternativas oferecidas pelo mercado. Para a aquisição de componentes,

estrutura, sensores, foi preferida uma busca no mercado nacional.

Seguiu-se com um estudo teórico e prático sobre os componentes e

sensores utilizados.

Para o desenvolvimento prático, pretendeu-se implementar o software da

estação base em paralelo com o software do sistema embarcado para que, quando

finalizado o sistema de comunicação, fossem iniciados os testes práticos à distância

com o quadricóptero.

Por fim, tratou-se do desenvolvimento dos sistemas de controle seguidos

de ensaios práticos. Paralelo a esses desenvolvimentos, foi atualizado o plano de

projeto que será base para a escrita da monografia.

1.7 ESTRUTURA DO TRABALHO

O capítulo 1 deste trabalho apresenta a introdução sobre o tema,

exemplificando os problemas que podem ser solucionados pelo Quadricóptero

Investigador. Uma visão geral do projeto pode ser obtida, sendo estabelecidos os

objetivos e delimitações previstas para o artefato resultante.

O capítulo 2 fornece os trabalhos correlatos que foram tomados como base

para este projeto. Deles se obteve informações importantes para que a equipe

pudesse se familiarizar com problemas comuns durante o desenvolvimento, bem

como suas soluções. Grande parte da análise das tecnológica foi orientada por este

levantamento.

O capítulo 3 estabelece os requisitos das três principais partes do projeto

e, baseado neles, apresenta as alternativas tecnológicas encontradas para os

atender. As opções feitas para cada alternativa também foram esclarecidas e citadas

ao longo deste capítulo.

O capítulo 4 trata do desenvolvimento de cada parte do projeto,

evidenciando as subdivisões feitas em cada uma delas.

14

No capítulo 5 são discutidos alguns resultados obtidos na construção do

quadricóptero.

Por fim, no capítulo 6 são mostradas as conclusões da equipe sobre o

desenvolvimento do projeto, bem como sobre a metodologia adotada para o seu

gerenciamento.

15

2 TRABALHOS CORRELATOS

A seguir, são apresentados alguns trabalhos correlatos ao tema, que

serviram como exemplos para o desenvolvimento deste projeto.

2.1 Projeto “Quadricóptero” – 2011

O escopo do projeto “Quadricóptero” (FILHO; RUDIGER; NASCIMENTO,

2011) previa o desenvolvimento de um dispositivo eletromecânico capaz de se

locomover no sentido vertical e estabilizar-se no ar com base nos dados apresentados

pelos sensores eletrônicos. Foram, ainda, previamente listados os equipamentos

elementares para tais objetivos: propulsores, rotores, controles eletrônicos de

velocidade (ESCs), acelerômetros e giroscópios. Ao longo da documentação, são

detalhadas informações sobre como funcionam cada um destes elementos e sua

importância para o projeto, o que forneceu base para o levantamento tecnológico.

Infelizmente, nenhuma imagem do aparato construído neste projeto foi

obtida em sua documentação.

2.2 Projeto “Heliomodelo Quadrotor como Plataforma para Desenvolvimento

de Algoritmos de Controle” – 2013

Neste projeto (CAMPERA et al., 2013), o escopo propunha o

desenvolvimento de um quadricóptero utilizando um algoritmo básico de controle, mas

que pudesse ser substituído por tipos mais complexos. Sua documentação também

fornece informações sobre os equipamentos, como a utilização de ESCs para o

controle da velocidade dos motores brushless, corroborando aquelas fornecidas pelos

demais projetos.

16

Figura 2 - Projeto Helimodelo Quadrotor como Plataforma para Desenvolvimento de Algoritmos de Controle.

Fonte: Documentação do projeto Helimodelo Quadrotor.

2.3 Projeto “Dirigível Explorador Controlado Remotamente – DECoRe” – 2012

Neste caso, o projeto apresentado na disciplina de Oficina de Integração 3

(CORDEIRO et al., 2012), destaca-se pela semelhança na necessidade de cumprir os

pré-requisitos solicitados – existência de estação-base, comunicação e usuário. Cabe

salientar a utilização de uma câmera acoplada ao aparato, possibilitando o envio das

imagens capturadas ao usuário. Por deter a capacidade de vôo, o projeto foi tomado

em consideração a fim de conhecer possíveis fatores relevantes ao nosso projeto,

como a prevenção de riscos inerentes ao teste de vôo da estrutura.

17

Figura 3 - Projeto DECoRe. Fonte: Documentação do projeto DECoRe.

2.4 Tutorial “Build A Quadcopter From Scratch – Hardware Overview”

Neste tutorial encontrado na internet, o autor (LIANG, 2013) resume

conceitos básicos como os critérios para o dimensionamento das hélices, da bateria

e alguns cálculos matemáticos para determinar o empuxo total necessário a ser

oferecido pelos motores. Tais conceitos devem ser considerados desde a montagem

da estrutura mecânica até a escolha de componentes eletrônicos como motores e

baterias.

18

3 ANÁLISE TECNOLÓGICA

O levantamento das alternativas tecnológicas e as escolhas realizadas pela

equipe serão descritas ao longo desse capítulo. Os requisitos e uma visão geral do

projeto também serão apresentados a seguir.

3.1 REQUISITOS

Requisito Especificação técnica

Exibir leituras dos sensores O software da estação base deve ser capaz de receber dados dos sensores e mostrar estes para o

usuário

Exibir imagens da câmera O software da estação base deve ser capaz de mostrar para o usuário imagens obtidas pela câmera

em tempo real

Enviar comandos de movimento

O software da estação base deve disponibilizar uma interface para o usuário enviar comandos de

movimento para o quadricóptero

Quadro 1 - Requisitos da estação base. Fonte: Autoria própria.


Trocar mensagens entre estação base e sistema embarcado

Módulo de comunicação sem fio e alcance de 20

metros

Ter baixo consumo de energia Baixo consumo de corrente, possuir modo idle para economizar bateria

Enviar imagens da câmera para a estação base

Câmera com comunicação wireless e receptor para não gastar banda do módulo de

comunicação

Quadro 2 - Requisitos do sistema de comunicação. Fonte: Autoria própria.

19


Acionar quatro motores DC brushless nos dois sentidos com velocidade variável, para a rotação das hélices e movimentação do

quadricóptero

ESC para controle do motor, gerador de

PWM com ciclo útil programável

Medir sua distância em relação ao solo, paredes e teto

Sensores de distância com alcance de no mínimo 3m

Evitar colisões com as paredes, solo e teto mesmo sob comando do usuário

Sensores de distância com distância mínima de funcionamento (ponto cego)

de 10 cm

O quadricóptero deve ser leve O peso total do sistema não deve ultrapassar 1,5kg

O quadricóptero deve manter sua estabilidade

Giroscópio e acelerômetro para controle da velocidade e da estabilidade do

artefato

Quadro 3 - Requisitos do sistema embarcado. Fonte: Autoria própria.

3.2 ALTERNATIVAS TECNOLÓGICAS

Nesta seção, são disponibilizados os resultados da pesquisa acerca das

alternativas tecnológicas disponíveis, bem como as escolhas feitas pela equipe.

a) Sistema Operacional

A câmera escolhida possui drivers apenas para Windows, o que limitou a

escolha para este sistema operacional.

20

b) Banco de Dados

Não será utilizado um sistema de banco de dados para armazenamento de

informações. Guardar imagens captadas da câmera é inviável devido o tamanho dos

arquivos. Dados dos sensores podem ser salvos em arquivos de log de texto puro e

caso seja necessário guardar configurações de usuário do programa, arquivos de

configuração do sistema podem ser usados.

c) Interface Web

Não será usada uma interface Web no projeto.

d) Algoritmo Principal

Várias linguagens orientadas a objetos são adequadas para o projeto, com

poucas diferenças entre elas, ao menos em termos de capacidades para a estação

base. Essas linguagens incluem C++, Java, Python e C#. Foram analisadas

bibliotecas para implementar a interface gráfica de usuário e para a captura da

imagem com a câmera e verificou-se que todas as linguagens consideradas possuem

as bibliotecas necessárias, tornando todas igualmente adequadas para o projeto.

Assim, o fator determinante para a escolha da linguagem utilizada na estação base foi

a experiência prévia da equipe que é maior com o C++.

O sistema de comunicação tem como objetivo realizar as trocas de

mensagens entre o Sistema Embarcado e a Estação Base. A tabela 1 apresenta as

tecnologias de comunicação sem fio pesquisadas. Para uso no projeto, o bluetooth e

o Wi-Fi foram descartados por apresentarem consumo maior do que os módulos RF

e Zigbee.

Optou-se pelo módulo Zigbee, pois mesmo apresentando um custo maior

em relação ao RF, sua utilização pareceu mais fácil devido ao conhecimento prévio

da equipe em relação a este equipamento somado à grande quantidade de exemplos

21

encontrados durante o levantamento bibliográfico sobre o assunto. Foi possível,

portanto, que a equipe prosseguisse com o restante do projeto sem gastar muito

tempo na parte de comunicação.

Tabela 1 - Alternativas de comunicação sem fio. Fonte: Autoria própria.

RF ZigBee Bluetooth Wi-Fi

Alcance 30 a 100

metros

30 a 100

metros

10

metros

50 a 300

Metros

Taxa de

Dados 2 Mbits/s 250 Kbits/s 1 Mbits/s 50 Mbits/s

Consumo Baixo Baixo Médio Alto

Preço R$ 15,00 R$ 55,00 R$ 30,00 R$ 150,00

a) Estrutura do Quadricóptero

Inicialmente, pensou-se em comprar um quadricóptero pronto para

aproveitar a estrutura. Com algumas pesquisas, verificou-se que esta ideia é

indesejável, já que muitos componentes não seriam aproveitados, além de possíveis

incompatibilidades desta estrutura com novos componentes que seriam instalados.

Os preços foram pontos negativos também.

Com isso, optou-se pela aquisição de um frame (apenas a estrutura) de

quadricóptero. O frame escolhido foi o Firefly Quadcopter AirFrame 450mm (figura 4).

22

Figura 4 - Firefly Quadcopter AirFrame 450 mm. Fonte:

http://www.hobbyking.com/hobbyking/store/__24172__q450_glass_fiber_quadcopter_frame_450mm.html

Especificações do Frame:

Largura: 450mm

Altura: 55mm

Peso: 270g

Este frame está disponível no mercado nacional a um preço de R$89,90

(desconsiderando frete). Além disso, a configuração de componentes sugerida condiz

com a especificação dos componentes que optamos por usar.

Configuração sugerida:

4 x motores 28mm 1000~1200kv

4 x 15~25 A ESC

4 x Hélices 8x4~10x4.5 (2CW & 2CCW)

Para a estrutura optou-se pela utilização de um frame pronto, disponível no

mercado e utilizado em vários projetos correlatos. O frame em questão é uma

estrutura composta por duas placas que possuem algumas perfurações possibilitando

23

a fixação de sensores, microcontroladores, câmeras entre outros componentes, e por

quatro braços de fibra de carbono, onde os motores são fixados.

Sua montagem é simples: os braços são parafusados às duas bases. A

figura 5 mostra a estrutura desmontada as figuras 6 e 7 mostram a estrutura montada

com os componentes fixados.

Esta estrutura possui 450mm de largura e uma massa de aproximadamente

270 gramas.

Figura 5 - Estrutura desmontada. Fonte: http://www.swiftrc.co.uk/ekmps/shops/swiftrc/images/dji-f450-quadcopter-artf-kit-6318-

p.jpg

24

Figura 6 - Estrutura montada com componentes. Fonte: Autoria própria.

Figura 7 - Estrutura montada com componentes. Fonte: Autoria própria.

25

b) Câmera

A tabela 2 mostra a comparação entre duas câmeras: Mini câmera CCTV

e Câmera IP H3-186A.

Tabela 2 - Comparação de modelos de câmera. Fonte: Autoria própria.

Analisando as características das duas câmeras, a equipe optou pela mini

câmera CCTV (figura 8), por preencher todos os requisitos propostos e possuir um

peso menor, reduzindo o peso total do artefato. A câmera CCTV também possui a

vantagem de não depender de uma conexão com a rede wireless, fazendo a

comunicação diretamente com a estação base. O consumo não foi utilizado como

critério, pois comparado ao dos motores ele se torna inexpressivo.

Mini Câmera CCTV Câmera IP H3-186A

Comunicação Wireless embutido Wireless

Recepção estação base Via USB Via LAN

Formato da imagem NTSC/PAL H.264

Resolução 380 linhas 480 linhas

Iluminação 0,3 lux 0,3 lux

Fonte de alimentação 8 V 5 V

Peso 20 g 276 g

Alcance 100 m Rede wireless

Preço R$ 90,00 R$ 155,00

26

Figura 8 - Mini câmera CCTV. Fonte: http://www.lightinthebox.com/pt/mini-camera-escondida-sem-fio-cctv-seguranca-203-

usb-dvr_p718167.html

c) Sensores de Distância

Dentre os sensores de distância encontrados, os sensores de ultrassom

são os que mais atendem ao alcance especificado. A tabela 3 ilustra a comparação

entre os sensores HC-SR04 e DYP-ME007.

Tabela 3 - Comparação sensores de distância. Fonte: Autoria própria.

HC-SR04 DYP-ME007

Fonte de alimentação 5 V 5 V

Corrente 2 mA 2 mA

Distância de trabalho 2 cm – 4 m 2 cm – 5 m

Resolução 0,3 cm 0,3 cm

Preço R$ 20,00 R$ 36,00

Peso 15 g 17 g

Saída Digital Sim Sim

Apesar da similaridade entre os sensores, a equipe optou pelo HC-SR04

(figura 9) por apresentar um custo mais baixo.

27

Figura 9 - HC-SR04. Fonte: http://www.filipeflop.com/pd-6b8a2-sensor-de-distancia-ultrassonico-hc-

sr04.html?ct=41d97&p=1&s=1

d) Acelerômetro e Giroscópio

Para o controle da velocidade e da estabilidade do quadricóptero a equipe

optou por utilizar um giroscópio e um acelerômetro de três eixos. Todos os

componentes analisados preenchem os requisitos propostos, mas por motivos

financeiros foi preferida a compra da placa com as duas funcionalidades. A placa

escolhida foi Módulo Giroscópio e Acelerômetro MPU-6050 (figura 10). A tabela 4

mostra a comparação com os modelos separados.

Tabela 4 - Comparação dos modelos de giroscópio e acelerômetro. Fonte: Autoria própria.

MPU-6050 (ambos)

L3g4200d (giroscópio)

MMA7361 (acelerômetro)

Alimentação 3 V – 5 V 2,4 V – 3,6 V 2,4 V – 3,6 V

Consumo 3,9 mA 6,1 mA 400 µA

Comunicação de dados IIC IIC ou SPI IIC

Operação de Acelerômetro ±2g ±4g ±8g ±16g --- ±1.5g ±6g

Operação de Giroscópio ±250 ±500 ±1000

±2500 º/s

±250 ±500

±2000 º/s ---

Peso 31 g 50 g 5 g

Preço R$ 25,00 R$ 66,00 R$ 16,00

28

Figura 10 - Módulo Giroscópio e Acelerômetro MPU-6050. Fonte: http://www.infotronic-pe.com/loja/product_info.php?products_id=925

e) Motores

Para a escolha dos motores, deve-se levar em conta alguns fatores como:

KV (RPM/V) – Uma constante referente ao número de rotações por

minuto realizadas por um motor em relação à tensão aplicada a ele;

AMAX – Corrente máxima que consome;

Empuxo (thrust) – indicando quantas gramas o motor consegue

“levantar”;

Peso – Também é um fator a ser considerado, pois faz parte da

massa total do quadricóptero.

A análise do KV foi interpretada da seguinte forma: quanto maior o seu valor

maior velocidade pode ser atingida com 1 V. Será mais rápido, porém terá menor

torque (informalmente, será mais rápido e mais fraco).

Para o empuxo, considera-se que os 4 motores juntos devem levantar o

dobro da massa total do quadricóptero. Assim, cada motor deve ser capaz de levantar

metade da massa total do quadricóptero.

Na tabela 5, são comparados 3 motores brushless com 800KV, 1000KV e

1200KV.

29

Tabela 5 - Comparação entre motores brushless. Fonte: Autoria própria.

Motor Turnigy 2830

800kv

Turnigy 2830

1000kv

Turnigy 3632

1200kv

Peso 54 g 54 g 99 g

Empuxo 540~800 g 500~900 g 1400~1930 g

Corrente máxima 14 A 18 A 40 A

Foi descartado o motor de 1200KV, pois é mais pesado, possui um maior

consumo e um empuxo que se jugou exagerado para o projeto.

Optou-se pelos motores de 800KV e 1000KV, ambos com o mesmo peso.

Com isso, estima-se, na tabela 6, a massa total do quadricóptero.

Tabela 6 - Estimativa da massa total do quadricóptero. Fonte: Autoria própria.

Frame 270 g

4 motores 216 g

4 ESCs 76 g

Bateria 421 g

Considerando demais componentes

(câmera, micro, sensores) temos

um total aproximado:

1300 g

Serão necessários aproximadamente 650 g de empuxo de cada motor.

Optou-se, então, pelo motor de 1000KV (figura 11) que, apesar de ter um consumo

máximo maior, possui uma margem de empuxo maior, dando uma maior segurança.

Outro ponto é a disponibilidade no mercado nacional com um custo não tão elevado

se comparado ao preço no mercado internacional.

30

Figura 11 - Motor brushless Turnigy 1000KV. Fonte: http://www.hobbyking.com/hobbyking/store/catalog/T2830-1000.jpg

f) Hélices

Para as hélices, devemos analisar seu diâmetro e o pitch. O pitch refere-se

à distância percorrida com uma rotação completa da hélice, como mostra a figura 12.

Com pitches menores pode-se obter um torque maior, além de auxiliar na economia

do consumo por parte dos motores.

Uma hélice com menor pitch e um diâmetro maior é mais aconselhável para

quadricóptero que necessita carregar peso extra. Outro ponto positivo desta

configuração é sua maior estabilidade.

O fabricante dos motores sugere o uso de hélices 9x6 a 10x4.7 (diâmetro

x pitch, em polegadas). Assim, considerando a explicação acima, optou-se pelas

hélices 10x4.7, também de fácil acesso no mercado nacional.

Outro detalhe importante é a orientação das hélices: sentido horário e anti-

horário. Em projetos de quadricóptero utiliza-se duas hélices de cada sentido, sendo

assim, dois motores girando no sentido horário e dois no sentido anti-horário. Esta

configuração possibilita o giro no eixo Z, movimento abordado na seção 5.1.

31

Figura 12 - Pitch de uma hélice. Fonte: http://www.pilotfriend.com/aero_engines/aero_eng_dvmt.htm

g) Microcontrolador

Baseado nas especificações do sistema embarcado e de comunicação,

foram definidas as características mínimas necessárias para o microcontrolador, como

mostra a tabela 7.

Pretende-se utilizar um timer para cada sonar e um timer para controlar os

quatro motores. A leitura do acelerômetro e giroscópio também exigirá um timer,

assim, deve-se escolher um microcontrolador que suporte estes 8 timers.

Tabela 7 – Requisitos para o microcontrolador. Fonte: Autoria própria.

Característica Mínimo

Timers 8

Saídas PWM 4

Pinos I/O 24

Interfaces

seriais

1 x SPI,

1 x IIC

Dentre os vários microcontroladores que possuem essas especificações,

levou-se em conta os mais baratos encontrados na pesquisa e os de maior facilidade

na obtenção. No entanto, a equipe não possui conhecimento suficiente para a

32

construção completa de placas com essa complexidade e o tempo gasto para isso

seria inviável para o projeto. Portanto, decidiu-se utilizar um kit de desenvolvimento.

A comparação entre as principais características dos dois kits considerados se

encontra na tabela 8.

Tabela 8 – Comparação entre microcontroladores. Fonte: Autoria própria.

TM4C123GH6PM LPC1343

Barramento 32 bits 32 bits

Pinos I/O digitais 43 42

Frequência de clock 80 MHz 72 MHz

Timers 12 GPTM, 2 Watchdog 4

PWM/Output compare 16 13

Canais ADC 2 8

UART 8 1

SPI 4 1

I2C 4 1

USB Sim Sim

Flash 256 kB 32 kB

SRAM 32 kB 8 kB

EEPROM 2 kB -

Alimentação 3,3 V 2,0 V – 3,6 V

A tabela 9 mostra a comparação entre o consumo:

Tabela 9 – Comparação entre o consumo dos microcontroladores. Fonte: Autoria própria.

TM4C123GH6PM LPC1343

Modo Corrente típica Modo Corrente típica

Active mode 45 mA Active mode 4 mA

Sleep mode 29,5 mA Idle mode 2 mA

Deep-sleep mode 9,3 mA Power-Save mode 30 µA

Hibernate mode 4,5 µA Power-Down mode 220 nA

33

Por fim, a tabela 10 mostra a comparação entre os dois kits de

desenvolvimento.

Tabela 10 – Comparação entre kits de desenvolvimento. Fonte: Autoria própria.

TivaTM C Series

TM4C123G

(TM4C123GH6PM)

LPCXpresso

(LPC1343)

Dimensões 51 x 66 mm 35 x 72 mm

Programação USB nativo ou JTAG USB nativo ou JTAG

Debug Só com JTAG Sim

Expansibilidade Alta Alta

IDE Sim Sim

Preço R$ 34,00 R$ 150,00

Baseando-se nas tabelas 7 a 10, a equipe optou pela aquisição do kit

TM4C123G. Essa escolha se deve principalmente ao custo reduzido e em segundo

lugar porque o número maior de timers e interfaces de comunicação facilitam a

expansão em trabalhos futuros.

Ele apresenta um consumo maior, porém, comparado ao consumo dos

motores, este se torna inexpressivo. A aquisição deste kit só é possível através de

importação, o que explica o custo mais baixo.

h) Bateria

O motor escolhido tem um consumo máximo de 18 A. Somado ao consumo

dos demais componentes, esperamos um consumo total de 73 A. A escolha da bateria

deve ser capaz de fornecer esta carga e ter uma margem de segurança.

Será utilizada uma bateria de lítio com 3 células, produzindo 11,1 V (figura

13).

Para suprir o consumo de corrente, será utilizada uma bateria com

capacidade de 5000 mAh 25C. Esta bateria pode fornecer uma corrente constante de

5 A durante uma hora e possui uma taxa de descarga 5 A * 25 = 125 A, suficiente para

nossa demanda.

34

Pode-se estimar, aproximadamente, o tempo de voo com essa bateria, no

caso de força máxima dos motores.

5 A / 73 A = 0,068 horas = 4,8 minutos

Essas baterias são caras e, por esse motivo, foram importadas.

Figura 13 - B-Grade 5000 mAh 3S 25 C Lipoly Battery. Fonte: http://www.hobbyking.com/hobbyking/store/catalog/B5000.3S.25C.jpg

35

4 DESENVOLVIMENTO

Neste capítulo são apresentados detalhes sobre o desenvolvimento da

estação base, do sistema embarcado, do sistema de comunicação e, ainda, da

estrutura física do quadricóptero.

4.1 PROTOCOLO DE COMUNICAÇÃO

Nesta seção é apresentado o módulo Xbee, utilizado para o sistema de

comunicação do projeto. As mensagens utilizadas na comunicação com o

quadricóptero foram definidas com base nesse protocolo.

Os módulos Xbee são uma família de módulos de rádio projetados para

fácil utilização, a maioria deles possuindo também vários recursos adicionais que

aumentam sua versatilidade em relação aos módulos RF simples. Esses recursos

incluem controle de fluxo, conversão analógico-digital, sincronização entre pinos dos

módulos e criptografia dos pacotes. O módulo Xbee 802.15.4 implementa o padrão

IEEE 802.15.4 na camada física.

O módulo possui três principais modos de operação:

Modo transparente: Os módulos simulam uma conexão serial entre os

dois pontos de comunicação. Do ponto de vista dos sistemas conectados,

não existe comunicação sem fio, como se existisse um cabo serial

conectando as duas pontas.

Modo API: Garante acesso à camada de empacotamento da

comunicação, tornando disponível para o usuário, por exemplo,

informações e controle de endereçamento, parâmetros de configuração e

confirmação de entrega de pacotes. Também permite usar as

funcionalidades de conversão analógico-digital e sincronização dos pinos,

entre outras.

36

Modo de comando: Serve principalmente para configuração do módulo.

O módulo entra no modo de comando quando uma sequência de controle

é enviada pelo pino DIN, seguida de uma pausa. Ele sai automaticamente

do modo de comando após um tempo sem receber nenhum comando.

Foi escolhido operar no modo transparente. Neste modo, todos os dados

que entrarem no pino Data In (DIN) (usando comunicação serial) são enviados pela

rede de acordo com a configuração de rede escolhida, e todos os dados que forem

recebidos são enviados por comunicação serial através do pino DataOut (DOUT). O

pino DIN é então conectado ao pino TX e o pino DOUT é conectado ao pino RX da

comunicação serial (conforme figura 25). Deste modo, dados enviados pelo pino TX

de um dos lados da comunicação entram pelo DataIn do Xbee, são enviados pela rede

sem fio, chegam no receptor de destino e são enviados pelo DataOut para o pino RX

do destino, formando uma comunicação serial.

Através do sistema de comunicação entre a estação base e o quadricóptero

serão trocadas as mensagens listadas nas tabelas 14 e 15.

Nota-se um maior número de tipos de mensagens enviadas a partir da

estação base, pois ela está encarregada de enviar os comandos de locomoção do

quadricóptero, mensagens para conexão e mensagens de erros.

O payload destes pacotes possui um tamanho que varia de 4 a 7 bytes. Os

quatro primeiros bytes representam o header da mensagem, sendo composto pelo

número de sequência da mensagem (numSeq) nos três primeiros bytes e o quarto

byte identificando o comando que está sendo solicitado.

Alguns comandos necessitam de um parâmetro extra, como comandos de

locomoção que devem passar um valor de velocidade com o qual deve ser executado

o movimento. Assim, um quinto byte é reservado para este dado.

Pacotes que indicam erros, como mensagens corrompidas, precisam

passar como parâmetro o número de sequência da mensagem em que foi encontrado

o problema. Três bytes são reservados para este dado (quinto ao sétimo byte).

37

Tabela 11 - Mensagens da estação base. Fonte: Autoria própria.

Comando Header – 4 bytes Mensagem – 0 a 3 bytes

numSeq

[0][1][2]

Tipo

[3]

Mover Esquerda 0x00h Velocidade [4]

Mover Direita 0x01h Velocidade [4]

Mover Frente 0x02h Velocidade [4]

Mover Trás 0x03h Velocidade [4]

Girar Horário 0x04h Velocidade [4]

Girar Anti-horário 0x05h Velocidade [4]

Subir 0x06h Velocidade [4]

Descer 0x07h Velocidade [4]

Parar 0x08h

Decolar 0x09h

Pousar 0x0Ah

Erro Desconhecido 0x0Bh

ID Msg Errada 0x0Ch numSeq [4][5][6]

Msg Corrompida 0x0Dh numSeq [4][5][6]

Msg Inesperada 0x0Eh numSeq [4][5][6]

Valor Inválido 0x0Fh numSeq [4][5][6]

Handshake 0x10h

Desconectar 0x11h

Keep Alive 0x12h

Os pacotes enviados a partir do sistema embarcado seguem um formato

diferente para alguns comandos. O header de 4 bytes é mantido, porém os dados de

todos os sensores são enviados em um mesmo pacote. Para estes dados são

utilizados 24 bytes além do header.

Mensagens informando colisão e diagnóstico utilizam um byte além do

header contendo seu status.

38

Tabela 12 - Mensagens do sistema embarcado. Fonte: Autoria própria.

Comando Header - 4 bytes Mensagem - 0 a 24 bytes

ID [0][2] Tipo [3]

Diagnóstico 0x13h Status [4]

Dados

Sensores 0x14h

Acel. X [4][5]

Acel. Y [6][7]

Acel. Z [8][9]

Giro. X [10][11]

Giro. Y [12][13]

Giro. Z [14][15]

Sonar Frente [16][17]

Sonar Trás [18][19]

Sonar Direita [20][21]

Sonar Esquerda [22][23]

Sonar Cima [24][25]

Sonar Baixo

[26][27]

Colisão detectada

0x15h Num. Sensor [4]

Status - No ar

0x16h

Status - No chão

0x17h

4.2 ESTAÇÃO BASE

Esta seção é composta pela apresentação do software da estação base. É

apresentado todo o planejamento (análise de requisitos e modelagem UML) e a

interface gráfica do sistema.

4.2.1.1 Requisitos Funcionais

RF01 – O software da estação base deverá permitir ao usuário

estabelecer uma conexão entre a estação base e o Quadricóptero.

RF02 – O software da estação base deverá permitir ao usuário

estabelecer uma conexão entre a estação base e a câmera.

39

RF03 – O software da estação base deverá permitir ao usuário visualizar

os dados de todos os sensores de distância contanto que o Quadricóptero

esteja conectado.


os dados do acelerômetro desde que esteja estabelecida a conexão entre

a estação base e o Quadricóptero.


os dados do giroscópio desde que haja conexão entre a estação base e o

Quadricóptero.

RF06 – O software da estação base deverá mostrar ao usuário a imagem

captada pela câmera, desde que ela esteja conectada.

RF07 – O software da estação base deverá permitir ao usuário enviar

comandos de movimentação do Quadricóptero desde que ele esteja

conectado.

o RF07.1 – O software da estação base deverá permitir ao usuário

enviar um comando para que o Quadricóptero suba.


enviar um comando para que o Quadricóptero desça.


enviar comandos para o Quadricóptero ir para frente.


enviar comandos para o Quadricóptero ir para trás.


enviar comandos para o Quadricóptero ir para a esquerda.


enviar comandos para o Quadricóptero ir para a direita.


enviar um comando de rotação do Quadricóptero no sentido

horário.


enviar um comando de rotação do Quadricóptero no sentido anti-

horário.

40

RF08 – O software da estação base deverá exibir uma mensagem de

alerta ao usuário quando algum dos lados do Quadricóptero estiver a

30cm de algum obstáculo.

4.2.1.2 Requisitos Não Funcionais

RNF01 – O software deverá exibir a imagem captada pela câmera,

acoplada ao Quadricóptero, em uma interface gráfica.

RNF01.1 – A imagem da câmera deverá ser atualizada em, no

mínimo, 15 quadros por segundo.

RNF02 – O software deverá exibir a distância do Quadricóptero às

paredes, teto e solo.

o RNF02.1 – A leitura dos sensores de distância deverá ser

mostrada em centímetros.

o RNF02.2 – A leitura dos sensores de distância deverá ser

atualizada, no mínimo, uma vez a cada meio segundo.

RNF03 – O software deverá mostrar a orientação relativa ao eixo Z do

Quadricóptero em graus.

RNF04 – O software deverá exibir a inclinação em relação aos planos X

e Y do Quadricóptero em graus.

Esta seção apresenta a modelagem UML do software da estação base.

Apenas são apresentados os componentes da modelagem que a equipe julgou

relevantes para o planejamento e desenvolvimento do software.

4.2.2.1 Atores Identificados

Os atores identificados durante a análise são listados a seguir:

Usuário

Câmera

41

Motores

Sensores

4.2.2.2 Casos de Uso Identificados para o Software da Estação Base

Comando de conectar a estação base ao quadricóptero.

Representado pelo caso de uso “Conectar - CU01".

Comando para o quadricóptero decola. Representado pelo caso de

uso “Decolar - CU02".

Comando para o quadricóptero pousar. Representado pelo caso de

uso “Pousar - CU03".

Comando de movimentação do quadricóptero para frente.

Representado pelo caso de uso “Mover para frente - CU04".

Comando de movimentação do quadricóptero para trás.

Representado pelo caso de uso “Mover para trás - CU05".

Comando de movimentação do quadricóptero para esquerda.

Representado pelo caso de uso “Mover para esquerda - CU06".

Comando de movimentação do quadricóptero para direita.

Representado pelo caso de uso “Mover para direita - CU07".

Comando de movimentação do quadricóptero para cima.

Representado pelo caso de uso “Subir - CU08".

Comando de movimentação do quadricóptero para baixo.

Representado pelo caso de uso “Descer – CU09".

Comando de rotação do quadricóptero no sentido horário.

Representado pelo caso de uso “Rotacionar no sentido horário –

CU10".

Comando de rotação do quadricóptero no sentido anti-horário.

Representado pelo caso de uso “Rotacionar no sentido anti-

horário – CU11".

Comando para aumentar a velocidade de movimentação do

quadricóptero. Representado pelo caso de uso “Aumentar

velocidade – CU12".

42

Comando para diminuir a velocidade de movimentação do

quadricóptero. Representado pelo caso de uso “Diminuir

velocidade – CU13".

Comando para desconectar a estação base do quadricóptero.

Representado pelo caso de uso “Desconectar – CU14".

4.2.2.3 Diagrama de Casos de Uso do Sistema

A figura 14 (encontrada em maior escala no APÊNDICE C) mostra a visão

geral do projeto, incluindo atores e casos de uso identificados no projeto. Os quadros

a seguir detalham a especificação de cada caso de uso.

Figura 14 - Diagrama de casos de uso. Fonte: Autoria própria.

43

Nome Ligar câmera

Ator principal Usuário

Atores secundários Câmera

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para ligar a câmera e obter imagens a partir do quadricóptero.

Pré-condições A conexão entre a estação base e a câmera não deve estar estabelecida.

Pós-condições A estação base e a câmera devem estar conectadas.

Fluxo básico

1. O usuário aperta o botão de ligar a câmera.

2. A comunicação entre a estação base e a câmera deve ser estabelecida.

3. A câmera retorna imagens em tempo real para a estação base.

4. A estação base mostra as imagens recebidas ao usuário. Quadro 4 - Caso de Uso: Ligar câmera.

Nome Conectar


Atores secundários

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para conectar a estação base ao quadricóptero.

Pré-condições A estação base precisa estar desconectada ao quadricóptero.

Pós-condições A estação base precisa estar conectada ao sistema embarcado.

Fluxo básico

1. O usuário aperta o botão de conectar.

2. A interface de comunicação da estação base envia uma mensagem com o comando solicitado para a interface de comunicação do sistema embarcado.

3. A interface de comunicação do sistema embarcado recebe a mensagem e envia uma resposta à estação base.

Quadro 5 - Caso de Uso: Conectar.

44

Nome Decolar


Atores secundários Motores

Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para que o quadricóptero decole.

Pré-condições

A estação base precisa estar conectada ao quadricóptero.

O quadricóptero precisa estar no chão.

Não deve haver nenhum obstáculo a menos de um metro de distância acima do quadricóptero.

Pós-condições O quadricóptero precisa estar voando.

Fluxo básico

1. O usuário aperta o botão de decolar.


3. A interface de comunicação do sistema embarcado recebe a mensagem e envia os respectivos comandos aos motores.

Quadro 6 - Caso de Uso: Decolar.

Nome Pousar



Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para que o quadricóptero pouse.

Pré-condições A estação base precisa estar conectada ao quadricóptero.

O quadricóptero precisa estar no ar.

Pós-condições O quadricóptero precisa estar no chão

Fluxo básico

1. O usuário aperta o botão de pousar.



Quadro 7 - Caso de Uso: Pousar.

45

Nome Mover para frente



Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para frente.

Pré-condições


O quadricóptero precisa estar parado.

O quadricóptero precisa estar a uma distância maior que 30 centímetros de qualquer obstáculo à sua frente.

Pós-condições O quadricóptero precisa se mover para frente enquanto o botão estiver pressionado.

Fluxo básico

1. O usuário aperta o botão de mover para frente.



Quadro 8 - Caso de Uso: Mover para frente.

Nome Mover para trás



Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para trás.

Pré-condições



O quadricóptero precisa estar a uma distância maior que 30 centímetros de qualquer obstáculo às suas costas.

Pós-condições O quadricóptero precisa se mover para trás enquanto o botão estiver pressionado.

Fluxo básico

1. O usuário aperta o botão de mover para frente.



Quadro 9 - Caso de Uso: Mover para trás.

46

Nome Mover para direita



Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para direita.

Pré-condições



O quadricóptero precisa estar a uma distância maior que 30 centímetros de qualquer obstáculo à sua direita.

Pós-condições O quadricóptero precisa se mover para direita enquanto o botão estiver pressionado.

Fluxo básico

1. O usuário aperta o botão de mover para direita.



Quadro 10 - Caso de Uso: Mover para direita.

Nome Mover para esquerda



Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para esquerda.

Pré-condições



O quadricóptero precisa estar a uma distância maior que 30 centímetros de qualquer obstáculo à suas esquerda.

Pós-condições O quadricóptero precisa se mover para esquerda enquanto o botão estiver pressionado.

Fluxo básico

1. O usuário aperta o botão de mover para esquerda.



Quadro 11 - Caso de Uso: Mover para esquerda.

47

Nome Subir



Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para cima.

Pré-condições



O quadricóptero precisa estar a uma distância maior que 30 centímetros de qualquer obstáculo acima.

Pós-condições O quadricóptero precisa se mover para cima enquanto o botão estiver pressionado.

Fluxo básico

1. O usuário aperta o botão de subir.



Quadro 12 - Caso de Uso: Subir.

Nome Descer



Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para baixo.

Pré-condições



O quadricóptero precisa estar a uma distância maior que 30 centímetros de qualquer obstáculo abaixo.

Pós-condições O quadricóptero precisa se mover para baixo enquanto o botão estiver pressionado.

Fluxo básico

1. O usuário aperta o botão de descer.



Quadro 13 - Caso de Uso: Descer.

48

Nome Rotacionar no sentido horário



Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para rotacionar o quadricóptero no sentido horário.



Pós-condições O quadricóptero precisa rotacionar no sentido horário enquanto o botão estiver pressionado.

Fluxo básico

1. O usuário aperta o botão de rotacionar no sentido horário.



Quadro 14 - Caso de Uso: Rotacionar no sentido horário.

Nome Rotacionar no sentido anti-horário



Sensores

Resumo Este caso de uso descreve as etapas percorridas pelo usuário para rotacionar o quadricóptero no sentido anti-horário.



Pós-condições O quadricóptero precisa rotacionar no sentido anti-horário enquanto o botão estiver pressionado.

Fluxo básico

1. O usuário aperta o botão de rotacionar no sentido anti-horário.



Quadro 15 - Caso de Uso: Rotacionar no sentido anti-horário.

49

Nome Selecionar velocidade



Resumo Este caso de uso descreve as etapas percorridas pelo usuário para selecionar a velocidade de movimentação do quadricóptero.

Pré-condições


O quadricóptero precisa estar no ar.


Pós-condições O quadricóptero passará a movimentar-se com a velocidade selecionada.

Fluxo básico

1. O usuário seleciona a velocidade.

2. Em cada mensagem de movimentação, o byte que representa a velocidade de movimentação se torna o valor selecionado.

Quadro 16 - Caso de Uso: Selecionar velocidade.

4.2.2.4 Diagrama de Classes

A figura 15 mostra o diagrama de classes do software da estação base.

Figura 15 - Diagrama de Classes. Fonte: Autoria própria.

50

A partir dele tem-se uma visão melhor da sua organização, além de facilitar

o processo de implementação. No APÊNDICE D a figura pode ser visualizada em

maior escala.

4.2.2.5 Interface Gráfica

A interface gráfica para controle do Quadricóptero Investigador foi

implementada para facilitar o controle e a visualização dos dados de todos os

sensores, como pode ser visto na figura 16.

Figura 16 - Interface gráfica da estação base. Fonte: Autoria própria.

Inicialmente, a GUI oferece ao usuário a possibilidade de configurar e

estabelecer a conexão da estação base com o quadricóptero. Entre essas

configurações, podem ser selecionadas opções da porta, baud rate, bits, paridade e

stop bits – todas encontradas no painel superior esquerdo da interface, mostrado na

figura 17.

51

Figura 17 - Painel de conexão. Fonte: Autoria própria.

A conexão é estabelecida em dois passos: o primeiro passo é a ativação

do módulo XBee através do comando “Conectar Serial”, e o segundo é a conexão

deste módulo com o QI através do comando “Conectar Quadricóptero” (figura 18).

Figura 18 - Demonstração dos botões. Fonte: Autoria própria.

Após realizadas, essas conexões podem ser canceladas com os

respectivos comandos de desconectar: “Desconectar Serial” e “Desconectar

Quadricóptero” que podem ser visualizados na figura 19. Cabe salientar que caso

esses comandos sejam dados depois que o QI esteja no ar, sua ação natural será

interromper qualquer movimento que estiver fazendo e permanecer no local onde está

até que a conexão com a estação base seja reestabelecida.

52


Estabelecida a conexão, o primeiro comando que o usuário pode enviar ao

Quadricóptero Investigador é o de decolar, que o fará levantar voo até altura pré-

determinada. Enquanto o quadricóptero estiver no ar, o botão “Decolar” ficará

desativado, como pode ser visto na figura 20.


Com o quadricóptero no ar, os comandos de movimentação são habilitados

no painel inferior esquerdo (mostrado na figura 21). Como o controle será feito através

do teclado, o painel mostrará em azul os comandos que estão sendo executados

naquele instante.

53

Figura 21 - Painel de comandos. Fonte: Autoria própria.

Os comandos disponíveis são:

Movimentar o Quadricóptero para frente;

Movimentar o Quadricóptero para trás;

Movimentar o Quadricóptero para a esquerda;

Movimentar o Quadricóptero para a direita;

Movimentar o Quadricóptero para cima;

Movimentar o Quadricóptero para baixo;

Rotacionar o Quadricóptero no sentido horário;

Rotacionar o Quadricóptero no sentido anti-horário.

Além disso, é possível aumentar ou reduzir a velocidade do Quadricóptero

através da barra gradativa ao lado dos demais comandos.

O botão “Subir” fará o quadricóptero aumentar a altura relativa ao solo e é

necessário manter o botão pressionado para que haja uma subida contínua. De forma

análoga, o botão “Descer” fará o quadricóptero diminuir sua altura relativa ao solo e,

para manter a descida, é necessário manter o botão pressionado.

Os botões “Frente” e “Trás” controlam o movimento do quadricóptero para

frente e para trás, respectivamente. Mantendo o botão pressionado, mantém-se o

movimento.

Os botões “Esquerda” e “Direita” controlam o movimento do Quadricóptero

para a esquerda e para a direita, respectivamente. O movimento é mantido enquanto

o botão estiver pressionado.

54

Finalmente, os botões “Rotacionar no sentido horário” e “Rotacionar no

sentido anti-horário” controlam o movimento de rotação do quadricóptero. Mantendo

o botão pressionado, mantêm-se o movimento.

Vale ressaltar que não é possível a execução de dois movimentos

simultaneamente: caso o usuário pressione o botão de algum movimento durante a

execução de outro, a movimentação anterior será interrompida e, depois disso, o

quadricóptero passa a fazer o novo movimento.

No painel superior esquerdo (mostrado na figura 22), são mostrados os

dados de inclinação do quadricóptero em relação aos eixos x, y e z. Uma melhor

ilustração dos eixos pode ser vista na figura 23.

Figura 22 - Painel de informações sobre inclinação. Fonte: Autoria própria.

Figura 23 - Demonstração dos eixos. Fonte: Autoria própria.

55

Por fim, no painel inferior direito (figura 24) são mostrados os dados dos

seis sensores de distância, em centímetros. As distâncias maiores que 400 cm são

apresentadas com um ‘X’ na cor verde, indicando que é uma distância superior às que

o sensor consegue captar. Já as distâncias inferiores a 50 cm são mostradas em

vermelho, por indicar que existe algum obstáculo por perto.

Figura 24 - Painel de informação dos sensores. Fonte: Autoria própria.

4.3 SISTEMA EMBARCADO

Na figura 25 temos o diagrama de blocos do sistema embarcado onde se

tem uma visão geral de como os periféricos e microcontrolador se conectam.

56

Figura 25 - Diagrama de blocos. Fonte: Autoria própria.

Os motores se conectam ao microcontrolador através dos ESCs. Um sinal

PPM, modulação por posição de pulso, é enviado para o ESC e este circuito se

encarrega de controlar a velocidade dos motores com base nesse sinal (conforme

explicado a seguir na seção 4.3.2). Sem este circuito, aumentaria muito a

complexidade da tarefa de controlar a velocidade dos motores.

Para a alimentação, utiliza-se uma bateria de 11,1 Volts, suficiente para a

alimentação dos motores. Porém, deve-se regular a tensão da bateria para 3,3 Volts

para que seja feita a alimentação do microcontrolador e dos sensores.

O módulo XBee para a comunicação wireless entre a estação base e o

sistema embarcado se conecta com o microcontrolador através de uma conexão

serial: os pinos DIN (entrada) e DOUT (saída) do XBEE são conectados

respectivamente aos pinos Tx e Rx do microcontrolador.

57

Na figura 25, pode-se notar a utilização do Arduino para a coleta dos dados

dos sensores. Esta escolha se deve pelos problemas surgidos quando se tentou

captar os valores utilizando o Tiva C. A comunicação está correta, porém dados os

dados recebidos se apresentavam inconsistentes. Assim optou-se pela utilização de

outro microcontrolador apenas para captar medições dos sensores e transmitir para o

microcontrolador principal através de uma comunicação serial.

O MPU-6050, módulo acelerômetro/giroscópio, utiliza uma comunicação

I²C com o microcontrolador. Para isso temos os sinais SDA e SCL, sinal de dados e

de clock, respectivamente.

O cálculo das distâncias é realizado emitindo um pulso para o sonar,

Trigger, que por sua vez ativa o Echo. Uma onda sonora é emitida e, enquanto esta

onda não bate em um objeto e retorna para o sonar, o sinal Echo continua em alto. Ao

receber de volta a onda sonora o Echo é desativado e pode-se medir a largura do

sinal Echo, proporcional ao tempo entre a emissão e recepção da onda sonora. No

sistema embarcado, o sinal Trigger é comum a todos os sonares e analisa-se cada

Echo de forma independente.

A câmera possui uma conexão própria com seu receptor e os dois possuem

alimentação própria.

O diagrama de blocos auxilia no desenvolvimento do diagrama elétrico do

sistema embarcado (figura 26) onde as ligações entre os pinos dos componentes e o

microcontrolador são demostradas. Nota-se a utilização do regulador de tensão

LM7833 para alimentar o microcontrolador, XBee, ESCs e MPU6050. Os pinos de

dados do MPU6050 estão conectados ao Arduino por meio de fios.

58

Figura 26 - Diagrama elétrico. Fonte: Autoria própria.

A figura 27 mostra o esquema elétrico das conexões entre o sonares e

Arduino.

59

Figura 27 - Diagrama elétrico da ligação entre sonares e Arduino. Fonte: Autoria própria.

O acionamento e controle de velocidade dos motores brushless não é feito

diretamente pelo microcontrolador, sendo utilizado um ESC (Electronic Speed

Controller – Controlador eletrônico de velocidade) para isso. O ESC é ativado através

de um sinal PPM, que consiste de um pulso com uma duração variando de 1 ms a 2

ms sendo repetido periodicamente a cada 20 ms. A saída do ESC, em termos de

throttle, é proporcional à duração do pulso de entrada, sendo que um pulso de 1 ms

causa uma saída de 0% throttle e uma entrada de 2 ms causa uma saída de 100%

throttle.

60

Figura 28 – Sinal PPM para o ESC. Fonte: http://i442.photobucket.com/albums/qq145/supperman2000/BGA/Module%20HC-

SR04/2.jpg

Foram utilizados dois tipos de placas de sensoriamento no projeto, a MPU-

6050, que mede aceleração nos três eixos e velocidade angular em torno dos três

eixos, usado para obter os ângulos de inclinação e a orientação do quadricóptero, e o

sonar HC-SR04, para medição de distâncias com obstáculos.

Sobre os dados obtidos da MPU-6050 é descontado o offset médio,

aplicado um filtro de média móvel para redução de ruído e é aplicado um filtro

complementar para fusão dos dados do acelerômetro e giroscópio, de forma a

aprimorar a qualidade da medição realizada. Nenhum processamento adicional foi

necessário sobre as medidas obtidas do sonar.

4.3.3.1 Ângulo

O sensor MPU-6050 é uma combinação entre acelerômetro e giroscópio,

capaz de medir acelerações nos três eixos x, y e z, e velocidade angular em torno

desses mesmos três eixos (roll, pitch e yaw). Com as acelerações é possível obter

uma medida dos ângulos roll e pitch, mas não é possível obter uma medida do yaw.

61

4.3.3.1.1 Leitura dos ângulos usando o acelerômetro

Para fazer a leitura dos ângulos (figura 29) usando as medidas de

aceleração nos três eixos, são usadas as seguintes fórmulas:

θroll_acel = arctan (AY / AZ)

θpitch_acel = arctan (AX / AZ)

Sendo:

θroll_acel – Medida em graus da inclinação em torno do eixo X obtida

com acelerômetro;

θpitch_acel – Medida em graus da inclinação em torno do eixo Y obtida

com acelerômetro;

AX – Aceleração percebida no eixo X pelo acelerômetro;

AY – Aceleração percebida no eixo Y pelo acelerômetro;

AZ – Aceleração percebida no eixo Z pelo acelerômetro.

O fator (180 / π) é multiplicado pelo valor do arco tangente para converter

o ângulo de radianos para graus, de forma a trabalhar com a mesma unidade usada

pelo giroscópio.

Figura 29 – Ângulos medidos usando o acelerômetro. Fonte: Autoria própria.

4.3.3.1.2 Filtros

O processo de filtrar os dados da MPU-6050 e fusionar os dados dos

sensores está delineado na figura 30. Inicialmente é descontado um offset de cada

medida realizada. Esta etapa possui a finalidade de reduzir a deriva dos dados obtidos

62

pelo giroscópio, e considerar o ângulo inicial do giroscópio como zero dos dados

obtidos pelo acelerômetro.

Após o cálculo do offset, é feita uma média móvel, com janela de tamanho

10, para reduzir efeitos de ruído das leituras.

Como não é possível obter informações do yaw com os dados do

acelerômetro, não é feita fusão de dados com esse valor, usando apenas informações

do giroscópio.

Figura 30 – Filtro dos dados obtidos da MPU-6050. Fonte: Autoria própria.

4.3.3.1.3 Fusão dos dados

Para fundir os dados dos sensores, são usadas as seguintes fórmulas:

θroll = (1 - PESO_ACEL) * (θroll + GX * Δt) + PESO_ACEL * θroll_acel

θpitch = (1 - PESO_ACEL) * (θpitch + GY* Δt) + PESO_ACEL * θpitch_acel

Sendo:

θroll – Medida em graus da inclinação em torno do eixo X;

θpitch – Medida em graus da inclinação em torno do eixo Y;

GX – Velocidade em torno do eixo X obtida com o giroscópio;

GY – Velocidade em torno do eixo Y obtida com o giroscópio;

Δt – Tempo decorrido desde a última medida;

θroll_acel – Medida em graus da inclinação em torno do eixo X obtida

com acelerômetro;

63

θpitch_acel – Medida em graus da inclinação em torno do eixo Y obtida

com acelerômetro;

PESO_ACEL – Fator entre 0 e 1 do filtro complementar,

representando o peso que acelerômetro terá no filtro. Quanto maior

o peso do acelerômetro, mais rápida a resposta do filtro e maior o

ruído. Foi utilizado o valor 0.2 como peso do acelerômetro.

Ou seja, a medida anterior do ângulo roll ou pitch é atualizada com a

variação medida pelo giroscópio (velocidade angular multiplicada pelo tempo desde a

última medida) e com o valor resultante é feita uma média ponderada com o valor

medido pelo acelerômetro.

4.3.3.2 Distância

Para realizar uma nova leitura em um dos sonares, basta aplicar um pulso

com duração de 10ms no pino de entrada do sonar (trigger). Após isso, o sonar irá

realizar uma leitura, e depois colocar o pino de saída dele (echo) em alta por um tempo

proporcional à distância medida. Pulsos de até 25ms no pino echo representam uma

leitura válida. Caso a distância a ser medida seja maior do que a capacidade de leitura

do sonar, este irá colocar um pulso de 38ms de duração no echo. Para converter o

tempo medido do pulso na distância de leitura, é usada a seguinte relação:

Tempo (us) / 58 = Distância (cm)

64

Figura 31 – Funcionamento dos sonares. Fonte: http://cdn.instructables.com/F7N/VALH/GP6NVNWH/F7NVALHGP6NVNWH.LARGE.jpg

65

5 RESULTADOS

Neste capítulo serão apresentados os resultados obtidos da etapa de

desenvolvimento, concentrando-se no projeto de controle.

5.1 PROJETO DE CONTROLE

Para o controle de estabilidade e controle de movimentos do quadricóptero

optou-se pela utilização de um controle PID. Verificou-se que este tipo de controle é

muito popular, pois apresenta bom desempenho com uma implementação simples e

direta se comparado com outros modelos (NATIONAL INSTRUMENTS, 2011). Em

projetos envolvendo quadricóptero nota-se que o PID é amplamente utilizado.

Dos movimentos possíveis que o quadricóptero pode executar, cada um

possui um controle específico, pois o comportamento dos motores é diferente. Assim,

têm-se os seguintes controles:

Controle_parado;

Controle_decolagem;

Controle_pouso;

Controle_subir;

Controle_descer;

Controle_esquerda_direita;

Controle_frente_tras;

Controle_gira_horario;

Controle_gira_antihorario;

A figura 32 mostra a orientação dos motores utilizada, na qual foram

baseados os controles de movimentos.

66

Figura 32 - Orientação dos motores. Fonte: Autoria própria.

Para um melhor entendimento, a figura 33 apresenta os eixos X,Y e Z,

mostrando quais são os movimentos Roll, Pitch e Yaw, utilizados no controle dos

movimentos.

Figura 33 - Movimentos Roll, Pitch e Yaw. Fonte: Autoria própria.

O atraso no cronograma prejudicou o desenvolvimento do projeto de

controle. Assim, foi implementado o controle com apenas o erro proporcional (“P”).

67

Todos os movimentos utilizam uma mesma função para o cálculo da nova

sáida com base no erro proporcional, que neste caso é a nova velocidade dos motores

em porcentagem.

A função “calculaP” recebe um input, que pode ser um valor de ângulo ou

de altura e um setpoint que é o valor que se quer chegar. O resultado desta função é

um fator de correção que é utilizado pelo controle dos movimentos para variar a

velocidade dos motores.

O algoritmo desta função e das demais funções utilizadas para o controle

dos movimentos estão detalhadas no APÊNDICE E.

O Quadricóptero entra neste estado após qualquer tipo de movimento, é

nele em que deve se manter estável e manter sua altitude constante, sem

movimentação ou inclinação.

Este é o controle para que o quadricóptero decole, partido do chão, para a

altura escolhida como padrão (um metro). As velocidades dos motores são

aumentadas suavemente até que o Quadricóptero comece a levantar do solo, então

é utilizado o controle para chegar ao setpoint de um metro, sempre mantendo a

estabilidade.

Este é o estado em que o objetivo é chegar ao solo. As velocidades dos

motores são reduzidas suavemente até que comece a descer. É utilizado o controle

para o Quadricóptero chegar a cinco centímetros do chão, e então são reduzidos os

motores rapidamente para pousar.

68

Este controle é utilizado para que o Quadricóptero aumente sua altura em

relação ao solo. As velocidades dos motores são aumentadas até que comece a subir

e são mantidas até que o comando seja interrompido, voltando ao estado “parado”.

Já este controle é utilizado para que o Quadricóptero diminua sua altura em

relação ao solo. As velocidades dos motores são diminuídas até que comece a descer

e são mantidas até que o comando seja interrompido, voltando ao estado “parado”.

Este controle é utilizado nos movimentos do Quadricóptero para os lados.

Para isto utiliza-se os dados do acelerômetro, obtendo as inclinações em torno dos

eixos X (Roll) e Y (Pitch). Para uma movimentação lateral, é colocada como setpoint

uma inclinação em torno do eixo X, dependendo da velocidade escolhida. Assim o

quadricóptero buscará manter a inclinação aumentando a velocidade dos motores de

um lado e diminuindo as do lado contrário.

De maneira similar ao anterior, este controle é utilizado nos movimentos do

Quadricóptero frente e para trás. A diferença é que o setpoint agora é colocado na

inclinação em torno do eixo Y (Pitch).

69

Este controle é utilizado no movimento de rotação do Quadricóptero no

sentido horário: as velocidades dos motores 1 e 3 são aumentadas e dos motores 2 e

4, diminuídas. Como a velocidade das hélices girando em um só sentido será maior,

haverá um torque fazendo com que o Quadricóptero gire.

Similar ao controle anterior, este é utilizado para rotacionar o Quadricóptero

no sentido anti-horário. A diferença é que as velocidades dos motores 1 e 3 são

diminuídas e as dos motores 2 e 4, aumentadas.

70

6 CONCLUSÃO

Ao final do projeto, verificou-se que alguns riscos previstos no plano de

projeto realmente ocorreram. Houve alguns atrasos na aquisição de componentes, por

exemplo, a bateria adquirida não chegou. Este problema foi contornado com o

empréstimo de uma outra bateria.

A subestimação de tarefas foi algo determinante. Isso acarretou em atrasos

no cumprimento de outras tarefas, tendo como resultado final a implementação

incompleta ou até a não implementação de alguns requisitos.

Durante o desenvolvimento da comunicação, verificou-se, com atraso, que

havia problemas com determinado pino do microcontrolador. Além disso, a troca de

informações também foi um atraso inesperado, pois havia algum problema na

conversão de dados negativos, pois o kit utilizado não possui um suporte à dados do

tipo double. Isto foi resolvido, posteriormente, deslocando os valores e trabalhando

com porcentagem.

Assim, sobrou pouco tempo para o desenvolvimento prático do projeto de

controle. Esta é uma etapa extremamente trabalhosa, dependente das outras tarefas.

Por esse motivo optou-se pelo desenvolvimento apenas do controle proporcional,

deixando de lado as partes integral e derivativa do controlador PID.

Mesmo com os problemas apresentados, acredita-se que este projeto deixa

uma boa base para projetos futuros. Tem-se uma estrutura sólida, sensores

funcionado, porém, necessitando de algum estudo para contornar os problemas

enfrentados com o microcontrolador utilizado. Um projeto futuro poderá focar no

aprimoramento da parte de controle e na adição de funcionalidades e componentes,

como por exemplo, novos sensores, tendo atenção à carga total do quadricóptero, fato

extremamente relevante.

Vale ressaltar que este projeto mostrou a necessidade de integração de

vários conceitos estudados tanto em disciplinas anteriores à de Oficina de Integração

3 como as que foram cursadas em paralelo, como Fundamentos de Controle e

Sistemas Microcontrolados. Isso faz com que o principal objetivo da disciplina seja

atingido.

71

7 REFERÊNCIAS

Arduino. Disponível em: <http://arduino.cc/it/Main/ArduinoBoardNano>.

Blog QuadcopterGuy. Disponível em: <http://thequadcopterguy.blogspot.com.br/p/choosing-your-parts_23.html,2014>.

Blog RepeatDoMiau. Disponível em: <http://blog.repeatdomiau.com.br/miadas/arduino-com-ultrassom-hcsr04>.

BRANDÃO, Alexandre S.; PIZETTA, Igor H. B.; FILHO, Mario Sarcinelli; CARELLI, Ricardo. Modelagem e Controle Não Linear Subatuado de um Quad-rotor: Parte 2. Campina Grande, 2012.

CAMPERA, Bruno; FILHO, Claudio Toledo; NAKASHIMA, Renan Taizo; LEITE, Rui Pimentel. Heliomodelo Quadrotor como Plataforma para Desenvolvimento de Algoritmos de Controle. Curitiba, 2013.

CORDEIRO, André Cristiano; SCHUARTZ, Fábio César; FERREIRA, Fernando Padilha; HARADA, Luana do Amaral; MEURER, Rafael de Farias. Dirigível Explorador Controlado Remotamente – DECoRe. Curitiba, 2012

COSTA, Exuperry Barros. Algoritmos de Controle Aplicados à Estabilização do Vôo de um Quadrotor. Juiz de Fora, 2012.

E-voo.com. Aeromodelismo elétrico. Disponível em: <http://www.e-voo.com,2012>.

72

FILHO, Gerson Luis Silva; RUDIGER, Gustavo Teixeira; NASCIMENTO, Jonathan Pontes Morais. Quadricóptero. Curitiba, 2011.

FilipeFlop.com. HC-SR04. Disponível em: <http://www.filipeflop.com/pd-6b8a2-sensor-de-distancia-ultrassonico-hc-sr04.html?ct=41d97&p=1&s=1>.

Github. Build software better, together. Disponível em: <https://github.com>.

Hobbyking.com. Frame Q450 Glass Fiber Quadcopter Frame. Disponível em: <http://www.hobbyking.com/hobbyking/store/__24172__q450_glass_fiber_quadcopter_frame_450mm.html,2012>.

LIANG, Oscar. Build a Quadcopter from Scratch – Hardware Overview. Disponível em: <blog.oscarliang.net/build-a-quadcopter-beginners-tutorial-1/>. 2013.

Lightinthebox.com. Mini camera CCTV. Disponível em: <http://www.lightinthebox.com/pt/mini-camera-escondida-sem-fio-cctv-seguranca-203-usb-dvr_p718167.html,2012>.

LONGHITANO, George Alfredo. VANTs para sensoriamento remoto: aplicabilidade na avaliação e monitoramento de impactos ambientais causados por acidentes com cargas perigosas. Dissertaração (Mestrado em Engenharia) –Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia de Transportes. São Paulo. 2010.

National Instruments. Explicando a Teoria PID. Disponível em: < http://www.ni.com/white-paper/3782/pt/>. 2011.

73

OscarLiang.net. Disponível em: <http://blog.oscarliang.net,2013>.

PADILHA, Bruno Ricardo; ZAIONS, Douglas Roberto; SPULDARO, Everton. Projeto aerodinâmico, estabilidade e controle de um veículo aéreo não tripulado (VANT) de asa fixa. Joaçaba, 2012.

PASTOR, Enric; LOPEZ, Juan; ROYO, Pablo. UAV Payload and Mission Control Hardware/Software Architecture. Barcelona, Espanha. 2007.

Sparkfun.com. Disponível em: <https://www.sparkfun.com/products/8687,2010>.

Texas Instruments. Engineer to Engineer Community. Disponível em: <http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/315587.aspx>.

Texas Instruments, Tiva C Series. Disponível em: <http://www.ti.com/tool/ek-tm4c123gxl>.

Zigbee.org. Disponível em: <http://www.zigbee.org>.

74

APÊNDICE A - PLANO DE EXECUÇÃO

Neste plano de execução está presente a metodologia de desenvolvimento, o

cronograma, o orçamento, a relação de gastos e o plano de riscos. Tais documentos puderam

ser elaborados graças as decisões tomadas na análise tecnológica.

A.1 CRONOGRAMA

A tabela 13 apresenta os entregáveis cumpridos durante o desenvolvimento do

projeto. Em anexo se encontra o cronograma de atividades.

Tabela 13 – Cronograma de entregáveis. Fonte: Autoria própria.

Data Subgerente Entregável

18/12/2013 Leonardo

Documentação:

Requisitos do software da estação base

Diagrama de classes do software da estação base

Diagrama de casos de uso do software da estação base

Definição do protocolo de comunicação

Diagrama do protocolo de comunicação da estação base

Diagrama do protocolo de comunicação do sistema embarcado

Descrição das interfaces

29/01/2014 Eduardo

Documentação:

Definir mensagens

Guia de montagem da estrutura

Manual de usuário do software da estação base

Diagramas de sequência do software da estação base

Demonstração da GUI

12/02/2014 Andrei

Documentação:

Projeto dos sistemas de controle: o Estabilidade o Altura o Decolagem o Pouso

Documentação do MPU-6050

Demonstração do funcionamento dos motores

75

26/02/2014 Leonardo

Documentação:

Diagrama em blocos do sistema embarcado

Diagrama elétrico/eletrônico do sistema embarcado

Projeto da PCB

Projeto dos sistemas de controle de movimentação

Diagrama de casos de uso do software embarcado

Diagrama de máquina de estados do software embarcado

Demonstração do recebimento de dados dos sensores

Demonstração da exibição de imagens da câmera

A.2 ORÇAMENTO E GASTOS

A tabela 14 mostra o orçamento para o projeto, indicando itens que serão

importados e os que serão adquiridos no mercado nacional.

Tabela 14 – Orçamento do projeto. Fonte: Autoria própria.

Item Nacionalidade Quantidade Preço Unit

Frete Total

Frame Q450 Nacional 1 R$

89,90 R$ 18,40

R$ 108,30

Helices 10x4.5 Nacional 8 - Envio junto ao frame

R$ 45,80

Bateria B-Grade 5000mAh 3S 25C Lipoly Battery

Internacional 2 R$

33,70 R$ 52,34

R$ 119,74

Sensores

MPU-6050 Acelerômetro 6 Eixos

Nacional 1 R$

20,00 R$ 12,00

R$ 32,00

Sensor Ultrassom Distancia HC-SR04

Nacional 6 R$

16,00 Retirada

pessoalmente R$

96,00

Mini câmera CCTV Nacional 1 R$

89,00 R$ 20,00

R$ 89,00

Comunicação

XBee 1mW Trace Antenna - Series 1 (802.15.4)

Internacional 2 R$

53,24 Grátis

R$ 106,48

76

XBee Explorer USB Internacional 1 R$

57,88 Grátis

R$ 57,88

Microcontrolador

Tiva™ C Series LaunchPad Evaluation Kit

Internacional 1 R$

31,18 Grátis

R$ 31,18

Itens emprestados

Motor Turnigy 2830 Brushless Motor 1000kv

Internacional 4 R$

34,22 R$ 24,00

R$ 160,90

Turnigy AE-20A Brushless ESC

Internacional 4 R$

22,85 R$ 14,40

R$ 105,79

Total (considerando os itens emprestados) R$

953,06

Os cursos do projeto com recursos humanos são apresentados na tabela 15:

Tabela 15 - Custos com recursos humanos. Fonte: Autoria própria.

Principais Etapas Custos

Início do projeto

Aquisição dos componentes necessários

R$ 953,00

Análise de opções tecnológicas – Custos com

horas de trabalho R$ 2.100,00

Definição do cronograma – Custos com horas de

trabalho R$ 1.050,00

Primeiro entregável do projeto – Custos com horas

de trabalho R$ 4.200,00

Segundo entregável do projeto – Custos com horas


Terceiro entregável do projeto – Custos com horas


Quarto entregável do projeto – Custos com horas


Finalização do projeto R$ 4.200,00

Total R$ 25.103,00

77

Os custos com recursos humanos foram contabilizados considerando salário de

cada membro da equipe como R$ 35,00 por hora de trabalho.

78

APÊNDICE B – PLANEJAMENTO DE RESPOSTA AOS RISCOS

Projeto: Quadricóptero Investigador

1 Etapa: Identificação do Risco

Denominação do risco: Subestimação da complexidade, ou dificuldade de uma tarefa

N Identificação:

01

Descrição do risco: Devido à falta de experiência dos membros da equipe, há o risco de que a complexidade

de uma tarefa seja subestimada, resultando, assim, no atraso do desenvolvimento do projeto.

2 Etapa: Avaliação do Risco

Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)

Explique: Como o tempo para o desenvolvimento do projeto é escasso, atrasos no cronograma podem inviabilizar o projeto ou fazer com que as qualidades e/ou funcionalidades sejam diminuídas, afim de que o projeto ainda possa ser concluído no tempo de 10 semanas.

Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)

Explique: A equipe não possui conhecimento suficiente para obter uma boa estimativa da complexidade das tecnologias e suas integrações envolvidas no projeto. Portanto, pode haver o risco de que alguma etapa demore mais que o planejado no cronograma.

3 Etapa: Desenvolvimento da Resposta ao Risco

Ações, Responsáveis e Datas de Conclusão

Estratégias e Ações para eliminar ou reduzir este risco (minimizar impacto e/ou probabilidade):

Prevenir: Primeiramente, dedicar uma atenção especial para a especificação dos tempos necessários para realização das tarefas, durante a etapa de planejamento. Além disso, verificar com outras pessoas (professores e alunos), as quais já possuam experiência com as tecnologias envolvidas, qual será a aproximação de tempo necessário para a realização das partes do projeto.

Transferir:

Mitigar/Aceitar: A execução das etapas de desenvolvimento do projeto sempre será feita aos pares. Desta forma, se houver subestimação em alguma etapa do cronograma, a dupla realizará mais trabalho durante a semana. Para que as funcionalidades e/ou qualidades do projeto não sejam comprometidas, o cronograma envolverá uma “folga” de duração de duas semanas, que poderá ser utilizada para a finalização de determinada implementação. Também, deverão existir folgas no tempo alocado para cada tarefa, reduzindo assim, o impacto de uma subestimação de complexidade de uma tarefa.

Impacto reavaliado: 2 (médio/baixo) Probabilidade reavaliada: 4 (média/alta)

Elaborado por:

Andrei, Eduardo, Leonardo, Marcelo

Data:

16/11/2013

Respostas incluídas na

WBS/Cronograma

Registros adicionais:

Verso ou Anexos

Formulário sugerido por Gasnier, 2000 Editora IMAN e alterado por Wille

79



Denominação do risco: Atraso na entrega de algum componente com data prevista de chegada após 20/01/2014

N Identificação:

02

Descrição do risco: Caso necessário a compra de componentes fora da cidade de Curitiba, pode ocorrer que

a entrega demore mais que o esperado. Esta demora se torna crítica somente após o período de recesso das atividades acadêmicas.



Explique: Se ocorrer um atraso na entrega de algum componente eletrônico, a equipe terá que tentar achar substituto ou realizar uma nova encomenda por outro distribuidor, o que possivelmente comprometerá as funcionalidades e/ou qualidades do projeto (ou até mesmo o inviabilizando por falta de tempo).


Explique: Para alcançar todos os requisitos e funcionalidades exigidas pelo cliente, a equipe terá que contar com a possibilidade de importação de equipamentos eletrônicos. Ao realizarmos importações, existe a probabilidade de que a encomenda seja retida pela Receita Federal.




Prevenir: Evitar a importação. Caso determinado componente não esteja disponível no Brasil, a equipe fará uso de sites comerciais recomendados por professores e/ou de lojas que preveem a demora máxima de um mês na entrega de encomendas. Comércios chineses de equipamentos eletrônicos apresentam demora de mais de um mês para entregas, e devem ser evitados por este motivo. Além disso, realizaremos a compra da maioria dos componentes antes do recesso e evitaremos entregas com data prevista posterior ao dia 20/01/2014.

Transferir:

Mitigar/Aceitar: A equipe também pode usar componentes emprestados de professores ou alunos da UTFPR até o recebimento de encomendas importadas. O cronograma deve ser bem organizado de forma que tempos de espera por encomendas estejam previstos, diminuindo o impacto da espera pelos componentes.

Impacto reavaliado: 3 (médio) Probabilidade reavaliada: 1 (baixa)

Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


80



Denominação do risco: Falha de comunicação entre a equipe N Identificação:

03

Descrição do risco: Devido à equipe não poder realizar encontros diariamente, a comunicação terá que ser

feita basicamente através de e-mails. Desta forma, a interpretação de informações pode ser comprometida e desentendimentos na equipe podem ocorrer.



Explique: Caso haja falha de comunicação entre a equipe, o cronograma pode ser afetado. Consequentemente, mais tempo se fará necessário para a entrega do projeto, ultrapassando o prazo anteriormente planejado.


Explique: Os membros da equipe não se encontram pessoalmente todos os dias. Portanto, é alta a probabilidade de utilização de outros recursos para comunicação.




Prevenir: Primeiramente, a equipe terá a disposição uma relação de telefones de cada membro, para facilitar o contato. A equipe também realizará reuniões semanais, nas quais tudo que for considerado pertinente ao projeto deverá ser esclarecido entre os membros. Cada membro fará um relatório semanal sobre o que fez e como fez, o que facilitará os relatórios quinzenais para os clientes e ajudará no entendimento da resolução do problema para os outros integrantes da equipe.

Transferir:

Mitigar/Aceitar: Pedir esclarecimento absoluto para os membros de forma que não sejam deixadas dúvidas nas decisões de projeto. Fazer a releitura de materiais em texto produzidos pela equipe caso algo não seja esclarecido.

Impacto reavaliado: 2 (médio/baixo) Probabilidade reavaliada: 2 (média/baixa)

Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


81



Denominação do risco: Não cumprimento dos prazos das metas

estabelecidas pela equipe

N Identificação:

04

Descrição do risco: Metas serão estabelecidas para serem entregues a cada duas semanas. Essas metas

devem ser cumpridas pelos membros da equipe para que o projeto siga seu cronograma.



Explique: O impacto desse risco é alto porque atrasa outras metas (devido ao tempo que será necessário gastar para a meta não concluída, na semana seguinte ao deliverable), além de pressionar os integrantes da equipe psicologicamente.


Explique: No período de duas semanas poderão contar com professores ou outros alunos para obter conselhos de como resolver os problemas e seguir com o projeto.




Prevenir: Planejar adequadamente o cronograma, colocando as metas principais para serem realizadas no início do projeto para que não atrasem futuramente outras metas dependentes delas. Transferir:

Mitigar/Aceitar: Utilizar o período de férias em Janeiro.

Impacto reavaliado: 4 (médio/alto) Probabilidade reavaliada: 1 (baixa)

Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


82



Denominação do risco: Desistência de um membro da equipe

N Identificação:

05

Descrição do risco: Algum membro da equipe pode desistir da disciplina no meio do projeto.



Explique: A desistência de um membro da equipe afeta totalmente o cronograma e a distribuição de tarefas para cada integrante.


Explique: Pela conversa que houve entre os integrantes da equipe, nenhum pretende desistir.




Prevenir: Manter os membros animados com o projeto. Cabe ao gerente a tarefa de conversar semanalmente com os integrantes, para verificar o interesse e disponibilidade dos outros membros com o projeto. Transferir: Mitigar/Aceitar: Planejamento do cronograma de forma que torne possível a divisão de tarefas entre duplas de integrantes, de forma que seja minimizado o impacto da desistência de um membro em qualquer momento do projeto.

Impacto reavaliado: 3 (médio) Probabilidade reavaliada: 2 (média/baixa)

Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


83



Denominação do risco: Desistência do gerente da equipe

N Identificação:

06

Descrição do risco: Por alguma razão, o gerente pode desistir da disciplina no decorrer do projeto.



Explique: A desistência do gerente da equipe afeta totalmente o projeto devido à necessidade de eleger outro membro para o cargo, além de acarretar em diversas mudanças no cronograma.


Explique: A probabilidade é baixa, levando em consideração as conversas realizadas entre a equipe.




Prevenir: Manter o gerente confiante em relação ao sucesso do projeto. Os membros precisam sempre demonstrar empenho e seriedade com o cronograma, mantendo a autoestima da equipe sempre alta. Transferir:

Mitigar/Aceitar: Eleger, previamente, um gerente substituto que fique preparado para assumir o cargo a qualquer instante. O gerente deve ter responsabilidade com o projeto e, caso escolha desistir, deve continuar tempo

suficiente para organizar as coisas para garantir que não cause mais problemas do que os causados pela desistência de um membro qualquer.


Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


84



Denominação do risco: Erro de planejamento

N Identificação:

07

Descrição do risco: Cronograma mal planejado.



Explique: Caso as funcionalidades ou a qualidade do artefato sejam afetados, os clientes avaliarão negativamente o produto, e solicitarão que as etapas envolvidas sejam refeitas.


Explique: Devido à inexperiência da equipe em especificação de cronogramas, a probabilidade é elevada.




Prevenir: Através de alunos e/ou professores experientes, verificar a quantidade de tempo aproximada para realização de cada tarefa. O cronograma deverá ser analisado por todos os membros da equipe, de forma que sejam planejados os períodos em que os membros não poderão utilizar horas extras (períodos de prova) para o desenvolvimento do projeto, transferindo essas horas para outras datas, como por exemplo, no início do projeto. Transferir:

Mitigar/Aceitar: Atualizar o cronograma caso as etapas não sejam cumpridas.

Impacto reavaliado: 4 (médio/alto) Probabilidade reavaliada: 3 (média)

Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


85



Denominação do risco: Doença de algum membro da equipe

N Identificação:

08

Descrição do risco: No decorrer do projeto, algum membro pode ficar doente, o que dificultaria ou

impossibilitaria a execução das tarefas no período em que está mal.



Explique: A paralização de um membro por algum tempo pode atrasar o desenvolvimento do projeto, pois impossibilitará a execução de tarefas dependentes daquela que foi atrasada.


Explique: A probabilidade de doenças sempre existe, pois não há nada que possa ser feito com relação a isso.




Prevenir: Sempre procurar cuidar da saúde e, verificado os primeiros sintomas, procurar ir ao médico. A tarefa passa a ser responsabilidade do outro membro da dupla e, caso não consiga, a equipe passa a cogitar um atraso e verificar possíveis mudanças no cronograma. Cabe ao gerente avaliar a possibilidade de delegar a tarefa do membro doente a outro membro da outra dupla.

Transferir:

Mitigar/Aceitar: Atualizar o cronograma, de forma que não comprometa tanto o desenvolvimento do projeto.

Impacto reavaliado: 2 (médio/baixo) Probabilidade reavaliada: 3 (média)

Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


86



Denominação do risco: Avaria na estrutura do quadricóptero

N Identificação:

09

Descrição do risco: O quadricóptero pode sofrer quedas ou choques mecânicos durante os testes

resultando em avarias na sua estrutura.



Explique: Avarias na estrutura do quadricóptero podem acarretar a interrupção ou, ainda, o cancelamento do projeto, dependendo da gravidade das avarias e da fase em que se encontra o projeto.


Explique: Os testes de funcionamento com o quadricóptero em voo oferecem, além da probabilidade de choques contra obstáculos, a probabilidade de queda brusca, podendo ocorrer por imperícia da equipe ou falha eletrônica.




Prevenir: Realiza os primeiros testes com a estrutura amarrada ao teto, para evitar acidentes e, ainda assim, realizá-los sobre superfícies que possam amortecer os impactos provenientes de uma queda. Deve-se ter cautela ao aproximar o quadricóptero de obstáculos enquanto os sensores estiverem em teste.

Transferir:

Mitigar/Aceitar: Possuir componentes de reserva para substituição rápida, principalmente a estrutura e as hélices. Providenciar também rapidamente novos componentes de reserva caso seja necessário utilizar os primeiros.

Impacto reavaliado: 3 (médio) Probabilidade reavaliada: 2 (média/baixa)

Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


87



Denominação do risco: Queima de componente eletrônico

N Identificação:

10

Descrição do risco: Componentes eletrônicos utilizados no projeto podem queimar, sendo necessária sua

substituição.



Explique: O impacto deste risco depende da importância da função desempenhada pelo componente que sofre a queima. Componentes mais ordinários não geram impactos tão grandes, pois são facilmente substituídos.


Explique: Os componentes podem ocorrer principalmente devido a falta de atenção no seu manuseio.




Prevenir: Realizar a compra de componentes reservas caso seja um componente vital e seu prazo de entrega muito grande. Sempre verificar a montagem dos componentes no circuito por outro membro da equipe. Deve-se tomar cuidado no manuseio dos componentes eletrônicos, de forma a evitar erros que possam queimá-los.

Transferir:

Mitigar/Aceitar: Procurar por um componente substituto ou outro fornecedor que possa entregar o componente em um prazo menor, mesmo a um custo maior.

Impacto reavaliado: 2 (médio/baixo) Probabilidade reavaliada: 2 (médio/baixo)

Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


88



Denominação do risco: Falta de componentes em estoque local

N Identificação:

11

Descrição do risco: Falta em estoque local dos componentes eletrônicos utilizados no projeto quando

houver necessidade de substituição.



Explique: O projeto pode sofrer grave atraso em seu desenvolvimento devido à falta do componente a ser substituído, até que um novo fornecedor seja encontrado.


Explique: A maioria dos componentes a serem utilizados no projeto tem caráter ordinário, podendo ser facilmente encontrado para substituição.




Prevenir: Preferência pela utilização de componentes comuns e abundantes no mercado local.

Transferir:

Mitigar/Aceitar: Encontrar outros fornecedores próximos e com componentes em estoque. Manter componentes reservas daqueles considerados essenciais para o projeto. Caso necessário, obter materiais emprestados de colegas e/ou professores da UTFPR.


Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


89



Denominação do risco: Sobrecarga de tarefas devido à semana de

provas de membro da equipe

N Identificação:

12

Descrição do risco: Todos os membros estão sujeitos a entrarem em semana de provas das demais matérias

cursadas, sofrendo sobrecarga de tarefas externas ao projeto.



Explique: A sobrecarga de tarefas externas ao projeto pode diminuir a capacidade de operação do membro da equipe e consequentemente gerar atrasos no cronograma.


Explique: Todos os membros cursam outras disciplinas, estando certamente sujeitos a entrarem em semana de provas.




Prevenir: O planejamento do cronograma deverá levar em conta as datas marcadas de provas dos membros da equipe. Além disso, o gerente precisa estar sempre em contato com a equipe e ciente das mudanças que ocorrerem no cronograma de planejamento das disciplinas, tornando possível a prevenção de sobrecargas inesperadas.

Transferir:

Mitigar/Aceitar: Cabe ao gerente avaliar a possibilidade de delegar maior parte da tarefa ao outro membro da dupla e, caso não seja possível, contar com o auxílio de outra dupla para que a sobrecarga seja mínima para a equipe.

Impacto reavaliado: 2 (médio/baixo) Probabilidade reavaliada: 3 (média)

Elaborado por:


Data:

16/11/2013


WBS/Cronograma


Verso ou Anexos


90

APÊNDICE C – DIAGRAMA DE CASOS DE USO

91

APÊNDICE D – DIAGRAMA DE CLASSES

92

APÊNDICE E – ALGORITMOS DE CONTROLE

E.1 FUNÇÃO CalculaP

*/Este método será utilizado em todos os movimentos*/

/*input é o valor atual, setpoint é o objetivo, output é o erro ou fator de

correção que será aplicado ao motor (no caso)*/

unsigned long lastTime; double Input , Output, Setpoint; double errSum, lastErr; double kp, ki, kd; void CalculaP(input, setpoint) { Input = input; Setpoint = setpoint; /*quanto tempo de interval entre um calculo e outro*/ unsigned long now = getTime(); double timeChange = (double)(now - lastTime); /*calcula os erros*/ double error = Setpoint - Input; // errSum += (error * timeChange); //double dErr = (error - lastErr) / timeChange; /*calcula a saida*/ Output = kp * error + ki * errSum + kd * dErr; /*guarda as variaveis pra proxima vez*/ lastErr = error; lastTime = now; } /*parametros de calculo*/ void SetTunings(double Kp, double Ki, double Kd) { kp = Kp; ki = 0.0; kd = 0.0; }

93

E.2 ALGORITMO DE CONTROLE – PARADO

/*este projeto de controle é pra quando o Quadricóptero precisa se manter

estável, ou seja, parado, sem movimentação*/

/*Ao final de cada movimento, será guardada a altura que estava para

manter*/

Int alturaEst = distSensor6;

CalculaP (distSensor6, alturaEst); //mantêm a altura

vMotor1 += Output*fatorA1;




/*mantêm a estabilidade em relação aos eixos X e Y */

CalculaP (pitch,0);

vMotor1 -= Output*fatorE1; //motores da frente

vMotor2 -= Output*fatorE2;

vMotor3 += Output*fatorE3; //motores de trás

vMotor4 += Output*fatorE4;

CalculaP (roll,0);

vMotor1 -= Output*fatorE1; //motores da esquerda


vMotor2 += Output*fatorE2; //motores da direita


}

94

E.3 ALGORITMO DE CONTROLE – DECOLAGEM

/*motores são aumentados até que a distância em relação ao chão comece a aumentar,

então vai subindo e estabilizando*/

while (distsensor6 <5){

//fica aumentando as velocidades até que saia do chão

vMotor1 += fatorD1;

vMotor2 += fatorD2;

vMotor3 += fatorD3;

vMotor4 += fatorD4;

}

/*cálculo para a altura*/

CalculaP (distSensor6, 100)




vMotor4 +=Output*fatorE4;

/*cálculos para a estabilidade*/

CalculaP (pitch,0);





CalculaP (roll,0);





95

E.4 ALGORITMO DE CONTROLE – POUSO

/*joga setpoint = 5 (altura de segurança = 5cm) então manda resposta pros motores

*/

CalculaP(distsensor6, 5)

vMotor1 -= Output*fatorD1;




/*quando chega em 5cm, vai desacelerando pra ir pro chao*/

while (distsensor6<=5){

vMotor1 -= fatorD1;

vMotor2 -= fatorD2;

vMotor3 -= fatorD3;

vMotor4 -= fatorD4;

}

/*Estabilidades*/

CalculaP (pitch,0);





CalculaP (roll,0);





96

E.5 ALGORITMO CONTROLE – SUBIR

Int velocidade = getVelocidade(); /*armazena a velocidade*/

/*vai aumentando os motores para começar a subir. Depois fica só mantendo a

estabilidade (5cm de margem de segurança*/

/*distEst é uma variável que guarda a altura antes de cada movimento*/

While(distSensor6 < (distEst +5)){

vMotor1 += fatorSD1*velocidade; //motores da frente

vMotor2 += fatorSD2*velocidade;

vMotor3 += fatorSD3*velocidade; //motores de trás

vMotor4 += fatorSD4*velocidade;

}

/*Mantêm estabilidades*/

CalculaP (pitch,0);





CalculaP (roll,0);





97

E.6 ALGORITMO DE CONTROLE – DESCER


/*vai diminuindo os motores para começar a descer. Depois fica só mantendo a

estabilidade (5cm de margem de segurança*/

/*distEst é uma variável que guarda a altura antes de cada movimento*/

While(distSensor6 > (distEst -5)){

vMotor1 -= fatorSD1*velocidade; //motores da frente

vMotor2 -= fatorSD2*velocidade;

vMotor3 -= fatorSD3*velocidade; //motores de trás

vMotor4 -= fatorSD4*velocidade;

}

/*Mantêm estabilidades*/

CalculaP (pitch,0);





CalculaP (roll,0);





98

E.7 ALGORITMO DE CONTROLE – FRENTE/TRÁS


/*angObjetivo é a variável que vai definir a inclinação do quadricóptero para

efetuar o movimento*/

Int angObjetivo = velocidade*fatorFT;

CalculaP (pitch,angObjetivo);





/*mantêm estabilidades do roll e da altura*/

CalculaP (roll,0);





CalculaP(distSensor6, alturaEst); //mantêm a altura

vMotor1 = +Output*fatorA1;




99

E.8 ALGORITMO DE CONTROLE – ESQUERDA/DIREITA


/*angObjetivo é a variável que vai definir a inclinação do quadricóptero para

efetuar o movimento*/

Int angObjetivo = velocidade*fatorFT;

CalculaP (roll,angObjetivo);





/*mantêm estabilidades do pitch e da altura*/

CalculaP (pitch,0);










100

E.9 ALGORITMO DE CONTROLE – GIRAR SENTIDO HORÁRIO

Int velocidade = getVelocidade();

Int accelObj = velocidade*fatorACC;

/*calcula P para que busque uma velocidade em torno do eixo Z, de acordo com

a velocidade*/

calculaP (gyroZ, accelObj);

vMotor1 += Output*fatorR1;

vMotor3 += Output*fatorR3; //gira no sentido horário

vMotor2 -= Output*fatorR2;


/*mantêm estabilidades do Roll, Pitch e altura*/

CalculaP (pitch,0);





CalculaP (roll,0);










101

E.10 ALGORITMO DE CONTROLE – GIRAR SENTIDO ANTIHORÁRIO

Int velocidade = getVelocidade();

Int accelObj = velocidade*fatorACC;

/*calcula P para que busque uma velocidade em torno do eixo Z, de acordo com

a velocidade*/

calculaP (gyroZ, accelObj);


vMotor3 -= Output*fatorR3; //gira no sentido anti-horário



/*mantêm estabilidades do Roll, Pitch e altura*/

CalculaP (pitch,0);





CalculaP (roll,0);










102

APÊNDICE F – DIAGRAMA DE ESTADOS DO SISTEMA EMBARCADO

QUADRICÓPTERO INVESTIGADOR - dainf.ct.utfpr.edu.brfabro/IF66J/Relatorios_Finais/2013_2... · E.9...

Documents

Transcript of QUADRICÓPTERO INVESTIGADOR - dainf.ct.utfpr.edu.brfabro/IF66J/Relatorios_Finais/2013_2... · E.9...