В данной статье речь пойдет про использование платы Luckfox Pico Mini. Я расскажу про особенности, её настройку, а также о том как запускать на ней нейронные сети для детекции объектов с камеры (Yolov8). Всё дальнейшее повествование опирается на желание автора использовать устройство для обработки изображений нейронными сетями в реальном времени (или почти). При этом обработка изображений не может работать изолированно от других устройств общей системы, поэтому в статье также будет рассмотрена интеграция Luckfox Pico с внешней периферией.

О серии плат

Luckfox Pico - серия плат для разработки на основе процессоров Rockchip RV1103 и RV1106. 

В плане вычислительной мощности между данными процессорами большой разницы нет. Приведу концептуальные схемы устройства процессоров из даташитов:

У  RV1106 есть некоторые дополнительные интерфейсы для внешних устройств, а в остальном процессоры похожи.

Компания Luckfox выпускает различные одноплатники, но меня больше всего заинтересовал самый маленький по размерам Luckfox Pico Mini.

Есть две версии этого одноплатника:

• Luckfox Pico Mini A

• Luckfox Pico Mini B

B версия отличается от A только наличием распаянной на плате Flash памятью на 128 Мб. На Flash можно поставить операционную систему, но 128 Мб - как - то мало (в 2024 году, разумеется), поэтому особого смысла в Flash памяти нет, хотя его можно использовать в качестве резервного хранилища важных данных, например, логов.

На данный момент стоимость A версии с учётом доставки немного больше 900 рублей:

Характеристики платы:

Главный интерес вызывает NPU, который позволяет проводить инференс нейронных сетей с достаточно большой скоростью (относительно инференса на процессоре). Отношение размера платы к её возможностям радуют.

Масса платы чуть больше четырёх грамм.

На плате имеется 17 GPIO пинов, некоторые из которых могут реализовывать различные протоколы проводной связи - SPI, UART, I2C:

UART2 используется для отладки/альтернативного взаимодействия с платой. Также плата поддерживает Ethernet, в отзывах на товар я нашёл такую фотографию:

Установка Linux

Для платы существует 2 основных образа - сборка на основе Buildroot и сборка на Ubuntu. Все готовые образы можно найти здесь, также вы можете собрать свой, но в этой статье про это рассказываться не будет. Для большинства задач будет достаточно образа на основе Buildroot, в нём есть всё что нужно и даже лишнее, что мы позднее отключим. Именно его я и использую на своих Luckfox Pico Mini:

Скачанный архив нужно распаковать где - нибудь. Установить операционную систему можно на Flash память или SD карту. Как было сказано ранее, объём Flash памяти на данной плате невелик или вообще отсутствует в A версии, поэтому я подробно расскажу про установку операционной системы на SD карту.

C записыванием образа на SD карту есть некоторые сложности. В документации разработчики предлагают использовать проприетарный SocToolkit, который должен работать под Windows и Linux. У меня воспользоваться им не получилось. В разделе “SDTool” в поле выбора SD карты для прошивки было пусто. При этом я запускал программу от рута, запускал на разных операционках: Arch Linux, Ubuntu, Windows 10, Windows 11. Также подключал SD карту через разные адаптеры. Утилита не хотела её видеть, при этом система показывала, что она есть (пробовал форматировать в FAT32, а также полностью удалял все разделы и оставлял её неразмеченной). В итоге на гитхабе я нашёл Python-скрипт blkenvflash.py от комьюнити, который позволяет из под линукса записать образ. 

Вы можете попробовать воспользоваться SocToolkit (запускайте от root/админа), возможно у вас он заработает, официальная инструкция.

Как использовать blkenvflash.py:

• Вам нужен компьютер с Linux и Python 3

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

• Скрипт blkenvflash.py необходимо поместить в директорию с распакованным образом операционной системы, которую вы собираетесь установить

• Далее через команду lsblk посмотрите путь/название вашей SD карты в системе (если она автоматически примонтировалась - отмонтируйте её). В моём случае это /dev/sda1

• Далее из директории с образом нужно запустить blkenvflash.py от рута:

sudo python3 blkenvflash.py /dev/sda1

Вместо /dev/sda1 подставляйте путь к вашей SD карте.

• Если всё правильно, то через некоторое время скрипт успешно завершит свою работу.

Теперь можете вставлять SD карту в Luckfox Pico Mini:

Подавать питание можно через пин VBUS (5 Вольт) или через type c разъём (тоже 5 Вольт). Так же type c используется для взаимодействия с платой через компьютер (на Luckfox Pico нет wifi). После подачи питания вы увидите мигающий красный светодиод, судя по документации, он мигает не просто так, а служит индикатором активности платы. 

Также в целях отладки вы можете подключить USB TTL переходник на пины UART2. Через него можно видеть все логи запуска системы, а также использовать виртуальный терминал. Но стоит обратить внимание на одну деталь - при использовании данного интерфейса FPS инференса нейросети на плате по какой - то причине упал на несколько единиц, поэтому использовать UART2 нужно только для отладки.

Кроме отладочного UART’а к плате можно подключиться следующими способами:

• ADB (Android Debug Bridge)

  Этот способ я использую как основной, так можно удобно через команды adb push и pull перекидывать файлы и директории с хоста на плату и наоборот. 

  На Linux он ставится легко:
  
  sudo apt install adb # Debian Based (Ubuntu)

  sudo pacman -Sy adb # Arch based

  Далее если всё правильно установлено, то команда adb shell откроет терминал вашей платы.

Если adb выдаёт ошибки вида: “недостаточно привилегий”, то попробуйте выполнить следующие команды:

adb kill-server
sudo adb start-server
adb shell

• Виртуальная сеть через USB

Данный способ позволяет через USB организовать локальную сеть между вашим компьютером и Luckfox Pico, также можно настроить раздачу интернета с вашего компьютера. Реализация такого подключения зависит от вашей операционной системы.

Настройка

Добавления swap

