Motores quentes no Betaflight: ajuste os filtros pelo log do Blackbox

Motores quentes demais para tocar depois de um pack, chiado nos punch-outs, jello, zumbido no hover: isso é ruído, e a reação instintiva é mexer nos filtros. Mas os filtros não removem a causa. Eles escondem problemas mecânicos, acrescentam atraso e não resolvem nada quando o ruído vem do feedforward reagindo ao seu rádio. A seguir: os quatro números que o bbdoctor extrai de um log para encontrar a origem, logs reais de cada caso e a ordem das correções.

Por que o ruído esquenta os motores

O giroscópio detecta mais do que o movimento do drone: hélice desbalanceada, rolamento áspero, braço flexionando, stack solto. Os filtros cortam parte disso, e o restante entra no loop PID. P deixa o ruído passar direto. D é uma derivada, então sua saída cresce com a frequência: antes do passa-baixa do termo D, uma vibração de 300 Hz com a mesma amplitude de uma oscilação de 30 Hz gera dez vezes mais D.

Esse ruído acaba nos comandos dos motores, e um rotor com hélice não consegue acompanhá-lo. Quando o bbdoctor compara o RPM com o comando, considera cerca de 20 ms de atraso do rotor, o equivalente a um passa-baixa de 8 Hz. A 80 Hz, o RPM acompanha com uma intensidade cerca de dez vezes menor; a 300 Hz, quase não se move. Não há empuxo, mas a corrente nos enrolamentos ainda oscila a cada ciclo e vira calor no ESC e no motor. Daí a referência a 80 Hz.

Os quatro números

Tudo usa apenas dados durante o voo; “ruído” significa RMS acima de 80 Hz.

O quinto número é qual termo carrega o ruído. Betaflight e INAV registram os termos PID separadamente (axisP, axisD, axisF). O bbdoctor aplica um passa-alta de 80 Hz a cada um, converte para porcentagem do curso do motor (uma soma PID de 1000 equivale ao curso total) e calcula a participação de cada termo na energia do ruído: 60% ou mais indica a origem; abaixo disso, o resultado é “misto”.

Dois detalhes. O atraso compara o giroscópio bruto com o filtrado, então cobre apenas a cadeia do giroscópio (passa-baixa, notches, filtro RPM), e não os filtros do termo D mais adiante. E o ruído dos motores fica na casa das centenas de hertz, que um log a 250 Hz não consegue captar (ele para em 125 Hz); por isso o mínimo de 500 Hz.

De onde vem o ruído: quatro casos

Mecânica: ruído no giroscópio bruto

Log A na figura: Betaflight 4.2.5, 215 segundos de voo. O ruído bruto é 35.8 deg/s em roll e 23.8 em pitch. Depois dos filtros, fica em 1.34 deg/s e os motores estão limpos: o relatório classifica o ruído bruto como crítico, mas considera os filtros adequados. Os filtros fizeram o trabalho, ao custo de 3.2 ms de atraso, o maior entre todos os logs deste guia. Se você avaliar pelo giroscópio filtrado ou pelos motores, não vai perceber; mas aquela elevação em 200–450 Hz vem das hélices, dos motores ou de alguma peça solta.

A correção é usar uma chave de fenda e colocar hélices novas, não mexer nos filtros. Quando o ruído bruto diminuir, os filtros terão margem de verdade para recuperar parte do atraso. Para descobrir qual motor ou hélice está causando isso: como encontrar um motor ou uma hélice com problema pelo log.

O tune: o ruído passa pelos filtros e o termo D carrega

Log C na segunda figura: um whoop 1S com INAV 8.0. Giroscópio bruto em 22.1 deg/s, 4.8 depois dos filtros; portanto, o ruído está passando. O ruído HF dos motores está em 5.5%, nível crítico, e 97% dele vem do D. Faz sentido reduzir o D ou os cortes dos filtros do termo D, mas com 4.8 deg/s ainda depois da filtragem, as hélices e o frame também precisam de atenção (D amplifica tudo o que passa). E primeiro vem um ganho que parece erro de digitação (abaixo).

O D pode ser o problema mesmo com ruído nos motores abaixo de 2.5%. Quando só o D envia 1.5% do curso aos motores (3% é crítico), o bbdoctor mostra um achado separado: “O ruído do termo D chega aos motores”, com uma sequência de recomendações: giroscópio filtrado em 1 deg/s ou mais? Comece pela mecânica; filtro RPM desligado (dshot_bidir = OFF ou rpm_filter_harmonics = 0)? Ative-o; depois reduza em 15% os cortes dos filtros do termo D em relação aos valores atuais. Se o filtro do termo D já estiver abaixo de 70 Hz, reduza o D em 10% no lugar, pois baixar mais o corte acrescenta atraso com pouco benefício. Os motores continuam quentes? Reduza o D em 10% no próximo voo. Com ruído nos motores acima de 2.5%, a recomendação é mais curta: mecânica, depois reduzir os cortes dos filtros do termo D em 15% ou reduzir o D.

