When doing the Roll Rate D/P gain autotune step on my 700, I note the final ATNH.Gain is very much higher than the AUTOTUNE_GN_MAX even with P==0 (therefore the tuning finishes as soon as it gets to setting the P gain).
The tuning/sweeps were a bit scary due to the magnitude of the oscillations, but it’s my first copter autotune so I’m not sure if bits are supposed to fall off the helicopter or not.
Is a very high ATNH.Gain like this an indicator that the FF may be set to high? Or else do you have a suggestion on how to bring it back to a more reasonable number <2?
FWIW I just did the roll FF autotune again and it settled on a very similar number to the previous run 0.210 vs 0.215.
I was wondering about the FF only because I’m not sure what else could be a factor in this. But during the “Autotune Pilot Testing” after this last FF run, it certainly doesn’t look like it’s overshooting. Below. There was a bit of wind also acting on the copter.
Hi David, glad to see you are using autotune. Please post all of your autotune logs to a google drive or similar and share the link here. I would like to review them to determine why your roll response gain is so high. Had you tuned the pitch rate P and rate D gains before moving to the roll axis. I am wondering if they are affecting the roll response.
Edit
Sorry there aren’t more protections for something like this. This is very unusual. So did things actually fall off you heli or is this a turn of phrase.
Hi Bill - many thanks for engaging. And sorry, yes bits falling off was just a turn of phrase although it was more exciting than I had expected (and the vibration levels went from ~15 to ~45 but I haven’t found anything that’s physically broken).
Indeed there was a lot of pitch motion during the roll rate stage (the one that showed the unusually high response gains). And yes I had tuned the pitch rates in the flight prior to this flight for the roll rates.
@Brodo i reviewed the logs and it looks like it did a good job at finding the FF gain for pitch and the roll FF gain is a little high. The way I tell is using the very first cycles of the rate P and D tuning for the second frequency sweep. You will see that the response is slightly higher than the request. I would recommend setting the roll FF to 0.9 of the value you currently have which I believe is 0.215 (sorry not at my computer). So the new value would be 0.1935.
So the pitch rate p and d tuning was interesting in that it was not as lightly damped as I am used to seeing. I recommend in the tuning wiki to use 1.8 as the response gain parameter, but in your case you could use something lower. I am thinking you should use 1.4. Since the pitch and roll responses are coupled, this should help reduce the response gain for the roll axis. You don’t need to fly this again, you can look back at the log and view the ATNH message in the table. Pick the rate P gain that produced 1.4 or less of response gain. You can even interpolate if you like.
As for the roll rate p and d, I noticed that you left the roll rate D gain at 0.001. I saw this in both the pitch and roll axes. What page in mission planner did you use to set your gains? I think one of the pages will not let you set a value outside what it thinks is the acceptable range. Thus you get settings you don’t want. Therefore I highly recommend that you make any tuning gain changes through the full parameter tree page. Although it will warn you of a setting that is outside of the “acceptable” range, it will not force it upon you. In looking at your log for the roll rate p and d, I saw that the max acceptable value for rate D is 0.002. So the value that was set (0.001) is pretty high and could be what was driving the high response gains.
Anyway before flying the rate p and d tuning for the roll axis be sure to set both roll rate p and d gains to zero. Set the max response gain parameter to 1.8 for this tuning. Try this tuning flight again. If this high response gain is still present then we may have to use filtering to suppress those frequencies in order to tune the roll axis.
I zeroed ATC_RAT_RLL_D and ATC_RAT_RLL_P, and reduced the ATC_RAT_RLL_FF and selected a ATC_RAT_PIT_P from the pitch rate logs that had a gain of 1.4. I was reattemping the roll rate autotune.
It got through the sweeps okay but during one of the dwells something went awry (lots of messages start about EKF errors etc. at ~12:56:25) and it started gaining altitude. I think I brought it back but then on the next dwell it took off to the south-west. It was still kind-of responding to controls and I managed to reverse the direction of travel but then it started a rapid uncontrolled descent.
I noticed all of the control linkages were still connected in a quick post-mortem, but I’m not yet sure if the root cause was software related or perhaps a connector came loose. Perhaps it was excess vibration related.
I managed to get a video of the dwell when it first went awry and started climbing:
Anyway, it’s not the first time something has fallen out of the sky for me and won’t be the last. Nobody is injured and all is well (except the helicopter). I’ll have a closer dig through the log shortly and report back if I find anything interesting.
@Brodo David,
I have looked over this log and had gone back and looked at the previous logs too. After the aircraft started having problems in this last log, you switched to loiter and then to RTL. Please be aware that Loiter is not a very good mode to be using before the Attitude controller has been properly tuned. And RTL or any Auto mode are also unreliable without first properly tuning the Attitude controller. Especially if you are seeing the aircraft acting unexpectedly. It is highly recommended in any future tuning that you use Alt Hold going into and recovering from autotune. And be prepared to got to Stabilize mode as a last resort, if you start seeing problems.
This plot shows the rate P and Rate D contributions for the pitch axis tuning. I didn’t notice this last week. Typically it isn’t good to have the rate d contribution be equal to the rate P. The D contribution is higher frequency and can over actuate the servos. You generally want this 25-50% of the P contribution.
It is interesting to note that after your pitch tuning, the vibrations remain high and you start seeing a lot of clipping which is not good news for the EKF
In the roll tune conducted before the one that resulted in a crash, a similar behavior is seen where the VIBE.Y gets very high and remains that way even after the autotune is off and gains are returned back to original values. And again a lot of clipping is seen at the end.
This is from the last log. It appears the EKF had very high errors. in fact, looking at the innovations for the compass, I tend to think that maybe the GPS puck may have come loose. Was the GPS puck still affixed to its mount when you retrieved the aircraft? If it was, then you may want to verify that the compass is still working properly.
How was your controller mounted? What did you use to mount it. Double sided foam tape? How thick? Just trying to understand why your roll oscillations resulted in such high response gains.
Apologies for my delay in responding (I had a trip away) and many thanks for your insights.
The POSHOLD was a desperate attempt to close a position loop as the heli was flying away at this point and I wasn’t getting much of a response to manual controls! I did have it in POSHOLD in calm conditions while I was turning the ground-camera on. But otherwise agreed and noted. I was building up towards an AUTO mission but hadn’t attempted one yet for the reasons you describe.
For the high pitch rate D contribution > the P contribution, I had gone back through the log and manually reduced/picked the rate P gain that produced ~1.4 of response gain, but not altered the D gain. I guess I should reduce this as well.
Yep I’m not sure what the go is with the Y vibrations getting high and staying high after the sweeps/dwells. The Y vibration was <15 for the FF flights. I’ve just checked and see that Y is the left/right axis.
The GPS and flight controller are mounted on the front tail boom in the little black boxes in the video. Perhaps having them away from the CG might be one of the issues with my autotune, given the magnitude of the (pitch component of the) velocities/accelerations is therefore greater… ? I did have the INS_POS parameters set accordingly FWIW.
My best guess is that the entire tail boom rotated a little during this last flight, and that’s why the EKF went haywire, since the compass and IMUs also all would have rotated. It was certainly slightly rotated when I recovered it, although the whole thing had had a big whack by then as the boom was also bent.
I’m slowly gathering up the parts to get it flying again.
