Statements like this tend to self reinforce based on anecdotal evidence alone, with no real engineering support or evidence, until someone puts it into mission planner or adds it to a wiki. Then everybody is happy and starts blaming the problems they are having on the next thing. Sometimes years later someone actually does the engineering and finds it was wrong then everybody says “why was this the official instruction”.
I will summarise the current state of understanding about expo (thrust linearisation).
We can only determine the expo based on a static thrust measurement. We have not been able to successfully make informative measurements in flight yet. However, we are hopeful that we may be able to do this.
A perfect expo calculated based on measured static thrust results does not mean this is the best expo over the whole flight envelope. This is a very difficult thing to quantify.
Static thrust measurements of a single propeller are not valid for a coaxial setup. You would need to measure the static thrust of the coaxial arrangement.
When I wrote the thrust linearisation code originally I was able to get thrust curves of something like 50 propellers and I used this to provide an estimation of expo vs diameter. I have no way of verifying the data or the way it was collected. I consider that data only a little better than anecdotal evidence.
I have some wishy washy feelings too. I suspect but can’t prove:
Highly loaded propellers will benefit from lower expo.
Flexible propellers tend to reduce pitch under load and benefit from lower expo. (this appears to cause a two part curve, a high expo for the first 30% and an almost linear expo after that)
Stiffer props will maintain pitch under load and benefit from higher expo.
Higher and Lower expo means less than ± 0.2
I have never seen an expo based on measurements, on a normal propeller of less than 0.5.
The expo is rarely the problem people are having trouble getting a good tune.
I just wanted to make it clear that this is an area that can still benefit from a lot of testing. Don’t just believe what you see on the internet as the most accurate answer is still “I don’t really know”.
I plan on doing some further testing of the thrust expo during ascends and descends. It would be great if T-motor helped more regarding their ESCs…
I’m glad to hear that it’s not abandoned of deemed impossible. The theory regarding flexing props is also interesting. I myself use polymer props. I have a set of carbon-fiber but they generate more vibrations. Probably more than they necessary du to poor design on my part.
By further testing. Is there any specific tests you need of that could help this go forward? I’m currently re purposing some parts to make a really lightweight machine. Max maxTOW would be around 6kg and minTOW could be as low as 2kg with battery and all. That could really operate throughout the entire throttle range of the ESC and motor.
Please let me know your results too, I keep track of any expo results I can find so I can improve the Initial Parameters calculator.
I’ve got a slightly updated formula in my own spreadsheet, which gives a slightly lower expo that the old Initial Parameters formula, but more data will be good before making further changes.
@tridge thanks for the work on this! Ran it on an “fpv” style quad with a Matek H743 stack and it performed beautifully.
Initially I tried to use the .apj for the matek fc from one of your earlier posts but it didnt work. Ended up using the one from @Yuri_Rage google drive. Interestingly it changed a few of my serial settings. Not sure why.
Anyways, once I sorted that out, went out in the yard and performed the test. Worked great on some motors I didnt have a chance to mount to a thrust stand. Thanks again!!
Can you please send me the .bin log and your copter details (prop size, motors and anything else you can think of), along with the thrust expo estimation.
I gather this data to see if our formulas need updating - and YES the Initial Parameters in MissionPlanner does need an update but I’ve been avoiding it
I’ll get a whole bunch of different quads and props compiled.
Only issue I’m having is that the lua seems a bit CPU intensive. Depending on whether or not I’m running a telem radio or just an rc input, I don’t always see the CPU warning message if I don’t have a GCS so running the script is kind of hit or miss.
I’m running everything on Matek H7’s, but I find I have to turn off a number of things before I can even get the script to run without the CPU error.
