I’m not planning on using the BLHeli_32 capability for RPM telemetry at this point. I’d like to keep things simple for now and just stick to FFT - the same as if I were using standard PWM esc’s.
I really appreciate your help in helping me get my hands around some of this. I’m curious what you’re using as reference for some of your settings. Maybe there’s a wiki that I’ve overlooked. Or maybe you’ve got reference sheets you’ve compiled yourself.
My goal for this copter is to go to 15" props - which haven’t arrived yet - looks like Monday. So at this point I’m just trying to get the copter stable enough to run auto-tune.
Today I went back to the firmware default settings - I’ll probably start there when 15" props arrive. So as much as I really appreciate the time you’re investing in helping me - and helping me learn - I’m a little worried at having you spend more time that you can justify. I’d hate to use up my “three wishes” before I run out - and really need the help.
One thing I discovered today is that the ArduPilot wiki section on auto-tune doesn’t appear to list all the parameters that auto-tune adjusts. I sure would like to have a definitive list so I can keep track of the changes.
I’d really like to learn enough about all this so I can write a helpful article about it - to pay it forward to others.
HNOTCH is doing something, but not a complete job.
You’ll need to change it.
I hear there are improvements in the pipeline for FFT to pick up on the base frequency more reliably when it’s down in the low (sub-80Hz?) range.
See in your FFT settings and data…
It’s getting confused about something, because it’s using the 1st harmonic. You could alter some of the FFT settings, but in my limited experience when that happens it’s difficult or impossible to get it to focus on the base frequency.
Others could hopefully correct me with the required FFT settings.
EDIT
You could try some combination of these, or all of them
FFT_NUM_FRAMES,4 (or 2 or 3)
FFT_SNR_REF,20
FFT_WINDOW_SIZE,128
and adjust until you get reliable detection of the (current) 64Hz peak. Obviously that will change a bit with prop size, I estimate 15" props will give about 60Hz or just under.
If it’s not working, just set throttle-based.
You could try that, might help. Dynamic Harmonic option isn’t working well (see the graph above). I don’t really understand why one would use FFT when ESC RPM via a Bdshot target is available. Even serial ESC telemetry would probably work better than FFT. Or Throttle based as the next selection. IMO FFT is only the best choice if you don’t have RPM as a reference due to old hardware. I’m using it on one old quad with Oneshot125 (remember that?) and it’s a toss up with throttle based as to what works better.
You are going to want to use it as some point why not now before you advance with tuning? You will just have to repeat the process.
As I see these graphs, “ACC0” is a pre filter graph - and “ACC3” is its post filter graph. The ACC3 graphs shows that the FFT attenuation is reducing vibration a whole order of magnitude over what’s displayed in the ACC0 panel.
The “GYR0” AND “GYR3” graphs show similar pre and post attenuation being achieved - the peaks are a whole order of magnitude lower.
I believe in a comment you made above, you said the “ACCx” graphs are “pre” and the “GYRx” graphs are the “post.” That doesn’t seem possible with the charts that are presented.
Also note that I’ve change INS_HNTCH_FREQ, INS_HNTCH_BW and INS_HNTCH_HMCS per the suggestion of Peter’s @Clogz comment above. So I’m including harmonics.
At some point I’d like to tap into the telemetry capability of Dshot and BLHeli_32. Right now, I have to “pick my battles” - and I’ve decided not to go that route yet.
A have a faint recollection that to get the RPM telemetry from Dshot you have to implement bi-directional Dshot - and that ArduPilot has a few wrinkles in that implementation.
I’m already taking advantage of quite a few BLHeli_32 features - such as variable PWM timing to the motors. I’m even using the “By RPM” feature that was implemented in the latest BLHeli_32 firmware.
What I’d really like to have is motor temperature telemetry. As copter efficiency comes from using large propellers which can cause motors to get hotter, I’m thinking that motor temperature telemetry might make using large props a bit safer.
As a case in point, I’m using SunnySky V4006-12 KV740 motors on this project. The SunnySky data sheet shows that props up to 15" can be used as long as full throttle doesn’t exceed a specified number of seconds. eCalc issues a warning about power and temp with such large props. But so far I’ve tried 14" props and had cool motors - perhaps in part because such low throttle is required - an average of PWM-1400 or a bit less to hover.
I’ll keep the group informed as I progress - and I really appreciate all the incredible help I get from those knowledgeable people in the group such as you.
You don’t have to, Serial Telemetry will give you that now with the version you are using if you connect the telemetry output to a UART but the sample rate for RPM data is relatively low compared to Bdshot. Bdshot provides RPM data every ESC command update (loop rate). Sends out a ESC signal and receives RPM data back. I don’t think there are any wrinkles with the hardware you are using, it’s very common to use the Dshot target with Cube Orange and Dshot capable ESC’s.
Fine to go at your own pace but you will get to a better tuned craft by using the best available technology now.
One suggestion. You are building nice craft with quality hardware. Build a 5” Test Mule quad that you can throw around and not worry about crashing. I have always had such a craft. You will learn a lot with low risk.
Basically ignore the Acc graphs (although they can be a clarifying reference or confirmation sometimes).
It’s the Gyro graphs you want, Gyro0 is pre-filter and Gyro3 (with your FC) is post-filter.
You can see in the post-filter graph the peaks are still quite noticeable at the default scale, I’d expect them to be much lower, or really flattened off.
The problem with the HNOTCH settings you have is that it’s still working from faulty FFT data that targets that nice clear first harmonic, instead of the base frequency that caused it.
The BDSHOT firmware update is a quick easy route to get RPM data. The serial port/telemetry wire route gets you voltages and temperatures too. You can even run both for each of their advantages, and other Cubes do this fine. Not pushing you down either way, it’s up to you. Just backing up what Dave said.
EDIT:
in the pre- and post-filter graphs, they both would show some filtering even without any HNOTCH settings in place. This is most apparent in the Accel graphs. Because of these low pass filters:
INS_ACCEL_FILTER
INS_GYRO_FILTER
I’ll continue to dig into the wiki to see what I can learn about improving about using FFT.
As I recall, the basic FFT doesn’t require setting anything more than just turning it on - it just works.
I don’t disagree that by overriding some parameters it may be able to be improved. But if I’m making changes that are wrong, I at least stand a chance of making things worse.
For a typical user who’s not investing a great deal of time learning the details of FFT, it may be better to simply let it work on it’s own - rather than taking the risk of making it worse by “tuning” parameters the wrong way.
In the mean time - my charts so a 10-times reduction in vibration detected - seems to me that this is a significant improvement.
BTW - regarding ESC telemetry - I expect if temperature data is provided, it’s the temperature of the ESC, not the motor. I’ve heard that motor temperature telemetry can be achieved - but I’m not familiar with how it’s implemented.
As my ESC is rated at a much higher amperage than I will ever experience, I’m not concerned about the temperature of the esc for now.
I’ll study up on BDSHOT when I get some time. I’m glad to know it’s now functioning properly.
I agree the FFT can be mostly left to it’s own devices. In your case, and I see it a bit with larger props, it doesnt pick up on the correct base frequency. It seems to be when there’s either a mess of noise (totally understandable), or like yours where the amplitude of the base frequency is low compared to the amplitude of the harmonics.
So you can leave it like it is and “it’s doing something” but that’s not my interpretation of how you work
I would either go with some of the FFT adjustments to see what helps it work down around 60Hz (you can tell from FFT_FREQ_HOVER), or disable it and set the throttle based notch.
I’m sure you’d feel more comfortable knowing that HNOTCH was targeting the correct frequency and not just a harmonic - I know I would.
FYI, while INS_HNTCH_MODE is 4 and INS_HNTCH_OPS is 2 → the value of INS_HNTCH_FREQ doesnt matter since the frequency comes from FFT. So even though 60Hz is the frequency to target, HNOTCH is ignoring that setting and believing FFT.