Изначально в официальном Buildroot образе нет swap раздела, а встроенной оперативной памяти не хватает для всех задач. Например, у меня не хотела запускаться Yolo (не хватало памяти для загрузки модели) при подключенной CSI камере (для неё, кстати, память (24 Mb) аллоцируется статически при запуске системы). Следующие команды добавят 7.8G свопа (используется оставшееся пространство на SD карте, поэтому у вас может быть другое значение):

mkfs.ext4 /dev/mmcblk1p8 # оставляйте всё по-умолчанию, нажимайте Enter в качестве ответа на вопросы
mkswap /dev/mmcblk1p8
swapon /dev/mmcblk1p8

Затем через команду free вы можете проверить, что swap добавился:

Но swap нужно включать (swapon) после каждой перезагрузки, поэтому автоматизируем этот процесс через initd (эта система инициализации используется в официальном buildroot образе). Для этого переходим в директорию /etc/init.d и выполняем следующую команду:

echo '#!/bin/sh
case $1 in
    	start)
            	swapon /dev/mmcblk1p8
            	;;
    	stop)
            	;;
    	*)
            	exit 1
            	;;
esac' > S90autoswap

Или просто через текстовый редактор создаём файл S90autoswap с содержимым скрипта. Из коробки в buildroot образе есть только nano.

Далее выдаём права на запуск:

chmod +x ./S90autoswap

Теперь можно перезагружаться и проверять, что swap активировался автоматически.

Ещё немного оптимизации

Но проблема с нехваткой оперативной памяти добавлением swap’а полностью не решается. При подключении CSI камеры, иногда RKNN не хочет инициализировать yolo модель, выводя ошибку: “Can’t allocate memory”. Я устранил эту ошибку следующими двумя способами:

• Перед запуском своих программ выполняю команду killall rkipc

• Удалил авто-запуск разных ненужных мне программ

В официальном buildroot образе по умолчанию эти сервисы запускаются автоматически, вот их список (скрипты для их запуска находятся в /etc/init.d):

• S49ntp - NTP может быть нужен, для некоторых сетевых запросов, но мне - нет

• S50sshd - SSH я не использую, так как подключаюсь через ADB

• S50telnet - аналогично ssh

• S91smb - сетевые папки я не использую

• S99python - Судя по коду внутри, скрипт нужен для автоматического запуска Python файлов из /root (boot.py, main.py), но это не системные файлы (их вообще нет). В общем, скрипт ничего полезного не делает

Для того, чтобы эти сервисы не запускались автоматически, я перенёс соответствующие скрипты в папку /oem/services_backup. Хотя вы можете их просто удалить. Также возможно отключить системные логи (syslogd, klogd), удалив их сервисы из автостарта, но я решил этого не делать.

Hello, World

Весь код под плату я буду писать на С/C++. В официальном buildroot образе предустановлен интерпретатор python, но учитывая ограничения по вычислительным ресурсам платы, нет смысла писать код под плату на питоне. Управление GPIO пинами через Python, ещё может быть и будет нормально работать, но пост-обработка результатов инференса yolo через Python - плохая идея.

Именно поэтому весь дальнейший код под одноплатник написан на C/C++. Все примеры в виде готовых структурированных проектов с Makefile/CMake (для некоторых) можно взять из моего github репозитория.

git clone https://github.com/ret7020/LuckfoxAI

Текущий пример находятся в Projects/HelloWorld.

Для компиляции вам нужен кросс-компилятор. Его бинарники есть только под Linux x86. Их можно скачать из официального github репозитория:

git clone https://github.com/LuckfoxTECH/luckfox-pico/

Кросс-компиляцию проекта можно проводить на Google Colab, здесь есть пример.

В директории tools/linux/toolchain/arm-rockchip830-linux-uclibcgnueabihf/bin находятся бинарники нужных программ (в первую очередь, нас интересуют gcc и g++). Далее для компиляции моих примеров и примеров из репозитория rknn_model_zoo нужно установить переменную среды с путём к директории кросс-компилятора:

export GCC_COMPILER=/home/stephan/Downloads/LuckFox/luckfox-pico/tools/linux/toolchain/arm-rockchip830-linux-uclibcgnueabihf/bin/arm-rockchip830-linux-uclibcgnueabihf

Обратите внимание на то, что в конце пути после последнего / добавляется ещё arm-rockchip830-linux-uclibcgnueabihf

Исходный код примера очень простой, стандартный HelloWorld:

#include <stdio.h>

int main()
{
    printf("Hello, world!\nFrom luckfox...\n");
    return 0;
}
/* Можете использовать iostream cout, вместо stdio printf, кому как нравится, 
    но не забывайте компилировать через компилятор C++ (например, g++)*/

Makefile для сборки тоже очень простой:

build:
    mkdir -p bin
    echo Using: ${GCC_COMPILER}
    ${GCC_COMPILER}-g++ main.cpp -o ./bin/hello

deploy:
    adb push ./bin/hello /oem/hello

Команда build собирает итоговый бинарник в ./bin/hello, используя указанный в переменных среды кросс-компилятор g++.

Команда deploy с помощью adb перекидывает бинарник в директорию пользователя (/oem) на Luckfox Pico.

Управление GPIO пинами

Рассмотрим взаимодействие с пинами через терминал, а также программным управлением. У нас есть возможность управлять пинами через линуксовую абстракцию. Схема управления следующая: сначала экспортируем пин и устанавливаем его на вход/выход (напоминает pinMode в Arduino), затем записываем/считываем из него значение, освобождаем/unexport.

На схеме пины имеют названия следующего вида: GPIO1_D0_d. Это название необходимо интерпретировать следующим образом:

GPIO{bank}_{group}{X}_d

Для того, чтобы рассчитать итоговый ID пина, с которым мы будем работать из под линукса нужно воспользоваться следующей формулой:

pin = bank * 32 + (group * 8 + X)

Исходя из этого, ID правого нижнего пина (GPIO1_D0_d) будет равен 56. Следующий пример показывает управление пином через терминал:

# Экспортируем в userspace (у нас появится директория gpio56 в /sys/class/gpio)
echo 56 > /sys/class/gpio/export

# Переводим его в режим “выхода”
echo out > /sys/class/gpio/gpio56/direction

# Записываем значение HIGH (1), 3.3 В, называйте как хотите
echo 1 > /sys/class/gpio/gpio56/value

