Recriação de um Cockpit para Pilotos Amadores

LABSIS

2019

Autores:

Gonçalo Marinho dos Santos (Nº 1170582)

1170582@isep.ipp.pt

João Paulo Carvalho da Silva Alves (Nº 1170779)

1170779@isep.ipp.pt

Introdução

Arquitetura

Hardware

Software

Resultados

Conclusões

Referências

• Introdução

Início

   No âmbito da disciplina "Laboratório de Sistemas", foi-nos proposto o desenvolvimento e implementação de um protótipo funcional utilizando um microcontrolador com o requisito mínimo ter um LED a piscar à frequência de 1 Hz.

- Descrição do trabalho e Objectivos:

   Neste projeto pretende-se recriar as funcionalidades básicas de um cockpit de uma aeronave comercial, usando o simulador Microsoft Flight Simulator X e o programa Link2fs como ponte de comunicação entre o simulador e o projeto desenvolvido. Numa fase inicial foram simuladas as diversas tarefas do painel de instrumentação tais como a ativação dos flaps e spoilers, o uso do trem de aterragem, a ativação de luzes, o travão de estacionamento, e em caso de necessidade a alternância de pausa e resumo do simulador.

   Posteriormente foi implementado um joystick para o controlo das diversas funcionalidades do piloto automático, em conjunção com um encoder, e o adicionamento de dois potenciômetros para o controlo do throttle dos motores, de forma a adicionar alguma complexidade e separação de tarefas ao projeto.

   Finalmente, implementou-se alguns tipos de alarmes, nomeadamente o de overspeed e o de stall com recurso a buzzers e o visualizamento da posição do trem de aterragem com o uso de leds, para aproximar a uma simulação mais imersiva.

- Estado da Arte

   Um cockpit é um ambiente de trabalho no qual o piloto tem à sua disposição diversos instrumentos e auxiliares de voo, também conhecidos como painel de instrumentos. Apesar da evolução tecnológica que tem havido, a indústria aeronáutica ainda possui e desenvolve painéis maioritariamente analógicos, para tal, a necessidade de criação de simuladores levou a um desenvolvimento tanto a nível profissional e industrial como a um nível do simples consumidor para lazer.

   A nível industrial, o uso destes simuladores é predominantemente para a formação de pilotos profissionais, nos quais a atenção ao minucioso detalhe é valorizado e quase sempre necessário, resultando num orçamento sem restrições e muitas vezes fora do alcance do utilizador recreativo. Em concordância com este objetivo em mente, os materiais utilizados na construção são usualmente de maior qualidade em contrapartida com os que vamos usar no nosso projeto como por exemplo, de maior dimensão (de não estranhar que muitos acabam por optar por construir uma fuselagem de cockpit e módulos inteiros para uma maior imersão) e com a certificação de entidades aeronáuticas.

   Como é exemplificado nas seguintes empresas, a primeira que especializa na construção e venda de módulos do painel de instrumentos de fácil uso, desenvolvidos para comunicar com simuladores no PC usando o software GF-Config para assegurar a sua compatibilidade, de maneira a obter uma experiência mais próxima do real possível. Um destes módulos é o painel de piloto automático [1] (figura 1), que tem como base interruptores eletrónicos e potenciómetros integrados num chassi de metal, que consoante os inputs do utilizador este vai ser traduzido como output no simulador. Com o preço de $489.00 denota – se um valor razoavelmente elevado em contraste com os materiais comuns usado pelo consumidor e entusiasta desta área.

