Comments 54
Да, действительно, при обучении и экспорте в 320x320 я допустил несколько ошибок (видимо, в 2 часа ночи голова как - то не очень хотела думать):
Нужно при экспорте в onnx в файле /content/ultralytics_yolov8/ultralytics/cfg/default.yaml кроме пути к модели поменять параметр imgsz. Так же для квантизации, в коллабе в ячейке с генерацией списка файлов калибровки я добавил ресайз в нужное разрешение. Кстати, квантизация изображениями 320x320 происходит практически моментально!
Это пример детекта:
Примерный FPS: 49 - 50. Это выглядит очень круто! Есть конечно проблемы с ложными детектами, например такие:
Но эта проблема решается улучшением начальной модели/датасета.
Ещё касательно температур:
Проц нагревается до 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 ?
Скорее всего я где - то ошибся при экспорте, я даже знаю где. Модель я обучил на 320x320, при этом квантизировал на изображениях 640x640. Скорее всего RKNN Toolkit сам не догадался ресайзнуть изображения. Это точно объясняет падение качества. На днях постараюсь аккуратнее перенести модель на 320x320 изображения.
С камерой конечно беда и я пока не могу придумать как использовать более качественные камеры без глобального увеличения размеров устройства
Думаю оптимальным с точки зрения простоты применения будет ESP-01, компактный модуль на основе ESP8266, управляется AT командами по UART'у. У меня он пока просто сам по себе полноценно не завёлся (не захотел к сети подключаться), но это нюансы отладки.
Да, действительно, при обучении и экспорте в 320x320 я допустил несколько ошибок (видимо, в 2 часа ночи голова как - то не очень хотела думать):
Нужно при экспорте в onnx в файле /content/ultralytics_yolov8/ultralytics/cfg/default.yaml кроме пути к модели поменять параметр imgsz. Так же для квантизации, в коллабе в ячейке с генерацией списка файлов калибровки я добавил ресайз в нужное разрешение. Кстати, квантизация изображениями 320x320 происходит практически моментально!
Это пример детекта:
Примерный FPS: 49 - 50. Это выглядит очень круто! Есть конечно проблемы с ложными детектами, например такие:
Но эта проблема решается улучшением начальной модели/датасета.
Ещё касательно температур:
Проц нагревается до 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)
esp8266 лучше не брать, он чудит, ног мало и т.п. хоть и дешевый. Лучше esp32, nodemcu и т.п.
С камерой можно просто решить - imx500, там вообще все на камере распознается. Но это, как говорится, совершенно другой ценник.
65 градусов прогрев - есть понимание как такое тепло отводить ?
50 fps - отлично! Но расстояния до объектов до 30 см, полагаю ?
Да, почему - то не подумал об этом
Касательно ESP32 - думаю да, это будет оптимальный вариант. Можно будет связать ESP32 и Luckfox по SPI и использовать её не только для передачи данных по WiFi/Bluetooth/esp_now, но и ещё управлять её пинами, чтобы расширить возможности Luckfox'а
Ну да, дороговато
Меня напрягает то, что SD карта находится практически вплотную нал процессором и от него греется. Самый простой вариант - обдувать каким-нибудь маленьким вентилятором (по типу тех, что ставят на кастомные корпусы для Raspberry), но мне такой вариант не очень нравится.
Да, что - то около такого
Думаю оптимальным с точки зрения простоты применения будет 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
Удивительная штуковина, даже не верится, что в ней помещается такая мощь! И, конечно, очень сильная статья, спасибо!
Помимо 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());
Купил себе на поиграть 5 штук этих плат...
Первое, что сделал - исправил разметку, чтобы шить только через dd, без каких-либо утилит. Выкинул разметку по оффсетам, впилил человеческий gpt - полет нормальный.
Второе - завел все в gitlab ci, прикрутил сборку чистого билдрута, ибо в родном черт ногу сломит, даже питон есть.
Третье - добавил некоторые дисплеи, например, круглые, которые перепали по 80 рублей
Надо будет напилить статью, хороший проц на самом деле.
Спасибо большое за великолепную хабратортную статью. Вообще 128 МБ, ИМХО, может быть вполне достаточно для большинства задач. Роутеры вообще 8 метров флеша, 8 метров ОЗУ и работают много-много лет.
Это справедливо для серийной железки в релизном варианте. В игрушке или дебаге такой подход не очень удобен, поскольку шить банально неудобно - или прищепкой, или фирменной утилитой под винду. Видел даже серийные образцы тех же планшетов, где в релизе eMMC, но в инженерных версиях для разрабов стоит uSD-флешка, либо eMMC на отдельной мини-платке.
А зачем вы обучаете на разных размерах? Это же йоло - обученный на 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, насколько я понял только её можно запустить из коробки
Запускаем Yolo на пятирублёвой монете или Luckfox Pico Mini