ArduDeck: open-source cross-platform GCS, PX4 support just landed, looking for testers

[rubenCodeforges]

Hey guys, I’m the developer of ArduDeck, an open-source ground control station. I’ve recently added PX4 support and I wanted to ask for your help testing it. The app runs on any platform (Mac, Windows, Linux), and if testing goes well and the support stabilizes in the desktop app, I’ll bring it to the mobile app as well (Android and iOS).

Honest status first: the PX4 support is experimental. The full flow works against PX4 SITL, but it has not seen real PX4 hardware yet, which is exactly why I’m here.

Here is a PX4 quad flying a mission in it, with the instruments docked on the map:

The flight modes are PX4’s own vocabulary, not translated ArduPilot ones:

What’s in it today:

• Automatic PX4 detection: PX4 flight modes decoded and commandable in PX4’s own vocabulary (Position, Hold, Mission, Offboard, and the rest, no translated ArduPilot names), prearm and preflight failures translated into plain hints
• Configuration: airframe picker, actuator outputs with motor test, RC and flight-mode slots, battery, safety and failsafes, backed by bundled PX4 parameter metadata with correct parameter typing
• PID tuning schemes for multicopter and fixed wing
• ULog: a native parser feeding the log explorer, health checks, and a map flight trace, with the log format detected automatically
• In-app PX4 SITL using the built-in SIH simulator, so you can try all of the above without hardware in about two minutes

Parameters come with PX4 metadata, typed correctly (int vs float), searchable with regex:

And the built-in PX4 SITL launcher, so testing needs no hardware at all:

Since this is probably the first time most of you see ArduDeck, a quick word on the rest of the app, all of it works with PX4 connected. The telemetry screen is built around the map with the instruments docked directly on it (that is the first screenshot above), there is a catalog of instruments with live previews, multi-vehicle flying, and a HUD widget for EdgeTX radios built visually in the app. And missions can be previewed before upload: a gizmo flies the plan on the map with a live camera cone, on a scrubbable timeline:

What would help me most:

1. Connect a real PX4 vehicle (USB or telemetry) and tell me what breaks: wrong parameter values, modes that refuse to switch, anything that looks off
2. Run through the config tabs against QGC side by side and flag any disagreement
3. Open a ULog from a real flight and check the analysis against what you know happened

More about the app: ArduDeck Beta 1.1: The Map Is the Cockpit - ArduDeck Blog
Download: Releases · rubenCodeforges/ardudeck · GitHub
Issues and reports: Issues · rubenCodeforges/ardudeck · GitHub

I’ll be in this thread. Thanks for any time you throw at it.

[yigitcan-ozturk]

Nice project the native ULog path is especially interesting.

One test I’d suggest is to validate the log explorer against a flight where the visible failure is not the original cause.

In other words, instead of only checking whether ArduDeck shows the final failsafe or mode change correctly, compare whether the timeline preserves the earlier sequence:

sensor / estimator anomaly → control response → mode/failsafe transition → final vehicle behaviour

A useful validation case would include:

• one known-good flight;
• one failing flight from the same vehicle/configuration;
• the same signals plotted side by side;
• identification of the earliest meaningful divergence before the final failure.

That would test not only ULog parsing correctness, but whether the analysis view is useful for actual incident reconstruction.

I’d also be interested in checking:

• timestamp consistency across topics;
• estimator reset / innovation events;
• flight-mode transition timing;
• actuator/control-allocation response;
• whether missing or lower-rate topics are made explicit rather than silently interpolated.

If you want, I can test the ULog analysis path against a real PX4 incident pair and report any discrepancies I find.

[rubenCodeforges]

Yes that is exactly how the ardupilot community is doing it , they share feedback, bug reports, suggestions etc. and i fix/implement them. With px4 its a bit harder , because it is not that wide spread , therefore i decided to post here.

[yigitcan-ozturk]

Understood in that case I’m happy to help with the PX4 side.

I’ll focus first on the ULog analysis path, since that is where I can give you the most useful feedback.

Rather than testing only whether a log opens correctly, I’ll use a known PX4 incident and compare what ArduDeck presents against the underlying ULog timeline estimator state, mode transitions, control response and the earliest observable divergence.

If I find a parsing issue, missing signal, misleading interpretation or useful analysis feature, I’ll report it as a reproducible GitHub issue rather than just posting general feedback here.

I think that should give you a useful first PX4 validation case.

[rubenCodeforges]

Awesome and thanks for the professional approach

[yigitcan-ozturk]

Thanks Ruben appreciated. I’ll work from a known PX4 incident first and come back with reproducible findings rather than general feedback.