Ajuste de PID no Betaflight a partir do Blackbox: corrija a causa, não o sintoma

Seu drone passa do ponto depois de um flip. A resposta no fórum é "reduza P" ou "aumente D". O problema: o mesmo overshoot pode ter três causas, e duas delas exigem correções opostas. Se o feedforward estiver causando isso, reduzir P piora o problema. Se faltar amortecimento no loop, reduzir FF não muda nada. O log mostra qual é o seu caso. Veja como o bbdoctor interpreta os dados, com validação em seis logs reais do Betaflight 3.1.5 ao 2026.6.

Ordem do trabalho: mecânica → ruído → PID

1. Mecânica. Hélices boas, motores sem folga, frame firme e bateria que não se desloca. Nenhum PID corrige uma hélice empenada.
2. Ruído e filtros. Filtro RPM (DShot bidirecional), filtragem sensata e motores frios depois do voo. Veja o guia de ruído e filtros.
3. PID. Primeiro roll e pitch (P/D e feedforward), depois I, TPA e anti-gravity.

Por quê? D é a derivada do giroscópio, então amplifica o ruído de alta frequência e o envia direto aos motores. O bbdoctor não sugere aumentar D quando o ruído de alta frequência dos motores passa de 2.5% da faixa dos motores, quando o ruído do PID vem principalmente do termo D ou quando o ruído bruto do giroscópio acima de 80 Hz chega a 10 deg/s. No caso 4.2.5 abaixo, o loop precisava de mais D, mas o ruído bruto do giroscópio, de 35.8 deg/s, mudou a recomendação para P −10% (p_roll 42 → 38) e revisão da mecânica primeiro.

O log necessário

• ACRO. Faça 30–60 segundos de rolls e flips bruscos em cada eixo, levando o stick rapidamente de volta ao centro. Em ANGLE e HORIZON no Betaflight e INAV, o setpoint vem do loop de ângulo, não do stick; se mais da metade do voo estiver em auto nivelamento, a resposta não é calculada. ArduPilot e PX4 registram o alvo do controlador de taxa (RATE.RDes, vehicle_rates_setpoint), então a resposta é válida em qualquer modo.
• Taxa de registro. A resposta ao degrau funciona a partir de 200 Hz; 1 kHz é o mínimo prático. Abaixo de 500 Hz, o bbdoctor não consegue medir quanto D realmente sobe e limita o diagnóstico de oscilação a "info".
• Quantidade de movimentos. O voo é dividido em janelas de 1 segundo, a cada 1/8 s; são mantidas as janelas em que o stick pediu pelo menos 20 deg/s. Um diagnóstico por eixo exige 10 janelas utilizáveis (e pelo menos um quarto do total); um diagnóstico "critical" e a análise da causa exigem 50. As janelas se sobrepõem, então 65 janelas correspondem a cerca de 8 segundos de voo ativo.
• Registre o campo setpoint; veja os detalhes de configuração em configuração do blackbox.

Como ler a resposta ao degrau

A resposta ao degrau mostra como o drone giraria se você movesse o stick instantaneamente para uma determinada taxa. 1.0 é a taxa solicitada. Uma boa curva sobe rápido, passa um pouco de 1.0 e se estabiliza logo em seguida.

Overshoot

Quanto o pico ultrapassa 1.0; até 15% é normal. O diagnóstico usa o intervalo de 90%, não um único número:

• warn quando o limite inferior passa de 15%, crit acima de 35% (com pelo menos 50 janelas);
• fine quando a estimativa é de até 15% e o limite superior, de até 25%;
• borderline quando a estimativa passa um pouco de 15%, com intervalo estreito: ainda não mude nada; compare com o próximo log;
• uncertain quando o intervalo tem mais de 15 pontos: na próxima vez, faça mais 5–6 movimentos nesse eixo.

Amortecimento ζ

O bbdoctor ajusta um modelo de segunda ordem à curva e calcula sua razão de amortecimento ζ, que indica quanto overshoot o loop P/D produz sozinho:

O bbdoctor só aponta oscilação quando dois sinais coincidem: ζ de no máximo 0.5 e queda abaixo do alvo de pelo menos 4% (pelo menos 2% com 90% de confiança). O nível é warn com ζ de até 0.40 ou queda de 15% ou mais. Se o modelo se ajusta mal, ζ não aparece e só a queda determina o resultado, no máximo em nível info. Oscilação abaixo de 6 Hz em um drone de 5 polegadas aponta para o termo I ou uma aeronave pesada, não D.

Velocidade

• t50 é o tempo para chegar à metade da taxa solicitada: 7–12 ms nos logs responsivos deste guia.
• Atraso entre setpoint e rotação vai da mudança do setpoint até o pico da reação, passando pelo loop inteiro: PID, FF, filtros, motores e hélices. O normal é 4–12 ms com feedforward, até 15 ms sem ele. A partir de 20 ms, o eixo é considerado lento e o bbdoctor não recomenda reduzir P nele. O caminho do rádio se soma a isso (12 ms no caso GEPRC abaixo).

Como a curva é construída

