Skip to main content

Drone integration & flight control

Stratumly is a data platform, not a flight-control stack. This page is the boundary statement: what we accept from drone hardware, what we deliberately leave to the drone vendor's tools, and the small set of planning-adjacent hooks that bridge the two.

Stratumly's drone story is passive ingest​

The drone is flown using its manufacturer's tooling: DJI Pilot 2, DJI MSDK apps, Skydio Cloud, AgEagle eMotion, Microdrones mdInfinity, Yuneec DataPilot, Pix4Dcapture, etc. Stratumly receives the captured data after (or during) the flight:

  • Live drone streaming (shipped): the drone (or a vendor SDK on the drone's controller) streams point batches over WebSocket; viewers watch in real time.
  • Post-flight upload: the operator uploads the saved .las / .laz / mesh / orthoimagery via the survey upload flow; the processing pipeline produces a tileset.

Either way, the drone manufacturer owns the flight. Stratumly's value is in what happens after the data lands: storage, processing, AI defect detection, annotation, integration with the asset register, twin sync, compliance reporting.

What Stratumly will not build​

  • Mission planning / waypoint editing. Designing the flight path inside Stratumly.
  • Takeoff / land / abort / RTH commands. Sending control to the drone.
  • In-flight piloting UI. Joystick, camera gimbal control, manual flight mode toggles.
  • Geo-fencing enforcement. Refusing to launch in restricted airspace.
  • Pre-flight checklists tied to airframe state. Battery health, prop attachment, FAA / CAA airspace clearance.
  • Drone fleet management. Battery cycle tracking, hours flown per airframe, scheduled maintenance.
  • Pilot certification / log books. CAA / FAA / EASA commercial-pilot record keeping.

Why not​

  1. Liability. If a mission planner crashes a £30k LiDAR rig into a transmission tower, that's a lawsuit, not a bug report. Drone vendors carry that risk via their own SDKs and certified flight stacks.
  2. Regulated. Active flight control is CAA / FAA / EASA territory: commercial pilot rules, airspace clearance APIs, geo-fencing certification. A different compliance lift to "asset management software".
  3. Hardware-specific SDKs. DJI MSDK, Skydio SDK, AgEagle, Microdrones, Yuneec: each is months of integration. Building competing flight stacks and maintaining them against vendor updates forever is not a fight worth picking.
  4. Customer profile. Utilities, councils, rail, and mining operators typically contract a drone surveyor; they don't fly in-house. The drone surveyor already has tooling they're trained on and expensive to displace.
  5. Competing with the vendor. DJI Pilot 2 is genuinely good. Skydio's autonomous obstacle avoidance is best-in-class. Stratumly would be a third-best option from day one without the airframe leverage to ever close the gap.

What Stratumly does accept​

Three narrow, non-flight-safety hooks that are cheap to build, useful, and compatible with the "after" positioning.

1. Flight-plan import (KML / KMZ / Shapefile)​

The operator (or contracted surveyor) plans the flight in their tool of choice, exports as KML / KMZ / Shapefile, and drops it into Stratumly. Stratumly renders the planned route alongside the captured data on the same map and persists it on the survey row.

  • Endpoint: POST /api/surveys/{id}/planned-route. Multipart KML / KMZ upload; converted and persisted.
  • UI: "Planned route" toggle in the survey viewer's layer panel; renders as a dashed polyline.
info

This hook is on our roadmap; we'll prioritise it when a customer pulls it forward.

2. Coverage reconciliation​

Given a planned route plus actual telemetry, compute and surface the gap. "You planned 2.3 km of carriageway, the drone covered 2.1 km. Here's the missed 200 m." Lives next to the survey on the inspection viewer.

  • Backend: PostGIS ST_Difference(planned_buffer, actual_buffer) over a small buffer of each path (~5 m).
  • UI: small KPI on the survey detail page; the missed segments render as a red overlay layer.
info

Coverage reconciliation depends on flight-plan import (above) and lands alongside it.

3. Pre-flight target tagging (export, not control)​

The operator picks features in Stratumly ("inspect these 12 hydrants") and exports a waypoint file (KML or vendor-specific format) for import into the drone vendor's planner. One-way: Stratumly hands off to the planner; no return path.

  • UI: "Export to flight plan" button on a multi-select of features.
  • Format: KML 2.2 with a Placemark per feature. Vendor-specific exports (DJI WPML, Skydio JSON) are added when a customer explicitly asks.

Frequently asked​

Can you control the drone? No. Stratumly is the data platform. Pair it with DJI Pilot 2, Skydio, or whichever flight stack your surveyor already uses. Many surveyor partners have done this for our existing customers.

Will you build flight control? Not on the current roadmap. We'd consider it if a customer's procurement makes it a hard requirement, but the realistic answer is we'd integrate with their existing flight stack via flight-plan import (above) rather than build our own.