I put my new high thrust-weight ratio quad through autotune today. (15" props - 2000g flying weight)
I was pleased with the autotune flight as it happened - less than 4 minutes for each axis - less than 50% of battery capacity for all three axis - even landing after each one.
I then did a 5 minute test flight after autotune to test the tune - and it was clear that something wasn’t quite right.
Looking at the attitude control in MavExplorer for the test flight - it appears that roll is not tuned properly.
Prior to doing the autotune I followed the ArduPilot Initial Tuning Setup in the wiki - to the letter.
I made these adjustments from the firmware defaults on my initial test flights - reduced the PIDs by 50% because of oscillations (per the wiki instructions) and then changed to an only 40% reduction because the copter was a little sluggish at the 50% reduction.
The copter behaved well in my pre-autotune test flights after these adjustments.
After the post-autotune test flight, I compared the PIDs with each other - expecting pitch and roll PIDs to be similar - and compared them with the firmware defaults:
Thank you for finding my numbskull mistake of having psc_accz_i and psc_accz_p reversed. Once again, I owe you a case of your favorite adult beverage.
I fixed my mistaken swapped values, and took “option 2” where I put the PIDs from pitch into roll and repeated a flight test. The copter oscillated severely in yaw - so per the wiwi tuning instructions, I reduced all the PID’s by 50%.
This resulted in nice stable flight - so I headed out to the large field where I do auto tune flights.
This time the auto tune concluded normally - with considerably different values than before - perhaps due to the mistake I’d made with psc_accz_i and psc_accz_p being swapped.
I then conducted an 8 minute test flight in LOITER. The copter performed well - and from the ridged mounted camera on the copter there were no apparent oscillations.
Looking at the MavExplorer Attitude chart, it does seem like PIDs could be improved to be a bit smoother in following the desired pitch and roll. On this chart I’m transitioning forward at 2.5 meters per second at 60 meters altitude.
I was particularly interested in performance during the fast-segment of landing from 60m altitude. While there were few visible oscillations, the MavExplorer Attitude chart does show some room for improvement:
The log for the 8 minute test flight after the auto tune flight:
Dave - you’ve gone far and above the call of duty on helping me with this tune - I can’t tell you how much I appreciate your efforts on my behalf. Thank you.
This is looking good Joseph! The Auto Tuned PID values are in a range one might expect now. There does appear to be a small amount of jitter that you could try to tune out manually. But there isn’t much Pitch/Roll action in the log so I think some more aggressive flying is warranted and then review that. If you did want to try to reduce it now perhaps start with putting Rate Roll/Pitch kD on a Chan 6 in-flight tuning pot with a range of .0015 to the the current .0032 and see how lower values do. You can do the entire range in one flight.
I’m not sure the FFT based Notch is doing a great job for you. It would be interesting to try a Throttle based notch.
Thank you Dave, for your encouraging words. And I think you’re right - this is the fun part.
I really shot myself in the foot by not being more methodical on this tune - and as a result wasted lots of time - both yours and mine. I apologize.
I don’t know how much the FFT notch filter is falling short. But I’ll take your word for it that it could be better. If there are any parameters I’ve got set that you think I ought to consider changing, I’d appreciate your advice.
I think I’ll wait until the next revision of FFT that’s coming out in the next couple of revisions before considering RPM telemetry. Not that I don’t think it’s important - but only that I have to prioritize where I work on things. And I’d really like to save the added complexity if I can.
I’m using a HereLink - so I don’t have a tuning pot to do manual tuning. I suppose I could do it on Mission Planner on my laptop via it’s telemetry connection with the HereLink ground unit - using one of the Mission Planner config/tuning screens. But frankly - since I can’t see oscillations in flight with a tune as good as I already have - I’m at a loss to see the benefit. I could use the tuning display graphs on Mission Planner - but that really requires an assistant - someone to fly and someone to operate Mission Planner.
With so much data available in the BIN file, I have to believe that it should be possible to determine tuning parameter changes that would improve the tune just from the charted performance graphs. The wiki has such cryptic explanation of the parameters - I’m guessing few but the DEVs that were in on ArduPilot from the beginning really know what they all do. A super detailed explanation may be too much to ask - but a little more help would surely go a long way.
Lastly - I’d be interested to know what your experience says about the ATC_ACCEL_(R,P,Y)_MAX parameters.
I seem to recall in past experiments that when these values were higher or lower (can’t remember which) that the “jitter” was smoothed out.
As this copter has a very high thrust/weight ratio - I’m guessing that it may be sensitive to these parameters - and autotune may be unable to get it exactly right.
Andy Piper in his presentation about using a Chimera7 to film desert truck races mentions that repeating auto-tune has a benefit of getting better tunes each time you repeat the process. I may try that for now while I tend to my other projects. I’ll report back if I find anything significant.
Maybe only the FFT_WINDOW_SIZE for better frequency resolution. Increase it to 128 for an H7 processor is no problem.
These are 2 different things. RPM telemetry does not use in-flight FFT and it’s this In-Flight FFT that is getting improvements in 4.4. RPM Telemetry works great now. It’s actually much less complex than in-flight FFT. With Bdshot you don’t have to connect any additional signals. But totally your choice, it’s looking pretty good now.
These are angular acceleration limits and are set based on how quickly the craft can actually respond. Jitter is usually a function of the Rate PID terms. My suggestion of using in-flight tuning was addressing the Rate D-term which you could just manually lower and see if it helps. With in-flight tuning you can test a wide range of parameters values in one flight, it’s very efficient. I almost always Tune manually and use this tool extensively. It can be time consuming but it’s a part of the hobby I enjoy!
FFT is still using 100Hz
FFT_FREQ_HOVER,100.094
but the logging puts it at 50Hz
So you’d be better off setting:
FFT_ENABLE,0
INS_HNTCH_MODE,1
INS_HNTCH_FREQ,50
INS_HNTCH_BW,25
INS_HNTCH_FM_RAT,0.7
INS_HNTCH_OPTS,0
INS_HNTCH_REF,0.08
For the jitter, I would try setting the calculated ACCEL values (not necessarily because they are calculated, but because they are conveniently close enough) which are a bit lower than your autotuned values and should smooth out those jitters.
ATC_ACCEL_P_MAX,78000
ATC_ACCEL_R_MAX,78000
ATC_ACCEL_Y_MAX,22500
You could play around with the yaw value if required, the autotuned value is usually quite low.
The hover thrust value is quite low, and resulting params that rely on it. You might want to add some dummy payload, just to ensure this beast will descend when required.
Check how low you can go with MOT_SPIN_ARM, and set MOT_SPIN_MIN around 0.12 , just slightly lower than now but still a tiny bit lower than what motors are sometimes going to in that test flight.
I think it might be worthwhile if I put up a new thread just about this particular FFT situation.
I’m thinking if they are working on enhancing FFT for a couple revisions down the line - maybe there’s something here in my results that might be worth looking at.
