So, the issue is just as the title says. It’s a new drone, and it’ll fly for couple minutes then just turns off. At which point it falls from the sky, always breaking something!
Best I can see the logs say, at he same time: disarmed, land complete, land complete maybe, motor interlock disabled.
So yeah that sounds bad.
Here’s the log:
Google Drive - Log Link
Please help. This is my first Arducopter drone, and it sure hates me!
THANK YOU!
Channel 5 is set to arm/disarm. It switches to disarm in flight. A radio failsafe occurs shortly thereafter, possibly because ELRS goes to low power mode when disarmed.
I think your compass is also very poorly calibrated, among likely other issues that a more comprehensive log would bear out. It looks like you’re using DSHOT1200, which is typically not recommended (DSHOT600 is the standard). I did not deep dive into other parameters or data.
There’s a few critical things missing from that log that would allow diagnosis, like RCout’s , RCin and IMU data (Vibrations)
It looked like it lost the motor outputs at a peak in altitude, which happens at the same time as the attitude control deviates and the voltage rises in this graph
All ESC RPM output stops at that moment too. So without knowing more (from the missing data) this could even be related to BLHELI settings, like the low voltage protection.
Check your ESC for these settings:
Set all these parameters to get back to a known-good state and log some more useful data:
ARMING_CHECK,1
BATT_ARM_VOLT,22.10
BATT_CRT_VOLT,21.00
BATT_LOW_VOLT,21.60
INS_ACCEL_FILTER,10
INS_HNTCH_BW,15
INS_HNTCH_FREQ,70
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
LOG_BITMASK,180222
MOT_PWM_TYPE,6
PSC_ACCZ_I,0.4
PSC_ACCZ_P,0.2
Just so you know, I have considered your prop size and use of ESC RPM, and per-motor notch filter when calculating those parameters.
Ok, I see the reason for the missing log data - LOG_BITMASK is excluding RC input and RC output. I wonder if that’s an attempt to limit log size on black box flash autopilots?
For now, it’s probably worth enabling those along with IMU data. However, RCIN5 appears to show pilot actuated arming and disarming, along with reason “2” for all arm/disarm actions (which is aux switch).
I’m sticking with accidental disarming in flight until there is evidence otherwise…
I have a theory after looking at your other related topic. There, you say your Copter is misbehaving after attempting a mode change. I wonder if you are accidentally flipping the arm/disarm switch when you’re actually intending to change flight modes?
While it’s recommended by ExpressLRS to use Channel 5 for arming, I recommend NOT doing that with ArduPilot air vehicles. Instead, leave RC5_OPTION set to 0 (nothing), but keep a switch assigned to it on your transmitter. Simply flip that switch to the high position before stick arming to enable the “armed” features of ELRS. The receiver itself uses Ch5 as a flag to enable things like dynamic power. ArduPilot doesn’t have to reciprocate by actually arming on that switch. I hope that makes sense.
If you’re using an EdgeTX transmitter, I can show you how to set it up to automatically switch Ch5 when you use the stick arm/disarm gestures. That’s how my own Copters are set up.
I’m interested in why you don’t recommend arming with Ch5 on Ardupilot vehicles, @Yuri_Rage. Is is just because it’s easy to accidentally disarm in the air with a switch vs. the typical rudder disarm? I would be interested to know how you do it in EdgeTX as well - maybe some kind of special function? I currently arm on a switch with all my vehicles (all on ELRS), but I have had students who have accidentally switch disarmed (and crashed) their copters - so showing them how to follow the ELRS CH5 arm procedure while still using rudder arm/disarm would be helpful, as most of them also use ELRS. Do you maintain a motor kill switch on your TX in case of emergency if you don’t use switch arming?
I don’t recommend it on air vehicles because time and time again we see crashes caused by unintentional switch disarming in flight. I do arm most of my Rovers on a switch - they don’t suffer the same catastrophic pitfall.
I do maintain either motor kill or switch arming during early testing on a new vehicle, but I usually move away from having any looming catastrophe on a switch, especially since I do so much testing, and my switch functions often change as I add and remove various features.
Here is my series of logical switches to enable detection of the stick arm/disarm gesture in EdgeTX:
And my corresponding first 6 channels in the mixing tab (see below for Ch6’s curve):
Just for grins, and since I’m already making screenshots in Companion, here’s a custom curve to enable 6 different flight modes on a 6-position switch:
My apologies for the brief, slightly off-topic hijack.
I think the copter doesnt hit disarmed state until after the fall.
ESC RPM output stops before the peak in altitude and momentum carries the copter in an arc before gravity wins.
At the moment it could be an ESC fault, or premature stoppage due to low voltage, but it’s hard to tell without seeing what the flight controller was demanding of the ESC
Good point, Shawn. I was actually beginning to think this thing simply takes off on its own after arming because of the lack of observed throttle command…not realizing at first that the LOG_BITMASK is a bit neutered. Took me a bit to wrap my brain around what was actually presented here. Your assessment makes a lot more sense to me now that I’ve looked a bit more broadly at things, and I agree that ESC settings are a good first step, along with more comprehensive logging.
As Shawn suggested use of Dshot1200 is not advisable. I have seen stuttering motors while bench testing with that protocol.
You guys are amazing! Thank you SO MUCH!
So it flew well enough with your settings where I was actually able to LAND it and not replace any props! lol
It’s got some funny oscillations, can one of you please review the new log data and give me some guidance on what next?
New Log: Log
Again thank you, thank you.
I even changed modes and didn’t crash (pos hold to alt hold and back)
The copter is very overpowered so hover throttle is not learning correctly (it is limited in code)
So MOT_THST_HOVER should be about 0.03 - which is extremely low. You should probably add a payload of some sort to make that hover throttle a bit more realistic. As it is now, motor outputs will hit minimums when you manoeuvre and that will affect stability. You might even be able to put on smaller props.
Attitude control is quite reasonable considering there’s no tuning yet.
Vibrations are low.
The harmonic notch filter is working perfectly
Definitely change ARMING_CHECK,1
If you get the hover thrust to be a bit more towards midrange of the motor outputs, you could run Autotune and it should end up very good!
Some people get hung up on thinking disabling the GPS arming check (and others) means they can fly without waiting for a GPS fix - which is slightly wrong. All the checks should normally be enabled unless a fault develops and you need to track it down (eg: arm to see what happens next with the faulty component).
The arming checks will tell you if a fault develops and you should not fly.
In your case you might want to set FENCE_ENABLE,1 and set a stay out zone so you dont get shot down. And if you encounter aliens you have the GPS track in logs 
There is some output oscillation so you should try lowering these to match the actual hover thrust value:
PSC_ACCZ_I,0.1
PSC_ACCZ_P,0.05
I say try because these are very low. Think my highest thrust/weight craft has a hover thrust of .08. You could easily add a higher capacity battery!
And if you can lower MOT_SPIN_MIN and still have smooth rotation on all motors you should try it.
Thank you so much!
I can’t wait to get AutoTune going.
So it’s over powered? My goal when I built it was for a craft with extremely long range. It already feels crazy heavy when you hold it.
I can see adding some more batteries, but how will that effect it’s flight time?
OR what’s the trick to getting crazy long endurance on a drone?
What if I used 2 bladed props instead of 3?
Also @ xfacta, why is arming_check 1 - checking everything when the docs say it should be 0?
That is a bitmask, so setting bit 0 (binary) equals decimal value 1
Thank you for the notes! I’ll have to play around a bit with that.
It’s high thrust/weight. Nothing unusual there, it just needs attention. If you increase the weight by adding battery capacity it will increase the flight time. Up to a limit of course. What motors (size and kV), and props (size and pitch) and what is the take-off weight with the battery you have?
Motors: Foxeer Datura 2806.5 1750Kv
Props: 3 blade, 10x5.
Weighs 3.5 lb.
10" 3 blade props with those motors on 6S? That’s fairly ridiculous. That will be way over the power limit of those motors if you drive it hard. And perhaps the ESC’s too depending on what you have. Use 7" props and you could still add significant weight in additional battery capacity.
Well POO!
So really 7" and I’d still have some weight to go? Two bladed?
So what motors/escs are you supposed to run on one of these:
Seems to me I’d be better off just putting all the guts I have on this 10" into a 7" frame…?
Lower kV motors.
Yea, you could do that. But even then you should have went with the 1350kV motors. It’s what I have on a 7". 10" is in 800-900 kV range. But if you want to salvage it as is replace the props with 7" 2 blade. And, you could add another 1.4kg in battery capacity…
Get a subscription to eCalc. It will save you further expense building with the wrong components.
