Hello! Curious if anyone else has had problems with larger UAV frames and autotune, and if so, have you found any fixes to prevent crashes?
We’re running into an issue with Autotune on a large quadcopter (16" props).
Autotune worked beautifully and the drone appears to fly perfectly afterwards, with logs showing minimal vibration and almost perfect roll/pitch rate tracking.
It flies perfectly in altitude hold mode and appears to fly well in position hold with autotune
In certain cases the drone goes into unstable oscillations and crashes with the autotune PIDs (e.g. a client immediately gave it full left roll, then full right roll, then no roll and it goes into an increasing oscillation and crashes)
The only solution we’ve found for them is to reduce all gains by about 50% and make the drone substantially less nimble and limiting the maximum rate on pitch and roll axes and various MPC settings to reduce aggressiveness.
We have the UAV back for repairs and it flies much worse than it did with autotune settings, so trying to find a crash-proof middle ground before we send it back.
I’ve had limited luck with autotune on big frames. In tuning 900mm class (22” prop X-frames) I’ve found success in taking default PIDs for frame class, going straight to MC_PITCH_P (and ROLL_P) and halving the P gain value. That removes the bad behavior for me and acts as a starting point to tighten back up from there. I generally end up around .6x initial default P gain value in the Attitude Controller tab and up a few ticks on master multiplier in Rate Controller tab.
Every build is different on filtering and vibes so it’s not a fire and forget tune. I’m not a pro by any means but I’ve generally found that the P gain needs to come way down on the big boys.
Yeah, that’s what we’ve found too. Generally much lower P values help a lot. It’s too bad that autotune doesn’t have any settings or adjustment for prop size, as it works great on smaller builds but fails once you seem to get to 12" or larger.
Any improvements would be appreciated! The issue seems to be that there is a lot more inertia with large props, which the system sees as unresponsive and tries to fix with very large P gains. Then during flight, those large P gains cause overshoots when large movement is demanded, leading to crashes from increasing oscillations.
I had a chat to @bresch - he says there is a parameter to change the desired rise time of the step response, which should be lowered on large vehicles. I suspect that would be MC_AT_RISE_TIME. Hopefully he’ll get back here and confirm.
Thank you for checking again on this! That would definitely be very helpful to confirm any parameters to adjust!
It would make sense that parameter could need adjusted, with the large props there is a great deal more time required to see the corresponding step change.
@hamishwillee Yes, that’s the correct parameter. Increasing it could be a good idea for larger vehicles, but it’s a bit of a guess work to find the “good” desired rise time. It is related to the vehicle size but not only; it also depends on the response of the rotors.
@Raptor272 Maybe one thing to check first is why the drone was oscillating. Was the rate loop overshooting?
Was is just out of phase?
Were the motors saturated?
Is it maybe just because the attitude gain is too high (how large is that value?)?
Before attempting another tuning, could you share the log or at least plots showing the oscillation that occurred before the crash?
@bresch I think in this case the P values were just too high. Here’s a log below of the crash right after the autotune. It just way overshoots the target pitch / roll.
After reducing the gains by 30% it crashed again, you can see in the graph below from that crash that the roll axis just kept climbing above target because the gains were still too high.
We ended up bringing the P values in particular down about 50% before it seemed to be more stable and less crash-prone, but we’d prefer to figure out the MC_AT_RISE_TIME parameter to generate a good autotune.
The drone flew really well after the autotune, but large inputs just overwhelms it and puts it into an oscillation that eventually causes crashing. We only solved it by limited the angular change.
Here’s another log after we had them reduce their gains quite a bit that shows the oscillation better.
