This topic raises an improvement request for next releases : go back to a logical intuitive scale expressed in PWM microseconds (from 1000 to 2000). Why making things more complicated where you must actually compute the parameter value. By the way, to compute it right in the current version ; do we have to substract 10% or the value 0,1 ?
I can say that it does a good job of automatically setting the new mid-throttle parameter. However, my throttle stick in stabilize is still at the one third mark to hover and not the half way mark. So when I go from Loiter or Alt Hold to stabilize, it still shoots up, as I need to have the throttle at the the mid point for those modes to maintain a stable hover.
I am not understanding how this works now. The main point of mid throttle setting is surely so that when you leave alt-hold or loiter and go to stabilize you do not have to make a quick adjustment. This is still happening even with the MOT_THST_HOVER set to the correct setting (about 0.289 in my case).
Am I missing something here? (Probably!).
MOT_THST_HOVER LEARN works wery well…you do not have to calculate nothing,just set to 2…
Of course it works well, that is not my point. My point is that it is not anymore the direct hover PWM value (like it was in previous releases, which was much easier). That’s all I’m saying.
I have it set to 2. It has indeed set my mid-throttle parameter correctly.
My copter still shoots up in stabilize. Previously, in stabilize when I had mid throttle set my throttle stick was at the halfway mark after I had done this. So what is the point of setting mid-throttle if my stabilize throttle setting is not at mid-throttle. When I go from alt hold to stabilize I need to be quick on the throttle adjustment. This does not seem correct.
Is my copter’s behavior different than yours under 3.4.1?
Mine is at 3.4.2… but in 3.4.1 it was the same…and yes,after i let Pix to hoover learn my throtle is at middle…
What do you mean(i am not native english) when u say my copter shoots up …?
How do you start your flights?Must be in Stabilize,and when you copter leaves the ground where is your throttle stick(should be at half)?
Also when you are in AltHold,if you move your stick just a little out of center,when you turn it off,copter will adjust throttle acording to your stick…in other words,if you lower your throttle during althhold copter will drop when u turn it off…
check my tuning thread here(its long…very long),maybe u can find some information here
Thanks – that is the issue in stabilize my throttle is not half way. I clearly have to look at this again as my experience is not matched by others. I am sure I will figure it out.
Nice custom copter BTW.
Do you have any dataflash logs with your problem?all developers will ask the same…i think you should do ESC calibration again (with OneShot off) and be sure u did it properly…
A bit of clarification, or more to the point a bunch of confusion and an explanation of why this way is MUCH easier to understand.
Before we made this change we had the output pwm values. They were generally somewhere between 1000 to 2000 and 1100 and 1900. So a difference of between 1000 and 800.
We scaled this range to 0 to 1000. Then we had minimum throttle of something like 130. Hover throttle was then say 400.
Ok, soooooo what was the pwm output a hover throttle. Lets assume the normal pwm range of 1100 to 1900. For now lets ignore one_shot that can have 125 to 250 us or can buss that could have a 16 bit int or a float.
So minimum throttle was 1100 + 800 *130/1000.
Hover throttle was 1100 + 800 *400/1000. (or something like this). The throttle was represented in 3 different ways and scales through out the code.
So no, it was not simple or directly related to the pwm value and the pwm range is almost never 1000.
So now the throttle value is 0 to 1 where 0 is minimum throttle and 1 is maximum throttle. If you look in your log and you see your throttle value (CTUN_ThO) is set to 0.31 at hover you just set your hover throttle to 0.31 and you are good to go. If you have set your MOT_ parameters correctly the hover throttle won’t change much from a full battery to an empty battery.
So we have a couple of throttle settings that you should probably understand here. We can now set MOT_PWM_MIN and MOT_PWM_MAX. This lets you choose what the pwm range is independent to the range on your radio. If you leave them as zero then it uses the radio values.
MOT_SPIN_ARM, MOT_SPIN_MIN and MOT_SPIN_MAX define the armed pwm output, minimum throttle output and maximum output throttle.
spin when armed pwm = MOT_PWM_MIN + (MOT_PWM_MAX-MOT_PWM_MIN )*MOT_SPIN_ARM
minimum throttle pwm = MOT_PWM_MIN + (MOT_PWM_MAX-MOT_PWM_MIN )*MOT_SPIN_MIN
maximum throttle pwm = MOT_PWM_MIN + (MOT_PWM_MAX-MOT_PWM_MIN )*MOT_SPIN_MIN
MOT_THST_HOVER defines the hover throttle using the formulae below.
Hover throttle pwm = minimum throttle pwm + (maximum throttle pwm-minimum throttle pwm) * MOT_THST_HOVER
The new representation is very simple and has simplified the code a great deal. It has made it much easier to understand and ensure it is bug free. It has also cut down the code significantly and made it quicker.
A few notes on hover throttle:
it has a minimum of 0.125 and maximum of 0.6875. This is the minimum and maximum values we can use a smooth expo curve to put the hover throttle at mid stick.
Add a dataflash log so we can see what is happening and I am sure we can fix your issue.
Thanks for the clear explanation Leonard. Code simplification is always good. I will recalibrate my radio and ESCs again and see if this persists. Than I will post my data flash logs. It seems I am an outlier.
Thx for explaining the difference between how it was and now how it is. I still hear two different versions between what you’re saying and what Randy is saying.
If I understand your explanation right, before to set Throttle_MID we had something like Hover throttle =1100 + 800 *(throttle value read in logs, e.g. 450)/1000. And now we have the same formula (Hover throttle pwm = minimum throttle pwm + (maximum throttle pwm-minimum throttle pwm) * MOT_THST_HOVER) but the log variable name has changed (to CTUN_ThO).
However Randy says we have to lower by 10% the logged hover throttle (he gave the example that if you had 290 in the Throttle log in previous version, you should use 0,19 as the new mid THST_HOVER value).
Sorry, but this is still very confused. Before it was so simple : you’d open your hover flight log, you’d just read the throttle value, for example 55 and you’d configure MID_THROTTLE to 550 and you’d be good to go. Now I have to calculate a complex formula, maybe removing 10% ? (tbc)
To cut it short, I do not think we need to understand behind the scenes developer’s logic or explanations why this or that has changed in the code. Why not just show us step by step with screenshots, what log should be opened (Throttle ?), what variable(s) should be read in hover and to write to which parameter(s) ?
You just need to enable hover learning by setting MOT_THST_HOVER_LEARN to 2.
Randy was saying that the new scale is about 10% smaller than the previous THR_MID setting.
I think it is always nice and welcome when devs do an enrichment explanation like this one. It helps people debug their own issues and to help each other. Thats how good open source projects are.
Your copter shooting up with your throttle stick at middle is an issue, if you provide the logs I’m pretty sure we can help.
I was the one whose copter is shooting up. Since I am an outlier here it must be related to my setup. I am going to re-do my calibrations and do more test flights – which I will do when I finish a few other setup issues on this bird.
Hope you find anything. If not, just let us know!
You do not have to do anything special…it is more simple than before…you just set mot-thst-hoover to value 2…and your stick will be in middle…always…if you change weight of your copter it will still be in middle…no calculations ,why do you care what was before when u do not need it?
I might be missing something here (it is, after all, 01:17 in the morning here where I live!), but aren’t the the parameters to the right of the equal sign in the last two equations identical?
Ok. If you say so. I will try to see if this works indeed so easily, then fine. The origins of my comments come from this thread here that lets us think it is much more complicated.
Leonard - I’m assuming that
minimum throttle radio pwm = MOT_PWM_MIN
maximum throttle radio pwm = MOT_PWM_MAX
minimum spin upon arming in pwm = MOT_PWM_MIN + (MOT_PWM_MAX-MOT_PWM_MIN )*MOT_SPIN_ARM
minimum spin in flight in pwm = MOT_PWM_MIN + (MOT_PWM_MAX-MOT_PWM_MIN )MOT_SPIN_MIN
maximum spin in pwm = MOT_PWM_MIN + (MOT_PWM_MAX-MOT_PWM_MIN )MOT_SPIN_MAX or
= MOT_PWM_MIN(1-MOT_SPIN_MAX) + MOT_PWM_MAXMOT_SPIN_MAX
… but just a guess.
Note that if the defaults for both MOT_PWM_MIN and MAX remain at 0 then
minimum spin upon arming in pwm = 0
minimum spin in flight in pwm = 0
maximum spin in pwm = 0
… so if PWM_MIN and MAX are undefined, then are the radiio calibrated throttle MIN and MAX values used instead?
The way I see it, the PWM MIN and MAX are just the radio calibrated values. The flight controller will not spit out pulses outside of those pulse widths. The 3 “SPIN” parameters are merely a percentage of that calibrated range. As an example, I make the math really easy by setting up the transmitter to send exactly 1.00ms to 2.00ms on the throttle channel.
So, if MOT_SPIN_ARM is 0.12, our ‘idle’ pulse after arming will be 1.12ms.
If MOT_SPIN_MIN is 0.17, the flight controller will not send anything under 1.17ms while in flight.
Then MOT_SPIN_MAX could be 0.9 if I know my ESC output saturates (max speed) at 1.90ms.
One can use an adjustable PWM generator to better understand their ESC’s pulse vs. speed behavior using a bare motor on the bench.
Undefined as 0, yes.