В России наблюдается интерес к комплексным системам автоматизации строительства, но их внедрение — долгий и сложный процесс. Поэтому чаще застройщики предпочитают точечные решения. Появился спрос на специализированные нейросетевые микросервисы для подключения к готовым системам заказчика.
Мы отметили эту тенденцию после одного примечательного проекта по мониторингу процесса строительства. Фактически сначала нас попросили сделать «то, не знаю что», причем в очень сжатые сроки. Ситуация могла обернуться провалом, но мы справились и нашли новую перспективную нишу для разработки новых продуктов. Сейчас расскажу, как это было.
Правильный подход к разработке VS суровая реальность
Автоматизация строительства охватывает широкий спектр задач: необходимо следить за техникой на площадке, оценивать количество использованного материала и даже искать трещины на штукатурке. Однако большинство кейсов сводится к мониторингу тех или иных процессов.
Но какие именно показатели нужно отслеживать и как их измерять? Чтобы это выяснить, нужно пройти через этап плотного общения с заказчиком, составить детальное техническое задание. Например, для обеспечения безопасности на стройплощадке необходимо детектировать дым, отслеживать перемещения рабочих, проверять наличие у них средств защиты и распознавать гос. номера въезжающего транспорта.
В идеальном мире заказчик уже имеет почти готовое ТЗ и четкое понимание своих потребностей, но в реальности бывает иначе. В этом проекте клиенту требовалось автоматически отслеживать, идет ли строительство по намеченному плану. Это важно для отчетности и бизнеса — некоторые категории сделок с недвижимостью невозможны до тех пор, пока здание не будет почти готово.
Заказчик хотел исключить человеческий фактор из процесса мониторинга, снизить число подтасовок и злоупотреблений, но на старте проекта было непонятно, как автоматически отслеживать прогресс работ. Нам дали несколько недель на раздумья, свободу в выборе решения и способов его реализации. После обсуждения мы решили считать построенные этажи при помощи машинного зрения.
Подсчет этажей: кажущаяся простота и скрытая сложность
На первый взгляд может показаться, что нет ничего проще, чем посчитать, сколько этажей построено за N дней. Достаточно посмотреть видео с камер на стройплощадке и записать получившееся число — справится любой сотрудник. Однако это не так просто, когда речь идет о большом застройщике с сотнями объектов и тысячами камер. Человек просто не может одновременно получать, агрегировать и быстро без ошибок анализировать столько информации. Здесь нейросети покажут лучший результат, но перед стартом разработки возникают вопросы:
Что именно считать этажом?
Под каким углом размещать камеры, чтобы определить, построен ли этаж?
По какому элементу считать этаж завершенным — по окну? Но на этаже может быть несколько окон, в том числе одно над другим. По фасаду? Но эта сторона этажа может быть построена раньше, чем весь этаж.
Как учитывать подземные этажи?
У заказчика не было готовых ответов, поэтому мы самостоятельно сформулировали концепцию решения и описали базовые ограничения будущего решения:
Для нормального распознавания этажей необходима четкая видимость стройплощадки без значительных препятствий, блокирующих обзор этажей (здание должно просматриваться целиком).
Возможность отличать этажи друг от друга. Этаж не должен представлять собой сплошную стеклянную поверхность, окна должны быть разделены.
Подземные этажи не учитываются из-за отсутствия видимых признаков для их обнаружения.
Достаточная освещенность для четкого различения деталей. При съемке в сумерках или ночью система может давать некорректные результаты.
Минимальные атмосферные помехи: туман, сильный дождь или пыль могут ухудшать видимость и снижать точность.
Стабильные платформы для съемки, обеспечивающие четкие изображения без существенного смазывания. Это на случай, если для мониторинга будут использоваться дроны.
Прописывать и обсуждать требования с заказчиком важно, особенно в ситуации, когда у клиента их фактически нет. Часто от этого зависят используемые технологии. Например, в нашем проекте надо было применять другой метод подсчета этажей, если бы попадались овальные здания или постройки какой-то другой сложной формы. А если нужен мониторинг строительства на этапе котлована, что и как там отслеживать?
В результате мы сошлись на том, что сначала будем работать только с типовой многоэтажной застройкой, а под другие типы строительства потребуются другие метрики, методы измерения прогресса и алгоритмы, которые мы разработаем на следующих этапах проекта.
Быстрое решение без оверинжениринга
После получения заказа мы оперативно сформировали рабочую группу из руководителя ML-проектов с опытом разработки ERP-систем, лида по Data Science и нескольких разработчиков.
В первую очередь нужно было ответить на вопрос: а что считать этажом? Четких требований и привязки к каким-либо нормативным документам у нас не было, поэтому приняли за этаж все, что построено от перекрытия до перекрытия. Далее мы подключили к работе внешнюю команду для разметки данных.
Подготовка датасета
Нам требовался небольшой, но качественный массив данных:
Около 1500 снимков зданий на разных стадиях строительства под разными углами, в разное время суток и при различном освещении.
Аннотации с указанием количества видимых этажей на каждом изображении.
По возможности, последовательные кадры одного здания для отслеживания прогресса строительства.
Изображения, сделанные в неблагоприятных условиях (например, при плохой погоде) для повышения устойчивости модели к таким помехам.
Чтобы сразу получить подходящий датасет, мы составили для разметчиков протокол подсчета этажей с несколькими ключевыми правилами:
Правило 1: не считать этажом конструкцию без перекрытия/покрытия, даже если есть стены.
Правило 2: если у здания есть колонны и не видно, сколько этажей скрывается за ними, принимаем область за колоннами за 1 этаж.
Правило 3: лифтовые шахты не считаются этажом.
Таких пограничных случаев было достаточно много, и по каждому пришлось принимать решение и прописывать правило обработки. Усилия оправдались: инструкции позволили команде разметки действовать автономно и не отвлекать инженеров от подготовки пайплайна.
ML-пайплайн для подсчета этажей и первые результаты
Из-за сжатых сроков мы решили использовать open source: предобученную YOLO-World для обнаружения зданий и предварительно тренированную Dino v2 для извлечения фичей и классификации.
Наш подход заключался в анализе статичных кадров с камер на стройплощадке. На вход YOLO-World подается изображение строящегося здания, внутри происходит его детекция в формате BBox. Вырезанное изображение продается на вход Dino v2, где происходит классификация на N классов, где N соответствует количеству этажей от 0 до 50.
Чтобы провести первые тесты еще до получения основного датасета, мы разметили картинки, сгенерированные нейронкой по текстовому запросу: «Нарисуй строящиеся здание в 30 этажей». Использовали Stable Diffusion и ControlNet (Depth).
С такими некачественными сгенерированными данными мы не добились хоть сколько-нибудь точного подсчета. Однако через 5 дней после начала разметки внешняя команда предоставила первую партию из 1,5 тысяч снимков с аннотациями. В итоге использовать синтетику мы не стали. На датасете из реальных фотографий точность нейросети приблизилась к 80%.
Однако мало обучить модели детектить здания и считать этажи. Надо еще сделать из всего этого решение «под ключ».
Подсчет этажей как сервис
Мы упаковали пайплайн в Docker-контейнер, подключили Facet API и разместили на сервере. Интерфейс — REST API, но можно использовать любой другой (GRPC, GraphQL, WebSocket). Ну вы поняли: гибко, кастомно.
Работает это так:
Получаем от заказчика фото зданий с уникальным ID. Важно, чтобы здание занимало весь кадр. Это может быть стоп-кадр с видеопотока или RTSP-ссылка. Зная реквизиты камеры, сами вырежем подходящий кадр.
YOLO-World детектирует здание.
Dino v2 берет берет детектор по BBox, считает этажи и возвращает JSON с ID, количеством этажей и датой.
Получился ограниченный, узкоспециализированный MVP. К счастью, нам не нужно было считать этажи в реальном времени, ведь строительство идет достаточно медленно. Чтобы получать актуальные данные, будет достаточно нескольких наблюдений в день. Поэтому быстродействие сервиса на том этапе разработки нас особо не волновало. Даже с довольно тяжелой нейросетью можно обойтись без GPU. Для сравнения: YOLO на CPU — 2 сек, LoRA на CPU — 0.3 сек, на GPU — 0.1 сек.
Мы сэкономили время на оптимизации, организации очереди и подключении БД. На этапе MVP мы просто брали фото и отдавали информацию о ходе строительства по готовности, но к сервису можно было подключить S3-хранилище. В перспективе данные данные из этой базы можно будет использовать для анализа рабочего процесса: например, сравнения производительности на отдельных площадках или поиска наиболее медленных и трудозатратных этапов стройки.
Результат и точность решения
После дообучения и дополнительного тюнинга точность нашей нейросети достигла 82%.
Val on the +200 images
Accuracy +-0: 0.59
Accuracy +-1: 0.90
Accuracy +-2: 0.96
MAE: 0.56
Average accuracy: 0.82
Таким образом, иногда наше решение допускает ошибки в ±2 этажа. Казалось бы, этого недостаточно, ведь никому не нужен сервис по подсчету этажей, который не может определить, 8 или 10 этажей готово. Однако такие выбросы (из-за непогоды, нависающих кранов и т. п.) можно сгладить за счет статистики, не тратя время и деньги на переобучение нейронок. Проводя измерение два-три раза в день и собрав информацию, допустим, за неделю, можно исключить аномальные значения, а затем, например, перевести этажи в процент выполненных работ. Таким образом, поставленная задача решена скромными средствами.
Разработка в сжатые сроки и без ТЗ иногда оправдана
Браться за срочный проект без четкого ТЗ — нежелательная практика, которая часто ведет к непредсказуемым результатам. Ведь, как говорится: «Без ТЗ и результат ХЗ». Но всякое правило имеет исключение.
При большом опыте в узкой нише можно справиться с небольшой задачей не дожидаясь детальных требований. Можно сработать на опережение — реализовать прототип и предложить реализацию, которая станет затравкой для дальнейшего роста проекта. В условиях острой конкуренции бизнесу часто важно получить решение буквально за пару недель (пускай сначала несовершенное), а не ждать, пока будет разработана комплексная система, которые так любят предлагать разработчики на аутсорсе.
В рамках этого кейса мы оперативно закрыли срочную потребность, а затем спокойно доработали сервис контроля хода строительства.
Теперь, после доработок, мы предлагаем его в двух вариантах: SaaS на наших мощностях и On-Premise на инфраструктуре заказчика. Причем необходимое железо можно разместить не только в серверной, но и прямо на строительной площадке. Мы собрали прототип на базе NVIDIA Jetson в защищенном от непогоды корпусе.
К слову, детекция этажей не единственное перспективное направление в этой нише. В аналогичном формате можно реализовать алгоритмы:
детекции средств индивидуальной защиты (жилетов, касок);
детекции персонала;
детекции строительной техники;
мониторинга активности персонала и техники (их перемещения по стройке);
детекции государственных регистрационных знаков строительной техники;
обнаружения задымления и возгораний.