# Или “выключаем” его
echo 0 > /sys/class/gpio/gpio56/value

# В конце делаем unexport
echo 56 > /sys/class/gpio/unexport

Касательно unexport стоит заметить, что состояние пина при этом не сбрасывается, оно остаётся таким же каким и было установлено.

Теперь продемонстрирую программу, которая управляет состоянием пина из кода. Фактически она делает всё тоже - самое, записывая значения в соответствующие файлы. Код программы в репозитории - Projects/GPIO.

#include <stdio.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
    int bank = 1;
    char group = 2;
    int X = 0;
    int linuxPin = 0;
    char result[2];
    printf("Enter pin from pinout, like example: 1 B 2 stands for GPIO1_B2_d in pinout: ");
    scanf("%d %c %d", &bank, &group, &X);
    group -= 'A';
    linuxPin = bank * 32 + (group * 8 + X);
    printf("Set to (1 or 0)?:");
    scanf("%s", &result);
    printf("Pin %d will be set to %s\n", linuxPin, result);

    // Export pin to userspace
    FILE *exportFile = fopen("/sys/class/gpio/export", "w");
    if (exportFile == NULL)
    {
   	 perror("Failed to open GPIO export file, maybe it is alreay exported or invalid?");
   	 return -1;
    }
    fprintf(exportFile, "%d", linuxPin);
    fclose(exportFile);

    // Set to output
    char directionPath[50];
    snprintf(directionPath, sizeof(directionPath), "/sys/class/gpio/gpio%d/direction", linuxPin);
    FILE *directionFile = fopen(directionPath, "w");
    if (directionFile == NULL)
    {
   	 perror("Failed to open GPIO direction file, check export");
   	 return -1;
    }
    fprintf(directionFile, "out");
    fclose(directionFile);

    // Write value
	char valuePath[50];
	snprintf(valuePath, sizeof(valuePath), "/sys/class/gpio/gpio%d/value", linuxPin);
	FILE *valueFile = fopen(valuePath, "w");
	if (valueFile == NULL) {
    	perror("Failed to open GPIO value file");
    	return -1;
	}


    fprintf(valueFile, result);
	fflush(valueFile);


    // Release pin
	fclose(valueFile);
	FILE *unexportFile = fopen("/sys/class/gpio/unexport", "w");
	if (unexportFile == NULL) {
    	perror("Failed to open GPIO unexport file");
    	return -1;
	}
	fprintf(unexportFile, "%d", linuxPin);
	fclose(unexportFile);


    return 0;
}

Сначала вам нужно ввести пин в виде 1 D 0 (означает GPIO1_D0). Далее ввести значение, которое хотите записать в пин.

Не всеми пинами можно управлять из официального образа, чтобы настроить каждый пин используется dtb (Device Tree Binary), его изменение требует пересборки ядра. Подробнее можно прочитать в документации.

Программируем UART

Судя по pinout платы, у Luckfox Pico есть: UART2, UART3, UART4.

UART2 используется для отладки, поэтому мы не можем его сконфигурировать (если речь идёт про официальный Buildroot образ, возможно, через dtb uart2 можно переназначить). В официальном Buildroot образе UART3 не настроен, его необходимо вручную сконфигурировать в dtb и пересобрать ядро. Исходя из вышесказанного, проще всего воспользоваться UART4. Его удобно настроить через luckfox-config (до raspi-config он не дотягивает).

luckfox-config

Стрелочками выбираем второй пункт “Advanced Configuration”

Выбираем единственный доступный UART4_M1 и переключаем его состояние на 1, enabled

Теперь можно выйти из конфигуратора. Командой luckfox-config show можно в удобной форме посмотреть текущую конфигурацию пинов платы:

Напротив UART4 для пинов GPIO1_C4 и GPIO1_C5 (10 и 11 номер на плате) будут стоять звёздочки, которые означают, что пины сконфигурированы под UART.

Если всё сделано правильно, то в /dev должен появится ttyS4:

Для проверки того, что всё работает, к пинам можно подключить реальное устройство, которое работает по UART или TTL переходник. 

Пример кода отправит сообщение “ping\n”. Далее, если в ответ получит “e”, то завершит работу, иначе продолжит отправлять "ping”. Такой простой демонстрации будет достаточно. 

Для тестирования я использовал UART TTL переходник и программу CuteCom.

Пример кода для обмена данными по UART:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <termios.h>
#include <unistd.h>

#define UART_PATH "/dev/ttyS4"

int main()
{
    // Init part
    char serialPort[] = UART_PATH;
    char txBuf[] = "ping\n";
    struct termios tty;
    ssize_t writeLen;
    int serialFd;
    char rxBuffer[256];
    int bytesRead;

    serialFd = open(serialPort, O_RDWR | O_NOCTTY);

    memset(&tty, 0, sizeof(tty));
    

    // Setting baud
    cfsetospeed(&tty, B9600);
    cfsetispeed(&tty, B9600);

    // Generic flags
    tty.c_cflag &= ~PARENB;
    tty.c_cflag &= ~CSTOPB;
    tty.c_cflag &= ~CSIZE;
    tty.c_cflag |= CS8;
    
    while (1){
   	 writeLen = write(serialFd, txBuf, sizeof(txBuf));
   	 if (writeLen > 0)
   	 {
   		 bytesRead = read(serialFd, rxBuffer, sizeof(rxBuffer));
   		 if (bytesRead > 0) {
   			 rxBuffer[bytesRead] = '\0';
   			 printf("Recieved: %s", rxBuffer);
   			 if (rxBuffer[0] == 'e') {
   				 printf("Exit\n");
   				 return 0;
   			 }
   		 }
   	 }
    }

    return 0;
}

Скорость обмена - 9600 бод, остальные параметры “стандартные”. Под “стандартными” я имею в виду следующие:

Программируем SPI

Данный протокол может передавать данные с бОльшей скоростью и может быть полезен при подключении Luckfox к другим контроллерам в общей системе.

SPI, так же как и UART, необходимо сконфигурировать через luckfox-config. На Luckfox пользователю нормально доступна только одна SPI шина (вторая используется Flash/SD памятью). 

