Just setting up a new build. Twice now, soon after commencing autotune it loses thrust, drops out of the sky. Log link.
I used @xfacta spreadsheet setting for initial tuning parameters. I’ve set up other builds with all these same components except the motors; those are the new variable here (trying to say my initial starting tune numbers shouldn’t be wildly incorrect). I tried to pair components carefully (props/motors/ESCs are properly sized on paper) but this still seems like that sort of issue. Motor thrust on paper puts me in the 2.6 thrust to weight ratio (not accounting for “over enthusiasm” in t-motors reported thrust curves), but I’m still thinking that’s my problem here.
I am not sufficiently knowledgeable, however, to be able to extract the cause from the logs. What does one use from the logs to diagnose undersized motors/props? Looks like I’m hovering around 28%. My vibe never exceeds 10. I read in other posts to check the rcouts (mine are channels 7-10 fyi). One motor goes maxed out during the drop out of the sky, but not until (drop starts at 2min17s). Does that look like an individual motor problem or insufficient thrust overhead?
A bit odd you have a Dshot protocol selected but the MOT_PWM_MAX/MIN are at default 0. Typically they resolve to 2000/1000 when you select that protocol.
I was looking at the ThO (throttle output) and ThH (throttle hover calc) fields to arrive at my 28% hover thrust number (I was hovering just before going into autotune).
Those are not linear with output. Best to see what the actual commanded output is.
And as an aside you can use Dynamic Harmonic (Option 2) for the Harmonic Filter. No lack of processing with that FC. Also, consider using the Bdshot target for that FC. Better reference for the Notch filter.
are you saying that my crash occurred because of the motor being maxed out? or that the error itself occurred when the motor maxed out, but there’s some other, as yet undiscovered reason for the motor being maxed out?
The motor being commanded to maximum output (and thrust loss warning) is a symptom of that motor/prop combo not producing the required thrust to maintain attitude. That could be from physical failure, electrical failure (large current spike or dip) or motor/ESC desync.
I havent looked at the log, but what ESCs have you got, and what BLHELI settings?
I wanted to see if it was always the same motor that lost thrust, for troubleshooting purposes (it’s not) and just by observing it for a while it appears that I lack sufficient torque on the low end to give me the responsiveness needed for good stability. I have no idea how one can support that hypothesis with the log data however.
The purpose for this is a search-and-rescue platform. Long flight time and long range are the design drivers.
1950 kg all-up-weight
BATT: 2 each 6S Li-Ion 10C 4000mAh in parallel (8000mAh total, rated together at 20A continuous 80A intermittent, so I’ve got the current overhead)
ESC: T-motor F55A 4-in-1 pro v2
FC: Matek H743-WING
PROPS:
for testing I’m using T-motor MS1503 15x5.6 polymer/CF, at 25g each (cheaper)
ultimately I’m intending to fly the T-motor NS 15x5 CF, at 13g each (expensive)
MOTORS: T-motor MN4004 300KV
(thrust curve in the specs on the t-motor site)
these motors look to have the thrust to do the job on paper, with a 2.6 ratio. Sufficient I would think. However, maybe the motor torque is too low despite the thrust? I don’t know how to calculate the required torque, but this is still my current hypothesis. The t-motor thrust curves specifically provide the numbers for a 15x5 prop (screengrab from the t-motor website below), so it was my impression that the props would not be oversized for this motor, according to the manufacturer.
given all this, here are some more questions for the experts:
does anyone know how to take the torque specs for the motor to estimate whether that’s a problem for me? I don’t even understand the reported numbers, to be honest; the torque is reported in the t-motor material differently depending on the prop length. I thought it was supposed to be an attribute inherent to the motor, independent of the prop selection.
do you think swapping the props for the more expensive ones, at half the weight (lower moment of inertia) and marginally less pitch (0.5") would make a significant difference? I don’t want to ruin the expensive props with testing if I can avoid it. Those NS ultralight carbon props are pricey! I’ve been lucky keeping it close to the soft ground and e-stopping quick enough to not ruin any of the polymer props so far, but that’s just luck. Wouldn’t want to count on that with the more expensive props. But if it’s going to make a big difference, I’ll just have to take the chance.
might messing with the BLheli32 settings improve things? I’m using an ESC that is marketed toward small-frame, high-performance racing, on this large-frame, low-performance build. Perhaps the ESC settings are not optimized for my purposes? I’ve seen some material regarding motor timing, but I don’t know enough to make changes. Here’s a screencapture of my blheli settings (everything should be stock from the factory for this ESC):
Hi Matt,
No, I don’t think this is a factor with the issues seen. Just some longer term advice to consider. Another bit for reference. You don’t need to set the SERVO_BLH_MASK and OTYPE for Dshot. Unless you are using other outputs in the timer group for standard PWM. Just the MOT_PWM_TYPE parameter is good. And consider the Bdshot target.
Turn off Low RPM Power Protect right away! I have found all other ESC settings at default to work for a wide range of Motors kV.
Will 16" props fit on the craft? eCalc says ~55% hover throttle with 15’s which is in the ball park of the ~1600µs command hover output seen. You could use a bit more thrust/weight. Forget those motor manufacturer tables, they can be accurate or way off the mark in my experience.
yes indeed 16" will fit. the only reason I went with the 15" is because of the higher efficiency listed in the tables, I thought that might get me a bit longer flight time.
I’ll turn off the “low RPM power protect” first, then fly again to check if I observe any changes, then I’ll switch to 16" and try that afterwards. The 16" immediately available to me aren’t the same type of prop, but it should provide useful data regardless
That would be an easy fix and it might have some influence. But typically with this on with low kV motors the motors won’t spin ~ above 1/2 throttle. So it’s a drastic problem. But hey, let’s see!
Not sure if this is related but your RCX_MIN values are odd. Some are 989/991, then RC5_MIN is 1041. I had some weird calibration numbers like that when my Taranis transmitter wasn’t set up correctly for 16 channel ppm
How come your RCOUT that look like motor outputs are on C7,C8,C9,C10 instead of C1,C2,C3,C4?
In my opinion the 16" are too big and also too heavy (too much inertia), even if you take the lightweight NS type. In my tests with the 4006 380kv, 15" was the limit that could be flown with sufficient agility. OK, this was not directly comparable because it has 380kv but it also has already 50% more “iron”.
I have not tried the 16" yet (forgot them this morning) but I tried the 15" NS, no improvement. Busted one of them unfortunately.
The whole thing is very strange, because it seems to fly just fine in stabilize, alt-hold, loiter. But as soon as I turn on auto-tune, it crashes on the first or second roll attempt. Is there something about the auto-tune that can be tuned? Isn’t it strange that I can’t recreate the instability while I’m flying, even aggressively, but then it crashes on autotune?
Re crashing in AutoTune, you’ve done the ESC calibration and motor test of course and set the MOT_SPIN_MIN value to ensure the PWM values don’t go too low?
Are all the BLHELI ESC settings back to defaults and low voltage and low RPM protect settings turned off? Leave timing and everything else at defaults.
I am using dshot150 so calibration is irrelevant yes?
my motors start to spin at 1% when I use the motor test tool (can’t exactly go any lower). By the wiki advice then MOT_SPIN_ARM should be set to .03 and MOT_SPIN_MIN to .06, but I left them at the default of .1 and .15 respectively. Turning them down won’t benefit my situation, right? I was under the impression that higher was safer for this sort of issue. Should I put them down at .03 and .06?
@xfacta
yes I believe my settings are back to defaults, with “low rpm protect” turned off. Below is a screengrab of the settings I used to crash this morning. Looking at it now, I don’t know where the 1040/1960 for min/max throttle come from. Perhaps that’s how AP maps my taranis inputs of 988/2012. Does blheli suck in the 1040/1960 over the ds150 coms, based on the MOT_SPIN_MIN and MOT_SPIN_MAX values scaling my taranis raw inputs?
One thing: I just noticed that my MOT_THST_EXPO is 0.71. I don’t remember ever entering such a high value–is that learned somehow? (EDIT: my expo value came from @xfacta’s great spreadsheet I remember now) Could that be causing a problem? I’ve read somewhere that the t-motor ESC might have some built in linearization, so that we’d be doubling up with a curve in AP. Do you think this could be an issue? Any suggestions on what value I should use for my ESC (T-motor F55A 4-in-1 pro v2)?
.1 and .15 will be good for the MOT_SPIN values.
Usually only the T-Motor Flame ESCs require an odd MOT_THST_EXPO, your BLHELI ESC will just need the normal value of 0.71
I think BLHELI defaults to those PWM values until calibrated, but all that is irrelevant and ignored when using DHSHOT.
All my BLHELI ESCs (so far) show Motor Timing = Auto
And I set Rampup Power = 25% but that may not be required - there was an “arm shaking” issue I was chasing and I’ve stuck with that setting even though it may not have fixed anything
EDIT: Actually I also use Sine Modulation = ON and PWM Freq = 96kHz
Higher numbers of MOT_SPIN_MIN are generally safer in terms of protecting against too-low throttle value but will reduce the vehicle’s ability to use lower throttle values for control (both attitude and altitude). A larger range is better if possible.
