Pull to refresh

Comments 71

PinnedPinned comments

Да, действительно, при обучении и экспорте в 320x320 я допустил несколько ошибок (видимо, в 2 часа ночи голова как - то не очень хотела думать):

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

Это пример детекта:

Примерный FPS: 49 - 50. Это выглядит очень круто! Есть конечно проблемы с ложными детектами, например такие:

С другой стороны NRF'ка в какой - то степени ESP-01 :)
С другой стороны NRF'ка в какой - то степени ESP-01 :)

Но эта проблема решается улучшением начальной модели/датасета.

Ещё касательно температур:
Проц нагревается до 65 градусов при постоянном инференсе модели (в течении минут 10-ти).

Спасибо большое за статью. Подскажите, пожалуйста, единица измерения TOPS, упомянутая в статье, может ли быть переведена во FLOPS? Если платы на руках нет, но как-то оценить производительность обнаружения нейросетью все равно хочется.

Забал упомянуть в статье. TFLOPS - TERA Float operations per second. Т.е. это для флоатов. TOPS - для интов. Данный npu не умеет обрабатывать флоаты, поэтому для него есть только tops характеристика. Некоторые, наоборот (jetson tx2 не умеет в int8, для него только tflops).На сколько я понимаю, какой-то линейной зависимости нет. Но yolo вроде выдаёт GFLOPS для модели, могу попозже посмотреть и дополнить.

Спасибо за ответ. На самом деле, как раз нелинейная зависимость flops и tops представляет особый интерес. Для меня не совсем ясно, существует ли зависимость вообще, или хотя бы корреляция.

Значения TOPS и TFLOPS сравнивать так не выйдет, так как всё зависит от оборудования. Плюс еще при переводе в int8 модели падает немного точность, так что надо в каждый конкретный случай отдельно смотреть. А еще те же видеокарты могут выдавать разные TFLOPS для случаев использования float16, float32 или float64 точностей. Тут вот например в Theoretical Performance можно глянуть.

Это просто подарок!

Как раз вчера озадачился выбором hello world проекта под данный проц.

Думаю портировать его поддержку под Openwrt.

Обеими руками плюсую статью и карму!

Приятно слышать, что статья кому - то помогла, спасибо)

Пожалуйста, если добавите поддержку, напишите статью, либо хотя бы отпишитесь тут. Спасибо!

Сколько труда!
1. Странно, что сети на 640х640 и 320х320 выдают одинаковое время. Может быть там ошибка в export ? Попробуйте 224х224 либо 480х480 обучить.
Криво отрисованные боксы, возможно они рисуются на image 640x640 ? Если нет, то что-то было на этот счет для onnx моделей (понятно, что у вас rknn) у ultralytics.
2. Грустно, что только одна камера в наличии и та global shutter.
3. И как результаты передавать ? sim800, здорово, конечно. Но может bluetooth или wifi ?

  1. Скорее всего я где - то ошибся при экспорте, я даже знаю где. Модель я обучил на 320x320, при этом квантизировал на изображениях 640x640. Скорее всего RKNN Toolkit сам не догадался ресайзнуть изображения. Это точно объясняет падение качества. На днях постараюсь аккуратнее перенести модель на 320x320 изображения.

  2. С камерой конечно беда и я пока не могу придумать как использовать более качественные камеры без глобального увеличения размеров устройства

  3. Думаю оптимальным с точки зрения простоты применения будет ESP-01, компактный модуль на основе ESP8266, управляется AT командами по UART'у. У меня он пока просто сам по себе полноценно не завёлся (не захотел к сети подключаться), но это нюансы отладки.

Да, действительно, при обучении и экспорте в 320x320 я допустил несколько ошибок (видимо, в 2 часа ночи голова как - то не очень хотела думать):

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

Это пример детекта:

Примерный FPS: 49 - 50. Это выглядит очень круто! Есть конечно проблемы с ложными детектами, например такие:

С другой стороны NRF'ка в какой - то степени ESP-01 :)
С другой стороны NRF'ка в какой - то степени ESP-01 :)

Но эта проблема решается улучшением начальной модели/датасета.

Ещё касательно температур:
Проц нагревается до 65 градусов при постоянном инференсе модели (в течении минут 10-ти).

1.Cтранно, что вы руками правите в ultralytics. Там все гораздо проще - загрузили модель, потом просто выполнили экспорт.
Например (это python):

from ultralytics import YOLO
model_yolov8 = YOLO('model.pt', task='detect') # load a custom model
model_yolov8.export(format='onnx', imgsz=320, int8=True)

  1. esp8266 лучше не брать, он чудит, ног мало и т.п. хоть и дешевый. Лучше esp32, nodemcu и т.п.

  2. С камерой можно просто решить - imx500, там вообще все на камере распознается. Но это, как говорится, совершенно другой ценник.

  3. 65 градусов прогрев - есть понимание как такое тепло отводить ?

  4. 50 fps - отлично! Но расстояния до объектов до 30 см, полагаю ?

  1. Да, почему - то не подумал об этом

  2. Касательно ESP32 - думаю да, это будет оптимальный вариант. Можно будет связать ESP32 и Luckfox по SPI и использовать её не только для передачи данных по WiFi/Bluetooth/esp_now, но и ещё управлять её пинами, чтобы расширить возможности Luckfox'а

  3. Ну да, дороговато

  4. Меня напрягает то, что SD карта находится практически вплотную нал процессором и от него греется. Самый простой вариант - обдувать каким-нибудь маленьким вентилятором (по типу тех, что ставят на кастомные корпусы для Raspberry), но мне такой вариант не очень нравится.

  5. Да, что - то около такого

