Set MOT_THST_EXPO value with RPM (CAN) controlled ESCs

[tobiokanobi]

Dear Community,

I tried to find related discussions, so in case this topic has been discussed, pls. point me there.

Configuration: Pixhawk 6X via CAN to VESC6.0 to TMotor MN705S (kv140) with T-Motor 26.8" CF props.

I am using CAN and the VESC keeps the RPM pretty tight to anything the AP commands. When using the inital tuning, the Motor Thrust Expo parameter is set to something like 0.77 .

Now, since the VESC follows RPM commands from the AP and as far as I understood, the parameter is to calibrate a nonlinear curve to a linear curve when PWM signal is used, I imagine that the parameter should be, when RPM is used, 0 ?

Discusions related to mot_thrst_expo parameter are:

Automatic MOT_THST_EXPO estimation lua script

Highly interesting! Thanks for the info. Regarding the high expo and large props, I have been thinking of altering the calcs in the Initial Params to suit a maximum value of around 0.8 since I also noticed Leonard mentioned that. EDIT - what I mean is change the curve, formula, a bit rather than just setting a hard maximum - this new estimation script will be great info for that, so I’m holding off until I know more. I like the informative output from the script too - nice! You might have to…

Using "measured" MOT_THST_EXPO: What improvement can one expect?

Hey let’s assume one has measured the motor thrust curve and thus can determine a more accurate value for MOT_THST_EXPO, than the default of 0.65. Theoretically this should improve control and thus the copter behavior. What I’d like to understand better, since I lack the experience/knowledge: How much of a positive effect can one expect in practice? If there is any significant effect, how could one actually validate/demonstrate the positive effect, in some objective manner? Thx, Olli

Kind regards,
Tobias

P.S. The spreadsheet is layed out for measuring microseconds (PWM) on a thrust test bench. I could use the VESC PWM input, but that seems like beating a screw with a hammer into the wood. If I would have to do it accurately, I would most like need to take also the aerodynamics C_d of the fuselage into account.

[xfacta (Shawn)]

Just my thoughts:
I believe MOT_THST_EXPO should still be close to a standard value based on your prop size, at least as a starting point. The thrust curve mostly changes because of the prop rather than how well the motor and ESC track the demands from the flight controller. Most modern ESCs will be quite good in this regard, see BLHELI and AM32. Unless your ESC tries to linearise the thrust somehow, but then there would be some setting in the ESC for that to suit different applications, or the ESC would come in a set tied to the motor and prop.

A thrust stand will give you good results if you are OK with using the spreadsheet correctly, but keep in mind: that is static thrust. So in reality you probably want some value that’s an average of the static thrust expo value and some expo value that might be in play during forward flight and other maneuvers.

Generally you can test your MOT_THST_EXPO by doing some ascents and descents and looking for instability, provided tuning is quite good - for a multirotor of course.

• set too high you can see instability at low throttle
• set too low you can see instability at high throttle

If you make a significant change to MOT_THST_EXPO then you also have to retest and set MOT_SPIN_ARM and MOT_SPIN_MIN

Leonard Hall is the king of this sort of stuff and will have much more scientifically-backed information than whatever I say.

Check this:

Automatic MOT_THST_EXPO estimation lua script

I am not sure exactly what you are referring to but I will try to clarify this. The expo curve moves between a y = x straight line to a y = x^2 line based on the expo value. The idealised propeller model and motor model produces a y = x^2 thrust curve but in real systems this curve is flattened out due to the various losses in the system. When we use this thrust in a multirotor we can’t use the zero thrust point because this requires the propellers to stop spinning and esc’s don’t like trying…

[tobiokanobi]

Thanks a lot for your reply.

In my first tests, I did not see undesired behaviour with the pre-calculated MOT_THST_EXPO.

My thought was that the algorithm is based on the (very simplified) theory that pwm and thrust are set into a (linearized) correlation (based also on the propeller properties). If I am not completly off, thrust force is, independent of the propeller (diameter, pitch…), equal to rpm^2 (
T∝(RPM)^2).

But I understand that ardupilot would still maps (pwm to rpm) for UAVCAN. Hence, it may be still necessary. And aerodynamics are strange. Don’t want to get into any turbulances here!

I simply test it with 0 and 1 the next time to identify if it makes a difference. I mean an expensive hobby is nice, but buying a thrust test bench is at the moment a little too much for the budget, even though christmas is coming. If I have a lot of time, I put a train scale under the aircraft and increase rpm to identify the relationship rpm and thrust force for my configuration.

[aaaa (Jaeuk Bae)]

If you are using can-esc, it might be worth logging the RPMs to see how well the motor tracks the RPMs commanded by the FC.

As you know, thrust T = Ct * rho * n^2 * D^4. Here, Ct and D are constant if the propellers are the same so we can treat them as constants. rho also doesn’t make much difference if the altitude is the same.

In my case, I use an integrated propulsion system, so testing with a thrust stand was not possible.

By default, an ESC with linearisation seems to linearise the throttle input-RPM relationship. Below is data from the Tmotor integrated propulsion system tested without a propeller.

Below is the actual flight data. You can see how the data is quite scattered due to the delay caused by inertia.

The orange line is for thst_expo=1. The figure on the right is the result of applying mot_spin_min. You can see that the thrust linearisation results deviate due to the propeller’s drag, the effect of mot_spin_min, and the minimum rotation speed of the ESC.

So in my case, I decided that thst_expo=0.55 works well, and the result is shown below.

Testing on a thrust stand would be the best way to do this, but most people probably don’t want to spend a few thousand dollars on that.

I think this could be a way to indirectly estimate thst_expo.

[tobiokanobi]

A good approach @aaaa; I do have the data recorded.
Right now I am doing some mechanical configuration changes to minimize the mechanical cause of a “yaw-unbalance” message (Fully articulated TVC bi-(or)-tandem copter.). As soon as I’ve finished that, I’ll follow your advise.

[Yuri_Rage]

See here for a tool that should produce better results than the spreadsheet:

ArduPilot Thrust Expo

[tobiokanobi]

Dear Yuri,
thanks for the link. My intention was more to identify if the MOT_THST_EXPO is still reasonable if direct RPM values are passed on to the motor controller instead of the old school PWM. A thrust test bench is fancy “nice to have”, but shouldn’t be a must to have. The thrust test bench tool uses PWM signal, and not RPM (or rad^(-1)).

[Yuri_Rage]

As Shawn said, a nominal value for the prop size should likely still be used. There are very few ESCs that perform any thrust linearization (and I’d argue they probably shouldn’t try). Thrust is typically not directly proportional to RPM, so an expo value should likely be employed.

Since the topic of test stand data and the legacy spreadsheet arose, I thought it important to link to the newer tool that should produce superior results.

As for whether test stand data is mandatory - I’d argue that it is highly preferable, especially as prop size increases. It’s not strictly necessary, but error sources quickly compound, and removing them via empirical data will always result in better behavior.