Конфигурация очень похожа на конфигурацию UART:

Advanced Options -> SPI -> SPI0_M0 -> 1 enable

Далее вас попросят ввести частоту работы шины в Герцах, максимальная - 1 МГц, поэтому вводим 1000000 и нажимаем OK. Далее, нажимая Cancel, выходим из конфигуратора.

Если всё настроено правильно, то в /sys/bus/spi/devices/ должна появиться директория spi0.0 (нулевое устройство на нулевой шине). Подробнее про настройку SPI при использовании нескольких SPI устройств, подключенных к одной шине (выбор разных Chip Select пинов) можно прочитать в официальной документации, там тоже не обойдётся без сборки dtb.

Я же покажу, как использовать Luckfox Pico в качестве Master платы, подключенной к Slave Arduino Nano.

Slave код на Arduino Nano:

#include <SPI.h>

bool cnt = 0;

void setup()
{
  Serial.begin(9600);
  pinMode(SS, INPUT_PULLUP);
  pinMode(MOSI, OUTPUT);
  pinMode(SCK, INPUT);
  SPCR |= _BV(SPE);
  SPI.attachInterrupt();
}

void loop(void)
{
  if (cnt != 0) {
	Serial.println("All data recieved");
	cnt = 0;
  }
 
}

ISR (SPI_STC_vect)
{
  Serial.println("New byte recieved");
  Serial.println(SPDR);
  cnt = 1;
}

Master код на Luckfox (в репозитории находится в Projects/SPITest):

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <fcntl.h>
#include <unistd.h>
#include <linux/spi/spidev.h>
#include <sys/ioctl.h>

#define SPI_DEVICE_PATH "/dev/spidev0.0"

int main()
{
    int spi_file;
    uint8_t tx_buffer[1] = {20};
	uint8_t rx_buffer[1];

    // Open the SPI device
    if ((spi_file = open(SPI_DEVICE_PATH, O_RDWR)) < 0)
    {
   	 perror("Failed to open SPI device");
   	 return -1;
    }

    uint8_t mode = SPI_MODE_0;
    uint8_t bits = 8;
    if (ioctl(spi_file, SPI_IOC_WR_MODE, &mode) < 0)
    {
   	 perror("Failed to set SPI mode");
   	 close(spi_file);
   	 return -1;
    }

    struct spi_ioc_transfer transfer = {
   	 .tx_buf = (unsigned long)tx_buffer,
   	 .rx_buf = (unsigned long)rx_buffer,
   	 .len = sizeof(tx_buffer),
   	 .speed_hz = 1000000,  // SPI speed in Hz
   	 .delay_usecs = 0,
   	 .bits_per_word = 8,
    };

    if (ioctl(spi_file, SPI_IOC_MESSAGE(1), &transfer) < 0)
    {
   	 perror("Failed to perform SPI transfer");
   	 close(spi_file);
   	 return -1;
    }

    close(spi_file);

    return 0;
}

Это максимально простой пример, который ничего полезного не делает (просто передаёт один байт с Luckfox на Arduino), но так как статья далеко не про SPI, считаю, что этого достаточно.

Использование OpenCV

Для маломощных устройств есть специальный OpenCV Mobile (форк OpenCV), в нём нет некоторых компонентов, но зато он более производительный, чем классический OpenCV. Изучить какие модули включены в Mobile версию можно в официальном GitHub репозитории проекта. 

В моём репозитории демонстрация OpenCV Mobile находится в Projects/OpenCVMobile

Для простоты подключения библиотек используется система сборки CMake. Содержимое CMakeLists.txt

cmake_minimum_required(VERSION 3.5)

project(OpenCVMobile)

set(CMAKE_CXX_STANDARD 11)

SET(CMAKE_C_COMPILER "$ENV{GCC_COMPILER}-gcc")

SET(CMAKE_CXX_COMPILER "$ENV{GCC_COMPILER}-g++")

SET(CMAKE_C_LINK_EXECUTABLE "$ENV{GCC_COMPILER}-ld")

set(CMAKE_SYSTEM_PROCESSOR arm)

set(OpenCV_DIR "${CMAKE_CURRENT_SOURCE_DIR}/libs/opencv-mobile-4.10.0-luckfox-pico/lib/cmake/opencv4")

find_package(OpenCV REQUIRED)

include_directories(${OpenCV_INCLUDE_DIRS})

add_executable(OpenCVMobile main.cpp)

target_link_libraries(OpenCVMobile ${OpenCV_LIBS})

В нём указываются пути к кросс-компиляторам и путь к файлам библиотеки OpenCVMobile. На момент написания актуальная версия 4.10.0. В директории libs проекта находится скрипт download.sh, который автоматически скачает и распакует эту версию. Выполнить этот башник необходимо до начала сборки проекта.

Тестовый код для OpenCV просто создаёт и сохраняет 3 изображения:

#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/imgproc/imgproc.hpp>
#include <stdio.h>

int main()
{
    printf("Generating images test");
    cv::Mat redImg(480, 640, CV_8UC3, cv::Scalar(0, 0, 255));
    cv::imwrite("red.jpg", redImg);

    cv::Mat greenImg(480, 640, CV_8UC3, cv::Scalar(0, 255, 0));
    cv::imwrite("green.jpg", greenImg);

    cv::Mat blueImg(480, 640, CV_8UC3, cv::Scalar(255, 0, 0));
    cv::imwrite("blue.jpg", blueImg);
    return 0;
}

Для сборки проекта необходимо выполнить следующие команды в корне проекта (Projects/OpenCVMobile):

mkdir build
cd build
cmake ..
make

В итоге в директории ./build вы получите бинарник с названием OpenCVMobile. Его надо скопировать на Luckfox и запустить:

adb push OpenCVMobile /oem
adb shell
cd /oem
./OpenCVMobile

После завершения работы, в директории /oem (рядом с бинарником программы) на Luckfox вы получите 3 файла с названиями: red.jpg, blue.jpg, green.jpg, которые являются изображениями соответствующих названиям цветов.

CSI камера

