Position Hold Low Frequency Vibration on Pavo20 Copter, any idea?

lida2003 · June 7, 2026, 6:44am

In Position mode (the optical flow module is normal and has been tested on other aircraft), after basically tuning the filters and PID in Stabilize mode, the flight feels very smooth.

When switching to Position mode, it initially hovers reasonably well, but after a while, it starts drifting left and right, then forward and backward, eventually drifting quite severely, requiring manual control for landing. Please refer to the log for details.

Many low-frequency vibrations are observed. What might be causing this, and what hasn’t been tuned properly?

My FC installtion (There is no dynamic interference around the flight controller board, and it is not touching anything.):

lida2003 · June 8, 2026, 12:10am

By adjusting rate p and p, there seems to be some progress. However, I don’t understand the principles behind it. Is there any guide I can read?

Does the propeller plane being lower than the upper plane of the ring cause turbulent flow, thereby affecting vibration?

propellers changed (no big difference): https://review.px4.io/plot_app?log=06eb298a-02c4-43d8-b9b4-7b86197c1cd1

farhang · June 10, 2026, 3:30am

your cut off freq seems unnecessarily high. Bring it down to 40 and fly again.
Bringing down P values means you make the attitudes less aggressive when responding to desired set points but your wobble is low frequency, so the gains likely need to go up, not down. So over a time horizon you have less accumulated noise. You can add a bit of D as well and try again. Just be careful about the increment steps of all these values.

lida2003 · June 10, 2026, 11:35pm

Using PX4 default params
MicroAir H743 AIO V1 board
Pavo20 T300 carbon frame
No filters I think.

It seems there is a 10~15 Hz vibration also. Maybe I should lower PI on roll axis and add some band-pass filter.

farhang · June 10, 2026, 11:53pm

ok now the cutoff should increase to 60.

Also try to start tuning from here: PX4-Autopilot/ROMFS/px4fmu_common/init.d/airframes/4901_crazyflie21 at 96e6fd0a46624449baae03246b65d2efb80fbccd · bradfordrobbins/PX4-Autopilot · GitHub

lida2003 · June 10, 2026, 11:58pm

Thanks @farhang I did lower PI 20% on roll, which has significant effect.

I’ll try follow your instructions above, and check what we’ll got.

lida2003 · June 11, 2026, 12:11am

Increase DGYRO/ACC cutoff to 60

In the FFT of angular velocity, there are some resonances in roll and pitch. What parameters should be tuned to address this?

Lower ACC cutoff to 30, and lower Yaw PI 20%

Increase ACC cutoff back to 60

farhang · June 11, 2026, 12:34am

Enable dynamic notch: IMU_GYRO_DNF_EN = 2, IMU_GYRO_DNF_MIN = 30. Your motor line is at ~89 Hz and leaking into torque output.
Fix MC_PITCHRATE_K = 0.4, set it back to 1.0. Your effective pitch gains are 40% of nominal, that’s why the poshold wobble (2-3 Hz) is worse in pitch maybe? . Tune P/I/D directly, don’t scale K.
Then retune rate P, and position loop last if the wobble persists.

lida2003 · June 11, 2026, 1:26am

Enable dynamic notch: IMU_GYRO_DNF_EN = 2, IMU_GYRO_DNF_MIN = 30
Fix MC_PITCHRATE_K = 0.4, set it back to 1.0.
Set MC_AIRMODE = 0 //it vibrates when on the ground, just disable

QA:
a) How did you find out " Your motor line is at ~89 Hz and leaking into torque output."
b) Should I continue lower PI to tune the resonances(wobble ) in roll and pitch in the FFT of angular velocity

–
lowering PI 20% in roll/pitch, not much changes.

farhang · June 11, 2026, 1:50am

a) FFT peaks are shown around that frequency.

b) No, the opposite. Lowering P/I makes it worse. The actual resonances can’t be tuned out with gains at all; they’re mechanical, notch filters handle those. Order is: notches added, then raise rate P until fast oscillation appears and then maybe reduce ~30% in 10% decrements.
Mostly: fast shaking = gains too high, slow wandering wobble = gains too low.

lida2003 · June 11, 2026, 2:18am

Enable dynamic notch: IMU_GYRO_DNF_EN = 2, IMU_GYRO_DNF_MIN = 30
Add NF 100Hz BW 40
increase rate PI 20% relative to default value

