Fixes for IMU filter settings

[bkueng]

The description of IMU_GYRO_CUTOFF says:

* The cutoff frequency for the 2nd order butterworth filter on the gyro driver. This features
* is currently supported by the mpu6000 and mpu9250. This only affects the signal sent to the
* controllers, not the estimators. 0 disables the filter.

But this is not correct, it also sets the on-chip DLPF cutoff frequency to the next supported higher value. It means that #9070 had a much larger impact than what I thought (it set the on-chip filter to 98Hz, thus affecting the estimators as well).

But since it seems to work and generally improves flight performance, this PR explicitly sets the DLPF to 98Hz, so it leaves the default behavior unchanged.

---

The bmi055 and bmi160 drivers both do not support setting the on-chip filter settings. @FAC94 and @scheiermanns do you plan to add support for that? It's an important feature that these drivers should have.

---

I also tested on my quad setting the DLPF frequency to 188Hz and noticed the following:

• noise levels on the output and accel data is increased
• the quad still flies however
• according to the mpu6000 datasheet, delay is reduced by 0.9ms
• I was able to increase the P gains a bit, which again shows that every millisecond we can take out of the control delay makes a difference.

[mhkabir]

We should be able to use this delay data to improve IMU timestamping. We should subtract this value (based on selected DLPF) from the hrt_absolute_time() we use to timestamp the accel/gyro data.

[bkueng]

I'm fine with that. You'll have to make sure that it works with the estimators.

[LorenzMeier]

Could we also enable the lower delay settings by default?

[scheiermanns]

Hi Lorenz,

IMU's like bmi160, bmi055 supports different bandwidth configurations depends on the application needs. As far I know, all necessary HW configurations are already supported by drivers. What will be your target in terms of group delay/ bandwidth and ODR/read-out rate?

BMI160 offers HW configurations: e.g. f_c~150Hz / 90Hz for ODR=1.6kHz/800Hz + OSR4 accordingly. This configs might be good choice for drone application (no special driver adaptation needed if 2nd order IIR filter enough).

BMI055 include two chip solution, so every component need to configured separately:
bmi055 gyroscope: BW = 112Hz + ODR=1kHz; or BW=47Hz + ODR=400Hz might be a right choice.
bmi055 accelerometer: BW = 125Hz + ODR=250Hz; or BW=500Hz + ODR=1kHz, so in this case SW filter make sense (e.g. reduce accelerometer BW to same as gyroscope ~112Hz/47Hz).

Valid for all sensors: if special SW filters in the driver required, the continuous sampling w/o data loss and read-out with >=1kHz might be needed.

Please let me know if support on configuration of the filters of IMU are required, or even SW filter tuning for BMI's.

Best Regards,
Sergej

P.S. BMI088 will have DLPF in accelerometer chip, in parallel we are working on the API which supports customized SW filters (case which you describe above)

[bkueng]

Hi Sergej

Thanks for your quick response. We currently have ODR=1kHz for most of our IMU drivers, but would like to increase it at some point.
What I would like to have for the BMI drivers at the moment is a functionality to set the HW filter frequency (that might depend on the ODR, which is fine). Something like the MPU6000 driver already has: https://github.com/PX4/Firmware/blob/8fbdc6629f1a4b55c42cb42809108177633ae4c5/src/drivers/imu/mpu6000/mpu6000.cpp#L958:L993.
I see 2 problems at the moment:

• I don't know the current HW filter settings of the BMI drivers just by looking at their source code.
• I cannot change the HW filter frequency easily, as this PR does for the MPU6000 (large drones might have different filter requirements than smaller ones. So even if the filter frequency is hardcoded in the driver via a macro, we will have the ability to test different settings).

[scheiermanns]

Hi Beat,
I will check the drivers and reply how to deal with HW configurations (support of different BW).

Maybe one idea: I was thinking is it not better to have SW filter for all IMU's and let them run at high speed (e.g. 1kHz) --> so you can be almost independent on IMU and you better control of the group delay based more or less on the known group delay of the SW filter. Then you can just change the settings for SW filter and adjust them to frame / drone size used in the projects?

Best Regards,
Sergej

[bkueng]

Maybe one idea: I was thinking is it not better to have SW filter for all IMU's and let them run at high speed (e.g. 1kHz) --> so you can be almost independent on IMU and you better control of the group delay based more or less on the known group delay of the SW filter. Then you can just change the settings for SW filter and adjust them to frame / drone size used in the projects?

You are completely right, and ideally we will disable the on-chip filter completely and only have the SW filter. But to avoid aliasing, we need >1kHz readout rate, which as it seems requires DMA, and that is a bigger effort.