Análise de logs do ArduPilot: vibração, clipping, filtros e PIDs

Seu ArduCopter não mantém a altitude, deriva no Loiter, gera avisos do EKF ou vibra depois do autotune. Em geral, a causa é a vibração: a estimativa de posição perde qualidade e o piloto automático tenta corrigir algo que não existe. A sequência é sempre a mesma: o log certo → vibração e clipping → espectro e notch → filtros passa-baixa → PIDs. Veja abaixo os limites aplicados pelo bbdoctor, com números de logs reais do ArduCopter.

Como obter o log certo e ativar o registro rápido

Você precisa do log DataFlash .bin gravado na placa (Mission Planner → DataFlash Logs → Download ou APM/LOGS no cartão SD); um .tlog de telemetria não tem dados suficientes. O que será registrado é definido por LOG_BITMASK. Cinco bits são importantes aqui:

A máscara padrão é 176126 até a versão 4.5; a 4.6 adicionou o bit PID e passou a 180222. Nos dez logs de ArduCopter do nosso conjunto de testes (da versão 4.1 à 4.8-dev, de fmuv2 a Pixhawk 6X, além de duas execuções SITL), IMU foi registrado a 25 Hz e RATE, RCOU e VIBE a 10 Hz: suficiente para VIBE e carga média dos motores, mas não para espectro, análise de filtros ou resposta dos PIDs.

No Mission Planner, basta marcar ATTITUDE_FAST e IMU_RAW em LOG_BITMASK. Se o log não tiver o giroscópio bruto, o bbdoctor acrescenta os bits que faltam à máscara atual. Para 176126:

LOG_BITMASK = 700415
INS_RAW_LOG_OPT = 9

Partindo de 180222, como em todos os nossos logs da versão 4.7, o resultado é 704511. INS_RAW_LOG_OPT = 9 (giroscópio primário antes e depois da filtragem) surgiu na versão 4.5; nos logs da 4.3.7, o bbdoctor sugere apenas LOG_BITMASK = 700415, pois ali o bit 19 sozinho ativa o registro bruto.

Os logs podem ficar dezenas de vezes maiores, e placas ou cartões lentos podem perder dados (o bbdoctor informa "Gaps in the recording"); a documentação do ArduPilot recomenda o registro bruto de IMU em placas H7, então espere falhas em uma F4 como a fmuv2 abaixo. Depois, restaure seu LOG_BITMASK anterior e defina INS_RAW_LOG_OPT = 0.

Faça um voo de teste de 3 a 5 minutos: mantenha o hover, varie o acelerador suavemente bem acima do hover e volte, e dê alguns comandos curtos e rápidos nos sticks em cada eixo, a uma altura segura. Não faça flips.

O bbdoctor rejeita logs que não sejam de copter e logs sem IMU ou RCOU (um log real de um quad grande tinha o bit 7 ativado, mas nenhuma mensagem IMU: envie o .bin completo, não uma exportação recortada). Logs SITL (parâmetros SIM_*) não passam pelas verificações de hardware. Para registrar logs em qualquer firmware, consulte o guia de configuração do registro.

VIBE e clipping: dois sinais diferentes

VIBE.VibeX, VibeY e VibeZ são o desvio padrão do acelerômetro em m/s², uma medida da vibração média. VIBE.Clip (Clip0–Clip2 nas versões antigas) conta as amostras que atingem o limite de faixa do sensor; o contador acumula desde que a placa é ligada e não zera entre voos. O bbdoctor classifica os valores assim:

• VIBE: percentil 95 por eixo durante o tempo no ar. Abaixo de 30 m/s²: OK; de 30 a 60: atenção; 60 ou mais: crítico (limites da documentação do ArduPilot);
• Clip: aumento do contador entre a primeira decolagem e o último pouso; acima de 0 é atenção, acima de 100 é crítico. Clipping durante a armação ou depois do pouso final não conta. A documentação do ArduPilot concorda: o ideal é zero; alguns casos em pousos duros são toleráveis, mas um aumento constante é sério.

Por que é preciso olhar os dois: um log real do ArduCopter 4.7.0, fmuv2, 4S, sete voos e 414 s no ar.

O VIBE passa: 29, abaixo de 30. Mesmo assim, houve clipping 424 vezes (crítico no bbdoctor), e os dados de cada voo mostram que não foi acaso:

• Pode haver clipping com VIBE "normal". VIBE é uma média; o clipping detecta picos. Pancadas curtas (bateria solta, fio batendo na FC, rolamento ruim) mal alteram a média, mas saturam o sensor e fazem o EKF receber dados sem sentido.
• O percentil do log inteiro esconde o pior voo: Z é 29 no total e 32 no último voo. Ocorrências de clipping por minuto: 19 no primeiro voo e 134 no último. Alguma peça está se soltando.
• Não foram punch-outs. O acelerador mediano durante o clipping foi 23%, igual ao do voo inteiro; tudo ocorreu em modos de autoestabilização. A causa é mecânica.

Um octocóptero (CubeOrangePlus, 4.5.7) teve clipping 64 vezes no log, mas apenas 19 durante o voo; por isso o bbdoctor alertou sobre 19. Um Tarot X4 saudável na versão 4.5.5 (figura abaixo): X 3, Y 3, Z 7 m/s², Clip = 0.

Até corrigir VIBE e clipping, deixe os filtros e PIDs como estão. Para encontrar o motor com problema, consulte o guia de vibração dos motores. A mensagem "Vibration compensation ON" indica que o failsafe de vibração (FS_VIBE_ENABLE, ativado por padrão) já mudou o controle de altitude para uma estimativa mais tolerante à vibração.

Espectro do giroscópio e notch harmônico

Com o giroscópio bruto (GYR) registrado, o bbdoctor monta o espectro antes e depois da filtragem e procura picos que não mudam com o acelerador: ressonâncias do frame. Ele recomenda apertar o frame e, como solução provisória, sugere o segundo notch, INS_HNTC2_*, em modo fixo, somente quando a frequência é inequívoca; se o pico puder ser um alias, lista as frequências possíveis e pede um log curto do giroscópio bruto. Para uma ressonância de 140 Hz:

INS_HNTC2_ENABLE = 1
INS_HNTC2_MODE = 0
INS_HNTC2_FREQ = 140
INS_HNTC2_BW = 70
INS_HNTC2_ATT = 40

A outra opção é o amostrador em lote (INS_LOG_BAT_MASK, INS_LOG_BAT_OPT, com o bit IMU_RAW desligado): blocos de 1024 amostras (ISBH/ISBD) que quase não aumentam o tamanho do log. O bbdoctor ainda não os lê; use a ferramenta web Filter Review do ArduPilot ou o FFT do Mission Planner. Veja o Tarot X4.

O notch funciona em modo FFT (INS_HNTCH_MODE = 4). A linha mais forte está em 67 Hz, seguida por 134 e 202. A linha de 34 Hz parece ser a rotação (cerca de 2000 rpm) e 67 Hz seu segundo harmônico, a passagem das pás de uma hélice de duas pás. Mas a janela FFT termina em 62 Hz, e o FFT informou 25 Hz durante todo o voo, exatamente FFT_MINHZ (a frequência de hover aprendida, FFT_FREQ_HOVER, também é 25.0). O sistema nunca encontrou a frequência dos motores.

No modo FFT, o notch nunca fica abaixo de INS_HNTCH_FREQ, que aqui é 35 Hz. Então ele ficou nessa frequência, com um segundo notch em 70 Hz por causa de INS_HNTCH_HMNCS = 3. Por sorte, isso cobre as linhas de 34 e 67 Hz: em comparação apenas com o passa-baixa de 20 Hz, o espectro filtrado fica cerca de 10 dB mais baixo em 34 Hz e 17 dB mais baixo em 67 Hz, sem redução adicional em 134 e 202. O notch funciona, mas como notch fixo.

Esse é o ponto: nem tudo o que pode ser corrigido precisa ser corrigido agora. Depois dos filtros, as linhas de 67, 134 e 202 Hz estão 35–43 dB mais baixas; VIBE está em 3/3/7 e não há clipping. Mas uma bateria mais pesada ou outras hélices vão deslocar as linhas, e o FFT não vai acompanhá-las. Antes do próximo AUTOTUNE, eu mudaria para um notch baseado no acelerador:

INS_HNTCH_ENABLE = 1
INS_HNTCH_MODE = 1
INS_HNTCH_REF = 0.2
INS_HNTCH_FREQ = 67
INS_HNTCH_BW = 33
INS_HNTCH_HMNCS = 7

REF é o acelerador em hover (MOT_THST_HOVER = 0.20), FREQ é a linha nessa condição, BW é metade dessa frequência e HMNCS = 7 ativa os harmônicos 1–3: 67, 134 e 201 Hz. Com o padrão INS_HNTCH_FM_RAT = 1, o notch nunca fica abaixo de FREQ. O notch de 34 Hz é removido de propósito: essa linha mal ultrapassa o piso de ruído do giroscópio, e um notch tão baixo, perto da faixa de trabalho do controlador de um copter grande, reduz a margem de fase. Para mantê-lo: use FREQ 34, BW 17 e HMNCS 43 (harmônicos 1, 2, 4 e 6: 34, 67, 134 e 202 Hz). Outra opção é continuar no modo FFT e ampliar FFT_MINHZ/FFT_MAXHZ para incluir 67 Hz.

