Modulo medio

KSP Cockpit

Controle físico (painel + joystick + telemetria) para o Kerbal Space Program 1, feito do zero com hardware e software próprios.

O objetivo principal é aprender firmware/embarcados e eletrônica, e de quebra ter um cockpit de verdade — com direito a um botão que dispara um script de pouso autônomo estilo SpaceX.

Arquitetura

 PC com Windows: KSP 1 + servidor kRPC
          ▲
          │  cabo de rede direto, com IP fixo (kRPC, TCP/protobuf)
          │  (pela Wi-Fi de casa durante o desenvolvimento)
          ▼
 Raspberry Pi 4 = computador de bordo ............... bridge/
   • ponte kRPC ⇄ placas, aberta sozinha quando o Pi liga
   • tela multifunção no navegador do tablet ........ bridge/celular/
   • dispara os scripts de voo ....................... scripts/
          ▲                         ▲
          │ USB/serial              │ Wi-Fi de casa
          │ (protocolo próprio)     │ (página da tela, por HTTP)
          ▼                         ▼
 Arduino Mega = I/O do painel    tablet = tela multifunção
 firmware/painel/                (Galaxy Tab S 8.4, no Chrome)
          ▲
          │  SPI + linhas analógicas
          ▼
 Backplane: 12 slots ................................ hardware/backplane/
          ▲
          │  um cabo flat de 16 vias por módulo
          ▼
 Módulos do painel, um por seção .......... hardware/modulo_pequeno/, _medio/ e _grande/
   pequeno: 8 entradas + 8 LEDs (1 × 74HC165 + 1 × 74HC595)

Cada parte tem um papel bem definido:

Durante o desenvolvimento, o mesmo código Python roda no PC — só muda o endereço do servidor kRPC e a porta serial.

Princípios

• O LED mostra o estado do jogo, não a posição da chave. A chave só avisa para onde foi ("SAS para cima"); o computador de bordo decide o que fazer e o jogo confirma. Assim o painel nunca fica dessincronizado (ex.: SAS desligado pelo jogo).
• Uma tela só, no meio do painel: a tela multifunção. Os módulos não têm tela própria. Cada módulo que precisa mostrar números (editor de manobras, piloto automático, rendezvous...) tem uma página na tela multifunção. Quando o piloto mexe num módulo, a ponte troca a tela para a página dele; uns segundos depois do último toque no módulo (uns 10 s, a ajustar), a tela volta sozinha para a página de antes, em geral a navball.
• Protocolo serial em duas versões:
  • v0 — texto, uma mensagem por linha. Fácil de depurar no Serial Monitor.

    Pi → placa:  ALT 12345      SAS 1      FUEL 73
    placa → Pi:  BTN STAGE 1    SW SAS 0   AX PITCH -312

  • v1 — binário, com enquadramento COBS, ID de mensagem e CRC. Mais rápido e robusto; vem quando a v0 começar a apertar. É o mesmo protocolo para o Mega e para a mikromedia.
• Entradas analógicas (joystick, acelerador) são enviadas a uma taxa fixa, com zona morta e filtro; entradas digitais são enviadas só quando mudam.

Decisões

Estrutura planejada do repositório

bridge/           computador de bordo em Python: ponte kRPC ⇄ serial, tela de telemetria;
                  tela multifunção: ponte (mfd.py), simulador, navball e a página do celular (celular/);
                  painel de sistemas de controle (sistemas.py), com a página de botões (celular/painel.html);
                  painel de scripts (painel_scripts.py): o korry POUSO abre o scripts/pouso.py, e o
                  LANCAR, o scripts/subida.py, com o menu da subida;
                  avisos de voo por voz, como o GPWS (avisos.py);
                  editor de nós de manobra com botões na página (manobras.py); testes em bridge/tests/;
                  o serviço do systemd que abre a ponte da tela quando o Pi liga (servico/)
scripts/          scripts de voo (pouso, subida até a órbita, rendezvous, fly by wire...), que rodam com ou sem o cockpit; testes em scripts/tests/
firmware/painel/  Arduino Mega (Arduino IDE ou PlatformIO)
firmware/encoder/ Arduino Uno com o encoder AJUSTE da tela (docs/encoder.md)
firmware/passos/  sketches de aprendizado, um por passo da fase 1
firmware/mfd/     mikromedia for ARM / LPC2148 (C, compilado com o LLVM pelo compilar.py): a tela multifunção
hardware/         esquemáticos e PCBs (KiCad), desenhos da caixa; ver hardware/README.md
                  e hardware/construcao.md (o cockpit da versão B, a caixa e os painéis);
                  cada peça própria numa pasta, com ficha e desenhos (hardware/korry/:
                  modelo no OpenSCAD, STL das legendas, das grades e das peças, gerar.py e o desenho da ligação);
                  identidade visual (hardware/identidade_visual.md) e desenhos dos painéis
                  gerados por código (hardware/desenho/, SVG em hardware/img/)
docs/             protocolo serial, pinagem, anotações

Roteiro

Cada fase termina com algo funcionando de ponta a ponta. Não pule o critério de "pronto".

Fase 0 — Ambiente

Status: concluída. Passo a passo detalhado e problemas encontrados em docs/setup-pi.md. No cockpit, o Pi liga no PC por um cabo de rede direto, testado com o fase0_altitude.py, e a ponte da tela abre sozinha quando ele liga, espera o jogo e reconecta quando ele fecha e abre de novo.

No PC:

• Instalar KSP 1.12.x e o kRPC (via CKAN ou manualmente).
• No jogo, abrir a janela do kRPC e iniciar o servidor (dica: ativar auto-start e auto-accept nas configurações).
• Nas configurações do servidor, trocar o endereço de localhost para Any (aceitar conexões da rede), e liberar no firewall do Windows as portas do kRPC (padrão: 50000 e 50001).
• Marcar a rede do Windows como Privada; em rede Pública o Windows bloqueia a conexão do Pi.
• Instalar Python 3, pip install krpc pyserial e a Arduino IDE 2 (ou PlatformIO no VS Code).
• Se a placa for clone com chip CH340, instalar o driver CH340 no Windows.

No Raspberry Pi 4:

• Gravar o Raspberry Pi OS com o Raspberry Pi Imager, já configurando Wi-Fi e SSH.
• pip install krpc pyserial pygame (de preferência dentro de um venv).

import time
import krpc

