Чтобы ответить на вопрос «Есть ли жизнь после Nvidia?», мы продолжаем поиск альтернативных вычислительных устройств, с помощью которых надеемся в дальнейшей перспективе решать задачи по распознаванию транспорта и пешеходов.

Мы — CodeInside — аутсорсинговая ИТ-команда, открывшая продуктовое направление и разработавшая ряд цифровых решений для города и бизнеса на основе нейросетевых технологий Machine Learning (ML) и Computer Vision (CV).

Наш флагманский продукт — Smart Traffic System (STS) — система мониторинга транспортных потоков для «Умного города» на основе ML и CV. Смена инфраструктуры для развертывания системы заставила нас, разработчиков, заняться поиском альтернатив линейки аппаратных и программных платформ Jetson от компании Nvidia. Это же, возможно, позволит присвоить системе STS статус «кроссплатформенная».

В предыдущей серии

В первой части исследования мы развернули STS на аппаратной платформе Rockchip RK3588S. Теперь переходим к работе с другим устройством, а именно — SOPHON AI Micro Server SE5-16.

Что имеем сейчас

В течение пилотирования устройства производилось исследование возможности запуска сервисов Smart Traffic System. Особое внимание требуют сервисы, которые в базовом варианте (при использовании Nvidia Jetson) используют ресурсы видеокарты. Такими сервисами являются Traffic detector и Plate recognition.

Traffic detector

Для переноса Traffic detector необходимо решить задачи:

• Object detection — по детекции (распознаванию) объектов;

• Object tracking — по трекингу (отслеживанию) объектов;

Задача Object detection решается с помощью детектора YOLOv8. Данный детектор достаточно распространённый и проблем с конвертацией для использования TPU на базе SOPHON не возникло. Конвертация произведена успешно для базового YOLOv8, а также для переобученной модели.

При решении задачи Object tracking возникла проблема. В базовом варианте при использовании Nvidia Jetson в качестве Object tracking алгоритма реализован NvDCF. NvDCF — это оптимизированный при помощи CUDA трекер DCF. Исходный код скрыт, так как для использования предоставляется только скомпилированный .so файл. Было решено исследовать примеры из официального репозитория:

• DeepSORT;

• Byte Tracker.

В репозитории представлено две реализации решения DeepSORT: с использованием OpenCV и с использованием BMCV — это специализированная библиотека и инструмент, разработанный компанией SOPHON (иногда также называемой Bitmain) для обработки задач компьютерного зрения на базе TPU. Решение на базе OpenCV на текущем этапе исследования показало достаточную точность, но недостаточную скорость inference. 

В связи с этим было решено попробовать запустить решение DeepSORT BMCV, так как оно больше опиралось на библиотеки SOPHON и могло быть более оптимизированным, в сравнении с DeepSORT OpenCV. Изначально мы хотели добиться скорости обработки в 10 кадров в секунду и точность, сравнительную с Jetson. При использовании BMCV удалось достичь требуемой скорости inference, однако по точности результат ухудшился.

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

Далее было произведено исследование Byte Tracker. На базе данного алгоритма удалось достичь требуемой точности и скорости обработки (не менее 10 FPS). Было проведено тестирование, результаты, которого представлены в таблице 1.

Таблица 1. Результаты тестирования.

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

Основная проблема при переносе детектора трафика — это работа в режиме реального времени. При использовании платформы Nvidia Jetson работа осуществляется с частотой в 10 FPS. При том, что с камеры видеопоток поступает с частотой в 25 FPS.

Осуществляется это с помощью плагина Videorate из Gstreamer. При запуске на Sophon не использовалось средств Gstreamer, поэтому регулирование входной скорости кадров осуществлялось с помощью базовых средств Python и OpenCV. При пропуске 2 кадров трекер стал некорректно работать и постоянно менять идентификаторы у треков.

Но это были первые тесты, дальше - лучше :)

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

Алгоритм работы не является специфичным. Средствами OpenCV производится получение кадра, он изменяется под размер модели нейронной сети, далее обрабатывается через YOLO, после чего результаты отправляются в ByteTracker. Результаты трекера обрабатываются нашим алгоритмом подсчета объектов по направлениям. И параллельным потоком производится визуализация обработанных кадров, как показано выше на Рисунке 2.

Таблица 2. Результат тестирования RTSP.

Для улучшения точности требуется более глубокая настройка трекера.

Также была проверена возможность запуска 2-х потоков для Traffic detection. При работе в таком режиме скорость обработки увеличивается в среднем на 10-15 мс (110-130 мс/кадр), общее потребление ресурсов процессора в сумме составляет около 50%, общее потребление оперативное памяти поднимается до 700±5 МБ, а нагрузка на TPU варьируется от 30% до 40% при потреблении памяти TPU 110 МБ из 9 ГБ. Такие результаты получены без трансляции. Тесты проводились при RTSP-соединении с камерой. 

При тестировании 3-х потоков нагрузка на процессор возросла до 75%, на TPU до 160 МБ потребления и 40-50% с общим потреблением оперативной памяти в 760-770 МБ, скорость обработки составляет 110-170 мс/кадр. 

При тестировании 4-х потоков: процессор потребляет до 85%, TPU до 220 МБ потребления и 40-50% нагрузки, общее потребление оперативная память 850 МБ, скорость обработки составляет 110-190 мс/кадр.

Plate recognition

Задача распознавания номера состоит из 3-х этапов:

1. Детекция 4-х точек рамки номера;

2. Приведение рамки номера к положению параллельно горизонту;

3. Чтение текста с рамки номера.

Для реализации 2-го пункта не требуется аппаратных ускорителей, Поэтому перенос этого решения не вызывает никаких трудностей. Для пунктов 1 и 3 были разработаны «кастомные» модели, которые успешно конвертировались в необходимый для SOPHON формат.

Конвертация в onnx для Plate recognition описана в статье «Разработка производительного распознавателя автономеров для edge-устройств». А для YOLO конвертер уже присутствует в репозитории SDK от производителя. Для запуска любого примера требовалась сборка модели под формат bmodel. Как позже выяснилось, конвертация моделей из onnx в bmodel производится при помощи docker-образа, который разворачивается на стороннем ПК. На нем собирается модель, после чего ее можно переносить на SOPHON и использовать. Инструкция по развертыванию Docker на компьютере.

Сложности в работе с SOPHON

Первые трудности при работе с SOPHON начались чуть ли не сразу.

На устройстве была предустановлена ОС Debian 9, на которой нельзя установить Python той версии, которая требуется для запуска примеров. Найти необходимый образ ОС оказалось не сложно. Переустановка системы реализована достаточно удобно. Распаковываем архив с образом ОС на microSD карту, вставляем в SOPHON и ждем 5-10 минут.

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

Дальнейший план исследования

По итогам пилотирования получилось полностью перенести Traffic tracker и Plate recognition на SOPHON. В режиме реального времени, при соединении с камерой по RTSP проект корректно работает. Основной целью дальнейшего исследования является улучшение ByteTracker, либо портирование других трекеров на SOPHON для повышения точности трекинга объектов.

Был ли у вас опыт переноса ПО на другую платформу? Будем рады почитать про ваш опыт в комментариях.