AI alone, without context does not help in this case, and will not help in most ArduPilot configuration questions.
You need to read the existing documentation that AMC presents you and if that is not enough, you need to read relevant wiki pages.
In this specific PID notch filter case the docu is the PR. So you need to read the PR, or tell the AI to read the files changed by the PR and explain them to you. This way the AI will at least get some valid context instead of alucinating generalities.
I’ll try to see to it soon
I took a close look at the filtering spectrum today and realized I’ve been going in the wrong direction all along. I contacted Hobbywing official support, and they confirmed that the RPM transmitted to the flight controller via their CAN protocol is incorrect for the X6 SE.
The CAN protocol is defined for a 10-pole motor, but the actual motor is 28 poles. This makes the calculated RPM wrong. The true motor RPM = received RPM × 10/28.
After correcting with this formula, the RPM now matches the peaks in the spectrum. However, the notch filter dynamically adjusts its center frequency based on the raw RPM value. Right now I can manually convert to the true RPM, but the ESC still sends incorrect raw RPM to the flight controller over CAN, and the notch filter still works off that wrong RPM.
Is there a way to calibrate/correct the RPM directly on the flight controller side? You mentioned there is a script for this—do you have the link and usage instructions?
It’s there, in my post. But from your log it’s not obvious that it’s wrong, for me it’s looks correct:
Due to incorrect motor speed readings previously shown in the flight controller logs, the speed difference between diagonal motors was around 600 RPM. Now that Hobbywing has provided a correction formula, the actual speed difference between the diagonal motors is about 600 × 0.35 = 210 RPM. Under this condition, is the impact still obvious, and is this level acceptable?
That is a lot better in absolute terms, but in relative terms it remains still a 20% difference between the RPMs.
Fix that.
I’ve already bought a higher-precision level gauge with a scale accuracy down to 0.1, which I expect will fix this issue. Since Hobbywing has provided the conversion formula, I shouldn’t need to use a script to correct the motor RPM anymore.
However, right now only I can see the true RPM of each motor. The key point is to let the flight controller know the actual real RPM, so the notch filter can dynamically track the peak based on the true rotational speed.
I’ve set rpm1_type = dronecan, and RPM1_SCALING = 0.35 (10-pole / 28-pole). During actual flight, the ESC RPM is visible, but RPM1 always shows -1. I’m not sure if I’ve messed up any settings.
I’ve tried setting rpm1_dc_ID to -1, 1, or 127 (ESC Node ID), and 124 (GPS Node ID). You can check my parameter screenshots for reference. Thanks.
Is this script really only this short?
As long as SCR_ENABLE = 1, does it run automatically with no extra switch settings needed?
If it’s running, will ESC RPM* then display real-time individual motor RPM values for each motor?
If I use RPM1_TYPE = DroneCAN, it only outputs the average RPM of the four motors. That means I can’t set up a separate notch filter for each motor.
On top of that, my RPM1 still can’t display correct RPM readings right now, and I’m still researching how to fix this issue.
Also, after looking at this script: it sends the calibrated RPM data to the GCS in the end.
I’d like to confirm — does it only send the corrected RPM for GCS display only, or does it also feed the calibrated RPM data into the notch filter for flight control use as well?
You need to edit the script for your own ESCs and for the ratio of your own ESCs. The script is just an example for two ESCs
It will also feed the calibrated RPM data into the notch filter but you need to configure it correctly.
Not with RPM* parameters. Those need all to be set to their default values or disabled.
You need to follow less Rossler/Betaflight procedures and more ArduPilot/AMC procedures
Thank you very much. I’ve finished setting up the script and configured the flight controller parameters: SCR_ENABLE = 1 and RPM1_TYPE = 0. I’ll test it tomorrow. I’ve learned a lot of useful knowledge from this thread. Thanks again to everyone.
We’re glad to help. good to see you making progress.
Please post a .zip file of your AMC configuration by pressing the “Zip vehicle for forum help” button. This will help other users with similar vehicles.
Okay, it’s not fully finalized yet. I’ll sort it out and upload it later. Thank you all so much for your help. After applying the ESC RPM script, the motor RPM is now back to normal. We can now really focus on how to filter out the waveform peaks more cleanly without introducing excessive latency.
I did a hover test and checked the spectrum in the Filter Review Tool (as shown in the figure). There are four prominent peaks at 37 Hz, 43.53 Hz, 75 Hz, and 95 Hz. A clear pattern can be seen:
75 Hz ≈ 2 × 37 Hz, and 95 Hz ≈ 2 × 43.53 Hz.
Evidently, 75 Hz is the second harmonic of the 37 Hz peak, and 95 Hz is the harmonic of the 43.53 Hz peak.
For a 2-blade propeller:
RPM = 37 × 60 ÷ 2 = 1110 RPM
RPM = 43.53 × 60 ÷ 2 = 1305 RPM
These two rotational speeds correspond exactly to the speeds of the two sets of diagonal motors. In other words, these two fundamental frequency peaks are precisely caused by the rotation of the two pairs of diagonal motors.
From the spectrum plot, this airframe is very well-built; almost no fuselage resonance is visible.
I set the notch filter center frequency to 37 Hz with a bandwidth of 1/4（9.25HZ）, and the filtering performance turned out excellent. I even raised the low-pass filter cutoff from the recommended 22 Hz all the way to 45 Hz, while still maintaining great filtering results.
I also enabled Multi-Source, which essentially deploys an independent filter for each motor. When I set the notch filter center frequency to 37 Hz, I could clearly see the dynamic notch filter not only tracking 37 Hz, but also automatically locking onto and filtering the 43 Hz peak.
However, I’ve run into a question now — I think I may not fully understand the parameter INS_HNTCH_HMNCS.
My previous understanding was that this parameter controls how many harmonic orders the notch filter tracks and suppresses. For example, if I set INS_HNTCH_HMNCS = 7 (meaning track the first 3 harmonics), with a fundamental center frequency of 37 Hz, the filter should attenuate peaks at 37 Hz, 74 Hz, and 111 Hz.
Meanwhile, with Multi-Source enabled, the other set of diagonal motors runs around 1300 RPM, so a second set of filters should automatically detect the 43 Hz peak and also track its three harmonics: 43 Hz, 86 Hz, 129 Hz. (Note: 43 Hz cannot be configured independently in Notch 1 unless we enable a separate Notch 2.)
To save bandwidth and minimize latency, I chose to only use Notch 1. That was my understanding of INS_HNTCH_HMNCS, but it may be incorrect. Theoretically, it should accurately filter all four peaks: 37 Hz, 43 Hz, 73 Hz, 95 Hz,111HZ,129HZ.
But the actual spectrum does not behave this way. In the Show Notch view:
the solid black lines are, as I understand it, the filter center frequencies, and the shaded areas are the effective filter bandwidth ranges.
With my current settings and Multi-Source enable, there should theoretically be 4 motors × 3 harmonic orders = 12 active filter notches. However, the plot only shows three solid lines, with center frequencies at 37.63 Hz (matches my setting), 41.59 Hz (not as expected), and 63.37 Hz (also not as expected).These frequencies show no obvious pattern at all.Meanwhile, I can only see eight filters taking effect in the time domain.As shown in the figure
This discrepancy between theory and real-world performance has puzzled me for a long time. I hope with everyone’s help this time, I can fully understand the entire filter principle thoroughly, so I can apply it properly next time.
You only need two harmonics (set parameter to 3) because the third is already below -50dB.
The frequency you set is not the center frequency, it is the minimum frequency. Set it to 30 Hz and reduce the bandwidth accordingly.
The center frequencies displayed on the graph are the average center frequencies of all four motors, hence their number.
There’s a phrase line up that I don’t quite understand.It says line up with noise peak. Does this mean I need to adjust INS_HNTCH_FREQ to make the black solid line align exactly with the noise peak?I just can’t seem to get them lined up properly no matter how I try.
That instruction phrase is only for throttle based notch filters.
Yours are ESC telemetry based filters. Follow my instructions from above.
And get rid of the yaw imbalance.
And your attenuation is too high, you only need to achieve -50dB.
With your suggested settings, the first solid black line is indeed at 30 Hz, while the second one is at 43 Hz. In addition, the first black line has no shaded range, whereas the second one does have a shaded bandwidth area. I have no idea what this means. I’ll upload a screenshot for you to check.
You rpm telemetry data is half from what it shoud be. Correct that.
After using the ESC RPM script, my RPM readings are now accurate.
For example, if the peak on the graph is at 45 Hz, for a 2-blade propeller the corresponding motor RPM is calculated as:
45 × 60 ÷ 2 = 1350 RPM
This matches my actual motor RPM, and the real-time RPM displayed in Mission Planner is also around this value.
I’ve found that as long as I align the black solid line right on the noise peak, the peak can be attenuated very effectively.
However, I still don’t understand how to adjust these black lines properly.
The first black line follows my configured base frequency, which is straightforward.
But I cannot figure out the rule for how the second and third black lines move and adjust.
Double the ratio on your lua script.
Is the number of motor poles correct?
