Русский
Русский
English
Статистика
Реклама

Movidius

RPi-няня

28.08.2020 10:04:17 | Автор: admin
Периодически меня подмывает сделать что-то странное. Очевидно бесполезную вещь, которая не оправдывает себя по объему вложенных средств, и через полгода после создания пылиться на полке. Но зато полностью оправдывает себя по количеству эмоций, полученному опыту и новым рассказам. На Хабре даже есть две моих статьи про такие эксперименты: Алкоорган и умная кормушка для птиц.
Что ж. Пришло время рассказать о новом эксперименте. Как собрал, что из этого вышло и как повторить.

К новому проекту меня подтолкнуло событие, в каком-то смысле, банальное родился сын. Я заранее устроил себе отпуск на месяц. Но ребёнок оказался тихим было свободное время. И спящий рядом деть.
Дома много разных embedded-железок для computer vision. В итоге решил сделать видео-няню. Но не такую унылую, которыми завалены все магазины. А что-то поумнее и поинтереснее.


Статья будет написана в повествовательном ключе, чтобы понять как шла разработка игрушки, куда она пришла и куда движется дальше.
У статьи есть несколько дополнений:
1) Видео где я показываю и рассказываю как всё работает.
2) Небольшая статья на VC где я рассказываю почему такие штуки скорее всего не придут в нормальный продакшн, и про ограничения ML систем такого плана.
3) Сорсы всего на гитхабе + готовый образ для RPi. В конце статьи описание как пользоваться.

Выбор идеи


Самый банальный функционал видеоняни посмотреть в любой момент что происходит с ребёнком. Но, к сожалению, это не всегда работает. Вы не будете смотреть трансляцию всё время, это не удобно. Младенца можно вообще положить спать рядом в коконе, зачем видео всё время? В итоге, для начала собралась следующая подборка:
  1. Система должна давать возможность посмотреть видео или фото в любой момент с телефона
  2. Система должна реагировать на просыпание ребёнка, и извещать об этом
  3. Система должна детектировать пропадание лица, для предотвращения СВДС


Выбор платформы


У меня была большая статья на Хабре про сравнение различных платформ. Глобально, для прототипа типа того что я делаю есть несколько вариантов:
  1. Jetson Nano. Есть на руках + я много с ним работал (не только с Nano), но меня немного смущает, что он более производственный. Из коробки запустятся только самые простые модели. Чтобы ускорить и оптимизировать память надо переносить на TensorRT. Это требует времени. Но все обученные сети надо искать, тестировать, не факт что запуститься их коробки, не факт что из коробки TensorRT пойдёт.
  2. VIM3. Никогда не использовал, попробовать было бы интересно. Но ради проекта для которого есть уже пять разных вариантов исполнения не хотелось тратить денег.
  3. Raspberry PI + Movidius. Есть большая пачка предобученных сетей. Производительности хватит, удобно работает, более менее стабилен.
    1. Абсолютно непроизводственное решение, но для игрушки сойдёт.
    2. Нереально переобучить выложенные сети. Не все сети обученные с нуля будут работать.
  4. Raspberry PI 4 при работе через OpenCV будет хорошо утилизировать открытые сети, чего должно хватить. Но, было подозрение, что не хватит производительности.
  5. Coral у меня он есть на руках, по производительности прошло бы, но в другой моей статье написано почему я его не люблю:)

Итого я выбрал Rpi+movidius. Есть на руках, умею работать с ним.

Железо


Вычислитель Raspberry Pi 3B, нейропроцессор Movidius Myriad X. С этим понятно.
Остальное поскрёб по сусекам, докупил.



Камера


Я проверил три разных, которые у меня были:
  • Камера от RaspberryPI. Шумная, неудобный кабель, нет удобного крепления. Забил.
  • Какая-то IP камера. Очень удобно потому что не надо включать в RPI. Камера разнесена с вычислителем. Моя камера имела даже два режима, дневной и ночной. Но та что была у меня не давала достаточного качества лица.
  • Веб камера от Genius. Я её использовал уже лет 5. Но что-то в последнее время стала работать нестабильно.А для RPI в самый раз. Более того, оказалось что её можно тривиально разобрать и достать оттуда IR фильтр. Плюс, как потом выяснилось, что это был единственный вариант с микрофоном.


А фильтр меняется вот так:



В целом, понятно, что это не продуктовое решение. Но работает.
Если что, то в коде увидите оставшиеся куски для перехода на другие два типа камер. Возможно даже что-то сходу заработает, если 1-2 параметра поменять.

Освещение


С одной из старых задачек у меня завалялся осветитель:
Подпаял к нему какой-то блок питания. Светит неплохо.

Направляю на потолок комната освещена.


Экран


Для некоторых режимов работы мне понадобился монитор. Остановился на таком. Хотя не уверен что это самое правильное решение. Может стоило взять полноформатный. Но про это позже.


Питание


Ребёнок спит в произвольных местах. Так что проще когда система питается от павербанка. Выбрал такой, просто потому что лежит дома для походов:


OpenVino


Пройдём немного по OpenVino. Как я сказал выше большим преимуществом OpenVino является большой объём предобученных сетей. Что нам может пригодиться:
Детекция лица. Таких сетей в OpenVino много:
  1. 1
  2. 2
  3. 3

Распознавание ключевых точек на лице. Это нужно нам чтобы запускать следующие сети
Распознавание ориентации лица. Активность ребёнка и куда смотрит.
Распознавание направление взгляда если пробовать взаимодействовать
Анализ глубины? Может быть получится
Анализ скелета
Ну и много других интересных
Основным минусом этих сетей будет их основное преимущество их предобученность
Это можно поправить, но сейчас мы делаем быстрый прототип, наша цель не работа в 100% случаев, а принципиальная работа которая будет приносить хоть какую-то пользу.

Поехали. Общая логика версии 1


Так как мы разрабатываем embedded устройство, то нам надо с ним как-то взаимодействовать. Получать фото/сигналы о тревоге. Так что решил сделать так же как когда делал кормушку, через телеграмм. Но довести до ума.
Для первой версии я решил:
  • Запустить на RPi обозначенные сети (хотелось бы сразу все, вдруг производительность позволит). Это позволит посмотреть больше вариантов решения задачи/вероятных путей развития
  • Написать общий шаблон программы.
  • Придумать алгоритм распознающий просыпание.
  • Сделать алгоритм присылающий уведомление при потере лица

Пошло всё более-менее неплохо, не считая кучи багов всего вокруг. Это свойственно для ComputerVision Я привык к этому:)
Вот краткая сводка того на что я натолкнулся:
  1. OpenVino под RPi не запускается в последней версии (на май 2020) из-за того что не срабатывает from openvino.inference_engine import IECore. Есть способы иначе использовать OpenVino (через OpenCV например), но там логика программы изменится, не хотелось.
  2. OpenVino старой версии не работает на новых сконверченных нейронных сетях, надо конвертить с -generate_deprecated_IR_V7 или брать старые
  3. OpenVino в последней версии (опять же, на май) с Movidius под виндой не может инферить сетки с int 8 из официального репозитория. В int32 может. Под RPi в int8 может. Ничего критичного, но сложнее дебажить.
  4. OpenVino не устанавливается под виндой в нестандартную папку. Точнее ставится, но все дальнейшие проблемы не решились и OpenVino не запустился. Про это много ругани, но судя по тому что у меня то же самое произошло так и не починили.
  5. OpenVino не работает на старых но мощных процах Intel (не везде дебажить удобно, но не критично).
  6. PyTorch в версии 1.5 не смог сконвертировать сети в onnx, пришлось конвертировать из 1.4


Но, тут как Уверен что если бы пошёл через TensorRT, то там бы проблем было как всегда больше.

Итак. Всё сбилжено, сети запущены, получаем что-то такое (запустив стек по голове, ориентации, ключевым точкам):

Видно, что лицо будет часто теряться когда ребёнок закрывает его руками/поворачивает голову. да и не все показатели стабильны.

Что дальше? Как анализировать засыпание?
Смотрю на те сетки что есть, и первое что приходит в голову распознавать эмоции. Когда ребёнок спит и тих на лице нейтральное выражение. Но не всё так просто. Вот тут темно-синий график это нейтральное выражение спящего ребёнка на протяжении часа:

Остальные графики грусть/злость/радость/удивление. Даже не особо суть того что где по цветам. К сожалению, данные сети нестабильны, что мы и видим. Нестабильность возникает когда:
  • Лишняя тень на лице (что ночью не редкость)
  • Лиц ребёнка не было в обучающей выборке OpenVino => произвольные переключения на другие эмоции
  • Ребёнок реально корчит рожи, в том числе во сне

В целом, я не удивился. С сетями распознающими эмоции я сталкивался и ранее, и они всегда нестабильны, в том числе из-за нестабильности перехода между эмоциями нет чёткой границы.

Ок, с помощью эмоций просыпание не распознать. Пока что мне не хотелось обучать что-то самому, так что решил попробовать на базе тех же сетей но с другой стороны. Одна из сетей дает угол поворота головы. Это уже лучше (суммарное отклонение от взгляда в камеру во времени в градусах). Последние 5-10 минут перед просыпанием:

Уже лучше. Но Сын может начать махать головой во сне. Или наоборот, если поставить большой порог проснуться и не махать головой после этого. Получать каждый раз уведомление Уныло:

(здесь где-то час времени сна)
Значит надо всё же делать нормальное распознавание

Возникшие проблемы версии 1


Просуммируем всё что мне не понравилось в первой версии.
  1. Автозапуск. Не удобно запускать эту игрушку каждый раз заново, подключаться по SSH, запускать скрипт наблюдения. При этом скрипт должен:
    • Проверять состояние камеры. Бывает что камера выключена/не воткнута. Система должна ждать пока пользователь включит камеру.
    • Проверка состояния ускорителя. То же самое что с камерой.
    • Проверка сети. Штуку я хочу использовать и дома и на даче. А может где-то ещё. И опять же, заходить по ssh не хочу => надо сделать алгоритм подключения к wiFi если инета нет.
  2. Просыпание, обучение сети. Простые подходы не зашли, значит надо обучать нейронку на распознавание открытых глаз.

Автозапуск


В целом, схема автозапуска получилась следующей:
  • Запускаю на старте программу свою. Как я это делаю написал отдельную статью, не сказать что это на RPi сделать тривиально. Если кратко:
    • Создаю сервис который инициализирует OpenVino окружение
    • Сервис на старте запускает сначала скрипт проверки окружения, а потом основной рабочий скрипт
  • Проверяю наличие камеры
  • Проверяю наличие Movidius-модуля
  • Проверяю наличие интернета
    • Если нет запускаю камеру и жду QR-кода локальной wifi сети
  • Проверяю наличие информации о канале telegram через который будет управление. Если нет жду QR-код с данными на управление


Обучение сети для распознавания глаз


В OpenVino нет готовой сети для распознавания глаз.
Хахаха. Сеть уже появилась. Но её запушили, как оказалось, только после того как я начал разрабатывать. А в релизе и документации она появилась уже когда я более-менее всё сделал. Сейчас писал статью и нашёл апдейт.
Но, переделывать не буду, так что пишу как делал.

Можно очень просто обучить такую сеть. Выше я уже говорил, что использовал выделение глаз по кадру. Осталось всего ничего: добавить сохранение все встреченных на кадре глаз. Получается такой датасет:

Остаётся его разметить и обучить. Более подробно процесс разметки я описал тут (и видео процесса на 10 минут тут). Для разметки использовалась Толока. На настройку задания ушло~2 часа, на разметку 5 минут + 300 рублей бюджета.
При обучении думать особо не хотелось, так что взял заведомо быструю сеть, которая имеет достаточное качество для разрешения задачи mobilenetv2. Весь код, включая загрузку датасета, инициализацию и сохранение занял меньше 100 строк (большей частью взятых из открытых источников, переписал пару десятков строк):
Скрытый текст
import numpy as npimport torchfrom torch import nnfrom torch import optimfrom torchvision import datasets, transforms, modelsdata_dir = 'F:/Senya/Dataset'def load_split_train_test(datadir, valid_size = .1):    train_transforms = transforms.Compose([transforms.Resize(64),                                           transforms.RandomHorizontalFlip(),                                           transforms.ToTensor(),                                       ])    test_transforms = transforms.Compose([transforms.Resize(64),                                      transforms.ToTensor(),                                      ])    train_data = datasets.ImageFolder(datadir,                    transform=train_transforms)    test_data = datasets.ImageFolder(datadir,                    transform=test_transforms)    num_train = len(train_data)    indices = list(range(num_train))    split = int(np.floor(valid_size * num_train))    np.random.shuffle(indices)    from torch.utils.data.sampler import SubsetRandomSampler    train_idx, test_idx = indices[split:], indices[:split]    train_sampler = SubsetRandomSampler(train_idx)    test_sampler = SubsetRandomSampler(test_idx)    trainloader = torch.utils.data.DataLoader(train_data,                   sampler=train_sampler, batch_size=64)    testloader = torch.utils.data.DataLoader(test_data,                   sampler=test_sampler, batch_size=64)    return trainloader, testloadertrainloader, testloader = load_split_train_test(data_dir, .1)print(trainloader.dataset.classes)device = torch.device("cuda" if torch.cuda.is_available()                                  else "cpu")model = models.mobilenet_v2(pretrained=True)model.classifier = nn.Sequential(nn.Linear(1280, 3),                                 nn.LogSoftmax(dim=1))print(model)criterion = nn.NLLLoss()optimizer = optim.Adam(model.parameters(), lr=0.003)model.to(device)epochs = 5steps = 0running_loss = 0print_every = 10train_losses, test_losses = [], []for epoch in range(epochs):    for inputs, labels in trainloader:        steps += 1        inputs, labels = inputs.to(device), labels.to(device)        optimizer.zero_grad()        logps = model.forward(inputs)        loss = criterion(logps, labels)        loss.backward()        optimizer.step()        running_loss += loss.item()        if steps % print_every == 0:            test_loss = 0            accuracy = 0            model.eval()            with torch.no_grad():                for inputs, labels in testloader:                    inputs, labels = inputs.to(device), labels.to(device)                    logps = model.forward(inputs)                    batch_loss = criterion(logps, labels)                    test_loss += batch_loss.item()                    ps = torch.exp(logps)                    top_p, top_class = ps.topk(1, dim=1)                    equals = top_class == labels.view(*top_class.shape)                    accuracy += torch.mean(equals.type(torch.FloatTensor)).item()            train_losses.append(running_loss / len(trainloader))            test_losses.append(test_loss / len(testloader))            print(f"Epoch {epoch + 1}/{epochs}.. "                  f"Train loss: {running_loss / print_every:.3f}.. "                  f"Test loss: {test_loss / len(testloader):.3f}.. "                  f"Test accuracy: {accuracy / len(testloader):.3f}")            running_loss = 0            model.train()torch.save(model, 'EyeDetector.pth')


И ещё пара строк на сохранение модели в ONNX:
Скрытый текст
from torchvision import transformsimport torchfrom PIL import Imageuse_cuda=1mobilenet = torch.load("EyeDetector.pth")mobilenet.classifier = mobilenet.classifier[:-1]mobilenet.cuda()img = Image.open('E:/OpenProject/OpenVinoTest/face_detect/EyeDataset/krnwapzu_left.jpg')mobilenet.eval()transform = transforms.Compose([transforms.Resize(64),                                      transforms.ToTensor(),                                      ])img = transform(img)img = torch.unsqueeze(img, 0)if use_cuda:    img = img.cuda()img = torch.autograd.Variable(img)list_features = mobilenet(img)ps = torch.exp(list_features.data.cpu())top_p, top_class = ps.topk(1, dim=1)list_features_numpy = []for feature in list_features:    list_features_numpy.append(feature.data.cpu().numpy())mobilenet.cpu()x = torch.randn(1, 3, 64, 64, requires_grad=True)torch_out = mobilenet(x)torch.onnx.export(mobilenet, x,"mobilnet.onnx", export_params=True, opset_version=10, do_constant_folding=True,input_names = ['input'],output_names = ['output'])print(list_features_numpy)


Сохранение модели в ONNX нужно для дальнейшего вызова модели в Open Vino. Я не запаривался с преобразованиев в int8, оставил модель как была в 32-битном формате.

Анализ точности, метрики качества?.. Зачем это в любительском проекте. Такие штуки оцениваются по-другому. Никакая метрика не скажет вам система работает. Работает система или нет вы поймёте только на практике. Даже 1% ошибок может сделать систему неприятной для использования. Я бывает обратное. Вроде ошибок 20%, но система сконфигурирована так, что они не видны.

Такие вещи проще смотреть на практике, будет работать или нет. И уже поняв критерий работы вводить метрики, если они будут нужны.

Проблемы версии 2


Текущая реализация качественно другая, но всё же она имеет ряд проблем:
  • Лицо детектируется не всегда. Это особенность вызвана тем, что сеть обучалась для других условий:
    • Целевым объектом сети были явно не младенцы
    • Сеть не обучалась в ИК
    • Сеть явно отдаёт преимущество вертикальным лицам
    • Сеть явно предпочитает лица размером где-то в кадра.

  • Иногда ребёнок может проснуться не открывая глаз. Скорее всего при этом он будет махать головой. Но, как мы показали выше, махание головой не есть однозначное просыпание. Так что хотелось бы детектировать звук, чтобы понять проснулся или нет.
  • Мы получили неплохую платформу детектирования просыпания. А что ещё можно сделать на её базе?


Переобучить детект лица?


Я не стал переобучать детект лица. В отличие от распознавания глаз тут сильно больше работы. И со сбором датасета, и с качественным обучением.
Конечно, можно заоверфититься на лицо сына, наверное даже чуть лучше работать будет чем текущая сеть. Но по остальным людям нет. И, возможно, по сыну через 2 месяца тоже нет.
Собирать нормальный датасет долго.

Звук


