add harmonic notch tracking mode
call AP_GyroFFT::update_freq_hover() from update_throttle_hover()
move gyrofft configuration and control to AP_Vehicle
move fft logging to fft library
This formulation of the notch equations lets the user specify the depth of the Notch. The presence of a diveide by A prevents the gain going to zero and therefore achieving a perfect notch. It also provides the risk that a user may attempt to do this and cause a divide by zero error. This change adds the ability to achive a perfect notch and removes the possibility of a divide by zero.
Add Notch Filter parameter checking
This delegates updates to a bank of NotchFilters located at an rpm frequency and harmonics. Center frequency can be updated dynamically. Notch parameters are configurable, including the number of harmonics to filter on. Updates to the filter parameters are optimized across the notch bank. Convert notch bandwidth and frequency to floats.
allow all filter harmonics to be controlled.
add destructor to harmonic notch.
don't allocate sub-filters for harmonic notch if no harmonics set.
We currently check examples are buildable with waf which doesn't need
the libraries to be specified in a make.inc file. Having the makefiles
there is misleading since people try to build and realize the build is
broken.
When the the variable in which we are saving the current sum is of
integral type we can use a much more optimized apply() method: instead
of looping the entire number of samples adding them up, we always keep
the current sum in a member. It also allows the caller to decide the
type it wants to use to get the average: this may be dictated by another
interface it uses or it may want to avoid the implicit truncate in the
return of apply().
../../libraries/Filter/examples/Derivative/Derivative.cpp:16:14: warning: ‘float noise()’ defined but not used [-Wunused-function]
static float noise(void)
^
We are currently not using LowPassFilter2p<double> and it just generates
a lot of warnings on PX4 while instantiating it due to implicitly
promoting float to double:
libraries/Filter/LowPassFilter2p.cpp: In instantiation of
'T DigitalBiquadFilter<T>::apply(const T&, const DigitalBiquadFilter<T>::biquad_params&) [with T = double]':
libraries/Filter/LowPassFilter2p.cpp:86:41: required from 'T LowPassFilter2p<T>::apply(const T&) [with T = double]'
libraries/Filter/LowPassFilter2p.cpp:98:16: required from here
libraries/Filter/LowPassFilter2p.cpp:20:82: warning: implicit conversion from 'float' to 'double' to match other
operand of binary expression [-Wdouble-promotion]
T delay_element_0 = sample - _delay_element_1 * params.a1 - _delay_element_2 * params.a2;
^
Instead of requiring every program to specify the HAL related modules,
let the build system do it (in practice everything we compiled depended
on HAL anyway). This allow including only the necessary files in the
compilation.
The switching between different AP_HAL was happening by giving different
definitions of AP_HAL_BOARD_DRIVER, and the programs would use it to
instantiate.
A program or library code would have to explicitly include (and depend)
on the concrete implementation of the HAL, even when using it only via
interface.
The proposed change move this dependency to be link time. There is a
AP_HAL::get_HAL() function that is used by the client code. Each
implementation of HAL provides its own definition of this function,
returning the appropriate concrete instance.
Since this replaces the job of AP_HAL_BOARD_DRIVER, the definition was
removed.
The static variables for PX4 and VRBRAIN were named differently to avoid
shadowing the extern symbol 'hal'.
There are implementations for float, Vector2f and Vector3f for the Low
Pass Filter and the *2p filter. I tried to implement these filters
with one common template implementation. This implementation saves
some lines of code and reduced the redundancy. One could save even
more code if the currently overloaded isinf/isnan functions and checks
can be removed.
Signed-off-by: Daniel Frenzel <dgdanielf@gmail.com>
This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.