Думаю оптимальным с точки зрения простоты применения будет ESP-01

Не рассматривали семейство ESP32 вместо ESP 8266?

ESP32 C3 SuperMini вполне подходит для домашних поделок.
Есть модификации с внешней антенной.

При цене меньше 2$ вполне решение.

Возможно и esp32 стоит рассмотреть. На самом деле, я сейчас думаю о разработке отдельной платы (на подобие ардуиновских шилдов) на которой будет разведена esp и luckfox просто будет в неё вставляться. Таким образом размеры итогового устройства сильно не увеличатся, но появится полноценный мк с WiFi, Bluetooth

Так есть же Luckfox Pico Ultra W со всеми беспроводными интерфейсами

Да, но она больше по размерам

... думаю о разработке отдельной платы (на подобие ардуиновских шилдов) на которой будет разведена esp и luckfox просто будет в неё вставляться.

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

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

Хорошо! Я прямо сейчас пока не начал работу, но буду иметь ввиду к кому обратиться.

Восхитительно! Ради таких статей нужно стараться писать свои, заслужить знак Легенда и ставить +3. А сейчас пока лишь +2, но была бы возможность, я бы поставил и +10.

Спасибо за высокую оценку моих трудов))

Спасибо, очень интересно! Нет ли у вас графиков энергопотребления данной сборки каким-нибудь тестером усб? Было бы очень любопытно взглянуть.

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

Провёл немного экспериментов с замером энергопотребления, пока примерно такие результаты:

Но это ещё пока не всё, позднее будут графики и более детальный анализ.

Нагрузка процессора определялась так: top -b -n 1 |grep ^CPU

Температура SoC'а: cat /sys/class/thermal/thermal_zone0/temp

Нагрузка на NPU: /sys/kernel/debug/rknpu/load

Питание подавалось на VBUS от лабораторника, команды отсылались через UART2

Большое спасибо! Очень интересные цифры.

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

Удивительная штуковина, даже не верится, что в ней помещается такая мощь! И, конечно, очень сильная статья, спасибо!

Сам не ожидал от неё таких результатов. И сначала скептически относился к тексту в описании товара: "AI Board ARM better than Raspberry Pi Pico"

Помимо FPS важна ещё задержка обработки (не знаю правильного термина) - от момента как событие произойдёт в реальности, обработается камерой, распознается нейронкой и выдастся сигнал - происходит некоторая задержка. Не замеряли её?

Если я понял, то она суммируется из:

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

Попробовал замерить для модели 320x320, получилась ~0.029345 секунды (без учёта отправки сигнала). Замерял так:

std::chrono::steady_clock::time_point begin = std::chrono::steady_clock::now();
cap >> camFrame;
cv::resize(camFrame, 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);
std::chrono::steady_clock::time_point end = std::chrono::steady_clock::now();
printf("Frame -> od_results latency: %lf\n", std::chrono::duration<double>(end - begin).count());

Мелочь, но всё же - почему begin не объявить просто как auto begin? Тот же вопрос про end.

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

Купил себе на поиграть 5 штук этих плат...

Первое, что сделал - исправил разметку, чтобы шить только через dd, без каких-либо утилит. Выкинул разметку по оффсетам, впилил человеческий gpt - полет нормальный.

Второе - завел все в gitlab ci, прикрутил сборку чистого билдрута, ибо в родном черт ногу сломит, даже питон есть.

Третье - добавил некоторые дисплеи, например, круглые, которые перепали по 80 рублей

Надо будет напилить статью, хороший проц на самом деле.

Напишите обязательно, очень интересно!

А где можно прочитать про разметку и gpt? Это uboot делается?

Поделитесь информацией о круглых дисплеях пожалуйста)

Спасибо большое за великолепную хабратортную статью. Вообще 128 МБ, ИМХО, может быть вполне достаточно для большинства задач. Роутеры вообще 8 метров флеша, 8 метров ОЗУ и работают много-много лет.

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

Сам знаю эти боли. Просто больше к тому, что объём вполне может быть достаточен для домашних поделок.

Да, в этом я с вами согласен. В процессе изучения устройства я закидывалл на него много разных тестовых программ, которые писал. Так же для оценки mAP закидывал часть датасета. Разные веса. В общем, на "продакшн" - достаточно 128 мб, а в процессе разработки хотелось бы побольше, просто удобнее.

А зачем вы обучаете на разных размерах? Это же йоло - обученный на 320х320 можно запустить хоть на 8192х4096

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

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

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

