Да, в этом я с вами согласен. В процессе изучения устройства я закидывалл на него много разных тестовых программ, которые писал. Так же для оценки mAP закидывал часть датасета. Разные веса. В общем, на "продакшн" - достаточно 128 мб, а в процессе разработки хотелось бы побольше, просто удобнее.
Возможно и esp32 стоит рассмотреть. На самом деле, я сейчас думаю о разработке отдельной платы (на подобие ардуиновских шилдов) на которой будет разведена esp и luckfox просто будет в неё вставляться. Таким образом размеры итогового устройства сильно не увеличатся, но появится полноценный мк с WiFi, Bluetooth
задержка чтения кадра + задержка инференса + задержка пост-процессинга + задержка "выдавателя сигнала" (просто это может быть как условный GPIO пин, так и какой-нибудь радио - модуль и у них задержка будет разная).
Попробовал замерить для модели 320x320, получилась ~0.029345 секунды (без учёта отправки сигнала). Замерял так:
Пока нет, только от лабораторника один раз запускал, точно помню, что максимальное потребление было гораздо меньше 1 Ампера, но сколько конкретно и при какой нагрузке сейчас сказать не могу. Постараюсь как - нибудь провести эксперимент и собрать данные по отношению нагрузки к потреблению.
Да, действительно, при обучении и экспорте в 320x320 я допустил несколько ошибок (видимо, в 2 часа ночи голова как - то не очень хотела думать):
Нужно при экспорте в onnx в файле /content/ultralytics_yolov8/ultralytics/cfg/default.yaml кроме пути к модели поменять параметр imgsz. Так же для квантизации, в коллабе в ячейке с генерацией списка файлов калибровки я добавил ресайз в нужное разрешение. Кстати, квантизация изображениями 320x320 происходит практически моментально!
Это пример детекта:
Примерный FPS: 49 - 50. Это выглядит очень круто! Есть конечно проблемы с ложными детектами, например такие:
С другой стороны NRF'ка в какой - то степени ESP-01 :)
Но эта проблема решается улучшением начальной модели/датасета.
Ещё касательно температур: Проц нагревается до 65 градусов при постоянном инференсе модели (в течении минут 10-ти).
Скорее всего я где - то ошибся при экспорте, я даже знаю где. Модель я обучил на 320x320, при этом квантизировал на изображениях 640x640. Скорее всего RKNN Toolkit сам не догадался ресайзнуть изображения. Это точно объясняет падение качества. На днях постараюсь аккуратнее перенести модель на 320x320 изображения.
С камерой конечно беда и я пока не могу придумать как использовать более качественные камеры без глобального увеличения размеров устройства
Думаю оптимальным с точки зрения простоты применения будет ESP-01, компактный модуль на основе ESP8266, управляется AT командами по UART'у. У меня он пока просто сам по себе полноценно не завёлся (не захотел к сети подключаться), но это нюансы отладки.
Забал упомянуть в статье. TFLOPS - TERA Float operations per second. Т.е. это для флоатов. TOPS - для интов. Данный npu не умеет обрабатывать флоаты, поэтому для него есть только tops характеристика. Некоторые, наоборот (jetson tx2 не умеет в int8, для него только tflops).На сколько я понимаю, какой-то линейной зависимости нет. Но yolo вроде выдаёт GFLOPS для модели, могу попозже посмотреть и дополнить.
Яндекс - диск. Excel файлы открываются во встроенном редакторе. Так же имеется api для получения/загрузки файлов. Да, не так удобно, как с гуглом, но всё - же можно назвать аналогом. Подобный функционал (из статьи) можно получить.
У него на видео какой - то неправильный код (на скрине из гитхаба, но в видео он такой же), а точнее часть по замеру FPS. Он после инференса перезаписывает start_time. И в итоге у него разница во времени не между началом инференса и концом, а концом инференса и концом пост-процессинга.
А с какой частотой происходил сбор и процессинг(получение окончательных данных о позиции робота) с MPU6050? Какие - то фильтры применяли? И какая по-итогу была точность локализации, если замеряли?
Спасибо за ответ. В теории можно попробовать запускать параллельно "быструю детекцию" и sahi. Т.е. пока нет результатов работы SAHI используются данные с других методов. И в итоге все данные комплексируются. Но для этого нужно дополнительные мощности, а также если дрон летит быстро, то пока SAHI его обработает он может улететь.
Да, в этом я с вами согласен. В процессе изучения устройства я закидывалл на него много разных тестовых программ, которые писал. Так же для оценки mAP закидывал часть датасета. Разные веса. В общем, на "продакшн" - достаточно 128 мб, а в процессе разработки хотелось бы побольше, просто удобнее.
Да, но она больше по размерам
Возможно и esp32 стоит рассмотреть. На самом деле, я сейчас думаю о разработке отдельной платы (на подобие ардуиновских шилдов) на которой будет разведена esp и luckfox просто будет в неё вставляться. Таким образом размеры итогового устройства сильно не увеличатся, но появится полноценный мк с WiFi, Bluetooth
Сам не ожидал от неё таких результатов. И сначала скептически относился к тексту в описании товара: "AI Board ARM better than Raspberry Pi Pico"
Если я понял, то она суммируется из:
задержка чтения кадра + задержка инференса + задержка пост-процессинга + задержка "выдавателя сигнала" (просто это может быть как условный GPIO пин, так и какой-нибудь радио - модуль и у них задержка будет разная).
Попробовал замерить для модели 320x320, получилась ~0.029345 секунды (без учёта отправки сигнала). Замерял так:
Пока нет, только от лабораторника один раз запускал, точно помню, что максимальное потребление было гораздо меньше 1 Ампера, но сколько конкретно и при какой нагрузке сейчас сказать не могу. Постараюсь как - нибудь провести эксперимент и собрать данные по отношению нагрузки к потреблению.
Спасибо за высокую оценку моих трудов))
Да, действительно, при обучении и экспорте в 320x320 я допустил несколько ошибок (видимо, в 2 часа ночи голова как - то не очень хотела думать):
Нужно при экспорте в onnx в файле /content/ultralytics_yolov8/ultralytics/cfg/default.yaml кроме пути к модели поменять параметр imgsz. Так же для квантизации, в коллабе в ячейке с генерацией списка файлов калибровки я добавил ресайз в нужное разрешение. Кстати, квантизация изображениями 320x320 происходит практически моментально!
Это пример детекта:
Примерный FPS: 49 - 50. Это выглядит очень круто! Есть конечно проблемы с ложными детектами, например такие:
Но эта проблема решается улучшением начальной модели/датасета.
Ещё касательно температур:
Проц нагревается до 65 градусов при постоянном инференсе модели (в течении минут 10-ти).
Приятно слышать, что статья кому - то помогла, спасибо)
Скорее всего я где - то ошибся при экспорте, я даже знаю где. Модель я обучил на 320x320, при этом квантизировал на изображениях 640x640. Скорее всего RKNN Toolkit сам не догадался ресайзнуть изображения. Это точно объясняет падение качества. На днях постараюсь аккуратнее перенести модель на 320x320 изображения.
С камерой конечно беда и я пока не могу придумать как использовать более качественные камеры без глобального увеличения размеров устройства
Думаю оптимальным с точки зрения простоты применения будет ESP-01, компактный модуль на основе ESP8266, управляется AT командами по UART'у. У меня он пока просто сам по себе полноценно не завёлся (не захотел к сети подключаться), но это нюансы отладки.
Забал упомянуть в статье. TFLOPS - TERA Float operations per second. Т.е. это для флоатов. TOPS - для интов. Данный npu не умеет обрабатывать флоаты, поэтому для него есть только tops характеристика. Некоторые, наоборот (jetson tx2 не умеет в int8, для него только tflops).На сколько я понимаю, какой-то линейной зависимости нет. Но yolo вроде выдаёт GFLOPS для модели, могу попозже посмотреть и дополнить.
Яндекс - диск. Excel файлы открываются во встроенном редакторе. Так же имеется api для получения/загрузки файлов. Да, не так удобно, как с гуглом, но всё - же можно назвать аналогом. Подобный функционал (из статьи) можно получить.
Так я не говорю, что нужно в статье про гугл - таблицы писать про другие сервисы. Статья изначально должна быть про другой сервис
Мне кажется, что в текущих реалиях более актуально будет использовать какие - нибудь российские сервисы, аналогичные гугл документам.
llava будет оверхедом для данной задачи. Лучше будет работать модель, которая заточена под конкретные объекты.
У него на видео какой - то неправильный код (на скрине из гитхаба, но в видео он такой же), а точнее часть по замеру FPS. Он после инференса перезаписывает start_time. И в итоге у него разница во времени не между началом инференса и концом, а концом инференса и концом пост-процессинга.
А с какой частотой происходил сбор и процессинг(получение окончательных данных о позиции робота) с MPU6050? Какие - то фильтры применяли? И какая по-итогу была точность локализации, если замеряли?
Спасибо за ответ. В теории можно попробовать запускать параллельно "быструю детекцию" и sahi. Т.е. пока нет результатов работы SAHI используются данные с других методов. И в итоге все данные комплексируются. Но для этого нужно дополнительные мощности, а также если дрон летит быстро, то пока SAHI его обработает он может улететь.
А вы не тестировали качество детекции SAHI, вроде специально разработана для мелких объектов?
Я под линуксом использую spoof-dpi