Figura 1. Painel Piloto Automático MCP-Pro

   No entanto, tal como referido anteriormente, o maior público alvo destes simuladores são escolas de formação, e estas tendem a usar cockpits construídos de raiz análogos aos seus homólogos presentes em aviões comerciais (figura 2), possuindo os mesmos instrumentos que estes. Para tal, empresas como a Flightdeck Solutions [2] não só constroem e vendem para consumidores privados e escolas, mas também para companhias aéreas. Os diversos componentes passam por painéis com LEDS integrados controlados por dimmers [3], aceleradores fornecidos automaticamente por um solenoide [4] e PCBS [5] desenvolvidos por eles próprios que servem como comunicação direta com o software desejado para efetuar a simulação.

   Figura 2. Painel de Instrumentos FDS-B737NG-MX-DSTD

   A nível do cliente, são vários os fãs de aviação que tanto compram como constroem os seus próprios módulos, basta um pouco de ingenuidade para conseguir construir um cockpit fiel e de custo relativamente acessível. Em termos de componentes usados muitos dos projetos seguem um certo padrão: um ou mais microcontroladores, uma ligação em série que normalmente é facilitada devido ao uso do Arduíno com o microcontrolador desejado. O resto fica dependente do que o utilizador deseja para simular quer seja um joystick para controlar a direção do avião, pedais para controlar o leme ou um módulo para simular o piloto automático à base de interruptores.

   Temos como título de exemplo os seguintes projetos feitos pela mesma pessoa em que numa primeira fase não se sentia satisfeita com os dispositivos disponibilizados e que decidiu desenvolver um cockpit com vários componentes integrados uns com os outros [6].

   Os materiais usados nunca vão além do referido anteriormente, um Arduíno com o microcontrolador integrado e que posteriormente iria ser usado como ponte de ligação entre o hardware (interruptores e potenciómetros) e o software (passagem dos dados para que o computador possa interpretá-los decentemente). Em conclusão este primeiro projeto conseguiu cumprir o desejado apesar de uma fraca resposta e imprecisão do joystick e dos pedais (figura 3).

Figura 3. 1º Projeto do Simulador

   O projeto posterior entrou em muito detalhe [7], com várias adições e melhoramentos, nomeadamente a adição de um extra Arduíno, a troca do joystick por um volante e vários interruptores e potenciómetros para simular um cockpit de um avião Cessna 172 (figura 4).

   Para a comunicação com o PC, os Arduínos foram usados como emuladores para o joystick de modo a retornar os dados dos interruptores como valores de botões e do potenciómetro como valores, e iria analisar os cliques do encoder e retornar esse número como um valor. De seguida, foi usado um script Lua para aceder aos registos no software Prepar3d para usar os componentes no simulador corretamente.

Figura 4. 2º Projeto do Simulador

• Arquitetura

Início

   Neste projeto, no âmbito de promover um consolidamento dos conhecimentos adquiridos ao longo da licenciatura, foi feito um estudo de modo a congregar o maior número de atuadores, passando por botões, potenciômetros e um encoder, e de alarmes, leds e buzzers.

   Como pode ser observado (figura 5), o projeto está dividido em 2 módulos que se encontram numa comunicação bidirecional (inputs-simulador-outputs), um responsável para mandar os comandos ao simulador,o módulo dos inputs (ATmega88) e o outro para receber as extrações deste, o módulo dos outputs (ATmega168p), ambos fazendo proveito da comunicação série e do programa Link2fs para interagir com o simulador.

Figura 5. Arquitetura do Projeto

• Hardware

Início

- Microcontrolador:

   Os microcontroladores usados neste trabalho foram o ATmega88 e o ATmega168p, ambos pertencendo à mesma familia de AVR de 8 bits, em que partilham a mesma arquitetura nos pinos (figura 6), funcionam com uma frequência de fábrica de 1 MHz, com a possível implementação de timers e comunicação USART, diferenciando - se apenas na memória de cada um (ATmega88-8KBytes/ATmega168p-16KBytes) e no tamanho do vetor das interrupções (ATmega88-1 palavra de instrução por vetor/ATmega168p-2 palavras de instrução por vetor) [8].

Figura 6. Pinout do ATmega88/168p

- Cristais Externos:

   Tal como referido anteriormente, os microcontroladores inicialmente estavam configurados com uma frequência de fábrica de 1 MHz, no entanto, tendo em mente que estes seriam usados em conjunto com o programa Link2fs (o qual entraremos em detalhe mais adiante) para possibilitar a comunicação com o simulador. Para tal é necessário alterar a frequência dos dois microcontroladores para 16 MHz.

   Consequentemente, decidiu - se implementar um cristal externo de 16 MHz em paralelo com 2 condensadores de 22pF (figura 7), recorrendo aos dados do fabricante na datasheet, a uma calculadora online [9] para determinar os comandos necessários a alterar nos fuses do ATmega88 e ATmega168p e o programa AVRDUDE para efetuar as alterações necessárias nestes.

Figura 7. Montagem do Cristal e componentes implementados

- FTDI:

   Para os microcontroladores serem capazes de comunicar com o programa Link2fs, foi necessário adquirir conversores FTDI (figura 8), que tem como propósito habilitar a conversão da comunicação série USART para o protocolo USB e vice-versa. Para além disso, aproveitou - se os +5 V que os conversores disponibilizam para alimentar o circuito implementado. Com o auxílio deste dispositivo poderemos assim enviar os dados necessários para que o Link2fs comunique corretamente para com o simulador.

Figura 8. FTDI

- Botões/Switches:

   Como base do projeto, para simular as funcionalidades mais básicas do módulo dos inputs de um cockpit, foram implementados botões de pressão (figura 9), que baseiam - se em alterar o nível lógico de 0 para 1 num certo pino [10], aquando pressionado, fazendo, assim, a connecção entre os extremos, connectando aos +5 V fornecidos. Essa alteração depois será recebida pelo microcontrolador e, dependendo do pino utilizado, será efetuada uma resposta no simulador. É-se aconselhado o uso de resistências de 10k Ohms.

Figura 9. Botões/Switches

- Potenciômetros:

   De seguida, para a implementação do controlo do throttle dos motores, foram usados potenciômetros de 2.2 K Ohms (figura 10), possuindo 3 pinos, os dos extremos ligados à massa e à fonte de alimentação e o do meio que será connectado ao microcontrolador e que tem como base a variação da sua resistência interna, variação essa que vai mudar a queda de tensão ao microcontrolador e a sua respetiva resposta no simulador consoante a medida de tensão analógica.

Figura 10. Potenciômetros

- Joystick:

   Com o objetivo inicial de controlar o avião no simulador recorrendo aos seus ailerons, rudder e elevator, foi idealizado a implementação do módulo KY-023 Joystick (figura 11). Infelizmente, à medida que o nosso estudo sobre o Link2fs era aprofundado, chegou - se à conclusão que esta implementação não seria possível pois o progama não possui as funcionalidades que seriam necessárias para esse nível de controlo. Tendo isto em mente, e após consultarmos o nosso docente, foi decidido implementar este módulo no controlo das funcionalidades do piloto automático, nomeadamente no controlo do heading e da altitude.

   Este componente possui 5 pinos em que, tal como os restantes, possui um que se liga à massa do circuito (GND), outro que se liga à fonte de alimentação (VCC), um que se trata de um botão (SW), e outros dois, os pinos VRX e VRY, que são ligados ao microcontolador e que têm como base 2 potenciômetros de 10 K Ohms, posicionados perpendicularmente, capazes de controlar os eixos do X e Y consoante a variação das suas respetivas resistências internas [11].

Figura 11. Joystick

- Encoder:

   Foi utilizado o encoder KY-040 (figura 12) que possui 5 pinos, 2 para a massa e alimentação, 1 switch e finalmente os dois pinos que caracterizam o seu funcionamento CLK e DT. Esses últimos enviam impulsos de onda quadrada desfasados a 90º graus entre eles. Tanto o pino CLK como o pino DT podem ser responsáveis pela determinação da posição gerada pelos pulsos do sinal, contudo para saber em qual direção é que está a ser rodado, é necessário serem ambos os impulsos dos pinos comparados [12].

Figura 12. Encoder

