Своевременная диагностика на производстве: шесть фич с компьютерным зрением. Кейс rdl и угольного терминала

Конвейер — критичный для производства элемент системы, своего рода кровеносная система предприятия. Иногда в её работе случаются сбои, порезы, порывы, поэтому за ней нужен постоянный контроль. В этом случае компьютерное зрение — это средство для своевременной диагностики. За этим руководители компании-стивидора и обратились к rdl by red_mad_robot.

Клиент, имя которого мы не можем называть по условиям NDA, пришёл к нам с проблемой: «Рвётся конвейерная лента, хотим с этим что-то сделать. Например, однажды в уголь воткнулся лом и порвал сотни метров ленты».

Дальше мы с бизнес-аналитиками начали разбираться, что есть сейчас, какие перед нами стоят задачи, на каких конвейерах проявляется проблема и к чему это всё ведёт. Так как клиент — интегратор, он знал проблему, но не был полностью погружён в специфику. Мы организовали встречи, чтобы узнать дополнительную информацию.

После предпроектного исследования запрос «сделать что-то c порывами на ленте» превратился в семь гипотез, одна из которых себя не оправдала из-за технических ограничений и сомнительной бизнес-ценности. Итого — шесть пилотных фич и выездная встреча.

На ней мы продемонстрировали прототип MVP. Это не был полноценный сервис, скорее тестовый стенд, работающий на реальном конвейере. Несмотря на то что этап MVP начинается после пилота, топ-менеджеры клиента хотели увидеть систему в работе как можно скорее — и мы пошли им навстречу.

Шесть фич — это:

На каждый этап — с двумя гипотезами-фичами в нём — уходило по два месяца. Довольно быстро с учётом того, что каждое такое событие — это чрезвычайная ситуация, которая происходит довольно редко, а в идеале не должна происходить вообще. Нам же для датасета и обучения модели нужно было генерировать эти события часто. Поэтому на каждом этапе мы дополнительно организовывали эксперимент: то имитировали движение повреждённой ленты, тянув её грузовиком, то подбрасывали мусор на работающую ленту и быстро убирали его, чтобы не нарушать технологический процесс.

В ходе проекта клиент активно погружался в специфику Data Science и инструментов компьютерного зрения. Совместно мы организовали несколько экспериментов для сбора датасета в промышленных условиях. Такая вовлечённость помогала поддерживать интенсивный темп работы, несмотря на техническую сложность проектов.

А теперь поговорим про каждую фичу подробнее.

Когда лента порвана, уголь просыпается на нижнюю часть конвейера. Со временем разрыв может расти, пока лента окончательно не выйдет из строя. Чем раньше удастся найти повреждения, тем быстрее можно починить ленту — и тем самым сократить простой.

Сначала мы находили сквозные порывы косвенно — через просыпание угля. Это бинарная задача из разряда «да/нет»: уголь просыпается или не просыпается. На город опускается ночь, уголь просыпается, а оператор на дежурстве — нет, и вот у нас проблема. Компьютерное зрение позволяет её избежать.

В этой и последующих фичах мы вели съёмку камерой глубины Intel RealSense со штатива, но снимали в обычном режиме без фиксации карты глубины.

Но как найти сквозные порывы, если лента в порядке? Мы провели простой эксперимент. Чтобы заснять нужные для обучения модели кадры, сотрудники конвейера подбрасывали уголь лопатой на обратную сторону.

Дальше мы обучили на сделанных кадрах несколько разных моделей и выбрали лучшую из них. Вот так выглядит результат:

Так как на производстве часто бывает пыль, клиенту было важно убедиться, насколько модель уверена, что в кадре действительно просыпания угля. Поэтому в рамках пилота мы выводим процент точности на экран.

Иногда при пересыпании угля на ленту шибер — заслонка на пересыпном бункере — немного смещается. Из-за этого центр горки тоже уходит в сторону. Если смещение от фактического центра больше определённого значения, скажем, трёх сантиметров, это может привести к тому, что лента сойдёт с роликов. А это уже чрезвычайная ситуация, которая влечёт за собой ремонт и незапланированный простой.

Для сбора датасета мы специально имитировали смещение шибера, чтобы получить краевые случаи и обучить модель находить центр горки.

В отличие от предыдущего проекта, здесь нужна карта глубины и, соответственно, камера, которая может её определять.

Сначала мы вычисляем центральную линию пустого конвейера, затем находим центр горки. Потом совмещаем две центральные линии и высчитываем отклонение по модулю. Если отклонение больше тех же трёх сантиметров, подаём оповещение, что лента может сойти с роликов.

Вот так выглядит результат:

Этот алгоритм затем применялся при определении забутовок. О них поговорим чуть ниже.

В угле может попадаться мусор и повреждать ленту. А ещё лента может изнашиваться сама по себе. В результате в ней образуются порезы и порывы.

Сначала мы детектировали только сквозные порывы через просыпания угля на нижнюю часть конвейера. Ну вы помните. Но в процессе работы с клиентом поняли, что нужно также находить и несквозные отверстия, так как со временем порезы могут превратиться в порывы. Хоть мы и не закладывали это в бэклог, решили искать не только порывы, но и порезы в ленте.

Эксперимент для этой гипотезы придумывали на ходу. Крутить пустой конвейер с лентой — не вариант. Специально портить ленту на работающем конвейере — ещё больше не вариант. Поэтому клиент соорудил для нас конвейер из подручных материалов: куска ленты и вала. На ленту специально нанесли повреждения, на валу её крутили и тянули грузовиком, имитируя движение конвейера.

