T-Motor MN2806 KV650 with Arducopter 4.2.x

Noted, will repeat the flights and also include 11x10x3

do you mean this? I think FFT_ENABLE is = 0, I have enabled it now for next flight test.

The FFT_ENABLE parameter is for the flight controller to run the FFT analysis live and use that for a souce of HNOTCH filtering.
I couldnt get MissionPlanner to display any of the INS_LOG_BAT data as it normally does, where MissionPlanner runs the FFT analysis post-fight.

okay, I put it back to 0 then.

Hmm, interesting. I have put in all values already.

log for 11x7x3, uploaded into same folder
log for 11x4.5x2, uploaded into same folder
log for 11x10x3, uploaded into same folder

Does anyone know why my autotune failed to tune? Is it due to HNTCH being enabled?
Prompting the pilot to tune manually.

Because the basic/initial tune is poor.

Not sure is it due to 4.1.x and and above issue. Previously other drones were done using 4.0.x

All along the craft we build with Cube series do not use vibration damping mount.

I think I will try reduce the aggressive to see any good surprise. This is the first time I tune a drone using a low KV motors.

You will most likely be surprised with an even worse tune by lowering aggression.

I don’t quite get it, it started when I lowered the default PID by 50%. Then it stopped and started to prompt the pilot to manual tune. No different if I turn off the INS_HNTCH_ENABLE.

The default initial parameters and lowered values are both flyable and only noticeable a slight height drop when pitch and roll. No oscillation so call.

4.2.3 firmware.

I am now suspecting MOT_THST_EXPO with the digital ESC and the motor. Many T-Motor users pointed out very linear motor curves.

after changing thst_expo from 0.66 to 0.99, I got a recommended thst_hover value of 0.2503457. I hope the autotune starts and works next, finger-cross.

No, not the problem of the thst_expo. Not due to the initial tune not being properly done too. With the default PID parameters, it hovers like a charm without position lock and without pilot sticks input except drops high when pitching and rolling. I am doing in indoor with no wind condition.

I also tried reducing pitch and roll PID by 50%, but it did not start to tune also (engaged but didn’t start).

I run out of ideas about where the settings are wrong. This is not the first drone I do and had attempted autotune successfully before with the 4.0.x version.

autotune failed 2nd time, 4.2.3

Have you got a link to the actual .bin log file?

done, uploaded.

First up to answer a question a lot of people seem to ask - enabling HNOTCH and setting correct values (or even close values but not perfect) wont make Autotune fail. I suppose such bad values could be set that it would affect normal flight, but that’s not an Autotune issue.
It is definitely better to set up the Harmonic Notch Filter as soon as possible, and before running Autotune if it can be done.

Back to the log
Was that log from before you changed
INS_LOG_BAT_MASK,7
and other HNOTCH settings ??
I ask because there’s no data collected in that log for FFT use, and those values are not set.
Otherwise definitely set this right away.
INS_LOG_BAT_MASK,7
and make
AUTOTUNE_AGGR,0.1
but dont go out and try to run Autotune right away. Let’s get a few things sorted first.

There’s some Y axis vibration like prop balance, or something about the flight controller mount. See if you can fix that.

MOT_SPIN_MIN and MOT_SPIN_ARM are way too low. Set them
MOT_SPIN_ARM,0.04
MOT_SPIN_MIN,0.09
to ensure the motors spin reliably.

MOT_THST_EXPO,0.99 ?? Surely this is an early log??
It should be 0.66 for 11 inch props.
I’m thinking this log is old and probably useless for the purpose of tuning your quad.

If you have a spring-centered throttle also set
PILOT_THR_BHV,7

Have you got the latest log where you made all the changes that have been suggested?
Go over the whole discussion and implement all the changes. Ask if you’ve got any questions and we’ll sort this out. :slight_smile:

No, it is after. I turn it off thinking suspecting the cause to complete the autotune. Previously you suggest to me to enable them and you still didn’t find any data inside.

I can increase, motor test result looks comfortable to me.

this was again suspecting my hover thrust not below 0.25 and cause autotune unable to complete, therefore increasing the expo resulting my drone hover thrust going towards 0.25. No, this is the latest log. The date and time indicate 20221011…

I will do that, not sure how much it can contribute.

Do not quite understand what you mean.

Now, I am tempting to use 4.0.7 on this drone where we have successfully autotune many drones before to narrow down the issue.

I would use the latest stable firmware, reset all to defaults and start over with calibrations, battery voltage setup and Inititial Parameters.
Set INS_LOG_BAT_MASK,7 and PILOT_THR_BHV,7 then do some hover and gentle movements in AltHold mode.
Dont rush to be in Loiter or doing Autotune yet.
Let’s see that log.

The latest firmware indicates issues with Autotune, where as the earlier versions just dont alert you to the issue. That doesnt meant the earlier version works better.
In that log there was no sign that Autotune was doing anything despite you switched into Autotune mode, clearly indicating there was problems preventing Autotune from working.

2 Likes

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