- Buzzers:

   No módulo de outputs, anteriormente referido, o qual seria capaz de receber as extrações do Link2fs, fez se aproveito de buzzers (figura 13) para indicar que a resposta ao estado do avião no simulador era recebida, nomeadamente em 2 alarmes, quando a aeronave ultrapassa-se a velocidade máxima permitida (alarme de overspeed) e quando esta alcança-se uma velocidade muito baixa (alarme de stall).

   Este sistema foi usado com 2 buzzers de 3 pinos, o do meio e um dos extremos para conectar, respetivamente, à fonte de alimentação e à massa, e o do outro extremo para emitir a onda sonora. No entanto, eles divergem nas suas ondas, um deles emite uma onda quadrada (som idêntico aos impulsos de um relógio analógico), que será ativada continuamente com a variação do nível lógico de 0 para 1, enquanto que o outro emite um som agudo contínuo ao ser alimentado.

Figura 13. Buzzer

- Leds:

   Adicionalmente foi implementado um led vermelho (figura 14) a piscar a uma frequência de 1 Hz, e, ainda no módulo de outputs, de modo a se possibilitar uma visualização da ação do botão do trem de aterragem no módulo de input, referido anteriormente, foram implementados leds vermelhos, significando que o trem de aterragem está retraído, amarelos, quando este está em transição, e verdes, ao estarem completamente estendidos. Tendo em atenção o uso complementar de resistências de 330 Ohms para os leds serem alimentados com uma corrente de 10 miliamperes [13].

Figura 14. Leds

- Esquemático:

Figura 15. Esquemático do Circuito do módulo dos Inputs

Figura 16. Esquemático do Circuito do módulo dos Outputs

- PCB:

Figura 17. Placa de Circuito Impresso do módulo dos Inputs

Figura 18. Placa de Circuito Impresso do módulo dos Outputs

• Software

Início

- Link2fs:

   Servindo como uma das bases mais importantes deste projeto, o Link2fs (figura 19) é um programa desenvolvido por um ávido entusiasta do simulador Microsoft Flight Simulator X, criado em 2011 com o propósito de habilitar a comunicação e troca de informação entre o Arduino e o simulador e vice-versa, possibilitando tanto inputs e outputs, viabilizando o uso de diversos métodos, como botões, encoders, entre outros [14]. No entanto, deparámos com uma limitação neste programa, este como foi desenvolvido com o uso de Arduino em mente, só funciona com dispositivos a trabalhar a uma de frequência de 16 MHz com um baudrate de 115200, daí a implementação dos cristais externos, referidos anteriormente.

Figura 19. Interface do Link2fs

   O princípio deste processo é relativamente simples, uma string, associada a um certo código, é enviada pela porta USB, esta mesma é depois recebida pelo Link2fs, efetuando no simulador a sua respetiva ação. Nas extrações a lógica é a mesma, a única diferença sendo que agora é ao contrário, a ação vai transmitir o seu código associado em forma de string pela porta USB. Na tabela abaixo (figura 20) estão apresentados os diversos códigos usados no decurso neste projeto e os seus respetivos significados:

Figura 20. Códigos usados e seus respetivos significados

 - Função "send_message()"

   A função "send_message()" é, sem margem de dúvida, a função mais importante e crucial neste projeto, pois esta é que vai possibilitar a comunicação com o programa Link2fs, estando todas as restantes funções dependentes desta.

   A comunicação com o programa, tal como referida anteriormente, funciona à base de envio de strings, logo, a função vai, num ciclo, verificar se a string chegou ao fim antes de a enviar. Se esta condição não se verificar, então esta vai certificar, em ciclo, que o "UDR0" (USART DATA REGISTER), variável responsável pelo envio das strings, está vazio.

Figura 21. Fluxograma da função "send_message()"

