По мои непълни и неангажиращи наблюдения, колкото по-евтино изпълнение е автомобила, толкова по-лошо работи тая екстра.
А доста често важи и за останалите екстри...


Така е, но понеже не касае частта с датчик / камера, и го пропуснах.

Странно... И аз го пробвах и мога да потвърдя

Какъв точно е тоя Дейвид Майер и защо е голяма драма, че не е актуализирана програмата? Повече бих се притеснил, ако чата не знаеше кой е Дейвид Ковърдейл

Поне веднъж копилота да е напред:

И нашия Тъпанчев отговаря без проблем за Дейвид Майер де Ротшийлд.

Знам какво е класическия детектор, обаче аз не правя нещата просто за да работят. Камера + TF + OpenCV могат да добавят много функционалности, не само въпросните дъжд и насрещни фарове. По-нататък мислех да накодя и асистент за паркиране и прочие.

криво ляво го разбрах ... на теория
NPU са "бързи калкулаторчета" за "умножение" на тегла/матрица (слой от невронната мрежа)
( и други невронни функции )

на практика ... е мазало - NPU не са "стандартни" при всичките производители
следователно - много непознати API библиотеки към NPU
Туй едно, другото е че чипмейкъра си мисли, че ще прави огромни "лимони" и -> "секретна" документация и скъп развой

Математиката е елементарна. Зависи от архитектурата, но общо взето се свежда до това за всеки слой от невронната мрежа да сметнеш

като активиращата функция може да е толкова проста колкото едно макс(0,х), а конволюцията едно просто умножение. Обаче за да е практически релевантно сметките трябва да вървят паралено и с това изборът на хардуер определя какви възможности имаш. И там опираш до

1. FPGA - това е най-доброто ако търсиш бърза реакция, защото си дялкаш всичко според архитектурата на мрежата и заданието
2. АРМ CPU - това е най-универсалното и като се има предвид колко работа наливат от 2 години в АРМ по ускорителите може би най-правилния избор в дългосрочен план. Можеш да работиш както с TensorFlow Lite така и с PyTorch Mobile, аз бих препоръчал второто. Ще намериш по-лесно разработчици в момента. Това което повтаряш, че архитектурите и моделите не те интересуват няма как да стане. След няколко години може би, но сега сме на ниво пишем фирмуер за първите ПИК-ове и оптимизираме достъп до паметта...
3. Nvidia/Jetson - това е мощно и често го ползват за обработка на видео. Идва си с техния си фреймуорк и библиотеки и съответно сваляш гащи
4. Google/Edge TPU - и това си идва с техния софтуер и библиотеки и сваляш гащи още повече от горните
5. Intel/Movidius - тези даже нямат нито фреймуорк, нито библиотеки нито документация която да е като хората. Нито ще ти обърнат внимание, нито ти си струва да си губиш времето 


Така погледнато, за начало най-лесно би било да вземеш някое бордче от Lattice ако ще вървиш по 1) или нещо с АРМ, стига да има NEON разширенията ако ще вървиш по 2) За целта и едно Пи ще свърши работа, backend библиотеките на гореспоменатите фреймуоркове са оптимизирани за тях

ясно...
горе описах, че самото обучение на AI, теорията и математиката за обучението изобщо не ме интересува

интересува ме Embedded реализация - малки чипове с NPU / библиотеки ...
индустриално прилагане на AI за "физични" процеси, "генерирани" от сензори
изключвам видео/аудио ... Nvidia, PI blah - Linux - машинно зрение и слух - рабтата е "ясна"
( пример MYXATA - защита на мотор )

ще "копам" по темата - че видим

Да, исках просто да наблегна, че


нищо по-различно от алгоритмичните embedded така погледнато

има нещо такова

предполагам, че проблемите ще са свързани с документацията около хардуера
код ... код се пише и предполагам ще се реверсва "сложното"(видео) за да се напише за "малкото"(сензори)

за сега само ресърчвам какво пише в мрежата ... да ми се изясни картинката

Няма какво да рисърчваш Накарай чата да ти проведе един бърз курс по темата. Много добре се справя. Дори и ще те изпита накрая и ще ти даде домашно

Кой рисърчва в днешно време без чата?

Да се похваля, че и аз използвах chatLGBT по предназначение.
Ем, дава някакъв грешен отговор и ако не знаеш какво да очакваш, ходи се оправяй

Аз например, защото предпочитам да знам какво правя, не да бъда лъган и да губя часове и дни, за да може програмата да се сети какво точно я питам. Реших един път да дам шанс на такива програмки относно термодинамиката на флуидите и ми изгуби няколко дни, защото ме подлъга на грешни следи. След това сам си търсих, четох, разбрах, смятах, направих го. И го обясних на програмата - къде ме е забила в грешни изследвания, формули, предположения, защото знаеш ли, лъже като малко дете, за да си обясни някаква формула, дето не може да открие от раз. Видиш ли тази константа била "емпирична" и "често се ползвала при анализ на форсирана конвекция" и т.н. и т.н. Ама не знае откъде идва, докато не и посоча истински сорс. После почват пак извинения и колко съм бил прав. И преди съм го писал - ако искаш да затъпееш, разчитай на тези програми. Аз ги ползвам предимно за проверки и да спестя черна работа, но стигне ли се до това да си размърдам мозъка, няма да го дам на чатовете. За програмирането - въпреки, че не съм програмист и не го правя всеки месец, имам много забележки, ама много. С моя малък опит там пак намирам сравнително често по-лесни или елегантни решения от предложените кодове от програмите, което също ме учудва. Би трябвало да е точно обратното.