Uncommanded indoor flyaway after failed calibration/reconnection. No log generated (LOG_DISARMED=0). How is this possible?

ArduCopter Copter 4.6
1

Hey everyone,

I am trying to reverse-engineer a terrifying indoor bench accident that resulted in an uncommanded, full-speed takeoff and crash. I need help understanding ArduPilot’s internal safety architecture because what happened feels like a catastrophic firmware/hardware lockup.

:warning: CRITICAL CONTEXT TO PREVENT MISUNDERSTANDINGS:

  • NO LOG EXISTS (0 BYTES): Because LOG_DISARMED = 0 and the crash happened instantly, NO log file was ever initialized or written for this event. The SD card is verified perfectly healthy (working fine before and after the crash), but there isn’t even a 0-byte file header for this event.
  • STANDARD DIRECT WIRING: The ESCs are plugged directly into the Cube Orange MAIN OUT ports. No companion computers, Lua scripts, multiplexers, or direct receiver-to-ESC passthrough wiring.

The Hardware:

  • FC: Cube Orange (ArduCopter V4.6.3)
  • RC System: Radiolink Transmitter & Receiver (SBUS)
  • Hardware Switch: Physical safety switch button was disabled (BRD_SAFETY_DEFLT = 0).

The Exact Sequence of Events:

  1. We plugged in the flight battery. The drone sat static on the bench.
  2. We successfully connected to the laptop GCS via telemetry and attempted a calibration (which we did not complete).
  3. We intentionally disconnected the telemetry link with the plan to reconnect it immediately.
  4. The glitch begins: On the second attempt, telemetry completely refused to reconnect. The drone was unresponsive to the GCS. No arming commands had been sent at any point since plugging in the battery.
  5. Surprised by the telemetry dropout, we assumed the RC transmitter might be the issue. We power-cycled the transmitter (off, then on).
  6. Crucially, when the transmitter booted back up, the physical throttle stick was unintentionally resting all the way up (100%).
  7. The exact millisecond the receiver re-linked with the radio, the motors instantly spun up to absolute maximum power, rocketed 7 meters into the ceiling, and crashed.

The Paradox:
If the flight controller was healthy and disarmed, the ArduPilot motor library should strictly mask/kill all PWM outputs, regardless of what raw SBUS throttle data the receiver delivers upon re-linking.

However, because telemetry had just failed to reconnect right before this happened, and absolutely zero bytes of a log file header were generated, we suspect the Cube Orange’s main processor may have entered a frozen, corrupted, or “watchdog loop” state during the failed calibration/reconnect sequence.

My Questions for the Community:

  1. Is there a known edge-case bug where a failed/interrupted calibration or telemetry disconnection can cause the I/O driver layer to lock up or lose its “disarmed motor masking” safety logic?
  2. If the main loop freezes or crashes, can the Cube Orange’s hardware default to passing raw timer outputs/SBUS inputs straight to the MAIN PWM rails without ArduPilot’s safety code actively blocking it?
  3. What is the definitive way to build a bulletproof hardware firewall on the bench to guarantee that an internal flight controller lockup cannot default to an unmasked, full-throttle output state?

Thanks for reading, and I’d appreciate any insights from anyone intimately familiar with the Cube Orange hardware and ArduCopter output stages.

2

Not sure if I missed something but it happenned while the calibration process was going on. If this was esc calibration, then it does some rc passthrough to assist in calibration and this pass through could have caused it.

Also, why disable the safety switch? It’s a decent safety system

3

What calibration?

4

No matter what calibration, working with props on the bench is not a good idea.

The wiki clearly mentions to remove all props in calibration/ configuration steps, there are very few cases when you want the props on the vehicle while configuring

5

Upload your param file.

I agree why did you have props on?

What guide did you use to setup your quad?

6

sorry I wasn’t clear about it earlier, the drone wasn’t connected to the laptop in order to perform a calibration, we had a problem with connecting it that’s why we power-cycled the transmitier and at this moment it took off, it wasn’t armed not even connected to the missionplanner, additional detail it was in land mode when in took off

7

we wanted to perform an accelerometer calibration which it gliches so we had to reboot the mission planer and tried to connect to the drone once again we also did disconnect the battery and connect it again, at this momment it refused to connect to the drone via the telemetry (let alone arming) so we power-cycled the transmiter and whooom the drone flew and crashed the stadium’s ceiling.

9

With the props on? Sounds like your process was reckless and I doubt there is any “Ardupilot Paradox”.

10

yes… that was a mistake we made that cost us a drone.
I admit this was a stupid thing to do. the question is why did this happened?? I doesn’t seems right to me why it took off, it should’t what so ever.

we had rebooted the drone, and the mission planner also the transmiter, only rebooting the transmitter caused the problem (while not connecting to the laptop).

beeing reckless aside, how to prevent this from happing again? and what made this actually happining?

11

Post your parameter file as requested. This may not not show anything relative to the event but it’s all you have w/o a log.
Your sequence of events plus the fact you were indoors Transmitter at full throttle when you connected the battery if I understand the circumstances.

12

AFAIK we do not continuously try to arm and any attempts to arm with battery disconnected should have been caught by battery voltage arming check. Furthermore pretty much all ESC require 0 signal before spooling up.which should have prevented spool up even in the unlikely event somebody armed with ESC unpowered and they were powered after.arming.