- Módulo dos Inputs:

 - Inicializações:

    No módulo dos inputs foi usado, em termos de interrupções, o Timer0, de modo a obter um tempo de 1.204 ms, o USAR_RX_VECT de modo a obter um baud rate de 115200 e as 2 interrupções externas disponibilizadas pelo microcontrolador (INT0 e INT1). Para finalizar, foi inicializado o ADC, começando este no ADC1 (figura 22).

Figura 22. Inicializações do Módulo dos Inputs

 - Função "main()"

    O programa inicia o processo principal na função "main()" chamando a função das inicializações antes de entrar no ciclo principal. Neste ciclo são invocadas 4 funções: a função "switchadc()", responsável pela conversão dos valores analógicos dos potenciómetros e do joystick em valores digitais, a função "func_e1e2()", responsável pela leitura do valor final dos potenciômetros e o envio do seus respetivos códigos para o Link2fs, a função "func_joystick()", responsável pela leitura do valor final do dispositivo e o envio dos seus respetivos códigos para o Link2fs e a função "func_botoes()", responsável pela leitura do nível lógico de cada pino associado a cada botão e o envio dos seus respetivos códigos para o Link2fs.

Figura 23. Fluxograma da função "main()"

  - Função "switchadc()":

     A função "switchadc()", tal como foi referida anteriormente, é responsável pela conversão analógica para digital dos potenciômetros e do joystick, efetuando um ciclo de verificação de 20 leituras, de modo a reduzir futuras imprecisões ou discrepâncias com o auxílio da função "adc()". Para tal foram usados 4 pinos de ADC do microcontrolador, um para cada componente, o ADC1 para o pino VRX do joystick, o ADC0 para o pino VRY do joystick, o ADC2 para o pino do potenciômetro 1 e o ADC3 para o pino do potenciômetro 2, fazendo uso da flag "trocador", para indicar qual conversão está a ser efetuada.

     Posteriormente, no final das 20 leituras de cada componente, é efetuada a média.

Figura 24. Fluxograma da função "switchadc()"

   - Função "adc()":

      A função "adc()" vai ser responsável pela verificação se a conversão já foi efetuada, realizando um ciclo até esta condição se verificar, e que, depois, consoante o valor indicado pela flag "trocador", irá converter o valor analógico em digital e armazenar este nas varíaveis correspondentes a cada componente (x-VRX do joystick/y-VRY do joystick/E1-potenciômetro 1/E2-potenciômetro 2).

Figura 25. Fluxograma da função "adc()"

  - Função "func_e1e2()":

     Após passarem 300 ms (flag0 = 1) entre cada leitura, vai-se ser efetuada a conversão do valor digital, obtido da função "switchadc()", para percentagem de cada um dos potenciômetros e o envio, recorrendo à função "send_message()", dos respetivos valores finais para o programa Link2fs.

Figura 26. Fluxograma da função "func_e1e2()"

  - Função "func_joystick()":

     A função "func_joystick()" vai buscar os valores obtidos da função "switchadc()" armazenados nas variáveis "adcx" e "adcy", estabelecendo, de início, um conjunto de parâmetros necessários antes de serem enviados os dados para o simulador. Em primeiro lugar, apesar da posição neutra do joystick corresponder a 512 na conversão, foi estipulado ,que de forma a reduzir potenciais ruídos, devesse existir um espaço entre o valor da posição neutra e o valor em que o programa reconheça o movimento provocado pelo utilizador, daí a existência dos valores 542 e 480. Em segundo lugar, o valor da altitude enviada ao programa nunca pode ser negativa, sempre que atinja esse pormenor o valor da variável "altitude" é reconfigurado como 0. Por fim, uma vez que a direção (ou heading) é reconhecida pelo avião como uma circunferência com os ângulos marcados no cockpit, é obrigatório criar 2 condições de forma convencer o programa de que estamos utilizar uma incrementação ou decrementação cíclica em que, caso a direção desca para valores negativos continue a ocorrer essa decrementação apartir de 360º. O contrário terá de ser estipulado na qual se ultrapassar os 360º começa no 1º e adiante. A informação é enviada em cada 100 ms de forma a reduzir a poluição visual no Link2fs e entender o que está a ser enviado.

