Betaflight muda política de hardware: o que observar antes de comprar uma FC

O Betaflight publicou em 28 de setembro de 2026 uma nova política de hardware para deixar mais claro quem responde por cada parte do ecossistema. A mudança é relevante principalmente para quem compra controladoras de voo novas, monta drones do zero ou acompanha a compatibilidade de uma FC ao longo das próximas versões do firmware.

A ideia central é simples: o Betaflight corrige o Betaflight, o fabricante dá suporte ao hardware e o piloto responde pela própria montagem.

Parece óbvio. Na prática, não era tão óbvio assim, porque a quantidade de placas suportadas cresceu muito e o time do projeto é pequeno, majoritariamente voluntário. A nova política tenta impedir que problemas de hardware, configuração de target e bugs reais de firmware acabem todos caindo no mesmo balde.

Três estados de suporte para as controladoras

A partir da nova política, as placas exibidas no ecossistema passam a se encaixar em três categorias principais.

Betaflight Supported

É o nível mais forte de suporte.

Nesse caso, o projeto Betaflight revisou o design da placa, incluindo esquemáticos, com base nas diretrizes oficiais para fabricantes. O fabricante também precisa assumir compromissos claros, como manter o target, fornecer documentação e oferecer um canal de suporte.

Se uma regressão de firmware atingir uma placa Betaflight Supported, o próprio projeto trata isso como um problema que precisa ser corrigido antes do lançamento.

Para o piloto, esse é o cenário mais confortável ao escolher hardware novo.

Manufacturer Supported

Aqui, o Betaflight revisou e aceitou a configuração da placa no cloud build, mas não fez uma revisão profunda do projeto eletrônico.

O suporte passa a ser responsabilidade principal do fabricante ou do mantenedor responsável pelo target.

Se uma determinada versão do Betaflight deixar de funcionar naquela placa e o problema não for resolvido, o target pode deixar de aparecer para versões novas, continuando disponível apenas nas versões conhecidas como funcionais.

Isso não quer dizer que a placa seja ruim. Quer dizer apenas que a responsabilidade de mantê-la compatível não está diretamente nas mãos do time Betaflight.

Legacy

São placas antigas que continuam disponíveis, mas não possuem mais um mantenedor ativo.

Elas podem continuar funcionando perfeitamente na versão que você já usa, mas não existe compromisso de adaptação contínua para futuras mudanças do firmware.

Para um drone pronto e estável, isso pode nem ser um problema. Para uma build nova que você pretende manter atualizada por anos, já merece mais atenção.

O que muda na escolha de uma FC nova

A política também define tecnologias que não serão mais aceitas em novos designs enviados ao cloud build.

Entre os exemplos estão novos projetos baseados em STM32F411, algumas combinações de F4/F7 com mais de quatro saídas de motor, receptores SPI integrados e projetos nos quais o gyro compartilha o barramento SPI com outros dispositivos.

O MPU6500 também aparece como componente em fim de vida para novos designs.

Outros componentes não são completamente proibidos, mas passam a ser classificados como não recomendados ou aceitos apenas em situações específicas.

O BMI270, por exemplo, pode ser aceito como segunda opção em um footprint também preparado para ICM-42688-P. O MPU6000 segue possível em condições limitadas, desde que seja uma peça genuína.

A mensagem para quem compra hardware em 2026 é bastante direta: a lista de componentes da FC importa mais do que simplesmente ler “compatível com Betaflight” na caixa.

Sua placa atual não vai parar de funcionar

Esse ponto merece destaque porque todo anúncio desse tipo inevitavelmente produz o clássico pânico de fórum antes de alguém ler a documentação inteira.

A política vale para novos designs enviados a partir de 28 de setembro de 2026.

Placas que já estavam no cloud build mantêm o status atual. Nada que funciona hoje está sendo removido apenas porque utiliza um componente que deixou de ser recomendado para novos projetos.

Portanto, não existe motivo para trocar uma FC funcional só por causa dessa política.

Onde procurar ajuda quando algo dá errado

Outra mudança importante é a divisão mais explícita de responsabilidades.

Problema no firmware, no aplicativo ou no cloud build: Betaflight.

Defeito da placa, documentação, garantia ou configuração específica do target: fabricante.

Erro de ligação, periférico, ajuste da build ou tuning: responsabilidade do piloto, normalmente com apoio da comunidade.

Essa distinção pode acelerar muito um diagnóstico.

Uma FC que reinicia quando o VTX é ligado, por exemplo, pode ter um problema elétrico da própria build. Um target que desaparece do flasher pode ser uma questão de manutenção do fabricante. Já uma regressão que afeta várias placas diferentes pode ser um bug real no Betaflight.

Mandar cada problema para o lugar certo economiza o tempo de todo mundo.

O que observar antes da próxima compra

Para quem está escolhendo uma controladora nova, vale acrescentar algumas perguntas ao checklist:

• qual é o status de suporte daquela placa;
• o fabricante mantém documentação atualizada;
• existe um target oficial no cloud build;
• quais MCU e gyro estão sendo usados;
• o fabricante possui histórico de atualização dos targets;
• o projeto segue as recomendações atuais do Betaflight.

Não é necessário transformar a compra de uma FC em tese de doutorado, embora nós humanos pareçamos particularmente talentosos em fazer isso com qualquer hobby.

Mas uma checagem de cinco minutos pode evitar comprar uma placa que nasce tecnicamente ultrapassada.

Uma mudança saudável para o ecossistema

A política não reduz a abertura do Betaflight. Fabricantes continuam livres para distribuir seu próprio firmware para placas que não entrem no cloud build oficial.

O que muda é a clareza sobre o que o projeto realmente revisa, mantém e assume como suporte.

Para pilotos, isso cria um sinal adicional de qualidade ao avaliar uma FC.

Para fabricantes, aumenta a pressão por documentação, manutenção de target e decisões de hardware mais sustentáveis.

E para o time Betaflight, significa menos tempo tentando diagnosticar cada placa do planeta e mais tempo trabalhando no firmware que todas elas usam.

No fim, a mudança transforma uma área antes meio nebulosa em algo mais verificável: antes de comprar uma controladora, agora faz sentido olhar não apenas para quantidade de UARTs, BEC e memória de Blackbox, mas também para quem vai continuar cuidando daquela placa quando a próxima versão do Betaflight chegar.

Crédito da capa: Imagem gerada por IA — FPV Brazil Hub. Ilustração conceitual.

Fontes

• Fonte 1
• Fonte 2
• Fonte 3
• Fonte 4