Skip to content
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

Merged
merged 16 commits into from
Mar 15, 2024

Conversation

tridge
Copy link
Contributor

@tridge tridge commented Nov 2, 2023

This reworks the harmonic notch setup. Major changes include:

  • move all clamping decisions down to one place in HarmonicNotchFilter::set_center_frequency
  • by default disable notch completely when freq is under 50% of min freq
  • added INS_HNTCH_OPTS bit to use min freq when RPM source stops (for heli governors)
  • make the double and triple notch clearer, note this changes the spread for harmonics, need to think if that is correct
  • removed code that initialised frequencies to the min freq, instead rely on update calls
  • allow harmonic notches to run in quadplanes in fwd flight

@tridge tridge added the WIP label Nov 2, 2023
@Hwurzburg Hwurzburg added the WikiNeeded needs wiki update label Nov 2, 2023
Copy link
Collaborator

@andyp1per andyp1per left a 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.

libraries/AP_ESC_Telem/AP_ESC_Telem.cpp Outdated Show resolved Hide resolved
@tridge
Copy link
Contributor Author

tridge commented Nov 3, 2023

The structure is no easier to understand and we are making quite large sweeping changes to some very basic functionality.

it is not just that it is easier to understand, it fixes a number important limitations:

  • fixed wing notch filtering works for fwd motor (doesn't work at all in master)
  • quadplane notch filtering works when in fwd flight (doesn't work at all in master)

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.

@tridge
Copy link
Contributor Author

tridge commented Nov 3, 2023

the DynamicRpmNotches flapping test has me worried. It failed on this PR:
image
it passes locally, so likely just flapping again, but I think we should try and get it fixed

@andyp1per
Copy link
Collaborator

The structure is no easier to understand and we are making quite large sweeping changes to some very basic functionality.

it is not just that it is easier to understand, it fixes a number important limitations:

* fixed wing notch filtering works for fwd motor (doesn't work at all in master)

* quadplane notch filtering works when in fwd flight (doesn't work at all in master)

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.

@andyp1per
Copy link
Collaborator

@lthall is going to write up an issue to explain the problem we are trying to solve

@tridge tridge force-pushed the pr-notch-rework branch 3 times, most recently from cf84b98 to 1c5d873 Compare November 3, 2023 22:22
Copy link
Contributor

@lthall lthall left a 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

libraries/Filter/NotchFilter.cpp Outdated Show resolved Hide resolved
@tridge
Copy link
Contributor Author

tridge commented Jan 29, 2024

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
image
In the above graph the attenuation and lag is plotted with and without the adjustment. This graph shows:

  • source frequency of 35Hz
  • notch min freq of 50Hz
  • bandwidth of 25Hz
  • attenuation of 30dB

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.
The blue and yellow lines are without the TreatLowAsMin, which means it is using the attenuation formula to allow the tracking frequency to drop below the notch min freq. As expected we see that the maximum attenuation is at the source frequency of 35Hz. The problem is that for frequencies above 35Hz we see more phase lag than we get with the old method, which means the attenuation forumula is not achieving the "no more phase lag than at min freq" target

@tridge
Copy link
Contributor Author

tridge commented Jan 29, 2024

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.
image

the above graph is for:

  • source frequency of 35Hz
  • notch min freq of 50Hz
  • bandwidth of 25Hz
  • attenuation of 30dB

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

@tridge
Copy link
Contributor Author

tridge commented Jan 30, 2024

@lthall @andyp1per after the discussion on the call today this graph illustrates the result:
image

This is the familiy of attenuation graphs for the following settings:

  • INS_HNTCH_FREQ = 50
  • INS_HNTCH_HMNCS = 15
  • INS_HNTCH_BW = 25
  • INS_HNTCH_ATT = 30

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

Copy link
Collaborator

@andyp1per andyp1per left a 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.

tridge added 15 commits March 12, 2024 07:23
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
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
@andyp1per
Copy link
Collaborator

@tridge I setup a post-filter fft notch to test this, but I am not getting any logging for the second notch which makes me think it isn't working. Not sure whether its your PR or something else, maybe you can see what is going wrong. Here is the log:

log1.zip

@tridge
Copy link
Contributor Author

tridge commented Mar 15, 2024

I setup a post-filter fft notch to test this, but I am not getting any logging for the second notch which makes me think it isn't working.

I'm seeing logging for both notches in your log.
Here is the first notch, a multi-source ESC notch:
image
here is your 2nd notch, a single source FFT notch:
image
maybe you don't know that FTN is used for multi-source and FTNS is used for single source?
here it is with 1st and 2nd harmonic shown:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WikiNeeded needs wiki update
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants