Умная стройка как (микро)сервис: следим за возведением зданий

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

Мы отметили эту тенденцию после одного примечательного проекта по мониторингу процесса строительства. Фактически сначала нас попросили сделать «‎то, не знаю что»‎, причем в очень сжатые сроки. Ситуация могла обернуться провалом, но мы справились и нашли новую перспективную нишу для разработки новых продуктов. Сейчас расскажу, как это было.

Правильный подход к разработке 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). Ну вы поняли: гибко, кастомно.

Работает это так: 

1. Получаем от заказчика фото зданий с уникальным ID. Важно, чтобы здание занимало весь кадр. Это может быть стоп-кадр с видеопотока или RTSP-ссылка. Зная реквизиты камеры, сами вырежем подходящий кадр. 

2. YOLO-World детектирует здание.

3. 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 в защищенном от непогоды корпусе.

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

• детекции средств индивидуальной защиты (жилетов, касок);

• детекции персонала;

• детекции строительной техники;

• мониторинга активности персонала и техники (их перемещения по стройке);

• детекции государственных регистрационных знаков строительной техники;

• обнаружения задымления и возгораний.