I conducted a 3-axis auto-tune today - it was a nice calm day, and the auto-tune appeared normal - taking about 12 minutes.
Looking at the log file, I noticed that there were two messages in the MavLink messages during the YAW tuning phase: data_autotune_reached _limit
There are a couple of other message threads here that mention this error - but I didn’t see anything helpful.
I’m not sure if the limit is in software - perhaps an addressing limit - or hardware - perhaps a memory limit.
I’m going to repeat auto-tune to see if it re-occurs. And to see if I can improve the PID’s. From a subsequent test flight, I think the PID’s from this auto-tune are a little too agressive.
Thanks for any comments. And if the DEVs are looking for examples of this - I hope it’s helpful.
That sounds like there bugs or limitations in the auto-tune routines. I’d be interested to know if @rmackay9 has this situation identified.
If it’s a limitation, not a bug, then users would benefit from having that limitation explained in the wiki. If it’s a bug - then as long as the DEV’s know about it, I’m sure it will be addressed at the appropriate time.
As info - I repeated the auto-tune, and it set lower pitch and roll PID’s - which is what I’d hoped for. My test flight after the first auto-tune showed that the PID’s were too aggressive in pitch and roll - especially in the fast segment of landing.
The second auto-tune only generated a single data_autotune_reached_limit message. But the yaw twitches appeared irregular. (not “twitchy” enough)
My test flight after the second auto-tune showed much better PID’s - and greater stability in steady flight. Still room for improvement though.
This incident was from three separate flights. I landed and disarmed after each axis. The DATA_AUTOTUNE_REACHED_LIMIT message still occurred during the yaw axis flight. This was the third flight.
I can’t tell if it effected the YAW tuning solution - the messages log seem to indicate that the autotune for yaw continued - and was saved after landing and disarming.
I think you experienced the latter. With a fresh boot, I expect it will complete (if it did not). If it indeed completed, then I suppose the next step is to fly and assess the new tune.
It would be a benefit to those who get this message when doing an autotune to know for sure. There are plenty of people who do all three axis in one flight.
If there’s some sort of buffer overflow going on - and autotune requires a re-boot - then this should be explained in the wiki.
And if it’s a bug in the autotune routine, then then maybe people like @amilcarlucas and @rmackay9 might like to note it for future releases.
We’ll never get away from total dependency on “tribal knowledge” to use ArduPilot successfully. But the more we get away from it by accurate documentation, the more likely new people will succeed. And that benefits us all.
I believe the harmonic notch filter is configured wrong and this will probably affect Autotune results.
If you want to use per-motor notches INS_HNTCH_OPTS,2 then you need INS_HNTCH_BW,7
otherwise you can keep INS_HNTCH_BW,30 but should set INS_HNTCH_OPTS,0
That message might be a bit misleading - as I look through the source, it looks like the AUTOTUNE_REACHED_LIMIT event is triggered whenever an upper or lower bound for a P or D term is reached. So it is not indicative of an overrun or bug, but rather that the routine has hit a term value that it should not exceed (presumably to keep things from running out of control as the algorithm seeks a good value).
Since the autotune completed successfully, it looks to have backed away from the Yaw P limit and subsequently found a valid value.
I don’t think there need be a wiki edit for this expected behavior, but, as always, if you find it a worthy note, the wiki is user editable.
Thank so much for digging into this Yuri - I really appreciate it.
I do think there should be a note about this in the wiki. As I recall there’s someone who does the updates - and does a good job of checking the facts for suggested changes.
I’ll have to dig around and find out who that is again.
MavExplorer comes with a ground control program called MavProxy. I’ve never used MavProxy - someday I’ll explore it.
But MavExplorer is very useful - it has really good graphs, it has the best compass calibration utility called “MagFit” - and it has the ability to make custom charts.