Jitter de feedforward causado pelo rádio

Log A na segunda figura: um VX3.5 com Betaflight 4.5.2, log a 1 kHz, ruído HF dos motores em 3.0%, nível de atenção. A recomendação padrão de reduzir os filtros do termo D ou o D não faria nada: o D carrega 4% do ruído, P menos de 1% e feedforward, 96%. FF é a derivada do stick, e como o rádio envia comandos em pacotes, cada mudança de pacote dá um tranco. Neste caso, FF acima de 40 Hz representou 3.6% do curso do motor em roll, com 51 trancos por segundo acima de 5% do curso ao longo de 112 segundos movimentando os sticks.

O sinal, mesmo sem análise: motores ruidosos enquanto você movimenta os sticks, silenciosos no hover. O mesmo relatório mostrou overshoot de 25–31%, então o primeiro passo do bbdoctor é reduzir o FF por causa desse achado; depois, usar averaging e smoothing e, no voo seguinte, mudar feedforward_jitter_factor de 7 para 12:

set feedforward_averaging = 2_POINT
set feedforward_smooth_factor = 65
save

Esses são os nomes usados no Betaflight 4.3 ou mais recente. No 4.2, o bbdoctor usa ff_interpolate_sp (AVERAGED_2 ou AVERAGED_3 em um link a 500 Hz), ff_spike_limit (reduza para 50) e rc_smoothing_auto_smoothness (aumente para 20). Veja como o overshoot de FF aparece na resposta ao degrau: ajuste PID a partir do blackbox.

Um ganho que parece erro de digitação

O mesmo whoop: P em roll 17 e D 50; P em pitch 40 e D 35 (padrão do INAV: D 23 com P 40). Em um eixo, D é três vezes P; no outro, fica abaixo de P. No log, o termo D em roll é 12 vezes mais forte que P. O bbdoctor identifica esse padrão (D pelo menos 2×P em um eixo e no máximo P no outro) como provável erro de digitação e o coloca em primeiro lugar, pois basta uma linha na CLI: D × 0.7 naquele eixo. Se o ruído continuar, cuide da mecânica e dos filtros do termo D:

set mc_d_roll = 35
save

Participação e intensidade são coisas diferentes. No log B, D carrega 83% do ruído, mas isso equivale a apenas 0.5% do curso: nada que precise de correção. A participação indica o que corrigir; a intensidade indica se vale a pena.

Ordem das correções

1. Mecânica. Use hélices novas do mesmo lote, aperte os parafusos dos motores e gire cada motor com a mão: deve girar suavemente, sem raspar nem ter folga. Verifique se há braços rachados, se o stack está em suportes macios e se nada está balançando: câmera, antena, cinta da bateria.
2. Filtro RPM. Você precisa de DShot bidirecional (dshot_bidir = ON), ESCs com Bluejay, AM32 ou BLHeli_32 e o valor correto de motor_poles (o número de ímãs no sino). Configure os harmônicos com rpm_filter_harmonics ou gyro_rpm_notch_harmonics nas versões 4.1–4.2; 0 significa que o filtro está desligado. Para confirmar que funciona, registre o RPM também: veja configuração do blackbox.
3. Notch dinâmico para ressonâncias que não acompanham o RPM. Com o filtro RPM funcionando, normalmente bastam 1–2 notches (dyn_notch_count, BF 4.3 ou mais recente). O bbdoctor considera um pico que permanece na mesma frequência em diferentes aceleradores (6 dB acima do piso em pelo menos 60% das faixas de acelerador, acima de 60 Hz) uma ressonância do frame ou do stack. Ele só sugere um notch estático quando a frequência não deixa dúvida: o log roda na taxa do loop PID ou foi gravado a 2 kHz ou mais e o pico está abaixo da metade da frequência de Nyquist. Em três logs 6S no 4.5.1 (gravados a 1013 Hz com loop PID de 4 kHz), os picos aparecem em 186–226 Hz; um pico de “206 Hz” pode, na verdade, estar em 206, 807 ou 1219 Hz. Em vez de sugerir um notch às cegas, o bbdoctor pede um log curto com blackbox_sample_rate = 1/1.
4. Filtros passa-baixa. Reduza 15% em relação aos valores atuais: os do termo D se o D carregar o ruído; os do giroscópio se o ruído passar pelos filtros ou se P o carregar. Não reduza o filtro do termo D para menos de 70 Hz.
5. D por último, e somente se o D carregar o ruído e os filtros já estiverem baixos. Os nomes do D mudaram em 2025.12; veja abaixo.

