Камера, нейронки и дымящийся микро-ПК: дешевая и практичная альтернатива радару

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

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

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

Старт проекта

После того, как мы реализовали систему распознавания ДТП по видео с дорожных камер, заказчик поставил новую задачу — разработать ПО для стационарного комплекса фотовидеофиксации дорожных нарушений (КФВФ), способное в режиме реального времени контролировать скорость транспорта. В перспективе новая система должна стать более доступной по цене заменой программным решениям от зарубежных вендоров.

Софт и оборудование

ПО комплекса фотовидеофиксации не раздает штрафы — за это отвечают вышестоящие IT-системы. Так что нашей задачей было создать ПО для распознавания номеров, генерации bbox, формирования треков и измерения скорости движения транспортных средств.

В правом верхнем углу кадра виден радар. Под ним расположены прожекторы инфракрасной подсветки. Между ними скрывается IP-камера. Белая антенна отвечает за связь, а микрокомпьютер и остальная электроника спрятаны в сером распределительном щите
В правом верхнем углу кадра виден радар. Под ним расположены прожекторы инфракрасной подсветки. Между ними скрывается IP-камера. Белая антенна отвечает за связь, а микрокомпьютер и остальная электроника спрятаны в сером распределительном щите

Что до технических средств, то конструктивно комплекс состоит из четырех устройств, закрепленных в статичном блоке на столбе у автотрассы:

  • микро-ПК Nvidia Jetson Nano;

  • черно-белой IP-видеокамеры;

  • инфракрасной подсветки;

  • радара.

Вместе они позволяют в режиме реального времени наблюдать за транспортным потоком и сохранять данные об автомобилях. Даже если комплекс останется без связи с «центром», например, из-за обрыва интернет-кабеля, данные останутся в памяти микрокомпьютера.

Микрокомпьютер

Jetson — зрелая платформа с подробной документацией, но ограниченной вычислительной мощностью. Так что запуск на ней нескольких нейросетей стал интересным профессиональным вызовом.

Нам долго не удавалось достичь обработки видеопотока с частотой (FPS), достаточной для трекинга транспортных средств с приемлемой погрешностью. Прежде чем попасть в нейросеть, сигнал проходит через буфер камеры и серию подготовительных процедур. К тому же, чем выше FPS, тем сложнее железу обрабатывать видеопоток в реальном времени.

IP-камера

Здесь нас ждал сюрприз. Большинство популярных IP-камер работает на потоковом протоколе RTSP, который выдает наружу видеотрансляцию с настройками из коробки.

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

Радар

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

В общем, отказ от радара мог бы заметно удешевить и упростить весь комплекс. Мы решили, что попробуем добиться сопоставимой точности видеофиксации при помощи одной только камеры и нейросетей. Заказчик поддержал идею, но с оговоркой. В первую очередь мы должны реализовать поддержку радара, а затем уже думать о том, как комплекс будет работать без него.

Нейронные сети и архитектура проекта

Проект стартовал на Python — так проще работать с гипотезами. Его основой стала YOLO — нейронная сеть, которая за один проход прогнозирует для изображения положение ограничивающих прямоугольников и вероятности классификации. В сочетании с методом немаксимального подавления (NMS) этот алгоритм позволяет значительно повысить точность локализации объектов и уменьшить число ложных срабатываний.

В процессе разработки мы запускали на Jetson до 6 нейросетей, но им там было тесновато. Так что мы пошли по пути объединения нейронок, занимающихся отдельными задачами детекции, например определением ТС и плашек ГРН. Взяли облегченный вариант модели YOLOv5s, научили распознавать номера и заточили под наши задачи. Для дообучения мы подготовили новый набор данных на основе датасета COCO и сократили число классов распознаваемых объектов до пяти: "numberplate", "car", "truck", "bus", "motorcycle".

При разработке модулей, работающих с изображениями и нейронными сетями, использовали библиотеки для работы с CUDA/cuDNN и OpenCV, а нейронки обучали на PyTorch.

Применение фреймворка ENOT позволило поднять быстродействие нейросетей на микрокомпьютере почти в 2 раза. Правда, вместе с ускорением произошел и значительный рост потребления оперативной памяти, поэтому от него пришлось отказаться. 

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

  1. Детектор — находит на картинке с камеры транспортное средство и его номер.

  2. Распознаватель (OCR) — считывает символы на номерных знаках.

Источник: Number Plates of around the World … What they tell?
Источник: Number Plates of around the World … What they tell?

В случае OCR большой сложностью стало распознавание номеров на иностранных автомобилях. Многие используемые в них символы не встречаются на российских номерах и сильно затрудняют идентификацию.

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

Бок о бок с этими двумя нейронными сетями на Jetson запущено ПО для радара, предоставленное заказчиком. Оно проводит измерения и отправляет данные в основное объектное хранилище Minio, а еще выступает посредником между радаром и нашими нейросетями.