Плата не поддерживает высококачественные CSI камеры. В характеристиках заявлено чтение в 30 fps 4MP (это допустимый максимум) камеры. Поддерживаются только камеры на основе SC3336. На Aliexpress такая камера только одна:

Отсутствие автоматической фокусировки расстраивает, но нет так нет.

Тестируем камеру

Сначала нужно определить к какому устройству (/dev/video*) подключилась физическая камера. Определить это можно с помощью команды:

v4l2-ctl --list-devices

В разделе rkisp_mainpath (platform:rkisp-vir0) будут отображены устройства привязанные к CSI камере.

rkisp_mainpath (platform:rkisp-vir0):

    /dev/video11

Нас интересует самое первое устройство, у меня это /dev/video11.

Выше я показал пример запуска OpenCV Mobile, через него я и предлагаю получать кадры с камеры. При этом из OpenCV Mobile убран модуль opencv_videoio, который добавляет возможность сохранять видео с камеры нужным кодеком (cv::VideoWriter). Поэтому мы будем просто сохранять каждый новый кадр в один и тот же файл (не стоит злоупотреблять, можно убить SD карту).

Код этого примера в репозитории находится в Project/OpenCV_CSI_Camera.

#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/imgproc/imgproc.hpp>
#include <stdio.h>
#include <chrono>

// OpenCV Mobile doesn't support VideoWriter

#define DEVICE_PATH 11
#define VIDEO_RECORD_FRAME_WIDTH 640
#define VIDEO_RECORD_FRAME_HEIGHT 640

double avgFps = 0.0;
int framesRead = 0;
int main()
{
	// Camera init
	cv::VideoCapture cap;
	cap.set(cv::CAP_PROP_FRAME_WIDTH, VIDEO_RECORD_FRAME_WIDTH);
	cap.set(cv::CAP_PROP_FRAME_HEIGHT, VIDEO_RECORD_FRAME_HEIGHT);
	cap.open(DEVICE_PATH);

	cv::Mat bgr;

	// "Warmup" camera
	for (int i = 0; i < 5; i++){cap >> bgr;}

	for (int i = 0; i < 25 * 10; i++){
		std::chrono::steady_clock::time_point begin = std::chrono::steady_clock::now();
		cap >> bgr;
		std::chrono::steady_clock::time_point end = std::chrono::steady_clock::now();
		printf("Get frame - OK\n");
		double fps = 1 / std::chrono::duration<double>(end - begin).count();
		avgFps += fps;
		framesRead++;
		if (bgr.empty()) break;
		cv::imwrite("captured.jpg", bgr);
	}
	printf("AVG FPS: %lf\n", avgFps / framesRead);

	cap.release();

	return 0;
}

Перед запуском программы рекомендую выполнять ещё команду:

killall rkipc

Код очень простой, используются стандартные методы OpenCV.
“Прогрев” камеры добавил по привычке, в целом от него нет смысла на этой камере. Код измеряет FPS чтения изображений с камеры. Для изображений размером 640x640 выходит около 39 FPS, для изображений 320x320 значительного прироста нет. Но, вот если вы попытаетесь читать изображения 1920x1080, то FPS будет очень низким. В любом случае, для инференса Yolo будет достаточно и 640x640.

Запуск Yolo

Немного аналитики

Rockchip любезно делятся готовым кодом для запуска и конвертации различных моделей yolo (и не только). На данный момент в rknn_model_zoo есть исходники для 8 версий yolo:

yolov5, yolov5_seg, yolov6, yolov7, yolov8, yolov8_seg, yolov10, yolox

При этом не все эти примеры запускаются на Luckfox Pico, некоторые компилируются под RV1103, но при запуске не могут прочитать конфиг модели или ссылаются на нехватку методов в RKNN (yolov10 по этой причине не хочет запускаться). Я составил следующую таблицу, которая для базовой yolo модели (обученной на COCO) показывает средний FPS в детекции объектов на изображениях 640x640.

Изначально планировалось провести подобный анализ для изображений 320x320, но по итогу использовались только изображения 640x640. О том почему 320x320 оказались неподходящими будет написано далее.

Судя по бенчмарку от Ultralytics, yolov8 работает быстрее всех предыдущих, но этот график описывает скорость инференса на A100, что явно намного мощнее нашего рантайма.

Также рассмотрим бенчмарк из репозитория rknn_model_zoo, полную таблицу вы можете посмотреть здесь. К сожалению в ней нет информации о процессорах RV1103/RV1106, но я проанализирую относительный FPS между различными моделями в контексте одного процессора. Просто так переносить результаты одного процессора на другой не совсем правильно, но изучить чужие бенчмарки тоже полезно. Так, yolov5n работает быстрее yolov8n на всех представленных в таблице процессорах. Из таблицы видно, что самая быстрая модель - yolov6. 

Мои замеры показали (на RV1103), что yolov6 быстрее yolov5, но не так сильно, как на других процессорах из таблицы ниже.

Также есть бенчмарк от Qengineering на процессорах большей мощности - RK3588/66/68

Модели yolov5_seg и yolov8_seg выполняют семантическую сегментацию изображений, а остальные - детектирование объектов. Сегментация (с точки зрения вычислительных ресурсов, а значит и временных) сложнее, поэтому пока не будем её рассматривать.

Но приведённая выше аналитика основывается на COCO моделях и других рантаймах, поэтому эти результаты не очень интересны в контексте текущей задачи. Куда интереснее узнать mAP и FPS на кастомной модели, запущенной на Luckfox Pico Mini.

Экспорт и запуск

Перед запуском yolo на Luckfox необходимо экспортировать её в формат rknn, а перед экспортированием в rknn, необходимо экспортировать оригинальную модель в ONNX (но не совсем обычный). Я опишу процесс экспорта на примере Yolov8. Самые свежие версии модели (Yolov10) на данном процессоре (RV1103) не поддерживаются, им не хватает каких - то методов из библиотеки RKNN. 

