Aviação - Piloto Automático Boeing 737


#1

Olá pessoal,

Essa é minha primeira contribuição no Forum e tenho imenso prazer em poder fazer parte de uma iniciativa tão bacana assim como é o “Fazerdores”.

Introdução

Apesar trabalhar atualmente como desenvolvedor de software, sou apaixonado por aviação e pela possibilidade de seguir na carreira de piloto de aeronave. Em meu tempo livre, procuro estudar assuntos relacionados e, sempre que possível, botar em prática no simulador de voo.
Muitos irão pensar “Ahhh…é Microsoft Flight Simulator”… Não! É quase isso!
Sem desmerecer o tão famoso MFS, mas por não possuir máquina rodando Windows em casa, utilizo um simulador de voo chamado X-Plane. Trata-se de uma plataforma de simulação muito madura com mais de 10 anos de desenvolvimento, certificado nos EUA pela FAA (Federal Aviation Administration).
O X-Plane é famoso por sua física realista, precisão de seus instrumentos de navegação e também por ser compatível com Mac OS X, que é o meu caso.
Uma das características mais legais do X-Plane é que permite a criação de plugins e outras personalizações. A grande e ativa comunidade online possui uma variedade gigantesca de contribuições tanto freewares quanto paywares.
Quem quiser saber mais sobre o simulador especificamente pode acessar: x-plane.com e também o site da comunidade x-plane.org

Motivação

Alguns de vocês já devem imaginar que pilotar um avião não é algo simples, pois envolve muita teoria e técnica. Por mais que as aeronaves mais modernas sejam quase em sua totalidade “automatizadas”, ainda sim é necessário muito estudo para programa-las/opera-las corretamente.
Vocês já devem ter visto a quantidade de controles, botões, displays, sistemas de segurança e indicadores dentro de uma cabine de um Boeing 737. Se não viram, abaixo segue duas fotos para ilustrar.

 http://1.bp.blogspot.com/-3WTWWc3_XlQ/UcFnTSFb9MI/AAAAAAAABHM/rXbQDNwYspI/s1600/airarabia_pilot_1.JPG

Os softwares simuladores de voo mais modernos, em especial o X-Plane, permitem a total operacionalidade de todos(ou quase todos) esses botões e funções através de um 3D Cockpit. Mas vamos concordar que operar simultaneamente tantas funções com um mouse fica um pouco complicado.
Principalmente em uma situação de stress intenso como a de aproximação e pouso no aeroporto de Congonhas no meio da cidade de São Paulo. Afinal de contas, ninguém quer derrubar um avião com 200 vidas abordo (inclusive a minha), mesmo que em um ambiente virtual. (rsrs)
Pensando nesse problema e também no prazer de simular e aumentar cada vez mais a sensação de realidade, muitos “simuleiros” como dizem por ai, resolvem construir verdadeiros cockpits em suas casas.
E posso afirmar que existem alguns “malucos” que constroem verdadeiras obras de engenharia em suas próprias casas motivados pelo prazer de voar sem sair do chão.
Um excelente exemplo pode ser consultado no canal desse cara aqui:

http://www.youtube.com/channel/UC796zH3CJXUx_XwDQbecMUQ

Mas afinal, por que eu vim aqui postar sobre isso?

Pois bem, existem comunidades online, a maior parte delas nos EUA e Europa, que compartilham assuntos relacionados a DIY para simulação de voo. Sem contar com as empresas que surgiram por lá com a proposta de oferecer esse tipo de produto.
Essas empresas constroem módulos de controle para projetos de cockpits, sejam eles para diversão ou até mesmo para simuladores profissionais. Uma delas é a http://www.flightdecksolutions.com/.
Ainda não é de meu conhecimento a existência de empresas brasileiras explorando com “qualidade” esse mercado.
Como todos devem presumir, importar um produto desses não é nada barato (Aproveito para agradecer a Receita Federal Brasileira).

