Critical failure in VTOL flight - IO MCU crapped out..?

Hi all,

Today I am writing to describe a really suspicious crash that happened to us a week ago. It was the second flight day of MFE Fighter VTOL that we have set up with our own electronics and propulsion configuration. The crash happened during testing the transition to fixed-wing flight however not during the transition but while the plane was steadily hovering in QLOITER mode. All of a sudden it disabled all motors, went into RC failsafe, and fell from about 40 meters. Our pilot did not have control of the plane during this event. In the title I mentioned suspected IO MCU failure, that’s because from the log analysis that we’ve performed, it seems the most likely. To paint a better picture here’s a list of the hardware that we’ve used:

  • Autopilot – Cube Orange with ADSB carrier board, Ardupilot 4.3.5
  • GPS – Here 3+
  • RC and telemetry – HereLink v1.1
  • FPV camera – GoPro Hero4
  • Motors and ESCs – KDE direct UAS series
  • Servos – HiTec 6v digital
  • Voltage and current sensing – mauch premium line
  • Airspeed sensor – matek DLVR can sensor

Power architecture: POWER1 and POWER2 inputs on carrier board: separate Mauch 5,3V BECs, SERVO RAIL on carrier board: Jeti SBEC set to 6V output, HereLink AirUnit power input: Polulu 12V BEC, GoPro USB power in: Mauch 5V BEC

Every connection was inspected pre-crash and post-crash. Apart from the obvious components that got disconnected during the crash (wings got yeeted 10 m from the fuselage), every connection was in perfect condition. We’ve even measured every wire harness with an LCR meter that we installed on the aircraft prior to the maiden flight to ensure there’s no cold solder or improperly crimped connector. That leads us to believe the crash was not caused by an electrical failure. Voltage readings in the log file confirm that.

In the log file, there was a registered RC failsafe event which is weird because we had FPV video transmission during the whole flight and the plane was not far away from the pilot (approx. 60 m). We have a buzzer installed on the plane and prior to the crash, we’ve heard the RC failsafe chime. Furthermore, the RC Failsafe action was set to QLAND. We think the autopilot registered RC Failsafe, because the IO MCU stopped processing any radio inputs. We had a killswitch set up, which was assigned to a channel with certain PWM values, but this value remained in HIGH state all the time (killswitch not engaged and not logged).

We have also installed a camera on the left wing. From its footage (which I unfortunately cannot share at this moment), we can see that autopilot had authority over the elevator during the crash. The motors and ailerons were not moving during the crash. This behaviour is consistent with logs, every RC output that was connected to MAIN OUT (RCOU.C1-8) on the carrier board remained “frozen” at its last logged value as if the MCU stopped working. The elevator which was moving during the crash had a changing output in the logs. The elevator and rudder were connected to the AUX out. This led us to suspect that we have encountered an IO chip failure. This is further confirmed when looking at the IOMC messages which stop at the start of the crash event.

When looking at the Cube architecture, the IO chip is responsible for RC input and 8x main out PWM signals, and if it fails I would suspect a behaviour like we observed during our crash.

This leads us to strongly believe that the crash was caused by the IO chip failure of some kind, my question is has anybody experienced a similar issue? Do you know what can cause this chip to fail during flight? Another strange thing is that the chip now works as after rebooting the autopilot it receives the RC signal and has authority over the MAIN OUT ports so it wasn’t a permanent failure. Is there a way to further diagnose this event by looking at the logs? Or maybe there are some tests that can be done to this unit of Cube Orange that could bring us closer to an explanation? Links to the log file: 00000287_crash.BIN - Google Drive

Any help would be greatly appreciated. Right now I’m scared to use the Cube in any platform anymore…

Very similar crah happened to me recently with cube black. https://discuss.cubepilot.org/t/black-cube-with-latest-wing-fw-crash/11167

There is something wron in combination of black cube and latest FW.

Ardupilot will soon have a new release with a bug fix included for an IOMCU radio control issue, it’s in Beta now.

In your log only elevator and rudder retain control because they are on the AUX outputs (Servo9 and above) while the IOMCU definitely does appear to become totally unresponsive. The IOMCU logging stops entirely and we could assume it’s (main) outputs go dead too since the plane clearly drops.
I cant see any external reason for the IOMCU to die. The Vcc drops slightly when it does, indicating maybe there is more current draw.

Exactly, all AUX outputs were functioning properly, only the main ones died. We decided to ground this cube permanently. After an issue like this we think it’s unpredictable and dangerous to use.

by checking the logs seems that the plane was commanded to do the pitch and roll oscillations.
see desroll vs roll and despitch vs pitch, so the AP and servos were functioning.
but pitch rates were out of control …
Checking AOA shows stalling.
seems that you never gained enough air speed to do the transition.
looks like the AP is good,