Bug #456
openRPM filter
Description
What is RPM filter?¶
Based on the frequencies of the motors, we can apply the notch filters for these specific frequencies (for each motor and its harmonics). RPM filter (name from Betaflight) is just a set of those Notch filters (2nd order biquad) - for each sensor (Acc, Gyro), for each axis and for each motor and its harmonics. Then, based on the measured speed of the motor (from ESC), the notch filters are updated each loop and used to filter the data from Gyro and Acc. This was done in all big software (PIX4/Ardupilot/Betaflight) and works great. To read more about it, check here
Logs-based test¶
I made a test to check the concept. I implemented the basic structure of the RPM filter following this simple implementation. Then I ran the filter as it would be done during online operation (no knowledge about future measurements) and checked the noise reduction with PSD. Results can be seen below (each axis as separete plot I put at the end of the issue):
Raw data vs RPM filtered data for ACC:¶

Raw data vs. filtered data for Gyro:¶

It works very nicely, and we can control the level of attenuation with the Q parameter of the notch filter.
Requirements¶
- We need to have a fast enough motor reading from ESC (old ESC can not provide it) - ideally frequency of sampling should be 2 times higher than maximal value of the 3rd harmonic of the motors - for small motors 1st harmonic is (motor speed) is in the range 100-500 Hz so 3rd harmonic is up to 1500 Hz which would require sampling rotor speed at 3kHz! Luckily, we can ignore the frequencies >1kHz, which are usually attenuated well by the LPF (also, high frequencies are damped by the frame quite well, so the magnitude is really insignificant). However, for small drones with high Kv motors, we still need ESC sampling at 2kHz. For bigger Robots (with bigger and slower motors) it can be much lower. Also for 2-blade propellers 3rd harmonic doesn't really appear so we need even lower frequency for ESC sampling.
- In reality, we need IMU reading at high frequency. For the motors, we can assume that they have enough inertia that the velocity is not changing and 1kHz is enough to know real speed of the motors. However, to be able to filter out a specific frequency from IMU data, we need a sampling frequency 2 times higher (as I described above). So for big motors, we can get along with 1kHz (2nd harmonic will be max around 400 Hz < Niquist freq. (500 Hz)), but for smaller one we need higher IMU sampling (2kHz). Not all IMU sensors support this high rate (Tawaki can do it - max. sampling is at 32kHz). #
Possible problems¶
- Notch filters introduce a significant delay, but operational BW of the motors is far enough from control BW that we can ignore it (or set up a higher or lower limit for RPM operational BW),
- Computation expense: for 2 sensors, each with 3 axes, 4 motors with 3 harmonics, we need 2x4x3x3=72 notch filters (for hexacopter, it would be 108) which have to be updated with high frequency (1-2kHz). It is a noticeable amount of computation required; however, there are some tricks to make it easier and it was done on much worse microcontrollers (F4 series), so I don't think it is a real issue.
Additional questions¶
- Should it be in the rotorcraft or FC? - if there is no problems with delays and computation expenses for 2kHz operation it can be in rotorcraft. However, can we run just filtering at this frequency or all tasks run with 2kHz if we increase the frequency of the rotorcraft (waste of CPU)? Another option is to move low-level filtering to FC (RPM and LPF, which will work better at 2kHz) and then output the preprocessed data to rotorcraft as "raw". This is analogical as the old MKQuad FC where there is an analog filter and we set filtering on the rotorcraft to 0. Also, the microcontroller of FC can be much more "real time" than classic CPU.
- What is the implementation of the Filters? - In my opinion we should use the 2nd order filters (biquad) as others do (betaflight). Then we have an expected behaviour. Implementation can be found here
Additional plots¶
Accelerometer each axis:



Gyro each axis:



Files
AM Updated by Anthony Mallet 5 months ago
1 We need to have a fast enough motor reading from ESC (old ESC can
not provide it) -
2 In reality, we need IMU reading at high frequency.
In any case, the implementation should make no requirement on the
data rate. Of course, with too small rate it will not work "correctly"
(from the theory point of vue) but the code should still perform what
it is asked for. This is so that we can test and compare different
scenarios and also adapt to different requirements or to what is
feasible in practice.
Regarding the task rate, you can still make several computations
within a single period. E.g. task running at 1kHz but processing two
samples in a row (acquired at higher frequency) so that it computes in
practice a 2kHz filter. Having tasks running at a higher rate than
1kHz on a regular linux (not real time) may work but becomes fragile
as the frequency increases.
So to start with something, you could acquire (by hacking the paparazzi
code) motor and IMU data at 2kHz to have a sample file to work with
comfortably on a desktop computer and see how the filter behaves when
artificially lowering the data rate (taking every other sample to
emulate 1kHz acquisition for instance, or even less).