# No PC: krpc.connect(name="KSP Cockpit")
# No Pi: informar o IP do PC onde o KSP está rodando
conn = krpc.connect(name="KSP Cockpit", address="192.168.0.10")
vessel = conn.space_center.active_vessel
altitude = conn.add_stream(getattr, vessel.flight(), "mean_altitude")

while True:
    print(f"{altitude():,.0f} m")
    time.sleep(0.1)

Versão completa, que recebe o IP como argumento, espera a cena de voo e explica os erros de conexão: bridge/fase0_altitude.py.

Pronto quando: o script roda no Pi e imprime a altitude ao vivo enquanto o foguete sobe no PC.

Fase 1 — Primeiro circuito fechado

Status: concluída, no PC e no Pi. Roteiro passo a passo, montagem e testes: docs/fase1.md. Protocolo: docs/protocolo.md.

• Mega ligado no PC pela USB durante o desenvolvimento; no fim, no Pi.
• 1 botão (STAGE), 1 LED (SAS) e a altitude num LCD 20x4 com módulo I2C.
• Protocolo v0 (texto).
• Aprende: pull-up, debounce, leitura/escrita serial, laço principal sem delay().

Pronto quando: apertar o botão faz stage, o LED acompanha o SAS do jogo e o LCD mostra a altitude.

Fase 2 — Painel de controle

Status: em andamento. Chaves, botões e LEDs estão prontos para montar: pinagem, código e testes em docs/fase2.md. O cockpit inteiro está desenhado: a versão B, em U, com 11 painéis de 125 mm, o sidestick e o acelerador no painel.

• Chaves para SAS, RCS, trem de pouso, luzes e freios; STAGE e ABORT com capa de proteção. Depois, action groups.
• Painel VOO, de sistemas de controle (desenho): os 10 modos do SAS em korry de duas cores (azul virando, verde segurando), korry SAS, RCS, FBW e TRAVA ALT, e o encoder do piloto automático. Numa placa grande com 4 × 74HC595. Apertar um modo do SAS abre a roda dos modos na tela multifunção, só para ver. Trem de pouso, luzes e freios foram para o painel do acelerador.
• A posição da chave é o estado desejado (para cima = ligado); o LED de cada sistema mostra o estado no jogo.
• Painel em módulos: cada seção vira uma placa, ligada por cabo flat a um backplane de 12 slots no Mega. A placa pequena tem 8 entradas e 8 LEDs (1 × 74HC165 + 1 × 74HC595); a média, 16 e 24 (2 + 3), com um jack JST-XH para cada korry; a grande, 24 e 32 (3 + 4). Os LEDs só mostram o que vem do jogo: nenhum é ligado a um botão. Cada módulo tem uma etiqueta numa chave DIP, e o Mega descobre sozinho o que está encaixado. Esquemáticos, etiquetas e qual placa vai em cada seção em hardware/.
• Enquanto o primeiro módulo não fica pronto, os controles básicos continuam direto nos pinos do Mega, como em docs/fase2.md.
• Próximo passo: o firmware do Mega lendo a fila de módulos pelas etiquetas, e testar o primeiro módulo direto no Mega.
• Tela e encoder: a tela multifunção agora é um tablet Galaxy Tab S 8.4, atrás do painel duplo. Um encoder só, o AJUSTE, no VOO, logo embaixo da tela, mexe na página aberta: o piloto automático, o Δv do editor, o alvo e a subida. As luzes do piloto e os avisos ficam ao lado dele. As barras de recursos saíram, e o painel da asa esquerda virou só EVA.
• Sidestick e acelerador no painel: um joystick JH-D400X-R4 de 3 eixos, com o botão do manche trocando entre VOO, CÂMERA e TRANSLAÇÃO, e uma alavanca deslizante de 60 mm, os dois lidos pelo Mega nas linhas analógicas do backplane (sidestick, acelerador). O Extreme 3D Pro fica para desenvolver no PC; mapeamento em hardware/construcao.md.
• Korry switches: botões iluminados com legenda, como nos aviões, 35 no cockpit. Legenda impressa em duas cores na FlashForge Inventor, encaixada num corpo igual para todos, com a chave e os LEDs num suporte impresso. As bases de cada grupo saem numa grade impressa, parafusada atrás do painel. O modelo, os STL das 31 legendas, das grades e das peças, o gerar.py e a ligação estão em hardware/korry/; o primeiro passo é o teste de folga e um korry ligado direto no Mega.

A fazer na ponte, para a versão B (o que cada controle faz e o comando do kRPC estão em hardware/construcao.md):

• Definir no protocolo as mensagens dos painéis novos: tempo, navegação, action groups e peças, câmera, EVA, acelerador e sidestick.
• Tempo: WARP, PARAR, FISICO, ATE O NO, PAUSA, SALVAR, CARREGAR e REVERTER.
• Encoder AJUSTE da tela: o firmware do Uno, mandando ENC AJUSTE e BTN AJUSTE (docs/encoder.md).
• Encoder AJUSTE da tela: a ponte lê o Uno (--encoder) e manda o giro e o aperto para a página aberta: a SUBIDA ou o piloto automático (docs/encoder.md).
• Encoder AJUSTE: o Δv do editor e o alvo, quando a ponte da tela tiver as páginas deles.
• Navegação: PROCURAR abre a página ALVO, e o AJUSTE escolhe o alvo; LIMPAR; REFERENCIA; trocar de nave.
• Action groups 1 a 8 e os korry das peças (paraquedas, painéis solares, antenas, compartimento de carga), com a luz do estado.
• Câmera: IVA, MODO CAM, FOTO e ESCONDER. O MAPA já existe na página de botões e abre a página MAPA do tablet.
• Acelerador pela alavanca; TREM, FREIOS e LUZES em korry.
• Sidestick: os 3 eixos pelo Mega, e o botão trocando o modo, com as luzes.
• EVA, quando houver o kRPC 0.7: andar e voar pelo manche, JATO, LUZ, SAIR, EMBARCAR, AGARRAR e SOLTAR.
• Tela no tablet: a página SUBIDA no navegador, com o menu e o desenho do voo, como na mikromedia.
• Testar a tela no Tab S pela Wi-Fi, em tela cheia.
• Página MAPA no tablet: a órbita em 3D, as luas, o alvo e o nó de manobra, no lugar do mapa do jogo (docs/mfd.md). Depois: as trajetórias que trocam de esfera de influência.
• Páginas novas na tela: ORBITA, DELTA-V, SUBIDA, ALVO, TEMPO, EVA e RECURSOS (combustível, oxidante, monopropelente e eletricidade, no lugar das barras de LED).

