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
Hi Olli,
This is an extremely important parameter for tuning aircraft. Most ESC’s work on a principle that the commanded input is approximately proportional to the average voltage used to drive the motor. This results in a strongly non linear thrust response for each propeller. I used measurements of approximately 100 propellers to come up with the default MOT_THST_EXPO value of 0.65. The basic principle is the larger the prop the higher the value. So a 30" propeller would be closer to 0.8 for a normal ESC and a 5" prop would be more like 0.5. Coax propellers also seem to be lower so I use 0.5 for most coaxial designs if I don’t have measure thrust characteristics.
However, some ESC’s appear to do a compensation on the commanded input to attempt to linearise the thrust value. Depending on the ESC and propeller the MOT_THST_EXPO can vary from -0.3 to 0.5.
The other parameter that changes the value of MOT_THST_EXPO is the MOT_SPIN_MIN value. So if you increase the MOT_SPIN_MIN then the perfect MOT_THST_EXPO will need to be reduced.
So the only way to define this parameter properly is to measure the thrust curve and calculate the MOT_THST_EXPO. However for most ESC and propeller combinations the defaults will work well.
So how do you tell if this value is wrong?
You get oscillations when you go full throttle or you have very poor control at low throttle.
You find that you can’t change the take off weight of the aircraft without redoing the tuning.
Both these assume you have a near perfect tune at hover (and I mean my idea of a near perfect tune). You should also have the voltage compensation features set in the MOT_ parameters.
So to give you some examples from aircraft I have tuned. I have aircraft with hover throttles of less than 15% that will not show any signs of oscillation at full throttle with no adjustment or compromise of the PIDs at low throttle settings. I have aircraft whose take off weight can vary from 12.5 to 50 kg without adjusting the PID values.
I hope that answers your question.
thx a lot for the detailed response.
You indeed gave a very nice and comprehensive explanation of things, which has much value by its own, and your response should probably become the first-go-to reference henceforth.
I’m afraid however that I’m not totally satisfied as regards the practical implications.
I see your point with the take-off-weight, and I have no doubt that when changing it by a factor of 4 that this has implications. However, I think that’s for many not very relevant. My takeoff weight may vary a couple of 10% at most. The bottom line is, that varying the take-off weight by factors would not be a practical method for me to validate the impact of a better MOT_THST_EXPO value.
I also see your point with the oscillations at low/high throttles. This would go more along lines I would have imagined for validation. I mean, one hopes for a better control, so looking for the “goodness” of the control is an obvious thing to do. The problem is though, what exactly should one look for to evaluate this “goodness”, and equally if not more important, how to clearly distinguish the effect from the effects due to non-“perfect” tuning. For my copter I could not see any oscillations, and I think I wouldn’t even if they would be there theoretically, simply because the high/low throttle situations always are short in what I’m doing (it’s not easy to see oscillations on top of a narrow spike, right). I’ve realized that you address this, IMHO crucial, point briefly, but it’s unclear how one would validate that your (or whomever else’s) idea of a near perfect tune at hover has been achieved. So, I do see these two issues here, how to establish a reproducible reference point, and what exactly to look for in some data to evaluate the loss of “goodness”.
For instance, one could think about the auto tuning. But to me it looks that it is not really sufficiently reproducible. Also, I wonder, since it does quick tilts, during which the motor is clearly driven quite a bit away from the however point, in how much that non-linearity expressed through MOT_THST_EXPO isn’t actually partially accounted for. I.e., it likely would not yield a reasonable reference point. And so on.
I would be, btw, also perfectly happy if the answer would be - if that would be the correct answer - that only if one is quite away from the 0.65 it would make sense to adjust MOT_THST_EXPO. I mean, I’m not trying to do 0.01% science here, and most wouldn’t find that practical either. So, if the answer would be that getting a rough measure of the thrust curve to get a rough check of MOT_THST_EXPO would be way sufficient, then this could be a more practically relevant answer than any 0.01%. For instance, you mention the possible effect of the ESC. I was wondering about that too, but would think that this should show up quickly in even only a rough thrust curve measurement. Of course, one still would want some confirmation through looking at data that the correction was indeed useful. Not sure I could explain what I mean.
thx, Olli
Hi Olli,
I think I completly agree with you here. I gave those two example because they are obvious symptoms that your MOT_THST_EXPO is a long way from correct and that it should be checked before moving forward. For most aircraft and pilots they do not operate over such a broad range.
It is worth keeping in mind here that ArduCopter has been designed to operate over a very broad range of aircraft and applications. As such we must me more comprehensive in our approach. This also means that many pilots can afford to ignore settings like MOT_THST_EXPO while others it becomes a critical variable.
I have often said “It is easy to make a multirotor hover, it is much harder to achieve the same level of confidence at the limits of the aircraft’s performance”. MOT_THST_EXPO is one of those settings that sets us apart from lesser autopilots.
So to directly address your question as I understand it. You are correct:
From what I have seen from T-Motor ESC’s they appear to do some thrust linearisation on the ESC and therefore aircraft using these ESC’s would be better off with values of 0.0 to 0.3.
Other than that, your average aircraft will not need to adjust MOT_THST_EXPO and it can be ignored as it has only a mild impact on the results of Autotune and most pilots couldn’t tell the difference anyway.
A little while I tuned a very small commercial vehicle using tiny brushed and geared motors. Thrust measurements lead to a negative value of MOT_THST_EXPO. This completly revolutionised the quality of performance and tune.
Another example was a large commercial aircraft using current controlled ESC’s. Again this needed a negative value of MOT_THST_EXPO.
So to summarise: If you have achieved performance you are satisfied with then you can probably ignore MOT_THST_EXPO. This will be the case with the majority of aircraft.
Thank¨s Leonard for so complete explanation, I have one copter with 14" props (idealy is 13") that fly well but don´t spin enought fast to take off in auto mode, is mot spin min the correct param to solve this issue? I have to change mot-thst- expo too? Thank´s
fantastic! This had been really very useful information.
I was asking these questions since I’m pondering if the telemetry data available with UAVCAN ESCs, such as rpm, current, could be used for evaluating better values for MOT_THST_EXPO. Pavel e.g. has shown in a blog/video how to use the UAVCAN tools to measure rpm vs pwm and current vs pwm curves.
Now, rpm is not thrust, and such measurements can’t replace real thrust measurements, but I’m kind of convinced that one may get relatively reasonable estimates of the thrust with pwm from the UAVCAN telemetry data, by plugging in some common relation ships. E.g. I would not expect that the prop efficiency varies by factors with rpm. In addition one can estimate torque from current using the motor’s KV, and mechanical power from torque and rpm, as well as the electrical power. So, there is quite some information deducible, which should help in the task of estimating an approximate thrust curve.
From the above I conclude that such a methodology might in fact work out, since it might detect the more extreme cases, in which one should act, and might suggest better values for MOT_THST_EXPO in these cases. As you explained, in these cases, it should not be too difficult to validate that the “better” values are indeed better.
At least worth a try, IMHO.
Thx a lot,
Olli
Hi Cala,
This does not sound right. You would have to give me a log to work out what is happening here. However, neither of these parameters will prevent you from taking off in auto mode.
HI Olli,
RPM measurement would be a good way detect and correct for ESC’s that have linearisation features. This would help take care of the majority of poor MOT_THST_EXPO settings.
Very good suggestion!!
I was trying to repeat a mission that my racer can do well some time ago, wp- land- delay- take off- wp - wp etc- RTL; after the delay the copter coudn´t take off well, and I aborted mission, I´m going to try to generate a new log because It was some time ago and don´t try again to avoid crash. Thank´s
just as some feedback to the above discussion
I did a .py script, using pyuavcan, which ramps up and down a UC4H ESC KISS driven motor with prop, and measures rpm and current (the script can be found in the UC4H git repo). From these curves I estimated the thrust using basic blade momentum theory and motor equations, yielding S^3 \propto (rpm x current)^2. The script also fits the data to the (1-a) x + a x^2 curve given in the Ardu docs. The data and fit looks good. The fit yields however a = 1.15, which I think should be MOT_THST_EXPO. Not sure what I should think about that. I guess a comparison to real thrust curves would be good, or there is a trivial flaw in my “theory”. But in principle, it’s all doable.
I’d like to mention that in order to get the .py script to work, Pavel gave me a crucial tip. THX Pavel!
A value of greater than 1 does not make sense. I think the problem is you have not moved the minimum and maximum values to where the Min_Throttle and Max_Throttle would be.
Could you provide the derivation of the equations you used. Even if it is just a photo of your written out maths?
I think the problem is the current measurement, it doesn’t look right at low rpms, maybe a calibration issue. I guess I’ll ask Felix.
Thanks,
If you send me your normalised thrust vs pwm data I can work out what I think the thrust expo is.
LOL stupid me has forgotten to save it to file, but it was highly reproducible, so I’ll redo it. The good thing of a quad is is that it has four esc+motor+props, so four independent measurements, I think this would be most important to do now, gives a chance to validate the accuracy of the data.
here the data of the 4 motors http://www.olliw.eu/drop/ap/data-2018-02-28.zip
they quite consistently give 1.12(5), and they consistently show that somewhat weird low-I behavior
one probably should cut out a bit of the low rpm range in the fit
the ‘theory’ btw assumes negligible I_0, and constant prop efficiency, not sure how well the later is justified, but if not I think a relatively universal curve could be extracted from ‘real’ data
have fun
Hi Olliw42,
I had some curve fitting fun and I get Expo : 0.59071 , Zero Throttle : 0.18624 , Max_Thrust : 0.868.
Looking at your data I expected it to be just a little flatter than what I see normally. So it is just a fraction below my standard 0.65 figure.
I would be interested to see this compared to measured thrust data.
Thanks for your input!!
could you share in which respect your fitting differed from ‘my’ fitting?
I was following the mathlab script given in the ArduPilot docs, so, there must be something wrong/incomplete/missing with that docu, e.g., it only fits expo
?
That is my code. You need to set the max and min in that though. I extended it a little to calculate the maximum and minimum points.
% Perform a least squares fit to solve for a in thrust = (1-a)throttle + athrottle^2
mdl = @(a,x)(((1-a(1))(x-a(2))/(max(command)-a(2)) + a(1)((x-a(2))/(max(command)-a(2))).^2))*a(3);
%Expo, Zero Throttle, Max Throttle, Max_Thrust
startingVals = [-0.5, min(command), max(thrust)];
coefEsts = nlinfit(command(range), thrust(range), mdl, startingVals);
frankly, this doesn’t make any sense
with a3 you have made the function to be a totally different beast. And if the expo indeed depends that strongly on little range changes, then it’s value and the whole fit is what is called (in some ares) unstable, and unstable = nonsense. You are fitting an elephant.
also, I thought the limits are used by ArduPilot to cut off the output to the motors, so they have enough headroom for doing yaw, altitude or for whatever reason, or to set meaningful input values, and would thus be independently set parameters. Are you seriously saying that you set these parameters according to the results of your fit?
