Help on analyzing log: Possible ESC desync leading to motor failure

Hi all,

Looking for some help interpreting a PX4 log from a crash and confirming a desync hypothesis.

Setup: Mark2-7", Holybro Kakute H7 (PX4 v1.18.0), SpeedyBee BLS 60A 4-in-1 ESC, T-Motor 2207 2080KV, 5" tri-blade props, 6S 2600mAh.

Pilot saw smoke in the air right before losing control. Post-flight, all 4 motors have some charred/carbonized winding insulation — one much worse, none in a hard short.

Theory: repeated desync leading to current spikes and insulation damage.

From the log, pointing to desync:

  • Roll rate self-oscillating ±240°/s while setpoint stayed flat.
  • Gyro PSD shows a narrow, stable 18-20Hz band , in distinct bursts, which vanishes completely in prop-off bench tests.
  • Final ~4-5s: one motor pinned at max DShot continuously, two others collapse to idle, torque_setpoint_achieved never recovers.
  • Battery sagged to ~19V (3.17V/cell) under load, current peaks ~123A (~47C on 2600mAh).

So my open question is: Does a narrow stable band fit a desync or is it a mechanical resonance?

Thanks!

cannot confirm with 15 seconds of flight time…First check how much time the battery can carrying the drone with the payload attached…

I don’t think the final motor saturation alone is enough to distinguish ESC desync from a downstream control response.

The part I would try to establish first is the event ordering.

Do you still have the original .ulg for this flight?

In particular, I would like to compare the timestamps of:

first 18–20 Hz growth → first rate/setpoint divergence → first actuator asymmetry/saturation → battery current/voltage excursion → allocator failure

If the spectral component is present significantly before the control divergence, that would be different evidence from it appearing only after the vehicle has already begun losing control.

I would also be cautious about treating the narrow frequency band itself as proof of desync without ESC RPM/telemetry or another independent indication of rotor/motor behaviour.

If you can share the ULog, I can take a look at the first divergence rather than only the final 4–5 seconds.

Thanks for your reply.

Find the .ulg attached:

Thanks for sharing the ULog. I went through the failure sequence.

There is a fairly clear loss of control authority starting at roughly 52.16 s.

Immediately before the divergence, the four motor commands are still relatively balanced (at ~52.09 s they are approximately 0.173 / 0.170 / 0.145 / 0.179). The measured angular rate then starts diverging rapidly from the requested rate. The rate error exceeds roughly 0.5 rad/s around 52.17 s, 1 rad/s around 52.21 s, and 2 rad/s around 52.29 s.

PX4 then reacts aggressively to the disturbance. By ~52.39 s the motor commands are driven close to 0 / 1 / 1 / 0, and control_allocator_status reports that the requested torque can no longer be achieved. This looks like the controller reacting to an already developing loss of control authority rather than creating the initial disturbance.

The battery voltage also drops substantially, but the timing is important. Around 52.18 s it is still about 24.06 V at 11.4 A. After the controller starts driving the motors hard, it drops to about 19.21 V at 39.8 A around 52.38 s. So I would not currently identify the voltage sag as the initiating event; it appears after the attitude/rate divergence has already started.

The log therefore looks consistent with a sudden propulsion/thrust asymmetry.

However, I don’t think the ULog alone is sufficient to conclude specifically that this was an ESC desync. The logged esc_status does not provide useful in-flight RPM/current telemetry through the failure, and failure_detector_status does not flag a motor failure.

My current interpretation would therefore be:

sudden propulsion loss/asymmetry is strongly indicated, but ESC desync versus motor/propeller/electrical-path failure cannot be distinguished conclusively from this log alone.

If you have ESC telemetry/logs (especially per-motor RPM, current, voltage or ESC error flags), that would be the next thing I would compare against the ~52.1–52.4 s window. That should make it possible to determine whether one ESC/motor stopped producing thrust despite PX4 continuing to command it.