OpenDroneKit

Problem

Infrastructure inspection happens where the connectivity is not. A system that assumes a cloud backend is useless on a bridge, a tower or a remote site, which is where the inspections are.

The second problem is trust. An inspection tool that guesses produces reports nobody can act on: a fabricated defect wastes a crew's day, and a missed one is a structural risk. Deciding what the system does when it is uncertain is a design question, not an implementation detail.

What I built

One desktop app covering the whole inspection loop in six steps: plan, fly, reconstruct, detect, measure, report.

• Plan: 22 mission templates, from grid and corridor to facade, tower, wind turbine and orbit, laid out with geofence containment, no-fly detours, altitude bands and terrain-aware AGL or AMSL following
• Export to six autopilot formats: QGroundControl .plan, QGC WPL 110, DJI WPML .kmz, Litchi CSV, KML and GeoJSON
• Fly: MAVLink 2 upload of mission, geofence and rally points to ArduPilot, tested against Copter 4.5.7 in SITL
• Reconstruct: COLMAP structure-from-motion with georeferencing, producing a Cloud-Optimized GeoTIFF orthomosaic, DSM, DTM, hillshade, point cloud and mesh in a real coordinate system
• Detect: trained models mark cracks, corrosion and solar faults for a person to review, each finding stamped with the SHA-256 of the weights that produced it
• Measure: area, perimeter, volume and change against the real DSM and DTM
• Report: HTML, PDF, DOCX and Markdown from the same report sections
• Projects in SQLite, with PostgreSQL and PostGIS optional for multi-user deployments

Architecture

Plan, fly, reconstruct, detect, measure, report, with each stage producing artefacts the next can verify rather than trust. Georeferencing is solved at reconstruction, as a RANSAC Helmert similarity between camera centres and image geotags, so defects and measurements land in world coordinates rather than image coordinates.

Everything runs on the operator's machine: processing, detection, measurement and reporting. Requesting cloud reconstruction runs locally and says so; no imagery leaves the machine.

Refuse rather than fabricate

The governing design rule. Without a model, the AI declines to guess and explains why. Without georeferenced rasters, the report states that measurements are absent rather than printing zeros. A mock flight driver exists for testing and is always labelled SIMULATED in the UI.

A finding keeps the model key, the SHA-256 of the weights and its confidence. The reviewer's decision is stored separately, so review never erases what the model asserted, and a replaced weights file is reported as a mismatch rather than trusted.

Status is computed, not claimed

A capability counts as verified only when the tests it names pass against real inputs, and that status is computed from test results rather than set by hand. The repository tracks 167 capabilities this way.

SITL earned its place: it caught missions putting NAV_TAKEOFF at sequence 0, which MAVLink reserves for home, after every mock-based test had passed.

An inspection, end to end

Each stage produces artefacts the next one can verify rather than trust. The branches are where the system declines to continue, which is the design, not a failure of it.

1. Plan the mission

   One of 22 templates, inside the geofence, around no-fly zones, following terrain.

2. Fly it

   MAVLink 2 to ArduPilot, validated in SITL first.

3. Reconstruct

   COLMAP, then georeferencing so results land in a real coordinate system.

   No CUDA COLMAP, skip dense stereo and say so

   Orthomosaic, DSM, DTM and hillshade that open in QGIS
4. Detect

   Cracks, corrosion and solar faults, each finding tied to the exact weights that produced it.

   No model installed, decline and explain why

   Findings go to a person for review
5. Measure

   Areas, lengths and volumes in metres, not pixels.

6. Write the report

Defect models that ship

Each with its measured score and the weakness that limits it. Three other trained models were rejected rather than shipped, with the reasons kept.

Experiments

Limitations and failure modes

• No Windows installer or tagged release yet; it runs from source with Python 3.11.
• Dense multi-view stereo needs a CUDA build of COLMAP. Without one, dense stereo is skipped and raster resolution drops to what the sparse cloud supports.
• No model has been measured on Indian sites.
• Reading FLIR or DJI thermal JPEGs directly is not implemented on main and is refused with that reason.

Gallery

Attribution

Built by me

OpenDroneKit is mine: mission planning, flight integration, reconstruction pipeline, geospatial outputs, defect models, measurement and reporting.

Based on external research

COLMAP, MAVLink, ArduPilot, SegFormer, YOLO and ResNet are upstream tools and architectures, integrated and trained here rather than authored. Sample imagery is the Aukerman Park dataset from the OpenDroneMap project. Not affiliated with DroneKit or OpenDroneMap.

Experiment performed by me

Model training, evaluation and the rejection decisions across the inspection task families.

Related

• Pushpak Viman

  Finding people under debris, from a transforming drone

• Recalibration-Free Stereo PTU

  Calibration and state estimation for a moving stereo pair