Pronto quando: dá para lançar e colocar um foguete em órbita usando só o painel.

Fase 3 — Tela de telemetria

• Interface em pygame no Pi: altitude, velocidades, apoapse/periapse, tempo até Ap/Pe, combustível e delta-v por estágio.
• Depois: gráfico de altitude × tempo, desenho simples da órbita, indicador de atitude.
• O Pi 4 tem folga de desempenho, mas vale o bom hábito: redesenhar só o que mudou e limitar a taxa de quadros.
• A tela do cockpit é um tablet Galaxy Tab S 8.4, com a página da tela no Chrome, com a página chegando pela Wi-Fi de casa e o tablet no próprio carregador (docs/mfd.md). A mesma tela roda no simulador do PC, no celular e na mikromedia (fase 6).
• A tela multifunção (docs/mfd.md) já mostra navball, velocidades, altitude e Ap/Pe, na placa, no simulador e numa página web.

Pronto quando: dá para circularizar uma órbita olhando só para a tela.

Fase 4 — Instrumentos físicos

Status: editor de manobras escrito, com botões numa página no lugar das chaves; falta testar no jogo. bridge/manobras.py cria e edita os nós pelo kRPC e mostra os números do nó e da órbita (antes e depois) no navegador do PC ou do celular: docs/manobras.md. A página manda linhas do protocolo pela rede; o painel vai mandar as suas pela serial, com o encoder no lugar dos pares +/- do Δv. Por enquanto a página também gira a câmera do mapa, o que tem que sair dela: no cockpit, a câmera do mapa vai ser mexida pelo joystick, no modo CÂMERA.

A fazer no editor, para ficar igual ao painel desenhado (desenho, mensagens):

• Ponte (bridge/manobras.py): guardar o eixo escolhido (PRO, NRM ou RAD), começando pelo PRO em cada nó novo, e trocar de eixo com BTN PRO, BTN NRM e BTN RAD.

• Ponte: aceitar ENC DV <cliques> (horário positivo) e aplicar os cliques × passo no eixo escolhido.

• Ponte: aceitar SW PASSO <0 a 3>, o passo pela posição da chave rotativa, no lugar do BTN PASSO.

• Ponte: mandar ao painel qual eixo está escolhido, para acender o korry certo.

• Página do celular (bridge/celular/manobras.html): trocar os pares PRO -/PRO +, NRM -/NRM + e RAD -/RAD + por três botões de eixo e um par -/+ que faz o papel do encoder, com o eixo escolhido destacado.

• Testes (bridge/tests/test_manobras.py) para o eixo escolhido, o ENC DV e o SW PASSO.

• Atualizar docs/manobras.md e tirar o "planejado" da seção No painel do protocolo.

• Displays de 7 segmentos com MAX7219 para os números mais importantes.

• Encoder rotativo para escolher o que cada display mostra. Lido pela mesma cadeia de 74HC165 dos módulos: o Mega lê a cadeia inteira mil vezes por segundo numa interrupção de timer, e assim o redesenho do LCD (~20 ms) não faz perder cliques. O painel acumula os cliques e manda ENC <nome> <cliques>.

• Editor de nós de manobra (pelo kRPC: control.add_node, node.prograde etc.):

  • Painel duplo de 250 × 125 mm, desenho e peças em hardware/construcao.md.
  • Δv por um encoder só, porque os três eixos nunca são mexidos ao mesmo tempo. Três korry (PRO, NRM e RAD) escolhem o eixo, e a legenda do escolhido acende na cor da alça do nó no KSP. Girar no sentido horário soma o passo; no anti-horário, tira. Um nó novo já vem com o PRO escolhido. O encoder é o AJUSTE, no VOO: com a página do editor aberta, a ponte manda o giro como ENC DV <cliques>, e quem sabe o eixo escolhido é ela.
  • PERCURSO: uma tecla basculante com mola para o centro, como a do TIME WARP, montada deitada, move o nó ao longo da órbita (para a esquerda, antes; para a direita, depois). Segurando, repete; o painel manda INC TEMPO <passos>. Embaixo dela, ANT e PROX trocam de nó.
  • PASSO: chave rotativa de 4 posições, com a legenda gravada em volta: 0,1 / 1 / 10 / 100 m/s no Δv e 1 s / 10 s / 1 min / 10 min no tempo.
  • Korry NOVO (nó novo no apoastro), APAGAR e CIRC (circulariza no ponto do nó, com o Δv calculado pela ponte). Sem AP e PE: o tempo já leva o nó a qualquer ponto.
  • São 14 entradas e 3 LEDs (os korry de eixo): cabe numa placa média.
  • Sem tela no módulo: Δv, tempo de queima, T− até o nó e o Ap/Pe resultante aparecem numa página do editor na tela multifunção, que abre sozinha quando uma tecla ou botão do editor é usado (ver os princípios).
  • O botão MAPA fica na seção da câmera e abre a página MAPA do tablet, onde o nó aparece com a órbita depois dele. A câmera do mapa (girar e aproximar) é o toque no tablet, não o editor.

• O que resta de combustível, oxidante, monopropelente e eletricidade vai para a página RECURSOS da tela multifunção, no lugar das barras de LED que estavam no painel da EVA.

• Ponteiro analógico com motor de passo X27.168.

• Fonte 5V externa (a USB não aguenta muitos LEDs).

Pronto quando: um voo inteiro (lançamento → órbita → reentrada) é feito sem olhar para o monitor do PC, inclusive planejar a circularização pelo editor de manobras.

Fase 5 — Protocolo v1 + scripts de voo

Status: script de pouso escrito, em teste no jogo; o korry POUSO já dispara o script pela página de botões. No primeiro teste, em Kerbin, a freada terminou alta e a nave tocou o chão inclinada e tombou. Corrigido: o pé agora é medido pelas pernas do trem. No segundo teste o pé ficou certo (0,4 m de erro no toque), mas a nave balançou até 31° na freada: o piloto automático do kRPC não segurava a nave. Agora quem aponta a nave é o SAS do KSP (falta testar de novo). scripts/pouso.py faz a queima de suicídio numa descida vertical, em qualquer planeta, contando o arrasto do ar; roda pela linha de comando ou pelo korry POUSO do painel de scripts, e a tela multifunção mostra o pouso numa página própria (docs/mfd.md). scripts/tests/test_pouso.py testa a mesma guiagem numa nave simulada, sem o KSP, em planetas com e sem atmosfera.

• Migrar para o protocolo binário (COBS + CRC).
• Painel de scripts (desenho): um korry por script, em faixas na ordem do voo (SUBIDA, ORBITA, DESCIDA). Por enquanto o POUSO e o LANCAR, da subida até a órbita; os outros quatro lugares ficam vagos, com a tampa lisa. Segurar o korry 5 s abre o script; segurar de novo 5 s aborta. O korry pisca âmbar enquanto conta, fica verde com o script voando e vermelho se ele foi abortado ou falhou.
• Korry "EXEC" (um lugar vago do painel de scripts) que executa o nó de manobra da fase 4: aponta a nave para o nó, acelera o tempo até perto dele, queima e corta quando o Δv restante chega a zero.
• Painel e tela mostram o estado do script (armando, voando, pousado, abortado). A página POUSO da tela, inspirada na tela do booster da SpaceX, mostra a nave descendo até o alvo, a fase, a altura, a descida, o empuxo/peso e quanto do empuxo a freada precisa. O pouso e o EXEC seguem a base comum dos scripts.

A fazer no painel de scripts:

• Ponte (bridge/painel_scripts.py): segurar BTN POUSO 5 s abre o scripts/pouso.py num processo; segurar de novo aborta; a linha SCR POUSO acende o korry.
• scripts/pouso.py: estado por UDP (linhas POU), código de saída e --demo com uma nave simulada.
• Página POUSO no simulador e no celular; korry POUSO na página de botões (bridge/celular/painel.html).
• Testar no jogo: o korry abre o pouso, a página acompanha, e segurar de novo aborta com o motor cortado.
• Firmware do Mega: o korry POUSO no módulo da ação executiva, mandando BTN POUSO 1 e 0, e o LED de duas cores pela linha SCR POUSO.
• Os outros scripts (piloto automático de avião, subida até a órbita, pouso de precisão...) estão em Scripts de voo e não entram no critério desta fase.

Pronto quando: um booster pousa sozinho a partir de um botão no painel, e um nó de manobra é executado pelo botão EXEC.

Fase 6 — Tela multifunção (mikromedia for ARM)

Fora do cockpit de novo: a tela do cockpit passou a ser um tablet Galaxy Tab S 8.4, com a mesma página do celular (decisões), porque a tela de 2,8" ficava pequena no meio do painel. O firmware continua aqui e roda na placa, com o jogo.

Placa da MikroElektronika com NXP LPC2148 (ARM7TDMI-S, 60 MHz, 512 KB de flash, 32 KB de RAM), tela 320x240 com touch resistivo, microSD, saída de áudio e carregador de Li-Po. Aqui o firmware é escrito sem framework: C, registradores, script de linker e código de inicialização próprios.

Status: rodando na placa, com o jogo. O firmware em firmware/mfd/ faz na placa o que o simulador faz no PC: navball, números, botões de toque e as páginas SAS, AP e POUSO, no protocolo em texto. A página SUBIDA (subida até a órbita) existe na placa e no navegador; o simulador mostra a navball no lugar dela. Ligada no Pi pela PROG, com a ponte da tela aberta pelo serviço, a placa mostra a navball ao vivo, lisa, e o toque funciona no jogo. O controlador da tela é o 0047, o HX8347-D. Falta o áudio. Gravar e ligar: docs/mikromedia.md. A tela também roda no simulador do PC e no navegador do celular: docs/mfd.md.

• Placa: duas mini-USB. A USB vai direto no LPC2148, e a PROG tem um conversor USB-serial FT232RL, por onde o PC conversa com a placa e o Flash Magic grava o firmware. No cockpit, o Pi liga na PROG; a USB só alimenta a placa, porque o firmware não usa ela. A tela é um módulo MI0283QT2 (320x240, barramento de 16 bits), com touch resistivo lido pelo ADC. Pinos em docs/mikromedia.md.
• Ferramentas: LLVM (clang, ld.lld e llvm-objcopy), chamado pelo firmware/mfd/compilar.py; o mfd.hex já vem compilado. Gravação pelo bootloader serial de fábrica do LPC2148, pela PROG, com o Flash Magic.
• Passos:
  1. Código de inicialização, script de linker, PLL a 60 MHz.
  2. Serial com interrupção e o protocolo da tela (docs/protocolo.md), em texto como o simulador; mais tarde o v1.
  3. Driver da tela (HX8347) e desenho em faixas de 16 linhas, porque não cabe um framebuffer (320×240×2 = 150 KB contra 32 KB de RAM).
  4. Touch pelo ADC, com a orientação e a calibração escolhidas na própria tela e guardadas na flash.
  5. Páginas: navball, roda do SAS, piloto automático, pouso e subida. Depois: mapa da órbita, informações e uma página para cada módulo do painel que precisa de números (a começar pelo editor de nós de manobra).
  6. Rodar na placa: o controlador é o 0047 (HX8347-D), o toque responde e a navball anda lisa (conferido na placa).
  7. Áudio: alarme de estol e avisos gravados no microSD (combustível baixo, contagem de altitude no pouso), pelo VS1053.

Pronto quando: a mikromedia mostra telemetria ao vivo recebida do Pi e toca um alarme de combustível baixo.

Fase 7 — Hardware definitivo

• PCB no KiCad a partir dos esquemáticos de hardware/: uma placa de módulo, fabricada em quantidade, e o backplane. Fabricação na JLCPCB, PCBWay… A do módulo médio já está pronta, com os Gerbers (hardware/).
• Caixa em MDF cortado a laser (no colégio), com peças impressas em 3D (em casa): um painel removível por seção, legendas gravadas, korry switches, o Pi e o tablet embutidos. Formato, aparência e ordem para construir em hardware/construcao.md.

Fase 8 — Embarcados avançado (opcional)

• Painéis modulares, cada um com seu micro, falando com um mestre via I2C, RS-485 ou CAN.
• Painel sem fio com ESP32.
• Reescrever o firmware do Mega sem o framework Arduino (registradores do AVR) ou migrar para RP2040 (Raspberry Pi Pico) com o C SDK ou Rust + Embassy.

Scripts de voo

Scripts que pilotam a nave, ou ajudam o piloto a pilotar, disparados pelo painel e acompanhados na tela. O primeiro é o pouso autônomo da fase 5 (scripts/pouso.py); o segundo, o fly by wire de avião (scripts/fbw.py); o terceiro, a subida até a órbita (scripts/subida.py); o quarto, o rendezvous (scripts/rendezvous.py). Os outros desta seção são ideias ainda sem código e sem ordem: cada um entra no roteiro quando o hardware de que precisa existir.

