T-Motor MN2806 KV650 with Arducopter 4.2.x

Already done that. Video proven hover still like a rock without position hold and pilot input

That’s the reason I am here hoping to hear something I am not very sure off after 4.0.7. I don’t face such an issue before in 4.0.x… even though you disagree to try 4.0.7

I suggest reset all to default and start over.
There should be no reason why this cant work with the current firmware version.

I can do that but even though the first post indicate August, in between I was preempted to do other supports and projects, the number of changes I think is about 20 times. This is mini project for the team where we do not foresee any hiccup because it is a repeating steps on latest firmware that is all.

I anticipate the autotune unable to complete will be the same result.

Do the reset and reconfig as suggest, then hover test, send that log file and we will go from there. Limit the amount of changes made to params, leave out anything “just because we always set that one” and just do the mandatory and intial params.
I understand your frustration completely.
I havent had the same issues as you with the newer firmware version, so going back to older versions is probably just masking a problem.

1 Like

done, and a very bad flying experience with 0.66 thrust expo.

OK, set these:
INS_HNTCH_ENABLE,1 ← set this then refresh params to see the rest
INS_HNTCH_MODE,1
INS_HNTCH_REF,0.2
INS_HNTCH_FREQ,76
INS_HNTCH_BW,38
INS_LOG_BAT_OPT,2

There’s a noise at about 64Hz (as well as the one targeted at 76 Hz) so lets see if the above settings knock it out too. Otherwise we can add another HNOTCH, or the twisted motor mount issue might solve it.
You’ve still got Motor 3 and 4 (Clockwise spin) working harder than motors 1 and 2 (Counter-Clockwise) to fight against some physical yaw bias. This is usually motor mounts slightly twisted on the arms. It’s not ideal but it’s not end of the world either.

There’s some oscillation of motor outputs and yaw at arming - do you think it’s because of long or flexible landing gear?

I would probably set these too and do another test flight
ATC_ANG_RLL_P,6.0
ATC_ANG_PIT_P,6.0
ATC_ANG_YAW_P,5.0
ATC_RAT_RLL_P,0.12
ATC_RAT_RLL_I,0.12
ATC_RAT_RLL_D,0.0075
ATC_RAT_PIT_P,0.12
ATC_RAT_PIT_I,0.12
ATC_RAT_PIT_D,0.0075
PSC_POSXY_P,0.5
PSC_VELXY_D,0.25
PSC_VELXY_I,0.5
PSC_VELXY_P,1.0
PSC_POSXY_P,0.5
PSC_VELXY_D,0.25
PSC_VELXY_I,0.5
PSC_VELXY_P,1.0
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2

1 Like

Done, at same folder 1559hr

What about ATC_THR_MIX_MAN, PSC_ACCZ_I and PSC_ACCZ_P?

Do not have long or flexible landing gear, 8cm from FCU, image attached.
This is a KV650 motor.

It seems to have reduced, is it?

Y axis vibrations are still a bit high. Not causing a major problem but it would be good to get them down and stop interfering with measurements.

You could definitely set
ATC_THR_MIX_MAN,0.5
PSC_ACCZ_P,0.3
PSC_ACCZ_I,0.6
I wasnt worried about doing them earlier because they are not going to affect much, like the initial tuning/Autotune.

If you can settle down some of those vibrations, I would run Autotune on one axis then copy it’s changes to the other axis.
After pitch and roll is working well, you can do a Yaw autotune, or all 3 axis at once. After that you might want to double the ATC_ACCEL_Y_MAX that Autotune gives.

okay, I got the graph I should use to analyse. Also, any suggested of the usual causes? I suppose along the pitch axis ya. The document suggests Maximum acceptable values appear to be below 30m/s/s. I think the Y-axis is within the suggested range.

Sound like I can start to retry autotune and high chance of not getting back the issue again.

I do not actually look forward to a good surprise and the autotune will complete as the suggested method I had tried before in Sep 2022. The only differences are the PSC_xxx values and PIDs differ from the default initial parameters.

Anyway, I will still try the 4th time once I have successfully booked the space next week. If it works, then the default initial parameters do not work well for this drone’s autotune.




Fixing vibrations is key to getting a good tune

I think I could have found the causes of the vibe.y. Vibe.x and Vibe.z also improved. Ready for 4th autotune.

Autotune started and working…

Finally, autotune completed, THANK YOU so much to @xfacta . I like to know how and why you suggested/derived those PSC_XXX and ATC_xxx values.

Interesting, AutoTune allows higher ANGLE_P gains

@xfacta
These values should not be increased beyond what Autotune suggests without careful testing. In most cases pilots will want to reduce these values significantly.

May I know the reason to double it instead?

Autotune seems to give a conservative ATC_ACCEL_Y_MAX which can lead to an apparent “overshoot” in yaw movements. Doubling or at least increasing ATC_ACCEL_Y_MAX allows yaw to respond to input and corrections in a more timely manner.
Its not critical at all, but can be useful or nice to have yaw responding in a timely manner.

Hi @xfacta

after resetting and using your suggested default values for autotune, I keep getting Altitude overshoot when the pilot takeoff, Pilot_TKoff_ALT = 200. After a few seconds, it will settle down to ± 2m.

Is it caused by one of the PSC values? Can I change back to default values?

I am also using a rangefinder for height as well. I am setting up the UA for both indoor and outdoor usage as suggested here.
EK3_SRC1_POSZ = 2 (RangeFinder)
EK3_SRC2_POSZ = 2 (RangeFinder)

PSC_POSXY_P,0.5
PSC_VELXY_D,0.25
PSC_VELXY_I,0.5
PSC_VELXY_P,1.0

PSC*XY params dont have anything to do with altitude, that would be Z-related parameters

Both indoor and outdoor selection has this overshoot. I notice not all my past logs have this CTUN.SAlt, It seems to follow Baro alt behavior. hmmm …

I thought it may be due to EK3_SRC2_VELZ set to none where no other option, but outdoor also happens.

I hope nothing to do with these settings, I did this on another UA before.

EK3_RNG_I_GATE,500
EK3_RNG_M_NSE,0.5
EK3_RNG_USE_HGT,63
EK3_RNG_USE_SPD,6


It got worst if I set EK3_SRC2_POSZ = 1 (Baro) indoor, it never come down to 2m.

I guess it is time to update to 4.3.0 release.

Potential thrust loss and crash

Can anyone able to help identify the cause of the thrust loss during a flight? PMU, ESC, or FCU (4.2.3)?

this drone has been overall functioning well since 2022 July. Just last week, I did a very successful 25mins single battery flight indoor. Really does not understand where goes wrong.