Mission Planning for High-Precision Drone Inspections

Why building a mission planner for substations had little to do with maps—and everything to do with safety, repeatability, and engineering constraints

When I first started building mission planning software for substation inspections, I thought the hard part would be making the drone fly autonomously.

What I didn't realize at the time was that this would probably be the easiest part.

The real challenge wasn't flying—it was making sure we could fly the same mission over and over again.

At the time, I was working on software for substation inspections. Unlike large mapping missions where a few meters of error might go unnoticed, these inspections happened incredibly close to energized equipment. Sometimes the drone was flying less than half a meter from transformers, disconnectors, or busbars.

There wasn't much room for improvisation.

Every mission had to be predictable.

Every movement had to be intentional.

And, perhaps most importantly, every inspection had to be repeatable months later. The real value wasn't a single flight—it was being able to compare the same asset over time.

One of the first questions people usually ask is whether we planned everything virtually.

We didn't.

I remember early on thinking that we'd somehow recreate the entire substation inside the planner.

It didn't take long to realize how unrealistic that was.

Substations are complex three-dimensional environments. Structures overlap, clearances are tight, and there are countless obstacles that don't show up in satellite imagery or CAD drawings.

On top of that, every inspection had to respect operational procedures and aviation regulations. The software wasn't just planning a path through space—it had to help operators execute inspections that were both safe and compliant.

So we took a different approach.

Instead of trying to model the environment beforehand, we let experienced pilots teach the software what a good inspection looked like.

The pilot would fly the inspection manually while the software continuously recorded the drone's position, aircraft orientation, gimbal orientation, camera settings, and every action that mattered.

That recording became the mission plan.

At the time, it felt like an elegant solution.

Let humans decide where to fly.

Let software make that flight repeatable.

It sounded almost obvious.

It didn't stay that simple for very long.

One of the first things I learned was that recording coordinates wasn't enough.

If the drone ended up even slightly displaced during a future inspection, the framing changed. Sometimes only a little. Sometimes enough that the exact component we wanted to inspect wasn't framed the same way anymore.

That might not sound like a big deal until you remember why we were collecting these images.

We weren't trying to take beautiful pictures.

We were trying to build a consistent historical record.

Every inspection needed to look as much like the previous one as possible.

That's when it clicked for me.

Repeatability, not autonomy, was the real objective.

That realization also changed the way I thought about positioning.

I still remember a conversation with our lead pilot, Grubert.

He was the one who first pushed for RTK and, more importantly, explained why it mattered.

Until then, I mostly saw RTK as another positioning feature. A nice improvement over standard GPS.

He walked me through how the inspection team actually worked in the field.

Why they relied on RTK.

What could go wrong if positioning wasn't reliable.

And why that wasn't just a navigation problem—it affected whether an inspection could be trusted at all.

That conversation completely changed how I looked at it.

RTK wasn't a feature.

It was a system requirement.

And once something becomes a requirement, I don't think it should rely solely on the operator remembering to check it.

It becomes the software's responsibility too.

One of the earliest safety mechanisms we added was deceptively simple: the mission wouldn't start unless RTK was healthy.

That sounds obvious now.

It definitely wasn't obvious then.

I remember the discussions we had around seemingly simple questions.

Should the operator be allowed to override the warning?

What if RTK disconnected halfway through the flight?

What if corrections were temporarily lost?

Do we pause?

Abort?

Keep going?

Those questions had surprisingly little to do with drones.

They were software design questions.

The hardware could tell us what was happening.

It couldn't decide what should happen next.

That responsibility belonged to the application.

Somewhere along the way, I realized we weren't just building navigation software anymore.

We were encoding operational procedures into software.

That felt like a subtle shift at the time.

In practice, that realization changed how I approached the rest of the project.

One thing this project reinforced for me was how valuable multidisciplinary teams are.

As software engineers, it's easy to think the hardest problems are technical.

In reality, many of the most important requirements come from people who don't write code.

Grubert didn't tell me how to implement RTK checks or mission validation. He explained how inspections were performed, what could go wrong in the field, and why those risks mattered.

My job was to translate that operational knowledge into software.

Once I felt confident that we could reliably execute recorded missions, another challenge started to emerge.

It wasn't about the flight anymore.

It was about everything that happened after the flight.

I still remember thinking that adding another waypoint was basically free.

It's just another stop.

Another photograph.

Why not?

Then you start following that photograph through the rest of the system.

Now it's another file to upload.

Another image for someone to review.

Another comparison to make during the next inspection.

A slightly longer mission.

More battery consumed.

More time for the pilot to complete the inspection

That's when I stopped seeing waypoints as coordinates.

I started seeing them as engineering decisions.

Before this project, I thought mission planning was mostly about drawing waypoints on a map.

Today, I think of it as designing an inspection.

The route is just one piece of it.

It's about designing an operation.

The flight itself only lasts a few minutes.

But every decision made before takeoff affects everything that comes after: the quality of the data, the confidence of the inspection, the amount of work required to review the results, and whether the next inspection can actually be compared to today's.

A mission plan isn't just a flight path.

It's the blueprint for an entire inspection.

That realization deserves its own discussion.

Because once you stop thinking of waypoints as coordinates and start thinking of them as engineering decisions, a very different optimization problem begins to emerge.