OpenDroneKit

Facts

One fact per line, each linked to the line in the repository it comes from, or marked as the owner’s dated statement. If anything elsewhere disagrees with this page, this page is the one that was checked.

Updated 2026-10-02Checked against main@1ef6351 (2026-09-01) · facts.md

What OpenDroneKit is

  1. OpenDroneKit is an open-source, offline-first drone inspection and GIS toolkit for Windows.

    README.md#L5
  2. It plans inspection missions, flies them over MAVLink, reconstructs the imagery into georeferenced products, detects defects, measures them and writes the report, in one desktop app.

    README.md#L5
  3. Outputs land in a real coordinate reference system and open directly in QGIS.

    README.md#L9
  4. OpenDroneKit is written as one word. It is not affiliated with DroneKit (dronekit.io, the Python MAVLink SDK from 3D Robotics) or with OpenDroneMap.

    Owner statement, 2026-10-02
  5. It is built by Prabal Khare. Source code: github.com/00PrabalK00/OpenDroneKit.

    Owner statement, 2026-10-02

Price, licence and availability

  1. OpenDroneKit is free: no account, no licence key and no paid tier.

    Owner statement, 2026-10-02
  2. The owner chose the MIT License (copyright 2026 Prabal Khare) on 2026-10-02. As of commit 1ef6351 (2026-09-01) the LICENSE file is not yet on the public main branch, so GitHub shows no licence for the repository.

    Owner statement, 2026-10-02
  3. There is no Windows installer and no tagged release as of 2026-10-02. OpenDroneKit runs from source: clone the repository, create a Python 3.11 environment and run pip install -r requirements.txt.

    Download page
  4. It needs Python 3.11 or newer, pip and Git; everything else is a Python package.

    docs/INSTALLATION.md#L11
  5. It is developed and tested on Windows and Linux. On Windows the desktop shell uses the built-in Edge WebView2; there is no bundled browser and no Qt dependency.

    docs/INSTALLATION.md#L86
  6. No GPU is required. A GPU matters only for dense reconstruction (a CUDA build of COLMAP) and for training models.

    docs/INSTALLATION.md#L71
  7. Model weights are not stored in the Git repository.

    README.md#L135

Mission planning

  1. The planner offers 22 mission templates, derived from its alias table by available_templates(): grid, double_grid, corridor, solar_inspection, magnetic_mapping, smart_adaptive, roof_inspection, facade, facade_mapping, multi_facade, box_inspection, tower_mapping, wind_turbine, dome_inspection, orbit, closed_loop, linear_inspection, lateral_capture, waypoints, panorama, bubble_360, linked_mission. (The README on main still says 16.)

    mission/planner.py#L277
  2. Missions are laid out with constraint geometry: ray-cast geofence containment, no-fly polygons with segment-level detours, altitude bands, stand-off and return-to-home rules.

    README.md#L14
  3. Terrain-aware planning follows AGL or AMSL using a GeoTIFF, an ESRI ASCII grid, CSV samples or a fitted plane.

    README.md#L19
  4. Missions export to six formats: QGroundControl .plan, QGC WPL 110 .waypoints, DJI WPML .kmz, Litchi CSV, KML and GeoJSON.

    mission/exporters.py#L706
  5. The exporters on public main have known defects that the development branch fixes or still carries; each format page lists them.

    Mission file formats

Flight

  1. Flight control is MAVLink 2 to ArduPilot. Mission, geofence and rally upload use the request/ack transfer protocol and land in the correct mission slot; gimbal, yaw, dwell and camera-trigger items survive an upload/download round trip.

    README.md#L125
  2. DJI and Litchi aircraft are supported by export only: the file is flown with their own apps.

    mission/exporters.py
  3. A mock flight driver is selectable and is always labelled SIMULATED in the UI.

    README.md#L126
  4. Flight code is tested against ArduPilot Copter 4.5.7 in simulation (SITL). As of 2026-10-02, run locally in Docker, two of three SITL flight tests pass; the third (home position reporting) exposed a bug that is being fixed.

    Owner statement, 2026-10-02
  5. SITL caught missions putting NAV_TAKEOFF at sequence 0, which MAVLink reserves for home, after every mock-based test had passed.

    README.md#L122

