u/osamahh9

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.

⚠️ 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.

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.

⚠️ 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 Experts:

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..