Os scripts ficam em scripts/, fora da ponte: cada um roda sozinho pela linha de comando, no PC ou no Pi, mesmo sem o painel. No cockpit, a ponte só dispara o script pelo botão e mostra o estado dele no painel e na tela. Os testes, com naves simuladas e sem o KSP, ficam em scripts/tests/.

Base comum

• Um script ativo por vez. No cockpit, liga segurando o korry do script 5 s, e segurar de novo 5 s aborta. ABORT, ou mexer no joystick, também devolve o controle ao piloto na hora (a fazer).
• O painel e a tela mostram o estado do script (armado, ativo, terminado, abortado). Como nos outros LEDs, o LED mostra o que o script está fazendo, não o botão que foi apertado.
• Guiagem separada do kRPC, como em pouso.py: recebe uma leitura da nave e devolve comandos. Assim ela é testada numa nave simulada, sem o KSP, antes de ir para o jogo.
• Diretor de voo: todo script pode rodar no automático ou só como guia. No modo guia, a tela mostra para onde apontar e quanto acelerar, e o piloto voa pelo joystick. Serve para testar a guiagem sem entregar a nave e para aprender a pilotar junto.

Fly by wire de avião

Status: script escrito e testado num avião simulado; falta testar no jogo. Roteiro de testes, ajuste dos ganhos e problemas comuns em docs/fbw.md.

Como nos caças, o manche não mexe nas superfícies: ele pede o que o avião deve fazer, e o FBW decide as superfícies. scripts/fbw.py lê o joystick (o Extreme 3D Pro, ou um controle de Xbox) e pilota o avião pelo kRPC.

• O manche: para trás e para a frente pede carga, de −1 g a 4 g; solto, 1 g, e o caminho não curva. Para os lados pede velocidade de rolagem, até 90°/s; solto, a inclinação fica onde parou. A torção soma ao leme. O FBW não trava a altitude sozinho: numa curva, o piloto puxa.
• Proteções: com o manche, só a carga até 4 g: puxando tudo devagar, o avião estola. No piloto automático e na trava, ângulo de ataque entre −8° e 15°, asas até 60° e subida entre −30° e +30°.
• Aviso de estol: com o ângulo de ataque perto dos 15°, a luz ESTOL do painel pisca e a tela toca um alarme. É só aviso: o FBW não mexe no acelerador, no piloto automático, na trava nem no manche.
• Nada liga sozinho: os modos do piloto automático e a trava só ligam pelo painel.
• Lei direta no chão e com o botão do FBW desligado: o manche vai direto para as superfícies. O FBW assume 1 s depois da decolagem.
• Sem joystick (--sem-joystick): decola pelo teclado do jogo, na lei direta, e no ar o piloto automático voa pelo painel.
• O acelerador fica com o piloto. O acelerador automático (SPD) já existe por dentro, ainda sem interface.
• Na tela: com o piloto automático ou a trava, o caminho pedido aparece na navball da tela multifunção, como os quatro cantos verdes de um quadrado. Com o avião nele, o pró-grado fica dentro do quadrado.
• Por dentro, duas camadas: a carga e a rolagem pedidas viram velocidades de giro; os giros viram superfícies, com proporcional e integral e o ganho dividido pela autoridade do avião.

Pronto quando: um avião decola na lei direta e, com o FBW, responde ao manche na hora, sem balançar: puxar dá carga, rolar dá rolagem, e soltar segura o que estava.

Anotado depois dos primeiros voos no jogo (a fazer):

• O FBW está muito instável no jogo. O voo gravado mostrou o nariz oscilando a 1,5 vez por segundo (ganho de pitch alto para o atraso do kRPC) e um avião lento e "interventor". Refeito com a lei de caça e ganhos menores, testados com a leitura atrasada (docs/fbw.md). Falta confirmar no jogo.
• Não ligar o FBW sozinho na decolagem. Hoje ele assume 1 s depois de sair do chão; passa a começar desligado e só liga pelo korry FBW (ou pelo botão do joystick).
• Tirar a recuperação automática do estol, que só deu problema no jogo. Saiu tudo: o acelerador no máximo, o piloto automático e a trava desligando, o nariz para baixo, a trava ligando sozinha depois e o limite de ângulo de ataque no manche. Fica só o aviso (luz ESTOL e alarme).
• Os modos do piloto automático ligavam sozinhos ao ligar o FBW (o avião tentava subir para uma altitude): era a trava de altitude automática, que saiu. Falta confirmar no jogo.
• Avisar o estol também fora do FBW (na lei direta): a luz ESTOL e o alarme pelo ângulo de ataque, mesmo sem o FBW voando.

Avisos de voo (GPWS)

Status: código escrito e testado sem o jogo; falta ouvir no Pi e voar. Roteiro, limites e como ligar o alto-falante em docs/avisos.md.

Como o GPWS dos aviões de linha, a ponte da tela fala os avisos em inglês, num alto-falante USB ligado no Pi, em qualquer nave voando na atmosfera:

• Vermelhos: PULL UP (descendo rápido demais para a altura) e TERRAIN (o chão chegando rápido; vira PULL UP se continuar).

• Âmbar: SINK RATE, DON'T SINK (perdendo altura depois da decolagem), TOO LOW, GEAR e TOO LOW, TERRAIN (baixo com o trem recolhido), BANK ANGLE e OVERSPEED.

• Chamadas de altura no pouso: 100, 50, 40, 30, 20 e 10 pés.

• Luz GPWS (âmbar) / PULL UP (vermelha) no painel de sistemas; por enquanto, na página de botões.

• bridge/avisos.py: os avisos, a prioridade e a voz (espeak-ng ou gravações em bridge/sons/); --voz, --sem-voz e --testar-voz no mfd.py; testes.

• Luz GPWS / PULL UP na página de botões.

• Ouvir no Pi com o alto-falante USB e ajustar os limites no jogo.

• Luz GPWS no desenho do painel de sistemas.

• Olhar o terreno à frente (EGPWS), pela altura do terreno do kRPC.

Piloto automático de avião

Status: código escrito e testado com o avião simulado e a demonstração; falta testar no jogo. O fbw.py voa HDG, ALT e V/S pedindo um caminho ao FBW (docs/fbw.md), e o painel de sistemas é, por enquanto, uma página de botões aberta pela ponte da tela (docs/mfd.md), com a roda do SAS e a página do piloto na tela.