Uma exceção a essa ordem: corrija primeiro um ganho que parece erro de digitação. Faça uma mudança por voo. Depois de cada mudança, voe por 30–60 segundos, pouse, desconecte a bateria e toque nos motores. Esfriou? Mantenha a mudança. Não esfriou? Reverta.

A regra principal: não aumente o D com motores quentes e ruidosos, nem para combater propwash. O inverso também vale: se o relatório mostrar overshoot em roll ou pitch, não reduza o D para esfriar os motores; o overshoot vai aumentar, então o bbdoctor se limita à mecânica e aos filtros do termo D.

Nomes dos filtros nas versões do Betaflight

O 2025.12 mantém os nomes dos filtros, mas muda o significado de D: o valor base agora é d_roll/d_pitch e o valor máximo é d_max_roll/d_max_pitch.

A armadilha do slider (4.3 ou mais recente): com simplified_dterm_filter = ON, salvar uma aba do Configurator com sliders recalcula os cortes a partir do multiplicador e apaga os valores ajustados manualmente. Um log real de VX3.5 tem o termo D em 180/420 Hz com o slider ligado em 100, o que levaria aos valores padrão de 75/150; portanto, esses cortes foram definidos manualmente ou por um preset. Vai mudar os cortes pela CLI? Desligue o slider.

Use os valores atuais como base (get dterm_lpf mostra esses valores). O bbdoctor os lê no cabeçalho do log, multiplica cada corte por 0.85 (ou 1.15 para aumentá-lo) e desliga o slider. Para o termo D deste VX3.5 (180/420 Hz, passa-baixa 1 em 158, passa-baixa 2 em 150), uma redução de 15% fica assim; são apenas contas, pois nesse log quem carrega o ruído é o FF:

set dterm_lpf1_dyn_min_hz = 153
set dterm_lpf1_dyn_max_hz = 357
set dterm_lpf1_static_hz = 134
set dterm_lpf2_static_hz = 128
set simplified_dterm_filter = OFF
save

E não use simplified_tuning apply como solução rápida: ele recalcula os filtros e PIDs a partir dos valores padrão do Betaflight, não dos seus, e apaga silenciosamente o tune manual.

Quando você pode aliviar os filtros

Menos filtragem significa menos atraso e melhor resposta ao propwash. O bbdoctor só sugere aumentar os cortes dos filtros do giroscópio em 15% quando todas estas condições são atendidas:

• ruído filtrado abaixo de 1 deg/s em roll e pitch;
• atraso acima de 1.5 ms; caso contrário, não há nada a recuperar;
• giroscópio bruto abaixo de 4 deg/s;
• sem ressonância no frame;
• log gravado a 500 Hz ou mais.

Com os valores padrão do 4.5 (250/500 Hz, passa-baixa 2 em 500), os comandos seriam:

set gyro_lpf1_dyn_min_hz = 288
set gyro_lpf1_dyn_max_hz = 575
set gyro_lpf1_static_hz = 288
set gyro_lpf2_static_hz = 575
set simplified_gyro_filter = OFF
save

Quando o ruído e o atraso permitem, mas o giroscópio bruto está ruidoso ou há uma ressonância, o relatório indica que existe margem, mas ainda é cedo para aliviar os filtros. Caso contrário, considera os filtros adequados (ou alerta se o giroscópio filtrado passar de 3 deg/s); se o log estiver abaixo de 500 Hz, não dá um parecer favorável a aliviar os filtros. Um log 6S no 4.5.1 com exatamente esses valores padrão: 0.6 deg/s filtrado e 2.2 ms de atraso, bastante margem no papel, mas 7.4 deg/s bruto e uma ressonância em 206 Hz. Os filtros estão ocupados com a mecânica ruidosa, e aliviá-los envia esse ruído aos motores. Um log 6S no 4.2 a 534 Hz: 0.31 deg/s filtrado, 2.8 ms, mas 4.7 bruto, então também é cedo. Dos 17 logs em que consegui medir o giroscópio bruto e o atraso, nenhum atendeu às cinco condições. Uma mecânica limpa é mais rara do que muita gente pensa.

Atraso e propwash

O atraso é o preço da filtragem. Nos logs deste guia, vai de 0.8 ms (INAV 6.0) a 3.2 ms (o log 4.2.5 com a elevação). Converta-o em fase para avaliar: a 50 Hz, na faixa central do propwash, 1 ms equivale a 18° de atraso e 3.2 ms já chega a 58°. Quanto mais tarde o loop percebe uma oscilação, pior consegue amortecê-la: daí vem o propwash; com atraso suficiente, o próprio loop começa a oscilar.

