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.
Hi all,
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.
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_ENABLE,1
INS_HNTCH_MODE,1 throttle based
INS_HNTCH_REF,hover_thrust
INS_HNTCH_FREQ,peak freq from FFT
INS_HNTCH_BW,peak_freq / 2
INS_HNTCH_ATT,40
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,2 capture post-filter gyro data
- hover & dynamic test, check FFT results
HNOTCH phase 3
INS_LOG_BAT_MASK,0
INS_LOG_BAT_OPT,0
- 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.
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:
INS_HNTCH_FREQ,71
INS_HNTCH_BW,35
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
ATC_RAT_RLL_P,0.12
ATC_RAT_RLL_I,0.12
ATC_RAT_RLL_D,0.006
ATC_RAT_PIT_P,0.12
ATC_RAT_PIT_I,0.12
ATC_RAT_PIT_D,0.006
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:
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.
You’ll also need the Alpha ESC reprogramming interface.
Yup, thanks for the reminder.
Update after flights today:
Drone felt unstable in althold so I neglected to advance to Loiter or attempt an Auto mission.
It appears to me that this might be a PID issue? Ive gone ahead and uploaded the two relevant logs
Im not sure why the flights from 2 posts ago felt so much better than the ones today as I haven’t changed the PIDs.
Any input appreciated.
Flight looks to be bit smoother, the oscillation frequency seems to be approximately halved
compared to earlier:
INS_HNTCH_ATT needs to be 40
and keep these during testing:
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,2
I think you’d be able to sneak the ANG P values up a bit and see if that unsteadiness smooths out even further:
ATC_ANG_PIT_P,5.0
ATC_ANG_RLL_P,5.0
or even 5.5 if it works.
And if you get the chance, test with an even lower MOT_THST_EXPO, but maybe better to leave it and wait for the new ESCs.
EDIT: looking at new logs now
1 Like
There’s still a physical yaw imbalance, but it was there in previous flights too. Motors 1 and 2 (CCW) working hard to counteract the CW motors. Arm or motor-mount twisted.
I cant see why it was any different to previous flights though
I’ve seen the Yaw imbalance before, I will do my best to triple check level on props/motors before the next flight. I have also uploaded a video of the flights today that shows some of the oscillations and Yaw issues.
I’ll try and mitigate the yaw issue and make the Parameter changes above.
Thanks
During an Althold flight yesterday the same ESC desynch issue happened again where it appears a motor just stopped. I am now stopping all flights until the new Alpha ESCs arrive and hopefully fix this issue. Below is a link to the video and log of yesterday’s crash.
Before the crash, I had done a couple of flights in Althold and the craft seemed fairly stable. Then out of nowhere just lost a motor. Disappointing but hopefully the new ESCs sort this issue out.
1 Like
Hello. I’ve been dealing with the same problem for a while.
but frame is Quadplane. quad starts yaw movement after taking off. C7 ,C8 motors pwm is max.
motor: MN805S
ESC: FLAME 80A v2.0
battery: 12S LIPO
frame does not bend.
interestingly this problem always occurs from the moment it reaches 50 - 55 amps current value
here you can see 3 takeoff trying. (no yaw command from futaba)
did you solved your issue ?
Check your arms/motor mounts for not all being on the same plane, any twist will cause that yaw issue.
Since previous posts in this thread I’ve heard many more stories of issues with both Alpha and Flame ESCs and there’s evidence to backup the stories.
1 Like
thank you @xfacta
related topic (as you mentioned).
I have 2 frame (VTOL). this problem doesnt occur on old frame. So i mean frame twist problem need to be on old frames too. all vtol motors alignments are straight , measure with spirit level , but i will check again . changed ESC’s with news and I will change all ESC’s signal cables and power cables for double checking on new trouble frame.
Could it be another problem or how can I detect if it’s an ESC issue.
Solved:
solution
change frame type X to H on pixhawk.
Hello All, I am building a quad with DJI E5000 powertrain (28-inch props) and want to confirm what value of MOT_THST_EXPO shall be used for this powertrain.
@xfacta the Initial parameter excel suggests 0.79 for 28" prop and also 0.2 for T-Motor Flame ESC. I am not sure if the DJI E5000 have a flame ESC or not, so what value should i use?
@ThePara Could you please confirm the MOT_THST_EXPO you used for this Hexa?
Thanks in advance 