Análise do Blackbox do INAV: ajuste de PIDs e filtros com base no seu log

Muita gente usa o INAV para navegação: manutenção de posição, retorno ao ponto de partida e missões. Tudo isso depende do loop interno de taxa. Se o giroscópio tiver ruído e os PIDs estiverem mal ajustados, o quadricóptero mantém pior a altitude, oscila no POSHOLD e superaquece os motores. A seguir: como gravar um log que valha a pena analisar, o que fazem as configurações do INAV e o que revelaram nove logs reais do INAV 6–8 analisados pelo bbdoctor.

Configuração da gravação: taxa, giroscópio bruto e motores

O INAV define a taxa de gravação como uma fração da taxa do loop: 1,000,000 / looptime × blackbox_rate_num / blackbox_rate_denom. Com o valor padrão looptime = 500 (2 kHz), 1/2 resulta em 1 kHz e 1/32, em aproximadamente 62 Hz. Dois quads com INAV 7.1 da nossa coleção gravaram a 60 e 58 quadros por segundo.

• 500 Hz ou mais. O ruído dos motores e das hélices fica acima de 80 Hz; as ressonâncias da estrutura costumam começar perto de 100 Hz. O log só mostra frequências até metade da taxa de gravação; por isso, um log de 60 Hz termina em 30 Hz. O bbdoctor só executa as verificações de vibração e ruído dos motores a partir de 500 Hz. No papel, 1/4 resulta em 500 Hz, mas o loop real dos nossos logs funcionou entre 1890 e 1990 Hz, então 1/4 fica um pouco abaixo do limite. Use 1/2.
• GYRO_RAW. São os dados do giroscópio antes da filtragem. Sem eles, não dá para separar a vibração da estrutura do comportamento dos filtros, medir o atraso dos filtros nem distinguir um sensor com defeito de uma falha do firmware.
• MOTORS. São os comandos enviados aos motores. Sem eles, não há dados sobre ruído dos motores, distribuição de carga ou resposta ao stick, e o bbdoctor rejeita o log diretamente, como aconteceu com uma das nossas amostras do INAV 7.0 (Matek H743).
• Armazenamento. A memória flash integrada comporta alguns minutos a 1 kHz; um cartão SD precisa acompanhar a taxa. Um log do INAV 6.1.1 de uma placa H7 perdeu 27% dos quadros e teve 6 interrupções, então todos os números dele exigem ressalvas.

blackbox GYRO_RAW
blackbox MOTORS
set blackbox_rate_num = 1
set blackbox_rate_denom = 2
save

Se a memória flash for pequena, mantenha 500 Hz e faça voos de teste curtos, de 30 a 60 s. Para localizar uma ressonância com precisão, grave um log curto em 1/1 (2 kHz). Veja as orientações gerais no guia de configuração do blackbox.

INAV 8 e versões mais recentes gravam activeFlightModeFlags, que indica os modos realmente ativos. Assim, é fácil distinguir ACRO dos modos de autonivelamento e navegação. O INAV 7 e versões anteriores gravam apenas flightModeFlags, que indica as chaves de modo acionadas; um modo de navegação selecionado pode nunca ser ativado (por exemplo, se não houver sinal GPS).

Como voar para obter o log

Os PIDs só podem ser avaliados em ACRO. Nos modos ANGLE, HORIZON e de navegação, o stick comanda um ângulo; há um loop de ângulo entre o stick e o loop de taxa, então a resposta revela pouco sobre os PIDs. O bbdoctor exclui esses trechos da avaliação dos PIDs. No segundo voo do quad H743 abaixo (73 s, 78% em ANGLE/HORIZON), o relatório analisa ruído, filtros e distribuição de carga, mas não avalia o overshoot: não há dados adequados para isso.

1. Faça de 6 a 8 rolls e flips rápidos, trazendo o stick de volta ao centro num movimento seco e mantendo-o ali por meio segundo. Com menos de seis paradas por eixo, não é possível verificar o rebote; o bom log do H743 teve uma por eixo.
2. Faça de 5 a 8 cortes limpos de aceleração: suba com mais de 35% de throttle, corte para zero e mantenha os sticks centralizados por um segundo. Um corte que termina em um flip não serve para avaliar o propwash.
3. Faça algumas aceleradas a fundo, do pairado até o throttle máximo, e voe de forma estável em diferentes níveis de throttle para mapear o ruído.

Aeronaves grandes não precisam de flips: inclinações curtas e rápidas, em altura segura, são suficientes. Deixe a navegação desligada.

Configurações do INAV ajustadas com base no log