Можно было бы пойти по классическому пути распознавания звука, и обучить нейронку. В целом это было бы не очень долго, максимум в несколько раз дольше чем распознавание глаз. Но мне не хотелось возиться со сбором датасета, так что воспользовался более простым способом. Можно использовать готовые инструменты WebRTC. Получается всё элегантно и просто, в пару строк.
Минус, который я нашёл на разных микрофонах качество работы решения разные. Где-то тригериться со скрипа, а где то только с громкого крика.

Идём дальше, что ещё


В какой-то момент я провёл тест, запустив зацикленное 5-секундное видео себя с супругой:



Был видно, что сын залипает на лица людей в поле зрения (монитор подвесил его минут на 30). И родилась идея: сделать управление выражением лица. Это не просто статичное видео, но и вариант взаимодействия. Получилось как-то так (при смене эмоции сына происходит переключение видеоряда):

Папа, ты что, долбанулся?!

Наверное, надо попробовать с большим монитором. Но пока не соберусь.
Может надо подменить проигрываемое видео. Благо это просто видео проигрывается из отдельных картинок, где смена кадров подстраивается под FPS.
Может надо подождать (на текущем уровне ребёнок мог банально не понять связи своих эмоций и экрана)

А потом?


Одним и перспективных направлений, мне кажется, попробовать сделать управление какими-то физическими обектами/лампочками/моторчиками через направление взгляда/позу.
Но пока глубоко не продумывал этот вопрос. Скорее пока что буду тестировать управление эмоциями.

Как всё в итоге выглядит, описание, мысли


Как сейчас всё работает (в начале статьи есть более масштабное видео):
  • Всё управление идёт через Telegramm + через камеру.
  • Если не нужно управление видео эмоциями, то вся девайсина выглядит так:

  • Запускается включением питания на павербанке.
  • Если есть подключенная сеть то устройство уже готово к работе
  • Если нет сети то надо показать QR-код с сетью, система автоматически запуститься
  • Через Telegramm можно выбрать набор событий за которыми следить:

  • Каждый раз когда происходит событие которое интересно, присылается уведомление:

  • В любой момент можно запросить фотографию с устройства чтобы посмотреть что твориться


