Análise de ULog no PX4: vibração, filtros e ajuste do controlador de taxa

O Flight Review gera bons gráficos, mas deixa em aberto as perguntas importantes: qual pico importa, se a causa é mecânica ou do controlador, qual filtro ajustar e se o log tem dados suficientes. Todos os exemplos abaixo vêm de logs reais do PX4 1.12–1.17 usados nos testes do bbdoctor, e todos os valores foram medidos.

Como obter um log útil

O arquivo .ulg fica em log/ no cartão SD. Você também pode usar QGroundControl → Analyze Tools → Log Download. 11 dos nossos 18 logs do PX4 usam o valor padrão SDLOG_PROFILE = 1: o giroscópio só aparece em sensor_combined, a 200 Hz, calculado como média em janelas IMU_INTEG_RATE (200 Hz em 17 dos 18 logs), e os logs 1.12 tinham vehicle_rates_setpoint a apenas 5–50 Hz. Um log assim não mostra vibrações acima de 100 Hz nem a resposta do loop de taxa.

Some bits ao valor atual em vez de substituí-lo: 1 passa a ser 273; 25 (Default + System identification + High rate) passa a ser 281. Um log 1.15.4 de uma ARK FMU v6X com SDLOG_PROFILE = 1023 (bits 0–9) tem sensor_gyro_fifo com 800 pacotes de 10 amostras por segundo (8 kHz), taxas filtradas e actuator_motors a 800 Hz: 25 MB em 43 segundos, e ainda houve 4 lacunas que somaram 0,13 s de dados perdidos pelo logger.

sd_bench -r 100
param set SDLOG_PROFILE 273
reboot

SDLOG_PROFILE exige reinicialização. Os tópicos padrão geram cerca de 50 KB/s (documentação do PX4); High rate com Raw FIFO gera várias vezes isso. Os logs falham por travamentos de gravação de centenas de milissegundos, não pela velocidade média baixa: execute sd_bench no MAVLink Console e use um cartão de até 32 GB (limite do NuttX). Um log 1.16.2 perdeu 5,4 s com o perfil padrão: nessa taxa de dados, quase certamente a causa foi o cartão.

RPM dos motores. Para atribuir a vibração a um motor específico, você precisa de esc_status com RPM: DShot bidirecional, telemetria DShot (DSHOT_TEL_CFG) ou ESCs DroneCAN. Nas versões 1.16–1.17, DShot bidirecional usa DSHOT_BIDIR_EN = 1 com o valor correto de MOT_POLE_COUNT; a documentação atual substitui ambos por um protocolo de saída BDShot e DSHOT_MOT_POL1…12. Nosso log 1.17 tem esc_status a 167 Hz; um log 1.12, a 4 Hz.

Voo de teste: faça 20–30 segundos pairando, variações suaves de aceleração e, em seguida, 10–20 comandos curtos e rápidos do stick em cada eixo. O modo Stabilized serve: o PX4 registra a referência de taxa em todos os modos. Não é preciso fazer flips. Para Betaflight, consulte o guia de configuração do blackbox.

Vibração: o que observar

• FFT de Actuator Controls no Flight Review (requer o perfil High rate). Segundo a documentação do PX4, um gráfico saudável tem um pico na parte mais baixa (abaixo de cerca de 20 Hz) e valores baixos e uniformes no restante. As escalas variam entre veículos, então compare cada veículo com ele mesmo.
• Espectro do giroscópio bruto (somente Raw FIFO). Picos que mudam com a aceleração vêm dos motores e das hélices. Um pico que permanece na mesma frequência em qualquer aceleração é uma ressonância do frame, stack, mastro do GPS ou gimbal.
• Acelerômetro. No gráfico Raw Acceleration, é um mau sinal se o eixo z alcançar x e y durante o pairado. Os contadores de clipping ficam em vehicle_imu_status (accel_clipping); clipping exige resolver primeiro a parte mecânica e corrompe a estimativa de atitude.