OK, now I got below data, which is even worse

EDIT:

Maybe I should start from here(as you have previously posted):

github.com/bradfordrobbins/PX4-Autopilot

ROMFS/px4fmu_common/init.d/airframes/4901_crazyflie21

96e6fd0a4


      
          param set-default IMU_DGYRO_CUTOFF 70
          param set-default MC_PITCHRATE_D 0.002
          param set-default MC_PITCHRATE_P 0.07
          param set-default MC_ROLLRATE_D 0.002
          param set-default MC_ROLLRATE_P 0.07
          param set-default MC_YAW_P 3

EDIT2: https://review.px4.io/plot_app?log=a11284c7-fba8-480c-9ad0-283ddf580a01

farhang · June 11, 2026, 2:34am

Yeah start from the scratch. Bring your notch on 60Hz. And go carefully with increments.

This video may also give you an idea:

lida2003 · June 14, 2026, 7:24am

Got no progress. I have checked Chris Rosser 's video about how to tune pid for px4, but there is no bdshort for PX4 1.15.4, there is no DSHOT_BIDIR_EDT or DSHOT_BIDIR_EN for me to choose.

farhang · June 14, 2026, 10:16pm

What do you mean by no progress? You have any new logs? Did you reset the gains?

lida2003 · June 18, 2026, 6:36am

I have to use another Pavo 20 copter to tune.

a) K has been set back to 1.0.
b) There is no bdshot for 1.15.4, so I use FFT not RPM
c) use default PX4 values

This one has the same low-frequency issue below 20 Hz, but it also has an occasional twitch (a problem with angular deviation). See the log for details:

EDIT: yaw twitch is something to do with RC calibration.

EDIT2: The best result I have got(still vibration around 5Hz):

EDIT3：It seems a little better, but still got no clue:

EDIT4：There is some low oscillation here, any suggestion?

lida2003 · July 18, 2026, 4:27am

It seems bdshot is not working properly in v1.16.2. We should try the latest version ???

BTW, a loose screw is the root cause of the 5/10 Hz vibration peak.

github.com/PX4/PX4-Autopilot

BDShot/AM32 telemetry fails on battery-only boot when FC is powered from ESC/BEC, but works if FC boots before ESC rail

opened 09:04AM - 19 Jun 26 UTC

tasdep

kind:bug scope:drivers

## Description I am seeing a repeatable startup-order issue with PX4 bidirectio…nal DShot on a Holybro Kakute H7 using an AM32 4-in-1 ESC. When the flight controller and ESC are powered together from the main battery, BDShot telemetry does not start. The ESCs/motors can be powered, but PX4 receives no valid BDShot telemetry from any motor. If the FC is powered first over USB, and then the ESC battery is connected about 10 seconds later, BDShot telemetry starts correctly on all 4 motors and RPM feedback works. ## Hardware - Flight controller: Holybro Kakute H7 - ESC: MicoAir AM32 4-in-1 ESC - Motor outputs: MAIN1-4 - No separate ESC telemetry wire used - FC is powered by ESC/BEC when USB is not connected ## PX4 / BDShot Version Firmware is based on the PX4 v1.18 prerelease BDShot implementation that supports per-timer BDShot selection and multiple timer groups via sequential burst/capture. The branch under test is a local/custom branch derived from PX4 `v1.18.0-alpha1`. On-board version reported: - PX4 git hash: `3e89291f9da0be13d73cebc1564f43262a84faf6` - Branch under test: `tas/kakuteh7-bdshot-nosd-bench` - `git describe --tags --always HEAD`: `v1.18.0-alpha1-195-g3e89291f9d` - PX4 version reported by `ver all`: `1.18.0 40` - Board: `HOLYBRO_KAKUTEH7` Local branch changes relevant to this test: - Disabled the old Kakute H7 serial DShot telemetry startup line: `dshot telemetry -d /dev/ttyS5` - Allowed bench arming without an SD card - `DSHOT_TEL_CFG=0` - `Serial Telemetry: Disabled` confirmed in `dshot status` - `DSHOT_ESC_TYPE=1` for AM32 - `DSHOT_BIDIR_EDT=0` - `PWM_MAIN_TIM0..3=-7` for BDShot300 on all four motor timer groups ## Expected Behavior BDShot telemetry should start reliably after a normal battery-only boot where the FC and ESC are powered together from the flight battery. `dshot status` should show all four channels Online, and `esc_status.esc_online_flags` should be `15`. ## Actual Behavior ### Case 1: Battery-only boot, no USB Steps: 1. Unplug everything. 2. Plug in flight battery. 3. FC powers from ESC/BEC. 4. Connect over companion/Pi MAVLink route. 5. Check `dshot status`. Result: - All four BDShot channels Offline - `esc_online_flags: 0` - No RPM feedback - Diagnostic instrumentation showed empty captures: - `raw 0x000000` - `shifted 0` - `intervals 0` - `read_ok 0` Example: ```text BDShot Telemetry: Enabled Serial Telemetry: Disabled ESC Type: AM32 (1) Ch0: read_ok 0, fail_crc ..., raw 0x000000, shifted 0, intervals 0, min 0 Ch1: read_ok 0, fail_crc ..., raw 0x000000, shifted 0, intervals 0, min 0 Ch2: read_ok 0, fail_crc ..., raw 0x000000, shifted 0, intervals 0, min 0 Ch3: read_ok 0, fail_crc ..., raw 0x000000, shifted 0, intervals 0, min 0 ``` ### Case 2: USB/FC first, ESC battery later Steps: 1. Plug USB into FC first. 2. Wait for PX4 to boot. 3. Plug ESC battery about 10 seconds later. 4. Check `dshot status`. Result: - All four BDShot channels Online - `esc_online_flags: 15` - RPM feedback works while armed/spinning Example observed while spinning: ```text esc_online_flags: 15 (0b1111) esc_armed_flags: 15 (0b1111) esc_rpm: 2428 2400 2414 2414 ``` `dshot status` also showed all four channels Online with `read_ok` increasing on all channels. There is a possibly related ArduPilot issue for AM32 BDShot startup reliability: - https://github.com/ArduPilot/ardupilot/issues/32351

