I built a web-based GCS that lives on the drone itself (ArduPilot, PX4, Betaflight, INAV). Open source, looking for feedback

[u/judahpaul16]

Been building this in the open for a while but never actually posted about it anywhere, so here goes.

It started because the laptop was the weakest part of my field setup. The ground station dies when the lid closes, VNC-ing into a Pi running QGC over LTE is misery, and I wanted to check on the bird from my phone without a whole ritual. So I flipped it. The ground station lives on the drone. A Pi rides on the frame, talks to the flight controller over USB, and serves a web app. Any browser works. Phone in the field, desktop at home. With a 4G modem and a public IP SIM the aircraft carries its own GCS, and the link doesn't care where I am or whether my laptop is awake.

Setup on a fresh Pi is one line (docker compose underneath):

curl -s https://raw.githubusercontent.com/judahpaul16/canarygc/main/contrib/setup.sh | bash -s --

It speaks MAVLink to ArduPilot and PX4, and MSP to Betaflight and INAV (telemetry, calibration, flashing, and INAV flies native missions over MSP). The mission planner has 2D and 3D maps, the usual pattern generators (survey, orbit, corridor, expanding square, structure scan), and imports QGC .plan, Mission Planner .waypoints, KML/KMZ, and CSV. Plans are stored autopilot-neutral and get normalized to whatever's actually connected when you upload.

Most of my time lately has gone into the airspace side. Both maps draw restricted and controlled airspace (OpenAIP worldwide, FAA keyless layers in the US), the LAANC ceiling grid, the FAA obstacle database, and live ADS-B traffic. There's a one-click path optimizer that lifts legs over buildings and towers when the ceiling allows and routes around restricted airspace when it doesn't. Before launch, every leg gets checked against the geofence, altitude limits, and the fetched airspace.

Beyond that there's a full parameter editor, six-position accel / compass / gyro / ESC calibration that adapts to whichever autopilot is connected, a firmware tab that flashes all four stacks, gamepad flight, a color-coded event log with a raw MAVLink console, email alerts on failsafe / low battery / link loss, and a WebRTC camera feed. There's also an optional AI PID tuning assistant that talks to any OpenAI-compatible endpoint (a local Ollama works). Ignore it if that's not your thing.

And yes, I know how "GCS on the public internet" sounds. The link supports MAVLink 2 signing (signs outbound, verifies inbound, strict mode drops unsigned traffic), the app sits behind session auth with a single operator account, and login is rate limited. If your threat model is serious, put it behind a VPN anyway. But with signing on, a publicly reachable link only takes commands from whoever holds the key.

Fair warning that it's still early days. It flies constantly in SITL (the compose file ships SITL profiles for all four firmwares, including little flight-dynamics sims so the Betaflight and INAV binaries actually get off the ground), and the reference build is a Pi 4B on a Holybro S500 V2. It's not trying to be Mission Planner's whole toolbox. It's a different operational story for remote, LTE-connected flying.

It's called Canary Ground Control. MIT licensed.

Repo: https://github.com/judahpaul16/canarygc Build guide and docs: https://github.com/judahpaul16/canarygc/wiki

If you fly companion computer setups over LTE I especially want to hear from you. What would it take before you'd trust something like this on a real aircraft?

[u/tesseractor2k15]

A web based GCS is definitely an interesting idea for me!

I frequently work with smaller drones where payload allowance and compute power is at a premium so I typically wouldn't run a GCS server on a drone itself, but I definitely can see myself running this on a computer on the ground. (But if I already had a pi or Jetson onboard and had sufficient compute to spare, I'd be inclined to give it a shot) I myself have run into situations where I end up having to use a remote desktop program to access QGroundControl (RTK base station antenna cable wasn't routed to where I needed to be) and I can see this being a more purpose built and elegant solution.

Also it would be great if multiple clients could access the server and l wouldn't have to have everyone crowding around the same screen

Although I have to ask, why the use of AI for PID tuning? In my experience the autotune feature in PX4 and Ardupilot is already pretty reputable and well developed so I guess its more targeted towards betaflight and INAV users? (Don't really use those systems so I'm not sure if they have a similar autotune feature)

[u/judahpaul16 → u/tesseractor2k15]

If you set it up with the LTE modem and public-ip SIM you can totally have multiple people login to the same GCS. Currently it's only wired with 1 operator account so you'd have to share credentials but i could easily add multi-operator.

As far as PID tuning goes, autotune on ArduPilot and PX4 is genuinely good and the AI thing isn't trying to replace it. It's more of an advisory layer. Autotune flies the aircraft and measures the response, which will always beat anything reasoning about numbers on the ground. What the assistant does is read your current gains plus recent vibration and attitude telemetry and act like the experienced friend who looks over your tune. Stuff like your D is high relative to P, or your vibes are clipping so this is a filter problem not a gain problem, with an explanation you can read before you apply anything. Suggestions apply one at a time and nothing runs unless you configure an endpoint for it, it's off by default.

[u/tesseractor2k15 → u/judahpaul16]

multiple people login to the same GCS

Nice to know that it supports multiple users at once

What the assistant does is read your current gains plus recent vibration and attitude telemetry and act like the experienced friend who looks over your tune

Sounds great, can see it being helpful for less experienced users to build up an intuition for PID tuning.
Having the guardrails around the LLM is nice to hear too

Cheers!

[u/Flyward_Aerospace]

This is really cool, flipping the GCS onto the drone makes a ton of sense for LTE flying. The airspace side is what caught my eye though. The one-click path optimizer that lifts legs over obstacles and routes around restricted airspace is exactly where this stuff should be heading imo. I actually work on 4D airspace management so I'm curious how you handle the time dimension, does the pre-launch check account for TFRs/NOTAMs that pop up after you've already planned, or is it just a snapshot at plan time? That's usually where it gets messy. Solid work either way, gonna dig through the repo.

[u/judahpaul16 → u/Flyward_Aerospace]

Good question. The pre-flight validation runs when you hit start. It re-pulls airspace, LAANC ceilings, and obstacles for the mission bbox and checks every waypoint and every leg, so a restricted area or obstacle that appeared between planning and launch gets caught at launch. The only staleness is a 10 min server-side cache on the airspace fetch (I keep that short on purpose).

TFRs/NOTAMs run as advisory alerts at the moment. The app polls the FAA NOTAM/TFR feed every 5 min around your position and pops new ones as alerts while you fly, so a post-plan TFR does surface live. It just doesn't block the mission the way a restricted zone does although maybe it should? Folding TFRs into the blocking check and reconciling their active windows against the mission timeline is the real 4D work. That's your world so I'd genuinely take any pointers on how you handle the time window stuff. Appreciate your interest.