3D-лидар на КПП склада: как автоматизировали проверку кузовов фур

На крупном складе производителя стройматериалов ежедневно под погрузку заходят десятки фур. Часть из них приезжает с деформированными кузовами: заниженная высота у кабины, неровные борта, наваренные крючки и кронштейны на стойках у дверей. Снаружи такой кузов выглядит нормально — проблема обнаруживается, когда погрузчик с паллетой шириной 2,40 м упирается в выступ, которого там быть не должно. Результат — повреждённый груз, развёрнутая машина и сорванный график отгрузки.

До автоматизации решение принимал человек: кто-то заглядывал в кузов и на глаз определял, пускать фуру под погрузку или разворачивать. Такой подход медленный, субъективный и не масштабируется при росте потока машин. Задача, которую поставил заказчик, — убрать человека из точки принятия решения и выдавать вердикт по объективным числам. Пороги жёсткие: ширина свободного прохода менее 2,43 м — отказ, высота от пола до горизонтальной балки менее 2,60 м — отказ, длина менее 8 м — отказ. Точность измерений — лучше сантиметра на глубине до 15 м от точки установки сенсора.

В качестве сенсора выбрали 3D-лидар. Лидар (Light Detection and Ranging) измеряет расстояния, испуская лазерные импульсы и фиксируя время их возврата, — на выходе получается трёхмерное облако точек, описывающее геометрию пространства. Для промышленных задач это стандартный инструмент там, где нужна субсантиметровая точность на больших дистанциях. Однако выбор конкретной модели оказался нетривиальным: лидар везли из-за рубежа, поставка занимала несколько месяцев, а проверить его в боевых условиях до закупки было невозможно. Команда построила геометрическую модель — не цифровой двойник объекта, а инженерную проверку «хватит или нет»: положение сенсора относительно проёма ворот, рабочая зона, граничные дистанции, поле зрения. Отдельно считали плотность точек на разных дистанциях: на ближнем крае облако может выглядеть убедительно, а на дальнем — точек уже не хватит для устойчивого геометрического вывода.

Архитектура системы разделена на два слоя. Первый — сенсорный: вендорский драйвер публикует поток данных в ROS 2 в формате PointCloud2 (бинарный массив с координатами и интенсивностью точек). Адаптер подписывается на этот топик, читает кадр и переводит его в массив NumPy. ROS 2 здесь работает исключительно как транспортный слой — вся прикладная математика вынесена в отдельный сервис с HTTP/API-интерфейсом. Такое разделение позволило не смешивать логику обработки данных с инфраструктурой фреймворка.

Обработка облака точек организована через два независимых контура. Контур 1 непрерывно анализирует поток: проверяет дисперсию координат и плотность точек в зоне интереса, чтобы подтвердить — объект заехал, остановился, сцена стабильна. Контур 2 находится в режиме ожидания и запускается один раз по триггеру от первого контура: выполняет финальную фильтрацию взвеси и пыли, выравнивает облака, сегментирует плоскости и рассчитывает геометрические параметры кузова. Первая версия алгоритма работала проще — запускала анализ при появлении критического числа точек в рабочей зоне. На реальном КПП это не сработало: фура маневрировала, сдавала назад неравномерно, могла заехать в зону только задней частью, а соседние машины провоцировали ложные срабатывания. Двухконтурная схема решила эту проблему.

Отдельную сложность создал стык ROS 2 и веб-сервиса. Попытка держать ROS-подписчика постоянно запущенным внутри долгоживущего веб-процесса приводила к ошибкам повторной инициализации контекста, зависаниям потоков и непредсказуемому поведению. Решение — короткие ROS-сессии: контекст поднимается только на время захвата одного кадра, после чего принудительно завершается. Для задачи «один снимок по запросу» это стабилизировало пайплайн и исключило утечки памяти. Наконец, промышленные серверы на КПП работают без графического окружения, поэтому интерактивные 3D-вьюверы недоступны. Тяжёлое облако точек конвертируется в плоские 2D-проекции и тепловые карты — лёгкие артефакты, пригодные для фиксации инцидентов оператором склада.