• Página de botões no celular, no lugar do painel, como a do editor de manobras.
• Ponte da tela (bridge/mfd.py e bridge/sistemas.py): modos do SAS, SAS e RCS no jogo; azul ou verde pelo erro até o marcador; o menu do piloto; as páginas do SAS e do piloto, com a volta à navball.
• Tela do celular e simulador: a roda dos modos do SAS e a página do piloto.
• scripts/fbw.py: HDG, ALT e V/S pedindo um caminho; FBW e TRAVA pelo painel; estado e comandos por UDP com a ponte da tela; testes no avião simulado.
• Testar no jogo: os modos do SAS e as luzes (roteiro), e o piloto automático num avião (roteiro).
• Tela: tirar os botões redondos SAS e RCS da navball. Eles ficam só no painel.
• Tela: as páginas que abrem sozinhas (a roda do SAS, a do piloto e as outras que aparecem por cima da navball) ficam 6 s depois do último toque, em vez de 10 s.
• O painel de verdade: as mesmas linhas pela serial do Mega, e as pontes do painel e da tela juntas.

Inspirado no painel de piloto automático dos aviões de linha (o MCP do Boeing, o FCU do Airbus).

• Modos:
  • HDG: vira para o rumo escolhido e segura.
  • ALT: sobe ou desce até a altitude escolhida e segura. Enquanto não chega, fica armado (azul na tela); ao chegar, nivela e fica verde.
  • V/S: sobe ou desce com a velocidade vertical escolhida. Com o ALT ligado junto, nivela ao chegar na altitude escolhida.
  • SPD: acelerador automático, segura a velocidade escolhida. Fica para depois, como mais uma linha do menu.
  • Sem HDG ligado, a rolagem fica com o manche, e a inclinação fica onde o piloto deixou.
• No painel de sistemas de controle, junto do SAS, do RCS e do FBW:
  • Um encoder só, o AJUSTE, que também mexe nas outras páginas da tela, mexido pelo menu da página do piloto na tela multifunção: girar move o cursor entre HDG, ALT e V/S; apertar escolhe a linha, e girar muda o valor (horário soma); apertar de novo sai; segurar 1 s liga ou desliga o modo da linha. Girando devagar, o valor muda de 1 em 1 (1°, 10 m, 0,1 m/s); rápido, de 10 em 10.
  • Uma luz verde por modo, ao lado do encoder, acesa quando o modo está ligado no FBW. Sem displays de 7 segmentos: os valores ficam na tela.
  • Korry FBW (liga e desliga o FBW, como o botão do joystick) e TRAVA ALT (trava e destrava a altitude do momento).
• Na tela: a página do piloto, com os modos (azul armado, verde ligado) e os valores escolhidos, abre sozinha quando o encoder é mexido e volta para a navball uns 10 s depois. O caminho pedido aparece na navball: é o ponto verde do FBW.
• Por dentro: o piloto automático fica por cima do fly by wire e pede um caminho, como um piloto que não cansa:
  • HDG pede o rumo escolhido, que vira inclinação das asas; sem HDG, a rolagem fica com o manche;
  • ALT, V/S e a TRAVA ALT pedem o ângulo de subida, que vira carga; sem eles, o pitch fica com o manche;
  • SPD liga o acelerador automático que já existe no fbw.py;
  • as proteções do FBW continuam valendo, e mexer no manche devolve o eixo ao piloto.
• Precisa de: o encoder e as luzes do VOO. Para começar, uma página de botões no celular faz o papel do painel.

Pronto quando: um avião decola na mão, e o piloto automático leva ele até a altitude e o rumo escolhidos no painel e segura lá.

Rover com controle de cruzeiro

• Os mesmos botões e encoders HDG e SPD do avião, e o mesmo PID: segura a velocidade e o rumo no chão, pelo acelerador e pela direção das rodas (control.wheel_throttle e control.wheel_steering).
• Freia nas descidas, para não passar da velocidade escolhida.
• Sai quase de graça depois do piloto automático de avião.

Subida até a órbita

Status: voou no jogo em 20/10/2026 e chegou em órbita sozinho, com um foguete de 552 t, a 80 e a 100 km; o giro está em ajuste. scripts/subida.py leva a nave da plataforma até uma órbita circular, em qualquer planeta, com ar ou sem. Como funciona, as contas e o roteiro de teste no jogo estão em docs/subida.md.

• O piloto escolhe a altitude, a inclinação e, se quiser, o plano do alvo escolhido no jogo, na página SUBIDA da tela multifunção, por um encoder. Segura o korry LANCAR 5 s, e o script voa.

• O rumo desconta a rotação do planeta e é refeito a cada passo, pela velocidade que ainda falta. A inclinação final sai a menos de 0,1° da pedida.

• O giro da curva de gravidade é escolhido por simulação: antes de inclinar, o script simula a subida inteira com 16 giros e fica com o de menor Δv, somando a subida e a circularização. Depois, a cada 5 s, ele simula de novo o resto da subida e corrige o nariz em até 4°, em malha fechada.

• Com o plano de um alvo, o script espera a janela de lançamento, com time warp, e no fim iguala o plano numa queima na linha dos nós.

• Os estágios saem sozinhos; o corte é no apoastro pedido, e a circularização, em malha fechada, centrada no apoastro. O próprio script queima: o EXEC ainda não existe.

• Junto com o pouso, fecha o ciclo: do chão até a órbita e de volta.

• scripts/subida.py: a guiagem, a simulação do giro, a janela, o kRPC, o --demo e as linhas SUB; testes em scripts/tests/test_subida.py, numa nave simulada em Kerbin e na Mun.

• Ponte da tela: o korry LANCAR, o menu da subida (ENC SUB, BTN SUB) e a página SUBIDA; na página de botões, o LANCAR e um encoder para a configuração.

• A página SUBIDA na mikromedia e no navegador (o celular e o tablet): a configuração e o voo. O simulador mostra a navball no lugar dela.

• O desenho do voo na página SUBIDA: o KSC na decolagem, a parábola na subida e a órbita na circularização, com dois zooms. No navegador, testado com o --demo; na placa, falta gravar. Falta ver num lançamento. Depois, a visão oblíqua do planeta na órbita.

• Testar no jogo (roteiro): primeiro 80 km e 0°, depois a inclinação, o plano de um alvo e a Mun.

• A configuração pelo encoder AJUSTE, no Uno, com a página SUBIDA aberta (docs/encoder.md).

• Depois: a guiagem do vácuo (PEG), mais eficiente que seguir o pró-grado.

• Depois: lançar na hora certa para o rendezvous. Além de esperar o plano do alvo, o script esperaria a fase: decolar quando o alvo estiver no ângulo certo à frente, para a subida terminar logo atrás dele, e o rendezvous virar só a aproximação final. Na Estação um (quase equatorial, ~37 min de volta), o alvo passa por cima do KSC a cada ~41 min, então a espera é curta. No primeiro voo completo (21/10/2026), a subida sem essa espera terminou a 576 km da estação, e o rendezvous previu 89,6 m/s e 5 h até o encontro.

Pouso de precisão (volta à base)

O pouso da SpaceX completo. O pouso.py desce na vertical onde a nave estiver; aqui o booster volta para um lugar escolhido, como a plataforma do KSC.

• Queima de retorno logo depois da separação: vira a nave e queima até a trajetória cair no alvo.
• Queima de reentrada, para chegar mais devagar nas camadas grossas da atmosfera.
• Na descida, as aletas corrigem a trajetória para o alvo.
• Termina com a queima de suicídio do pouso.py, com a mira puxando para o alvo em vez de só anular a deriva.
• É o mais difícil da lista: precisa prever onde a trajetória cai, com arrasto, como o pouso.py já faz na vertical.

Rendezvous

Status: voou no jogo em 21/10/2026, de 100 km até 111 m da Estação um, com 98,3 m/s gastos (89,6 previstos); a aproximação com RCS de translação também foi testada no jogo. scripts/rendezvous.py leva a nave até 100 m de outra em órbita do mesmo planeta, parada em relação a ela. Como funciona, as contas e o roteiro de teste no jogo estão em docs/rendezvous.md.

O script queima sozinho, porque o EXEC da fase 5 ainda não existe. O nó que ele cria no jogo é só para mostrar: no mapa, o KSP desenha a aproximação, e o piloto confere o plano. Com --so-planejar, o script só cria o nó, imprime o plano e sai.

• As etapas:
  1. Igualar o plano: só se a inclinação relativa passa de 0,05°. Queima na direção normal, no nodo relativo, de Δv = 2·v·sen(Δi/2).
  2. Transferência: a conta pesada. Uma busca com tiro (shooting): para cada momento de queima e tempo de voo, um palpite tangencial e um Newton em 3D acertam a queima para a nave passar 300 m acima do alvo. O momento da queima varre o período sinódico, e o custo é o Δv da queima mais a velocidade relativa no encontro. Serve também quando a nave já está na altitude do alvo, onde uma Hohmann dá 0 m/s. Sem motor, as órbitas seguem Kepler: a previsão é exata.
  3. Correções no meio do caminho: o mesmo tiro, a partir do estado de agora, em frações de volta antes do encontro.
  4. Igualar a velocidade: no momento da menor distância, com a queima igual à diferença entre a velocidade do alvo e a da nave.
  5. Aproximação final, sem nó: aponta para o alvo e vai pelo RCS de translação, sem virar a nave, a até 2 m/s, freando só no fim, e para a uns 100 m. Sem RCS, vai pelo motor. Dali segue o acoplamento assistido.
• Automático ou diretor de voo: o script encadeia as etapas e acelera o tempo entre elas (warp_to). O modo diretor de voo, em que ele só propõe cada nó e o piloto queima, fica para depois.
• Na página do editor de manobras, na tela multifunção: a menor distância prevista até o alvo, quando ela acontece e a velocidade relativa nesse ponto, atualizadas enquanto o encoder e o TEMPO mexem no nó.
• Ordem para fazer, do mais simples ao mais difícil:
  1. Só mostrar a menor distância prevista enquanto o piloto edita os nós na mão. Sem automação, e já é como se faz rendezvous "de olho" no KSP.
  2. Os nós de igualar o plano e igualar a velocidade e a busca da transferência, numa etapa só, para o script já fechar o voo. Testado em voos simulados.
  3. A aproximação final, que já entrou junto. Falta a passagem para o acoplamento.
  4. O plano conferido no jogo (--so-planejar, 21/10/2026): 99,5 m/s previstos de 100 km até a Estação um.
  5. O voo completo no jogo (roteiro), 21/10/2026: 111 m e 0,20 m/s no fim, 98,3 m/s e 117 de monopropelente gastos.
  6. A aproximação com o RCS de translação, sem virar a nave, e com a curva de frenagem até 2 m/s. Testada no jogo em 21/10/2026: de 1,3 km a 59 m, parada a 0,19 m/s. O RCS só fica ligado nela; no resto do voo, quem vira a nave é a roda de reação.
  7. De longe (mais de ~1 km), trocar a reta por um tiro de Kepler: seguir a reta contra a órbita gasta ~2 m/s de RCS a cada 100 m.
• Decidido:
  • Quem prevê as órbitas: uma previsão própria, com a equação de Kepler (as funções f e g), rápida e testável sem o KSP. Com o kRPC, cada pergunta vai pela rede, e a busca faz milhares. O --so-planejar confere a menor distância da previsão própria contra a do kRPC.
  • Queimas longas: começam metade da duração antes do nó, senão o encontro erra por quilômetros, e seguem o Δv que ainda falta, como o KSP. Como o script queima sozinho, a regra está nele; o EXEC, quando existir, usa a mesma.
• Precisa de: só do kRPC e de uma nave com motor aceso; roda pela linha de comando, sem o painel. A etapa 1 da ordem precisa da tela. O EXEC e o editor de manobras só entram no modo diretor de voo.

Acoplamento assistido

• Página nova na tela multifunção: a mira de alinhamento com a porta de acoplamento do alvo, a distância e a velocidade de aproximação.
• O sidestick no modo TRANSLAÇÃO, escolhido pelo botão do manche: o manche move a nave com o RCS, sem girar (os três modos).
• Primeiro manual, com a tela ajudando. Depois automático: a nave se alinha e se aproxima devagar sozinha.
• Precisa de: joystick (fase 2) e a tela multifunção.

Lista de compras

Itens marcados já estão na bancada. Compre por fase — não precisa tudo de uma vez. AliExpress costuma ser mais barato (e lento); Mercado Livre e lojas nacionais chegam mais rápido.

Atenção à tensão: o Mega trabalha em 5V; o Pi, em 3,3V. Nunca ligue um pino do Pi direto em 5V — a comunicação entre os dois é pela USB.

Ferramentas (uma vez só)

• Ferro de solda com controle de temperatura + estanho + malha dessoldadora
• Multímetro
• Alicate de corte e decapador de fios
• Impressora 3D (em casa)
• Corte a laser: no colégio
• Paquímetro (para medir as peças antes de desenhar os furos dos painéis)

