Yeah that’s becoming more clear the more flights we make/learn about contextual parameters.
We’ve just done basic PID tunes first looking at the aircraft visually and then the desired angle/actual angle logs and graphs. I tried to replicate autotune movements by jamming the sticks in pitch/roll and we felt comfortable moving forward once we saw the aircraft was taking & responding to the inputs very happily.
I think the problem might have been the PWMs. Our ESCs ranges are at 1250-1800us, we’re going to retune and try to autotune again once we feel comfortable. For example, I’ve attached a picture of the first twitch from the last accident after the Accel changes. The plane jumps from 1600 to 1200, inadvertently turning the motors off.
We were using QStabilize to tune the vehicle, we never tried to see if QHover was flying well before trying autotune.
Okay thank you for the clarification here. After we have that value learned and saved, should we turn off hover learn, or let it continue to rewrite itself?
I agree that the tune is likely unstable at this point, when we fly it around the field it seems to handle maneuvers fine (max pitch and roll), but I guess that doesn’t mean that its tuned to the point it can enter auotune yet. We are still seeing a lot of overshooting in the response , from what youre saying since were having overshoot problems the autotune will terminate after the initial twitching test.
Specifically the manually tuning of roll and pitch section. We may need to dial in P more for pitch and roll. Should we follow this section exactly, specifically setting the I term equal to the P term each time, and doing the D terms before the P terms?
Here is a log for a flight done today after addressing the motor parameter issues, as @ohitstarik says above he was jamming the sticks to test roll and pitch.
Just to be clear. That page is a step by step guide to doing a tune. I do not skip a single step when I do an industrial tune. I wrote it with the goal of giving the community something they could print out and literally cross of each line one at a time until they get to the end.
No, Autotune immediately terminates the test if it exceeds 20 degrees but it assumes this was a disturbance of some sort and continues to repeat the test after the aircraft is stabilised.
This is absolutely critical to achieve a reliable tune. The more D you have the more P you can have. So by setting P first you end up with a much lower P term because the D term is lower when you tuned P. After a good tune you can’t reduce the D term without reducing P and I by the same percentage because reducing only D will probably cause a P term oscillation.
Hi @Leonardthall ended up with a successful day and got AUTOTUNE to work with pitch and roll successfully.
We ended up using an aggressiveness of 0.05 and was wondering if increasing the aggressiveness tends to provide significant stability improvements, or if 0.05 is suitable for larger frames.
Also would increasing the minimum autotune D value decrease the time spent in autotune mode?
Thanks to you and Leonard for all the info in this post. Most helpful. I’ve had some issues using Autotune with my Skywalker and found this info most interesting.
In general you should always start with AUTOTUNE_AGGR set to 0.1. This is a conservative value and there is no reason to go lower here. This value defines the overshoot plus noise. In a perfectly clean aircraft the ideal value for disturbance rejection is 0.1 but 0.05 is ever so slightly faster. So when you factor in a little noise you get a nice safe range. The risk to going lower is any noise on your system can quickly cause autotune to fail so 0.1 or 0.15 for a noisy aircraft are good. (fix noise if you have it use 0.1).
We have a large VTOL aircraft that can only hover for 4 minutes, while attempting to autotune roll axis it took too long and we had to land before it was complete. Landed in Autotune mode and disarmed but the tune seems to have not saved. Is there a way to complete it faster or land and continue after a battery swap?
Tried Qautotune in pitch to see what sort of improvement could be made to the aircraft but kept getting the ‘failed to level’ message. Could having a q_trim_pitch offset be an issue?
Okay I’ll have to give it more attention - thanks for the quick reply. I just assumed it was able to handle autotune because I was pretty happy with the responsiveness after setting the params outlined in Tuning Process Instructions — Plane documentation.
What is the tolerance on that levelling requirement out of curiosity?
Also while letting the autotune run, it was moving around a bunch ~10 m radius circle (no wind, engaged from QLoiter). Do you think that is related, expected, or a separate issue?
Okay worth trying thanks - It does hold position really well generally in Qloiter but it will be easy enough to give it another shot from Qhover. I know for certain the Yaw tune is poor (still transitions fine) but does that need to be good for Qautotune in Pitch to succeed?
I am trying to qautotune a tailsitter and after about 6 minutes or so, it stops twitching. When I land without changing mode, and then disarming, I do not see any of the PIDs changed. I am basically saving the parameters to a file and looking for changes. Is there an indication that qautotune finished or has not (something in the log/visual on mission planner)?
I’ve been trying for a few days without any success.