Также я пробовал обучать и запускать yolov5, при этом экспортированная модель не могла адекватно находить боксы объектов. Она правильно определяла факт наличия объекта, но при этом боксы были совсем неверные. Ранее я показывал, что инференс Yolov8 занимает больше времени, чем у Yolov5, но это было на датасете COCO из 80 классов. При этом кастомные yolov5 и yolov8, обученные на несколько классов работают примерно с одинаковой скоростью (на Luckfox Pico, возможно на других рантаймах/вычислительных модулях ситуация будет другой). В любом случае в репозитории вы можете найти проекты с названием вида: “HelloYolovX”, в них есть примеры запуска разных версий yolo. Также можете изучить репозиторий rknn_model_zoo, в нём собраны примеры запуска различных моделей через RKNN (не только CV, есть LLM и аудио обработка). Но я решил остановиться на Yolov8. 

Если вам нужно запустить базовую модель Yolov8 (обученную на COCO), то вы можете скачать уже экспортированную в RKNN модель отсюда.

Её можно сразу запускать на Luckfox, без необходимости что - либо экспортировать. Но скорее всего устройство планируется использовать для решения более узкой задачи (подробнее об этом написано в заключении), чем детекцию 80-ти различных объектов, тем более, как было замечено в предыдущей статье про yolo, модель, обученная на меньшее количество классов, имеет меньше параметров, вследствие чего инференс происходит быстрее.

Тем более, исключительно по моему опыту, COCO датасет хорошо использовать для быстрого тестирования/сравнения моделей, но в реальности используется “склеивание” своих датасетов с готовыми. И нет необходимости в детектировании такого большого количества классов, как в COCO. 

Далее я опишу процесс обучения и запуска на Luckfox Pico Mini модели yolov8 на кастомном датасете для детекции сопла от паяльного фена и модуля ESP-01.  

Для экспорта модели нужна x86 система под управлением Linux. Для упрощения процесса я подготовил ноутбук под Google Colab, поэтому для минимизации количества проблем связанных с особенностями вашей системы (операционная система, версии пакетов и т.д.) рекомендую пользоваться коллабом. А так, на Arch Linux, RKNN_Toolkit2 устанавливается без проблем и работает без нареканий.

Немного про датасет

В моём датасете всего 2 класса: сопло от паяльного фена и WiFi модуль ESP-01.

Я собирал датасет сразу на CSI камеру, подключенную к Luckfox. В репозитории в директории Project/RecordDataset находится небольшая программа для сбора датасета.

Принцип её работы следующий:

Сначала вы вводите название/id класса, изображения для которого вы собираете. Рядом с бинарником программы должна быть директория с названием этого класса. Далее, нажимая Enter, программа сохраняете очередной кадр в эту директорию.

Датасет я размечал через Roboflow и экспортировал с x3 аугментацией. Хочется обратить внимание на низкое качество датасета. Разметку проводил с помощью инструмента Smart Polygon внутри Roboflow. С его помощью можно очень быстро в полуавтоматическом режиме выделить маску объекта. Качество очень сильно зависит от освещения/теней и сложности геометрии объекта. Я собирал датасет в демонстрационных целях, поэтому мне не нужно очень качественно детектировать боксы объектов. Разумеется, чтобы улучшить качество работы модели необходимо собрать датасет по-больше и аккуратнее отнестись к разметке.

При генерации датасета использовал следующие параметры аугментации:

И вот небольшая аналитика по датасету:

Датасет далёк от идеала, но как было сказано ранее, такого качества достаточно для поставленной цели.

Обучение и экспорт модели

Общий пайплайн "от датасета к модели, работающей на Luckfox" (и вообще на всех NPU в процессорах Rockchip) выглядит так:

Для конвертации Yolo модели в ONNX необходимо воспользоваться кастомной Yolo от RKNN. Из коробки Yolo умеет экспортировать в ONNX, но кастомные версии RKNN проводят ряд дополнительных оптимизаций, например:

• Yolov8 - Change output node, remove post-process from the model. (post-process block in model is unfriendly for quantization)

• Yolov8 - Remove dfl structure at the end of the model. (which slowdown the inference speed on NPU device)

• Yolov8 - Add a score-sum output branch to speedup post-process.

• Yolov10 - Removed the post-processing structure from the output to improve inference performance and quantization precision, as the original post-processing operators were not friendly to these aspects (Modify ultralytics/nn/modules/head.py).

• Yolov10 - To enhance inference performance, the DFL (Distribution Focal Loss) structure has been moved to the post-processing stage outside of the model (Modify ultralytics/nn/modules/head.py).

• Yolov5 - Optimize focus/SPPF block, getting better performance with same result

• Yolov5 - Change output node, remove post_process from the model. (post process block in model is unfriendly for quantization)

Так же при таком экспорте из модели убирается пост-процессинг (в него, например, входит NMS), который надо будет выполнять отдельно на CPU после инференса.

Весь пайплайн я реализовал в Jupyter ноутбуке, который работает в Google Colab. Ниже будет рассказано, как им пользоваться. Для начала запустите Runtime с GPU (T4). 

Далее несколько ячеек выполняют базовую настройку окружения: устанавливается ultralytics, монтируется Google диск, распаковывается датасет. 

Если вы хотите просто повторить эксперимент на моём датасете, то скачать его можно отсюда. Не забудьте указать правильное название и путь к архиву. Он был экспортирован с Roboflow в формате “для Yolov8”. Также, если у вас уже есть веса модели, то вы можете пропустить шаги обучения.

Теперь в файле конфигурации датасета data.yaml нужно поменять пути к файлам с изображениям на абсолютные (возможно обучение запустится без этого):

train: /content/nozzle_data/train/images
val: /content/nozzle_data/valid/images
test: /content/nozzle_data/test/images

Далее идёт обычный процесс обучения yolov8:

Результаты обучения следующие:

Судя по матрице ошибок ещё есть куда стремится, но простое увеличение количества эпох обучения не решает проблему, а приводит к переобучению/остановке по Early Stop. Нужно более детально настраивать гиперпараметры. 

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

Теперь приступим к экспорту, обученной модели, в ONNX. Для этого сначала скачаем специальный форк yolov8:

Теперь нам надо заменить путь с дефолтной модели к нашей (обученной ранее) в этом файле:

/content/ultralytics_yolov8/ultralytics/cfg/default.yaml

Это можно сделать вручную:

После этого можно начинать экспорт модели в ONNX.

Теперь ONNX модель необходимо сконвертировать в RKNN.

Для этого сначала установим RKNN-Toolkit2 для версии Python 3.10 (в коллабе):

Через импорт rknn можно убедиться, что всё установилось. Теперь нужно скачать репозиторий rknn_model_zoo. Вообще, в нём очень много примеров запуска и конвертации различных моделей под RKNN, но нам из него нужен только экспорт yolov8.

При экспорте модели под RV1103 мы обязаны её квантизировать в int8, потому что npu данного процессора не умеет обрабатывать fp модели. Процесс квантизации обычно происходит с, так называемой калибровкой, (можно просто урезать разрядность весов, но это приведёт к сильному падению точности). Для калибровки необходимо использовать часть (или все) изображения из датасета.

Рекомендуется использовать не менее 20 изображений (кто - то считает, что чем больше - тем лучше), но я буду калибровать на всём трейне датасета, это дольше, но возможно итоговая модель будет работать чуть - лучше и негативный эффект квантизации будет минимальным.

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

Не забудьте поменять путь к датасету на свой. Если вы не хотите калибровать на всём датасете, то просто можете взять срез от files (files[:30]).

Теперь нужно отредактировать файл /content/rknn_model_zoo/examples/yolov8/python/convert.py

В нём укажем путь к списку файлов для калбировки:

И наконец, запускаем экспорт в RKNN:

Не забудьте поменять путь к своим весам

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

В итоге, в директории ../model появится yolov8n.rknn. На этом питон заканчивается, начинаются segmentation fault, модель готова, теперь её нужно деплоить на Luckfox.

Итоговый проект по запуску кастомного Yolov8 детектора с камеры на Luckfox я залил в отдельный репозиторий.

В src/main.cc в MODEL_INPUT_SIZE указывается размер входного изображения. Так же в model/labels.txt прописывается мэппинг id класса к его текстовому названию. Важно не забыть указать правильное количество классов (background не считается, только объекты, в моём случае - это 2) в файле include/postprocess.h в дефайне OBJ_CLASS_NUM, иначе ничего работать не будет, будут только Segmentation Fault.

Собирается проект стандартно:

git clone https://github.com/ret7020/Yolov8CustomNPU
export GCC_COMPILER=ПУТЬ/arm-rockchip830-linux-uclibcgnueabihf
mkdir build
cd build
cmake ..
make install

Далее копируем всю папку bin на Luckfox (через adb это делает так):

adb pull ../bin/ /oem/yolov8_inference

И на Luckfox запускаем:

killall rkipc
./HelloYolov8 model/yolov8.rknn

И оно работает. Разные классы отрисовываются боксами разных классов.

Далее я попробовал обучить модель на изображениях 320x320, но результат детекции на Luckfox был отвратительный:

Возможно, необходимо собрать датасет значительно больше и тогда получится добиться адекватных результатов детекции. Но на самом деле в этом нет смысла, так разницы в времени инференса практически нет. Обе модели выдают примерно по 15 FPS. Я постараюсь разобраться почему так происходит, так как для меня это немного странно.

UPD: При обучении и экспорте модели для изображений 320x320 я допустил несколько ошибок.

Нужно при экспорте в onnx в файле /content/ultralytics_yolov8/ultralytics/cfg/default.yaml кроме пути к модели поменять параметр imgsz. Так же для квантизации, в коллабе, в ячейке с генерацией списка файлов калибровки я добавил ресайз в нужное разрешение. Кстати, квантизация изображениями 320x320 происходит практически моментально!

Пример дектирования на изображении 320x320:

При этом скорость инференса выросла до ~48 - 50 FPS.

Теперь необходимо сравнить mAP модели до квантизации и экспорта с итоговой моделью, которая работает на Luckfox. 

mAP для Luckfox модели подсчитывался по следующей схеме: 

• Модель обрабатывала 83 изображения valid части датасета

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

• Далее через python скрипт происходил просчет mAP-50/mAP-50-95

Результаты валидации модели до конвертации (сразу после обучения):

Пример детекции на одном из батчей:

Для замера метрик на Luckfox я написал следующую программу:

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "yolov8.h"
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/imgproc/imgproc.hpp>
#include <sys/types.h>
#include <dirent.h>

#define MODEL_INPUT_SIZE 640


int main(int argc, char **argv)
{
	if (argc != 4)
	{
    	printf("%s <model_path> <val_path_dir> <results_path>\n", argv[0]);
    	return -1;
	}

	const char *model_path = argv[1];
	const char *val_path = argv[2];
	const char *results_path = argv[3];

	int ret;
	rknn_app_context_t rknn_app_ctx;
	memset(&rknn_app_ctx, 0, sizeof(rknn_app_context_t));

	init_post_process();

	ret = init_yolov8_model(model_path, &rknn_app_ctx);
	if (ret != 0)
	{
    	printf("init_yolov8_model fail! ret=%d model_path=%s\n", ret, model_path);
	}

	cv::Mat bgr640(MODEL_INPUT_SIZE, MODEL_INPUT_SIZE, CV_8UC3, rknn_app_ctx.input_mems[0]->virt_addr);
	DIR* dirp = opendir(val_path);
	struct dirent * dp;
	FILE *resWriteptr;

	while ((dp = readdir(dirp)) != NULL) {
    if (!strcmp(dp->d_name, "..") || !strcmp(dp->d_name, ".")) continue; // Skip ../ path

    char absFilePath[128];
    sprintf(absFilePath, "%s/%s", val_path, dp->d_name);
    cv::Mat img = cv::imread(absFilePath);
    	cv::resize(img, bgr640, cv::Size(MODEL_INPUT_SIZE, MODEL_INPUT_SIZE), 0, 0, cv::INTER_LINEAR);
    	rknn_run(rknn_app_ctx.rknn_ctx, nullptr);
    	object_detect_result_list od_results;

    	post_process(&rknn_app_ctx, rknn_app_ctx.output_mems, 0.25, 0.45, &od_results);
    	printf("%d\n\n", od_results.count);
    	for (int i = 0; i < od_results.count; i++)
    	{
        	object_detect_result *det_result = &(od_results.results[i]);
        	int x1 = det_result->box.left;
        	int y1 = det_result->box.top;
        	int x2 = det_result->box.right;
        	int y2 = det_result->box.bottom;
   	printf("IMG: %s -> x1=%d1 y1=%d x2=%d y2=%d class: %d\n", dp->d_name, x1, y1, x2, y2, det_result->cls_id);
   	char resFilePath[256];
   	char fileName[128];
   	strcpy(fileName, dp->d_name);
   	//char fileName[128];
   	fileName[strlen(fileName) - 4] = 0;
   	sprintf(resFilePath, "%s/%s.txt", results_path, fileName);
   	resWriteptr = fopen(resFilePath, "w");
   	fprintf(resWriteptr, "%s %lf %d %d %d %d\n", coco_cls_to_name(det_result->cls_id), det_result->prop, x1, y1, x2, y2);


   	fclose(resWriteptr);
    	}
    printf("----------\n");
	}

	return 0;
}

