The drone performed well during the initial flight phase but then suddenly lost control with drastic attitude fluctuations before crashing. Could you kindly review the attached logs and assist me in troubleshooting this problem? Thank you very much.
There is some yaw imbalance and an unusually low level of vibrations, could you probably share some photos of the machine?
Regarding the crash itself, things are not exactly clear, but there are multiple signs pointing towards a possible ESC failure. In particular, right in the middle of plain hover (Loiter and no inputs) there was a hiccup mostly on pitch, but also affecting yaw, happening out of nowhere between 02:01.5 and 02:02.2.
When looking for the possible causes, I realised that the machine is running Bluejay which provides EDT2 entries for Extended DShot Telemetry v2 (which I happened to introduce support for some years ago), and that at least one ESC (the one corresponding to the forward right motor) experienced an event triggering an Alert bit during this episode.
A different ESC, the one running the forward right motor, is in the Alert state all the time. It’s important to note, however, that this Alert is by itself the lowest problem-indicating bit according to the specs. However, this may indicate some problems, and when we come to the actual crash, we see this:
Here, we see that the EDT2 stream stops completely for ESC#2 (forward right) at the same time it goes to near-zero RPM, and that the EDT2 stream stops completely for ESC#1 (rear left) at the same time this one goes to near-zero RPM. This indicates these ESCs are really struggling internally to provide appropriate telemetry. The region of same RPM reported is likely the absence of telemetry as well, so each of these ESCs were offline for at least 0.2 seconds.
Overlaying the corresponding servo outputs (RCOU.C2 => ESC[1], RCOU.C4 => ESC[3], the RCOU indices are one-based and the ESC ones are zero-based), we can see that this low-RPM region was not commanded - although the initial deceleration might have been actually commanded:
All combined, my conjecture is that the cause was some kind of ESC failure. Whether it was simply a desync that was not recovered from, or anything else, I cannot speculate as of now. One other thing worth checking is whether you are running the latest Bluejay, just in case.
First of all, thank you very much for your reply. I’m currently busy repairing my 3D‑printed aircraft. This flight was carried out indoors with optical‑flow positioning. The system warned of magnetic‑field interference before take‑off, which I suspect caused this malfunction. Hardly any magnetic‑field warnings popped‑up during my outdoor tests, and the drone flew perfectly then. What puzzles me is that severe shaking occurred right after the magnetic‑field interference, putting the flight in a highly‑hazardous state.
Interesting.
(Compasses are a bit of my blind spot, most of my machines are too small for them to work reliably, they taught me to look at PIDs and related issues mostly)
Now I see that the initial “glitch” around 02:01 is caused by setting the home location. At that moment, two coordinate system reset events happened in quick succession, with one setting the destination point a couple of meters away from the current location, and another changing that again, but in an opposite direction. That jumping was likely caused by unreliable GPS reception just before that (HDOP = 2.3 or so, jumping back to 1.1 at the moment of set-home). It’s this event that caused that “glitch”, which was not a low-level glitch at all - just the machine trying to follow quickly changing setpoints.
Then the pilot switched to AltHold (a bit before the second setpoint was reached). Quite at the same time, a EKF yaw reset happened with a change of 15 degrees, and the pilot started to perform inputs on roll and pitch (but not yaw), possibly to get the machine back to its original location.
All in all, the machine could have managed that reasonably well, if not the failing ESCs. The requests to the ESCs do not seem like something exceedingly demanding - at least judging by what the logs contain - so I believe this all could have been just a nuisance if the ESCs did well.
So, what I think now is the sequence was as follows:
- a GPS glitch caused the setpoint jumping for ~2-3m around
- the pilot went to AltHold to stop and compensate for the apparently erratic behavior
- a yaw reset happened at the same time (may or may not be an overall magnetic issue)
- this was a manageable load, but it happened to knock out two ESCs for 0.2s each within a single second of the flight - and that was not recoverable.
I would say that magnetic interference, as well as GPS glitches, may be a contributing factor to the sequence, but definitely not the main cause of the crash - which is still an ESC fault to me.
By the way, I am not sure PSC{N,E} position entries should ever reach values like 12 million meters, like this log did. Yes, the difference was still of ~1m order which is not fatal, but the overall thing looks strange to me. I’m tagging @WickedShell for GPS and @priseborough for EKF, maybe you can look at that (or confirm that this was fixed since AP 4.6 - this machine reports 4.6 despite the post labelled 4.5).
Great news! Kindly let you know our latest update. We ran numerous tests today and confirmed that flight performance became stable after lowering the weight parameter of the magnetometer.Thank you again for your assistance.