Reconstruction

  1. Reconstruction uses COLMAP structure-from-motion with bundle adjustment, camera intrinsics from an EXIF sensor database, and georeferencing solved as a RANSAC Helmert similarity between camera centres and image geotags.

    README.md#L26
  2. It outputs a Cloud-Optimized GeoTIFF orthomosaic, DSM, DTM and hillshade, plus a point cloud (.ply), a Poisson mesh (.ply/.obj) and a camera-track GeoJSON.

    README.md#L29
  3. The UTM zone is chosen automatically from the mean position of the images' geotags (EPSG 32600 + zone in the north, 32700 + zone in the south); an explicit EPSG code can be passed instead.

    core/geo.py#L317
  4. Dense multi-view stereo needs a CUDA build of COLMAP. The pycolmap wheels are CPU-only, so without one dense stereo is skipped, raster resolution drops to what the sparse cloud supports, and the run says so.

    README.md#L107
  5. On the public OpenDroneMap Aukerman survey, main's README records 77 of 77 images registered, 1.27 px mean reprojection error and 1.22 m georeference RMSE in EPSG:32617. The homepage figures (1.255 px, 1.12 m) come from a later run of the development branch.

    README.md#L105
  6. Cloud reconstruction is not implemented. Requesting it runs locally and reports that it did; no imagery leaves the machine.

    README.md#L124

Defect models

  1. crack_segmentation (SegFormer-B5 (run crack_segformer_b5, 40 epochs)): IoU 0.637 on the held-out test, threshold 0.85 split. Known weakness: At 0.85 thin and faint cracks are missed, so an empty mask is not evidence of a sound surface.

    docs/features/registry.py#L737
  2. corrosion_severity_segmentation (SegFormer-B2 (run corrosion_segformer_b2_cs, 80 epochs, log-inverse class weighting)): Severe-pixel recall 0.788 on the validation split. Known weakness: Errors are almost entirely between adjacent grades: of the 653,071 severe pixels it recovers 514,827 (recall 0.788) and loses 124,241 of the rest to 'poor', one step down. A reported grade can be one step optimistic.

    docs/features/registry.py#L764
  3. solar_cell_defect_detector (YOLO11l (run pvel_ad_yolo11l, 60 epochs)): mAP50 0.8835 on the validation split. Known weakness: EL cell-level imagery only (module manufacturing and lab inspection). It is not an aerial or thermal model and must not be applied to drone photographs of installed panels.

    models/model_registry.json#L143
  4. solar_thermal_anomaly_classifier (ResNet18 (run solar_thermal_cls, 26 epochs, early-stopped)): Balanced accuracy 0.724 on the validation split. Known weakness: Soiling is the weak class at 0.367 recall and 0.344 precision on 30 validation samples: roughly two in three soiled modules are missed, and a third of soiling calls are wrong.

    models/model_registry.json#L165
  5. A model's finding keeps the model key, the SHA-256 of the weights that produced it, and its confidence; the reviewer's decision is stored separately, so review never erases what the model asserted.

    docs/features/registry.py#L843
  6. The installed weights file is hashed at load and compared with the registry; a replaced file is reported as a mismatch, and a model with no recorded digest is reported as unrecorded, never as verified.

    README.md#L117
  7. No model has been measured on Indian sites.

    README.md#L116
  8. Three trained models were rejected rather than shipped, with the reasons kept: an RGB solar panel-condition detector, a corrosion detector and mine change detection.

    docs/features/registry.py#L758

Measurement and reports

  1. Area, perimeter, volume and change are computed against the real DSM and DTM. Volume is verified to 0.00 m³ error against an analytic test surface.

    README.md#L123
  2. Without georeferenced rasters the report states that measurements are absent rather than printing zeros.

    README.md#L123
  3. Reports are written as HTML, PDF, DOCX and Markdown from the same report sections.

    core/report_formats.py#L1

Offline and data

  1. Processing, detection, measurement and reporting run on the operator's machine.

    README.md#L124
  2. Projects are stored in SQLite with geometry as GeoJSON text; PostgreSQL with PostGIS is optional, for multi-user deployments.

    docs/INSTALLATION.md#L69
  3. Basemap tiles can be cached for offline use (the Hub's Offline tiles panel on main).

    app/web/hub.html#L35
  4. Thermal temperatures are computed from radiometric counts plus the camera's Planck constants. Reading a FLIR or DJI thermal JPEG directly is not implemented on main and is refused with that reason.

    core/thermal.py#L244

How status is measured

  1. A capability is only 'verified' when the tests it names pass against real inputs. Status is computed by tools/feature_status.py from test results, never set by hand.

    docs/features/registry.py#L3
  2. docs/FEATURES.md on main tracks 167 capabilities: 163 verified, 0 implemented, 2 in progress, 2 not started. It was computed on a machine with trained weights installed; a run without weights reaches a lower verified count.

    docs/FEATURES.md#L9
  3. OpenDroneKit has published no user counts, customer names, testimonials, ratings or benchmarks against other products; this site does not claim any.

    Owner statement, 2026-10-02