Interprete com cuidado accel_vibration_metric e gyro_vibration_metric: pelos nossos logs, a escala muda entre versões. Um log 1.12.3 com ruído bruto do giroscópio de 68,5 deg/s tem métrica mediana do acelerômetro de 0,06; um veículo 1.15.4 com um décimo desse ruído mostra 1,6, e um 1.17 mostra 11,7. Compare apenas dentro da mesma versão e do mesmo veículo.

O bbdoctor mede o ruído do giroscópio bruto como RMS acima de 80 Hz em roll e pitch: abaixo de 4 deg/s é limpo, 4–10 é ruidoso e acima de 10 é ruim. Uma ressonância é um pico acima de 60 Hz que fica mais de 6 dB acima do piso local em pelo menos 60% das faixas de aceleração. A frequência é inequívoca se o giroscópio estiver registrado na taxa total do sensor (sensor_gyro_fifo) ou a 2 kHz ou mais, com o pico abaixo da metade de Nyquist; caso contrário, você terá frequências candidatas. Para localizar o motor específico, consulte vibração no drone: encontre o motor com problema.

Casos reais dos logs

PX4 1.15.4: ressonância de 469 Hz e notch estático

No log da ARK FMU v6X 1.15.4 citado acima (6S, giroscópio bruto a 8 kHz), o bbdoctor encontrou um pico de 469 Hz somente em pitch, 6 dB acima do piso em qualquer aceleração. Ruído bruto: roll 6,4, pitch 1,6, yaw 2,1 deg/s; 0,11 deg/s permanece após a filtragem. Acima de 250 Hz, os suspeitos habituais são os suportes macios e os fixadores da stack, não os braços.

Como solução provisória, use um notch estático nessa frequência:

param set IMU_GYRO_NF0_FRQ 469
param set IMU_GYRO_NF0_BW 100

A largura de banda costuma ser cerca de 30% da frequência, mas IMU_GYRO_NF0_BW chega no máximo a 100 Hz (assim como IMU_GYRO_NF_BW na 1.12). Há duas sutilezas. Primeiro, a FFT embarcada está ativada aqui, mas por padrão busca apenas de IMU_GYRO_FFT_MIN a IMU_GYRO_FFT_MAX (30–150 Hz); todos os picos registrados ficaram entre 31–146 Hz. Um notch dinâmico controlado pela FFT nunca alcançaria 469 Hz e, para um pico que não se desloca, um notch estático é melhor do que ampliar a janela. Segundo, com IMU_GYRO_CUTOFF = 40, o passa-baixa de segunda ordem já atenua 469 Hz em cerca de 43 dB. O notch traz benefício quando você aumenta o cutoff para recuperar parte do atraso de 5,6 ms. A conclusão do bbdoctor: há margem para ajuste, mas resolva primeiro a mecânica.

PX4 1.17: auto-oscilação de 42 Hz em pitch

Um quad 4S com FMU v6C, sem giroscópio bruto, mas com esc_status registrado. Em 63 s de voo tranquilo, o erro de pitch (giroscópio − referência) tem um pico estreito de 41,7 Hz, 28 dB acima do piso e 11,5 deg/s, abaixo das frequências dos motores (61–87 Hz). Roll, com P 0,18, I 0,15 e D 0,003 idênticos, está limpo. A coerência entre giroscópio e comando do motor nessa frequência é 1,0, com fase de +13°: P está causando o pico.

param set MC_PITCHRATE_P 0.162

Isso reduz P em 10%. Voe novamente: se o pico diminuir, era o loop; se aumentar, restaure P; se não mudar, restaure P e investigue a mecânica. Observe os filtros: em 42 Hz, só IMU_GYRO_CUTOFF = 40 já adiciona cerca de 90° de atraso de fase, e IMU_DGYRO_CUTOFF = 20 atenua D várias vezes e acrescenta o próprio atraso, então D amortece mal a oscilação. Um cutoff mais alto no giroscópio ajudaria, mas sem o giroscópio bruto você não consegue verificar o ruído: ajuste P agora e os filtros depois, usando o perfil 281.

PX4 1.12.3: 68,5 deg/s de ruído em um log de 222 Hz

Uma placa FMU v3 antiga, 4S, perfil 1. O ruído bruto do giroscópio acima de 80 Hz é: roll 68,5, pitch 27,8 e yaw 14,5 deg/s, em um log que só enxerga de 80–111 Hz. Um pico também permanece no lugar em qualquer aceleração, mas, com registro a 222 Hz, sua frequência real poderia ser 94, 129 ou 316 Hz. Portanto, não aplique um notch às cegas: revise primeiro hélices, motores e fixadores; depois faça um log curto com Raw FIFO para identificar a frequência exata.

PX4 1.12.3: motor 2 e o segundo harmônico

Um veículo 6S, com mais de 15 minutos de voo e motores a 2500–3170 rpm (42–53 Hz), segundo esc_status. A análise de ordens (giroscópio demodulado pela fase de rotação de cada motor) encontrou um componente de 5,3 deg/s em 2× no M2 e quase nada nos outros: normalmente isso indica pá danificada ou passo de pá desigual. Porém, o RPM foi registrado a apenas 4 Hz e 2× (cerca de 83 Hz) fica perto do limite de 100 Hz, então é uma pista, não uma conclusão. O motor 2 fica atrás à esquerda em um Quad X padrão; este veículo tem SYS_AUTOSTART fora do padrão, então confira o mixer antes de remover uma hélice.

Filtros do PX4

O PX4 filtra cada amostra FIFO na taxa total do sensor e só depois reduz a frequência para IMU_GYRO_RATEMAX (padrão 400 Hz, 800 em 16 dos nossos 18 logs). Por isso um notch de 469 Hz funciona com um controlador a 800 Hz.

Atraso. O bbdoctor calcula o atraso do passa-baixa do giroscópio a partir da configuração: √2/(2π·fc) para um filtro de segunda ordem. O deslocamento de tempo entre tópicos registrados não serve como substituto: no PX4, ele pode ser zero com cutoff de 30–60 Hz.

Aumentar o cutoff. Avance em passos de 10 Hz (40 → 50 → 60). Depois de cada ajuste, voe por 20–30 segundos, pouse e toque nos motores e ESCs: a documentação do PX4 alerta que eles podem superaquecer e sofrer danos. Pare quando o ruído na FFT de Actuator Controls subir visivelmente e volte um passo. Se o ruído bruto passar de 4 deg/s, não mexa nos filtros e resolva a parte mecânica. Saiba por que o ruído aquece os motores e como ajustar filtros.

param set IMU_GYRO_CUTOFF 50

Controlador de taxa: P, I, D, FF e K

O controlador de taxa do PX4 calcula K·(P·erro + I·integral − D·aceleração angular) + FF·referência. D atua sobre a aceleração medida, não sobre o erro, então comandos bruscos do stick não provocam um tranco. Parâmetros: MC_ROLLRATE_P/I/D/FF/K e os equivalentes para PITCHRATE e YAWRATE, com limites do integrador MC_RR_INT_LIM, MC_PR_INT_LIM, MC_YR_INT_LIM.

O multiplicador K. K = 1 corresponde à forma paralela; P = 1, à forma padrão, em que K é o ganho geral. Um log 1.13.1 de uma CubeOrange tem P 1, I 2, D 0,029 e K 0,08 em roll e pitch: os ganhos efetivos são 0,08, 0,16 e 0,0023. Portanto, não faz sentido comparar o “P = 1” desse log com o valor 0,15 de outra pessoa. FF não é escalado por K.

param show MC_ROLLRATE*
param show MC_PITCHRATE*

Ordem de ajuste manual, segundo a documentação do PX4: ajuste P e D iterativamente em roll e pitch e, depois, I. Em geral, yaw usa D = 0. A documentação também recomenda desativar MC_AIRMODE durante o ajuste.

