From Detecting Problems to Building Routes: Where We Are on Auto-Generated Missions

[Mission-analyzer]

A few weeks back we wrote about the tangent-graph method Mission Analyzer uses to detour a route around populated areas. That post ended with a specific claim: the same geometry that reshapes an existing leg should, in principle, generalize to building a route from scratch — give it a takeoff point and a landing point, get a complete mission back.

That's still the goal, not a shipped feature. This post is about what's changed since then, and — just as importantly — what's still missing before "two points in, mission out" is something we'd actually recommend using.

The part that was already true

optimize_leg(), the function that finds the shortest path around obstacles between two waypoints, doesn't know or care whether those two waypoints are adjacent legs in an existing mission or the very first and very last point of a flight. It treats them as a pair of
coordinates and a graph to build. We said as much when we wrote it: building a mission from a takeoff point and a landing point is the same call, just with one very long "leg" instead of many short ones.

That was true then and it's true now. What's changed is that several of the other pieces such a from-scratch route would need have gone from "doesn't exist" to "exists and is tested."

What's been built since

Aircraft profiles. A from-scratch route needs to know what the airframe can actually do — cruise speed, how tightly it can turn, how fast it climbs and sinks. That data used to live nowhere; it's now a proper profile, filled in once, with the turn-radius and climb/sink figures pulled from the same ArduPilot TECS parameters the autopilot itself tunes on. That's not a new capability for this problem, but it's a piece the problem genuinely can't be solved without, and it didn't exist before.

Wind sampled across the flight, not just at departure. The optimizer's fuel and turn-radius checks assume constant airspeed
through still air — reasonable for checking a route, less reasonable for choosing one. We now pull wind forecasts at several points along a route, timed to when the aircraft is actually expected to be there, not one number borrowed from takeoff and stretched across the whole flight. This doesn't feed into route selection yet — right now it's a display layer, not a cost function — but it's the first piece of infrastructure a wind-aware router would need, and it's the harder half of it: getting the right forecast for the right place and time.

A settlement is a circle; a mission is any shape. This part isn't new, but it's worth restating because it's the part that makes the rest
possible. A safety exclusion zone doesn't care whether it's placed inside a 600 km transit route or between a takeoff point and a landing point 3 km away — it's a circle the path has to clear. That's already proven out on the settlement-avoidance case, on real data, at real distances.

What's still missing

Being direct about this matters more than the progress above.

Terrain isn't an obstacle to the router — it's an afterthought check. Right now, elevation gets verified after a path exists, by
walking the SRTM profile along it. For a route built from just two points, terrain needs to be a forbidden zone the pathfinder actively
routes around, the same way a settlement is — not something checked once the geometry is already decided. That's a different data
structure than a circle on a map, and we haven't built it.

No airspace data at all. Populated areas come from OpenStreetMap. Restricted airspace, danger areas, and aerodrome control zones come from an entirely different kind of source — and right now, from none. A route generated from two points with no awareness of airspace isn't a serious tool, it's a demo.

Altitude is interpolated, not planned. Detour points currently get an altitude by blending the terrain height under them with the
average height-above-ground of their neighbors. That's a reasonable patch for a short detour. A full route needs an actual climb-cruise-descent profile, coordinated with both the terrain obstacles above and the turn physics already in place — not a number borrowed from whichever two points happen to be nearby.

Wind informs the display, not the path. Having the forecast at the right place and time is necessary but not sufficient — the router
still optimizes for geometric distance. Making it optimize for time or fuel under a real wind field is a separate piece of work from having the wind data in the first place.

This is a transit-planning idea, not a mission-planning one. Two points and a straight-line-equivalent shortest path make sense for
"get this aircraft from A to B." They make no sense for a mapping grid, a search pattern, or anything else where the shape of the coverage is the point of the flight. That's a permanent scope boundary, not a gap to close later.

Where that leaves us

Every piece above is either fully reusable as-is (the tangent graph), partially there (wind data exists, wind-aware routing doesn't), or not
started (terrain-as-obstacle, airspace). None of it is close enough to call "two points in, mission out" a near-term feature. But the list of
what's missing is shorter and more concrete than it was when we first floated the idea, and that's really the only thing worth reporting this time.