Pull to refresh

Есть ли жизнь после Nvidia? Часть 2: исследование возможностей SOPHON AI Micro Server SE5-16

Level of difficultyEasy
Reading time7 min
Views1.5K

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

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

CodeInside
CodeInside

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

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

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

Сравнение устройств Rockchip, SOPHON и Nvidia
Сравнение устройств Rockchip, SOPHON и Nvidia
GPU (графический процессор) — это процессор, предназначенный для...

... выполнения матричных операций. Он включает сотни или тысячи арифметико-логических устройств (ALU) и способен параллельно обрабатывать большое количество вычислений.

NPU (нейропроцессор) — это специализированный процессор для...

... ускорения задач нейронных сетей. NPU энергоэффективен и подходит для долгосрочного использования в непрерывных нейросетевых вычислениях.

TPU (тензорный процессор) — это специализированные процессоры, для...

... приложений искусственного интеллекта. Они предназначены для эффективного выполнения тензорных операций, что делает их особенно подходящими для задач глубокого обучения. TPU в 15-30 раз производительнее современных GPU и CPU в задачах inference, но из-за ограниченного производства могут быть дорогими.

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

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

Traffic detector

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

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

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

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

Почему мы не использовали YOLOv10?

Переход на более новые версии мы производим по мере необходимости. В основном он осуществляется из-за улучшения показателей производительности в новых версиях. Точность не сильно интересует, так как даже YOLOv5s модели хватает, чтобы в совокупности с трекером показывать 98% точности трекинга на Nvidia Jetson.

При решении задачи 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. Схема перекрёстка
Рисунок 1. Схема перекрёстка
Рисунок 2. Фото перекрёстка

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

Nvidia Jetson

SOPHON SE 5

Из направления №1

Bus

12

10

Car

254

257

Truck

7

4

В направлении №1

Bus

14

13

Car

235

228

Truck

6

5

Ambulance

0

1

Из направления №2

Bus

4

1

Car

74

71

Truck

2

1

В направлении №2

Bus

2

1

Car

81

79

Truck

1

2

Ambulance

2

1

Из направления №3

Bus

10

12

Car

205

205

Truck

5

5

Ambulance

2

2

В направлении №3

Bus

12

11

Car

257

261

Truck

8

5

Из направления №4

Bus

2

2

Car

129

129

Truck

2

2

В направлении №4

Bus

0

0

Car

89

94

Truck

1

0

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

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

Почему именно 10 FPS?

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

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

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

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

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

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

Nvidia Jetson

SOPHON SE 5

Из направления №1

Bus

21

16

Car

110

108

Truck

3

1

В направлении №1

Bus

16

9

Car

92

94

Truck

3

1

Из направления №2

Bus

18

8

Car

77

78

Truck

1

0

В направлении №2

Bus

16

12

Car

102

102

Truck

3

1

Из направления №3

Bus

0

0

Car

55

56

Truck

3

1

В направлении №3

Bus

8

7

Car

47

46

Truck

1

1

Из направления №4

Bus

3

4

Car

37

40

Truck

2

1

В направлении №4

Bus

2

0

Car

38

40

Truck

2

0

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

Также была проверена возможность запуска 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 для повышения точности трекинга объектов.

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

Tags:
Hubs:
Total votes 2: ↑2 and ↓0+3
Comments2

Articles