Glitches in PWM-controlled Myxa B0

Over the past two weeks we’ve observed strange flight behavior on our hexacopter flight platform, which we finally tracked down to be related to some kind of motor controller issue.

A quick rundown of the setup:

  • Hexacopter, T-Motor U8II KV150, Mejzlik 28x9.4 folding propeller, Myxa ESCs
  • Auterion Skynode Flight Controller (basically a Pixhawk FMUv5X), running PX4
  • Myxa ESCs running Telega v1.0, controlled via PWM (yes, I know… :confused:)
  • Myxa’s CAN1 for configuration and monitoring only, shared with FMU and GPS units communicating via DroneCAN

As mentioned above, the Myxas are controlled via PWM, configured to run in velocity-controlled mode (aux.ctl.mode: dv 300.0). After many months of successful operation, the ESC driving motor 5 (UID 32000d00…) started acting weird: occasionally it seems to ignore the setpoint received via PWM, throttling up to maximum power.

The first picture below shows PX4-sent actuator signals, the second plot shows the velocity reported by Myxa (dynamics port).
With M5, one can see the velocity setpoint and feedback diverging greatly:

I see a few possible causes here, one less likely than the previous one:

  1. I might be picking up crosstalk on the PWM line in question, which somehow creates a valid PWM carrier, which in turn is correctly picked up by Myxa.
  2. One flight controller PWM output channel might have a fault, emitting PWM signals which have nothing to do with the attitude control loop.
  3. Myxa might have problems, either with decoding the PWM signal or with controlling the motor.

None of the causes above seem likely, and unfortunately I have not been able to reproduce this behavior on the test stand.

@pavel-kirienko and other Zubax folks, do you have any idea?

Vector control systems actually may have one failure mode where uncontrolled acceleration can occur, but only the voltage control mode is affected and Telega has a mitigation in place that restarts the estimator within a few milliseconds from the onset of the failure before the rotor has a chance to accelerate. This is not what you’re dealing with, I am just providing some background.

We encountered the described behavior multiple times while bench-testing larger drives in RCPWM control mode. This occurs when the electrical connection of the analog port connector is poor; when the connection is broken, the analog input pin becomes almost floating – it is tied to the ground via a 20 kohm resistor only:

Depending on how the wiring is organized, the EMI from the power stage can be strong enough to cause the pin to flip in a pattern roughly following the phase currents, which is sometimes interpreted by the RCPWM demodulator as a valid signal. It is enough for a false signal to occur once to trigger a positive-feedback runaway process, where the drive accelerates based the first false high-value setpoint, then the acceleration causes stronger EMI at the analog pin and the process thus becomes self-sustaining.

There is an option to enable strong pull via the aux.pull parameter; however, this won’t really address the root of the problem but rather make the drive shut down in a predictable manner instead of accelerating uncontrollably. Also, it requires the RCPWM signal source to have a sufficiently low impedance to override the strong pull resistor, which is not always the case – there have been reports on this forum of Telega-based drives failing to respond to RCPWM signal when the pull resistor is enabled.

My advice is to check the wiring.

Thank you for the detailed analysis, Pavel. I’ll check the wiring and see if I can reproduce some of the EMI issues.