Os valores padrão vêm do Settings.md do INAV; confirme os seus com get. Muitos não aparecem no cabeçalho do log: ele contém as sequências de PID, gyro_lpf_hz, dterm_lpf_hz, dynamicGyroNotchMinHz, TPA e rpm_gyro_*, mas não inclui d-boost, anti-gravity, I-term relax, airmode_type nem nenhuma configuração do EzTune. O bbdoctor reconstrói throttle_idle a partir de minthrottle. Por isso, para esses valores o relatório recomenda conferir com get. Salve primeiro os valores atuais:

get mc_
get dterm_lpf
get dynamic_gyro_notch
get antigravity
get mc_iterm_relax
get throttle_idle
get airmode_type

Para verificar toda a configuração, cole o resultado de diff all na verificação de configuração.

Logs reais do INAV e o que revelaram

INAV 7.1 a 60 Hz: sem dados de vibração nem de PIDs

Uma Matek F722SE com 6S (voos de 213 e 171 segundos) e uma SpeedyBee F7 V3 (26 segundos), ambas com blackbox_rate_denom = 32 em um loop de 2 kHz: 60 e 58 quadros por segundo. A F722SE também não gravava GYRO_RAW, e todos os voos foram inteiramente em ANGLE/HORIZON. Só é possível ver de 0 a 30 Hz, então ruído dos motores, ressonâncias e filtros ficam fora da faixa; além disso, os PIDs não podem ser avaliados por dois motivos: taxa e modo incorretos.

Ainda é possível analisar a distribuição de carga entre os motores (na F722SE, os motores da direita trabalham 17% mais: o CG está deslocado para a direita; confira a bateria e qualquer componente pesado fora do centro), a tensão da bateria sob carga, eventos de failsafe e a cronologia de uma queda. São processos lentos; 60 Hz bastam.

INAV 8, Matek H743, 6S: ressonância de 117 Hz e overshoot que não é causado pelo FF

Um bom log: 995 Hz, GYRO_RAW, 55 segundos em ACRO, com ganhos bem acima dos valores de fábrica: roll P 80, I 22, D 32, FF 100; pitch 88 / 24 / 35 / 110.

• Ruído bruto acima de 80 Hz: roll 8,0, pitch 6,8 e yaw 4,6 graus/s. As faixas do bbdoctor: abaixo de 4 é bom, de 4 a 10 indica ruído e acima de 10 é crítico. Após a filtragem: 1,07 graus/s, com cerca de 2,3 ms de atraso dos filtros; eles estão dando conta.
• Ressonância de 117 Hz somente no pitch, 12 dB acima do ruído de fundo e fixa em todos os níveis de throttle: a origem é mecânica (veja a figura abaixo). Os filtros reduzem o pico em cerca de 17 dB, mas ele ainda chega ao loop de PID. Com a gravação a 995 Hz, a frequência real é ambígua: pode ser 117 Hz ou 878 ou 1112 Hz rebatidos para baixo. Além disso, dynamicGyroNotchMinHz está em 126 Hz; se o pico realmente estiver em 117 Hz, o notch dinâmico não consegue alcançá-lo. As posições gravadas dos notches (gyroPeakPitch[0..2], INAV 8) mostram o primeiro notch de pitch preso no limite mínimo, entre 125 e 127 Hz, durante um quarto do voo. Ordem recomendada: reforce a estrutura, o stack, a câmera e a antena; grave um log curto em 1/1 (2 kHz) e então decida sobre o notch.
• Ruído dos motores de 2,9% (pior no M3); o bbdoctor sinaliza a partir de 2,5% e considera crítico a partir de 4%. Os termos de PID gravados mostram que D absorve de 4 a 4,5 vezes mais ruído que P, enquanto FF absorve quase nada. O relatório sugere alterar dterm_lpf_hz de 185 para 157.
• Overshoot: 30% no roll (133 trechos de stick, faixa de 90% entre 24 e 36%) e 25% no pitch. O amortecimento ζ ≈ 0,42 e 0,41, abaixo da faixa saudável de 0,6 a 0,9: após o pico, a resposta cai 14% abaixo do alvo e oscila perto de 7 Hz. O FF faz apenas 22% (roll) e 19% (pitch) do trabalho e nunca se antecipa ao stick; portanto, o próprio loop P/D causa o overshoot, e reduzir mc_cd_* não vai ajudar.
• Atraso entre o setpoint e o pico da resposta de roll: 31 ms (27,7 a 33,6), contra 4 a 12 ms em um ajuste preciso com feedforward. Não aumente FF para reduzir esse atraso enquanto o eixo tiver overshoot.
• Propwash (0,6 graus/s, 12 cortes limpos em 15) e aceleradas a fundo (pitch 1,0°, roll 0,6°) estão bons. Não foi possível verificar o rebote: houve apenas uma parada brusca por eixo.

