I’m looking for help diagnosing a crash on my custom ArduCopter build. During flight, the drone abruptly cut power and dropped from the air with no visible failsafe warning in Mission Planner and no obvious pre-crash warning. Please find the bin file here: .bin
The current drop confirms this I think. It’s not instantaneous, looks as if it was spinning down for a second and only then turned off.
If not knowing the exact ESC type I could conjecture that there was some protection (or software watchdog) triggered - but since the channels are independent and the fault developed at, seemingly, exactly the same time in all the channels, the fault was somehow centralized.
That said, this definitely happened in a region of flight with very large pitch deviation, which may have caused an overcurrent event. Surely, in the logs there are regions with even higher current consumption, so it was not solely because the current reached the limit, but probably because something in the circuit was deteriorating and was triggered by too much current at an awkward moment in time.
(Something either in the vehicle design or in the tuning is really poor, by the way, judged by both desired-vs-actual attitude errors and by constant motor clipping even in moderately aggressive regions of flight)
My speculation, from the overall picture, is that it was a brown-out of voltage supply on ESC’s CPUs. I mean the 3.3V that powers the F421s. It is likely shared between the chips (and pretty much is the only thing that can be shared), so they may indeed go brown at the same time, which looks consistent with telemetry freezing and with not too instant shutdown. This may be either the ESC design flaw (could get some points if Adam’s incident was with the same ESC), or a result of battery supply voltage spikes (insufficient capacitors?)
(An alternative even more bizarre explanation is that the ESCs were knocked out by something over the telemetry wire, which is also shared, but given the architecture on this part, I cannot really imagine how this could happen)
From logs, it does not look like current spike, batteyr voltage also looks OK. I used different ESC.
However current logged sees to be very hight, and I suspect You just do not have it calibrated for Your ESC ( BATT_AMP_PERVLT=170, where 170 is for betaflight ). Just looking for all flight it does not look like some spike at the end.
10000/170 = 58.82 for ardupilot (I belive that was the formula 10000/)
It was not an unusually high spike, but it locally demanded an increasing amount of current (more than previous 8 seconds of the flight) - and this might not have logged in its entirety either.
By the looks of it (if I am not mistaken) motors 1 and 4 (counter-clockwise), as well as motors 2 and 3 (clockwise), are kind of always paired together. Since these are not one-sided, it does not seem to be yaw imbalance - rather, a serious lack of yaw authority, which seems to be consistent with desired-vs-actual yaw plots. This is also what one would expect from EDFs, I think, so you have to cant the motors appropriately.
Because two motors are often near-saturated, the machine cannot deliver an appropriate amount of thrust, which may be the reason beyond thrust loss warnings. It may also be that the true thrust curve is different from what the machine thinks it is (MOT_THST_EXPO and such), but here only stand tests would tell.
without looking at logs, I am an EXPERT (ha…ha..) at copters falling out of the sky: overheating ESC 4 x 1 usually shuts off all channels simultaneously when thermal protection kicks in.. Speedybee does it so. Had close to dozen falls while pushing for maximum weight with minimal hardware.
To determine if that happened, one has to see the weight of the copter and the location of the ESC, if it is well ventilated or not. The size and current rating of the ESC does not matter.
If your ESC does not provide temperature telemetry, most reliable test is finger test: hover for a about 1 minute, then put the finger on to the ESC. If it feels damn hot, then you got the overheating problem.
I believe that log does have temperature from the ESC telemetry, and it did not report anything close to criminal. (Also @Adam_Borowski mentioned that too). It might be that temperature reporting itself was somewhat broken, but this is usually a Bluejay thing when running on 1s and being misconfigured (and then it just reports nonsense).
Almost certainly that is true. Known issue with ESC’s with F4 MCU’s.
This craft was overweight/underpowered to start. Attitude demands, mostly yaw, but Pitch also, maxed the outputs causing serial thrust loss errors. It would be no surprise if these ESC’s were overtemp and errored out. And as would be expected the Yaw authority from the use of EDF’s will be very poor.
Full stick Yaw Inputs and this craft chokes trying to do it:
Sometimes the temperature hangs up. I had that in logs, and also when displaying in goggles live. (as you can imagine, after several falls, I prefer to keep a very close eye on the temperatures during flight).
I am pretty confident if we saw the copter and its weight I could say that the problem was or was not temperature overheating.
Past the edge I would say. A hover thrust value of .45 accounting for expo is generally going to be overweight/underpowered. We see that here all the time. This craft at hover with no demand has outputs averaging 1750us.
Generally underpowered with poor attitude control authority on top of that.
Thanks a ton for checking out my logs and giving such great feedback. This really helps clear things up for me!
To give you some more context, the drone has a rectangular shape(5.5cm x 3cm) and a weight of 3.45 kg
About the ESC and Current Readings You guys are totally right about those crazy high current logs. I actually didn’t realize I had to divide the current sensor scale by 1000. I will change that.
It really sounds like the 4-in-1 ESC just gave up under the heavy load, probably from overheating or a voltage brownout. The logged temps looked fine right before the crash, but if the telemetry froze up or gave bad readings like a few of you mentioned, that completely explains why it got “stuck.” I’ll definitely look into better cooling.
About the Power and Control Issues: Regarding the drone being underpowered, it’s definitely pushing the limits. But since this is purely a custom test build and an experiment, I’m okay with it being a bit heavy and having a high hover throttle for now.
To give some context on the setup, the drone weighs 3.45 kg and has a rectangular shape where the short side is the front and back. We actually did a bench thrust test for an individual EDF and mapped our motor thrust curve based on that single test.
We actually did a bench thrust test for an individual EDF and mapped our motor thrust curve based on that single test. On the bench, we saw a thrust-to-weight ratio of 1.299 at 50% and 2.64 at 80%. After putting it all together, we let the flight controller figure out the actual hover throttle using the automatic MOT_HOVER_LEARN mode, which is how it ended up at that 1750µs average.
I do have a few questions on how to make it fly safer, though:
Improving Yaw Control: For the yaw authority issues and the motors maxing out to fight for control, how can I actually improve that? Would restricting the attack angles (pitch and roll lean limits) work? I know it would make the drone slower and less agile, but that is totally fine for this experiment if it stops the motors from choking.
Altitude Control Imbalance: How can I go about solving the altitude control imbalance? I really need some help in this area because I’m not entirely sure what to look for in the logs or what I need to change to fix it.
That kind of difference in thrust available indicates some serious issue somewhere, most likely incorrect thrust stand calibration or significantly less power available on the vehicle than during testing.
To improve yaw authority you can cant your thrusters to produce desired yawing moment.
Unless you change the mechanical setup, you should reduce yaw authority by several factors, i.e. I would reduce yaw PID to 30 % of what it is now. Probably not limit pitch/roll though, or reduce it somewhat. The copter will not crash, but will be extremely mushy in yaw.
And the stupid question is: why using these thrusters? I can not see any reason whatsoever for using them. You have extreme hover inefficiency, you have extreme lack of yaw control, what do you gain from them? And, considering 3.5 kg, ineffcient thrust and if ESC is not under direct prop wash (and it can not be because of the prop type), then your ESC does not stand a chance for a flight of more than 60..90 seconds.
Sudden power cutoff is almost always the battery. Percentage doesn’t do it, you need the actual volts, where cutoff is at 3.0 volts per cell.
Reliable battery-voltage monitoring requires a sensor directly connected to the battery balance lead. I don’t believe there is any other way. The leads coming from the terminals of a power distribution board and the utility given by Ardupilot/Mission Planner won’t do it either. As far as I can tell, voltage monitoring off the PDB is only makeshift, and even pseudo.
Accurate and reliable voltage monitoring is from a sensor directly off the balance lead, and then by live telemetry to your radio or console.
