Разбор аэроснимков ЛЭП: поиск дефектов
Инженер разбирает отобранные кадры с привязкой к опоре, а не весь архив облёта
Проверяется: протокол замера полноты и журнал обработки
Энергосети, операторы БПЛАРаботаем по NDA
Облёты линий идут, снимки копятся терабайтами, а разбирают их инженеры глазами, и скорость разбора отстаёт от скорости съёмки. Задача не в том, чтобы летать, а в том, чтобы из архива отобрать кадры с признаками дефектов и передать их человеку с привязкой к опоре. Съёмка, допуски и согласования остаются на стороне оператора: работа идёт с готовыми снимками и телеметрией.
Что съедает срок и бюджет на самом деле
Почти никогда — не модель. Ниже места, из-за которых такие проекты встают, и что мы с каждым делаем.
Дефекты редкие
на тысячи кадров приходятся единицы находок. Общая «точность» на таком наборе не значит ничего — считать надо полноту и ложные срабатывания по каждому классу отдельно, а порог подбирать под режим отбора кадров для инженера, где цена пропуска и цена лишнего кадра различаются на порядки.
Дефект занимает десятки пикселей на кадре в 20–50 мегапикселей
Кадр режется на тайлы с перекрытием, находки собираются обратно в координаты исходного снимка, а дубли на границах тайлов снимаются отдельным шагом — без этого один и тот же изолятор посчитается дважды.
Условия съёмки разные
контровый свет, снег, ракурс, высота, разные камеры на разных бортах. Выборка делится по облётам, а не по кадрам: соседние снимки одной опоры почти одинаковы, и если они попадут и в обучение, и в проверку, метрики окажутся завышенными, а на новом облёте система просядет.
Определение дефекта у инженеров расходится
где один видит коррозию, другой — загрязнение. Без письменной инструкции по классам разметка получается противоречивой, и модель учится на противоречиях; согласованность разметчиков проверяется на общей выборке до того, как размечен весь массив.
Ограничение, которое определяет решение
Электросетевой комплекс относится к критической информационной инфраструктуре, а материалы аэрофотосъёмки местности и объектов подпадают под ограничения на распространение, поэтому архив снимков не выгружается во внешние облачные сервисы: обучение и прогон выполняются на оборудовании заказчика или в его частном облаке, с журналом обработки. Разрешительная часть — допуски, согласование полётов, режим обращения с материалами съёмки — остаётся на стороне оператора; сторона, которая делает распознавание, съёмку не организует и допусков не имеет.
Как проверить, что работа сделана
Приёмка идёт на отложенном облёте, который не участвовал ни в обучении, ни в подборе порога, и разметку которого инженер заказчика делает после прогона — так исключается подгонка под известные ответы. Считаются полнота и число ложных срабатываний на сто кадров по каждому классу при выбранном пороге; значения, при которых система принимается, записываются в протокол до начала обучения, а не подбираются после.
Отдельно замеряется время обработки одного облёта заданного объёма на том оборудовании, которое остаётся у заказчика, и проверяется привязка: по случайной находке инженер должен от записи в отчёте дойти до опоры и исходного кадра.
О чём спросить любого подрядчика
- Спросите, как делится выборка на обучение и проверку.
- Ответ «случайно по кадрам» означает завышенные метрики: соседние снимки одной опоры окажутся по обе стороны.
- Спросите, считаются ли метрики по классам отдельно и что подрядчик считает ценой пропуска против цены ложного срабатывания — если этот разговор не начат, порог будет выбран произвольно.
- Требуйте приёмки на съёмке, которую подрядчик не видел, и фиксации порогов до обучения.
- Уточните, кому после проекта принадлежат разметка, веса модели и код: разметка вашего архива — актив, который стоит дороже самой модели.
- Настораживает обещание конкретной точности до того, как подрядчик посмотрел ваши снимки, и готовность взяться за класс дефектов, примеров которого в архиве единицы.
Порядок работ по этапам
На каждом этапе назван результат, который остаётся у заказчика. На проверке — признак, по которому работу не приняли бы.
- Разбор архиваПосчитали, сколько кадров в архиве, какое разрешение и какие камеры на бортах, есть ли телеметрия и привязка к номерам опор, сколько уже размечено и в каком формате. Здесь же выяснили, хватает ли примеров редких классов дефектов вообще.
- Определение классовНаписали вместе с инженером письменное определение классов дефектов и инструкцию разметки, затем проверили согласованность: два разметчика прошли одну выборку, расхождения разобрали и вернули в инструкцию. Без этого модель училась бы на противоречиях между разметчиками.
- Разметка и обучениеРазметили выборку и разделили её по облётам и опорам, зафиксировав состав проверочной части до начала обучения. Обучили детектор с нарезкой на тайлы и обратной сборкой находок, считая полноту и ложные срабатывания по каждому классу отдельно и подбирая порог под режим отбора кадров для инженера.
- Проверка на облётеПринимали на отложенном облёте, который не участвовал ни в обучении, ни в подборе порога, и разметку которого инженер заказчика делал уже после прогона. Провалом считали полноту ниже записанного в протокол значения и метрики, посчитанные на выборке, разделённой по кадрам, а не по облётам.
- Передача конвейераОтдали модель с описанием классов, конвейер обработки облёта, журнал, разметку и исходный код. Показали, как прогнать новый облёт своими силами и как переобучить детектор на пополненной разметке без нашего участия.
Как это устроено внутри
Конвейер работает пачками облётов: приёмник кладёт кадры и телеметрию в MinIO, задачи расходятся по воркерам через Celery, инференс вынесен отдельной службой на ONNX Runtime. Кадр в 20–50 мегапикселей режется на тайлы с перекрытием, находки собираются обратно в координаты исходного снимка и дедуплицируются на границах тайлов, иначе один изолятор считается дважды. Находки, привязка к опоре и пролёту и параметры прогона лежат в PostgreSQL, версии весов и порогов — в MLflow, поэтому результат прошлого облёта воспроизводится на той же версии модели. Разбиение выборки хранится на уровне облёта, а не кадра: соседние снимки одной опоры почти одинаковы, и при делении по кадрам метрики оказались бы завышенными. Весь контур разворачивается на оборудовании заказчика, при падении воркера пачка возвращается в очередь и обрабатывается заново.
- Python
- PyTorch
- PostgreSQL
- MinIO
- Celery
- Docker
- ONNX Runtime
- GDAL
- MLflow
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.