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

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

Именно с такой задачей к команде разработчиков «Формат кода» пришел заказчик этого проекта. Причем сразу с несколькими сценариями, связанными с компьютерным зрением. Нужно было автоматизировать несколько процессов на производственной площадке: считать компоненты на конвейере, определять события при крупноузловой сборке, контролировать ношение средств индивидуальной защиты и фиксировать въезд и выезд транспорта с территории.

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

Четыре класса задач и сразу понятная граница между простым и сложным

На старте команда «Формата кода» вместе с заказчиком разложила будущую систему на несколько классов задач. 

1. Первый блок: работа с конвейером. Камера установлена сверху, конвейер находится в помещении, освещение постоянное, объекты крупные, понятные, хорошо различимы. Это тот редкий случай, когда еще до начала разработки можно уверенно сказать, что все должно получиться. 

2. Второй блок: определение событий, связанных с крупноузловой сборкой из тех компонентов, которые учитываются на конвейере. И вот здесь проект резко выходит из «стерильной» зоны. Работы происходят уже не в помещении, а на открытой территории. Это предполагает смену освещения, осадки, разный фон. Плюс камеры размещаются на манипуляторах, которые перемещаются по территории. То есть камера уже не просто смотрит в одну стабильную сцену, а меняет ракурс и может видеть вещи, которые вообще не относятся к нужному сценарию.

3. Третий блок: контроль средств индивидуальной защиты. Здесь тоже было два разных мира. Первый — проходная, где камера статична, свет стабильный, люди проходят в относительно понятной зоне наблюдения. Второй — территория, где в кадр попадают люди с разного расстояния, под разными углами, в движении, в разных погодных условиях.

4. Четвертый блок: фиксация въезда и выезда транспорта с территории, классификация транспорта и попытка считывания номерных знаков. В этом сценарии тоже были свои ограничения. Камера хоть и статична, но установлена высоко, с большим обзором, без ночного режима и подсветки. То есть сам факт движения автомобиля и пересечения определенной зоны кадра определить можно довольно надежно, а вот чтение номера уже зависит от освещения, чистоты номерного знака, погоды и времени суток.

Почему заказчику вообще понадобилась такая система

За каждой задачей в рамках проекта стояла не абстрактная любовь к автоматизации, а вполне прикладной мотив.

• Контроль СИЗ — это вопрос техники безопасности. 

• Подсчет компонентов на конвейере — это уже про учет, контроль и планирование. 

• Фиксация въезда и выезда транспорта — это дополнительный слой контроля, безопасности и учета. 

• Наконец, контроль действий при сборке — это попытка перевести физические производственные операции в цифровые события: что именно происходило, в какой момент, в каком месте, над каким объектом. 

Что именно делала команда: строила рабочий пайплайн под конкретную площадку, а не придумывала нейросети с нуля

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

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

Данные решают все!

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

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

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

Предобработка и аугментация: как компенсировать то, чего нет в исходных данных

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

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

Как выглядел технический пайплайн

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

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

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

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

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

Почему для этого понадобилось облако, а не мощности заказчика

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

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

А вот обучение — совсем другая история. Это длинные вычислительные циклы, большие объемы входных данных и много чего еще. Полный цикл обучения одной модели (30 тысяч изображений) без GPU мог бы занимать до 9 суток, но с графическими картами Nubes занимал всего 8 часов. 

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

Что было критично в инфраструктуре

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

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

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

При этом реализация проекта осуществлялась в рамках ограниченного бюджета. Команда не брала «максимум железа на всякий случай», а искала рабочий баланс между стоимостью, скоростью обучения и удобством нескольких пользователей, работающих на сервере. В итоге остановились на конфигурации с одной видеокартой без избыточно мощного процессора, но с достаточным объемом хранилища. Это был не рекорд по мощности, а нормальная практическая середина под конкретные задачи.

Почему выбрали Nubes

На вопрос, почему для проекта выбрали именно облако Nubes, команда ответила довольно спокойно и без пафоса. Решающих факторов было три: скорость взаимодействия, наличие нужных ресурсов и стоимость.

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

Это тот случай, когда облако сработало так, как и должно работать нормальное инфраструктурное решение. Команда не тратила время на инфраструкту и могла заниматься своей основной задачей — обучением моделей и докручиванием решения.

Итог

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

• Нужны реальные данные с объекта, а не абстрактные картинки.

• Нужен внятный пайплайн обучения, а не вера в универсальную модель.

• Нужны вычислительные ресурсы там, где идет «тяжелая» разработка.

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

Именно в таких проектах облако перестает быть «модной ИТ-темой» и становится просто хорошим рабочим инструментом. Взяли ресурсы, обучили модели, довели качество до нужного уровня, загрузили результат в локальные устройства и получили систему, которая решает вполне прикладные задачи бизнеса.