Суть её работы заключается в следующем: для каждого изображения из директории (в данном случае из images/test) проводится инференс, а результаты записываются в txt файлы в отдельной директории с названием, основанном на названии изображения. Содержимое файла имеет следующий формат:

<class_name> <confidence> <x1 (left)> <y1 (top)> <x2 (right)> <y2 (bottom)>

Причём, хочу обратить внимание, что координаты записываются в ненормализованном виде (Т.е. их диапазон [0;640) px). Это сделано так, потому что скрипт для подсчёта mAP тоже использует ненормализованные координаты.

Скрипт для подсчёта mAP я взял из этого репозитория. В итоге mAP сильно не ухудшился:

mAP50 = 0.946

mAP95 = 0.903

Необходимо учитывать небольшой размер тестовой выборки (но размечать ещё один тестовый датасет я очень не хотел). По-хорошему модели надо было сравнивать друг с другом без замера оценки с ground-truth. Т.е. сравнивать насколько различаются показания одной относительно другой. В таком случае мы оцениванием не правильность работы модели, а то насколько результаты квантизированной модели отличаются от обычной, что может быть полезнее в случае заведомо плохо обученной модели.

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

Связь с внешним миром

На плате нет радио-трансивера, а отправка данных по Ethernet не всегда доступна. Комьюнити разработало адаптер для RTL8723bs. Но он подключается в слот для SD карты, соответственно всю систему придётся уместить на flash, которого может быть недостаточно. 

Поэтому я приведу примеры взаимодействия платы с модулем SIM800L(и подобными). Я решил не писать linux драйвер, который даст возможность использовать адаптер внутри всей системы для доступа к интернету, в этом мало смысла.

SIM800L

На Aliexpress есть различные версии модулей на основе SIM800L (и похожих), все они управляются по UART и протокол AT команд очень похож. Я отлаживал свой код на “красном модуле”.

Библиотека позволяет инициализировать модуль и совершать GET/POST HTTP запросы. Для упрощения интеграции в другие проекты библиотека реализована в одном хэдер файле. В репозитории она находится в Projects/SIM800.

sim800.h - код библиотеки, а main.cpp - пример использования. 

Например, вот так можно реализовать отправку сообщений в Telegram от имени бота. Не забудьте поменять APN, в зависимости от вашего оператора:

#include <stdio.h>
#include "sim800.h"

// Config

#define MODULE_UART "/dev/ttyS4"
#define MODULE_APN "INTERNET.MTS.RU"


int main()
{
    
    SIM800 module = SIM800(MODULE_UART);
    int initStatus = module.init();
    printf("Init status: %d\n", initStatus);
    if (initStatus)
    {
   	 if (module.checkAT())
   	 {
   		 module.setupInternet(MODULE_APN);
   		 char response[2000];
   		module.get("https://api.telegram.org/botTOKEN/sendMessage?chat_id=CHAT_ID&text=Hello", response);
   		 printf("Response: %s", response);

   	 }
   	 
    
    } else return 1;

    module.finishInternet();
    return 0;
}

О применимости

В данной статье не освещается реализация полноценного проекта на основе Luckfox Pico Mini. Только детекция объектов через Yolov8 и немного примеров работы с GPIO пинами, протоколами связи UART и SPI.

В предыдущей статье я замерял производительность Yolov8 на различных одноплатниках, но все они были бОльших размеров и далеко не все из них могут приблизиться к скорости инференса Luckfox Pico Mini. Поэтому 15 FPS - неплохой результат для такой платы. Это нельзя назвать realtime, но порог скорости для попадания в критерий realtime для каждого проекта определяется индивидуально. Очевидно, что Яндексу для своих беспилотников недостаточно 15 FPS. Для каких - то задач такого качества распознавания и скорости хватит. По-большей части - это бытовые или около-бытовые проекты. Хотя, никто не мешает поставить Luckfox Pico на какой - нибудь Tiny Whoop и что - нибудь детектировать (возможно вы подумали про военные цели, но нет, я этого не имел ввиду).

В любом случае, несмотря на то, что использование NPU в ноутбуках с мощными многоядерными процессорами звучит сомнительно, применение NPU в робототехнике выглядит перспективно. В RV1103 всего 0.5 TOPS мощности, а есть Hailo 8 с 26 TOPS мощности. Но Hailo и стоит горадо дороже, и без дополнительной обвязки в виде одноплатника c PCI M2 от него нет никакого толка. Так же Rockchip планирует выпустить процессор RK3688 с 16 TOPS INT8 NPU. В общем, по моему мнению NPU - перспективная технология для запуска нейронных сетей на мобильных роботах, когда нет возможности разместить/запитать/охладить/купить мощную RTX4090.

Я считаю, что Luckfox Pico однозначно заслуживает внимания. Возможно в ближайшее время на базе неё появятся интересные проекты.

Все полезные ссылки по Luckfox я собрал здесь, постараюсь обновлять в процессе появления новых материалов, потому что пока статей/репозиториев мало (а на русском практически нет).