I’m currently working on getting a rather large quadcopter (29in props) to hover stable. In the couple of flights that I have done in stabilize and alt-hold, I notice an oscillation that builds and causes the aircraft to “toilet bowl”. When taking off in alt hold the aircraft immediately over-corrects and begins to almost flip.
I’m a bit scared to run an autotune as I’m not sure how an aircraft of this size will react to large twitches even at the lowest aggression. Could someone advise based upon flight logs a correction to the PIDs that I am currently running, or if there is another noticeable issue?
I’m attaching a log that I believe includes my last three fights, the most recent of which a had to land abruptly because I noticed a significant oscillation and knocked one of my GPSs off in the process.
Any help or information would be appreciated!
Following thread for a future aircraft.
There is only one log there and other than extracting the parameters there isn’t much to go on. Do you have one of the craft hovering in AltHold for ~1 minute or so? It looks like you have done some fiddling with the Rate P&I, perhaps they are too low. Also your MOT_THST_HOVER value has learned a relatively high value so describe this craft in more detail (components, weight, etc). And set these:
And before you run Auto Tune the process for setting the notch filter should be done. And, setting the aggression too low can cause it’s own problems. The goal is the default value.
This quad uses 4 MN801-S KV120 from T-Motor paired with 29in props. This amounts to a maximum thrust of about 46Kgs. This aircraft is designed to carry a significant payload, but at the moment I am attempting to get a stable aircraft without a payload for testing purposes. In its current form, the aircraft weighs just under 10Kgs, without any payload equating to a fairly high thrust to weight.
Each time I have attempted to switch the aircraft from Stabilize to Alt-Hold, It has toilet bowled and I’ve either crashed or had to switch back to stabilize.
Would a longer stabilize log be helpful for solving this issue? I’m not sure that the current setup is capable of getting any extended time in Alt-Hold.
OK, plenty of thrust for 10kg. The learned MOT_THST_HOVER must be related to the AltHold problem.
Yes, try a longer flight in Stabilize. I saw you switched to Land mode. I wouldn’t do that until this problem is solved as it used the AltHold controller. Just land in Stabilize.
I’ve tuned a friend’s 28-incher hexa last month. You can’t fly these monsters without a payload. We used a 10 Kg car tire ziptied to the arms. Made for a nice landing gear, as well, during the tuning. Still, MOT_THST_HOVER at 0.26, which is a little less weight then I would’ve liked. 4x 14Ah in 2S2P, and I advised for 4x 22Ah for some added useful weight.
As Dave says: what ESCs !? On the hexa, I had the DJI E5000 Advanced drivetrain. Their ESCs are fine-tuned for the motor-prop combo. So fine, that spinning them on the bench, without props, at low RPM they seemed and sounded like stepper motors.
I’m currently using the FLAME 60A 12S from T-Motor as well. I’ve never used them before but in all of my motor testing, I seem to get a pretty smooth throttle response from them.
The battery configuration is 2 x 22Ah in 2S1P for a 12S system
Putting a heavy payload on was something that I had considered but was unsure if that would be good for the autotune. What weight would you recommend? For my next flight, I’ll go ahead and add a significant one and try a longer stabilize flight. That may also resolve the AltHold issue as well.
The folklore with Flames says they are prone to desynchs. They’ll recover from desynchs as well, without you noticing, so there’s a loss of thrust that you can’t notice, but the autopilot will, during the process, hence the oscillations. Many expensive T-Motor carbon fiber 24+ inch props have met their early demise due to probably Flame ESCs.
I’ve had my share of success with Alpha HV ESCs, on 12S, with the reprogramming interface, and 24" props. Very well behaved quads.
As for the dummy load… your multicopter will have a payload, once it’s flyable. Use that exact weight, in a compact slab of metal mounted as close to the CG as possible.
I’ve gone ahead and uploaded a video of some of the shorter flights with the aircraft to the shared folder. As you can see when taking off in AltHold the aircraft overcorrects significantly
The dummy payload will be required (as Cornel says) and it must be very secure.
Really go over the initial parameters, and I know there’s a bit of controversy but I’d use these params with the Flame ESCs:
And something like this for those big frames:
ATC_INPUT_TC,0.2 (to as much as 0.3)
Use everything this spreadsheet suggests.
In reality, the PID values are not necessarily different because “it’s a large quad”, but how effectively the autopilot can control those props (Rate PIDs) to make the frame do what is required. So it’s vitally important to have a good combination to start with. The Angle P’s (I and D terms only need to be in Rate) will be a bit different depending on your frame size. Autotune can sort that out, or manual tuning if you need to.
Your existing D terms in that log could go higher to start with:
In that log it seems like you might have prop wash over the barometers, or maybe you just didn’t get enough altitude to get out of ground effect.
As soon as you can get stable enough flight set up the Harmonic Notch filter.
10 years ago, when I first hovered my first multicopter, it was tied to a section of a railroad beam with a 4m rope, so it won’t fly out of control and damage my neighbours houses. Looking at the video, it’s just a very noob pilot driving its first multicopter and knowing not what to expect and how to react, control-wise.
I mean, the recovery from wobbles in stab from a badly-configured craft involves 30-degree banks, that are horryfiying ugly with props striking ground and 180 degree frame flips.
Common denominator. Countless posts about these expensive ESC’s.
Would it be worth trying out the Alpha HV ESCs that Cornel recommended then? If working with the other recommended parameters and payload does not work.
I don’t know. Your quad looks flyable if handed by an experienced pilot.
After adding the recommended payload and making the suggested parameter changes the quad is able to fly very well in AltHold and Loiter. I have gone ahead and uploaded a video of the last flight and the associated Log from that day.
Stable Flight Video and Log
I’m planning on completing an Autotune next flight.
Thank you all for your help and suggestions!
OK, looks a lot better!
Do the harmonic notch filter next, before Autotune.
Once you need to set the HNOTCH param first set INS_HNTCH_ENABLE,1 then refresh params to see the rest.
HNOTCH phase 1
INS_LOG_BAT_MASK,1 IMU 1
INS_LOG_BAT_OPT,0 capture pre-filter gyro data
- hover test in AltHold 1min+, check FFT
HNOTCH phase 2
INS_HNTCH_MODE,1 throttle based
INS_HNTCH_FREQ,peak freq from FFT
INS_HNTCH_BW,peak_freq / 2
INS_LOG_BAT_OPT,2 capture post-filter gyro data
- hover & dynamic test, check FFT results
HNOTCH phase 3
- no extra logging, assumes HNOTCH is working great
Let’s see the .bin log from the phase 1 test flight with those log params set and we can check the FFT to determine what goes into phase 2 params.
I went ahead and completed the steps for the harmonic notch filter and found that the hover frequency to be 107Hz. I then made the appropriate parameter changes and verified that the filter worked properly with an additional flight.
I then move onto the Autotune, where I first did a series of full stick deflections on my transmitter while in althold to verify that the quad was capable of maintaining stability during autotune. This flight is 59.Bin in the folder linked below. Following this test, I then opted to go ahead with the autotune as the craft appeared to be correcting itself normally.
Autotune Crash Folder
Upon initiating Autotune (60.Bin) vibrations spiked and it would appear to me that motor 2 (the nearest right motor in the video) lost sync or power momentarily following the correction. I’m not exactly sure as to the cause of this crash, any insight on this would be much appreciated.
I also suffered a fall in the same shape.
I haven’t found a solution yet.
It was the same even with the Autotune_aggr parameter value set to 0.05.
Did you perform Autotune with Payload loaded on the aircraft?
Really sorry to hear about that, it’s never a good feeling.
I couldn’t see where any one particular motor/ESC was an issue. Really the oscillations got out of control I think, although I cant rule out desyncs as the T-Motor ESCs seem to recover fast, just in time for the next ESC to lose sync
Although if you look very closely, desired pitch and roll don’t change, but actual pitch and roll just start doing their own thing.
I see you put in some HNOTCH params. I’d probably do it a little different:
I can’t see exactly what’s caused this crash but personally I would try these for the next starting point, (plus those HNOTCH values above)
MOT_THST_EXPO,0.2 or up to 0.4 <- if you stick with the Flame ESCs
Some tentative take-offs and checking for oscillations…
This echoes what @dkemxr mentioned earlier: searches for similar situations -> the number of times desyncs, autotune crashes and Flame ESCs are reported in the same sentence is remarkable. People have reported better success with the Alpha ESCs, but I’m not certain I’d trust them now either.
Thanks everyone for your help,
I’m going with the working theory that this is an issue with the historically problematic Flame ESCs. I’m planning on replacing them with the Alpha ESCs to see if that resolves the issue and then retry autotune. Until then, I would like to try a few tentative flights in loiter and eventually Auto with the acceleration and speeds lowered to prevent sudden changes in attitude which could have caused the desynch during autotune.
From a flight in stabilize and Althold the PIDs suggested above appeared to have worked great (Thanks Shawn!) on the rebuilt airframe according to this log:
New Frame First Flight
This reduced aggression in auto for the next flight is only a short term solution so that I can verify some code until the new ESCs arrive.