С точки зрения подхода эта фича не отличалась от следующей — это была задача семантической сегментации.

Вот так выглядит результат:

Пилотный этап завершился успешно: доля всех верно обнаруженных порезов и порывов — 82,68%.

Этот случай похож на предыдущий: заклёпки на местах стыков ленты со временем изнашиваются или страдают от внешних воздействий. Из-за этого разные части конвейерной ленты могут расходиться. В рамках пилота нам нужно было понять, можем ли мы вообще детектировать заклёпки на ленте и подсчитывать их количество.

Мы доработали эксперимент для порезов и порывов, раскидывая заклёпки по ленте. Сняли видео, с него уже нарезали кадры и на них обучали модель. При обучении себя хорошо показала модель RTMDet.

Мы обучали её с большим количеством аугментаций. Проще говоря, меняли различные параметры у кадра — контрастность, яркость, — чтобы получить другие кадры и увеличить выборку. Это помогло улучшить обобщающую способность модели и снизить зависимость результатов работы от условий съёмки видео.

Вот так выглядит результат:

В результате удалось добиться того, что доля всех верно обнаруженных объектов составила 93,75%.

Помните историю про сотни метров ленты, которую порвал воткнувшийся лом? Такое случается на производстве, поэтому неплохо было бы узнавать о мусоре заранее, пока повреждения не приобрели такой масштаб. Особенно если этот мусор металлический.

В рамках эксперимента клиент выделил нам конвейер, на который рабочие терминала подбрасывали мусор — мягкий и металлический, так как его нужно было детектировать отдельно. После того как мусор проезжал мимо камеры на ленте, его сразу убирали, чтобы не вредить техпроцессу. На эксперимент ушло полдня.

Вот как выглядит результат:

В результате удалось добиться того, что доля всех верно обнаруженных объектов составила 98,28%.

Забутовка — это что-то вроде тромба. Представьте, что пересыпной бункер, который похож на конусную воронку, забивается углём — и на верхнем конвейере оказывается больше угля, чем на нижнем. Это чрезвычайная ситуация, которую нужно детектировать.

Итак, чтобы контролировать ситуацию, нужно сравнивать объёмы угля на верхнем и на нижнем конвейерах. Когда всё идёт хорошо, они будут примерно одинаковыми.

Но нам не нужно идеально, нам нужно воссоздать критическую ситуацию. Как это сделать? Увеличить скорость верхнего конвейера. Если изменить скорость одного из конвейеров, это повлияет на объём проходящего угля. При реальной забутовке объём угля на нижнем конвейере будет меньше, чем на верхнем, что нам и нужно.

У нас уже был опыт с центром горки. Мы взяли такой же подход, потому что в нём косвенно определяли объём. Но у этого метода не было необходимой точности, поэтому мы экспериментировали и с другими, а этот выступал как референс.

Основная конкуренция была между калибровочным и аппроксимационным методами. Калибровочный метод работает нестабильно, потому что в нём присутствуют искажения от нагрузки на конвейерную ленту. Его нужно калибровать по реальному конвейеру, и каждый раз результат калибровки разный, что не даёт возможности адекватно сравнивать нижний и верхний конвейеры.

В рамках текущего пилота аппроксимационный метод — самый точный. Но на реальных конвейерах мы всё равно будем калибровать алгоритм при развёртывании MVP, поэтому уверены, что покажем даже лучшие результаты. Сейчас мы не определяли точность, так как алгоритм просто определяет, есть смещение или нет. Но на MVP мы будем измерять фактическое отклонение от центра и то, что определяет алгоритм.

Вот так выглядит результат:

Мы доказали работоспособность всех кейсов: с подготовленными в полевых условиях экспериментами, с видео, заснятыми камерой на штативе, и на вполне рабочих моделях. В процессе мы пошли клиенту навстречу и добавили ещё один кейс — определение порезов, а не только порывов, потому что поняли его бизнес-ценность.

Но самое главное: для двух проектов — просыпаний и смещения горки — мы даже успели сделать прототип, промежуточный этап к MVP, хотя на этапе пилотных проектов этого не предполагается.

Прототип был нужен, чтобы доказать работоспособность нашего решения в реальном времени и промышленных условиях. Для этого мы разработали веб-сервис с интегрированными в него моделями. А дальше провели два дня в полевых условиях:

Нам приходилось на месте организовывать эксперименты, подобные тем, что мы уже проводили. Например, во время движения ленты подкидывать уголь лопатой, чтобы показать работу сервиса в реальном времени.

Для показа демо прототипа со смещением горки клиент подвёз три вагона с углём, который нужно было в точное время загрузить на ленту.

Представьте, руководство собирается у стенда, готовится смотреть демонстрацию. Проходит минута, лента едет пустая, но ничего не происходит. Потом уголь появляется, но смещения горки нет. Приходилось координировать каждый шаг, чтобы всё прошло так, как задумывалось. Высчитывать время, когда нужно отгружать уголь, чтобы он появился под камерой, когда топ-менеджеры подошли к стенду. Смещать центр горки шибером, чтобы клиент увидел предупреждение в реальном времени.

На видео можно посмотреть момент, когда сервис сигнализирует о смещении горки угля:

Над материалом работали:

Чтобы ничего не пропустить, следи за развитием цифры вместе с нами:

Да пребудет с тобой сила роботов! 🤖