В итоге в этом образе у меня есть возможность полностью настроить пайплайн обработки, используя все аппаратные возможности (аппаратные кодеки, VPSS, чтобы заресайзить кадры в несколько каналов и т.д.)
Личи справится. Я не делал именно с mqtt, но я делал параллельно с rtsp стримом и YOLO детектором: постоянный обмен данными через UART, обмен данными через Zenoh. И ещё много свободных ресурсов оставалось. Касательно языка, не думаю, что будет особая разница, потому что особо большого потока данных не будет, тем более какой-то тяжёлой обработки. Единственное, через C++ решение будет более оптимальное по оперативной памяти, но и через MaixPy всё должно уложиться. В своих проектах на личи я MaixCDK (в том числе MaixPy) не использую, но это просто специфика такая (нужно выжимать максимум из платы), библиотеки от Sophgo более гибкие в этом плане. Но поверх части C/C++ кода я делал Python врапперы (собственно, MaixPy это такой же враппер поверх сишного MaixCDK) и всё хорошо работает. Главное, чтобы вся обработка данных шла через C/C++, а Python просто оркестрировал
Сам когда-то думал над этим. С одной стороны, если вы overlay рисуете не на стороне платы, а на стороне клиента, то нагрузка на процессор уменьшается, что достаточно важно в случае с lichee. Хотя, нагрузка от того, что вы пишите текст/прямоугольники рисуете достаточно низкая. Но в таком случае, клиент - это не просто ffmpeg/vlc, а уже что - то более сложное (хотя ffmpeg, наверное, и с таким справится, но там нужно будет постараться). Мне кажется, что смысл в отдельном потоке с детекциями есть, если вы кроме визуализации баундинг боксов с этими данными ещё что-то будете делать (записывать в какую-то внешнюю бд, отправлять какие-то уведомления и т.д.). По моему опыту, в большинстве задач визуализация детекций на стриме - это отладочная часть, т.е. когда устройство будет работать в продакшене, то визуализация будет выключена. И когда у вас два разных потока: изображение в RTSP и отдельно сокет с данными, то нужно их синхронизировать. Т.е. как минимум для каждого RTSP кадра и массива bbox нужно указывать совпадающий timestamp и при визуализации сопоставлять. При этом, если данные детекции скорее всего будут идти стабильно без потерь, то RTSP кадры могут пропадать, что тоже нужно будет учесть
Да, ещё вы можете в boot разделе создать файлик rndis.ipv4_prefix в котором прописать префикс для USB подсети (первые три октета). И тогда у вас будет статичный IP адрес для платы (и для компа тоже на самом деле, у него последний октет всегда 100 выдаётся)
Есть программный i2c5 на пинах A27 и A15. Касательно аудио входов/выходов глубоко не разбирался, но судя по схеме у них есть вход для простого микрофона через АЦП:
У них в английской версии документации есть не вся информация. В китайской есть следующая картинка (у неё внизу подписано, что пины P18-P23 заняты).
Отличная статья! А проводились/планируются ли эксперименты по исследованию погрешности определения координат объекта? И на самом деле кроме погрешности ещё интересны отклонения/шумы при разном нахождении маркера относительно оптического центра камеры.
Дисплеи подключать не пробовал (у меня просто интерес к плате другой). Касательно подключения не "из коробочных" дисплеев, я думаю там так же с драйверами могут возникнуть проблемы (необходимость самому писать). А распиновка разъёма, если я правильно понял про что идёт речь, публично доступна
Под эту плату из официального только buildroot, но он наверное даже ещё меньше openwrt должен быть. Тут главная проблема в том, чтобы всякие драйверы для работы со специфичными аппаратными возможностями завелись (в оф. образе они работают, но переносить в другие дистрибутивы, наверное, не очень просто будет). В целом, в buildroot не сложно добавлять кастомные пакеты. Но всё-таки buildroot это не дистрибутив, а просто система сборки
Можете осциллографом/логическим анализатором посмотреть на каких пинах что происходит после подачи питания. На TX пине будет характерный для UART сигнал, если конечно, ему не нужно отсылать какой - то пакет инициализации на RX, только после которого он начнёт отсылать данные (но вряд ли).
Yes, some time ago I tested model inference on Milk V Duo 256. I just take sample_yolov8 binary, test image, exported model and so libraries (same as I used for LicheeRV Nano). And it works without (as I remember) problems or special tuning
For custom object detection model I used yolo11n.pt base model, because it little faster than yolov8. But there is no difference in inference/run source code (you can just use sample_yolov8 program to run Yolo11 models).
Я скорее всего упоминал, но ещё раз тут напишу какой стек сейчас мне кажется самым удобным для личи:
Образ - https://github.com/scpcom/LicheeSG-Nano-Build. Он основывается на либах от Sophgo. В нём нормальный middleware (https://github.com/sophgo/middleware/), который без проблем работает с камерой.
Также теперь там последняя версия TDL SDK (https://github.com/sophgo/tdl_sdk).
В итоге в этом образе у меня есть возможность полностью настроить пайплайн обработки, используя все аппаратные возможности (аппаратные кодеки, VPSS, чтобы заресайзить кадры в несколько каналов и т.д.)
Личи справится. Я не делал именно с mqtt, но я делал параллельно с rtsp стримом и YOLO детектором: постоянный обмен данными через UART, обмен данными через Zenoh. И ещё много свободных ресурсов оставалось. Касательно языка, не думаю, что будет особая разница, потому что особо большого потока данных не будет, тем более какой-то тяжёлой обработки. Единственное, через C++ решение будет более оптимальное по оперативной памяти, но и через MaixPy всё должно уложиться.
В своих проектах на личи я MaixCDK (в том числе MaixPy) не использую, но это просто специфика такая (нужно выжимать максимум из платы), библиотеки от Sophgo более гибкие в этом плане. Но поверх части C/C++ кода я делал Python врапперы (собственно, MaixPy это такой же враппер поверх сишного MaixCDK) и всё хорошо работает. Главное, чтобы вся обработка данных шла через C/C++, а Python просто оркестрировал
Сам когда-то думал над этим. С одной стороны, если вы overlay рисуете не на стороне платы, а на стороне клиента, то нагрузка на процессор уменьшается, что достаточно важно в случае с lichee. Хотя, нагрузка от того, что вы пишите текст/прямоугольники рисуете достаточно низкая. Но в таком случае, клиент - это не просто ffmpeg/vlc, а уже что - то более сложное (хотя ffmpeg, наверное, и с таким справится, но там нужно будет постараться). Мне кажется, что смысл в отдельном потоке с детекциями есть, если вы кроме визуализации баундинг боксов с этими данными ещё что-то будете делать (записывать в какую-то внешнюю бд, отправлять какие-то уведомления и т.д.). По моему опыту, в большинстве задач визуализация детекций на стриме - это отладочная часть, т.е. когда устройство будет работать в продакшене, то визуализация будет выключена. И когда у вас два разных потока: изображение в RTSP и отдельно сокет с данными, то нужно их синхронизировать. Т.е. как минимум для каждого RTSP кадра и массива bbox нужно указывать совпадающий timestamp и при визуализации сопоставлять. При этом, если данные детекции скорее всего будут идти стабильно без потерь, то RTSP кадры могут пропадать, что тоже нужно будет учесть
Тогда у меня для Вас хорошие новости, следующая статья будет не менее душной!
Да, ещё вы можете в boot разделе создать файлик rndis.ipv4_prefix в котором прописать префикс для USB подсети (первые три октета). И тогда у вас будет статичный IP адрес для платы (и для компа тоже на самом деле, у него последний октет всегда 100 выдаётся)
Ну лучше поздно, чем никогда)
Есть программный i2c5 на пинах A27 и A15. Касательно аудио входов/выходов глубоко не разбирался, но судя по схеме у них есть вход для простого микрофона через АЦП:
У них в английской версии документации есть не вся информация. В китайской есть следующая картинка (у неё внизу подписано, что пины P18-P23 заняты).
Отличная статья! А проводились/планируются ли эксперименты по исследованию погрешности определения координат объекта? И на самом деле кроме погрешности ещё интересны отклонения/шумы при разном нахождении маркера относительно оптического центра камеры.
Дисплеи подключать не пробовал (у меня просто интерес к плате другой). Касательно подключения не "из коробочных" дисплеев, я думаю там так же с драйверами могут возникнуть проблемы (необходимость самому писать). А распиновка разъёма, если я правильно понял про что идёт речь, публично доступна
Что действительно круто, это то, что у Sophon открытые исходники SDK для NPU, в отличие от того же Rockchip.
Под эту плату из официального только buildroot, но он наверное даже ещё меньше openwrt должен быть. Тут главная проблема в том, чтобы всякие драйверы для работы со специфичными аппаратными возможностями завелись (в оф. образе они работают, но переносить в другие дистрибутивы, наверное, не очень просто будет). В целом, в buildroot не сложно добавлять кастомные пакеты. Но всё-таки buildroot это не дистрибутив, а просто система сборки
Я с openwrt никогда не работал, поэтому не могу сказать насколько просто его будет запустить. Но в целом, скорее всего это возможно
Very good blog
Можете осциллографом/логическим анализатором посмотреть на каких пинах что происходит после подачи питания. На TX пине будет характерный для UART сигнал, если конечно, ему не нужно отсылать какой - то пакет инициализации на RX, только после которого он начнёт отсылать данные (но вряд ли).
You can write to my telegram t.me/Rtyrdv
Yes
It is very good)
Yes, some time ago I tested model inference on Milk V Duo 256. I just take sample_yolov8 binary, test image, exported model and so libraries (same as I used for LicheeRV Nano). And it works without (as I remember) problems or special tuning
It is very strange, that you have such high FPS (1487), do you use proper libraries?
For custom object detection model I used yolo11n.pt base model, because it little faster than yolov8. But there is no difference in inference/run source code (you can just use sample_yolov8 program to run Yolo11 models).
You can find my custom yolo11 cvimodels here