Como escolher INS_HNTCH_MODE (0 fixo, 1 acelerador, 2 sensor RPM, 3 telemetria ESC, 4 FFT): com telemetria RPM, use 3. Sem telemetria, mas com F7/H7: FFT, depois que o log mostrar FTN1.PkAvg variando com o acelerador em vez de ficar em FFT_MINHZ. Com uma controladora de voo mais fraca: acelerador. Nos modos ESC, RPM e FFT, FREQ é o limite inferior e REF é 1; REF = 0 mantém o notch em FREQ.

Filtros passa-baixa: INS_GYRO_FILTER e ATC_RAT_*_FLTD

INS_GYRO_FILTER é o filtro passa-baixa do giroscópio, com padrão de 20 Hz (no log 4.7 e no Tarot; o log 4.3.7 usa 40). ATC_RAT_RLL_FLTD/_PIT_FLTD filtram o termo D (20 no log 4.7, 10 no Tarot), FLTT filtra o alvo e FLTE, o erro (2–2.5 Hz no yaw). Initial Tune Parameters, no Mission Planner, define valores iniciais conforme o tamanho das hélices: hélices menores permitem frequências de corte mais altas.

• Aumente INS_GYRO_FILTER somente depois que o notch remover as frequências dos motores: menos atraso e resposta mais precisa.
• Aumente em etapas de 10–20% e faça um voo curto depois de cada ajuste; desarme, desconecte a bateria e toque nos motores. Mornos estão bem; se estiverem quentes, reverta o ajuste.
• VIBE normal, espectro filtrado limpo e voo estável: deixe os filtros como estão. No Tarot, eu não mexeria neles.

Uma armadilha na análise: um log de 25 Hz mostra movimentos somente até 12,5 Hz; tudo que é mais rápido retorna como uma frequência baixa falsa. Por isso, o bbdoctor não verifica filtros nem PIDs nesses logs e informa o motivo. Veja mais no guia de filtros.

PIDs: o que o log mostra e quando usar AUTOTUNE

O controlador de taxa usa ATC_RAT_RLL_P, _I, _D, _FF, e os mesmos parâmetros para PIT e YAW. O bbdoctor compara o alvo RATE.RDes (e PDes, YDes) com o giroscópio para identificar overshoot, atraso e oscilações depois de um comando rápido. RDes é aplicado depois do ajuste de entrada: ATC_INPUT_TC suaviza o comando, mas não muda o quanto o giroscópio o acompanha; portanto, essa medição avalia o próprio loop de taxa. É necessário registrar a 200 Hz; caso contrário, o bbdoctor informa "PIDs can't be assessed from this log: gyro logged at 25 Hz" e sugere os comandos da primeira seção.

No ArduCopter, o AUTOTUNE integrado costuma ser mais confiável, mas só depois de resolver a vibração e configurar o notch:

1. VIBE abaixo de 30, Clip sem aumentar e notch configurado.
2. Ative AUTOTUNE em uma chave; escolha os eixos em AUTOTUNE_AXES (1 roll, 2 pitch, 4 yaw; 7 para os três) e a agressividade em AUTOTUNE_AGGR (0.075 nos dois logs acima).
3. Use AltHold, Loiter ou PosHold com pouco vento; reserve vários minutos para cada eixo e leve bateria suficiente.
4. Para salvar o resultado, pouse e desarme mantendo a chave ligada.

Outras recomendações do ArduPilot que o bbdoctor fornece quando o log tem frequência suficiente:

• A resposta fica mais forte com acelerador alto. Copters não têm TPA no ArduPilot, então linearize melhor o empuxo: aumente MOT_THST_EXPO em 0.05 (por exemplo, 0.65 → 0.7). Se não resolver, reduza P e D em 10% e execute AUTOTUNE novamente.
• Propwash ao cortar o acelerador com os motores no mínimo. Aumente MOT_SPIN_MIN em 0.02, mantendo-o pelo menos 0.03 acima de MOT_SPIN_ARM. O log 4.7 usa 0.08 com MOT_SPIN_ARM em 0.04; a recomendação seria 0.08 → 0.1. Consulte o guia de propwash.

Há duas coisas que o bbdoctor não verifica. Compensação de tensão: no log 4.7, MOT_BAT_VOLT_MAX = 0 e MOTB.BatVolt fica em 1.00, então o recurso está desativado e o loop perde força conforme a bateria descarrega. Para 4S:

MOT_BAT_VOLT_MAX = 16.8
MOT_BAT_VOLT_MIN = 13.2

Isso corresponde a 4.2 e 3.3 V por célula; configure antes do AUTOTUNE, pois o ajuste altera o ganho efetivo. E PIDR.Dmod: se cair abaixo de 1 com frequência, o limitador de slew ATC_RAT_*_SMAX está amortecendo uma oscilação e os ganhos estão no limite. No log 4.7, ele fica em 1.00 (a amostragem de 10 Hz pode ocultar quedas muito curtas).

Saídas dos motores a 10 Hz: mostram carga, não ruído

Os logs padrão registram RCOU a 10 Hz; o bbdoctor informa: "Motor outputs are logged at 10 Hz — average loads are visible, but not motor noise". Ainda é possível ver:

• Centro de gravidade deslocado. As saídas médias são comparadas entre os lados: 12% ou mais é atenção; acima de 30%, crítico. Em outro log 4.7, os motores traseiros operaram a 62.1%, contra 55.2% nos dianteiros: 13% a mais, um alerta. No log com clipping, M1–M4 tiveram médias de 44.4 / 46.9 / 40.2 / 46.0%, cerca de 10% de diferença entre dianteiros e traseiros, abaixo do limite.
• Motor inclinado: os motores que giram para um lado carregam 12% a mais que o outro par.

Observe a ordem: em um ArduCopter Quad X, M1 fica dianteiro direito, M2 traseiro esquerdo, M3 dianteiro esquerdo e M4 traseiro direito, diferente do Betaflight.

Para encontrar um motor que vibra, é preciso RPM: use DShot bidirecional (SERVO_BLH_BDMASK, DShot em MOT_PWM_TYPE e SERVO_BLH_POLES correto) ou telemetria ESC com fio. O Tarot está configurado com 28 polos, mas usa PWM convencional, então não há RPM. Com RPM, o bbdoctor compara os motores e o notch pode usar o modo 3.

Failsafe e bateria

Depois de um crash, primeiro confira se o failsafe foi configurado; quando suspeita de um problema de link ou bateria, o bbdoctor aponta estes parâmetros. O log 4.7 (4S):

FS_THR_ENABLE = 1
FS_THR_VALUE = 950
BATT_LOW_VOLT = 14.4
BATT_CRT_VOLT = 14.0
BATT_FS_LOW_ACT = 2
BATT_FS_CRT_ACT = 1

• FS_THR_ENABLE = 1 significa RTL na perda de sinal. FS_THR_VALUE deve ficar abaixo do acelerador mínimo do transmissor e acima do valor enviado pelo receptor durante o failsafe. Teste na bancada, sem hélices.
• 14.4 e 14.0 V correspondem a 3.6 e 3.5 V por célula; as ações 2 (RTL) e 1 (pousar). O Tarot (6S, 30,000 mAh) usa 3.1 e 2.95 V por célula: adequado para Li-ion, baixo demais para LiPo.
• A tensão precisa permanecer baixa durante BATT_LOW_TIMER (10 s por padrão), para que punch-outs não acionem o failsafe. Se isso acontecer em subidas longas, defina BATT_FS_VOLTSRC como 1 (com compensação de sag).

O bbdoctor informa a tensão inicial, a mínima sob carga e a resistência interna. No log 4.7: 4.11 V por célula no início, mínimo de 3.76 V sob carga (sustentado por 0.5 s), 3.91 V no fim, pico de 13 A, cerca de 1010 mAh e aproximadamente 10 mΩ por célula (estimativa, pois tensão e corrente são amostradas separadamente).

Os nomes dos parâmetros mudam entre versões

ANGLE_MAX = 3000 no log 4.5.5 e ATC_ANGLE_MAX = 30 no log 4.7 representam o mesmo valor: 30°. O firmware converte os valores durante a atualização; o risco é copiar manualmente números de um log antigo ou de uma publicação em fórum. Se você copiar ATC_ACCEL_R_MAX = 48000 do Tarot para ATC_ACC_R_MAX em vez de usar 480, estará pedindo cem vezes mais aceleração.

Verificação automática

Envie seu .bin para o bbdoctor, grátis. Ele executa as verificações acima (registro, VIBE, clipping, carga dos motores e bateria, além de espectro e PIDs em logs rápidos), informa o que está faltando e apresenta parâmetros no formato NOME = valor. O amostrador em lote, os dados FFT, a compensação de tensão e Dmod ficam por sua conta. Os limites foram ajustados para quads FPV; em aeronaves grandes, compare com logs anteriores da mesma estrutura. Veja um exemplo de relatório; para PX4, consulte o guia ULog.

Atualizado: 2026-10-22