Figura 27. Fluxograma da função "func_joystick()"

  - Função "func_botoes()":

     A função "func_botoes()", vai, inicialmente, averiguar se qualquer um dos botões é pressionado, com um intervalo de 200 ms, tempo definido pela flag "flag1" na interrupção Timer0, e se essa condição se verificar, envia, recorrendo à função "send_message()", a respetiva string. No entanto, no caso dos botões dos flaps e dos spoilers há uma condição adicional que tem que ser verificada, as condições das flags "contador_spoiler" e "contador_flap", flags, usadas na interrupção USAR_RX_VECT, responsáveis para atualizar a posição de cada um destes elementos consoante o que é recebido do Link2fs, além dessas flags temos as variáveis "separador" (para os flaps) e "separador1" (para os spoilers) para indicar ao programa que caso o botão seja pressionado, a posição tanto dos flaps como dos spoilers está em transição. Por fim, nos botões das luzes de painel e de aterragem, utiliza - se as flags "contador_landing" e "contador_painel" como um simples interruptor.

Figura 28. Fluxograma da função "func_botoes()"

 - Interrupção Timer0:

    A interrupção Timer0 vai ser responsável pela incrementação dos contadores de modo a obter os intervalos de tempos, de cada leitura, usados nas funções "func_e1e2()" (contador0), "func_botoes()" (contador1) e "func_joystick()" (contador2), ativando a suas respetivas flags.

Figura 29. Fluxograma da interrupção Timer0

 - Interrupção USAR_RX_VECT:

    A interrupção USAR_RX_VECT é sempre ativada quando o microcontrolador recebe um caráter, guardando-o numa string, de seguida, essa vai ser verificada para ver se se encontra numa situação em que os flaps ou os spoilers foram pressionados e se, anteriormente, foi recebida uma string a confirmar a sua receção ("<h" e/ou "<G"). Associados a estes carateres são esperados 3 algarismos, daí, a realização de uma espera de 3 ciclos nessa sub rotina. Após esta espera são retirados esses mesmos algarismos e tanto a string como a variável das leituras são reiniciadas. A partir daí é efetuada a comparação para saber em qual estado se encontra, reiniciando as flags "flag9", "c", "separador" e "separador1" e, consoante o resultado da variável "h", que significa o estado em que o flap ou spoiler se encontram depois da interação com os botões, esse valor vai ser usado futuramente. A próxima etapa certifica se, em primeiro lugar, que tanto o flap e o spoiler, se encontram em um dos extremos (000 ou 100), e se tal for verdade é possibilitada a transição entre eles (flag == 1), em que caso o utilizador pressione o botão, possibilite a comparação e, se se confirmar, ativa a "flag9", que significa que está ocorrer uma transição.

    A última decisão, é na realidade a primeira quando o código é processado pela primeira vez, que consiste em confirmar em qual posição o flap e o spoiler se encontram, e que, caso estejam nos extremos, seja ativada a variável "flag" e as flags "contador_flap" e "contador_spoiler", que ,consoante o seus valores, irão transmitir a direção que, tanto o flap e o spoiler, vão ter que percorrer.

Figura 30. Fluxograma da interrupção USAR_RX_VECT

 - Interrupção INT0:

    A interrupção externa INT0 é responsável pelo funcionamento do encoder, armazenando o estado dos pinos deste, PC4 e PC5, nas variáveis "ticks" e "dir", efetuando a atualização destas, inicialmente com a comparação da variável "tick" com a variável "oldtick", sempre que ocorrer uma mudança no encoder, seguido da comparação da variável "dir" com a variável "tick" para determinar o sentido em que o encoder está a ser rodado, armazenando essa informação na flag "contificador", fazendo, ainda, um reset quando este for menor que 0 de modo a evitar valores negativos. De seguida, essa informação é enviada, recorrendo à função "send_message()", para o programa Link2fs, finalizando com uma última atualização do valor da variável "oldtick" com o valor mais recente armazenado na variável "tick".