Autotune. Integrado desde a versão 1.13: defina MC_AT_EN = 1; no QGroundControl (Vehicle Setup → PID Tuning), ative Autotune e pressione o botão durante um voo nos modos Altitude, Hold ou Position. Qualquer comando do stick cancela o ajuste, então mantenha uma altura segura. MC_AT_APPLY = 1 (padrão) aplica os ganhos depois de desarmar. Se surgir uma oscilação rápida (mais de uma vez por segundo), a documentação recomenda reduzir MC_ROLLRATE_K e MC_PITCHRATE_K em passos de 0,02.

O PX4 não tem TPA no estilo Betaflight. Nenhum dos nossos logs 1.12–1.17 tem MC_TPA_*. O modelo de empuxo THR_MDL_FAC controla o ganho em função da aceleração (0 = empuxo linear em relação ao sinal; 1 = quadrático). A maioria dos nossos veículos usa 0; três usam 0,3 e um usa 0,1. A documentação indica 0,3–0,5 como faixa típica: comece em 0,3 e ajuste em passos de 0,1. Oscilação em baixa aceleração indica valor alto demais; em alta aceleração, baixo demais. Depois, confira novamente o ajuste de taxa.

param set MC_AT_EN 1
param set THR_MDL_FAC 0.3

O bbdoctor lê a resposta de vehicle_rates_setpoint até mesmo no modo Stabilized, se o giroscópio e a referência estiverem registrados a 200 Hz ou mais e ao menos 10 sequências de comandos bruscos do stick (e um quarto do total) forem utilizáveis; são necessárias 30 se a curva estiver instável. Em um log 1.16.2, roll alcançou apenas 84% da referência, e o bbdoctor sugeriu aumentar P e I em 10%: MC_ROLLRATE_P de 0,102 → 0,112 e MC_ROLLRATE_I de 0,1301 → 0,143. Veja como interpretar uma resposta a degrau: ajuste de PID a partir do blackbox.

Auto-oscilação ou ressonância do frame

Um pico estreito pode exigir duas correções opostas, e confundi-las custa caro: reduzir os filtros para corrigir uma auto-oscilação do loop aumenta o atraso e piora o problema.

O bbdoctor procura esses picos em trechos de voo tranquilo (referência abaixo de 60 deg/s, aceleração constante), entre 10 Hz e 80 Hz ou até 0,8 da frequência do motor. O pico precisa ser estreito, ficar 10 dB acima do piso local e atingir pelo menos 1 deg/s; ele é descartado se coincidir com harmônicos do motor, aparecer em todos os eixos incluindo yaw ou corresponder a uma ressonância conhecida do frame. O espectro cruzado entre giroscópio e torque mostra se os motores oscilam em sincronia (coerência de 0,5 ou mais), e a fase indica se P, D ou o atraso do filtro causa a oscilação.

Failsafe e bateria

O bbdoctor identifica um failsafe por meio de vehicle_status; a causa aparece nas mensagens do log (Flight Review → Messages). Um log 1.13.1 de uma CubeOrange registrou “Failsafe enabled: no offboard”, “Position-Ctrl activation failed” e, em seguida, “Failsafe: blind descend”. O modo Offboard foi perdido, a reação era COM_OBL_RC_ACT = 0 (Position) e o modo Position não conseguiu ser ativado. “Blind descend” significa que o controlador de posição não tinha estimativa de velocidade vertical, então o drone desceu com um empuxo ligeiramente abaixo do necessário para pairar. Corrija a conexão com o computador auxiliar e a estimativa de altura do EKF2, e escolha uma reação compatível com os sensores (Altitude ou Land sem posição); o problema não é o link RC. O timeout é COM_OF_LOSS_T; a versão 1.13 também tem COM_OBL_ACT para o caso sem RC, enquanto a 1.14+ usa apenas COM_OBL_RC_ACT.

