I was hoping I could get the community to critique the methodic configuration that I am working on for my Hexacopter and give me some mentoring on where I can improve. I’m loving that this methodology is forcing me into reading much material from the ArduPilot wiki as well as documenting my copter. But at the same time, I find myself second guessing many of my choices. I really want to understand every choice I make and why, and am finding gaps in my own understanding/knowledge that I hope the community can help with. I am trying not to rush things as I work through the whole methodic config around the latest 4.6 dev firmware (I realize its not production yet) and trying to not move on to the next step until I truly understand each param being set.
I’m using a Cube Orange Plus. As far as I know, there is no temperature calibration that it can do. So I really didnt do anything on 02_imu_temperature_calibration_setup.param and 03_imu_temperature_calibration_results.param. I did not have any INS_TCALn_ENABLE params available to me. This page says its only available on 2MB autopilots, and so I believe this cant be done on the Cube Orange Plus. Am I interpreting this correctly or do I have a glaring oversight where I missed something?
Do you see any issues standing out in my hardware report that I should correct immediately?
Do you see anything I should clean up or dive deeper into in files 02 through 18?
In my first flight of a simple hover for 50 seconds as described in this section, I did it in LOITER mode, even though the docs say ALTHOLD. Is this OK or will it throw off the notch filter tuning?
Vibrations from that first flight seem OK. Under 10 for X and Y, but the Z’s are going a bit over 10 at times. Is that something to worry about still? Anything to improve vibration wise from your perspective before moving on?
For the notch filter tuning setup 18_notch_filter_setup.param, I did the first flight with INS_HNTCH_HMNCS set to 1. The default is 3. I’m really struggling to understand what I should be using here for this first tuning. Does it matter for that first test flight prior to tuning the notch filters? Do you see anything else I should change and then redo the first flight?
Just an FYI, I had an issue using the filter review tool on the log that was produced today which was based off of firmware 4.6-dev. I am unable to proceed to step 19, and so I’ll just wait it out until the team has a chance to finish 4.6. I realize I’m using unstable firmware here. When loading the .bin file into the filter review tool it throws an error. I went ahead and logged a github issue for it: Issue Loading Log into Filter Review Tool from 4.6 Dev Build · Issue #199 · ArduPilot/WebTools · GitHub
I really appreciate any time and help you are able to provide. Thank you!
Is there a reason that you’re using 4.6-dev firmware? Unless there’s a brand new feature that you absolutely need, there should be no reason to use a nightly build.
This is a screenshot of the parameters from your log. They do exist. Maybe you are misspelling them in the search bar?
The log is otherwise so brief that it’s hard to do any real analysis, and the logging rate looks odd.
You have some odd logging options set.
Here is the typical logging setup for filter review from the configurator templates. I think, though, that we can actually zero out the INS_LOG_BAT* parameters and just use the online tool’s raw data analysis to keep the file size down and remove some CPU overhead.
INS_LOG_BAT_MASK,7
INS_LOG_BAT_OPT,4 # Logs measured data both before and after the filters for Filter Review Webtool usage
INS_RAW_LOG_OPT,9 # To get more Notch filter data
LOG_BITMASK,2242524 # Logs Notch filter data and other control signals
LOG_FILE_DSRMROT,1 # One .bin log file per flight, not per battery/reboot
Any chance you can validate my understanding of if I am doing this notch filter configuration correctly? What I am not understanding is how to know when I have reached optimal settings from the Filter Review Tool and if there is a more scientific way of determining what the proper settings should be. I’ve basically just been messing with settings until I find a combination that leads to the biggest drop in dB. I’ve pasted a screenshot below of what I believe is my most optimal parameter settings so far by looking at the estimated post filter vs the post filter. What Ive gotten there so far has been done by pure trial and error.
I can have a max of 54 notches before the auto pilot errors out on reboot. I have a hexacopter and am using ESC telemetry (cube orange plus and hobbywing x6 motors). I can get the dB to drop the most when I enable more in INS_HNTCH_HMNCS. However, I have to uncheck EnableOnAllIMUs in INS_HNTCH_OPTS.
Here’s the main area I dont fully understand: How do you determine the right value to use for INS_HNTCH_FREQ? And tradeoff wise, is it better to have more harmonics and disable the notch filter on all IMUs? Or should I have all EnableOnAllIMUs selected and have less harmonics selected? Will these settings have a dramatic impact on CPU as well that I will regret? Alterntively, am I just completely off track here and not understanding the optimization goal here? I’m thinking I need to balance this all with CPU load somehow as well.
I’m thinking of starting with INS_HNTCH_HMNCS=15 (first 4 harmonics), and not checking EnableOnAllIMUs to see what kind of CPU load this causes.
I’ve read the blog post by Peter Hall several times, watched the associated Youtube, and have been reading several other wiki articles. I’m just not finding anything that says objectively “here’s how you know when you’ve taken this step as far as it can go for the most optimal setup”.
Also here’s a slightly different view. If I switch the amplitude scale to Linear now I can more easily see to minimize it to 0.
Maybe this is my best setup, minimizing to 0 for as much of the X axis as possible with the least harmonics selected. I’m still not sure if I should check EnableOfAllIMUs or not, is it worth the additional computational overhead?
Should look at /analysis the pre-filter data.
More challenging if you face multiple peaks.
if the autopilot is capable of running the FFT (most F4 based autopilots are NOT), then by enabling the FFT_ENABLE and using the RC Auxiliary function “162” (Auto Throttle Notch Setup) during a sustained hover, the center frequency, INS_HNTCH_FREQ, INS_HNTCH_ENABLE, and INS_HNTCH_MODE will automatically be setup for the first notch, avoiding log analysis to determine center frequency as outline below:
For an ESC telemetry based notch, hover freq / 2 is usually adequate to set the lower bound (base frequency).
Then use the filter tool as above with as light a touch as possible, enabling as few harmonics with the lowest bandwidth and attenuation as reasonably flattens the noise peaks.
Real time calculated FFT filtering is unnecessary in most cases, especially when ESC telemetry is available, and the harmonics occur in regular/expected intervals with respect to the hover frequency.
Enabling on the primary IMU is probably all that’s needed, but I don’t think you’ll do much harm enabling on all IMUs.
Nice to see that you are using git to track changes to the files and that you are methodical in your operations. That said there is still room for improvement, see below.
There are reasons why you should use AltHold and not Loiter. Do not be creative, follow the instructions to get good results. Being “creative” leads to sub-optimal results. The instructions have their reasons. Most are not described because that would make the document even longer!
No, that is fine. The document also explains that that is fine.
AFAIK the methodic way is to use 1. And you did that, so that is correct. Yes it does matter and 1 is correct.
After the first flight you can change that, but only you you see harmonics.
And do update to the latest version, or at least to 0.9.7
Thank you @amilcarlucas! Your tool is really helping me to learn in a structured approach and order to things. Really appreciate that you made it available to the community and took the time to write that great blog post.
Also of note when you’re configuring ESC telemetry following notches:
INS_HNTCH_FREQ simply should be lower than the lowest expected flyable RPM-based frequency. Leaving it as its default of 40 keeps it high enough to avoid most controllability impacts. Hover freq / 2 is also a rule of thumb but isn’t very critical (and could potentially be imperfect advice on larger propped copters).
INS_HNTCH_BW is typically set to half of INS_HNTCH_FREQ, but you can adjust it to provide a little more or less notch width. It ends up as a ratio of sorts with respect to the followed frequency.
Leave INS_HNTCH_REF = 1 for an ESC telemetry based filter.
Experiment with enabling a triple notch vs multiple harmonics. The triple notch option will effectively broaden each notch (though not a technically correct description) and has a somewhat significant CPU cost, though an H7 shouldn’t struggle too hard unless you enable a bunch of harmonics and/or a second notch filter (which is usually not required on a well behaved quad).
Enabling on all IMUs will help with EKF lane switching (redundancy). If you have multiple IMUs enabled, it’s probably worth enabling this option. Further log review can help determine CPU impact.
Again, use the least amount of filter options as reasonably flattens the post filter noise curve. Don’t chase tiny spikes, especially those that change between logs.
@andyp1per may have a few more expert opinions on the subject, and I’d welcome his input regarding the above general advice.