Figura 31. Fluxograma da interrupção INT0

 - Interrupção INT1:

    A interrupção externa INT1 vai assegurar o correto debouncing ao pressionar o botão associado à pausa do simulador, visto que este tipo de interrrupção não entra em conflito com o programa principal e não é sujeito ao uso do Timer0 como acontece aos restantes butões na função "func_botoes()".

Figura 32. Fluxograma da interrupção INT1

- Módulo dos Outputs:

 - Inicializações:

   No módulo dos outputs foi usado, em termos de interrupções, o Timer0, de modo a obter um tempo de 1.204 ms, e o USAR_RX_VECT de modo a obter um baud rate de 115200 (figura 33). Para além disso, foram inicializados os bits dos ports PC5, PC4, PC3 como saídas.

Figura 33. Inicializações do Módulo dos Outputs

 - Função "main()":

    O programa inicia o processo principal na função "main()" chamando a função das inicializações antes de entrar no ciclo principal. Neste ciclo é invocada a função "gear()", responsável pela leitura das strings, associadas ao trem de aterragem, do Link2fs e demonstrar essa informação com a ativação dos respetivos leds.

Figura 34. Fluxograma da função "main()"

  - Função "gear()":

     A função "gear()" funciona apartir de uma técnica de multiplexagem chamada de charlieplexing, que faz uso das seguintes qualidades do microcontrolador: Quando um port é programado como saída possui os seguintes estados: HIGH e LOW. Contudo quando o port é ativado como entrada, irá ficar com uma impendância elevada sendo a corrente que passa nessa entrada muito baixa [15]. Como poder ser observado na figura 35 a elevada impendância no port com a letra "Z" impede que passe corrente suficiente para ligar o LED da direita entre os ports "H" e "Z". Consequentemente a ligação elétrica entre os ports "H" e "L" permite o funcionamento normal do LED da esquerda. Para complementar o raciocínio o contrário é aplicado no seguimento da figura 35. Apesar de só um LED ter de ligar de cada vez isso foi resolvido com o recurso ao Timer0 por exemplo. Outro detalhe é que as resistências têm que teóricamente ser metade dos valores calculados uma vez que a corrente vai passar em 2 e não numa única.

Figura 35. Esquemático do charlieplexing

     O cálculo de quantos ports são precisos consoante o número de LEDS é feita com a seguinte expressão: n = Pn x (Pn-1), que "n" é o nº de LEDS e "Pn" a quantidade de ports necessários. Por isso com 3 ports, 3x(3-1)=6, o número máximo de LEDS é 6.