A lógica do relatório: reduza P do pitch em 10%. Mantenha P do roll, pois o eixo já responde com 31 ms de atraso; aumente D do roll em 10% (32 para 35) somente depois de eliminar o ruído dos motores, ou os motores podem esquentar mais.

set dterm_lpf_hz = 157
set mc_p_pitch = 79
save

Mas confira primeiro o EzTune. Os filtros deste log correspondem exatamente à fórmula do EzTune para ez_filter_hz = 190: gyro_lpf_hz em 190, dterm_lpf_hz 5 Hz abaixo, limite mínimo do notch em dois terços (126) e Q do notch em 250. Os ganhos de pitch são 1,1 vez os de roll, que corresponde a ez_axis_ratio 110. Se get ez_enabled indicar ON, o EzTune vai sobrescrever os comandos acima. Você pode usar set ez_enabled = OFF (os PIDs e filtros atuais permanecem) e então aplicar as alterações, ou usar o controle deslizante: alterar ez_filter_hz de 190 para 160 define dterm_lpf_hz como 155, mas também baixa o passa-baixa do giroscópio para 160 Hz (mais atraso) e o limite do notch para 106 Hz.

O escRPM deste log está ativo e acompanha o throttle, mas rpm_gyro_filter_enabled = 0. O filtro de RPM eliminaria parte do ruído dos motores, mas não a ressonância de 117 Hz, que não varia com a rotação deles.

INAV 8, BetaFPV F411, whoop 1S: D doze vezes mais forte que P

Dez segundos a 973 Hz com GYRO_RAW. PID de roll: P 17, I 86, D 50, FF 60; pitch 40 / 90 / 35 / 60. D do roll é três vezes maior que P, enquanto no INAV padrão D é 23 e P é 40. No log, o termo D do roll é 12 vezes mais forte que P e absorve quase todo o ruído dos motores: 5,5% nos motores (M4, crítico), 22,1 graus/s de ruído bruto de roll e 4,8 graus/s após a filtragem. Parece um erro de digitação ou valores trocados; é por aí que o relatório começa:

set mc_d_roll = 35
save

Mais três observações. O filtro de RPM está ativado (rpm_gyro_filter_enabled = 1), mas escRPM mantém o mesmo valor sem sentido durante todo o voo; aparentemente, o filtro funcionou sem dados de RPM. A diagonal M1+M4 trabalha mais o tempo todo (46%): o mixer está corrigindo yaw continuamente; procure um motor inclinado ou hélices incompatíveis. O propwash foi de 9,4 graus/s, mas com apenas três cortes limpos (uma avaliação confiável precisa de cinco); em dois deles, o motor mais fraco ficou em marcha lenta por pelo menos 150 ms durante a janela de meio segundo após o corte. Não é falta de D: não resta força de frenagem para o controlador de voo. Se o próximo voo confirmar isso, ajuste throttle_idle de 8 para 10 e use airmode_type = THROTTLE_THRESHOLD. Veja mais no guia de propwash.

INAV 6.x: o giroscópio filtrado zerou enquanto o bruto continuou funcionando

Dois quads, ambos caíram. INAV 6.1.1 em uma AocodaRC H7 Dual (3S): o giroscópio filtrado fica em zero por 0,9 s quando o failsafe é acionado, embora os pacotes RC continuem chegando. INAV 6.0.0 em uma iFlight Blitz F7 (6S): fica em zero por 1,5 s; o failsafe ocorre 1,4 s antes de um impacto de 9 g, o throttle cai de 32% para 4% e, novamente, os pacotes RC continuam chegando. Nos dois casos, o giroscópio bruto continuou detectando rotação: o sensor estava funcionando e o zero foi causado pelo firmware.

O bbdoctor identifica um congelamento quando os três eixos do giroscópio permanecem exatamente iguais por 0,3 s ou mais durante o voo. Sem GYRO_RAW, não dá para distinguir uma falha do firmware de um defeito no sensor. O que fazer: atualize o firmware, confira se o failsafe está associado a uma chave do rádio e verifique failsafe_procedure. Se isso também acontecer sem failsafe, confira as soldas e a alimentação de 3,3 V da controladora de voo.

Ordem de ajuste para o INAV

