Ну одноплатных ПК много и ASUS мы тоже пробовали.
Главный недостаток Raspberry — отсутствие нормального накопителя для системы, всё остальное как-то решается (кроме минусовых температур). Да, 3 модель греется не так сильно, как 4-я, но и производительность там весьма средняя.
Всё, что мы использовали от FriendlyARM вполне открытое, понятное и есть все исходники, поэтому мне не вполне понятно, что именно там не очень открытое.
Я про то, что когда понадобится переходить на узкоспециализированное железо, где уже не будет нормального линукса или будет, но очень древний, вариантов найти нормальный тулчейн и компилятор может не быть.
Если совсем упростить, то С работает примерно везде, если есть компилятор, ваш код скорее всего заработает.
Если писать на С++, есть очень высокая вероятность, что на какой-то конкретной железке компилятор и тулчейн устарели, не обновляются, а вы уже написали код с использованием каких-то модных вещей.
Можно ли этого избежать? Да, но проще писать на С :)
И да, мы смотрели на то, что делал Адриан
это забавно с точки зрения «смотрите, как я умею», но совершенно не применимо в реальном мире:
1. Добиться F-меры хотя бы 0.6 при детекции моргания/закрытия глаз его способом вообще невозможно. Там выходит в реальных условиях 0.3 — 0.4, а это детский сад. Мы сейчас используем метод обнаружения закрытия глаз от VisionLabs c нашей логикой поверх него, однако есть своя обученная модель с F-мерой 0.85. Если вы умеете делать это лучше, быстрее и точнее, приходите к нам работать!
2. У него не детектор усталости, а алгоритм из 5 строк, определяющий, что водитель уснул, потому, что глаза закрыты более Х секунд. Попробуйте запустить его код и просто прищуриться :)
3. Понятно, что эта статья хороший туториал для новичков, но захватывать кадры через OpenCV — наверно самая неудачная идея из всех самых неудачных идей, которые тут можно было применить.
Вы наверно перепутали NanoPi с каким-то другим устройством.
Там как раз никаких приключений нет, всё стабильно и производительно.
А вот stereopi как раз использует RaspberryPi, где производительности нам не хватает.
Возможно, новая версия (4) неплохая, но судя по десяткам ежедневных постов с самодельными кулерами и системами охлаждения, там всё не очень хорошо…
Я бы не хотел очень глубоко влезать в подробности того, что и как мы оцениваем, но в качестве примера приведу одну довольно хорошую метрику:
если система по набору признаков позволяет с хорошей точностью сказать, что водитель выглядит/ведёт себя примерно как другие водители, которые провели за рулём, например, 8-9 часов, то это уже само по себе позволяет сравнивать их между собой. Усталость — вещь очень субъективная, но так мы можем привести её к какому-то объективно измеряемому показателю.
Понятно, что если поставить рядом 2 людей, каждый из которых считает, что он очень устал, мы всё равно мы не можем сравнить их между собой и понять, чья усталость это 90%, а чья — 70%, например. Но это и не нужно. В отличие от всяких детекторов лжи по камере или диагностики по фотографии, тут мы опираемся на вполне конкретную классификацию: проявляются ли признаки, характерные для группы «усталые люди» или нет. Если к этому добавить частоту отвлечений и другие измеряемые факторы, всегда можно обучить модель, которая будет довольно точно давать оценку.
Именно для того, чтобы собрать как можно больше данных и научиться максимально точно анализировать эти признаки мы и проводим этот эксперимент. Запускать такую систему можно только тогда, когда мы будем абсолютно уверены, что она работает точно и правильно.
Мы не утверждаем, что моргания — единственный и достоверный критерий усталости.
Спит-не спит вообще считаются чисто статистически: за несколько секунд % закрытых глаз выше порога = тревога!
Однако, в течение дня и с ростом усталости характер и частота морганий меняются и есть много других факторов, связанных с подвижностью головы, переводом взгляда и т.п. Если совместить все эти наблюдаемые характеристики, выводы об усталости делать можно.
наша камера отлично видит через солнечные очки за счёт ик-подсветки
нет под рукой фото, но линзы очков выглядят как будто их нет или они очень прозрачные
Технологии должны помогать, а не создавать неудобства.
Мне сложно представить себя водителя, который добровольно обвешивает себя браслетами, кепками, датчиками и т.п.
Отвечу по пунктам:
1. Нам надо было 1.5-2 метра, чтобы спрятать компьютер в подрулевое пространство и там же запитать. Сама по себе штатная камера для RaspberryPI не очень хорошая, нам пришлось бы всё равно делать корпус, подсветку, придумывать какой-то хитрый кабель, который мы могли бы за обшивкой провести и т.п. Это было в разы сложнее, чем взять USB. Тем более, что у нас на камере есть аппаратное сжатие, подсветка прямо на плате и множество других плюсов.
2. Камера всё таки хорошая. Мы тестировали много вариантов. На нашей камере сенсор Sony IMX291. Можно было использовать IMX224, там пиксель больше, но и текущий вариант показал себя крайне хорошо. FPS при низком освещении не падает, сенсор хороший и достаточно чувствительный. На плате установлен чип sonix 292B с поддержкой аппаратного сжатия h264, что тоже нам подходит.
3. Когда мы начинали всё делать, iMX.8 ещё не было, а iMX.7 точно не потянул бы наши задачи по производительности. К тому же, на iMX.8 надо было бы проектировать плату и т.п. и мы бы получили первые работающие прототипы не через 2 месяца, а через 4-5, если не больше.
4. По поводу пропасти между прототипом и серьёзным решением — конечно мы это знаем и понимаем. Именно поэтому мы начали процесс проектирования компактного устройства на специализированном чипе одновременно с созданием прототипов. И эти прототипы нам очень помогают понять, что как должно работать, где размещаться, какая нам нужна производительность и многие другие технические моменты.
Разумеется мы об этом думаем:
камера, да ещё и с ИК-подсветкой, которая видит не статичную фотографию, а видеоряд точно может использоваться для идентификации водителя и сравнения лица с имеющимся в нашей базе
Публичный ключ пока больше не используется, но мы планируем его использовать для поддержки множественных ключей шифрования. Больше рассказать не могу, к сожалению.
Мы используем системный генератор случайных чисел, но мысль про подмешивание пользовательских данных мне понятна и нравится. Посмотрим, может быть добавим.
Что касается уверенности в ключе: если вы настроены серьёзно и переживаете за наши алгоритмы, можно открыть через SQLite базу Ya Login Data и
создать свои ключи руками
а) сгенерировать случайный 256 битный ключ
б) сгенерировать пару ключей RSA
в) посолить и похешировать желаемый мастер-пароль
г) поставить хеш в качестве passphrase на ключ
д) записать всё это в базу
Никакого обмана. Включите 2-факторную авторизацию и возможность сброса перестанет зависеть от пароля от Яндекса. А подобрать 256-битный пароль для запасного ключа ни у кого всё равно не получится.
Могу ошибаться, но есть такое мнение, что в случае, если внезапно придумают успешную атаку на AES-128, возможно, в 2 раза больший ключ будет чуть сложнее взломать, а может и нет, а вот более медленная расшифровка AES 256 нам скорее на руку, т.к. замедляет перебор, но не настолько, чтобы это было визуально заметно.
Ну, в общем, это скорее из области психологии: «256 бит больше 128, а значит надёжнее, пока обратное не доказано».
Про 2048 бит — да, это где-то 112 бит сложности, поэтому действительно ключ 128 бит по общей сложности подошёл бы лучше, да и не 2048, а 3072 правильнее было бы тогда. Кстати, при определённых обстоятельствах, атака на AES-256 как раз снижает стойкость именно до 112 бит, что отлично согласуется с текущей стойкостью 2048 RSA.
А вообще, мы заложили в архитектуру возможность почти безболезненно менять алгоритмы шифрования/хеширования, поэтому ни к чему не привязаны и планируем регулярно повышать сложность и применять более современные алгоритмы при необходимости.
Если уже быть совсем честным, то самое слабое звено в системе — мастер пароль. Если пользователь выбирает недостаточно сложный/длинный мастер-пароль, никакие алгоритмы и большие ключи не помогут.
Параноики не поверят нам даже при таком сценарии и будут пользоваться аппаратными хранилищами паролей, использовать пароли, которые они придумывают по известному одним им алгоритму в голове или собирать Keepass из исходников, проверяя, что там внутри :)
Мы используем RSA_OAEP_2048_SHA256
Генерируем и экспортируем ключи через стандартную библиотеку Chromium boringssl через класс RSAPrivateKey. В криптографии велосипеды изобретать плохо, правильно брать что-то стабильное и давно работающее, что мы и сделали.
Главный недостаток Raspberry — отсутствие нормального накопителя для системы, всё остальное как-то решается (кроме минусовых температур). Да, 3 модель греется не так сильно, как 4-я, но и производительность там весьма средняя.
Всё, что мы использовали от FriendlyARM вполне открытое, понятное и есть все исходники, поэтому мне не вполне понятно, что именно там не очень открытое.
Если писать на С++, есть очень высокая вероятность, что на какой-то конкретной железке компилятор и тулчейн устарели, не обновляются, а вы уже написали код с использованием каких-то модных вещей.
Можно ли этого избежать? Да, но проще писать на С :)
Подсветка у нас работает всегда, камера принудительно в B/W режиме, т.к. нам не нужна цветовая составляющая совершенно.
это забавно с точки зрения «смотрите, как я умею», но совершенно не применимо в реальном мире:
1. Добиться F-меры хотя бы 0.6 при детекции моргания/закрытия глаз его способом вообще невозможно. Там выходит в реальных условиях 0.3 — 0.4, а это детский сад. Мы сейчас используем метод обнаружения закрытия глаз от VisionLabs c нашей логикой поверх него, однако есть своя обученная модель с F-мерой 0.85. Если вы умеете делать это лучше, быстрее и точнее, приходите к нам работать!
2. У него не детектор усталости, а алгоритм из 5 строк, определяющий, что водитель уснул, потому, что глаза закрыты более Х секунд. Попробуйте запустить его код и просто прищуриться :)
3. Понятно, что эта статья хороший туториал для новичков, но захватывать кадры через OpenCV — наверно самая неудачная идея из всех самых неудачных идей, которые тут можно было применить.
Там как раз никаких приключений нет, всё стабильно и производительно.
А вот stereopi как раз использует RaspberryPi, где производительности нам не хватает.
Возможно, новая версия (4) неплохая, но судя по десяткам ежедневных постов с самодельными кулерами и системами охлаждения, там всё не очень хорошо…
если система по набору признаков позволяет с хорошей точностью сказать, что водитель выглядит/ведёт себя примерно как другие водители, которые провели за рулём, например, 8-9 часов, то это уже само по себе позволяет сравнивать их между собой. Усталость — вещь очень субъективная, но так мы можем привести её к какому-то объективно измеряемому показателю.
Понятно, что если поставить рядом 2 людей, каждый из которых считает, что он очень устал, мы всё равно мы не можем сравнить их между собой и понять, чья усталость это 90%, а чья — 70%, например. Но это и не нужно. В отличие от всяких детекторов лжи по камере или диагностики по фотографии, тут мы опираемся на вполне конкретную классификацию: проявляются ли признаки, характерные для группы «усталые люди» или нет. Если к этому добавить частоту отвлечений и другие измеряемые факторы, всегда можно обучить модель, которая будет довольно точно давать оценку.
Именно для того, чтобы собрать как можно больше данных и научиться максимально точно анализировать эти признаки мы и проводим этот эксперимент. Запускать такую систему можно только тогда, когда мы будем абсолютно уверены, что она работает точно и правильно.
Спит-не спит вообще считаются чисто статистически: за несколько секунд % закрытых глаз выше порога = тревога!
Однако, в течение дня и с ростом усталости характер и частота морганий меняются и есть много других факторов, связанных с подвижностью головы, переводом взгляда и т.п. Если совместить все эти наблюдаемые характеристики, выводы об усталости делать можно.
нет под рукой фото, но линзы очков выглядят как будто их нет или они очень прозрачные
Мне сложно представить себя водителя, который добровольно обвешивает себя браслетами, кепками, датчиками и т.п.
Отвечу по пунктам:
1. Нам надо было 1.5-2 метра, чтобы спрятать компьютер в подрулевое пространство и там же запитать. Сама по себе штатная камера для RaspberryPI не очень хорошая, нам пришлось бы всё равно делать корпус, подсветку, придумывать какой-то хитрый кабель, который мы могли бы за обшивкой провести и т.п. Это было в разы сложнее, чем взять USB. Тем более, что у нас на камере есть аппаратное сжатие, подсветка прямо на плате и множество других плюсов.
2. Камера всё таки хорошая. Мы тестировали много вариантов. На нашей камере сенсор Sony IMX291. Можно было использовать IMX224, там пиксель больше, но и текущий вариант показал себя крайне хорошо. FPS при низком освещении не падает, сенсор хороший и достаточно чувствительный. На плате установлен чип sonix 292B с поддержкой аппаратного сжатия h264, что тоже нам подходит.
3. Когда мы начинали всё делать, iMX.8 ещё не было, а iMX.7 точно не потянул бы наши задачи по производительности. К тому же, на iMX.8 надо было бы проектировать плату и т.п. и мы бы получили первые работающие прототипы не через 2 месяца, а через 4-5, если не больше.
4. По поводу пропасти между прототипом и серьёзным решением — конечно мы это знаем и понимаем. Именно поэтому мы начали процесс проектирования компактного устройства на специализированном чипе одновременно с созданием прототипов. И эти прототипы нам очень помогают понять, что как должно работать, где размещаться, какая нам нужна производительность и многие другие технические моменты.
камера, да ещё и с ИК-подсветкой, которая видит не статичную фотографию, а видеоряд точно может использоваться для идентификации водителя и сравнения лица с имеющимся в нашей базе
Исходники браузера мы не публикуем.
Что касается уверенности в ключе: если вы настроены серьёзно и переживаете за наши алгоритмы, можно открыть через SQLite базу Ya Login Data и
б) сгенерировать пару ключей RSA
в) посолить и похешировать желаемый мастер-пароль
г) поставить хеш в качестве passphrase на ключ
д) записать всё это в базу
Ну, в общем, это скорее из области психологии: «256 бит больше 128, а значит надёжнее, пока обратное не доказано».
Про 2048 бит — да, это где-то 112 бит сложности, поэтому действительно ключ 128 бит по общей сложности подошёл бы лучше, да и не 2048, а 3072 правильнее было бы тогда. Кстати, при определённых обстоятельствах, атака на AES-256 как раз снижает стойкость именно до 112 бит, что отлично согласуется с текущей стойкостью 2048 RSA.
А вообще, мы заложили в архитектуру возможность почти безболезненно менять алгоритмы шифрования/хеширования, поэтому ни к чему не привязаны и планируем регулярно повышать сложность и применять более современные алгоритмы при необходимости.
Если уже быть совсем честным, то самое слабое звено в системе — мастер пароль. Если пользователь выбирает недостаточно сложный/длинный мастер-пароль, никакие алгоритмы и большие ключи не помогут.
Генерируем и экспортируем ключи через стандартную библиотеку Chromium boringssl через класс RSAPrivateKey. В криптографии велосипеды изобретать плохо, правильно брать что-то стабильное и давно работающее, что мы и сделали.