github.com/PX4/PX4-Autopilot

fix(boards/micoair-h743-v2): drive PWM/DShot output pins low on reset… (#27876)

main ← IgorKolesnikov:IgorKolesnikov/dshot-esc-bootloader-fix

opened 02:09PM - 12 Jul 26 UTC

IgorKolesnikov

+1 -1

… instead of floating them as inputs board_on_reset configured the PWM timer …channels as GPIO inputs, letting them float high before DShot output is initialized. ESCs sample the output line at power-up and interpret a floating/high signal as a bootloader-entry request, so motors could unexpectedly enter ESC bootloader mode instead of arming normally. Configuring the pins as GPIO outputs driven low keeps them at a defined low level through reset until DShot takes over, matching what the ESCs expect on power-up. Tested on MicoAir743v2-AIO-45A: ESCs no longer enter bootloader mode on boot, motors arm and respond to DShot normally.

github.com/PX4/PX4-Autopilot

[Bug] Enabling BDShot breaks motors 1 and 2

opened 06:54PM - 14 Mar 26 UTC

closed 08:22PM - 27 Mar 26 UTC

tuupola

### Describe the bug With MICOAIR_H743_V2 after enabling bidirectional dshot an…d rebooting, motors 1 and 2 stop working. Also `dshot status` starts to show errors. Using self compiled `1.16.1` with small changes to defaults. Did not try with other boards nor `master` branch yet. Wild guess is timer configuration issue? ```shell $ git diff diff --git a/boards/micoair/h743-v2/default.px4board b/boards/micoair/h743-v2/default.px4board index 74f1e2de29..2a7ca57498 100644 --- a/boards/micoair/h743-v2/default.px4board +++ b/boards/micoair/h743-v2/default.px4board @@ -21,9 +21,10 @@ CONFIG_DRIVERS_GPS=y CONFIG_DRIVERS_IMU_BOSCH_BMI088=y CONFIG_DRIVERS_IMU_BOSCH_BMI270=y CONFIG_COMMON_MAGNETOMETER=y +CONFIG_DRIVERS_OSD_MSP_OSD=y CONFIG_DRIVERS_PPS_CAPTURE=y CONFIG_DRIVERS_PWM_OUT=y -CONFIG_COMMON_RC=y +CONFIG_DRIVERS_RC_CRSF_RC=y CONFIG_DRIVERS_RC_INPUT=y CONFIG_DRIVERS_TAP_ESC=y CONFIG_COMMON_TELEMETRY=y ``` With `DSHOT_BIDIR_EN 0` both motors spin after arming and `dshot status` does not show errors. ```shell nsh> dshot status INFO [dshot] Outputs initialized: yes INFO [dshot] Outputs used: 0xf INFO [dshot] Outputs on: yes dshot: cycle: 31966 events, 605574us elapsed, 18.94us avg, min 17us max 30us 1.755us rms INFO [mixer_module] Param prefix: PWM_MAIN control latency: 31970 events, 3722141us elapsed, 116.43us avg, min 103us max 279us 7.404us rms INFO [mixer_module] Switched to rate_ctrl work queue Channel Configuration: Channel 0: func: 101, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 1: func: 104, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 2: func: 103, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 3: func: 102, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 4: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 5: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 6: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 7: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 8: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 9: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 ``` With `DSHOT_BIDIR_EN 1` motors still spin and `dshot status` is ok. ``` nsh> param set DSHOT_BIDIR_EN 1 DSHOT_BIDIR_EN: curr: 0 -> new: 1 nsh> dshot status INFO [dshot] Outputs initialized: yes INFO [dshot] Outputs used: 0xf INFO [dshot] Outputs on: yes dshot: cycle: 46272 events, 876355us elapsed, 18.94us avg, min 16us max 30us 1.715us rms INFO [mixer_module] Param prefix: PWM_MAIN control latency: 46276 events, 5387239us elapsed, 116.42us avg, min 103us max 331us 7.359us rms INFO [mixer_module] Switched to rate_ctrl work queue Channel Configuration: Channel 0: func: 101, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 1: func: 104, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 2: func: 103, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 3: func: 102, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 4: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 5: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 6: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 7: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 8: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 9: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 ``` After reboot motors 1 and 2 stop spinning and `dshot status` shows only failed reads for timer 0 channel 2 and 3. ``` nsh> reboot ... nsh> dshot status INFO [dshot] Outputs initialized: yes INFO [dshot] Outputs used: 0xf INFO [dshot] Outputs on: yes dshot: cycle: 11132 events, 239175us elapsed, 21.49us avg, min 18us max 34us 2.470us rms INFO [mixer_module] Param prefix: PWM_MAIN control latency: 11136 events, 1310837us elapsed, 117.71us avg, min 104us max 199us 8.502us rms INFO [mixer_module] Switched to rate_ctrl work queue Channel Configuration: Channel 0: func: 101, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 1: func: 104, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 2: func: 103, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 3: func: 102, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 4: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 5: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 6: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 7: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 8: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 Channel 9: func: 0, value: 0, failsafe: 0, disarmed: 0, min: 109, max: 1999 INFO [arch_dshot] dshot driver stats: INFO [arch_dshot] Bidirectional DShot enabled INFO [arch_dshot] Timer 0, Channel 0: read 3391, failed nibble 1, failed CRC 0, invalid/zero 76 INFO [arch_dshot] Timer 0, Channel 1: read 3393, failed nibble 0, failed CRC 0, invalid/zero 76 INFO [arch_dshot] Timer 0, Channel 2: read 0, failed nibble 0, failed CRC 0, invalid/zero 3470 INFO [arch_dshot] Timer 0, Channel 3: read 0, failed nibble 0, failed CRC 0, invalid/zero 3470 ``` ### Flight Log / Additional Information ``` nsh> ver all HW arch: MICOAIR_H743_V2 PX4 git-hash: 94cb2012792b2ae89f0b147cfee53ee31ae550be PX4 version: Release 1.16.1 (17826303) OS: NuttX OS version: Release 11.0.0 (184549631) OS git-hash: 886acbbdb4f061e5c0ce1a76afbcfa7cb7df9849 Build datetime: Mar 13 2026 16:28:56 Build uri: localhost Build variant: default Toolchain: GNU GCC, 13.2.1 20231009 PX4GUID: 000600000000333538343233510d003d001f MCU: STM32H7[4|5]xxx, rev. V ```

gfLv_amov · July 19, 2026, 8:41am

Thanks for sharing the root cause. If possible, a before-and-after log with the loose screw fixed would be very useful for distinguishing mechanical vibration signatures from controller-gain issues. It may also help to keep the BDShot telemetry problem separate, since the linked issue uses a different PX4 version and hardware setup.