Комментарии 5
А что тут думать? Конечно, использование видеонаблюдения и ИИ-анализа на производстве очень полезно. Создавал аналогичную систему для использования на кранах, работает отлично и эффективно. Она ловит человека в опасной зоне движения крана, заход под поднимаемый груз, отсутствие каски или спецодежды, и делает это в реальном времени, чтобы оператор успел среагировать до того, как что-то случится, а не постфактум при разборе записи.
Но есть несколько нюансов, и главный из них даже не сама модель, а железо. Чтобы срабатывание было мгновенным, анализ должен выполняться прямо на камере или рядом с ней: гнать видеопоток на центральный сервер и ждать ответа по сети - это и задержки, и нагрузка на сеть, и риск, что при обрыве связи обнаружение просто перестанет работать, ну и сами цеха и стройплощадки - не лучшее место для беспроводных сетей. А камеры с обработкой изображений "на лету" - это уже не офисный девайс отдела охраны, а промышленное изделие: виброустойчивое, с защитой от пыли и влаги, с рабочим диапазоном температур, сертифицированное. Плюс к этому нужен централизованный контур управления, чтобы правила обновлялись сразу на все камеры и новые участки подключались без переделки всей системы. Вот с этим у индустрии до сих пор беда: готовых стандартных решений, которые можно купить и развернуть за пару недель, практически нет, каждый объект - индивидуальная интеграция, а это совсем другие деньги.
По идее, на всех производствах нужно внедрять видеофиксацию и анализ для каждого сотрудника, спору нет. Но если посчитать честно - умная камера, сервер, сеть, интеграция, обучение персонала, техподдержка, - цена одной точки контроля выходит такая, что средний завод предпочтёт доплатить за страховку, а не вкладываться в профилактику.Для большинства предприятий это пока очень дорого. Короче, направление правильное, но до массового внедрения индустрии ещё далеко.
Вы смотрите на задачу с правильной стороны: моделька здесь действительно не самое сложное. Гораздо сложнее собрать всю систему и весь процес: камеры + связь + инцендент-менеджмент.
Кстати, edge-вычислитель и/или центральный сервер - это вопрос выбора архитектуры под конктретную видеоаналитику . Если речь о человеке под грузом, счёт может идти на доли секунды, тут важно такую аналитику делать прямо на объекте. А вот каски, спецодежду или соблюдение регламентов вполне можно контролировать через облако и даже не беря все кадры из видеопотока. У нас есть в практике и вариант с edge-вычислителями (и одноплатники китайские и новые коробочик от Nvidia Jetson).
С ценой всё тоже сложно. Сейчас экономическая ситуация такова, что для заказчиков покупать специализированную умную камеру для каждого участка просто дорого. При этом очень часто на объекте уже есть обычные IP-камеры. Почти всегда если получается решать задачи на уже готовой архитектуре - это упрощет внедрение и проект. Да и для заказчика - это дешевый формат проверки гипотезы о внедрении ИИ.
Универсальной коробки, которую можно поставить на любом заводе за пару недель, пока нет, условия слишком разные. Но вот SaaS Qmonitoring мы сейчас ставим за 3 дня рабочих на объекте, если на объекте уже стоят камер и есть связь. На большинстве строек и городских промплощадок связь вполне себе норм. То есть у нас есть готовые обученные на очень большом примере изображений ИИ-модели, которые легко ставить "из коробки".
П.с. ваш кейс с нейронкой, которая ловит опасные случаи под краном нам очень интересна. Будем рады обсудить подробнее, давайте обменяемся контактами на почте. Наша почта: office@qmonitoring.ru
YOLOv8 применяется непосредственно для обнаружения объектов на строительной площадке.
Устарело на несколько лет. Сейчас внедряю решения на базе RF-DETR. Это трансформер, у которого по сравнению с Yolo выше точность (mAP) и лучше сегментация границ.
ResNet позволяет классифицировать объекты.
RF-DETR без проблем решает задачи классификации. Более того, даже Yolo в виде Yolo-cls делает тоже самое.
Также используются EfficientDet, Mask R-CNN и U-Net для дополнительной сегментации.
И здесь все заменяется RF-DETR, кроме разве что, семантичекой сегментации в U-Net, но она в большинстве случаев просто не нужна.
RF-DETR действительно сейчас очень сильная архитектура, спорить с этим не будем. Но общий benchmark — это скорее ориентир, чем ответ на вопрос, какая модель лучше в конкретном продукте.
В production данные могут сильно отличаться от benchmark-датасета — у нас это реальные стройки со своей спецификой камер, ракурсов, маленьких объектов и освещения. Поэтому, как и написано в статье, новый объект мы отдельно прогоняем на своих данных: хорошая общая метрика ещё не гарантирует хороший результат на конкретной площадке.
RF-DETR однозначно стоит рассматривать и тестировать на своей задаче. Но слепо доверять benchmark'ам и выбирать архитектуру только по месту в таблице мы бы не рекомендовали.
Ещё хотим добавить, что и само семейство YOLO тоже не остановилось на v8: в актуальном YOLO26 уже есть end-to-end NMS-free inference и отдельные оптимизации под real-time/edge deployment.

Как ИИ снижает риски несчастных случаев