It is said that the value of “MOT_THST_HOVER” must be between “0.2 and 0.8”. Is it difficult to maintain altitude if this value is low?
The param simply says that your vehicle hovers with 20 to 80% thrust (or total throtle if you prefer).
Thus if your hover thrust is 0.8 your vehicle most propably is underpowered and will not have enough room for manuvres. On the opposite side if you hover with just 20% of your available thrust, the vehicle is overpowered and it will be jumpy and difficult to tune. …Or it means you’ve done a great job with your airframe weight and you have plenty of room for batteries to increase flight time.
In short, most of the times heavy is bad, light is good or managable
Best,
Dimitris
It is not good if the value of MOT_THST_HOVER is too low 
The current value for MOT_THST_HOVER is 0.23.
It’s neither good nor bad it’s just a higher thrust to weight. Tune for it or add a heavier/ higher capacity battery.
If there is higher thrust against weight, are there any drawbacks?
They can be more challenging to tune. But I have a small quad with a MOT_THST_HOVER value of .125 and it is very well tuned and flies great.
Guys, I try to figure out what value I should I use for MOT_THST_HOVER to properly set notch filter, but after setting MOT_HOVER_LEARN = 2 and hovering flight I read MOT_THST_HOVER = 0.17. It seem to be wrong value because my quad is reasonably powered and at hovering sends to ESCs servo value around 1420uS. If I interpolate 1420 between 1000uS (0%TH) and 1900uS (100%TH) it’s about 47% of TH, which is reasonable but far from 17% saved in MOT_THST_HOVER. What value should I use? Why is autolearnt throttle so strange?
Thanks!
Throttle is not linearly mapped to PWM, see:
Hi,
trying to calculate in the XLS sheet, but values still doesn’t fit together. Obviously my real hover thrust is somewhere between 40-50% and in this area are corrections by MOT_THST_EXPO very small - just in few % range. This doesn’t explain so big difference between MOT_THST_HOVER = 0.17 (17%) and real hover thrust (around 45%).
I’m becaming confused of this and notch filter setup isn’t very clean here. Can you please maybe using my hover log here tell me what is correct MOT_THST_HOVER value in my case to use for the notch filter setup?
I repeat that my quad isn’t any crazy overpowered beast as discussed above hovering with the TH stick at the bottom, but reasonably powered quad hovering with TH stick just a hair under the middle.
Edit: I tried to add some balast weight to my quad, do another hover and check whether MOT_THST_HOVER has changed - and yes - slightly. Adding 20% extra weight to my quad changed the value from 0.17 to 0.20. From it I guess that the value gets updated, but still I’m curious how such a big difference is possible. Any more explanations or ideas wellcome!
Thanks!
Hi. I know this is an old thread but I just came across it as I have the exact same question. I just built a thrust stand and took some measurements.
Based on the log files, the quad hovers at ~1515 PWM output, which would correspond to 4*1kg of thrust (according to the thrust stand measurements). This seems spot on because the quad weighs 4kg. At least the thrust stand works!
However I cannot see how the MOT_THST_HOVER (=0.21) learnt during flight corresponds to anything in the spreadsheet. I would have expected this hover throttle to be the ‘normalised throttle’ which takes the PWM_SPIN_MIN and the range of PWM_SPIN_MAX-PWM_SPIN_MIN into account. However in that case 21% normalised throttle would correspond to ~4*0.5kg = 2kg, which is not enough thrust to hover.
I think it’s the same observation as @rptacek made above. Is anyone able to shed light on what the MOT_THST_HOVER really means?
Thanks!
1 Like
I see the RATE.AOut at hover, in the logs, is ~0.21 which corresponds with MOT_THST_HOVER. I guess I am just missing something in how AOut gets mapped to the ‘normalised throttle’.
Thanks Yuri. In the spreadsheet I linked (the one that comes from that page you provided) I’ve already fitted the MOT_THST_EXPO.
You can chase the exact method through the source code, entering at this line:
libraries/AP_Motors/AP_Motors_Thrust_Linearization.cpp#L99
I think I applied the method correctly in the attached spreadsheet (ignoring voltage scaling). It seems to make sense with what you’re seeing. I’m not 100% certain I applied the transformation from linearized output to throttle correctly, but it does correlate nicely.
B2B Big Motor Thrust Fit (edited).zip (15.5 KB)
Hi Yuri. Many thanks for that spreadsheet and the pointer to the relevant source file.
You’ve helped the answer become clear to me. MOT_THST_HOVER, AOut etc. are a fraction of the maximum thrust, rather than being directly in units of throttle or actuator outputs. It seems obvious in retrospect.
That at least gets me within one row of where I expect to be in my spreadsheet, which is good enough given possible differences between the trust stand and flight. It also makes sense then that MOT_THST_HOVER changed after I updated the expo, it still hovers at the same actuator PWM obviously but that now corresponds to a different point on the thrust curve.
1 Like
MOT_THST_EXPO,0.3
is still quite low, like for very small props or ESCs trying to do some funky thrust linearisation.
Via our normal method (Leonards graphs turned into formulas) I would expect around 0.6 to 0.7 for 15inch props.
Yuri, are you able to check this post and see if lordvon is correct and how it affects to expo
EDIT
I plugged that in and it didnt make a big difference but maybe it is more correct.
I still suspect a higher MOT_THST_EXPO value would be correct, because even though the red and blue lines dont overlay perfectly, I think the slopes match better when using 0.6 even though the graph lines are offset.
1 Like
The real test will be some ascents and descents in Stabilise mode and checking in logs.
I’d be very interested to see that. It can actually be hard to find adverse effects from MOT_THST_EXPO since our rule of thumb talks about high throttle and low throttle, and in normal flight we almost always have hover throttle or near to it.
Yeah I agree that it looks like the ESCs (Turnigy Plush-32) seem to be doing some linearising. I initially had 0.71 until I took the thrust stand measurements.
Last night I rewrote the spreadsheet to make it simpler and more intuitive (IMO). Now it makes it more explicit that you are trying to linearise the actual delivered thrust against the demanded thrust from the controller.
I’ll see if I can make it solve for the MOT_THST_EXPO that minimises the RMS deviation from the straight line (easy in Python, I’m less sure about Google Sheets).
I think he’s right - it makes sense to normalize between MOT_SPIN_MIN and MOT_SPIN_MAX rather than just multiply by MOT_SPIN_MAX and add MOT_SPIN_MIN.
In practice, it seems to make very little actual difference on the curve shape, but maybe extreme examples (large MOT_SPIN_MIN values) would show appreciable differences.
this correction allows you to estimate mot_thst_hover more accurately on less data. e.g. your thrust curve data starts at 25% or so. makes a huge difference then.
edit: also some other improvements if i may.
- voltage column should be removed (normalized input throttle should not be corrected for voltage under load… otherwise you can never hit 100% input throttle at spin_max…)
- implicit is the assumption that spin_min corresponds to the lowest throttle in the dataset that is also greater than spin_arm. this should be made clearer somehow. i modified the spreadsheet to not be related to spin_arm and spin_min, as value of mot_thst_hover relates to physical performance of the thruster not ardupilot config. cleans up the spreadsheet while reducing chance of user mistake.
- current / amperage column appears unused…