Компьютерное зрение на реальном объекте: что нужно, кроме модели

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

Чем объект отличается от демо

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

Колонка «Демо» - типичная картина показа, а не описание конкретного демо.

Пример: камеры на контейнерных площадках

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

Камеры Dahua BF4CP 4G работают от батареи и выходят в сеть по 4G. Подключить их как обычные IP-камеры было нельзя: доступ к ним был только через облачный API производителя. API - программный интерфейс, через который одна программа управляет другой программой или устройством. Через этот API система по расписанию будит камеру, забирает снимок, узнаёт её состояние (на связи, спит или недоступна), смотрит заряд и при необходимости отправляет команду перезапуска.

В итоге получился не очередной ИИ-скрипт, а полноценная система на стыке оборудования, API производителя и vision-модели. Vision-модель, или VLM, - это модель, которая понимает и картинку, и текст: ей можно показать снимок и задать вопрос словами. В MVP это облачная модель. Для технических читателей - стек из поста: FastAPI, SQLAlchemy и APScheduler на сервере, PostgreSQL и MinIO для данных и снимков, React, TypeScript и Leaflet для интерфейса с картой.

Задачу системы я сформулировал так: убрать ручной контроль и сократить выезды на объект. Это цель MVP: измеренного результата и цифр по выездам в посте нет.

Шаг 1. Выясните, как система будет получать снимок

Этот вопрос стоит задать до закупки камер.

Для IP-видеосистем есть стандарт ONVIF. Например, его профиль T описывает передачу видео и события вроде обнаружения движения. Камеры из примера выше подключались иначе: только через облачный API производителя, и перед снимком камеру нужно было разбудить. Так ли устроены другие камеры на батарее, зависит от модели и её режимов. Например, у BF4CP-4G-XL на сайте Dahua есть режим AOV, в котором камера ведёт запись круглосуточно при очень низком потреблении. Поэтому способ получения кадра - первый вопрос к поставщику.

Почему это вопрос не только связи, но и батареи, видно по паспорту близкой по названию модели. В посте камера названа BF4CP 4G, точная версия из проекта там не указана. На сайте Dahua есть страница модели BF4CP-4G-XL: батарея 32,4 Вт·ч и несколько режимов с разным потреблением. Для трёх из них: если камера всё время работает в одном режиме, батареи хватит примерно на такой срок:

Это грубая оценка по паспорту, замеров из проекта здесь нет. Реальный расход зависит от того, как часто камеру будят, от сигнала 4G и от погоды. У Dahua есть и комплект этой модели с солнечной панелью, с ним расчёт другой.

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

Что выяснить у поставщика до покупки:

• Способ доступа. Можно ли получать кадр напрямую по сети или только через облако производителя. Поддержку ONVIF проверяйте в официальной базе соответствия ONVIF: соответствие там привязано к конкретной версии прошивки. У BF4CP-4G-XL в характеристиках на сайте Dahua стандарт ONVIF не указан; средством управления названо фирменное мобильное приложение. Отсутствие строчки в паспорте не доказывает отсутствие функции, поэтому такой вопрос лучше задать поставщику прямо.
• Что умеет API. Если доступ идёт через облако, уточните, есть ли API для разработчиков и можно ли через него разбудить камеру, получить снимок, узнать состояние и заряд, перезапустить устройство. И на каких условиях даётся этот доступ.
• Где работает облако. Работает ли облачный сервис производителя официально в вашей стране и где хранятся снимки.
• Паспорт под ваши условия. Рабочая температура (у BF4CP-4G-XL - от минус 20 до плюс 60 °C), питание и диапазоны мобильной связи. У этой модели на сайте указаны отдельные версии для разных регионов с разными диапазонами LTE, и версия должна подходить вашему оператору.

Шаг 2. Договоритесь, что модель должна ответить

Для показа достаточно ответа «навал есть» или «навала нет». В работе этого мало: службе нужно понять, ехать сейчас или дождаться планового вывоза. В MVP каждому снимку присваивается один из пяти уровней серьёзности: none, low, medium, high или critical.

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

Чтобы ответ модели можно было использовать:

• Опишите каждый уровень словами и примерами снимков. По этим же описаниям вы потом проверите модель.
• Попросите строгий формат ответа. Его будет читать программа. Образец запроса (составлен для примера; запрос из проекта в посте не приводится):

Задача: оценить снимок контейнерной площадки.
Определить, есть ли мусор вне контейнеров, и выбрать один уровень:
none - площадка чистая;
low - немного мусора рядом с контейнерами;
medium - контейнеры переполнены, мусор вокруг;
high - крупный навал, подход к контейнерам перекрыт;
critical - навал мешает проезду.
Если снимок тёмный, размытый или площадки не видно, выбрать unknown.
Ответ - только JSON: {"severity": "...", "reason": "что видно на снимке, одной фразой"}

• Оставьте модели вариант «не могу оценить». В образце это unknown - дополнение к пяти уровням, в посте его нет. Без такого варианта тёмный или засвеченный кадр может получить уровень none, то есть «чисто».
• Храните снимок вместе с ответом. Тогда спорный статус можно проверить глазами, а неудачные кадры - собрать для проверки модели.

Шаг 3. Покажите результат там, где принимают решения

В MVP результат сразу появляется на карте: у каждой площадки свой статус. Ради этого всё и строится: распознавание приносит пользу, когда человек открывает карту и видит, какие площадки требуют реакции.

Что стоит продумать для своей системы:

• Кто смотрит и что делает. На каждый уровень из шага 2 должен быть ответственный и понятное действие.
• Отдельный статус «нет данных». Камера недоступна или снимок не удалось оценить - это не то же самое, что чистая площадка. Иначе молчащая камера на карте выглядит как порядок.
• Снимок рядом со статусом. Тот, кто принимает решение о выезде, должен видеть кадр, по которому поставлен уровень.

Шаг 4. Заложите слой надёжности

В MVP пришлось отдельно собрать слой, который следит не за площадками, а за самими камерами. Без него, по моей оценке, такие системы в работе просто рассыпаются.

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

Как это можно устроить:

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

Как проверить систему до запуска

Этот порядок - рекомендация: как испытывали MVP, в посте не рассказано.

Ограничения

• Пример - MVP. Так система названа в посте, и замеров её работы там нет: в статье описано устройство системы, а не её результаты.
• Модель может ошибаться. Как часто она ошибается на ваших снимках, покажет только проверка из раздела выше. Поэтому снимок хранится вместе с ответом, а спорные статусы смотрит человек.
• Зависимость от внешних сервисов. Если облако производителя камер или поставщик модели недоступны, снимков или оценок не будет. Система должна показывать это прямо, чтобы старые статусы не висели на карте как свежие.
• Люди и машины в кадре. Камера на площадке может снимать прохожих и автомобили. Что хранить, сколько и можно ли отправлять снимки во внешний облачный сервис, решите с юристом до запуска.
• Стоимость в посте не указана. Она складывается из камер, мобильной связи, облачных сервисов, обращений к модели и разработки.

Частые вопросы