1. Gravação. 500 Hz ou mais, GYRO_RAW e MOTORS. Decida como usar o EzTune: ajuste pelos controles deslizantes ou defina ez_enabled = OFF e ajuste manualmente.
2. Mecânica. Ruído bruto acima de 4 graus/s em roll ou pitch, picos que aumentam com o throttle (hélices, motores) ou um pico fixo em frequência (estrutura): comece pelas hélices, parafusos e pelo stack com montagem antivibração. Filtros não corrigem problemas mecânicos. Veja mais no guia de ruído e filtros.
3. Filtros. Ruído dos motores de 2,5% ou mais e motores quentes: reduza dterm_lpf_hz em 15%. Se ainda houver ruído, reduza gyro_main_lpf_hz em 15%. Ressonância abaixo de dynamic_gyro_notch_min_hz: reduza o limite depois de confirmar a frequência com um log de 2 kHz. Se a telemetria do ESC estiver funcionando, ative o filtro de RPM. Pouco ruído e motores frios: alivie um pouco os filtros para reduzir o atraso.
4. P e D. Se houver overshoot, confira primeiro a contribuição do FF. Se for pequena, o overshoot vem de P/D: reduza P e, com ζ abaixo de 0,6 e motores frios, aumente D em etapas de 10%.
5. I, relax, anti-gravity e TPA. Rebote: reduza mc_iterm_relax_cutoff de 15 para 10 e depois reduza I em 10%. Nariz baixa em acelerações bruscas: use antigravity_gain = 2. Overshoot ou tremores apenas com throttle alto: altere tpa_rate de 0 para 20 ou aumente 15 se o TPA já estiver ativado (no INAV, ele reduz P, D e CD).
6. Propwash. Se um motor ficar em marcha lenta durante os cortes, aumente throttle_idle em 2 e use airmode_type = THROTTLE_THRESHOLD; não aumente D. O próprio Airmode precisa estar ativado com feature AIRMODE ou pela chave AIR MODE.
7. FF e suavização do stick ficam por último, depois que o loop parar de apresentar overshoot.

Faça uma alteração por voo e toque nos motores para verificar a temperatura depois de cada uma. Veja como interpretar a resposta ao degrau em ajuste de PID com blackbox.

Quando não alterar nada. Se o log estiver abaixo de 500 Hz, deixe os filtros como estão. Se o voo foi em ANGLE ou em um modo de navegação, não mexa nos PIDs. Com menos de cinco cortes limpos, não ajuste o propwash; com menos de seis paradas bruscas por eixo, não mexa em relax nem em I. Se houver perda significativa de quadros, faça outro voo. Com ruído bruto abaixo de 4 graus/s, ruído dos motores abaixo de 2,5% e amortecimento entre 0,6 e 0,9, mantenha o ajuste: mais filtragem acrescenta atraso e mais D esquenta os motores.

Diferenças entre os logs do INAV e do Betaflight

• Nomes. O cabeçalho armazena os ganhos em uma linha: rollPID:80,22,32,100 significa P, I, D e FF; no CLI, os comandos são separados: mc_p_roll, mc_i_roll, mc_d_roll e mc_cd_roll. Comandos do Betaflight, como p_roll ou f_roll, não funcionam.
• Campos. O setpoint é axisRate, não setpoint; os termos de PID são axisP, axisD e axisF. O bbdoctor usa esses campos para separar a contribuição de P, D e FF no ruído dos motores e no overshoot.
• Sem RPM individual por motor. O log não consegue identificar um motor específico desbalanceado, apenas o ruído geral, as ressonâncias e a carga. Suspeita de um motor? Localize-o trocando componentes.
• Numeração dos motores no Quad X é a mesma: M1 traseiro direito, M2 dianteiro direito, M3 traseiro esquerdo, M4 dianteiro esquerdo.

Ajuste a navegação somente depois de corrigir o loop interno

Os controladores de posição e altitude do INAV geram um ângulo e um throttle de referência, que os loops de ângulo e taxa ajustados acima precisam executar. Se o roll tem overshoot de 30% e oscila a 7 Hz, o POSHOLD vai oscilar; nesse caso, alterar nav_mc_pos_xy_p ou nav_mc_vel_xy_p significa corrigir o loop errado. Siga esta ordem:

1. Um loop interno estável, avaliado com um log em ACRO.
2. Throttle de pairado: encontre o throttle (campo rcCommand[3]) em que o quad paira sem subir nem descer e defina nav_mc_hover_thr com esse valor (mesmas unidades de 1000 a 2000); o controlador de altitude parte desse valor.
3. Depois, ajuste os ganhos de altitude (nav_mc_pos_z_p, nav_mc_vel_z_*) e de posição (nav_mc_pos_xy_p, nav_mc_vel_xy_*), um por voo.

O bbdoctor analisa o loop interno, não os controladores de navegação.

Verificação automática

O bbdoctor analisa gratuitamente e online logs blackbox do INAV (.txt e .bbl): mede tudo o que foi mencionado nos exemplos acima e sugere comandos na sintaxe do CLI do INAV, calculados a partir dos seus valores atuais. Como os limites foram ajustados com quads FPV Betaflight, o relatório avisa que são aproximados para drones grandes. Veja um exemplo de relatório.

Atualizado: 2026-10-22