Ninguém move o stick em degraus perfeitos, então a resposta é reconstruída de trás para frente (deconvolução): para cada janela de 1 segundo, qual reação a um degrau instantâneo transforma esta entrada do stick neste traçado do giroscópio? Há duas armadilhas:

• Altas frequências. Acima de cerca de 25 Hz, os movimentos do stick não têm energia, então a deconvolução calcula apenas ruído. O PID-Analyzer corta essa faixa com um corte acentuado perto de 25 Hz, mas o corte acentuado cria sua própria ondulação (efeito Gibbs): cerca de 10% de overshoot em uma resposta que não tem nenhum. O bbdoctor suprime tudo acima de 80 Hz e suaviza com uma gaussiana de 30 Hz, sem lóbulos negativos e sem inventar um ressalto.
• Viés do próprio método. O janelamento e a suavização ainda deixam um pequeno ressalto, então o mesmo cálculo é aplicado a uma resposta perfeita, com o setpoint atrasado pelo mesmo t50, e o overshoot resultante (1–5% nos nossos logs) é subtraído. Em dados sintéticos, um atraso puro resulta em 0%, e um sistema ζ 0.5 em 15%, diante dos 16% reais.

A curva é a mediana entre janelas; o intervalo vem de um bootstrap (200 reembaralhamentos aleatórios das janelas), daí "47% (90%: 44–53%)" no relatório. Portanto, 10% de "overshoot" em uma ferramenta com corte acentuado pode ser puro artefato.

Um overshoot, três causas

Mais três padrões, verificados separadamente:

• o overshoot aumenta com acelerador alto: é TPA; veja TPA e anti-gravity;
• movimentos suaves têm mais overshoot do que os bruscos: D base baixo demais; o boost só funciona nos movimentos bruscos; veja D Max vs D Min;
• movimentos bruscos têm mais overshoot do que os suaves: boost de feedforward; veja feedforward e suavização de RC.

Cinco casos reais

A referência: 2% com ζ 0.73

O log plasmatree_good_tune (Betaflight 3.1.5) é a referência de bom ajuste entre os logs usados para calibrar os limites do bbdoctor. Roll 2% (90%: 1–3%), pitch 5%, sem overshoot em yaw. Roll ζ 0.73, sem queda, t50 9 ms, atraso entre setpoint e rotação 10 ms. Não copie P 19, I 12, D 18 para o 4.x: filtragem, D e feedforward funcionam de outra forma nessa versão.

Ajuste padrão 3.1.5: 87% pelo peso do setpoint

O log 18_stock_tune, 7.9 kHz. Roll 87% (79–93%), pitch 65%. O 3.x não registra o setpoint, então ele é reconstruído a partir dos sticks e das taxas. Nos movimentos mais bruscos, o giroscópio se adianta ao setpoint, algo que um loop sem impulso do stick não consegue fazer; o impulso vem de dterm_setpoint_weight = 190, substituto do feedforward no 3.x. A recomendação é 190 → 100, uma configuração para todos os eixos. Roll também oscila (ζ 0.36), mas aumentar D é apenas o próximo passo: d_roll 20 → 23 se a oscilação continuar.

Drone de 3.5 polegadas no 4.5.2: 47%, quase tudo FF

O log vx35_18-23. Roll 47% (44–53%), t50 7 ms. Feedforward faz 60% do trabalho, com erro de tracking quase zero nos movimentos mais bruscos. Com ζ 0.62, o loop sozinho teria cerca de 9% de overshoot; FF acrescenta o restante. Pitch: 27%, FF faz 59%. A recomendação altera apenas FF:

set f_roll = 102
set f_pitch = 106
set simplified_pids_mode = OFF
save

A linha do slider é necessária porque os PIDs deste log já não correspondem aos sliders e seriam substituídos ao salvar. Além disso, o boost de D só sobe até ×1.15 do valor configurado ×1.67, então o drone voa principalmente com d_min_roll = 30, não 50.

Betaflight 2026.6: 35% causado pelo próprio loop

Log de um GEPRC F405 gravado a 247 Hz. Roll 35% (33–38%). FF faz apenas 29% do trabalho e o drone não se adianta ao stick, então não é feedforward. Depois do pico, a resposta cai 5% abaixo do alvo e oscila a ~9 Hz, ζ 0.49 (provavelmente 0.42–0.50). Pitch é parecido (ζ 0.50), então os dois eixos recebem uma correção: D base +15%.

set d_roll = 39
set d_max_roll = 46
set d_pitch = 53
set d_max_pitch = 63
set simplified_pids_mode = OFF
save

Reduzir P está fora de questão: roll já leva 24 ms e pitch 28 ms, além dos ~12 ms do link de rádio de 50 pacotes/s antes de o stick sequer chegar ao setpoint. A 247 Hz, o log não mostra ruído de D, então toque nos motores depois de um primeiro voo de 1–2 minutos.

Betaflight 4.2.5: 32% em movimentos suaves, 1% nos bruscos

O log v0002, 2 kHz. Roll 23%, causado pelo loop. Separando por tamanho do movimento do stick, movimentos suaves (até 101 deg/s) têm overshoot de 32%, os bruscos (a partir de 800 deg/s), 1%. D chega ao limite de ×1.52 nos movimentos bruscos (d_min_roll 23 → d_roll 35), enquanto os suaves usam o D base 23. A correção clássica seria aumentar o D base, mas este giroscópio tem muito ruído (veja a primeira seção), então a recomendação é P −10%.

P, I e D, um de cada vez

• P dá rigidez. D insuficiente para o P atual provoca overshoot e oscilação; P insuficiente deixa a resposta mole, aumenta o atraso e faz o drone segurar pior a trajetória no propwash. Reduza P para corrigir overshoot apenas quando a causa for o loop e o eixo não for lento.
• I mantém o drone contra forças constantes: centro de gravidade deslocado, vento, manobras longas. I demais em relação a P provoca uma oscilação lenta de 1.5–10 Hz em voo tranquilo. O bbdoctor procura um pico estreito no erro de tracking com o stick dentro de ±40 deg/s e verifica se o termo I provoca isso (coerência com o erro ≥ 0.5, I/P nessa frequência ≥ 1); então recomenda I −15%. Caso contrário, é folga (cinta da bateria, mastro do GPS) ou vento, e os ganhos ficam como estão. Se I ficar no limite por longos períodos (verificado no 2025.12+), algo continua puxando o drone: centro de gravidade, motor inclinado ou hélice. Bounce-back depois de flips muitas vezes também é I; veja bounce-back depois de flips.
• D fornece amortecimento e é o principal motivo de os motores esquentarem. O bbdoctor mede o D que realmente funciona em voo, não apenas o valor configurado. D base e boost: D Max vs D Min.

Quando roll e pitch respondem de forma diferente

No mesmo log VX3.5, o atraso de roll é 3.8 ms (90%: 2.9–5.0) e o de pitch é 9.5 ms (8.5–10.6). Os intervalos não se sobrepõem, então a diferença é real, e os ganhos explicam isso: P de pitch 42, P de roll 59. Quando o P do eixo mais lento é inferior a 85% do eixo mais rápido, o bbdoctor diz que isso, por si só, explica a diferença. Conclua primeiro os ajustes de overshoot; depois reduza P de roll em direção a ~50 em vez de aumentar pitch, que já tem overshoot. Sem diferença de P, uma causa comum é a distribuição de peso: uma bateria longe do centro aumenta a inércia de pitch.

Nomes de D por versão e a armadilha dos sliders

A mesma recomendação, "aumente d_roll", aumenta o D base no 2025.12, mas apenas o limite no 4.5, que o drone talvez raramente alcance. Exemplo para 4.5 (base 30, limite 50), +10% de amortecimento em roll:

set d_min_roll = 33
set d_roll = 55
set simplified_pids_mode = OFF
save

Sliders. Enquanto simplified_pids_mode estiver ON, o Configurator recalcula os PIDs a partir dos sliders ao salvar e apaga as mudanças manuais. Nunca execute simplified_tuning apply sobre um ajuste manual: isso reconstrói os PIDs usando os multiplicadores dos sliders aplicados aos padrões de fábrica.

INAV, ArduPilot, PX4

• INAV: mc_p_roll, mc_i_roll, mc_d_roll, mc_cd_roll (CD é feedforward), e o mesmo para pitch e yaw. TPA é tpa_rate e tpa_breakpoint. Saiba mais em análise de blackbox do INAV.
• ArduPilot: ATC_RAT_RLL_P/_I/_D/_FF, e o mesmo para PIT e YAW. No ArduCopter, comece com o AUTOTUNE integrado e use o log para conferir o resultado. Você precisa de registro rápido (o bit ATTITUDE_FAST em LOG_BITMASK). Saiba mais em análise de logs do ArduPilot.
• PX4: MC_ROLLRATE_P/_I/_D/_FF. MC_ROLLRATE_K multiplica P, I e D juntos, então leve isso em conta. Para autotune: MC_AT_EN = 1, depois inicie pelo QGroundControl (PID Tuning). Registre com o bit High rate em SDLOG_PROFILE. Veja análise de ULog do PX4.

Segurança

• Retire as hélices sempre que estiver na CLI com a bateria conectada.
• Uma mudança por voo, 10–15% por etapa, senão você não saberá o que funcionou.
• Faça o primeiro voo após uma mudança curto e baixo, com o dedo no disarm.
• Depois de um minuto no ar, toque nos motores. Se estiverem claramente mais quentes, reverta.
• Não tente zerar tudo: 5–12% de overshoot com linha reta depois do pico é um bom ajuste, não um problema.
• Tremedeira nos cortes de acelerador é outra questão: veja propwash.

Confira seu próprio log

Envie seu log para o bbdoctor, grátis. O relatório mostra o overshoot por eixo e seu intervalo, ζ, a queda, a participação do FF no trabalho, o atraso e a diferença entre eixos, além de comandos CLI gerados a partir dos seus valores atuais com os nomes corretos para sua versão. Veja um relatório de exemplo e confira suas configurações sem voar usando um diff all na página de verificação da configuração.

Atualizado: 2026-10-22