Fases 0–1 — Kit inicial

• Arduino Mega 2560 (também tem Uno e Nano)
• Raspberry Pi 4
• Botões
• Fonte para o Pi 4: 5,1V 3A USB-C de boa qualidade (fonte fraca causa travamentos)
• Dissipador ou case com ventoinha (o Pi 4 esquenta, principalmente dentro de uma caixa fechada)
• Cartão microSD de 16 GB ou mais (classe A1)
• Cabo USB-B para ligar o Mega no Pi
• Cabo de rede, para ligar o Pi direto no PC (qualquer um: o Pi 4 inverte os pares sozinho)
• 2× protoboard de 830 pontos
• Jumpers macho-macho e macho-fêmea
• Kit de LEDs 5 mm + kit de resistores (220 Ω–10 kΩ)
• LCD 16x2 ou 20x4 com módulo I2C (só para a fase 1; opcional se já tiver)

Fase 2 — Painel de controle

• 10–15× chaves alavanca (toggle) ON-OFF
• 2–3× capas de proteção para chave ("missile switch cover")
• 4–6× botões arcade (24 ou 30 mm), de preferência com LED
• Por módulo pequeno (5 no painel): 2× 74HC165, 1× 74HC595, 2× rede resistiva 10 kΩ SIP 9 pinos, 1× chave DIP de 8 vias, 8× resistor 1 kΩ, 3× capacitor 100 nF, 1× capacitor 10 µF, 3 soquetes DIP-16, conector IDC 2x8 e cabo flat de 16 vias
• Por módulo médio (5 no painel): 3× 74HC165, 3× 74HC595, 3× rede resistiva 10 kΩ SIP 9 pinos, 1× chave DIP de 8 vias, 24× resistor 220 Ω, 6× capacitor 100 nF, 1× capacitor 470 µF, 12× conector JST-XH de 4 vias, 6 soquetes DIP-16, conector IDC 2x8 e cabo flat de 16 vias
• Por módulo grande (1 no painel, o VOO): 4× 74HC165, 4× 74HC595, 4× rede resistiva 10 kΩ SIP 9 pinos, 1× chave DIP de 8 vias, 32× resistor 1 kΩ, 8× capacitor 100 nF, 1× capacitor 10 µF, 8 soquetes DIP-16, conector IDC 2x8 e cabo flat de 16 vias
• Backplane: 12× conector IDC 2x8, 5× resistor 47 Ω, 13× resistor 10 kΩ, capacitores de 470 µF e 100 nF, borne de 2 vias e jumper de 3 pinos
• Joystick: Logitech Extreme 3D Pro (para desenvolver no PC)
• Sidestick: 1× joystick JH-D400X-R4, 10 kΩ, 3 eixos com botão
• Acelerador: 1× potenciômetro deslizante Bourns PTA6043, 10 kΩ linear, curso de 60 mm
• 35 korry switches (lista completa), cada um com 1 chave PSW 8,5 × 8,5 mm sem trava, até 2 LEDs difusos de alto brilho de 3 mm, 4 fios finos e 1 conector JST-XH fêmea de 4 vias com os terminais; filamento PLA preto e transparente
• 10× LED azul e verde de 3 mm, difuso, catodo comum (korry dos modos do SAS)
• 17× parafuso M3 autoatarraxante de 8 mm, para as 9 grades dos korry (fixação no painel)
• 31× botão de 16 mm sem trava, com anel de 20 mm (R16-503 ou R13-507), e 2 capas impressas para o CARREGAR e o REVERTER
• 2× botão de metal de 22 mm com anel de LED (vermelho e branco), de 5 V ou 3 V, e 2× capa transparente para botão de 22 mm
• 2× tecla KCD1 (ON)-OFF-(ON) de 21 × 15 mm
• 7× LED de 5 mm difuso (3 verdes e 1 vermelho do piloto, 3 brancos do sidestick)
• 7× suporte de plástico com porca para LED de 5 mm
• Placas perfuradas de dupla face + barras de pinos (headers) e fio fino encapado (wire-wrap)

Fase 4 — Instrumentos físicos

• 3–4× módulos MAX7219 com 8 dígitos de 7 segmentos (o piloto automático não usa mais: os valores vão para a tela)
• 2× encoders rotativos (KY-040), para escolher o que os displays mostram
• Editor de manobras (peças e medidas): 1× chave rotativa de 1 polo e 12 posições, com anel de batente, e knob de ponteiro de 22 mm (a tecla, os botões e os korry estão na fase 2)
• Navegação: 1× chave rotativa de 1 polo e 12 posições, com anel de batente, e knob de ponteiro de 22 mm
• VOO, de sistemas de controle (peças e medidas): 1× encoder EC11 com botão e knob de alumínio de 30 mm, o AJUSTE (os korry e os LEDs estão na fase 2); 1 módulo grande
• 2–4× motores de passo X27.168 (ponteiros)
• 1× fonte 5V 3A + conector/borne

Fase 6 — Tela multifunção

• mikromedia for ARM (LPC2148)
• Cabo mini-USB com fios de dados, para a PROG (o antigo alimenta a placa, mas o Windows não reconhece o FT232)
• Cartão microSD (para os sons de alarme)
• Fone ou caixinha de som com plugue P2
• Alto-falante USB para o Pi (a voz dos avisos de voo)
• Gravador JTAG compatível com ARM7 (opcional, só para depurar passo a passo)

Fase 7 — Hardware definitivo

• PCBs fabricadas
• Conectores JST/dupont, parafusos e espaçadores M3
• Material da caixa: MDF 3 mm e acrílico 3 mm (preto ou branco leitoso) para a laser, filamento PLA, primer e tinta spray fosca
• Insertos roscados M3 (colocados a quente nas peças impressas) e pés de borracha
• Extensão USB de painel (para o joystick) e ventoinha 5 V de 40 mm (para o Pi dentro da caixa)

Referências

• kRPC — repositório e documentação
• pySerial
• pygame
• Raspberry Pi — documentação
• Arduino — documentação
• KiCad
• LPC214x User Manual (UM10139) — referência de todos os registradores do LPC2148
• LLVM (clang e ld.lld), que compila o firmware da mikromedia
• Flash Magic — gravação pelo bootloader serial do LPC2148
• Manual e esquemático da mikromedia for ARM (MIKROE-780): site da MikroElektronika
• Bibliotecas úteis para o firmware: LiquidCrystal_I2C, LedControl (MAX7219), FastLED ou Adafruit_NeoPixel (WS2812), SwitecX25 (X27.168)