В целом отзывы от себя любимого:
  1. Детектор лица работает не очень. Это реально особенность любых детекторов нефайнтьюненых на детей. Обычно это не мешает детектировать просыпание (хоть парочка нормальных фото с открытыми глазами да придёт). Сейчас нет планов переобучать.
  2. Без экрана немного непрозрачный запуск (считался QR код или нет). А с экраном много проводов. Я думаю, самый правильный вариант будет посадить диодов на GPIO. И зажигать их в зависимости от статуса (есть коннект, не работает камера, не работает Movidius, нет коннекта к telegram'у, и.т.д.). Но пока не сделал
  3. Иногда сложно закрепить камеру. Так как у меня есть пара штативов как то справляюсь. А без них, пожалуй, ничего бы не заработало.
  4. Реально позволяет освободить сколько-то времени и дать свободы перемещения. Больше это чем у нормальной радионяни/видеоняни со стримингом? Не знаю. Может чуть-чуть проще.
  5. Прикольная штука для экспериментов.


Как запускать


Как я и говорил выше я попробовал выложить все исходники. Проект большой и разветвлённый, так что может что-то забыл или не дал подробных инструкий. Не стесняйтесь спрашивать и уточнять.
Есть несколько способов всё развернуть:
  1. Сорсы с гитхаба. Это более сложный способ, придётся долго настраивать RPi, может что-то забыл. Зато вы полностью держите процесс под контролем (включая настройки RPi).
  2. Использовать готовый образ. Тут можно сказать что безблагодатно и несекьюрно. Зато на порядок проще.


GitHub


Основной репозиторий расположен тут github.com/ZlodeiBaal/BabyFaceAnalizer
Он состоит из двух файлов которые надо запускать:
  1. Скрипт инициализации/проверки состсояния/настройки сети QRCode.py (для этого скрипта, напомню, есть более подробное описание). Он подключает WiFi и проверяет что имеется настройки для бота в Telegram.
  2. Основной рабочий скрипт face.py

Кроме того. в Git нет двух вещей:
  1. Файла с креденшоналами WiFi wpa_supplicant_auto.conf
  2. Файла с креденшоналами Telegram бота tg_creedential.txt

Можно позволить система создать их автоматически при следующем запуске. Можно использвать следующие, заполнив пустые поля:
tg_creedential.txt
token to access the HTTP API чтобы его получить, отправьте @BotFather в telegram команду "/newbot"
socks5:// по умолчанию не используется, но должна быть пустая строчка хотя бы
логин для socks5 по умолчанию не используется, но должна быть пустая строчка хотя бы
пароль для socks5 по умолчанию не используется, но должна быть пустая строчка хотя бы


wpa_supplicant_auto.conf
network={
ssid="******"
psk="*******"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
}


Свистелки и перделки по настраиванию RPi


К сожалению, просто положить и запустить скрипты на RPi не получиться. Вот что ещё надо для стабильной работы:
  1. Установить l_openvino_toolkit_runtime_raspbian_p_2020.1.023.tgz по инструкции docs.openvinotoolkit.org/latest/openvino_docs_install_guides_installing_openvino_raspbian.html
  2. Установить автозапуск
  3. Удалить мессадж о дефолтном пароле (может не надо, но мне мешало) sudo apt purge libpam-chksshpwd
  4. выключить скринсейвер www.raspberrypi.org/forums/viewtopic.php?t=260355
  5. Для детекции аудио:
    • pip3 install webrtcvad
    • sudo apt-get install python-dev
    • sudo apt-get install portaudio19-dev
    • sudo pip3 install pyaudio
  6. Скачать модели из репозитория OpenVino используя скрипт Get_models.py в папке Models


Образ


Образ выложен тут(5 гигов).
Пара моментов:
  1. Используется стандартный логин-пароль (pi, raspberry)
  2. Включен доступ по SSH
  3. По умолчанию не подключен WiFi и не настроен адрес бота в телеге которого система будет использовать для контроля.


Как настроить WiFi в образе


Первый вариант после запуска показать QR код с текстом:
WIFI:T:WPA;P:qwerty123456;S:TestNet;;

Где после P идёт пароль сети, после S индентификатор сети.
  1. Если у вас есть телефон с Android 10 то там такой QR код генерируется автоматически при нажатии поделиться сетью
  2. Если нет то можно сгенерировать на www.the-qrcode-generator.com


Второй вариант зайти по SSH на RPi (подключившись по проводу). Либо включить монитор и клавиатуру. И положить файл
wpa_supplicant_auto.conf
network={
ssid="*********"
psk="*******"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
}

c вашими настройками wi-fi в папку "/home/pi/face_detect".

Как настроить телеграм-бота в образе


Первый вариант после запуска показать QR код с текстом:
tg_creedential.txt
token to access the HTTP API чтобы его получить, отправьте @BotFather в telegram команду "/newbot"
socks5:// по умолчанию не используется, но должна быть пустая строчка хотя бы
логин для socks5 по умолчанию не используется, но должна быть пустая строчка хотя бы
пароль для socks5 по умолчанию не используется, но должна быть пустая строчка хотя бы

сгенерировав его через www.the-qrcode-generator.com
Второй вариант зайти по SSH на RPi (подключившись по проводу). Либо включить монитор и клавиатуру. И положить файл tg_creedential.txt описанный выше в папку "/home/pi/face_detect".

Ремарка про детство


Уже когда собрал первую версию и показывал её своей маме, то получил внезапный ответ:
-О, а мы в твоём детстве почти так же делали.
?!
Ну, коляску с тобой на балкон выставляли, через форточку туда выкидывали микрофон, который был включен в усилитель в квартире.

Вообщем внезапно оказалось что это наследственное.

Ремарка про супругу


А как супруга отнеслась?
А как она позволила тебе эксперименты над сыном ставить?!
Спрашивали не раз.
Но, я жену испортил хорошо. Вот, она даже на Хабре иногда статьи пишет.

P.S.1


Я не специалист по ИБ. Конечно, я попробовал сделать так, чтобы никаких паролей нигде не светилось, и.т.д., а каждый смог сконфигурировать под себя, указав всю секьюрную информацию после старта.
Но не исключаю что что-то где-то не досмотрел. Если увидите явные ошибки попробую исправить.

P.S.2


Скорее всего про апдейты по этому проекту буду рассказывать в своём телеграм-канале, либо в группе вконтакте. Если накопиться много интересного, то сделаю ещё одну публикацию тут.
Подробнее..

Edge платы для домашнего Computer Vision

13.04.2021 06:09:41 | Автор: admin

Я люблю делать всякие странные штуки с Computer Vision. Из того, что я выкладывал на Хабре - умная кормушку для птиц и камера для слежения за ребенком. По работе примерно тем же занимаюсь. Так что слежу за актуальным рынком embedded устройств для ComputerVision. Прошлый обзор я делал полтора года назад. Для Embedded это долго. В этом я сосредоточусь на устройствах которые вышли недавно + некоторый анализ что из этих устройств можно использовать дома/для хобби.

Рассказ будет построен следующим образом:

  • Продуктовые железки которые стали классикой продакшна / железки которые почти доросли до таких.Их можно взять и запустить из коробки. Большие OpenSource комьюнити/персональные фреймворки. Время развертывания обученной сети на такой железке в 1-2 дня.

  • Продуктовые железки которые почти стали классикой, но по которым слишком мало открытых проектов/документации/где часть проекта закрыта. В таких проектах сложно ожидать большой подставы, и скорее всего все будет более-менее будет работать. Но вот что нужно будет сделать для работы сети, и как её сконвертировать, как перенести - нельзя будет оценить заранее.

  • Железки которые выглядят интересно, но нет ни гайдов по ним, ни историй успехи, ни подробной документации.

  • Железка есть информации почти нет/нельзя получить без запросов. На рынке нет истории использования/успеха.

Сразу несколько дисклеймеров, чтобы не возвращаться к ним:

  • Далеко не все из перечисленного я лично использовал/тестировал

  • Далеко не все перечислено. Я уверен что забыл/не знаю многое. И очень надеюсь что в комментарии накидаете чего-нибудь интересного

  • Я фокусируюсь на устройствах где есть GPU/NPU или прочие ускорители инференса. Безусловно, есть всякие FPGA, и прочее, но я не считаю их применимыми для хоббийных проектов. (что такое NPU GPU TPU и другие аббревиатуры - можно прочитать в этой замечательной статье)

Часть 1. Ближе всего к продукту

С одной стороны, весь этот раздел можно было бы свести к простому перечислению:

  • Jetson

  • Intel

  • Coral

  • Android телефоны

  • Прочие Embedded, устройства с хорошим процессором, без NPU/GPU

И в этом списке за последние 2 года появился бы лишь Coral. Но, в реальности, все сильно интереснее. Появились не только и не столько новые архитектуры, как имплементации/доработки старых. О чем мы и поговорим.

В мире Jetsonов новинок нет. Сейчас в продаже:

  • jetson nano

  • jetson xavier nx

  • jetson agx

  • jetson tx2

12ого началась конференция GTC от NVIDIA, но ничего нового на ней не объявили, так что, скорее всего, на следующий год ничего нового не будет.

Встречаются имплементации Jetson'а, под другие экосистемы. Самое известное - AWS Panorama. Jetson находящийся внутри экосистемы Амазона.

PanoramaPanorama

Jetson, безусловно, одна из самых удобных плат для хобби. Есть разводка GPIO, много кода который работает из коробки. Нейронные сети можно никуда не конвертировать, используя в оригинальном фреймворке.
Cтоит понимать, что из всех четырех Jetson'ов для хобби лучше всего подходит Nano. Он стоит лишь 100$, что значительно меньше следующего в серии NX, стоящего 400$. В теории, TX2в середине, но его почти нет в продаже + менее удобная плата. Проектов на Jetson очень много. Например из того что было в медийном пространстве - 1, 2. Вот тут есть неплохая подборка.
Лично я участвовал где-то в 5-7 проектах где Jetson был основной платформой. 2-3 из них переросли в полноценные продукты. Но, вынужден сказать, что для хобби его не использовал ни разу. Почему? Какая-то совокупность факторов всегда. Nano у меня был первой серии, там были баги по питанию. Иногда была не нужна производительность дополнительная. Иногда хотелось опробовать чего-то нового.

В отличие от Jetson, на базе Movidius появляются интересные штуки. В первую очередь это M.2 и mPCIe карты. Какие-то даже уже были, когда я писал прошлый обзор: 1, 2, 3.
Сейчас их очень много от разных производителей.

Удобны ли ли они для каких-нибудь прототипов и хобийных проектов? Мне кажется, что ниша есть, но очень узкая:

  • Когда надо много производительности (есть сборки где есть несколько мовидиусов)

  • Когда USB соединение слишком нестабильно, но M.2/PCIe хватит (переносные устройства)

Во вторую очередь - это ряд устройств от luxonis. Они устраивали большую компанию на кикстартере про OAK и OAK-D. OAK это платы где movidius воткнут не на материнскую плату, а на плату с камерой. Кроме того, у них есть несколько устройств с movidius когда он стоит на плате 1, 2. Я не буду вдаваться подробнее тут, кому интересно - про них я делал более подробный обзор у себя в блоге/на Youtube:

Кому лень читать/смотреть - вот краткая выдержка:

  • + Минус одно USB соединение + к стабильности - для части проектов полезно

  • - От USB все равно не уйти - до прода скорее всего не дойдет

  • + Неплохой дизайн, неплохой корпус

  • - Заменили хороший OpenVino на какой-то мутный DepthAI

  • - Дорого. Дороже чем собрать такое с оригинальным Movidius'ом, дороже чем с Jetson Nano

  • - В камере хорошее разрешение, но провален куда более полезный функционал для машинного зрения (ИК диапазон, нормальное управление выдержкой/частотой, синхронизация с вспышкой, и.т.д.)

Мне куда больше понравились эти две платы 1, 2. Но тут сразу понятно, что на первой оочень слабый процессор, а вторая дорогая и там есть лишнее соединение.

Кроме luxonis до movidius'а в камере догадался FLIR, достаточно крупный производитель камер. Они выпустили FireFly DL, который явно на порядки более продуктовый чем OAK, а стоит только на 100$ дороже (+объектив).

Чтобы закончить с Movidius окончательно. По простоте использования/наличию документации/комментариям и поддержке - на мой взгляд Movidius - это один из самых разумных ускорителей для своих проектов на нейронных сетях. Его минус - сложный переход с продакшну, и необходимость конвертации сети. То что вышло за последние годы - расширяет возможности использования. Но все же мне не хватает плат сравнимых с RPi3 где мовидиус бы стоял напрямую на плате.

Google Coral. Вот тут много нового. В своем прошлом обзоре я был крайне недоволен им - очень ограниченные платы, очень бажные. Но прогресс. Баги пофикшены, выпущена новая линейка. Есть почти все то же самое что и в movidius, только напрямую от производителя - отдельные платы, стики, M.2, pci-e, чистые чипы, и.т.д..

В качестве основного фреймворка - специальный tflite, где уже сильно меньше потерь на конвертации. Но, как видно, слоев все равно сильно меньше чем в том же ONNX.
Из плюсов, про которые не сказал - на базе Coral уже сторонние производители создают свои решения. Например Asus. Из минусов - считанные разы слышал что его использовали в продакшене. И, обычно, для каких-то простых задач.
Для себя я понимаю почему я избегаю Coral - при прочих равных не хочу трогать TensorFlow. А по текущим характеристикам он нигде не превосходит вариантов выше.

Телефоны. Так же, стоит отметить, многие телефоны получили поддержку из плат сопроцессоров для нейронных сетей. Есть несколько фреймфорков для инференса моделей на них. Например тут и тут описывал. Зачастую телефон стал удобнее чем embedded для пилота и хобби. Основной минус - отсутствие периферии. Второй серьезный минус для меня - внутренняя инфраструктура приложений. Конечно, Unity и Flutter упрощают логику использования. Но все же, лично для меня, телефоны сильно сложнее чем Linux-системы.
С другой стороны, в телефоне уже есть и камера и акселерометр, и интернет.

Прочее. Под "прочим" я в первую очередь подразумеваю системы где заход в нейронные сети идет со стороны процессора. Например в процессорах Intel за счет OpenVino можно сильно оптимизировать сети. На некоторых процессорах, например на RaspberryPI есть оптимизация под инструкции Neon. RPi4 вполне может справляться с какими-то задачами детекции и трекинга в реальном времени. Так что если вам нужно с помощью машинного зрения раз в день проверять рассаду - думаю подойдет.

Часть 2. Работает, но мало информации

Есть такая забавная штука. В ML сейчас 90% знаний открыто. Есть статьи, большая часть публикаций с OpenSource. Подробнейшие фреймворки на Nvidia и Intel. Но рынок аппаратных платформ был исторически не такой. Хотите подключить камеру по csi-mpi к своей платформе? Будьте добры купите дорогущий мануал по протоколу. Хотите разрабатывать на нашей платформе? Для этого вам нужно специальное программное обеспечение которое просто так вы не скачаете. И много фирм по производству железа по-другому и не мыслят. Как результат мы имеем полтора гайда на платформу до её покупки. Невозможность протестировать до покупки. Отсутствие форумов по теме. И проблему с каждой функцией где что-то пошло не так.

При этом платформы становятся популярнее и популярнее, реализовать можно все больше и больше. К таким платформам я в первую очередь отношу:

  • RockChip

  • Gyrfalcon

Обе платформы я видел в проде. Даже немного экспериментировал. Но у обоих платформ крайне неудобный фреймворк переноса сетей/использования.

RochChip. Основная платформа на которой все делается - Rockchip 3399Pro. Самая популярная реализация, наверное - Firefly, RockPiN10 или Toybrick.

Что забавно, у того же ASUS есть версия не только на базе Google Coral, но и на базе RockChip.
Сейчас разрабатывается новая версия - 1, 2.
В целом, плюс RockChip'а - это плата которую любят все разработчики железа. Есть референсный дизайн, комплектующие, и.т.д. Собрать продукт проще и быстрее чем на Jetson.
Но перенос сети весьма непредсказуем. Документация куцая и полукитайская. Как поддерживается - не понятно. Я видел несколько проектов где сети все же перенесли. Но, гарантировать что это всегда можно, нельзя.

Gyrfalcon. Вторым примером закрытой архитектуры, но на базе которой я видел проекты - является Gyrfalcon

Забавно, что платы на его базе в продаже почти отсутствуют. Что-то из того что есть: 1, 2, 3 .

Если я правильно понимаю, Gyrfalcon ориентирован на корпоративный рынок. Отсюда и закрытость инфраструктуры и мало число девайсов в продаже. Глобально, с прошлой моей статьи ничего особо не поменялось.

Делать ли свои проекты на базе этих платформ? Подходят ли они для хобби? В целом, такое мне кажется возможным. Главное чтобы были простые сетки. Классификация/базовая детекция, и.т.д.
По цене такие платформы достаточно дешевы и сравнимы с OpenVino|Jetson вариантами.
Но надо серьезно понимать зачем так делать. Это может быть:

  • желание сделать продукт из своей разработки

  • желание распаять свою систему

  • нехватка в Jetson|RPi каких-то возможностей

Я ни разу не испытывал такой необходимости. Но это может быть логичным для кого-то.

Часть 3. Внешне все выглядит неплохо, есть какая-то документация, но примеров нет

Пожалуй, сюда я отнесу только одну плату Khadas VIM3 . Много кто о ней знает, но не видел ни одного человека который бы что-то на ней сделал. Есть в открытой продаже, просто купить. Заявлены неплохие параметры по скорости.

Судя по документации перенос моделей достаточно простой. Но, так как никто не пробовал/не тестировал, - не понятны ограничения. Сама плата собрана на базе процессора Amlogic A311D, который содержит NPU модуль. Amlogic многие позиционируют как конкурент RockChip, сравнивая их. Но сравнений именно NPU модулей - нет.

Все что я говорил в прошлом раздели про проекты - глобально справедливо и тут. Единственное, внешне мне приятнее подход Khadas - документация открыта, поддерживаемые гиты, вроде все на русском английском. Возможно как-нибудь возьму попробовать, но пока лень. По цене выглядит неплохо, на уровне Jetson.

Часть 4. Железки есть, информации нет

Большая часть плат тут имеет очень слабую документацию. Часть плат - это отладочные платы для мобильных платформ. Другая часть - платы специально под ML, но по которым очень мало информации и данных в интернете.

BeagleV. Плата которая пока не вышла, но выглядит неплохо. Разработана на базе процессора U74 от SiFive. Используется RISC-V архитектура.

BeagleBoard - странная плата с комьюнити вокруг. Именно вокруг этого комьюнити частично построена плата BeagleV. Плата сделана на базе NPU модуля от Texas Instruments. Вроде даже какие-то репозитории есть:

  1. Фреймворк от TI для обучения нейронных сетей. Аж 55 звезд на гитхабе.

  2. Репозиторий платы. Аж 88 звезд.

Считать ли это "популярным" решением - не уверен. Но, возможно, какие-то базовые сети запустить будет можно.

Пример настоящего Edge (минимальное использование ЦПУ и энергоэффективности) это - Sipeed Maixduino и Grove AI Hat. Но, разработка на них, судя по отзывам, которые я слышал, ужасна. Сети плохо поддерживаются, мало производительности. Вот тут пример использования. Ну, по сути все проблемы обычного Arduino.
Я видел людей которые делали и адекватные проекты на их базе, и хоббийные. Но я не готов:)

Глобально, Qualcomm - это, конечно, производитель процессоров для мобильных. Но, на их же базе, есть какое-то количество именно embedded платформ. При этом, Qualcomm - имеет свой SDK, и свою платформу для исполнения нейронных сетей. Года 2.5 назад я сталкивался с ней. И тогда там была жесть. Простейший слой сложения не поддерживался. Что там говорить про сплиты или объединения. По сути работал лишь VGG на трехканальный вход.
Сейчас, судя по слухам все лучше. К тому же, должен нормально работать Tensorflow lite.
Но вот с платами под эмбеддед у Qualcomm плохо. Есть вот такое (но стоит почти 500 баксов). Или вот такое (мало информации, но выглядит прикольно, за 300 баксов камера + корпус + ускоритель = неплохо).

Примерно так же себя ведет Huawei. Есть фреймворк. Не пользовался, и не знаю. Есть какое-то количество плат. Должен работать Tensorflow lite.
Но, мне сложно придумать где такая плата будет иметь смысл на использование.

Наверное, стоит добавить и Модуль. Как никак отечественные производители. Но, понятно, вся документация открыто не выложена, не слышал про успешное применение, и.т.д.
Но, наверное, для госсектора кто-то применять может.

В целом, вся группа последних девайсов, очень на любителя. Иногда они могут иметь смысл для прода. Иногда, для получения новых навыков. В любом случае, чем больше платформ и вариантов развития - тем интереснее и больше выбор.

P.S.

Про девайсы которые попадают мне в руки/про которые я читаю - иногда пишу у себя в блоге (telegramm, vk). Наверное, через год-два проапдейчу тут что накопится.
Прошлый апдейт делал на ютубе.

Подробнее..

Как мы сделали акселератор инференса нейронных сетей для ЦОД с 64 чипами Intel Movidius

11.05.2021 10:09:42 | Автор: admin

Некоторое время назад мы искали оптимальное аппаратное и программное обеспечение для исполнения нейронных сетей в ЦОД и "на краю" (edge computing). В рамках нашего исследования мы протестировали множество устройств, от процессоров до встроенной графики iGPU и GPGPU различных производителей. С результатами исследования можно ознакомиться по ссылке.

В рамках этого исследования нас заинтересовал VPU Intel Movidius (MyriadX). При вычислениях "на краю" и использовании фреймворка Intel OpenVINO он позволял нам увеличивать число потоков или каналов путем дооснащения существующих устройств без какой-либо модификации аппаратной и программной базы. По умолчанию мы использовали встроенную графику, например, Intel HD или Iris Plus 655, но если FPS и число потоков необходимо было увеличивать, то промышленные ПК можно было дооснастить VPU. Это давало возможность сохранить единообразие множества устройств при изменяемом числе потоков. В качестве примера можно привести транспортную отрасль и подсчет пассажиров на борту автобусов. Автобусы бывают с 2, 3 и 4 дверьми. И если для двух дверей достаточно встроенной графики, то для четырех необходимо увеличение FPS, что достигалось расширением готового решения при помощи VPU формата M.2.