Первоначально архитектура системы была монолитной — все входящие в нее нейросети запускались последовательно. Затем, для повышения стабильности и отказоустойчивости, мы разбили архитектуру на контейниризированные микросервисы, работающие асинхронно. В нынешнем виде архитектура КФВФ состоит из нескольких модулей, которые взаимодействуют через In-Memory брокера RabbitMQ.

Аналитический модуль

Взаимодействует с IP-камерой через API и работает над обработкой полученных кадров с помощью нейросетей. Его главный компонент — уже упомянутый детектор ТС, рисующий bounding box (ограничивает цветными рамками объект детекции и отвечает за трекинг). Здесь же происходит детекция сигналов светофоров.

Сервис распознавания плашек ГРЗ

Получает информацию о местонахождении номерных знаков от детектора и запускает их распознавание. Основной компонент этого модуля — нейронная сеть YOLO

Модуль агрегации

Этот механизм сопоставляет данные с камеры и радара. ГОСТы предъявляют очень жесткие требования к точности измерений на дорогах, так что, если радар подключен к системе, мы используем его по максимуму и сравниваем его показания с результатами работы компьютерного зрения.

Кроме того, при помощи алгоритмов матчинга этот модуль связывает данные из детектора и модуля распознавания плашек ГРМ с данными, полученными с радара. Собранная информация постоянно агрегируется в итоговое сообщение и через RabbitMQ отправляется по сети на обработку в дата-центр. Там данные используются для выявления различных нарушений ПДД, включая пересечение разметки, выезд в зону остановки и так далее.

Модуль определения сдвига камеры

После установки КФВФ на конкретном участке дороги необходимо настроить сервис распознавания: разметить кадр и указать те участки изображения, где следует искать номера. 

Синяя рамка ограничивает зону контроля
Синяя рамка ограничивает зону контроля

Точно обозначив зону контроля, мы можем, например, исключить из рассмотрения встречный поток машин, попадающий в поле зрения комплекса. Однако из-за резких порывов ветра, птиц, и даже просто из-за вибрации от проезжающих машин камера со временем может смещаться, а с ней смещаются и зоны детекции. Сильные сдвиги могут вызывать сбои, так что их необходимо засекать при помощи отдельного алгоритма. Мы уже подробно рассказывали о нем в посте о подсчете пассажиров на остановках.

Как работает трекинг и определение скорости

После того, как нейросеть-детектор научилась определять автомобили, мы занимались отслеживанием зафиксированных объектов. При видеофиксации автомобиля алгоритм трекинга присваивает каждому ТС уникальный ID, который служит для этого снимка URL-адресом в базе Minio. ID помогает соотнести детекции на отдельных кадрах с номером конкретного автомобиля. 

Следующим шагом после распознавания и отслеживания машин стало определение скорости по анализу изменения местоположения объекта на разных кадрах видео. Это делается при помощи матричного преобразования координат через нахождение матрицы гомографии (homography matrix).

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

Матрица гомографии вычисляется с помощью функции библиотеки getPerspectiveTransform из OpenCV по формуле:

\begin{equation} \begin{bmatrix} u \\ v \\ w \end{bmatrix} = M  \times\begin{bmatrix} x_1 \\ y_1 \\ 1 \end{bmatrix}, x_2 = u/w, y_2 = v/w \end{equation}

M — матрица гомографии, x1,y1 — координаты точки на исходном изображении, x2,y2 — координаты точки на перспективе (вид сверху)

Пока ТС находится в зоне работы комплекса. Алгоритм собирает с каждого кадра координаты, указывающие на середину нижней части рамки (bounding box) транспортного средства:

Эти координаты преобразуются в координаты на «виде сверху». В момент, когда ТС выходит из зоны обзора системы, алгоритм отслеживает изменение координат ТС, соотнося его с пикселями на кадре. После чего строит трек ТС на кадре и на двухмерной проекции трассы.

Работа алгоритма на примере видеозаписи с обычной дорожной камеры. Зона контроля ограничена синими линиями (шумность картинки- следствие того, что хабр ограничивает размер загружаемых на сайт gif)
Работа алгоритма на примере видеозаписи с обычной дорожной камеры. Зона контроля ограничена синими линиями (шумность картинки- следствие того, что хабр ограничивает размер загружаемых на сайт gif)

В итоге при знании точного местоположения транспортного средства в отдельно взятый момент времени расчет скорости сводится к школьным курсам физики и геометрии. А вот детекция запрещающего сигнала светофора по черно-белой камере могла бы попасть в учебник как задача со звездочкой.

Определение сигнала светофора

Хотя по статистике более 90% нарушений ПДД связано с превышением скоростного режима и игнорированием дорожных указателей, комплексы фото-видеофиксации отслеживают и проезд на красный свет.