Pensando em tudo isso, minha “mente diabólica” começou a alimentar a ideia de que é possível realizar um DIY com custo totalmente acessível aqui em Terras Tupiniquins.
Como disse acima esses produtos são modulares, ou seja, cada parte específica pode operar de forma independente através de uma porta USB.
A operação dos botões, knobs e seletores programáveis, refletem em funções disponíveis nas interfaces do software de simulação. Não me aprofundei teoricamente nesse assunto mas imagino que podemos fazer uma analogia aos famosos controladores MID. (Espero não estar falando “besteira”…)

Em meus voos virtuais as operações que realizo com maior frequência são os ajustes no painel do piloto automático para executar o plano de voo. O nome técnico desse módulo é MCP (Mode Control Panel). Abaixo segue uma foto para ilustrar:

http://www.simflight.com/wp-content/uploads/2012/08/CPFlight_mcp737pro.jpg

A Proposta/desafio é o seguinte:

É possivel construir uma réplica totalmente funcional com conexão USB de um painel como esse? Assim como todo programador em uma reunião de estimativa de projeto, a resposta imediata seria “Sim, é possível!”, e a segunda expressão comumente dita seria “Mas depende…”.
É exatamente nesse ponto que o fator custo entra na história. E deixo claro nesse ponto que uma das motivações principais é exatamente o custo acessível, além do prazer e conhecimento que um DIY pode nos proporcionar.

Portanto, abro nesse momento um brainstorming e convido todos os interessados no desafio.

Conheço pouco de eletrônica especificamente. Porém, muitos anos atrás, cursei Mecânica Automobilística na escola SENAI, onde tive muito contato com sistemas embarcados (Injeção eletrônica e afins). Sei apenas conceitos básicos e imagino que poderia contribuir mais efetivamente em questões que envolvam software já que é minha área de atuação.

Alguém se habilita?


#2

Caro, acho que é perfeitamente possível construir a réplica do painel.
Um pouco de eletrônica e software para fazer a interface com o PC.


#3

Muito legal seu desafio. Pra dizer a verdade já tem um tempo que namoro essa ideia de construir um cockpit para simulador de vôo. Não conheço o X-Plane em termos de interface de comunicação com aplicativos externos ou plugins. Quando comecei pesquisar sobre essa ideia descobri o Flight Gear, um simulador com desenvolvimento maduro em atualização constante pela comunidade e Open Source. Sim, ele não tem o mesmo nível gráfico do X-plane plane, e não discuto isso, mas o fato de ser Open Source e ter uma qualidade no meu ponto de vista aceitável, me faz considerar a opção por ele. Já dei uma estudada no modo de programação e ele possui uma interface de comunicação por sockets bastante completa e bem documentada. Em alguns testes que fiz a integração com o hardware é bem fácil. Com essa abordagem tenho interesse em participar do desafio/projeto. Aproveitando o gancho acho que seria legal começar a ter projetos colaborativos aqui no fazedores.

Referências:
Site:
http://www.flightgear.org/

Vídeo da nova versão:


#4

@Marco
Fico feliz por saber que está interessado. Realmente, olhando pelo lado “open source”, o “Flight Gear” seria uma excelente plataforma para orientarmos o projeto. Mas não me agrada a ideia de, nesse primeiro estágio, especificar uma ou outra plataforma. Imagino que isso seria uma preocupação futura, já que o hardware diz mais respeito a aeronave em si e seria comum independente da plataforma de simulação. A compatibilidade e interface entre hardware e software poderíamos resolver posteriormente com conectores específicos para cada plataforma. Inclusive poderíamos incluir o Microsoft Flight Simulator também.

O que acha de seguirmos com o foco no hardware inicialmente? Sem, esquecer é claro, de considerar uma interface de dados comum que permita uma abstração diferente para cada plataforma. A partir dai seguimos com o desenvolvimento dos conectores. O que acha?


#5

Encontrei os detalhes de um projeto realizado em 2010 da construção de um MCP. Muito útil a publicação, pois lista o conjunto de componentes necessários. Irá ajudar no levantamento inicial.
Segue abaixo o link do projeto: http://www.hispapanels.com/cabina737/paneles/mip/mcp/mcp1i.htm


#6

