Skirrus

Skirrus turns a natural-language drone job into a traceable flight plan.

Comment

Inspiration

I fly DJI drones using the DJI RC 2, Mini 4 Pro, and Air 3S. Most mission-planning software begins with a blank map and expects the pilot to think like a GIS technician. Real drone work begins differently:

"Inspect this roof."

"Survey this property."

"Create a photogrammetry route for this location."

I built Skirrus to help close the gap between that human description of a job and the detailed flight plan needed to perform it.

AI makes that interaction possible, but a drone route is not something a language model should simply invent. The project became an exploration of a larger question: How can AI make a complex technical workflow approachable without hiding uncertainty or taking ownership of safety-critical calculations?

What it does

Skirrus is a chat-first drone mission planner. A pilot describes a location, desired outcome, aircraft, and optional capture settings in natural language.

Skirrus then:

  1. Interprets the requested mission and its constraints.
  2. Resolves the location using sourced geographic services.
  3. Finds the relevant property or building boundary.
  4. Pauses for operator selection when multiple roof footprints are plausible.
  5. Chooses an appropriate capture and route strategy.
  6. Generates a camera-aware route using deterministic geometry.
  7. Measures route efficiency and conditionally considers alternatives.
  8. Displays the AI decisions, calculations, sources, warnings, and unresolved operator checks.
  9. Exports the reviewed mission as DJI Fly KMZ, Skirrus JSON, or GeoJSON.

The pilot can revise the completed mission conversationally:

"Change the altitude to 150 ft, use a single grid, slow the aircraft to 2 m/s, and switch to the Air 3S."

Skirrus preserves the existing mission context, interprets the revision, regenerates the affected calculations, and presents the updated plan for another review.

Every export remains a planning artifact. Skirrus does not authorize a flight or replace the pilot's responsibility for airspace, obstacles, weather, property access, aircraft condition, and safe operation.

How I built it

The application uses React, TypeScript, Vite, MapLibre GL JS, Node.js, and Express.

GPT-5.6 Sol runs through the OpenAI Responses API using a small set of typed planning tools:

  • resolve_target resolves the requested place and gathers geographic evidence.
  • generate_mission records the model's mission interpretation and planning strategy, then invokes the deterministic planning engine.
  • optimize_route lets GPT select an optimization objective when measured route quality indicates that the initial plan needs review.

The most important architectural decision is the boundary between AI and deterministic code:

GPT selects and revises mission intent. Deterministic code owns coordinates, route geometry, validation, and export.

GPT interprets the requested outcome, extracts constraints, chooses the mission and capture strategy, and explains the result. It never invents coordinates, draws the route, performs camera calculations, approves flight safety, or writes the export package.

Location evidence comes from Google Places, Nominatim, OpenStreetMap Overpass, and Open-Topo-Data. A deterministic TypeScript kernel handles route geometry, camera footprints, photogrammetry spacing, waypoint limits, duration estimates, efficiency measurements, validation, and DJI export generation.

When an initial route contains excessive transit, outside-target travel, or waypoint pressure, GPT can choose what should be optimized. Skirrus then generates and measures deterministic candidate routes. The model chooses the goal; the planning engine proves whether the result is better.

The Plan Inspector makes these responsibilities visible. Its AI Plan view shows what GPT interpreted and selected. Its Evidence view separates model decisions, external geographic data, deterministic calculations, and remaining operator actions.

How Codex helped

I used Codex throughout Build Week as an implementation and review partner. I acted as a PM and gave it guidance of what to build, what to change, etc. Codex helped translate product requirements and field observations into the application architecture, typed Responses API workflow, map interface, geospatial integrations, deterministic mission planner, DJI export system, tests, request hardening, and documentation.

I also used Codex to repeatedly review the working product against the contest criteria. Those reviews exposed meaningful weaknesses, including insufficient visibility into the AI's role, unsafe assumptions around ambiguous addresses, weak route-efficiency evidence, revision-security concerns, and an incomplete judge-facing story.

Codex accelerated implementation, comparison, and verification, but it did not determine the product's safety boundary. I decided which recommendations to accept, rejected or refined generated approaches when necessary, and checked aircraft assumptions against real DJI RC 2 mission data.

Challenges

Turning an address into the correct physical target

A geocoder usually returns a point, not proof that the nearby building is the intended roof. Dense properties can contain several plausible footprints. Skirrus evaluates the available geometry and asks the operator to select the correct building when confidence is insufficient.

This was especially a challenge with larger properties like, Arlington National Cemetery, or Fort De Soto County Park.

Deciding what AI should not control

The hardest engineering problem was not prompt design. It was establishing a trustworthy division of responsibility. Natural-language interpretation benefits from GPT, while coordinates, geometry, camera math, validation, and export require deterministic and inspectable behavior.

Making the AI contribution visible

A chat response alone does not show whether the model made a meaningful decision. Skirrus records the model's target interpretation, capture strategy, constraints, and optimization objective separately from the planning engine's measurements and results.

Producing credible DJI exports

DJI waypoint packages contain aircraft-specific identifiers and behaviors that must be verified carefully. Export support remained blocked until native DJI RC 2 mission files confirmed the required aircraft values for the Mini 4 Pro and Air 3S.

Handling imperfect external services

Geocoding and public map services can be slow, ambiguous, unavailable, or rate limited. Skirrus uses provider routing, caching, throttling, retries, timeouts, request cancellation, and visible source attribution rather than pretending every lookup is equally reliable.

Accomplishments I am proud of

  • A complete, responsive product rather than a disconnected technical prototype.
  • A meaningful GPT-5.6 tool loop whose decisions affect the resulting mission.
  • Human-in-the-loop correction when geographic evidence is ambiguous.
  • Conditional AI-directed optimization backed by deterministic measurements.
  • Inspectable evidence showing who or what owns every planning step.
  • Camera-aware missions for both the DJI Mini 4 Pro and Air 3S.
  • DJI Fly KMZ export profiles verified using native RC 2 mission data.
  • Signed revision tokens, request limits, concurrency controls, cancellation, and explicit timeouts.
  • 130 automated tests, TypeScript validation, and a successful production build.

What I learned

I learned that trustworthy AI products are defined as much by their boundaries as by their capabilities.

A model can make a complex workflow dramatically more approachable without being responsible for every part of it. In Skirrus, AI handles ambiguity in human intent while deterministic software handles mathematical and flight-critical claims.

I also learned that a complete historical chain is part of the product experience. Showing where a boundary came from, why a route changed, and which checks remain unresolved makes automation more useful than an unexplained answer. Builds trust!

Finally, testing against real device artifacts matters. Native RC 2 mission data resolved aircraft-export assumptions that documentation and generated code could not safely answer on their own.

Potential impact

Drone pilots, photographers, inspectors, surveyors, and small teams often understand the job they need to perform but may not have specialized GIS or mission-planning expertise. Huge time-saver!

Skirrus could reduce the time between describing that job and obtaining a reviewable first plan. More importantly, it demonstrates a pattern for operational AI: let the model interpret intent and coordinate tools, but require sourced evidence, deterministic calculations, visible uncertainty, and human approval before action.

What's next

The next step is controlled field validation using imported RC 2 missions and post-flight telemetry. That would allow Skirrus to compare the planned mission with what actually occurred and improve future planning recommendations.

Future work also includes authoritative airspace integrations, richer terrain and obstacle awareness, additional inspection patterns, more aircraft profiles verified from native missions, and a feedback loop that turns completed flights into measurable planning improvements.

Built With

Share this project:

Updates