Drone crews can photograph pole tops faster than anyone can review the photos. A four-stage computer vision pipeline closes that gap, and this is what an inspection team gets out of it.
A large distribution utility owns hundreds of thousands of poles, sometimes millions. Each pole top carries a crossarm, a handful of insulators, fuse cutouts and often a transformer, and any one of them can fail and take a feeder down with it.
Drones solved the first half of the inspection problem. A crew can now photograph every pole top on a circuit in a day. The second half, having a qualified person look at all of those photos, has not changed at all. Utility pole defect detection with computer vision is about closing that gap: software does the first pass over the imagery, and engineers spend their time on the poles that need them.
TL;DR
Drone imagery is cheap to collect and expensive to review. This article walks through a four-stage pipeline, built on current foundation models, that turns raw pole-top photos into ranked inspection findings:
- A vision-language model (VLM) decides whether each image is usable and tells the flight crew what to re-shoot.
- SAM 3 segments crossarms, insulators, cutouts and transformers from plain-text prompts.
- Small classifiers on DINOv3 features score each component for defects, with an anomaly score for failures nobody has labeled yet.
- A VLM drafts the finding in the utility's own inspection language. An engineer approves it.
The reference data is EPRI's public Distribution Inspection Imagery dataset, about 30,000 images. The numbers in this article are design targets; measured results on EPRI data will follow in a later post.
What an inspection team gets out of it
The model names come later. The outcome comes first, because that is what the pipeline is for.
- Reviewers look at a fraction of the images, ranked by severity, instead of all of them in capture order.
- Unusable shots come back as a re-capture request, with the reason ("pole top obscured by tree canopy"), while the crew is still in the area.
- Findings arrive as draft work orders in the utility's own codes, with the evidence crop attached. The engineer's job is to approve or edit, not to write.
- Every correction the engineer makes goes back into training. The system gets better on your hardware, your regions and your seasons.
Why pole inspection breaks a single AI model
The obvious approach is one object detector trained on "defect" labels. It stalls for three reasons that are specific to this kind of imagery.
Many images are unusable. Blur, glare, backlighting, a tree canopy over the pole top, or a framing that cuts the hardware off. A detector trained on clean images will happily produce confident nonsense on bad ones.
The hardware that matters is small. Resize a 20 MP drone frame down to the 1,024-pixel input most models expect and a hairline crack in a porcelain insulator is gone before the model ever sees it.
Defects are rare and unlike each other. A rotted crossarm and a flashed insulator share almost no visual features. You will never collect enough examples of every failure mode, and the one that matters most is usually the one nobody labeled.
So we split the work into four stages. Each stage has one job.

Stage 1: a quality gate for drone inspection imagery
A VLM scores every image against a short checklist: pole top in frame, in focus, lit from the front, unobstructed. It returns a verdict and, more usefully, a reason:
{
"usable": false,
"reason": "pole top obscured by tree canopy"
}The reason goes straight back to the flight crew as a re-capture request. Catching a bad shot the same day is cheap. Discovering it three weeks later at a desk means another truck roll.
Running a VLM on every image in a fleet-wide survey would be expensive. So we run it on a sample, use those verdicts to train a small classifier on frozen image embeddings, and send only the borderline cases back to the VLM. Most images get a millisecond decision; the hard ones get the expensive model. It is the same split we made when sizing a tiny language model to one narrow job: the large model stays where it earns its cost, and the routine, high-volume decisions go to a small one.
Stage 2: segmenting pole-top components with SAM 3
SAM 3 is Meta's segmentation model that works from a text prompt. Give it "fuse cutout", "porcelain insulator" or "crossarm" and it returns a mask for every matching object in the image. Nobody has to draw boxes first.
We run it on high-resolution tiles from the upper part of the frame and merge the results, so the masks keep full detail around small hardware.
EPRI's annotations follow its own Distribution Taxonomy, which defines about 30 asset classes, from arresters to wildlife protection. We use those annotations twice: to lightly fine-tune SAM 3 on the hardware types in the dataset, and to measure how often each component type is actually found.
This changes what labeling means for a utility. Annotators review proposed masks and fix the wrong ones instead of drawing polygons from scratch. And adding a new component type, say a recloser or a voltage regulator, takes a new prompt and a few hundred verified examples rather than a new labeling project.
Stage 3: scoring each component for defects
Each masked component is cropped at full resolution and passed through a frozen DINOv3 backbone, Meta's general-purpose vision model. DINOv3 turns the crop into a feature vector; we do not retrain it. On top of those features we train one small classifier per component type:
| Component | Defects checked |
|---|---|
| Crossarm | Rot, splits, cracks, burn marks |
| Insulator | Chips, cracks, flashover, contamination |
| Cutout / fuse | Broken or missing parts, open fuse door, corrosion |
| Transformer | Oil leaks, corrosion, bulging, damaged bushings |
Two additions cover what a classifier alone would miss.
Anomaly scoring measures how far each component sits from healthy examples of its type. A failure mode nobody labeled gets flagged for a look instead of passing silently. We would rather over-flag a strange-looking insulator than miss a flashed one.
Synthetic defects fill in the rare classes. Diffusion-based image editing paints realistic cracks and corrosion onto healthy components for training. These images never appear in evaluation, so they cannot inflate the numbers.
One scoping note. This pipeline covers pole-top hardware. The pole itself (groundline rot, lean, woodpecker damage) needs ground-level or oblique imagery and its own defect heads. Same four stages, different prompts.
Stage 4: from defect scores to an inspection finding
An inspector does not need "defect: 0.91". They need a work order. A VLM receives the crop, the mask, the defect scores and the utility's inspection standard, and drafts one:
{
"component": "insulator, right phase",
"defect": "flashover damage",
"severity": "high",
"evidence": "crop_0142_b.png"
}Findings are ranked by severity. When confidence is low, or the defect classifier and the VLM disagree, the finding goes to an engineer. Every correction they make, a changed severity or a rejected finding, becomes training data for the next round.
The VLM writes in the utility's vocabulary because it is given the utility's standard. Priority codes, severity levels and component names come from your inspection manual, not from the model's idea of what a work order should look like.
Fitting into an existing inspection program
None of this asks a utility to change how it flies. The pipeline takes imagery from whatever capture workflow is already in place, whether a contracted drone service or in-house crews.
Findings carry the asset identifier from the flight plan, so they land against the right pole in GIS and the asset register, and approved findings can be pushed into the work-order system already in use, whether that is SAP PM, Maximo or something home-grown.
Imagery of critical infrastructure is sensitive. Every model in this design has an open-weight option, so the whole pipeline can run inside the utility's own cloud tenancy or on-premises. Nothing depends on sending pole imagery to a third-party API.
Design targets
These are the targets we design against, not results we have measured. Measured numbers on EPRI data will follow.
| Target | Value | What it means in practice |
|---|---|---|
| Recall on defective components | ≥ 90% | At least 9 of every 10 real defects are flagged. A miss costs more than a false alarm. |
| Images routed to human review | ≤ 15% | Reviewers see about 1 image in 7. Review is the bottleneck we are removing. |
| Labeled component images to reach production | ~2,000 to 3,000 | Weeks of labeling, not months. Foundation features plus model-proposed labels. |
| Time to add a component class | Days | A new prompt plus verified examples, not a new labeling project. |
What can still go wrong
- Errors compound. A component missed in Stage 2 is never checked in Stage 3. Recall has to be measured at every stage, not only end to end.
- Data drifts. Region, season, lighting and hardware vendors all change what "normal" looks like. A model tuned on one service territory needs re-checking on the next.
- VLMs can sound confident and be wrong. They draft findings. Engineers sign them. That division of labor is deliberate.
- Anomaly thresholds need tuning for each component type, or reviewers drown in false alarms and stop trusting the queue.
Beyond distribution poles: transmission, substations, solar and wind
The four stages (filter, segment, score, explain) are not specific to poles. They apply anywhere a fleet of similar assets is photographed at scale and labeled defect data is scarce, which describes most of the energy sector.
- Transmission: insulator strings, dampers, spacers and conductor hardware from helicopter or drone patrols.
- Substations: visual and thermal imagery of bushings, breakers and transformer radiators.
- Solar: module cracks, hotspots and soiling across thousands of identical panels, with thermal and RGB imagery scored together.
- Wind: leading-edge erosion, lightning damage and surface cracks on turbine blades.
The economics are the same in each case. Capture got cheap. Review did not.
Further reading
- EPRI, Distribution Inspection Imagery, IEEE DataPort (2021), with annotations on Kaggle
- EPRI, Distribution Taxonomy and Guidance, GitHub wiki
- Meta AI, SAM 3: Segment Anything with Concepts (2025), with code on GitHub
- Meta AI, DINOv3 (2025)
- Fine-Tuning a Tiny Language Model for Production Tool Calling, on sizing a model to one narrow job
Data: EPRI Distribution Inspection Imagery, Electric Power Research Institute (Lewis & Kulkarni, 2021), DOI: 10.21227/rh5n-xn68. Shared under a Creative Commons license.
About J33.AI
J33.AI builds AI and computer vision systems that hold up in production. The models in this article are new. The work around them is not: building the data that defines the task and measuring the number that matters, then wiring the result into the systems people already use. See our services.
AI and digital solutions for energy and renewables
Energy and renewables companies are not short of data. Drones fly the lines, thermal cameras sweep the solar fields, sensors sit on every turbine. Turning all of that into decisions is still mostly manual work. If you are planning an AI or digital initiative around your assets or operations, we would like to hear what you are working on. A scoped pilot on your own data, measured against your engineers' judgment, is the fastest way to find out whether it holds up.
Contact Us