Есть ещё аналогичная по функционалу плата milk-v duo(нету там 2х ядер как это рекламируют :D)
У luckfox-pico-mini есть печальный недостаток - контакты аудиокодека с SoC не разведены на плате. В luckfox-pico это, например, сделано

Про milk v duo я читал, тоже думаю заказать потестить, обещают бОльшую производительность

На первый взгляд luckfox выглядит более "причёсанным" и работает пошустрее, чем milk-v duo
Если есть паяльная станция(фен) - рекомендую ещё докупить флешек на 256МБ
Брал тут:
W25N02KVZEIR
https://aliexpress.ru/item/1005002409382797.html

p.s Ещё летом тестировал оба одноплатника, нужен был аудиокодек и HW h264. По итогу получился такой score:
1. luckfox-pico
2. milk-v duo
3. luckfox-pico-mini A(с покупкой флешки)

О, спасибо. Да, есть возможность впаять их.

нету там 2х ядер как это рекламируют :D

Есть! Там даже 3 ядра. Правда с нюансами, второе risc-v ядро вроде как не имеет MMU, поэтому для линукса доступно только одно. На втором freertos крутить, можно использовать его для работы с дисплеями через параллельный интерфейс ногодрыгом (800x480 легко должно быть), а не страдать с десятью кадрами на 480x320 по SPI.

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

Ух, вот это проект! Тут нельзя просто так взять и пройти мимо без лайкоса!

Здравствуйте, не подскажете, как можно к такой платке прикрутить экранчик на spi или 8-бит интерфейсе? Или где об этом почерпнуть информацию?

В офф. доках есть список поддерживающихся дисплеев и примеры кода для запуска по spi/i2c. А ещё где-то выше человек писал, что заводил какие-то дисплеи на этом одноплатнике.

Подскажите пожалуйста, какую камеру использовали в эксперименте?

Вот эту SC3336, насколько я понял только её можно запустить из коробки

Здравствуйте, возникла проблема с выделением swap, при вводе команды mkfs.ext4 /dev/mmcblk1p8

Возникает ошибка does not exist and size specified. Пробовал два sd карты 32 GB, форматированные fat32, но в /dev есть все разделы кроме mmcblk1p8

Может сможете подсказать?

А вы ставили официальный Buildroot образ? Возможно у вас просто немого по-другому разбит весь образ и там другие разделы

Установил официальный образ, пробовал двумя способами: через python-скрипт и через SocToolkit, в обоих случаях образ записывается, через ADB подключается, но в /dev только:
mmcblk1
mmcblk1p1
...
mmcblk1p7
При попытке добавить swap:
[root@luckfox ]# mkfs.ext4 /dev/mmcblk1p8
mke2fs 1.46.5 (30-Dec-2021)
The file /dev/mmcblk1p8 does not exist and no size was specified.

Проблема решилась установкой старого образа из backup.

Что скажете о Sipeed LicheeRV и прочие одноплатники с SG2002?

Сейчас тестирую Sipeed LicheeRV Nano (в телеграмм канале периодически о ней что - то пишу), с ней есть свои нюансы/сложности, но yolo на ней работает быстрее и есть больше возможностей по квантизации (не только int8). В общем, планирую по ней подобную статью выпустить. Она не менее интересная, чем Luckfox Pico.

А подскажите, как оно по производительности в сравнении с минипеками на intel n100?

Yolov8 работает быстрее, но это благодаря NPU, обычные вычисления на процессоре будут медленнее. Но, опять же, я не видел мини пк с поддержкой CSI камер, только через USB. А CSI камеры обрабатываются аппаратно, в отличии от USB камер. В общем, где - то выигрывает в производительности, а где - то и отстаёт. Всё зависит от задачи и требований.

И обязательно ли ставить linux? Это же по идеи оверхед большой.

Я бы не назвал это оверхэдом, это очень удобная абстракция. Процессор там сложный, написать нативный код, да так чтобы NPU ещё работал (на который документации немного) - очень сложно. Но, внутри SoC'а есть MCU, я пока ещё не пытался его завести, но вот на него можно писать нативный код, но вряд ли у него есть доступ к NPU, а так же ISP. В общем, было бы прекрасно реализовывать всё без абстракций, но в данном случае это очень тяжело.

Нативный код навряд ли. А вот систему реального времени наверняка можно установить и получить прирост как в производительности, так и в энергоэффективности.

Да, RTOS установить можно, судя по даташиту в процессоре есть MCU, на который как раз должна вставать FreeRTOS. Хотя, в целом есть unix'овые qnx и другие.

Какое потребление тока у этой крохи?

Здесь графики для разных сценариев с usb тестера. И на скриншоте усреднённые данные.

В общем - чуть больше 1 Ватта.

Весьма неплохо для такой производительности. На плате стоит контроллер питания с DC-DC преобразователями, как я понимаю?

Интересно, получится ли эту платку вместе с камерой запитать через usb-otg телефона?

Да, через OTG, имеющим доп питание она запитывается и работает. У меня в канале/комментариях пробовал человек так делать и всё работало

Sign up to leave a comment.

Articles