Dois voos do VX3.5 no 4.5.2: o primeiro com passa-baixa do giroscópio em 250/500 Hz e termo D em 75/150; o segundo em 300/700 e 180/420. O atraso caiu de 2.2 para 1.2 ms, e o pior valor de ruído filtrado entre os eixos ficou em torno de 1.4–1.5 deg/s nas duas vezes. O ruído HF dos motores subiu de 1.6 para 3.0%, mas 96% no segundo voo vinha do feedforward, com os sticks em movimento por 112 segundos, contra 45 no primeiro. Reduzir os filtros do termo D para esfriar os motores não faria sentido. Para ver o atraso na resposta ao degrau, consulte ajuste PID a partir do blackbox.

Erros comuns

• Reduzir os filtros quando o FF carrega o ruído. O atraso aumenta e os motores continuam igualmente quentes.
• Aumentar o D com motores quentes para combater propwash ou conseguir uma sensação de drone “travado”. O D amplifica justamente as frequências altas.
• Avaliar o ruído com um log a 250 Hz. Ele só capta até 125 Hz, e o ruído dos motores a 300 Hz aparece rebatido em 50 Hz (300 − 250), onde parece uma oscilação lenta. Veja a configuração do blackbox.
• Aplicar um notch a um pico de um log lento sem confirmar se a frequência é inequívoca: você corta a frequência errada e acrescenta atraso.

INAV, ArduPilot e PX4

INAV. O passa-baixa do giroscópio é gyro_main_lpf_hz (60 Hz por padrão); o dinâmico varia entre gyro_dyn_lpf_min_hz e gyro_dyn_lpf_max_hz e é ativado com gyro_use_dyn_lpf = ON até a versão 7.x ou com gyro_filter_mode = DYNAMIC a partir da 8.0 (que também adiciona ADAPTIVE). O passa-baixa do termo D é dterm_lpf_hz (110 por padrão, 120 no whoop acima). D é mc_d_roll/mc_d_pitch; FF é mc_cd_roll/mc_cd_pitch. O filtro RPM, rpm_gyro_filter_enabled, só funciona com um fio separado de telemetria do ESC. Saiba mais em análise do blackbox no INAV.

ArduPilot. O passa-baixa do giroscópio é INS_GYRO_FILTER (20 Hz na maioria dos logs do ArduCopter que testei); o filtro D é ATC_RAT_RLL_FLTD/ATC_RAT_PIT_FLTD. O bbdoctor ajusta os valores da mesma forma, × 0.85 ou × 1.15. O ruído dos motores e as ressonâncias são tratados pelo notch harmônico INS_HNTCH_*, controlado pelo acelerador, pela telemetria do ESC ou por FFT. Para uma ressonância fixa do frame com frequência inequívoca, o bbdoctor sugere o segundo notch, INS_HNTC2_* com INS_HNTC2_MODE = 0. Saiba mais em análise de logs do ArduPilot.

PX4. O passa-baixa do giroscópio é IMU_GYRO_CUTOFF; o filtro D é IMU_DGYRO_CUTOFF. No PX4, o deslocamento temporal entre tópicos registrados não é o atraso do filtro (pode aparecer como 0 com um corte de 30–60 Hz), então o bbdoctor estima o atraso pela configuração: √2/(2π·fc) para um passa-baixa de segunda ordem. A 40 Hz, valor que aparece na maioria dos logs PX4 que testei, são 5.6 ms, mais do que em qualquer log Betaflight acima. A 70 Hz, são 3.2 ms. O notch estático é IMU_GYRO_NF0_FRQ/IMU_GYRO_NF0_BW (1.13 ou posterior; antes, IMU_GYRO_NF_FREQ/IMU_GYRO_NF_BW), e o notch dinâmico (RPM do ESC ou FFT) é IMU_GYRO_DNF_EN. Saiba mais em análise de ULog do PX4.

Verifique automaticamente

Envie seu log para o bbdoctor: Betaflight .bbl e .bfl, INAV .txt, ArduPilot .bin ou PX4 .ulg. O relatório calcula os quatro números, separa o ruído dos motores por P, D e FF, verifica se as ressonâncias têm uma frequência inequívoca e fornece comandos CLI ajustados a partir dos cortes atuais, desligando o slider quando necessário. Veja o relatório de exemplo. Ainda não tem um log, mas tem um diff all? A verificação da configuração identifica passa-baixa e notch dinâmico desligados, filtro RPM sem telemetria e sliders longe de 1.0.

Atualizado: 2026-10-22