STM32 з нуля без HAL: Я змусив Luckfox думати: NPU, RetinaFace і перший inference. Частина 9

Серія «STM32 з нуля без HAL» · Частина 9 · Місяць 3

Колись GPU була лише іграшкою для геймерів. Сьогодні без них не існує сучасного AI.

А тепер з’явився ще один клас процесорів — NPU. Вузькоспеціалізовані чіпи, які роблять тільки одну річ: шалено швидко множать матриці.

І парадокс у тому, що цього виявилось достатньо, щоб запускати нейромережі прямо на tiny edge-платах з кількома ватами споживання.

RV1106 якраз має такий блок — RKNPU від Rockchip.

Третій місяць добігає кінця. Ми вже пройшли Device Tree, UART між Linux і STM32, налаштували GStreamer і підняли стрімінг з Luckfox. Залишився останній великий шматок пазла — NPU.

◆ Що таке NPU і навіщо він потрібен

CPU вміє робити все, але дорого з точки зору енергії і часу. Нейромережа — це мільйони операцій множення матриць. CPU робить їх послідовно, витрачаючи такти і енергію.

NPU (Neural Processing Unit) — це спеціалізований блок який робить тільки одне: матричні операції. Швидко і з мінімальним енергоспоживанням. Саме тому його ставлять у смартфони, відеокамери, і embedded плати для edge AI.

На RV1106 стоїть RKNPU від Rockchip. Перевіряємо що він живий:

dmesg | grep -i npu

[    3.441191] RKNPU ff660000.npu: RKNPU: rknpu iommu device-tree entry not found!, using non-iommu mode
[    3.441685] RKNPU ff660000.npu: RKNPU: Initialized RKNPU driver: v0.9.2 for 20230825
[    3.441774] RKNPU ff660000.npu: dev_pm_opp_set_regulators: no regulator (rknpu) found: -19

Драйвер версії v0.9.2 від 2023-08-25 — живий. /dev/rknpu є. Але це тільки ядро — userspace частина інша історія.

◆ Знаходимо частини пазлу

Для роботи з NPU потрібні три речі: драйвер (є), runtime бібліотека (librknnmrt.so), і модель (.rknn файл). Шукаємо:

find / -name "librknnmrt*" 2>/dev/null

/oem/usr/lib/librknnmrt.so

Є — але не там де очікуєш. Стандартний /usr/lib порожній. Бібліотека тут /oem/usr/lib.

⚠ Якщо будеш шукати через strings /usr/lib/librknnmrt.so — отримаєш No such file or directory. Не лякайся, шукай в /oem/usr/lib.

Перевіряємо версію:

strings /oem/usr/lib/librknnmrt.so | grep "librknnmrt version"

librknnmrt version: 1.6.0 (2de554906@2024-01-17T14:53:41)

І одразу бачимо в тих самих рядках, щось не так:

please try updating to the latest version of the toolkit2 and runtime
E RKNN: incompatible model version
E RKNN: Mismatch driver version

Rockchip вбудував попередження про версійний конфлікт прямо в бібліотеку, натяк — версії драйвера і runtime мають збігатись. Запам’ятовуємо: драйвер v0.9.2, runtime v1.6.0.

Чи знайде її лінкер? Перевіряємо:

echo $LD_LIBRARY_PATH

/oem/usr/lib:/oem/lib:

Пощастило — наш кастомний Buildroot образ вже має /oem/usr/lib в LD_LIBRARY_PATH. Нічого додатково налаштовувати не треба.

Шукаємо моделі:

find / -name "*.rknn" 2>/dev/null

Порожньо. Моделей на платі немає. Вони є в SDK на PC ми ще там поколупаємось.

◆ Перша спроба — rksmartdoor

В SDK Luckfox є папка project/app/rk_smart_door. Там лежать готові .rknn моделі: detection.rknn, recognition.rknn, headpose.rknn, fas_ir.rknn. Здається — ось воно, бери і запускай.

find ~/luckfox-pico/project/app/rk_smart_door -name "*.rknn" 2>/dev/null

.../algo/models/detection.rknn
.../algo/models/recognition.rknn
.../algo/models/headpose.rknn
.../algo/models/fas_ir.rknn

Відкриваємо CMakeLists.txt і бачимо:

