Страховая — это хороший регулятор. Но есть вариант «рынка». Самые современные по инновациям — частные клиники. Там и информационная система, и современное оборудование.
Если разбираться глубже, то даже поликлиника/больница — это бизнес единица. Сейчас многие на самоокупаемости. Деньги они получают за страховки/за платные услуги. Главврачи определяют бюджет/зарплаты. Они конкурируют за врачей. Если им выгодно поставить какой-то алгоритм — они ставят.
В Москве есть сейчас ДИТ. От него идут какие-то инновации. Но, конечно, это не самый правильный путь.
Врачам никогда не будет интересна система, которая заменяет врача, потому что она отбирает у них хлеб.
Это не совсем так. И автоматический анализ ЭКГ уже давно внедрён. И куча анализов уже давно внедрены.
Да и сами врачи в первых рядах голосуют за введение систем автоматизации документаоборота.
Просто внедрять надо аккуратно.
Это очень тонкая грань, по моему опыту врачи любят heatmap и диаграммы признаков (слой показателей перед max/softmax), им это нравится.
Пробовали внедрять и так и так. Общался с большим числом компаний, которые пробовали внедрять. Врачи говорят «да, прикольно», пока ты им прототип показываешь. Заставляешь пользоваться — отключают/не интересно/зачем мне это.
Такая штука не автоматизирует/ не помогает в работе/не несёт особого смысла.
Я понимаю почему оно может быть внедрено на уровне аппаратуры. Но это скорее инвестиция в будущее. Сегодняшние врачи будут пользоваться только тем что будет экономить их время/заполнять за них документы.
Таких сервисов достаточно много в последние годы. Никто ими не пользуется + это общее ухудшение качества здравоохранения. Ибо нейронка не решает вопрос «вовлечения» человека в лечение. Врачи во многом решают вопрос нехватки информации, и для 95% населения это критично.
Это неплохая идея, её многие обсуждают. Но:
1) Человек не может принять правильного решения на основании описания флюорограммы/мамограммы и.т.д. Ровно для этого нужны врачи. В качестве примера можно привести ту же Европу — там даже какие-то примитивные лекарства вам без рецепта не продадут. Это всё делается так как люди, когда дело доходит до их здоровья — предвзяты и некомпетентны.
2) Видел уже пару таких сервисов. Люди предпочитают людей однозначно. Их пугает любая автоматизация. Каждый в больнице считает что он уникален.
Вы хотите полностью изменить существующую модель с дырками на другую модель с дыркам. В вашей моделе не только дыр много, но и ещё ВСЕ законы менять нужно. Очевидно, что это невозможно.
То что я рассказываю и предлагаю — успешно работает. Посмотрите примеры снизу — там уже врачи вписаны в систему. Эффективность повышена в десятки раз, качество услуги — тоже. Однообразность не мешает. При большом объёме работы, без бумажной волокиты — врачу спокойнее работать, его качество работы растёт.
Но в целом, если примеры перешли на налоговую, то разговор надо сворачивать:)
Ещё раз повторю мысли из статьи:
1) Ситуаций «И так всё ясно» — не будет. А если будут, то и врачи там нормально распознают и без нейронных сетей. А в ситуациях «треш и угар» — нейронные сети будут даже хуже врачей.
2) Никто не будет внедрять сети пока не будет решён вопрос ответственности за ошибки. В том числе за очевидные ошибки. Какие-бы у вас не были пожелания — никто не будет брать на себя ответственность и сертифицировать. И никакие «нейросети должны» тут не помогут. Я так же могу сказать что вы должны:)
Обучать врачей всё равно придётся. И ваш аргумент «не вариант» — очень уныл. Просто этот процесс надо стандартизировать. До той же степени до которой стандартизировано распознавание пистолетов в аэропортах. Проводить проверку врача в том числе на рабочем месте, добавляя фейковые картинки. Чтобы каждый день врач работал с большим объёмом данных и учился на своих ошибках.
Это возможно, примеров работы таких система достаточно много.
Но надо разгружать врачей от ненужной писанины, нужно давать врачам удобные рабочие места и инструменты просмотра.
Почему-то в большинстве европейских стран сумели к этому придти. И нам надо лечить изначальные проблемы, а не затыкать их нейроночками. Если другие смогли — и в этой стране всё получиться:)
Однажды хотел поставить приложение Ленты. Оно мне выкинуло длинное согласие где обясняло что будет делать с моими данными что угодно/передавать их любым другим фирмам и использовать и перепродавать. Охренел и ставить не стал.
Мне не кажется что это «монополия». Встречал подобные выкрутасы и у фирм мельче.
2) Собственно я и говорю — что было бы интересно посмотреть сравнение. Оптимизировать свёртки можно разными путями. Может у вас всё сильно лучше вышло.
4) Там есть какой-то FPU (VFP), если я правильно понимаю. И максимальную производительность вроде как вытаскивают с него. Я просто не очень глубоко копал, но заметил что некоторые фреймворки основной процессор почти не грузуили. Читал описание что они вычисления на математическом сопроцессоре гоняют.
1) Но вы ставите в минус OpenVINO именно невозможность работать на ARM'ах. Что OpenCV неплохо реализует.
2) OpenVINO ещё оптимизирует свёртки и их последовательность для оптимального использования памяти. Так что интересно именно сравнение производительности.
3) Чем больше форматов, тем больше сеть теряет при перегонке. Например: чтобы выгрузить PyTorch -> TensorRT надо сделать 2 конвертации. Чтобы выгрузить TensorFlow в Google TPU там где-то 3 нужно было. И каждая конвертация режет список возможных слоёв/соединений, и.т.д.
Чем ближе вы к графу исходной сети — тем лучше. Чем дальше вы — тем сложнее вас использовать. Использование ONNX даёт вам всего один хоп до исходной сети. При этом ONNX очень много что поддерживает.
4) Мне кажется что там сопроцессор. Вы поддерживаете именно его? Или разбиваете на процессор + сопроцессор? Просто, например, Caffe2 считал только на сопроцессоре в RPi 3 (была нулевая загрузка проца, по времени получалось раза в полтора быстрее чем ту же сетку инферить на проце простой версией Caffe с его 100% загрузкой). OpenCV, если я правильно помню, инферит на обоих устройствах. Но я не понимаю как они задачи согласуют/раскладывают.
Возникает пара логичных вопросов:
1) А почему только с OpenVINO сравнение. а с OpenCV нет? Он то как раз умеет на армах инферить. Хотя не помню что там с поддержкой именно на мобильниках.
2) На i7 i9 вы сравнивали производительность с OpenVINO? Мне кажется у вас достаточно медленно.
3) Почему не поддерживаете какой-нибудь ONNX который сейчас по сути стандарт для передачи моделей между разными фреймворками?
4) Я правильно понимаю, что у вас только поддержка базовой архитуктуры? Для того же RPi NEON-совместимое ядро не будет поддерживаться? Так же как GPU-на чипе для Intel?
Смотрите. Ещё раз.
У вас в примере неправильный ответ. С вероятностью 99%. Где вы получили — я не знаю. Но десять лет работы в computer vision как бы кричат об этом. Мне лень выкачивать ваш пример/искать в нём ошибки и тратить на это больше того полу часа который я потратил чтобы найти вашу первую ошибку.
Могу лишь предположить что это где-то:
1) В непонятном использовании деления train и val, которое в вашем случае использовать не надо
2) В том что вы обучаете на val который может совпадать с train
3) В не потёртых где-то сохранённых файлах, из-за которых вы грузите что-то не то для обучения вместо ImageNet весов
4) В ошибках вашего fast.ai который где-то что-то засвопил не то.
И прочее и прочее.
Смотрите. 95% работы нормального DS'а — это сбор данных и проверка корректности всего что он делает. Обучить модель — вечер. Почему ваше решение не корректно?
1) Если вы откроете конкурсы на kaggle, то сможете убедиться что точность ResNet от техники обучения может изменяться максимум на проценты (если не делать явных косяков).
2) Точность людей в определении паталогий по рентгенограммам ~85-95%. Это справедливо и для флюрограмм и для мамограмм. В целом, есть неплохое мета-исследование которое оценивает эти точности — www.sciencedirect.com/science/article/pii/S2589750019301232
К чему это я. К тому что в вашем датасете по которому вы учитесь минимум ~3-4% — это ошибки и неоднозначные классификации. Соответственно вы не можете получить точность выше.
Ещё раз. Вы не выучили урок. «У меня лучше» -> ищите ошибку.
Обучать надо на обучении а проверять на тесте. Никаких «При этом делить изображения на обучающую и валидационную выборки будем случайным образом 80/20».
У вас в трейне и в тесте много данных по одним и тем же людям. Люди из train и test — не пересекаются. Но как только хоть один человек попадает из test в train — у вас точность прыгает на порядок. Да, организаторы судя по всему не удосужились это написать. Но такие вещи всегда надо учитывать.
Как бы сказать.
Если вдруг в каком-то исследовании получается точность на порядок выше, чем все другие подходы, при этом ничего реально нового не сделано (политика обучения влияет лишь на сходимость, замораживание/размораживание вообще глобально не влияет), то вариантов лишь два:
1) Все кто делал это исследование до вас некомпетентны
2) У вас где-то ошибка
Учитывая что вы обучаете самый простой ResNet, при этом всё обучение идёт достаточно классическим способом, то я бы ставил на то что ошибка у вас (обучалось/оттьюнилось на тесте/на валидации). И, кстати, соседнее ядро с вашим на Каггле грешит именно этим — www.kaggle.com/yasserlatreche/pneumonia-99-accuracy-using-densenet121
И точности там примерно как у вас.
А, нашёл. Вы даже сами про это говорите.
В нашем случае мы будем игнорировать распределение изображений по папкам train, val и test
Дальше надо объяснять почему всё что вы сделали — чушь?
— P.S.
В целом это и есть проблема использования любого deep learning. Он должен использоваться в первую очередь исходя из здравого смысла. Это лишь инструмент. И любая странность и неоднозначность — это лишь повод сказать себе «кажется я где-то накосячил». И начать искать этот косяк.
Это работающий комбайн. Который можно тащить. В отличии от PIL | matplotlib | dlib и прочего. Который скорее всего и так понадобиться для захвата потока с камеры/для загрузки/сохранений/для инференса нейронок если это какие-то неспециализированные устройства.
Конечно, если вы на калькуляторе обрабатываете — то лучше всё самому написать. А если уже на RPi — то памяти вам хватит, а по процессору OpenCV — это весьма неплохой вариант. Сколько в нём ковырялся — ни разу не видел именно «убогих» реализаций, в отличие от тех же dlib | PIL | PCL | AForge, которые я тоже мало-мало ковырял.
Не надо в проде использовать PIL, matplotlib и прочий бажный набор библиотек. Давным давно есть OpenCV, с которым всё интегрировано и который решает 90% проблем. И EXIF, и стриминг видео, и сохранение, и поддержку десятков форматов, и.т.д., и.т.п.
По сути это стандарт последние 10 лет. В отличие от того же matplotlib он быстрый, стартанёт на любом устройстве и не тащит кучу зависимостей.
Спасибо!
Кстати, по цене достаточно адекватен + вроде по начинке разумен. Единственное, хочется верить что Movidius там на пате, а не по USB воткнут. А то пока гуглил натыкался на похожий, где просто в корпусе была флешка.
Если что, то даже распознавание номера верифицируется сотрудником который штраф подписывает. А ещё так — habr.com/ru/news/t/468675. Естественно, они сначала откатали алгоритмы на которых вероятность ложного штрафа <0.1%.
Вы как-то очень странно и к интеграции OpenSource в продукт относитесь. Естественно, там свой форк делается, который тестами обкладывается. И естественно, нужна свои программисты которые эту ветку потом держат. 99% того что вы вокруг видите (включая кодеки на вашем компе/прошивку вашего телефона) — использует наработки OpenSource проектов… В тех же самолётах вся мультимедийная системы из открытых сборок линукса…
Ваша парадигма была применима 10-15 лет назад. И, может быть, будет применима через 10 лет. Сейчас — нет. Сейчас можно сделать успешный/хороший и конкурентный продукт за пару месяцев. Вот например вы говорите «год разработки». Но это не так. Я видел 3-4 примера как что-то разрабатывали на ПЛИСах задачи машинного зрения/интеллектуального управления. И это всегда года два в лучшем случае.
Основная причина того что ПЛИСы сейчас не работают в ML — в том что для ML задач сейчас парадигма разработки лежит в плоскости Software 2.0. Это динамическая, постоянно изменяющаяся структура постановки задачи и находимого решения. Вчера вы могли считать что ваш продукт — распознавание номеров. Завтра, что ваш продукт — распознавание номеров + контроль соблюдения логики ПДД, включая контроль пешеходов. Послезавтра — что ваш продукт это номера+пдд, но реально ваша цель — сбор информации о том какие марки авто в этом районе.
Эти задачи можно просто и быстро решать когда у вас быстрый продакшн. Например в CherryHome мы можем поменять курс развития или протестировать новые идеи за месяц.
Рынок систем распознавания номеров захватила система которая была сделана на Jetson. Именно из-за простоты и быстроты разворачивания. Её ребята продавали через 4 месяца после начала разработки (не скажу что оно у них хорошо работало, но что-то показывали).
Когда мы лицензировали нашу системы распознавания номеров, то оказалось что заказчику нужно распознавать британские номера. Мы переобучили всё за пару недель.
Я могу сказать десятки других случаев когда системы спасла именно возможность динамически перестроиться/изменить рабочий концепт.
И тратить год времени на то чтобы сделать прототип — это не вариант.
Конечно, я понимаю, что есть ситуации когда ПЛИСы могут иметь смысл. Ну, например, когда вы монополист захвативший рынок распознавания номеров — вы хотите более дешёвого и стабильного решения. Тогда можно существующую системы переписать на ПЛИСы.
Про ваш пример:
Но вот вы видели много опенсоурсных прошивок, например, на embedded системы для самолетов или автомобилей
Я могу сказать лишь одно. OpenSource зачастую имеет выше качество чем продуктовый код. А для вашего условного самолёта нет разницы что за железо и что за софт вы используете. Единственная критичная точка — это как вы тестируете/как вы резервируете. Сделать это можно и в парадигме «делать логику на ПЛИСах» и в парадигме «воткнём 3 резервирующих Jetson'а».
Тут возникает вопрос в специалистах, конечно. По ПЛИСам их очень мало, но никогда не поздно учиться.
Специалистов по ПЛИСам мало. Но их и не требует рынок. В отличие от того же ML. Если бы в ПЛИСах было много работы и денег — было бы куча курсов по ним. Люди бы на них ходили. А так — я лет 13-14 назад был одним из немногих кто на нашем курсе МФТИ пошёл на курс по ним. Все остальные выбрали другие варианты. И это при том что половина нашей группы имела базу в МЦСТ
Сейчас в МФТИ 20 курсов машинного обучения, они забиты. На них сложно попасть к хорошим препам.
А ребята кто умел ПЛИСы прогать с нашего курса — почти все поменяли направление работы. И это не потому что там какой-то Rocket Science.
Ну вот с Nano сейчас у ребят возникло много проблем, когда они захотели что-то сделать с Ubunta критичное для их прода. И оказалось что никак даже кусочно её перебилдить просто нельзя…
Про TX1|TX2 я согласен что там достаточно пристойно. Особенно в сравнении с всеми другими упомянутыми платформами. Но что «просто» я бы не сказал. Artec почти год разрабатывал свой сканер. Но они самыми первыми в России кто стартанул на них разработку. Возможно с тех пор стало проще.
Как вы могли заметить — в статье трактовка embedded идёт от другого класса устройств. Для него кто-то использует ещё слово Edge. Но в русском все поголовно эмбеддед говорят про них.
Если разбираться глубже, то даже поликлиника/больница — это бизнес единица. Сейчас многие на самоокупаемости. Деньги они получают за страховки/за платные услуги. Главврачи определяют бюджет/зарплаты. Они конкурируют за врачей. Если им выгодно поставить какой-то алгоритм — они ставят.
В Москве есть сейчас ДИТ. От него идут какие-то инновации. Но, конечно, это не самый правильный путь.
Это не совсем так. И автоматический анализ ЭКГ уже давно внедрён. И куча анализов уже давно внедрены.
Да и сами врачи в первых рядах голосуют за введение систем автоматизации документаоборота.
Просто внедрять надо аккуратно.
Пробовали внедрять и так и так. Общался с большим числом компаний, которые пробовали внедрять. Врачи говорят «да, прикольно», пока ты им прототип показываешь. Заставляешь пользоваться — отключают/не интересно/зачем мне это.
Такая штука не автоматизирует/ не помогает в работе/не несёт особого смысла.
Я понимаю почему оно может быть внедрено на уровне аппаратуры. Но это скорее инвестиция в будущее. Сегодняшние врачи будут пользоваться только тем что будет экономить их время/заполнять за них документы.
1) Человек не может принять правильного решения на основании описания флюорограммы/мамограммы и.т.д. Ровно для этого нужны врачи. В качестве примера можно привести ту же Европу — там даже какие-то примитивные лекарства вам без рецепта не продадут. Это всё делается так как люди, когда дело доходит до их здоровья — предвзяты и некомпетентны.
2) Видел уже пару таких сервисов. Люди предпочитают людей однозначно. Их пугает любая автоматизация. Каждый в больнице считает что он уникален.
То что я рассказываю и предлагаю — успешно работает. Посмотрите примеры снизу — там уже врачи вписаны в систему. Эффективность повышена в десятки раз, качество услуги — тоже. Однообразность не мешает. При большом объёме работы, без бумажной волокиты — врачу спокойнее работать, его качество работы растёт.
Но в целом, если примеры перешли на налоговую, то разговор надо сворачивать:)
1) Ситуаций «И так всё ясно» — не будет. А если будут, то и врачи там нормально распознают и без нейронных сетей. А в ситуациях «треш и угар» — нейронные сети будут даже хуже врачей.
2) Никто не будет внедрять сети пока не будет решён вопрос ответственности за ошибки. В том числе за очевидные ошибки. Какие-бы у вас не были пожелания — никто не будет брать на себя ответственность и сертифицировать. И никакие «нейросети должны» тут не помогут. Я так же могу сказать что вы должны:)
Обучать врачей всё равно придётся. И ваш аргумент «не вариант» — очень уныл. Просто этот процесс надо стандартизировать. До той же степени до которой стандартизировано распознавание пистолетов в аэропортах. Проводить проверку врача в том числе на рабочем месте, добавляя фейковые картинки. Чтобы каждый день врач работал с большим объёмом данных и учился на своих ошибках.
Это возможно, примеров работы таких система достаточно много.
Но надо разгружать врачей от ненужной писанины, нужно давать врачам удобные рабочие места и инструменты просмотра.
Почему-то в большинстве европейских стран сумели к этому придти. И нам надо лечить изначальные проблемы, а не затыкать их нейроночками. Если другие смогли — и в этой стране всё получиться:)
Мне не кажется что это «монополия». Встречал подобные выкрутасы и у фирм мельче.
4) Там есть какой-то FPU (VFP), если я правильно понимаю. И максимальную производительность вроде как вытаскивают с него. Я просто не очень глубоко копал, но заметил что некоторые фреймворки основной процессор почти не грузуили. Читал описание что они вычисления на математическом сопроцессоре гоняют.
2) OpenVINO ещё оптимизирует свёртки и их последовательность для оптимального использования памяти. Так что интересно именно сравнение производительности.
3) Чем больше форматов, тем больше сеть теряет при перегонке. Например: чтобы выгрузить PyTorch -> TensorRT надо сделать 2 конвертации. Чтобы выгрузить TensorFlow в Google TPU там где-то 3 нужно было. И каждая конвертация режет список возможных слоёв/соединений, и.т.д.
Чем ближе вы к графу исходной сети — тем лучше. Чем дальше вы — тем сложнее вас использовать. Использование ONNX даёт вам всего один хоп до исходной сети. При этом ONNX очень много что поддерживает.
4) Мне кажется что там сопроцессор. Вы поддерживаете именно его? Или разбиваете на процессор + сопроцессор? Просто, например, Caffe2 считал только на сопроцессоре в RPi 3 (была нулевая загрузка проца, по времени получалось раза в полтора быстрее чем ту же сетку инферить на проце простой версией Caffe с его 100% загрузкой). OpenCV, если я правильно помню, инферит на обоих устройствах. Но я не понимаю как они задачи согласуют/раскладывают.
1) А почему только с OpenVINO сравнение. а с OpenCV нет? Он то как раз умеет на армах инферить. Хотя не помню что там с поддержкой именно на мобильниках.
2) На i7 i9 вы сравнивали производительность с OpenVINO? Мне кажется у вас достаточно медленно.
3) Почему не поддерживаете какой-нибудь ONNX который сейчас по сути стандарт для передачи моделей между разными фреймворками?
4) Я правильно понимаю, что у вас только поддержка базовой архитуктуры? Для того же RPi NEON-совместимое ядро не будет поддерживаться? Так же как GPU-на чипе для Intel?
Но я бы посоветовал ещё раз всё проделать с нуля чтобы убедиться что всё ок и все файлы затёрлись везде.
У вас в примере неправильный ответ. С вероятностью 99%. Где вы получили — я не знаю. Но десять лет работы в computer vision как бы кричат об этом. Мне лень выкачивать ваш пример/искать в нём ошибки и тратить на это больше того полу часа который я потратил чтобы найти вашу первую ошибку.
Могу лишь предположить что это где-то:
1) В непонятном использовании деления train и val, которое в вашем случае использовать не надо
2) В том что вы обучаете на val который может совпадать с train
3) В не потёртых где-то сохранённых файлах, из-за которых вы грузите что-то не то для обучения вместо ImageNet весов
4) В ошибках вашего fast.ai который где-то что-то засвопил не то.
И прочее и прочее.
Смотрите. 95% работы нормального DS'а — это сбор данных и проверка корректности всего что он делает. Обучить модель — вечер. Почему ваше решение не корректно?
1) Если вы откроете конкурсы на kaggle, то сможете убедиться что точность ResNet от техники обучения может изменяться максимум на проценты (если не делать явных косяков).
2) Точность людей в определении паталогий по рентгенограммам ~85-95%. Это справедливо и для флюрограмм и для мамограмм. В целом, есть неплохое мета-исследование которое оценивает эти точности — www.sciencedirect.com/science/article/pii/S2589750019301232
К чему это я. К тому что в вашем датасете по которому вы учитесь минимум ~3-4% — это ошибки и неоднозначные классификации. Соответственно вы не можете получить точность выше.
Ну и прочее и прочее…
Обучать надо на обучении а проверять на тесте. Никаких «При этом делить изображения на обучающую и валидационную выборки будем случайным образом 80/20».
У вас в трейне и в тесте много данных по одним и тем же людям. Люди из train и test — не пересекаются. Но как только хоть один человек попадает из test в train — у вас точность прыгает на порядок. Да, организаторы судя по всему не удосужились это написать. Но такие вещи всегда надо учитывать.
Если вдруг в каком-то исследовании получается точность на порядок выше, чем все другие подходы, при этом ничего реально нового не сделано (политика обучения влияет лишь на сходимость, замораживание/размораживание вообще глобально не влияет), то вариантов лишь два:
1) Все кто делал это исследование до вас некомпетентны
2) У вас где-то ошибка
Учитывая что вы обучаете самый простой ResNet, при этом всё обучение идёт достаточно классическим способом, то я бы ставил на то что ошибка у вас (обучалось/оттьюнилось на тесте/на валидации). И, кстати, соседнее ядро с вашим на Каггле грешит именно этим — www.kaggle.com/yasserlatreche/pneumonia-99-accuracy-using-densenet121
И точности там примерно как у вас.
А, нашёл. Вы даже сами про это говорите.
Дальше надо объяснять почему всё что вы сделали — чушь?
— P.S.
В целом это и есть проблема использования любого deep learning. Он должен использоваться в первую очередь исходя из здравого смысла. Это лишь инструмент. И любая странность и неоднозначность — это лишь повод сказать себе «кажется я где-то накосячил». И начать искать этот косяк.
Конечно, если вы на калькуляторе обрабатываете — то лучше всё самому написать. А если уже на RPi — то памяти вам хватит, а по процессору OpenCV — это весьма неплохой вариант. Сколько в нём ковырялся — ни разу не видел именно «убогих» реализаций, в отличие от тех же dlib | PIL | PCL | AForge, которые я тоже мало-мало ковырял.
Не надо в проде использовать PIL, matplotlib и прочий бажный набор библиотек. Давным давно есть OpenCV, с которым всё интегрировано и который решает 90% проблем. И EXIF, и стриминг видео, и сохранение, и поддержку десятков форматов, и.т.д., и.т.п.
По сути это стандарт последние 10 лет. В отличие от того же matplotlib он быстрый, стартанёт на любом устройстве и не тащит кучу зависимостей.
Кстати, по цене достаточно адекватен + вроде по начинке разумен. Единственное, хочется верить что Movidius там на пате, а не по USB воткнут. А то пока гуглил натыкался на похожий, где просто в корпусе была флешка.
Вы как-то очень странно и к интеграции OpenSource в продукт относитесь. Естественно, там свой форк делается, который тестами обкладывается. И естественно, нужна свои программисты которые эту ветку потом держат. 99% того что вы вокруг видите (включая кодеки на вашем компе/прошивку вашего телефона) — использует наработки OpenSource проектов… В тех же самолётах вся мультимедийная системы из открытых сборок линукса…
Основная причина того что ПЛИСы сейчас не работают в ML — в том что для ML задач сейчас парадигма разработки лежит в плоскости Software 2.0. Это динамическая, постоянно изменяющаяся структура постановки задачи и находимого решения. Вчера вы могли считать что ваш продукт — распознавание номеров. Завтра, что ваш продукт — распознавание номеров + контроль соблюдения логики ПДД, включая контроль пешеходов. Послезавтра — что ваш продукт это номера+пдд, но реально ваша цель — сбор информации о том какие марки авто в этом районе.
Эти задачи можно просто и быстро решать когда у вас быстрый продакшн. Например в CherryHome мы можем поменять курс развития или протестировать новые идеи за месяц.
Рынок систем распознавания номеров захватила система которая была сделана на Jetson. Именно из-за простоты и быстроты разворачивания. Её ребята продавали через 4 месяца после начала разработки (не скажу что оно у них хорошо работало, но что-то показывали).
Когда мы лицензировали нашу системы распознавания номеров, то оказалось что заказчику нужно распознавать британские номера. Мы переобучили всё за пару недель.
Я могу сказать десятки других случаев когда системы спасла именно возможность динамически перестроиться/изменить рабочий концепт.
И тратить год времени на то чтобы сделать прототип — это не вариант.
Конечно, я понимаю, что есть ситуации когда ПЛИСы могут иметь смысл. Ну, например, когда вы монополист захвативший рынок распознавания номеров — вы хотите более дешёвого и стабильного решения. Тогда можно существующую системы переписать на ПЛИСы.
Про ваш пример:
Я могу сказать лишь одно. OpenSource зачастую имеет выше качество чем продуктовый код. А для вашего условного самолёта нет разницы что за железо и что за софт вы используете. Единственная критичная точка — это как вы тестируете/как вы резервируете. Сделать это можно и в парадигме «делать логику на ПЛИСах» и в парадигме «воткнём 3 резервирующих Jetson'а».
Специалистов по ПЛИСам мало. Но их и не требует рынок. В отличие от того же ML. Если бы в ПЛИСах было много работы и денег — было бы куча курсов по ним. Люди бы на них ходили. А так — я лет 13-14 назад был одним из немногих кто на нашем курсе МФТИ пошёл на курс по ним. Все остальные выбрали другие варианты. И это при том что половина нашей группы имела базу в МЦСТ
Сейчас в МФТИ 20 курсов машинного обучения, они забиты. На них сложно попасть к хорошим препам.
А ребята кто умел ПЛИСы прогать с нашего курса — почти все поменяли направление работы. И это не потому что там какой-то Rocket Science.
Про TX1|TX2 я согласен что там достаточно пристойно. Особенно в сравнении с всеми другими упомянутыми платформами. Но что «просто» я бы не сказал. Artec почти год разрабатывал свой сканер. Но они самыми первыми в России кто стартанул на них разработку. Возможно с тех пор стало проще.