Вот так выглядело наше устройство для исполнения нейронных сетей "на краю" с Intel Movidius:

ComBox Outdoor Box SquaredComBox Outdoor Box Squared

Сегодня для инференса "на краю" интерес представляют решения от компании AAEON, в частности VPC-3350S, VPC-3350AI:

AAEON VPC-3350SAAEON VPC-3350S

Они отличаются расширенным температурным диапазоном эксплуатации -20+70 градусов, наличием возможности расширения двумя VPU Movidius, широкой линейкой поддерживаемых процессоров от Intel Atom x5 E3940 до Pentium N4200 или Atom x7 E3950, а также наличием 4 PoE Ethernet портов для подключения камер или иного оборудования.

С использованием Movidius в IoT все было более или менее понятно, но нас заинтересовала хотя бы теоретическая возможность масштабирования и применения этих компактных энергоэффективных чипов в ЦОД в виде ускорителей инференса PCIe формата.

Суммарный объем рынка публичных и частных облаков в России по данным IDC с 2019 года растет минимум на 25% в год, что на 2019 год составляло $1,72 млрд., а на 2020 год увеличилось до $2,2 млрд. Доля публичных облаков в общем объеме рынка в 2019 году 84,6%. Несмотря на то, что облачный рынок претерпел ряд структурных изменений в 2020 году, рост продолжается с частичным, но постоянным увеличением объемов облачных вычислений в системах искусственного интеллекта прикладного уровня, например, видеоаналитике для обработки ранее сформированных видеоархивов.

После предварительной оценки рынка мы провели поиск имеющихся решений в формате PCIe. Все найденные на тот момент устройства содержали 4 или 8 Movidius на одну плату. Например, решения от AAEON:

AAEON AI CORE XP4/ XP8AAEON AI CORE XP4/ XP8

Общее назначение имеющихся устройств - инференса "на краю". И вот здесь родилась идея реализации собственного ускорителя инференса нейронных сетей для ЦОД с чипами Movidius высокой плотности.

Сейчас в этой сфере используются два основных устройства: GPGPU nVidia Tesla T4 и ускорители инференса Huawei Atlas 300. Альтернатив по производительности от компании Intel для дооснащения существующих систем или внедрения новых серверных решений нет. Возможное решение, сопоставимое по производительности и стоимости - это ускоритель на основе VPU Movidius (MyriadX) высокой плотности в форм-факторе PCIe с плотностью не менее 64 Movidius на каждой несущей плате.

Требования:

  • плотность чипов Movidius не менее 64 штук на каждую плату

  • наличие возможности изменения числа VPU на плате

  • минимально возможное энергопотребление

  • форм-фактор PCIe x4/x8

  • работа конечного устройства под управлением фреймворка Intel OpenVINO без каких-либо значимых доработок

  • исполнение под использование в серверных платформах

Концепт не заставил себя долго ждать:

ComBox x64 Movidius Blade BoardComBox x64 Movidius Blade BoardComBox x64 Movidius Blade BoardComBox x64 Movidius Blade Board

Результатом проектирования платы получилось устройство PCIe с размещенными на несущей плате кастомными разъемами для подключения дочерних плат с нанесенными на них VPU. Таким образом конечную плату можно использовать с числом VPU до 64 штук, кратно 8. На каждый разъем отведена 1 линия PCIe, а в рамках каждой дочерней платы устройства подключены через USB хаб.

Охлаждение - пассивные радиаторы вдоль каждой дочерней платы, которые продуваются мощными вентиляторами серверных платформ.

Первые образцы прототипа:

ComBox x64 Movidius Blade BoardComBox x64 Movidius Blade Board

Дочерние платы (по 8 Movidius на каждой):

x8 Movidius blades for ComBox x64 Movidius boardx8 Movidius blades for ComBox x64 Movidius board

Для тестирования и отладки мы использовали платформу Supermicro SYS-1029TRT и рекомендуем ее по следующим причинам:

  • хорошее соотношения цена/качество

  • форм-фактора 1U (занимает 1 место в стойке)

  • наличие 4 портов PCIe x8/x16

Про 1U отдельно отмечу, что при высоком энергопотреблении платформы и установленных ускорителей это не важно из-за наличия лимитов энергопотребления на шкаф, в целом. Но так как мы говорим о чипах, изначально предназначенных для использования в IoT, вся плата отличается низким энергопотреблением, что позволяет повышать плотность количества серверов в стойках.

Supermicro SYS-1029TRT с установленной платой ComBox x64 Movidius Blade BoardSupermicro SYS-1029TRT с установленной платой ComBox x64 Movidius Blade Board

На картинке выше у нас установлено 4 дочерних платы с 32 Movidius, что отображается на обратной стороне ускорителя 4 зелеными диодами.

Вид готового изделия:

ComBox x64 Movidius Blade BoardComBox x64 Movidius Blade Board

И первые первые промышленные образцы платы:

Каких итогов мы добились:

  1. Максимальная плотность VPU Movidius на одной плате в мире.

  2. Показатель в инференсе сверточных нейронных сетей (на примере Mobilenet v.2 SSD) - 2800 FPS.

  3. Энергопотребление платы не более 120 Вт при полной загрузке.

  4. Возможность использовать произвольное число дочерних плат и устанавливать по 8, 16, 24 и т.д. VPU в рамках одной несущей платы.

  5. Возможность запуска инференса под управлением фреймворка Intel OpenVINO с использованием MDL и HDDL плагинов.

Следующие планируемые шаги:

  1. Выпуск несущих плат с интегрируемым аппаратным ключом Senselock для защиты моделей нейронных сетей в процессе их исполнения.

  2. Предоставление облачных мощностей для инференса в аренду на базе ComBox x64 Movidius Blade board.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru