This isn’t about tuning at this stage. We are trying to understand why this is happening. If we can’t stop this by reducing the filters this low then it points to a problem that is not filtering or tuning dependent. (I have concerns about this but we need to make sure it isn’t something simple first)
As for the betaflight filter implementation. There has been a lot of cross pollination between all the open source code bases. But because ArduPilot is a fully stabilised control system rather than a rate only control system our response requirements are slightly different. Further ArduPilot is used to fly aircraft that are worth more than luxury cars so we have to do a lot of analysis to ensure what we are doing makes sense with minimal unnecessary complexity.
Betaflight uses the pilot to do angle stabilisation so they can tolerate (even enjoy) a less linear rate response without issue. Oh, they can crash. (I remember when were allowed to crash, it was nice)
There are gains to be had from dynamic low pass filters on aircraft with very high power to weight ratio. You get enough knobs that you can change, to get good to excellent results. And everybody is flying very similar aircraft so being able to copy and paste other peoples settings works well.
However, generally the control loops are unnecessarily complex and they don’t come with a methodical engineering tuning method needed to fly such a wide range of aircraft. My personal tuning experience ranges from 150 grams to 500 kilograms. Or aircraft, multi, heli, coax copters, even submarines use the same PID loops as multi. So we just don’t have the freedom to play with ideas in the release, all the work needs to be done up front and proven to not only do what we say but improve on what we have.
Finally I will leave you with where we really pull up short on small fpv style aircraft, compared to BetaFlight. It isn’t filtering or our pid loop design (both have been demonstrated to be able to compare directly with betaflight on performance). It is our inability to run our loops at over 1 kHz (reliably anyway), and our requirement for better AHRS performance to support navigation (ie we are more sensitive to noise, vibration, and calibration).
The 4.0 release had the required components in the RATE loops to support enable them to run at a faster rate than the rest of the code and Andy is doing a great job adding support for the ESC interfaces that BetaFlight has driven forward. But ArduCopter will necessarily move forward slowly, but only ever forward…