Caro
Acho que sua proposta está legal, podemos iniciar focando primeiro no hardware. No que cabe a eletrônica, firmware, e programação para interface com PC eu posso contribuir. Na mecânica eu diria que consigo fazer protótipos funcionais. Vamos definir os requisitos iniciais?
Marco


#7

Dando seguimento ao projeto…

Passei em uma pequena loja perto do trabalho e comprei componentes variados incluíndo um Arduino Uno.
Comecei a realizar algumas experiências para me familiarizar com o Arduino. Estou impressionado com a facilidade e rapidez com que evolui na plataforma. Realmente muito simples gravar um algoritmo no Arduino.
Já brinquei um pouco com Rotary Encoder e multiplexação com displays 7 segmentos. A ultima coisa que trabalhei foi com comunicação serial a partir de uma aplicação Java.
Escrevi um código que processa os movimentos do Rotary Encoder e envia por serial para a aplicação Java.
Fiz essas experiências para prototipar o HDG que é uma das partes mais simples do MCP. O HDG possui um seletor rotativo, um mostrador com 3 dígitos de 7 segmentos e um botão de ativação. Ele também deve possuir um seletor de ângulo de inclinação de curva, mas deixei para pensar nisso futuramente para não complicar.

Abaixo ilustração do HDG:

Algumas reflexões sobre as experiências:

1. Temos o seletor e o display. Ao alterarmos o valor pelo seletor estamos enviando dados para o simulador. Também temos que mostrar esse valor no display.
Porém não podemos pensar que esse processo possui somente o envio de dados, pois o que será mostrado nos displays/indicadores precisam estar sincronizados com os exibidos no cockpit virtual do simulador.
Logo conclui-se que precisamos implementar uma via de mão dupla, onde enviaremos e também receberemos dados do simulador para manter sincronizadas as informações no hardware e no software.
Um exemplo claro dessa necessidade é pensar na seguinte situação: Toda vez que ligarmos o hardware nossos displays exibirão todos os valores zerados e indicadores desligados, necessitando reconfigura-los um a um para ficar iguais ao estado do cockipit virtual.


2. Precisamos definir um “Protocolo” para padronizar o envio e recebimento de valores diferentes através de um único barramento serial. Por exemplo, precisaremos distinguir uma alteração de HDG de uma alteração de Vertical Speed.
Nesse ponto, para não reinventarmos a roda, é necessário pesquisar se já existe algum tipo de protocolo amplamente utilizado para organizar a comunicação serial.


3. O Arduino facilita a prototipagem, mas para o produto final devemos considerar microcontroladores apartados. Nesse caso os PICs da Microchip seriam a melhor opção??


#8

Excelente @Marco,
Vamos iniciar então as definições.
Por onde acha de devemos começar? Pela lista de componentes? Definição dos modelos de microcontroladores?
Como havia dito, tenho pouca experiência com hardware. Tenho algumas dúvidas do tipo: Será que existem algumas placas padrões de entradas e saídas que poderíamos considerar para evitar o “reinvento da roda”. Ou deveríamos montar tudo na raça?


#9

Acho que devíamos começar pela especificação do projeto, nem todo mundo conhece aviação e precisa saber exatamente o que essa caixinha vai fazer nos mínimos detalhes:

Que interfaces ele vai ter?
Que tipo de informação cada uma dessas interfaces envia/recebe?
Quais os componentes serão necessários para construir essas interfaces?
Qual o MCU/PLD caberia melhor para ele?

Vejo daqui 4 potenciômetros + Knobs (sem contar aquela rodinha ali que acho que é um tipo de potenciômetro), 4 displays… esses displays serão implementados com driver?.


#10

Caros
Acho que devemos partir de uma especificação mínima do projeto elencando todos esses pontos que vocês levantaram. A partir dai levantamos os componentes que serão utilizados. Eu voto por fazer tudo na raça, primeiro para aprender, segundo é ter um maior controle, terceiro caracterizar o espirito fazedor.
Além dos paineís tem os controles, manche pedais. Eu gostaria de fazer os meus, fica como sugestão para ponto de partida. Com esses controles dá pra fazer uma prova de conceito do hardware, protocolo de comunicação e avaliação da funcionalidade.


#11

Onde você comprou o material? Desses componentes eu não tenho o Rotary Encoder


#12

Boa pergunta… Quando cheguei na loja e pedi “Rotary Encoder” o atendente fez cara de interrogação. Tentei novamente dizendo “Encoder Rotativo”, a interrogação persistiu. Tentei explicar basicamente do que se tratava dizendo que era baseado em pulso luminoso, etc etc. Sem sucesso.
Ele só entendeu quando eu citei “É uma espécie de potenciômetro…”. Então ele disse "Ahhhhh… é o potenciômetro sem fim!!!"
Então galera, se tiverem problemas para encontrar esse componente, já sabe quais possíveis apelidos eles possuem na linguagem dos vendedores.
Muitas vezes a loja possui o componente mas conhecem por outro nome e nós acabamos voltando pra casa sem comprar. Fica a dica…


#13

@sksdutra

Primeiramente, fico feliz por seu interesse em participar no projeto.
Muito bem colocado, realmente teremos que alinhar os conhecimentos para falarmos a mesma lingua.
Em relação a isso segue o video abaixo que mostra em detalhes a operação do MCP que também é conhecido como módulo de controle do “Autopilot”.


#14

Pessoal,

Quanto a definição do protocolo padrão para comunicação, estive fazendo pesquisas sobre HID (Human Interface Device) e a especificação USB HID class. É cedo ainda para afirmar se essa abordagem seria nossa melhor alternativa em relação a comunicação serial. Pois ainda não sei como esse protocolo opera quanto ao envio de informação do computador para o dispositivo (atualizar os valores dos displays).
Encontrei video bem interessante explicando como atualizar o firmware do Arduino UNO para passar a ser reconhecido pelo S.O. como um dispositivo HID.

Segue:

Gostaria de saber a opinião de vocês sobre a possibilidade e/ou restrições de adotarmos esse padrão para a comunicação do nosso dispositivo.


#15

Ao invés de PICs, se a prototipagem for feita com Arduinos, eu recomendaria utilizar os próprios microcontroladores da Atmel, assim o código pode ser reutilizado. Aqui vai um exemplo, com o ATtiny.

Como pode ser um projeto bem grande, a escala pode pedir talvez até FPGAs, o que seria mais complicado.


#16

O HID (Human Interface Device) como o próprio nome diz é um protocolo em cima da especificação USB para dispositivos comuns de interação como teclado, mouse e controlador de jogo. Aproveitando o exemplo, mudando o firmware do Arduino para um firmware HID (muda o firmware do dispositivo que faz a comunicação USB) tem que entrar no modo DFU. Penso que o protocolo indicado é o CDC, usado no dia como o Arduino para exibir mensagens no monitor via comando print. Com essa abordagem o sistema ficaria com um firmware no arduino para fazer aquisição do sinais analogicos e digitais, um programa no PC para capturar essas informações e trocar dados com o simulador. No FlightGear a comunicação é por meio de comandos via sockets, bem fácil e documentado. No X-Plane não tenho idéia.


#17

@Marco
Um outro exemplo aqui: http://cjdavies.org/?p=1056

O X-Plane possui integração via UDP.
Eu imaginei que utilizando a abordagem via HID vc não precisaria de nenhum software intermediando o hardware e o simulador, pois o simulador reconhece dispositivos HID (Joysticks) automaticamente. Só precisaríamos ver como ficaria a questão do mapeamento de todos os comandos e principalmente o envio de informações do simulador para o hardware.
Precisamos estudar isso melhor…


#18

Considerando que vamos precisar do envio e recebimento de mensagens entre hardware e simulador e o HID é usado mais para dispositivos de entrada (teclado, joystick) não sei se é a opção que vai conseguir atender todos os requisitos. Podemos discutir e ver as vantagens e desvantagens


#19

@Marco, por isso recomendo a prototipagem/construção com Arduinos/AVR mesmo, usando a comunicação serial é possível ter tanto entrada quanto saída.


#20

Então podemos considerar que o caminho é usar comunicação serial (CDC) via USB, para ter tanto entrada como saída?