You may need to go lower on INS_HNTCH_FREQ, but also on these big copters you will need the double notch
I also have a static notch configured:
I did this to try and get the other spike down. Which it helped a lot.
When is your double notch making it into the mainstream code?
When it’s had enough testing. It works find and I’m happy to do you a build of 4.0 with it enabled if you would like. The question is the optimal spacing of the two notches which I’m not sure whether we have got that right or not yet.
If you can do a CUAV v5 nano build on 4.0.3+ that would awesome and i can load it when ever it’s ready. Thanks
you need to set INS_HNTCH_OPTIONS=1 for it to work
Got it, thanks. Supposed to be nice outside tomorrow and I can give it a try
Any other settings besides the one listed above?
This shouldn’t wipe out my existing settings right?
It’s vanilla 4.0.3 with the notch, shouldn’t change anything. Your HNTCH settings will be interpreted relative to the double notch, so you shouldn;t have to change anything else
Hi @andyp1per, thank so much for your work on the Harmonic Notch it’s very usefull, we used in every 5" copter since its first version instead of the previous static notch filter with great improvement.
I was using MP for made the FFT graph with the DF log, yesterday with the help of @anbello I’ve made a second graph with your mavfft_isb.py but the gyro graph appear somehow strange and the MP one seems more correct, could you help me understand the cause of it?
The log its post filtering and the Harmonic Notch is based on the simple throttle method atm.
this is the bin:
this is the DF log used for MP FFT graph:
The relevant parameters are:
Furthermore, I’m trying to improve and fine-tuning the throttle method before starting to test the esc telemetry method. Do you suggest me some different settings to try in the HNTCH parameters?
Hi Giorgio, pretty sure the weird output you see is because the log is corrupted. There are many data entries without a corresponding header (I have seen this when logging using FRAM) and I suspect this with a combination of too few samples is giving the analysis artifacts you are seeing. Whether we can do better in this regard I am not sure - I would have to delve into the specifics of your log. It would be useful if you could raise an issue on pymavlink?
On the settings please set INS_LOG_BAT_CNT back to the default of 1024. The longer length will mean you are more likely to get corrupted frames.
Your INS_HNTCH_REF is set below MOT_THST_HOVER which means that INS_HNTCH_FREQ should be somewhere below your hover freq, but from your graph it doesn’t appear that way? What happens if you set INS_HNTCH_REF = MOT_THST_HOVER ? Did you go through the procedure on the wiki for having a lower based frequency for the notch?
I will hopefully get it loaded this weekend
@andyp1per Thanks for all of your work! I’m going through the dynamic filter wiki with my 13" quadcopter with an AUW of 3.3kg. I’m using ESC telem as a reference for the notch. It flies pretty good, but has a strange issue where the CCW motors run about 10% faster than the CW motors. I know this is usually caused by frame flex/twist or motors that are not level. At this point I’ve gone to great lengths to make sure that the frame and motor mounts are rigid and level. Overall it has very low vibes, so I decided to dive into the FFT and see what it had to say.
Hover is about 5k RPM
This log is INS_LOG_BAT_OPT_1
Here’s a zoom of the same log
Here it is with INS_LOG_BAT_OPT_2
and the zoom
As you can see the filter is definitely helping but holy cow it’s a ton of noise at 41hz, even after filtering. Any idea what might be causing this?
Here’s my HNTCH settings
FC - mRo Control Zero mounted on Kyosho Zeal anti-vibe pad running on 4.0.4dev
ESC - AK32PIN
Motors - Brother Hobby 2812 600kv
Props - APC 13x4.5 MR
Battery - 6s 9Ah Li-Ion
Pre filter log - https://drive.google.com/open?id=1urHl38HXMQ34w978HNaJc6fKR0t-1Ocd
Post filter log - https://drive.google.com/open?id=1fyEi6YrJWTMzfsQ6Yj6exoqXQJxbQYkE
MH1 tuning.param (18.4 KB)
Something is not working here. You should have CTUN->N which will tell you what frequency the harmonic notch is using. You should be able to compare this with you rpm, but the value is missing. My guess is the harmonic notch is not working at all.
Ohhh, you are flying master. Looks like there is a bug - if FFT is not enabled then you don’t get harmonic notch logging Are you able to try this on 4.0.3? Or I guess enable FFT.
I can try 4.0.3 no problem. Is that the best way to go? Or should I try enabling FFT in 4.0.4?
Enabling FFT is fine, you are not relying on it for control so it might be a useful datapoint. Just be aware that there are some calibration bugs that I have fixed in another PR which might (or not) stop you arming depending on your FC
Here are my current settings, 3" / 4S
Gecko3-Tuned4.0-dev.param (19.8 KB)
here are the logs based on mode 3, with the same parameters, pre and post filtering:
Pre Filter https://drive.google.com/open?id=1csJGaqGWAALd8CON5L3p9YP2pg9aOaab
Post Filter https://drive.google.com/open?id=1D6LuUJYAPMgwurhVU5EDI_hTz6W3ayg7
These are some of the relevant parameters:
Do you see some way to improve the filtering?
Its working well. FFT says about 206Hz. RPM is between 12000 - 13000 which is 200-212Hz so all good.
For such a small copter try increasing Gyro filter to 100 or even 110 and increase FLTT/FLTD to 80 on both roll and pitch. I suggest you do an autotune if you can to eliminate the wobbles - you might want to reduce P and D on pitch and roll. You won’t need much D at all I would guess. Since you have ESC telemetry the notch bandwidth could probably be lower.
You are on a roll Andy with new stuff in Master Motor RPM from FFT? Cool.
It took some persuading, but both @Leonardthall and I agreed it was the right thing to do - it makes it very easy to get an estimate of RPM in telemetry even if you don’t have a sensor and you don’t have to figure out much - just enable the pseudo-sensor.