target_link_libraries(${PROJECT_NAME}
    libpthread.a librt.a librockit.a librockchip_mpp.a librkaiq.a
    librtsp.a librkaudio_detect.a libaec_bf_process.a libm.a
    librockiva.a libstdc++.a librknnmrt.a librga.a libsmartIr.a)

⚠ rk_smart_door — це повноцінний продакшн додаток для розумного дверного замка. З UVC, ISP pipeline, RTSP стрімінгом, аудіо детекцією і SmartIR підсвічуванням. 10+ залежностей, збірка тільки в контексті повного SDK build.

Нам не потрібен готовий дверний замок ми зробимо свій. Зараз нам потрібен лише мінімальний inference. Йдемо далі.

◆ Просто — luckfoxpicorknn_example

Rockchip і LuckfoxTECH мають окремий репозиторій з мінімальними прикладами:

git clone https://github.com/LuckfoxTECH/luckfox_pico_rknn_example
ls luckfox_pico_rknn_example/example/

luckfox_pico_retinaface_facenet
luckfox_pico_retinaface_facenet_spidev
luckfox_pico_yolov5

Три приклади. Нас цікавить перший — RetinaFace + FaceNet. RetinaFace детектує обличчя (знаходить bounding box), FaceNet розпізнає (порівнює з еталоном).

Перевіряємо версію бібліотеки в репо:

strings luckfox_pico_rknn_example/lib/uclibc/librknnmrt.so | grep "librknnmrt version"

librknnmrt version: 1.6.0 (9a7b5d24c@2023-12-13T17:33:10)

⚠ Версія 1.6.0 збігається з платою. Але білди різні: репо 2023-12-13, плата 2024-01-17. Той самий мажорний реліз але дати різниці. Запам’ятовуємо як потенційне джерело проблем — перевіримо при запуску.

◆ Збираємо

CMakeLists бере toolchain з змінної оточення LUCKFOX_SDK_PATH. Встановлюємо і збираємо:

export LUCKFOX_SDK_PATH=/home/alex/luckfox-pico
cd luckfox_pico_rknn_example
./build.sh

Скрипт запитає інтерактивно:

1. uclibc або glibc → вибираємо 1 (uclibc — наш Buildroot образ)
2. який приклад → вибираємо 1 (luckfox_pico_retinaface_facenet)

[100%] Built target luckfox_pico_retinaface_facenet
-- Installing: .../install/uclibc/luckfox_pico_retinaface_facenet_demo/luckfox_pico_retinaface_facenet
-- Up-to-date: .../model/RetinaFace.rknn
-- Up-to-date: .../model/mobilefacenet.rknn
-- Up-to-date: .../model/test.jpg
-- Up-to-date: .../lib/librga.so

Зібралось з першого разу. Якщо цікаво більше то порівняй з rk_smart_door де треба весь SDK build — різниця відчутна.

Що отримали:

install/uclibc/luckfox_pico_retinaface_facenet_demo/
├── luckfox_pico_retinaface_facenet  ← бінарник
├── model/
│   ├── RetinaFace.rknn              ← детекція облич
│   ├── mobilefacenet.rknn           ← розпізнавання
│   └── test.jpg                     ← еталонне фото
└── lib/
    └── librga.so

Копіюємо на плату:

scp -o PubkeyAuthentication=no -r \
    install/uclibc/luckfox_pico_retinaface_facenet_demo \
    [email protected]:/root/

⚠ Прапор -o PubkeyAuthentication=no обов’язковий якщо SSH видає Too many authentication failures. Це відбувається коли в ~/.ssh/ накопичилось багато ключів і сервер відхиляє з’єднання до перебору всіх.

◆ Запускаємо. І одразу перший сюрприз

Заходимо на плату і запускаємо:

cd /root/luckfox_pico_retinaface_facenet_demo
./luckfox_pico_retinaface_facenet model/ test.jpg

./luckfox_pico_retinaface_facenet <retinaface model_path> <facenet model_path> <reference pic_path>

⚠ Програма очікує три окремі аргументи, а не папку і фото. З’ясувалось, щоtest.jpg це не вхідне зображення для детекції, це еталонне фото для FaceNet (reference face для порівняння). Детекція іде з камери в реальному часі. І достатньо замінити фото на свій фейс

Правильний синтаксис:

./luckfox_pico_retinaface_facenet \
    model/RetinaFace.rknn \
    model/mobilefacenet.rknn \
    model/test.jpg

Але перед запуском — обов’язковий крок.

◆ RkLunch-stop.sh — завжди перед NPU

RkLunch-stop.sh

Stop Application ...
  872 root     rkipc -a /oem/usr/share/iqfiles
rkipc active
...
rkipc exit

⚠ rkipc — це процес який керує камерою і ISP при звичайному завантаженні. Він тримає /dev/video* і може блокувати доступ до NPU або камери. Завжди зупиняй його перед запуском NPU демо через RkLunch-stop.sh.

◆ NPU живе

Запускаємо з правильними аргументами і наводимо камеру на обличчя:

init retinaface
init facenet
Retinaface Info
model input num: 1, output num: 3
input tensors:
  index=0, name=input.1, n_dims=4, dims=[1, 640, 640, 3], ...
output tensors:
  index=0, name=515  ← bounding boxes
  index=1, name=553  ← confidence scores  
  index=2, name=592  ← landmarks (5 точок обличчя)
Facenet Info
model input num: 1, output num: 1
input tensors:
  index=0, name=input.1, dims=[1, 160, 160, 3]
output tensors:
  index=0, name=313, dims=[1, 128]  ← 128-мірний embedding вектор
Init success

Моделі завантажились без помилок. Версійного конфлікту не сталось — 1.6.0 з репо і 1.6.0 з плати спрацювали разом.

Камера ініціалізується через rkaiq ISP, і починається детекція:

@ (105 63 176 134) 1.345
@ (105 60 176 130) 1.291
@ (99 60 170 130) 1.360
@ (102 60 173 130) 1.397

Кожен рядок — знайдене обличчя:

@ (x1  y1  x2  y2 ) score
@ (105 63  176 134) 1.345

x1 y1 — верхній лівий кут bounding box. x2 y2 — нижній правий. score — впевненість моделі. Значення 1.1–1.5 означає що модель впевнена.

Детекція стабільна, реальний час. NPU робить те для чого створений.

◆ Що далі — Стаття 10

Зараз програма виводить координати в консоль. У Статті 10 ці координати стануть командами:

Камера → RetinaFace на NPU (детекція)
    → вирізаємо ROI обличчя
    → HTTP POST на сервер з базою
        → сервер порівнює через FaceNet embeddings
        → відповідь: OK / UNKNOWN
    → якщо OK: UART3 → STM32 → реле спрацьовує

«Luckfox думає, STM32 діє» — повний пайплайн.

Питання! До речі, поки розбирався з підключенням Luckfox по ethernet — задумався: а як в реальних автономних системах з’єднують vision модулі з мозком? CAN? Automotive Ethernet? Окремий SPI? Якщо є досвід з роботизованих систем або automotive — цікаво почути в коментарях.

◆ Гайд-шпаргалка

Всі команди в одному місці.

На PC:

# Клонуємо репо з прикладами
git clone https://github.com/LuckfoxTECH/luckfox_pico_rknn_example
cd luckfox_pico_rknn_example

# Встановлюємо шлях до SDK
export LUCKFOX_SDK_PATH=/home/alex/luckfox-pico

# Збираємо (вибираємо uclibc → retinaface_facenet)
./build.sh

# Копіюємо на плату
scp -o PubkeyAuthentication=no -r \
    install/uclibc/luckfox_pico_retinaface_facenet_demo \
    [email protected]:/root/

На платі:

# Зупиняємо rkipc — обов'язково
RkLunch-stop.sh

# Запускаємо
cd /root/luckfox_pico_retinaface_facenet_demo
./luckfox_pico_retinaface_facenet \
    model/RetinaFace.rknn \
    model/mobilefacenet.rknn \
    model/test.jpg

# Наводимо камеру на обличчя
# Очікуємо рядки виду: @ (x1 y1 x2 y2) score

Перевірка NPU і бібліотеки:

# Драйвер
dmesg | grep -i npu | grep -i version

# Бібліотека (увага — вона в /oem/usr/lib, не в /usr/lib)
strings /oem/usr/lib/librknnmrt.so | grep "librknnmrt version"

# LD_LIBRARY_PATH має включати /oem/usr/lib
echo $LD_LIBRARY_PATH

Репозиторій: github.com/pipicosim800-maker/stm32F103

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті