-
Notifications
You must be signed in to change notification settings - Fork 18.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filtering: re-work harmonic notch filter freq clamping and disable #25442
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm really not on board with this at all I am afraid. The structure is no easier to understand and we are making quite large sweeping changes to some very basic functionality. I don't think its necessary to make a change this large in order to address the bug in question and we have some quite subtle things going on. I don't think we should be handling options down in the filter class. If we do want to make such a large change I think the refactoring needs to be separate to the bug-fixing.
66e1273
to
71a8431
Compare
it is not just that it is easier to understand, it fixes a number important limitations:
the ability to completely disable notches when an RPM is zero is critical for fixed wing, and is at the heart of the bug that led to this work. The logic to treat zero as INS_HNTCH_FREQ was repeated in many places in the code, and it is just the wrong this to do in most aircraft. This centralises that decision and then gives the user the ability to configure either for the existing (use min freq) behaviour or to completely disable the notch. That is a huge improvement for fixed wing, and it enables us to remove the checks in AP_Vehicle.cpp that prevented the use of notches for fixed wing. |
Let's sit down and discuss because I do not agree and you are railroading in changes that require more discussion and thought. I have spent some time discussing with @lthall and I think there are other ways to do this that are certainly less invasive and less likely to introduce problems. |
@lthall is going to write up an issue to explain the problem we are trying to solve |
cf84b98
to
1c5d873
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before starting work on this we should accept #25355 as it fixes the original bug and the bug introduced in #25352. That gives us a minimum change fix to the existing code that can be back ported. Then we can develop this as a feature enhancement.
I have started a feature request as a place to develop the specification for this algorithm here: #25461
3a71d41
to
80e591a
Compare
80e591a
to
1e8bd30
Compare
1e8bd30
to
26e264b
Compare
The attenuation formula from #25461 does not seem to be correct. This PR implements it and also adds a test that graphs attenuation and phase lag with and without the adjustment
The purple and green lines are with the TreatLowAsMin option, which is what we do now. We see that the maximum attenuation is at 50Hz as expected. |
26e264b
to
297e736
Compare
after some discussion with @lthall we decided to use a linear interpolation and keep the notch at the min frequency. This ensures phase lag is no worse than current code but still has the property of no glitches as the notch fades to zero. the above graph is for:
you can see that the source freq of 35Hz, which is below the 50Hz min freq, results in a notch at 50Hz, while reducing the attenuation |
297e736
to
b1f164f
Compare
b1f164f
to
61b92a3
Compare
@lthall @andyp1per after the discussion on the call today this graph illustrates the result: This is the familiy of attenuation graphs for the following settings:
the different graphs are for changes in the RPM source frequency. You can see the harmonics folding down into a single notch then completely disabled, which is I think exactly what we want |
61b92a3
to
1b03ca2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few things remaining. I think the logging is basically ok but a couple of tidy-ups. There are a couple of comments that haven't been addressed and we need to resolve the FFT issue.
do all frequenct clamping in one place in set_center_frequency(). Allow for zero frequency to disable the notch. Add an option to treat inactive RPM source as min frequency
moved the claiming down into HarmonicNotchFilter
and pass params object down into HarmonicNotchFilter
fill in a parameters structure
this also fixes the uint8_t storage of a number than can be greater than 256. Max total notches in a single HarmonicNotchFilter is currently 12*16*3 for 12 ESCs, with INS_HNTCH_HMNCS=0xFFFF and triple notch
max is more than 256
use sqrt() adjustment from Leonard
this prevents duplication of the logic for the priority of the double notch vs the triple notch option
log up to 5 sources in new FCN message, or FCNS for single source
This reworks the harmonic notch setup. Major changes include: