quadricÓptero investigador - dainf.ct.utfpr.edu.brfabro/if66j/relatorios_finais/2013_2... · e.9...
TRANSCRIPT
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 19 - Demonstração dos botões. ..................................................................... 52
Figura 20 - Demonstração dos botões. ..................................................................... 52
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.
Requisito Especificação técnica
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
Requisito Especificação técnica
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.
RF04 – O software da estação base deverá permitir ao usuário visualizar
os dados do acelerômetro desde que esteja estabelecida a conexão entre
a estação base e o Quadricóptero.
RF05 – O software da estação base deverá permitir ao usuário visualizar
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.
o RF07.2 – O software da estação base deverá permitir ao usuário
enviar um comando para que o Quadricóptero desça.
o RF07.3 – O software da estação base deverá permitir ao usuário
enviar comandos para o Quadricóptero ir para frente.
o RF07.4 – O software da estação base deverá permitir ao usuário
enviar comandos para o Quadricóptero ir para trás.
o RF07.5 – O software da estação base deverá permitir ao usuário
enviar comandos para o Quadricóptero ir para a esquerda.
o RF07.6 – O software da estação base deverá permitir ao usuário
enviar comandos para o Quadricóptero ir para a direita.
o RF07.7 – O software da estação base deverá permitir ao usuário
enviar um comando de rotação do Quadricóptero no sentido
horário.
o RF07.8 – O software da estação base deverá permitir ao usuá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
Ator principal Usuário
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
Ator principal Usuário
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.
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 os respectivos comandos aos motores.
Quadro 6 - Caso de Uso: Decolar.
Nome Pousar
Ator principal Usuário
Atores secundários Motores
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.
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 os respectivos comandos aos motores.
Quadro 7 - Caso de Uso: Pousar.
45
Nome Mover para frente
Ator principal Usuário
Atores secundários Motores
Sensores
Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para frente.
Pré-condições
A estação base precisa estar conectada ao quadricóptero.
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.
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 os respectivos comandos aos motores.
Quadro 8 - Caso de Uso: Mover para frente.
Nome Mover para trás
Ator principal Usuário
Atores secundários Motores
Sensores
Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para trás.
Pré-condições
A estação base precisa estar conectada ao quadricóptero.
O quadricóptero precisa estar parado.
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.
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 os respectivos comandos aos motores.
Quadro 9 - Caso de Uso: Mover para trás.
46
Nome Mover para direita
Ator principal Usuário
Atores secundários Motores
Sensores
Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para direita.
Pré-condições
A estação base precisa estar conectada ao quadricóptero.
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 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.
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 os respectivos comandos aos motores.
Quadro 10 - Caso de Uso: Mover para direita.
Nome Mover para esquerda
Ator principal Usuário
Atores secundários Motores
Sensores
Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para esquerda.
Pré-condições
A estação base precisa estar conectada ao quadricóptero.
O quadricóptero precisa estar parado.
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.
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 os respectivos comandos aos motores.
Quadro 11 - Caso de Uso: Mover para esquerda.
47
Nome Subir
Ator principal Usuário
Atores secundários Motores
Sensores
Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para cima.
Pré-condições
A estação base precisa estar conectada ao quadricóptero.
O quadricóptero precisa estar parado.
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.
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 os respectivos comandos aos motores.
Quadro 12 - Caso de Uso: Subir.
Nome Descer
Ator principal Usuário
Atores secundários Motores
Sensores
Resumo Este caso de uso descreve as etapas percorridas pelo usuário para mover o quadricóptero para baixo.
Pré-condições
A estação base precisa estar conectada ao quadricóptero.
O quadricóptero precisa estar parado.
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.
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 os respectivos comandos aos motores.
Quadro 13 - Caso de Uso: Descer.
48
Nome Rotacionar no sentido horário
Ator principal Usuário
Atores secundários Motores
Sensores
Resumo Este caso de uso descreve as etapas percorridas pelo usuário para rotacionar o quadricóptero no sentido horário.
Pré-condições A estação base precisa estar conectada ao quadricóptero.
O quadricóptero precisa estar parado.
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.
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 os respectivos comandos aos motores.
Quadro 14 - Caso de Uso: Rotacionar no sentido horário.
Nome Rotacionar no sentido anti-horário
Ator principal Usuário
Atores secundários Motores
Sensores
Resumo Este caso de uso descreve as etapas percorridas pelo usuário para rotacionar o quadricóptero no sentido anti-horário.
Pré-condições A estação base precisa estar conectada ao quadricóptero.
O quadricóptero precisa estar parado.
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.
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 os respectivos comandos aos motores.
Quadro 15 - Caso de Uso: Rotacionar no sentido anti-horário.
49
Nome Selecionar velocidade
Ator principal Usuário
Atores secundários Motores
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
A estação base precisa estar conectada ao quadricóptero.
O quadricóptero precisa estar no ar.
O quadricóptero precisa estar parado.
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
Figura 19 - Demonstração dos botões. Fonte: Autoria própria.
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.
Figura 20 - Demonstração dos botões. Fonte: Autoria própria.
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
de trabalho R$ 4.200,00
Terceiro entregável do projeto – Custos com horas
de trabalho R$ 4.200,00
Quarto entregável do projeto – Custos com horas
de trabalho R$ 4.200,00
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
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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).
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
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.
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: 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:
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
80
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
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.
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, 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:
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
81
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
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.
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: 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:
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
82
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
Explique: A desistência de um membro da equipe afeta totalmente o cronograma e a distribuição de tarefas para cada integrante.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
Explique: Pela conversa que houve entre os integrantes da equipe, nenhum pretende desistir.
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: 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:
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
83
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
Explique: A probabilidade é baixa, levando em consideração as conversas realizadas entre a equipe.
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: 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.
Impacto reavaliado: 3 (médio) Probabilidade reavaliada: 1 (baixa)
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
84
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
Denominação do risco: Erro de planejamento
N Identificação:
07
Descrição do risco: Cronograma mal planejado.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
Explique: Devido à inexperiência da equipe em especificação de cronogramas, a probabilidade é elevada.
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: 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:
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
85
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
Explique: A probabilidade de doenças sempre existe, pois não há nada que possa ser feito com relação a isso.
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: 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:
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
86
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
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.
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: 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:
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
87
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
Explique: Os componentes podem ocorrer principalmente devido a falta de atenção no seu manuseio.
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: 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:
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
88
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
Explique: A maioria dos componentes a serem utilizados no projeto tem caráter ordinário, podendo ser facilmente encontrado para substituição.
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: 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.
Impacto reavaliado: 3 (médio) Probabilidade reavaliada: 1 (baixa)
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
89
Projeto: Quadricóptero Investigador
1 Etapa: Identificação do Risco
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.
2 Etapa: Avaliação do Risco
Impacto: 5(alto) 4(médio/alto) 3(médio) 2(médio/baixo) 1(baixo)
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.
Probabilidade: 5(alta) 4(média/alta) 3(média) 2(média/baixa) 1 (baixa)
Explique: Todos os membros cursam outras disciplinas, estando certamente sujeitos a entrarem em semana de provas.
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: 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:
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
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;
vMotor2 += Output*fatorA2;
vMotor3 += Output*fatorA3;
vMotor4 += Output*fatorA4;
/*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
vMotor4 -= Output*fatorE4;
vMotor2 += Output*fatorE2; //motores da direita
vMotor3 += Output*fatorE3;
}
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)
vMotor1 += Output*fatorE1;
vMotor2 += Output*fatorE2;
vMotor3 += Output*fatorE3;
vMotor4 +=Output*fatorE4;
/*cálculos para a estabilidade*/
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
vMotor4 -= Output*fatorE4;
vMotor2 += Output*fatorE2; //motores da direita
vMotor3 += Output*fatorE3;
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;
vMotor2 -= Output*fatorD2;
vMotor3 -= Output*fatorD3;
vMotor4 -= Output*fatorD4;
/*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);
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
vMotor4 -= Output*fatorE4;
vMotor2 += Output*fatorE2; //motores da direita
vMotor3 += Output*fatorE3;
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);
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
vMotor4 -= Output*fatorE4;
vMotor2 += Output*fatorE2; //motores da direita
vMotor3 += Output*fatorE3;
97
E.6 ALGORITMO DE CONTROLE – DESCER
Int velocidade = getVelocidade(); /*armazena a velocidade*/
/*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);
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
vMotor4 -= Output*fatorE4;
vMotor2 += Output*fatorE2; //motores da direita
vMotor3 += Output*fatorE3;
98
E.7 ALGORITMO DE CONTROLE – FRENTE/TRÁS
Int velocidade = getVelocidade(); /*armazena a velocidade*/
/*angObjetivo é a variável que vai definir a inclinação do quadricóptero para
efetuar o movimento*/
Int angObjetivo = velocidade*fatorFT;
CalculaP (pitch,angObjetivo);
vMotor1 -= Output*fatorE1; //motores da frente
vMotor2 -= Output*fatorE2;
vMotor3 += Output*fatorE3; //motores de trás
vMotor4 += Output*fatorE4;
/*mantêm estabilidades do roll e da altura*/
CalculaP (roll,0);
vMotor1 -= Output*fatorE1; //motores da esquerda
vMotor4 -= Output*fatorE4;
vMotor2 += Output*fatorE2; //motores da direita
vMotor3 += Output*fatorE3;
CalculaP(distSensor6, alturaEst); //mantêm a altura
vMotor1 = +Output*fatorA1;
vMotor2 = +Output*fatorA2;
vMotor3 = +Output*fatorA3;
vMotor4 = +Output*fatorA4;
99
E.8 ALGORITMO DE CONTROLE – ESQUERDA/DIREITA
Int velocidade = getVelocidade(); /*armazena a velocidade*/
/*angObjetivo é a variável que vai definir a inclinação do quadricóptero para
efetuar o movimento*/
Int angObjetivo = velocidade*fatorFT;
CalculaP (roll,angObjetivo);
vMotor1 -= Output*fatorE1; //motores da esquerda
vMotor4 -= Output*fatorE4;
vMotor2 += Output*fatorE2; //motores da direita
vMotor3 += Output*fatorE3;
/*mantêm estabilidades do pitch e da altura*/
CalculaP (pitch,0);
vMotor1 -= Output*fatorE1; //motores da frente
vMotor2 -= Output*fatorE2;
vMotor3 += Output*fatorE3; //motores de trás
vMotor4 += Output*fatorE4;
CalculaP(distSensor6, alturaEst); //mantêm a altura
vMotor1 = +Output*fatorA1;
vMotor2 = +Output*fatorA2;
vMotor3 = +Output*fatorA3;
vMotor4 = +Output*fatorA4;
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;
vMotor4 -= Output*fatorR4;
/*mantêm estabilidades do Roll, Pitch e altura*/
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
vMotor4 -= Output*fatorE4;
vMotor2 += Output*fatorE2; //motores da direita
vMotor3 += Output*fatorE3;
CalculaP(distSensor6, alturaEst); //mantêm a altura
vMotor1 = +Output*fatorA1;
vMotor2 = +Output*fatorA2;
vMotor3 = +Output*fatorA3;
vMotor4 = +Output*fatorA4;
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);
vMotor1 -= Output*fatorR1;
vMotor3 -= Output*fatorR3; //gira no sentido anti-horário
vMotor2 += Output*fatorR2;
vMotor4 += Output*fatorR4;
/*mantêm estabilidades do Roll, Pitch e altura*/
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
vMotor4 -= Output*fatorE4;
vMotor2 += Output*fatorE2; //motores da direita
vMotor3 += Output*fatorE3;
CalculaP(distSensor6, alturaEst); //mantêm a altura
vMotor1 = +Output*fatorA1;
vMotor2 = +Output*fatorA2;
vMotor3 = +Output*fatorA3;
vMotor4 = +Output*fatorA4;
102
APÊNDICE F – DIAGRAMA DE ESTADOS DO SISTEMA EMBARCADO