Реализовать такую функцию при помощи машинного зрения проще, чем можно подумать. Дело в том, что расположение сигналов светофора зафиксировано в международных правилах. Красный всегда располагается сверху, так что черно-белую камеру не пришлось учить различать цвета. Нужно было лишь найти на картинке сам светофор и зафиксировать момент, когда загорится нужная лампочка. Это можно сделать по изменению гистограммы яркости изображения.

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

Отладка и тестирование системы 

Перечисленные нейросети и алгоритмы компьютерного зрения требовали тонкой настройки, невозможной в «синтетических» тестах или на парковке у офиса. Требовались полноценные полевые испытания. 

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

Сперва специально обученные сотрудники выехали на место установки стенда и выставили на дороге 4 ориентира — «якоря», видимых на камере. Измерив расстояние между «якорями» в физическом мире, мы получили точные данные для расчета матрицы гомографии.

По сравнению с методами разметки на базе различных характеристик изображения (например, vanishing point) это более сложный процесс. Однако ручная разметка точнее. К тому же, на установку КФВФ все равно выезжает целая бригада, которая без проблем может уделить время и установке «якорей». Да, в природе существуют алгоритмы, позволяющие обойтись без них и не потерять в точности, но они используют куда больше камер и в основном применяются для автономного вождения, например в Tesla. Так что это решение оправдано.

Кроме того, мы снимали показания скорости транспортного потока с радара и калибровали по ним алгоритм определения скорости по картинке. Затем пришло время доказать эффективность наших алгоритмов. 

Первый показатель, на который ориентировался заказчик в процессе полевых испытаний, — число автомобилей, определенных в общем потоке. Его проверяли во время «итоговых проездов» при помощи отдельной обзорной камеры, которая на протяжении заданного времени записывала на видео все проезжающие мимо ТС. После этого подсчитывали машины на видеозаписи и сравнивали полученное число с информацией в базе данных КФВФ.

Оказалось, что на практике процент распознанных ТС «плавает», в зависимости от загруженности трассы. Большие грузовые автомобили и автобусы иногда закрывают легковушки от камеры. Тем не менее при помощи оптики нам удалось добиться точности распознавания от 90%. Это соответствует нормам ГОСТ для систем фотовидеофиксации на основе радаров.

Второй важный показатель — погрешность при определении скорости. Здесь мы снова ориентируемся на стандарты, принятые для комплексов с «радарным» измерением скорости, так как регуляторки для оптических систем пока просто нет.

Точность измерения скорости проверяли так: 

Испытатель садился в машину и брал с собой трекер, определяющий скорость по спутнику. Трекер записывал скорость через определенные отрезки времени, присваивая каждой записи метку времени (timestamp) с точностью до миллисекунды. Эти данные и сравнивали с показателями КФВФ.

Оказалось, что погрешность при определении скорости составила до 5% от абсолютного значения скорости. Таким образом, при скорости 100 км/ч погрешность около 5 км/ч. На скорости в 200 км/ч не более 10 км/ч. Это при том, что нештрафуемый порог превышения скорости в России по прежнему составляет 20 км/ч.


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

Мы реализовали требования из технического задания:

  • Определение скорости и номера ТС только по камере.

  • Сочетание двух методов измерения скорости — оптического и радарного.

  • Распознавание сигналов светофоров. 

  • Высокую точность распознавания номеров ТС — от 90%.

  • Высокую точность вычисления расстояния до ТС — до 2 метров (при том, что камера обычно находится на расстоянии 50-70 метров от зоны детекции).

  • Высокую точность определения скорости ТС (погрешность от 1 до 3 км/ч). 

  • Соответствие качества материалов фотовидеофиксации требованиям ГОСТ даже при замерах на высокой скорости.

Со временем КФВФ на нейросетях наверняка найдут применение на российских дорогах. Уже в ближайшем будущем метод определения скорости по оптике сможет конкурировать с радарами и лидарами, делая дорожный мониторинг доступнее. Технологии к этому готовы, осталось дождаться изменений в законодательстве.

Источник: https://habr.com/ru/companies/magnus-tech/articles/741902/


Интересные статьи

Интересные статьи

На днях Slack объявил, что в марте 2023 года полностью прекращает деловые отношения с клиентами из России. Компания планирует приостановить любой доступ к рабочим пространствам россиян 21 марта 2023...
В комментариях на статью "Калибровка и профилирование мониторов" был заметен некоторый скепсис относительно необходимости таких процедур как калибровка и профилирование монитора посредством достаточ...
Исключения – это базовый элемент многих языков программирования. Они обычно используются для обработки аномальных или непредусмотренных условий, при устранении которых необходим особый подход, нарушаю...
Инфраструктура открытых ключей (PKI/ИОК) включает в себя множество различных объектов и механизмов работы с ними, а также протоколы взаимодействия объектов друг с другом (например, проток...
Рано или поздно, фронтенд - разработчик устает играть со своими фреймворками, устает докучать коллегам - бэкендерам, устает играть в девопс и начинает смотреть в сторону ...