Software/Methodology: AMC (ArduPilot Methodic Configurator) using the “Hoverit X13” template, following the ArduPilot Copter documentation.
The Issue: I am currently at the “8. Minimalistic Mandatory Tuning” stage. My logs show exceptionally high Vibe levels, and the IMU Accel values are borderline (near the upper safety limits). This is concerning for a 50L class drone.
Current Testing: I have experimented with several damping materials. So far, the best results come from 3M Brand Tape and 3M 9448A, but the levels are still not ideal.
My Questions:
Should I prioritize further mechanical vibration isolation until IMU Accel values are well within the green zone before moving forward?
Or is it advisable to proceed with Notch Filter configuration and AutoTune to see if software-side filtering can stabilize the system?
Given the aluminum frame and the massive X13 motors, are there specific mechanical dampening strategies or mounting techniques recommended for this scale of aircraft?
Those vibrations are not ideal but not too problematic. Maybe show some pictures of the frame, because apart from loose wiring vibrating around all over the place, the next biggest problem is frame stiffness. Especially with bigger copters.
I believe the number of poles need to be changed to 21 KDE_NPOLE,21
unless there’s settings in the datalink that you can change.
Then this will be the correct settings for the harmonic notch filter:
I couldn’t find the official pole count for the Hobbywing X13 motors online, so I manually counted the magnets and found 42 poles. I have updated the KDE_NPOLE (or relevant pole count parameter) to 42 accordingly.
I’ve attached the latest flight log after this change. Overall, the aircraft’s behavior is trending in the right direction, and stability has improved. However, I feel there is still significant room for optimization.
My current questions for the experts here:
Is focusing further on Dynamic Notch Filter refinement the correct next step?
Given the vibrations I’m still seeing, should I continue fine-tuning the notch frequencies based on the new pole count, or is there another priority I should address first in the AMC workflow?
Thank you so much for your response and for developing AMC. I only discovered this software with the start of this project, and I find the philosophy behind its workflow to be excellent.
Regarding the pole count setting: I did configure this during the initial airframe setup in AMC. However, for some reason, the upload failed for that specific parameter. Additionally, I noticed that AMC references ESC_HW_POLES, which seems to behave differently from the KDE_NPOLE parameter I manually adjusted. I will investigate why this discrepancy occurred.
I will focus on confirming that the reported frequencies match the noise peak tomorrow and continue following the instructions based on your guidance.
I apologize for the oversight—I missed the log in my previous post, but it has been uploaded now. Thank you again for your invaluable help!
Go back to my suggestion for the harmonic notch filter - less is more.
Selecting more harmonics or options than are actually required can have negative/unwanted effects.
It’s likely you dont need to second harmonic.
It seems like the harmonic notch filter is ignoring your ESC RPM data. Unsure what’s happening there. EDIT AGAIN: No actually, it’s just that the number of poles of poles is wrong the otherway. So use 21 and the suggested harmonic notch filter should be good to go.
Your current filtering is inducing high delay which affect the attitude control. You may try filtering like this because first harmonic is actually not visible in log.
Changing poles number is not helping because you are getting RPM data directly via CAN, not with hobbywing datalink (indeed they have datalinkbox G3, but I don’t think it supported by the ardupilot). Some other hobbywing motors reporting wrong RPM via CAN which can be fixed by small lua script, but that’s not your case, RPM data looks valid.
Also please take a look if your props are aligned in level, in first log you had big imbalance, not sure because of that or bad COG.
Thanks for the continued support. I’ve implemented the filter settings suggested by Mike and xfacta. To keep things clear, I’ve detailed the specific adjustments in the filenames of the uploaded logs.
Key observations from today’s test flight:
Vibration Levels: I managed to get the vibe levels below 30 at several points. The Y-axis showed a noticeable improvement, but the Z-axis remains relatively high. I believe there is still room for optimization here.
CAN Communication & Pole Count: I am using CAN for motor communication. I’m still evaluating if the npole adjustment had a direct impact. I noticed several similar parameters in the list (SERVO_BLH_POLES, SERVO_FTW_POLES, and KDE_NPOLE) and I’m unsure which one ArduCopter prioritizes when using CAN-based ESCs like the X13.
Hardware Check: Regarding Mike’s point about the propellers, I am using brand-new Hobbywing X13 stock props, so mechanical imbalance from the blades should be minimal.
I’m not saying about props imbalance, I’m proposing to check the motor level on the arms, because ever small shift causes drone to rotate on yaw axis which autopilot trying to compensate, in first log, motor #3 (ESC[2].RPM) have much lower RPM. Wrong CoG can be a reason too.
Now about recent flight. You have switched to using 3rd EKF line by EK3_PRIMARY,2, keep in mind that 3rd line does not have GPS configured as position source by default, also it uses 3rd hard mounted gyro which from my experience gives better vibration levels but have more hardware filtering in IMU itself, it’s preferred to use first 2 IMU which are dampened by a foam. It’s impossible to review current filter setup because gyro data from 3rd IMU is not logged, you need to enable 3rd IMU in INS_LOG_BAT_MASK, or switch to first line by EK3_PRIMARY,0
All parameters like SERVO_BLH_POLES, SERVO_FTW_POLES, and KDE_NPOLE does not affect RPM reported by CAN AFAIK, only esc_telem:set_rpm_scale do, discussed here:
But that’s looks like not your case, I don’t see fundamental RPM in your logs, numbers just doubled from your RPM, which can be filtered by using 2nd harmonic in filter. To check exactly if reported RPM is correct I need to know AUW of your drone, so we can compare with motors datasheet.
Do you use vibration compensation platform under FC? Some dump differently on axis.
I am trying to get the vibration level down for a 750 holybro drone for better performance of drone camera with 30x zoom. I have found that connecting the 4 motors with 8mm carbon fiber tubes using 3d printed soft tpu mounts had a dramatic reduction of motor rpm vibration frequency angular motion (about 60 Hz on my drone). This was determined using IMUs mounted both on a motor arms and on the camera. Angular motion can be gotten by integrating the angular rate using Matlab…..
I also found that mounting the FC (holybro 6x) on a cheep Amazon vibration mount created a large reduction in the vibration level reported by the FC. However with this modification, did not generate any noticeable change in how drone flew.
Looks like a good mount. For any mount I wonder how one insures that the center of rotation is in line with the center of the IMU.
For video, I am mainly concerned with the angular vibration (integral of IMU rate). To my way of thinking linear vibration will make little difference in image quality, while angular vibration is a killer. When one determines the angular displacement the higher frequencies go as 1/frequency. I am finding that the only frequency that’s important is the propeller RPM (about 60 Hz).
Thanks for the continuous feedback. I’ve updated my mechanical isolation setup and have some new observations to share.
Current Setup:
I am now using a 3-layer damping platform (similar in design to the one by GuyMcCaldin).
Observations from the latest test:
VIBE Levels: Successfully dropped below 30.
IMU Accel: Interestingly, the Accel values have increased to ±10, which is concerning for a heavy-lift frame.
Analysis & Next Steps:
I suspect the Cube Orange is too light for the stiffness of this specific damping platform, causing the flight controller to oscillate at a lower frequency (effectively acting like a spring-mass system with insufficient mass).
To address this, I plan to add ballast/weight to the flight controller mount today to increase its inertia, hoping to dampen these low-frequency oscillations and bring the IMU Accel values back within a safe range.
I would greatly appreciate any advice on the ideal weight-to-damping ratio for a 50L class drone, or if there are specific parameters I should monitor in the logs during this ballast test.
1. Hardware Findings: During a detailed inspection, I found unusual wear on the propeller gaskets (washers) for Motors #3 and #4. This mechanical failure is likely the root cause of the vibrations I’ve been seeing. I am replacing these components immediately.
2. RPM & Filter Discrepancy: My current Take-off Weight (AUW) is 65kg. While the motor RPM in the logs matches the Hobbywing X13 thrust table for this weight, the Filter Viewer still shows irrational numbers. I have set npole to 21 (based on 42 magnets), but there still seems to be a scaling mismatch between the ESC data and the filter’s interpretation.
I think it’s preferable to return to using 1st IMU as primary, vibration levels does not differ a lot across 1st and 3rd accelerometer and are acceptable.
