r/ardupilot

Hi, I'm wondering if there's a simple plug n play RTK solution for pixhawk? Something that I don't have to set up a base station etc...

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.

This project builds a GPS-denied navigation system for a drone using a Raspberry Pi 5. A known GPS coordinate is captured once at the start as the origin. From there, a downward-facing camera tracks ground features frame by frame to measure how far and in which direction the drone has moved. A laser rangefinder provides real-time altitude to correctly scale those pixel measurements into real-world distances. The drone's compass continuously provides heading so the camera's displacement measurements are correctly oriented to North and East. The flight controller's gyroscope runs at high frequency between camera frames to detect and cancel out any false motion caused by the drone rotating in place, preventing yaw from accumulating as position error. All of this camera displacement, compass heading, gyroscope data, and altitude is fused into a continuously updated position estimate. That position is added to the origin coordinate every cycle to produce a current latitude and longitude, which is sent as standard GPS data at 5Hz directly into the Pixhawk's GPS port. ArduPilot accepts it as a real GPS signal, shows a full GPS fix in Mission Planner, and correctly plots the drone's live trajectory on the map with no real GPS involved.

https://preview.redd.it/xecg3j5p7wah1.png?width=2980&format=png&auto=webp&s=b63a3264f81fb43b48adcf96149cc33eae7b04ff

Hi all,

I wanted to share a project we’ve been working on: ArduConfigurator, a browser based configuration tool for ArduPilot.

Site: https://arduconfigurator.com
Source: https://github.com/j-w9/arduconfigurator

The goal is to make ArduPilot setup feel closer to Betaflight Configurator: a guided, configuration first experience rather than a raw parameter editor or a full ground station. Things like ports, receiver, outputs, power, OSD, and VTX are laid out as a walk through setup flow instead of being scattered across menus or buried in the parameter list, so getting a vehicle configured is much more approachable. It also handles firmware flashing.

The aim is that you can take a copter from flashing to flying without needing Mission Planner or QGroundControl, though it works for configuring other ArduPilot vehicles too.

It runs in the browser over Web Serial with no install, and there are installable desktop builds with native serial if you’d rather work offline.

The project is still new and under active development, so feedback, bug reports, and feature ideas are all welcome. The GitHub repo above is the best place for issues and contributions.

This is a joint effort with jb-01 (https://github.com/jb-01), co-developer on the project.

Thanks for taking a look, and we’d love to hear what you think.

Hello! I've been wondering how would one try and port ardupilot to another RTOS that is not chibiOS. In your opinion, would that be feasible? In what timescale?