UAV surveyAerospace & marine

Al-Batinah UAV LiDAR survey

Plan and optimise a LiDAR drone-fleet survey of a 500 × 500 m site in Oman — tune the mission to your fleet, drone and sensor specs, then drive an optimal mission against a simulated UAV fleet on an animated map.

DjiniousLabModelling & simulation

An animated mission map of three UAVs flying a LiDAR survey of a 500-metre square near the Al-Batinah coast of Oman, with their flight paths and a mobile base marked over an OpenStreetMap basemap

survey area (Al-Batinah, Oman): 500 × 500 msurvey area (Al-Batinah, Oman)
concurrent fleet at the optimum: 3 UAVsconcurrent fleet at the optimum
optimal mission makespan: 5.8 minoptimal mission makespan
selectable objectives: 3selectable objectives
makespan, 1 → 6 drones: −34%makespan, 1 → 6 drones
base-to-area transit (charged to endurance): ~2.3 kmbase-to-area transit (charged to endurance)

Plan the mission. Optimise the fleet. Fly it — in simulation.

A LiDAR survey of a 500 × 500 m site near Al-Batinah South, Oman, taken from a brief to an optimal, flyable mission entirely in DjiniousLab. Drone, LiDAR and fleet specs drive a coverage plan; an optimiser tunes altitude, speed and fleet allocation to whatever you care about — fastest, fewest battery swaps, or highest resolution; a Python mission then commands a simulated UAV fleet, replayed on an animated map. Six notebooks, one workflow, all on the worker.

From a site brief to a flyable mission, in six steps.

Each step is a Python notebook running on the DjiniousLab worker — numpy/scipy for the planning maths, Plotly and Leaflet for the maps. Nothing is hard-coded: change a spec and the whole mission re-plans.

Site & datum

The 500 m survey box and a mobile launch base are pinned in WGS-84 over the real Al-Batinah coastline. A local east-north metre frame (equirectangular at the site latitude) carries all the geometry; base-to-area transit comes out at ~2.3 km — and it is charged against every sortie's endurance.

Drone & LiDAR spec model

Cruise/scan speed, battery endurance and turnaround for the drone; field-of-view, point rate and minimum altitude for the LiDAR. Ground swath = 2·h·tan(FOV/2) and point density = rate / (swath · speed) fall straight out — so altitude and speed trade coverage against resolution.

Coverage path

A boustrophedon (lawnmower) path tiles the box at the swath spacing implied by the chosen altitude and overlap. At 60 m and 20 % overlap that is an 84 m swath, ~8 lines and a 4.5 km scan path — the raw work the fleet has to share.

Fleet allocation & optimisation

The strips are split into contiguous bands flown concurrently, so adding drones genuinely cuts the makespan. A sweep over altitude, speed, overlap and fleet size finds the optimum for the chosen objective — and shows the trade: makespan drops 34 % going from one drone to six.

Python mission → simulated fleet

The optimal plan becomes a per-drone waypoint program. A pure-Python driver commands a simulated remote fleet — arm, take off, go-to, scan, return — streaming live telemetry and a progress bar. The radio link is faked; the command structure reads exactly like the real thing.

Animated mission map

The telemetry timeline replays on an OpenStreetMap basemap: three UAVs launch from the base, transit, scan their bands concurrently and return, with a play button and time-scrubber over 48 frames. The headline artefact a planner can actually watch.

A DjiniousLab notebook rendering a grayscale Leaflet map of the Al-Batinah coast, with the 500-metre survey square, the mobile base, and the transit line between them — Step 1 — the site. The 500 × 500 m survey box and the mobile base pinned over the real Al-Batinah South coastline, with the ~2.3 km transit leg the fleet pays on every sortie.

Specs in, mission out — change one number and re-plan.

The mission is a function of the hardware, not a fixed plan. The drone's endurance sets how much of the survey fits in one sortie; the LiDAR's field-of-view and point rate set how wide each pass is and how dense the returns are; altitude and speed trade the two off against each other. Because every downstream step reads these specs, swapping in a different drone or sensor — or relaxing the overlap — re-derives the swath, the path, the sortie count and the optimal fleet automatically. The plots below are the levers a planner actually turns.

Ground swath grows linearly with altitude; point density falls with altitude and speed.

Endurance minus the ~2.3 km round-trip transit sets the per-sortie scan budget.

Overlap, altitude and speed are the continuous knobs the optimiser sweeps.

Two Plotly charts: ground swath increasing linearly with altitude, and LiDAR point density decreasing with flight speed — Step 2 — the spec model. Swath widens with altitude (left); point density thins as the drone flies faster (right). These curves are the trade-offs the optimiser searches.

A Plotly plot of a boustrophedon lawnmower flight path tiling the 500-metre survey square in east-north metres — Step 3 — the coverage path. A boustrophedon lawnmower tiles the box at the swath spacing — ~8 lines and a 4.5 km path at 60 m altitude with 20 % overlap.

One model. Three objectives. You choose what 'optimal' means.

The same plan can be optimised three ways: minimise mission time (makespan), minimise battery sorties, or maximise LiDAR resolution within a time budget. The fleet flies concurrently — strips split into contiguous bands — so the makespan objective genuinely rewards more drones, while the resolution objective drives the altitude down at the cost of time. A sensitivity sweep over fleet size and altitude makes the trade visible, so the choice is an engineering decision, not a guess.

Concurrent banding: makespan = the busiest drone's wall-time, so a bigger fleet finishes sooner.

Makespan falls from 8.0 min (1 drone) to 5.3 min (6 drones) at the time-optimal altitude.

Resolution-first pushes altitude to its floor — higher point density, longer mission.

Two Plotly charts: mission makespan decreasing as fleet size grows from one to six drones, and makespan versus altitude — Step 4 — the sweep. Makespan against fleet size (left, decreasing as drones are added) and against altitude (right) — the levers that turn a fleet and a sensor into an optimal mission.

Three objectives, three missions.

The same 500 m survey, optimised three ways for the default UR-class fleet. Minimising time flies high and fast; maximising resolution flies low and slow. (Here, fewest-sorties and best-resolution coincide at the altitude floor.)

Minimise mission time

Altitude: 75 m · Mission time: 5.8 min · LiDAR density: ≈159 pts/m²

Fewest battery sorties

Altitude: 30 m · Mission time: 13.0 min · LiDAR density: ≈1 322 pts/m²

Maximise resolution (≤ 90 min)

Altitude: 30 m · Mission time: 13.0 min · LiDAR density: ≈1 322 pts/m²

An animated Plotly map over OpenStreetMap showing three UAV flight paths from a mobile base across the survey square, with a play button and time slider — Step 6 — fly it. The optimal mission replayed on an animated map: three UAVs launch from the base, scan their bands concurrently and return, with a play button and a 48-frame time-scrubber.

A planning digital twin, not a flight system.

Everything here is simulation. The UAV fleet is faked — there is no radio link or autopilot; the Python driver mimics a real go-to/telemetry command interface but talks to a stub. The flight model is planning-grade: flat ground, no wind, a simplified energy budget, and an optimum found within the swept parameter ranges. What it is good for is exactly what a mission planner needs before anyone flies: sizing the fleet, choosing the altitude and speed, and seeing the time/resolution trade-off — on a real site, with your own drone and sensor numbers, in minutes.