Камеры с компьютерным зрением: мониторинг контейнерных площадок

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

Задача

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

Цель MVP - убрать ручной контроль и сократить выезды к объектам.

Что я сделал

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

Цикл устроен так. Камера делает снимок в заданное время, кадр сохраняется в хранилище, затем его оценивает облачная vision-модель. Это нейросеть, которая умеет разбирать фотографии: вместе с кадром она получает словесное задание, что именно на нём оценить. Модель выбирает один из пяти уровней серьёзности - none, low, medium, high или critical, - и статус площадки сразу меняется в интерфейсе с картой.

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

Что значит «к любой камере»

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

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

Слой надёжности

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

Что получилось

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

Мне в этом кейсе важно, что ИИ работает внутри рабочего цикла, а не ради презентации. Убрать ручной контроль и сократить выезды - цель MVP, а не измеренный результат: замеров о выездах я не публиковал.

Во что это обходится

Моя оценка: $5 за 10 000 фото против нескольких миллионов рублей на разработку и внедрение. Это оценка порядка цифр, а не смета. Бюджет конкретного объекта складывается из камер, мобильной связи, хранения снимков, разработки и поддержки, и считать его нужно под свои условия.

Кейс за 39 секунд: ролик для владельца бизнеса

Владельцу бизнеса подробности про API, модель и повторные запросы обычно ни к чему. Поэтому я проверил отдельную задачу: как показать этот кейс без технических деталей. Я передал исходный пост о кейсе своему ИИ-ассистенту, он выделил главное и написал сценарий, а программа сборки видео на моём сервере собрала из него ролик длиной 39 секунд с русской озвучкой (пост №106).

После заставки сцены идут так: задача, чем 4G-камера отличается от обычной IP-камеры, путь от снимка до статуса площадки, слой надёжности, из чего собрана система, итог.

Две детали к ролику. В кадрах подписаны сервисы, через которые в MVP работала модель, - так же они названы в посте о кейсе. Gemini официально в России не работает: России нет в списке стран, где доступен Gemini API. Для второго сервиса из того же кадра официального подтверждения, что он работает в России, на 12 октября 2026 года нет, поэтому здесь он не назван. Сервисы в кадре - часть устройства MVP, а не рекомендация: для своего проекта выбирайте модель, которая официально доступна в вашей стране.

И о надписях. «Production ready» в центре сцены про надёжность и «compact production stack» под списком технологий - формулировки ролика, статус системы - MVP. «Меньше ручного контроля» и «меньше лишних выездов» в финальной сцене - цели MVP, а не замеры.

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

Ограничения

• Это MVP. Описаны устройство системы и работа цикла, замеров результата нет. Измеренного экономического эффекта я пока не заявляю.
• Оценка стоимости - не смета. «$5 за 10 000 фото против нескольких миллионов рублей на разработку и внедрение» - мой порядок цифр, бюджет объекта считается отдельно.
• Подключение зависит от камеры. «К любой камере» - при условии, что кадр можно забрать программно. Камеры этого проекта доступны только через облако производителя: если оно молчит, новых снимков тоже нет.
• Модель облачная. Снимки уходят во внешний сервис. Выбирая модель для своего проекта, проверьте, что она официально доступна в вашей стране, и решите с юристом, можно ли отправлять туда кадры, где видны люди и машины.
• Модель может ошибаться. Частоту ошибок покажет только проверка на снимках с ваших камер, порядок такой проверки - в статье о компьютерном зрении на объекте.