No log 1.17, “Battery 1: over voltage. Land now!” apareceu em pleno voo, com média de 3,6–3,7 V por célula. O código atual do PX4 dispara esse aviso quando uma amostra de tensão não filtrada supera BAT1_N_CELLS × BAT1_V_CHARGED × 1,05; neste caso, 4 × 4,05 × 1,05 = 17,0 V. As amostras registradas a 5 Hz chegam a 16,27 V, mas os valores vizinhos saltam 2–3,5 V (16,13 → 12,6 → 14,96 V). Uma variação de corrente de 6–19 A explica no máximo 1,2 V, mesmo com os 22 mΩ por célula estimados pelo bbdoctor. Portanto, a própria leitura de tensão é ruidosa e um pico não registrado disparou a verificação. Confira a fiação e o terra do módulo de energia, além da calibração de BAT1_V_DIV; definir BAT1_V_CHARGED como 4,05 em vez de 4,2 (padrão atual) apenas reduz o limite.

12 dos nossos 18 logs têm COM_LOW_BAT_ACT = 0, que apenas emite um aviso. Para um veículo grande com GPS:

param set COM_LOW_BAT_ACT 3
param set NAV_RCL_ACT 2

Return exige uma estimativa de posição válida. Sem GPS, escolha o pouso: COM_LOW_BAT_ACT 2 e NAV_RCL_ACT 3.

Uma bateria desgastada aparece na resistência interna. O bbdoctor estima esse valor pela inclinação da relação entre tensão e corrente durante mudanças bruscas de corrente: abaixo de 12 mΩ por célula é bom; 12–25 é um alerta; acima disso é ruim. Este log 1.17 indicou cerca de 22 mΩ, contra 2–10 nos outros veículos. Porém, com uma tensão tão ruidosa, a estimativa é incerta: corrija a medição e confira a bateria em um carregador. O voo começou com a bateria parcialmente usada (3,94 V por célula), e o mínimo sustentado (mediana de 0,5 s) foi 3,41 V por célula, com pico de apenas 18 A.

Armadilhas comuns nos logs do PX4

• Numeração dos motores. PX4 Quad X: 1 dianteiro direito, 2 traseiro esquerdo, 3 dianteiro esquerdo, 4 traseiro direito. A ordem é diferente da do Betaflight. No log 1.17, a diagonal M3+M4 trabalhou 29% mais, conforme confirmado por esc_status: cerca de 93 Hz em voo, contra 76–77 Hz nos motores M1 e M2. O mixer está compensando o yaw: procure um motor inclinado, braço torcido ou hélices incompatíveis. Em outro log, os motores dianteiros carregavam 23% mais que os traseiros: o centro de gravidade estava muito à frente.
• FFT ligada, notch desligado. Seis dos nossos logs 1.13+ têm IMU_GYRO_FFT_EN = 1 com IMU_GYRO_DNF_EN = 0, e três logs 1.12 fazem o mesmo com IMU_GYRO_DYN_NF = 0. A FFT encontra picos (tópico sensor_gyro_fft), mas não filtra nada.
• Um notch que você não consegue verificar. Um log 1.12.3 tem um notch de 100 Hz com registro a 200 Hz, exatamente no limite de Nyquist: esse log não consegue mostrar se o notch funciona.
• Tópicos lentos e perda de dados. Uma referência de taxa registrada a 5 Hz não permite avaliar a resposta, por mais rápido que seja o giroscópio. Lacunas também prejudicam os espectros: se o logger perder dados mesmo no perfil 1, troque o cartão.

Verificação automática

O bbdoctor analisa gratuitamente online logs .ulg do PX4: ruído antes e depois dos filtros, ressonâncias, auto-oscilação do loop, resposta de taxa, carga e RPM dos motores, bateria, failsafes e lacunas de gravação. Se o log tiver frequência baixa demais, ele informa qual SDLOG_PROFILE usar. Os limites foram ajustados com quads FPV Betaflight, então compare veículos grandes com seus próprios logs anteriores. Veja o relatório de exemplo ou os guias de logs do ArduPilot e blackbox do INAV.

Atualizado: 2026-10-22