Figura 36. Montagem com recurso a charlieplexing [16]

     No programa em si, é se analisado o estado das flags "nosegear" e "winggear", com um intervalo de tempo de 10 ms (""flag0") entre ambas, que, com o recurso à interrupção USAR_RX_VECT, representam a posição do trem de aterragem no simulador, e, consoante o estado deste, irão ser ativados e desativados os leds, de acordo com o código de cores referido anteriormente.

Figura 37. Fluxograma da função "gear()"

 - Interrupção Timer0:

    A interrupção Timer0 vai ser responsável pela incrementação dos contadores de modo a obter os intervalos de tempos necessários para o funcionamento da função "gear()" (contador0), dos buzzers (contador1 usado para o buzzer overspeed e contador2 usado para o buzzer stall) e do led (contadorled). Somente no contador0 é ativada uma flag, enquanto que as decisões lógicas dos buzzers encontram-se dependentes com o que é recebido do Link2fs.

Figura 38. Fluxograma da interrupção Timer0

 - Interrupção USAR_RX_VECT:

    A interrupção USAR_RX_VECT é sempre ativada quando o microcontrolador recebe um caráter, guardando-o numa string, de seguida, essa vai ser verificada para ver se se encontra numa situação em que o botão do trem de aterragem foi pressionado e se, anteriormente, foi recebida uma string a confirmar a sua receção ("?Y"). Associado a este caráter é se esperado 3 algarismos, daí, a realização de uma espera de 3 ciclos nessa sub rotina. Após esta espera são retirados esses mesmos algarismos e tanto a string como a variável das leituras é reiniciada. A partir daí é efetuada a comparação para saber em qual estado se encontra, reiniciando a variável "flag" e, consoante o resultado das variáveis "winggear" e "nosegear", que significa o estado em que a roda do nariz e as rodas das asas se encontram depois da interação com o botão.

    Para além disso, é nesta interrupção que se efetua a análise da informação recebida do Link2fs referente aos buzzers, sendo o processo de receção da string associado a apenas 4 códigos ("?A0"/"?A1" e "<S0"/"<S1"), em que as flags de cada buzzer (flag1-referente ao buzzer overspeed e flag2-referente ao buzzer stall) vão ser manipuladas, de acordo com estes, e, em junção com o Timer0, ligar ou desligar os buzzers.

Figura 39. Fluxograma da interrupção USAR_RX_VECT

• Resultados

Início

Figura 40. Circuito Final

Vídeo 1. Módulo dos Flaps/Spoilers com botões

Vídeo 2. Módulo do Piloto Automático do Joystick e Encoder

Vídeo 3. Módulo do Throttle dos Motores com Potenciômetros

Vídeo 4. Módulo das Luzes de Aterragem

Vídeo 5. Módulo das Luzes do Painel

Vídeo 6. Módulo do Travão de Estacionamento

Vídeo 7. Módulo do Alarme de Overspeed

Vídeo 8. Módulo do Alarme de Stall

Vídeo 9. Módulo do Trem de Aterragem com Botão e Leds

• Conclusões

Início

   Como conclusão deste trabalho, podemos afirmar que conseguimos atingir os objetivos propostos e o produto final ficou de acordo com as nossas expetativas, sendo possível obter novos conhecimentos sobre hardware e programação relacionados com microcontroladores, sensores e atuadores e, além de que, acabámos por aprender bem a diferença entre o que se é planeado e o que realmente é possível de se concretizar, nomeadamente na adquirição, teste e a aplicação final de cada componente individual, todo este processo que acabou por demorar mais do que o previsto, sendo tempo para o estudo e implementação de outros componentes adicionais e o desenvolvimento da placa de circuito impresso, esta última também um pouco devido ao nosso relativo pouco conhecimento na construção destes, sacrificado.

   Em termos de problemas deparados no decurso deste projeto, o mais problemático foi as connecções, que por vezes, devido a mau contacto, interferiam no funcionamento dos componentes, apesar dos códigos do Link2fs serem detetados. Ainda assim, o programa não é isento de falhas, nomeadamente, na receção de strings, em que o programador tem que se certificar que os códigos irão ser comunicados pelo programa e assegurar a limpeza correta da variável que a armazena. Para além disso, como foram usados 2 microcontroladores, aquando o acontecimento desta falha referida anteriormente, era difícil efetuar o reset manualmente pelo ATMEL, devido há existência de um só USBASP e do nosso computador, onde foram efetuado os testes, só possuir 3 portas USB (2 para os FTDI's e a restante para o programador).

   Por fim, a continuação deste projeto, passaria por reforçar as ligações entre componentes, a implementação de outros (e.g. um LCD de modo a visualizar de melhor maneira os dados que são comunicados ao pilotos, um motor passo a passo para poder obter uma melhor visualização do comportamento dos motores do avião aquando a atuação dos potenciômetros) e a incoporação do circuito todo num módulo só, de modo a se assemelhar aos produtos existentes no mercado.

• Referências

Início

[16] O'REILLY—Rasperry Pi Cookbook , Disponível em: http://razzpisampler.oreilly.com/ch04.html#SEC7.8 . [Acedido a 28 de Novembro de 2019].

Início