Now that I have the number of poles sorted out, I finally performed a test flight with and without the RPM Notch filter enabled.
If I understand the charts properly, the Notch filter is significantly attenuating the gyro vibrations, but not having much effect on the accelerometers.
Also - the passive filters seem to be doing a good job without the notch filter.
It would be helpful if someone could look over my shoulder to see if my understanding of these charts is correct. And if I’m doing something wrong that is keeping the notch filter from attenuating the vibrations on the accelerometers.
Nope, nothing wrong. The notch filters only filter the gyros, not the accelerometers.
No, it will not work better if you somehow change the code to also notch filter the accelerometers. The EKF needs unfiltered Accel data to work properly.
Fascinating - I’m going to have to go back and study the wiki more closely. I’m feeling a bit foolish that I didn’t understand this distinction.
What is the cause of the attenuation depicted in ACC3 display window? Is this just the result of the low-pass filters?
Is there any tuning in this (accelerometer vibration attenuation ) that should be addressed?
Either way - what should be observed in the ACC0 and ACC3 display windows? Is there useful information in these displays that can be used in the tuning process?
Regarding your comment about “changing the code” - I’m not sure what you’re responding to. I haven’t suggested anything about changing the code to affect how notch filters attenuate vibration for the accelerometers. I just want to make sure I’ve set my parameters properly - and understand the results.
Perhaps this has come up from other folks. I hope if they read this thread, they find it helpful.
I thought I mentioned this in one of your other threads - the acc0 and gyr0 are pre-filter and acc3 and gyr3 are post-filter. The HNOTCH only affects GYRO for good reason.
EDIT - granted I didnt mention the bit about HNOTCH only working on GYRO
We should ensure the INS_ACCEL_FILTER value is low enough to filter unwanted noise, but not so low that it interferes with good data. The default used to 20 and lately we’ve all been using 10 on good authority (Leonard Hall) and I’ve not seen any ill-effects with using 10.
Unless I missed it, there’s nothing in the tuning wiki for guidance on “tuning” INS_ACCEL_FILTER.
It’s good to know that the new standard value is better - but it would be even better if we knew if and how it might be adjusted for improvements.
The fact that the accelerometers are shown in the FFT set of four graphs give a novice user the idea that something is going on there that needs to be dealt with. As it is, there not even a mention of what to look for in the accelerometer charts to even check to see if all is OK.
At a minimum - it should be clear that the effectiveness of the INS_ACCEL_FILTER value can be checked on the FFT charts.
It would be even better if it was stated whether or not this effectiveness should be checked - and what to do about it if it’s not right.
For example - could we tell from the charts if there was too much attenuation?
INS_ACCEL_FILTER is generally static and we almost always dont even have to check and change it. It doesnt need any tuning, that’s why it’s really not talked about. The only reason it’s brought up so much lately is because the old value of 20 is being replaced by 10.
I agree there’s times when the accel FFT charts could be confusing, because they exist at all, but in some cases they are a useful tool. I’ve used the accel FFT charts to verify what I’m seeing in the Gyro charts, usually where the gyro is showing lots of spread noise. Yes - the correct solution is to fix whatever is causing the spread of noise - sometimes that is not possible, like with a noisy vibrating ICE generator that you cant just unbolt from the copter and declare the problem solved
You would really only go to higher values if there was particularly low noise, and you are expecting your copter to have real movements that need tracking at a higher rate than 10Hz (extremely unlikely). The original default value of 20 is still OK to use, but our new value of 10 can make tuning easier since it is a better starting point. You wouldnt want to go lower than 10, or you will be at risk of filtering valid data.
If you dont have any special niche problem then the Accel charts can just be ignored and INS_ACCEL_FILTER,10 is appropriate in practically all cases.
Background info:
Trusted sources: Leonard Hall and Andy Piper. These people have implemented or worked with others on these areas of Ardupilot code, and there’s enough instructional videos (Ardupilot Dev conferences, not random youtube junk) and forum posts for us to know that if Leonard says it should be 10, then it should be. We have plenty of evidence that it works, and I’m sure Leonard has tuned more multirotors than most of us have had hot dinners.
