Drone Grid open-source cloud system for operation of PX4 drones

Spotlight
1

Hello, PX4 community!

I’m reaching out for feedback on my open-source project, Drone Grid: a cloud platform for flying PX4 multirotor UAVs over the internet from a web browser, with live WebRTC video, telemetry and manual control.

Detailed documentation lives on the docs.drone-grid.com subdomain.
Code: GitHub - radodim/drone-grid: An open-source cloud platform for operating drones in near real time. · GitHub

How it works with PX4:

Drone Grid system architecture

The companion computer (Raspberry Pi 3B with 4G modem) runs a python MAVSDK service that reads manual control input from the Drone Grid cloud system over a secure websocket channel and streams it (over ethernet) to the Pixhawk 6X running PX4. The telemetry, visualized in the browser HUD, is streamed back over the same websocket connection. The kill-switch mechanism in the diagram lets the safety RC pilot take over instantly by shutting down the companion, and losing the RC link does the same, so PX4’s RC-loss failsafe takes over.

The full-size diagram, the safety recommendations and the kill switch principle of operation are all in the docs - I would paste them but I can’t add more than 5 links as a new user.

Flight log: this is the flight from the video on the landing page (first link above). The drone was flown entirely through Drone Grid, with a backup RC pilot ready at all times to take over via Drone Grid’s kill-switch mechanism.

Hardware: Holybro X650 dev kit (Pixhawk 6X) and a Raspberry Pi 3B companion with a 4G modem or an old phone as a Wi-Fi hotspot. Click the photo for the build guide.

Drone Grid X650 build

What I’d appreciate to hear from you:

  • What would you improve or do differently, whether in the architecture, the safety design or the docs?
  • Is there real interest in something like this? Would you use it, and for what?

Want to try it? The hosted instance (linked from the landing page) is open for registration. You can also fly a simulated drone locally with PX4 SITL and Gazebo (my first open-source commit, #27178, was related to this); the quick start is on the docs home page.

Provided there is interest, I would like to extend the system with autonomous capabilities, GIS, and support for more hardware. It’s a one man show so far, so contributors are welcome.

This project stands on the shoulders of giants, namely the work of the PX4 and Dronecode community, for which I am very grateful.

P.S. I’ll be in Prague for the PX4 Developer Summit and look forward to meeting some of you. Happy to talk about the project and hear about your work as well.

Best regards,
Rado Dimanov

2

Hi Rado,

Interesting project, particularly the separation between browser-based control, the cloud service, the MAVSDK companion and PX4.

One area I would be interested in exploring is incident reconstruction across those boundaries.

For an internet-operated vehicle, the PX4 ULog can explain much of what happened onboard, but reconstructing the complete sequence may also require evidence from the cloud and companion computer.

For example, it would be useful to distinguish:

  • When a control command was generated in the browser.

  • When it reached the cloud and companion.

  • When the corresponding command or setpoint was transmitted to PX4.

  • What PX4 actually received and executed.

  • Whether a subsequent state transition was caused by command rejection, communication loss or an onboard condition.

Have you considered recording a correlated, timestamped event trace across these components, with explicit clock synchronization and uncertainty information?

That could be particularly useful when investigating intermittent network conditions or unexpected transitions between remote control, RC takeover and PX4 failsafe behaviour.

I’m working on reproducible PX4 incident reconstruction, so I’d be interested in discussing whether a small SITL-based validation scenario could help establish these evidence boundaries.

Nice work on making the project open source.

3

Hi, Yigitcan,

thank you for your interest!

what you’re proposing sounds really useful for troubleshooting Drone Grid issues and accurately measuring control latency.
I think everything up to “What PX4 actually received and executed” is relatively straightforward but I need to look into what would be the best way to correlate the events with the PX4 ulog, more specifically what MAVSDK tools I can use for this.

I am open to discussing and trying the SITL-based validation scenario you’re proposing as well.
I’ll also take a look at your PAMIR project, it sounds interesting.

4

Hi Rado,

Thanks I think keeping the first experiment small would be the best approach.

Rather than trying to solve full cross-system correlation immediately, we could start with one reproducible SITL scenario and establish exactly what evidence is available at each boundary.

For example:

Browser command → Drone Grid/cloud timestamp → MAVSDK send/acknowledgement → PX4-observable event/state → ULog

A simple first test could be:

  1. Run PX4 SITL with Drone Grid.
  2. Generate one clearly identifiable command/event from the browser.
  3. Record timestamps at the Drone Grid and MAVSDK boundaries.
  4. Identify the corresponding PX4 event/state change in the ULog.
  5. Repeat under an introduced network delay or interruption.

Before adding any new instrumentation, we can first determine how much of this chain can already be reconstructed from the data both systems produce.

I also wouldn’t assume that a MAVSDK acknowledgement means that PX4 actually executed the intended state change keeping command issued, command accepted, and observed execution as separate events would make the experiment more useful.

If you’re happy with that scope, I can define a minimal validation matrix and the evidence fields we should compare, and we can use that as the starting point.

Thanks for taking a look at PAMIR as well.

5

Hi Yigitcan,

Apologies for the late reply, balancing work with side projects can be challenging, as I’m sure you know.

I agree with the scope. I’ve created a GitHub issue in the Drone Grid repo where we can continue:

If you’d like to add the validation matrix there, that would be appreciated.