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

Датчики

Как я делал систему оптического трекинга

20.01.2021 20:22:57 | Автор: admin

Дело было в далеком 2015 году. В продаже только появились очки виртуальной реальности Oculus DK2, рынок VR игр быстро набирал популярность.

Возможности игрока в таких играх были невелики. Отслеживалось всего 6 степеней свободы движений головы вращение (инерциалкой в очках) и перемещение в маленьком объеме в зоне видимости инфракрасной камеры, закрепленной на мониторе. Процесс игры представлял собой сидение на стуле с геймпадом в руках, вращение головой в разные стороны и борьбу с тошнотой.

Звучало не очень круто, но я увидел в этом возможность сделать что-то интересное, используя свой опыт в разработке электроники и жажду новых проектов. Как можно было эту систему улучшить?

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

Видел я это так:

  1. Берем несколько игроков, надеваем на них VR очки, ноутбук и датчики на руки, ноги и туловище.
  2. Берем помещение, состоящее из нескольких комнат, коридоров, дверей, оборудуем его системой трекинга, вешаем датчики и магнитные замки на двери, добавляем несколько интерактивных предметов и создаем игру, в которой геометрия виртуальной локации точно повторяет геометрию реального помещения.
  3. Создаем игру. Игра представляет собой многопользовательский квест, в котором несколько игроков надевают на себя оборудование и оказываются в виртуальном мире. В нем они видят себя, видят друг друга, могут ходить по локации, открывать двери и совместно решать игровые задачи.

Эту идею я рассказал своему товарищу, который неожиданно воспринял ее с большим энтузиазмом и предложил взять на себя организационные вопросы. Так мы решили мутить стартап.

Для реализации заявленного функционала, нужно было создать две основные технологии:

  1. костюм, состоящий из датчиков на руках, ногах и торсе, отслеживающий положения частей тела игрока
  2. система трекинга, отслеживающая игроков и интерактивные объекты в 3D пространстве.

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

Система трекинга.


Бюджета на все это, конечно, у нас не было, поэтому нужно было сделать все из подручных материалов. Для задачи отслеживания игроков в пространстве я решил использовать оптические камеры и светодиодные маркеры, закрепленные на VR очках. Опыта подобных разработок у меня не было, но я уже что-то слышал про OpenCV, Python, и подумал, что справлюсь.

По задумке, если система знает где расположена камера и как она ориентирована, то по положению изображения маркера на кадре можно определить прямую в 3D пространстве, на которой этот маркер находится. Пересечение двух таких прямых дает итоговое положение маркера.



Соответственно, камеры нужно было закрепить на потолке так, чтобы каждая точка пространства просматривалась минимум двумя камерами (лучше больше, чтобы избежать перекрытия обзора телами игроков). Для покрытия трекингом предполагаемого помещения площадью около 100 кв.м., требовалось около 60 камер. Я выбрал первые попавшиеся дешевые на тот момент usb вебки.



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

Архитектуру я придумал следующую:
На каждые очки вешается акриловый матовый шарик от гирлянды с вклеенным внутрь RGB светодиодом. Одновременно в игре предполагалось несколько игроков, так что для идентификации решил разделять их по цвету R, G, B, RG, RB, GB, RB. Вот так это выглядело:



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

Поиск шарика на кадре

Мне нужно было в каждом кадре, пришедшем с камеры, искать координаты центра шарика и его цвет для идентификации. Звучит несложно. Качаю OpenCV под Python, втыкаю камеру в usb, пишу скрипт. Для минимизации влияния лишних объектов на кадре, выставляю экспозицию и выдержку на камере в самый минимум, а яркость светодиода делаю высокой, чтобы получить яркие пятна на темном фоне. В первой версии алгоритм был следующий:

  1. Переводим изображение в градации серого
  2. Бинаризуем по порогу (если яркость пикселя больше порога, он становится белым, иначе черным). При этом размытое пятно от шарика превращается в кластер белых пикселей на черном фоне
  3. Находим контуры кластеров и их центры. Это и есть координаты шарика на кадре
  4. Определяем усредненный цвет пикселей кластера (на исходном цветном изображении) в окрестности его центра для идентификации




Вроде, работает, но есть нюансы.

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

Во-вторых, разрешение камеры всего лишь 640*480, поэтому на некотором расстоянии (не очень большом) шарик виден как пара пикселей на кадре и алгоритм поиска контуров перестает нормально работать.

Пришлось придумывать новый алгоритм. В голову пришла следующая идея:

  1. Переводим изображение в градации серого
  2. Размываем картинку мощным Gaussian blur ом так, чтобы изображения светодиодов превратились в размытые пятна с градиентом яркости от центра к периферии
  3. Находим самые яркие пиксели на изображении, они должны соответствовать центрам пятен
  4. Так же определяем средний цвет кластера в окрестности центра


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

Чтобы убедиться, что все это будет работать с 8-ю камерами на одном компе, нужно провести нагрузочный тест.

Нагрузочный тест

Подключаю 8 камер к своему десктопу, располагаю их так, чтобы каждая видела светящиеся точки и запускаю скрипт, где описанный алгоритм работает в 8-ми независимых процессах (спасибо питонской либе multiprocessing) и обрабатывает все потоки сразу.

И сразу натыкаюсь на фейл. Изображения с камер то появляются, то исчезают, framerate скачет от 0 до 100, кошмар. Расследование показало, что часть usb портов на моем компе подключены к одной шине через внутренний хаб, из-за чего скорость шины делится между несколькими портами и ее уже не хватает на битрейт камер. Втыкание камер в разные порты компа в разных комбинациях показало, что у меня всего 4 независимых usb шины. Пришлось найти материнку с 8-ю шинами, что было довольно непростым квестом.

Спойлер
Подошли материнки с чипсетом Intel B85, в них поддерживается аж 10 usb шин. Но для работы с 10-ю камерами, нужно перекомпилить OpenCV, т.к. в нем захардкожено ограничение на 8 источников видеосигнала (совпадение?)

Продолжаю нагрузочный тест. На этот раз все камеры подключились и выдают нормальные потоки, но сразу сталкиваюсь со следующей проблемой низкий fps. Процессор загружен на 100% и успевает обрабатывать лишь 8-10 кадров в секунду с каждой из восьми вебок.



Похоже, нужно оптимизировать код. Узким местом оказалось Гауссово размытие (оно и не удивительно, ведь нужно на каждый пиксель кадра производить свертку с матрицей 9*9). Уменьшение ядра не спасало ситуацию. Пришлось искать другой метод нахождения центров пятен на кадрах.

Решение удалось найти внезапно во встроенной в OpenCV функции SimpleBlobDetector. Она делает прямо то, что мне нужно и очень быстро. Преимущество достигается благодаря последовательной бинаризации изображения с разными порогами и поиску контуров. Результат максимальные 30 fps при загрузке процессора меньше 40%. Нагрузочный тест пройден!

Классификация по цвету

Следующая задача классификация маркера по его цвету. Усредненное значение цвета по пикселям пятна дает RGB компоненты, которые очень нестабильны и сильно меняются в зависимости от расстояния до камеры и яркости светодиода. Но есть отличное решение: перевод из RGB пространства с HSV (hue, saturation, value). В таком представлении пиксель вместо красный, синий, зеленый, раскладывается на компоненты тон, насыщенность, яркость. В этом случае насыщенность и яркость можно просто исключить и классифицировать только по тону.



Технические детали
Эксперимент показал, что компонента тон действительно довольно стабильна и слабо зависит от расположения маркера. Но все же начинаются проблемы, когда маркер достаточно далеко от камеры и превращается в несколько пикселей на кадре. В этом случае, цвета начинают сильно искажаться и неправильно классифицироваться. Для решения этой проблемы я написал программу для обучения системы классификации по цвету в разных условиях на основе линейной регрессии.

Алгоритм такой:
  1. Указываю цвет маркера (например, R красный) и запускаю режим накопления
  2. Беру в руку соответствующий маркер и хаотично вожу им перед камерой, приближаю, отдаляю и тд. Параллельно наблюдаю как на интерфейсе на двумерном графике hue saturation появляются точки
  3. Завершаю режим накопления. Указываю следующий цвет маркера, прохожу еще одно накопление и так далее для каждого цвета.
  4. Вижу, как разноцветные точки на графике разбиты по кластерам, но эти кластеры немного пересекаются. Расстраиваюсь. Запускаю линейную регрессию, в процессе которой программа рассчитывает уравнения прямых, разделяющих кластеры наилучшим образом. Но т.к. облака точек пересекаются, толку с этих уравнений было мало. Понял, что по-модному сделать не получится, поэтому просто вручную на глаз разделил пространство на части вертикальными линиями и в области пересечений сделал мертвые зоны, где неопределившиеся точки будут просто игнорироваться.




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

Трекинг


Я использовал pinhole модель камеры, в которой все лучи падают на матрицу через точку, находящуюся на фокусном расстоянии от матрицы.



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

Для отслеживания 3D координат маркера нужно получить минимум две скрещивающиеся прямые в пространстве от разных камер и найти точку их пересечения. Увидеть маркер двумя камерами не сложно, но для построения этих прямых нужно, чтобы система знала все о подключенных камерах: где они висят, под какими углами, фокусное расстояние каждого объектива. Проблема в том, что все это неизвестно. Для вычисления параметров требуется некая процедура калибровки.

Калибровка трекинга

В первом варианте решил сделать калибровку трекинга максимально примитивной.

  1. Вешаю первый блок из восьми камер на потолок, подключаю их к системнику, висящему там же, направляю камеры так, чтобы ими покрывался максимальный игровой объем.
  2. С помощью лазерного нивелира и дальномера измеряю XYZ координаты всех камер в единой системе координат
  3. Для вычисления ориентаций и фокусных расстояний камер, измеряю координаты специальных стикеров. Стикеры вешаю следующим образом:
    • В интерфейсе отображения картинки с камеры рисую две точки. Одну в центре кадра, другую в 200 пикселях справа от центра
    • Если смотреть на кадр, эти точки падают куда-то на стену, пол или любой другой объект внутри помещения. Вешаю в соответствующие места бумажные наклейки и рисую на них точки маркером
    • Измеряю XYZ координаты этих точек с помощью тех же нивелира и дальномера. Итого для блока из восьми камер нужно измерить координаты самих камер и еще по две точки на каждую. Т.е. 24 тройки координат. А таких блоков должно быть около десяти. Получается долгая муторная работа. Но ничего, позже сделаю калибровку автоматизированной.
    • Запускаю процесс расчета на основе измеренных данных


Есть две системы координат: одна глобальная, связанная с помещением, другая локальная для каждой камеры. В моем алгоритме результатом для каждой камеры должна получиться матрица 4*4, содержащая ее местоположение и ориентацию, позволяющая преобразовать координаты из локальной в глобальную систему.



Идея следующая:

  1. Берем исходную матрицу с нулевыми поворотами и смещением.
  2. Берем единичный вектор в локальной системе камеры, который смотрит из объектива вперед и преобразуем его в глобальные координаты по исходной матрице.
  3. Берем другой вектор в глобальной системе, который из камеры смотрит на центральную точку на стене.
  4. С помощью градиентного спуска поворачиваем исходную матрицу так, чтобы после преобразования эти векторы были сонаправлены. Таким образом, мы зафиксировали направление камеры. Осталось зафиксировать вращение вокруг этого направления. Для этого и измерялась вторая точка в 200 пикселях от центра кадра. Поворачиваем матрицу вокруг главной оси, пока два вектора не станут достаточно параллельны.
  5. По расстоянию между этими двумя точками вычисляю фокусное расстояния в пикселях (учитывая, что расстояние между проекциями этих точек на кадре составляет 200 пикселей).

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

Для визуализации результатов калибровки я сделал 2D интерфейс с картой, на которой скрипт рисует метки камер и направления, в которых они видят маркеры. Треугольником обозначаются ориентации камер и углы обзора.



Тестирование трекинга

Можно приступать к запуску визуализации, которая покажет правильно ли определились ориентации камер и правильно ли интерпретируются кадры. В идеале, линии, идущие из значков камер должны пересекаться в одной точке.

Вот что вышло:


Похоже на правду, но точность явно могла быть выше. Первая причина несовершенства, которая пришла в голову искажения в объективах камер. Значит, нужно эти искажения как-то компенсировать.

Калибровка камеры
У идеальной камеры важный для меня параметр только один фокусное расстояние. У реальной кривой камеры нужно учитывать еще дисторсии объектива и смещение центра матрицы.
Для измерения этих параметров есть стандартная процедура калибровки, в процессе которой измеряемой камерой делают набор фотографий шахматной доски, на которых распознаются углы между квадратами с субпиксельной точностью.



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



А также вектор коэффициентов дисторсии



который позволяет компенсировать искажения объектива с помощью преобразований координат пикселей.

Применяя преобразования с этими коэффициентами к координатам маркера на кадре, можно привести систему к модели идеальной pinhole камеры.

Провожу новый тест трекинга:



Уже гораздо лучше! Выглядит настолько хорошо, что даже вроде будет работать.

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

Вычисление координат маркера

И так, я получил кучу прямых, разбросанных по пространству, на пересечениях которых должны находиться маркеры. Только вот прямые в пространстве на самом деле не пересекаются, а скрещиваются, т.е. проходят на некотором расстоянии друг от друга. Моя задача найти точку, максимально близкую к обеим прямым. Формально говоря, нужно найти середину отрезка, являющегося перпендикуляром к обеим прямым.



Длина отрезка AB тоже пригодится, т.к. она отражает качество полученного результата. Чем он короче, тем ближе друг к другу прямые, тем лучше результат.

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

Параллельно, при разработке костюма с датчиками, я обнаружил странное явление. Все датчики показывали разные значения угла рысканья (направления в горизонтальной плоскости), как будто у каждого был свой север. В первую очередь полез проверять не ошибся ли я в алгоритмах фильтрации данных или в разводке платы, но ничего не нашел. Потом решил посмотреть на сырые данные магнитометра и увидел проблему.
Магнитное поле в нашем помещении было направлено ВЕРТИКАЛЬНО ВНИЗ! Видимо, это связано с железом в конструкции здания.

Но ведь в VR очках тоже используется магнитометр. Почему у них такого эффекта нет? Иду проверять. Оказалось, что в очках он тоже есть Если сидеть неподвижно, можно заметить, как виртуальный мир медленно, но верно вращается вокруг тебя в рандомную сторону. За минут 10 он уезжает почти на 180 градусов. В нашей игре это неминуемо приведет к рассинхрону виртуальной и реальной реальностей и сломанным об стены очкам.

Похоже, что помимо координат очков, придется определять и их направление в горизонтальной плоскости. Решение напрашивается само ставить на очки не один, а два одинаковых маркера. Оно позволит определять направление с точностью до разворота на 180 градусов, но с учетом наличия встроенных инерциальных датчиков, этого вполне достаточно.



Система в целом работала, хоть и с небольшими косяками. Но было принято решение запустить квест, который как раз был близок к завершению нашим gamedev разработчиком, присоединившимся к нашей миникоманде. Была затречена вся игровая площадь, установлены двери с датчиками и магнитными замками, изготовлено два интерактивных предмета:



Игроки надевали очки, костюмы и рюкзаки-компьютеры и заходили в игровую зону. Координаты трекинга отсылались им по wi-fi и применялись для позиционирования виртуального персонажа. Все работало достаточно неплохо, посетители довольны. Приятнее всего было наблюдать ужас и крики особо впечатлительных посетителей в моменты, когда на них из темноты нападали виртуальные призраки =)



Масштабирование


Внезапно нам прилетел заказ на большой VR шутер на 8 игроков с автоматами в руках. А это 16 объектов, которые нужно тречить. Повезло, что сценарий предполагал возможность разделения трекинга на две зоны по 4 игрока, поэтому я решил, что проблем не будет, можно принимать заказ и ни о чем не волноваться. Протестировать систему в домашних условиях было невозможно, т.к. требовалась большая площадь и много оборудования, которое будет куплено заказчиком, поэтому до монтажа я решил потратить время на автоматизацию калибровки трекинга.

Автокалибровка

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

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

Идея следующая:

  1. вешаю камеры и на глаз направляю их в игровую область
  2. запускаю режим записи на сервере, в котором все приходящие с камер 2D точки сохраняются в файл
  3. хожу по темной игровой локации с маркером в руках
  4. останавливаю запись и запускаю расчет калибровочных данных, при котором вычисляются расположения, ориентации и фокусные расстояния всех камер.
  5. в результате предыдущего пункта получается единое пространство, наполненное камерами. Т.к. это пространство не привязано к реальным координатам, оно имеет случайное смещение и поворот, которое я вычитаю вручную.

Пришлось перелопатить огромное количество материала по линейной алгебре и написать многие сотни строк питонского кода. Настолько много, что я уже почти не помню как оно работает.





Вот так выглядит напечатанная на принтере специальная палка-калибровалка.

Тестирование большого проекта


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

Когда уровень кортизола в крови превысил теоретический максимум, я решил посмотреть на проблему с другой стороны. Как можно сократить количество разноцветных точек, не сокращая количество маркеров? Сделать трекинг активным. Пускай у каждого игрока, например, левый рог всегда корит красным. А второй иногда загорается зеленым по приходу команды с сервера так, что в один момент времени он горит только у одного игрока. Получается, что зеленая лампочка будет как-будто перепрыгивать с одного игрока на другого, обновляя привязку трекинга к красной лампочке и обнуляя ошибку ориентации магнитометра.

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



Алгоритмы трекинга пришлось заметно усложнить, но в итоге все заработало! Телепортации игроков друг в друга исчезли, нагрузка на процессор упала, засветки перестали мешать.


Проект был успешно запущен, первым делом я сделал новые платы костюмов с поддержкой активного трекинга, и мы произвели обновление оборудования.



Чем все закончилось?


За 3 года мы открыли множество развлекательных точек по всему миру, но коронавирус внес свои коррективы, что дало нам возможность сменить направление работы в более общественно-полезную сторону. Теперь мы довольно успешно занимаемся разработкой медицинских симуляторов в VR. Команда у нас все еще маленькая и мы активно стремимся расширять штат. Если среди читателей Хабра есть опытные разработчики под UE4, ищущие работу, пожалуйста, напишите мне.



Традиционный забавный момент в конце статьи:


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



Система в прямом смысле работала через задницу.
Подробнее..

О том, как мы температуру в ЦОД мерили

21.04.2021 14:19:32 | Автор: admin

Если у вас большой и серьезный ЦОД, то параметрия температурных режимов не является проблемой. Существуют проверенные решения, например, программируемые контроллеры TAC Xenta, которые работают через LonWorks. Именно так мы собираем данные в московском ЦОД Datahouse. Но непосвящённому смертному весьма непросто собрать правильные показатели из этой связки и выводить их в мониторинг в нужном виде. К тому же решение промышленное и достаточно дорогостоящее. Поэтому при строительстве новой гермозоны
в Екатеринбурге мы решили поэкспериментировать и внедрить альтернативное решение по измерению температуры в холодных и горячих коридорах.

Ничто не предвещало беды

Так как множество систем в этом ЦОДе завязано на открытом коммуникационном протоколе Modbus мы решили заказать температурные датчики, работающие поэтой шине, и собирать данные с дальнейшей интерпретацией в интерфейсе мониторинга. Недорогие датчики быстро нашлись на известном китайском сайте и были заказаны партиями в количестве 20 и 40 штук.

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

Из первой партии завелось 15 датчиков. Так как острой потребности в остальных не было, пока работали с ними. К моменту прихода второй партии выявили, что часть уже установленных в шину датчиков имеет поведение новогодней елки: показывают некорректные данные, отдают checksum error или отваливаются по таймауту.

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

Вот так это выглядело:

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

Не ищем легких путей

Вскрыли, посмотрели: микросхемы идентичны. Значит дело в прошивке.

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

Пока разбирались с работоспособностью датчиков поняли, как без особых сложностей обнаружить кривую версию прошивки. Если кроме Modbus работают обычные текстовые команды READ, PARAM, AUTO, STOP значит прошивка хорошая. В мертвых прошивках текст не отдается.

Решили взять прошивку с этих живых 8 датчиков, купили программатор Nu-Link,
но хитрые китайцы заблокировали чтение прошивки. То есть перезалить можно, а считать - нельзя. Запросы правильных прошивок у поставщика потерпели фиаско:
Я продаван, я не разработчик.

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

За основу был взят Keil, пакет С51, позволяющий работать с 8-битными MCU.

В начале я научил читать сенсор SHT 20 (который собственно и снимает температурные данные), потом научил передавать эти данные по Modbus. В виду того, что этот MCU ни что иное как Nuvoton N76E003AT20, то вся база знаний, видимо, сосредоточена в руках наши китайских друзей.

В итоге i2c и Modbus сделал быстро, а вот с таймерами пришлось повозиться. Чтобы не было коллизий в шине, добавил возможность смены SLAVE_ID без выключения датчика в Китайской версии прошивки после смены адреса его нужно было обязательно выключать, что не очень удобно.

Начали шить новой прошивкой, из семи прошитых получили семь успешных и стабильных устройств. Так понемногу реанимировали все датчики, присвоили им номера и подключили витой парой в шину.

Так стало:

Если говорить про результаты измерений, то нормальные показания появляются только
в помещении с явной циркуляцией и движением воздуха. Без продува датчик показывает 30С. Это объясняется тем, что внутри установлен стабилизатор напряжения, который преобразует 24В в 3.3В, переводя разность в тепло.

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

Несмотря на возникшие осложнения, данное решение имеет два очевидных преимущества: стоимость и гибкость. Датчики можно установить в любом удобном месте, точечно или объединить в гирлянды. Можно измерять как общую температуру, так и частные показания отдельных приборов и устройств. И самое важное, что все это отлично работает по Modbus.

Программа выложена на GitHub кому интересно, можно забрать и поиграться.
Стоимость датчика всего 300 , правда, нужен программатор.

Подробнее..

Сенсорика для медицины и Умного дома лекция Станислава Полонского

04.12.2020 16:09:39 | Автор: admin

Предлагаем вашему вниманию текстовую версию видео лекции Станислава Полонского, посвященная сенсорике в Интернете вещей. Станислав - физик, кандидат физико-математических наук, начальник управления перспективных исследований и разработок в Исследовательском центре Samsung. Много лет жил и работал в США.

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

Добрый день, меня зовут Стас Полонский, я представляю российское подразделение Samsung, управление перспективных исследований и разработок (Samsung Advanced Institute of Technology).

Сперва я хотел бы обратить внимание, что прежде чем говорить о сенсорах, науке, технологиях, необходимо найти потребность. Нужна ли ваша идея, нужно ли ваше приложение? Как выйти на потребителя, на людей, которым потенциально ваша идея нужна, и с чем выйти? Есть термин минимальный жизнеспособный продукт (MVP). Какие минимальные движения вы должны предпринять, чтобы проверить на практике, нужна ли ваша идея?

Моя лекция из четырех частей:

1. Потребности. Я расскажу, как мы представляем эти потребности без проверки рынков, исключительно исходя из того, что описывается в прессе. Посмотрим, как так называемая кривая шумихи Гартнера видит использование Интернета вещей. Поговорим о том, чего москвичи ожидают от Интернета вещей, более точно - от Умного города как его части. Оказывается, что людей очень сильно волнует Интернет вещей в применении к здоровью

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

3. Сенсоры для Умного дома. Мы поговорим о газах, о запахах, которые бывают в доме, бывают неприятными и опасными. Еще одна интересная тема - мы постоянно теряем вещи, и мне кажется, было бы абсолютно классно, если бы мы могли эти вещи находить при помощи Интернета вещей.

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

Потребности

Итак, начинаем. Что такое кривая шумихи Гартнера? По оси X время слева направо, и по оси Y - ожидания.

График Гартнера. Источник - ВикипедияГрафик Гартнера. Источник - Википедия

В самом начале кривой возникают новые красивые идеи. Они плохо разработаны и пока плохо понятны. Вначале мы всегда встречаем их с энтузиазмом, и наши ожидания от технологии быстро возрастают, соответственно финансирование этих идей улучшается. Мы лучше понимаем эти идеи, и через какое-то время становится ясно, что не все из них сработают, не все из них нужны. Что начинается после достижения максимума ожиданий? Мы видим так называемую Долину смерти. Многие технологии здесь погибнут и никогда не выживут. Только часть, пройдя Долину смерти - здесь это даже не показано, потому что их так мало - в какой-то момент очень маленькая часть технологий доходит до промышленности.

График Гартнера за 2020 год. Источник: GartnerГрафик Гартнера за 2020 год. Источник: Gartner

Почему я показываю эту кривую? Здесь достаточно много технологий, связанных с Интернетом вещей. Я выделил их красным:

  • Паспорт здоровья: здесь, мы ожидаем, Интернет вещей может помочь нам.

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

  • Технология социального дистанцирования. Очень модная, и может быть, она окажется полезной. Есть очевидный запрос и очевидно простая реализация.

Ключевые идеи, которые хотелось бы здесь донести:

  1. Интернет вещей пока еще не взлетел, пока что это много надежд, небольшие приложения, но повсеместного использования нет.

  2. Мы говорим о сенсорике Интернета вещей. Сенсорика - эта физика, и за двести-триста лет развития физики мы изобрели массу сенсоров. По всей видимости, особой нужды изобретать новые сенсоры у нас нет. Но важно посмотреть, как существующие сенсоры могут быть вписаны в новые модели, сценарии использования, которые позволят продавать. Я напоминаю: как инженеры, мы хотим не только делать вещи, но и продавать их. Этим занимается не только отдел продаж, инженеры тоже должны об этом беспокоиться.

Итак, давайте двигаться дальше. Что думает Москва? Это слайд из стратегии Москва - Умный город 2030, и здесь показаны проценты по опросам, какие технологии больше всего нас волнуют. Это на 64% персональная медицина, и на втором месте всего на два процента меньше, это Умный дом. Другие технологии в принципе не так сильно отстают по процентам.

Источник: mos.ruИсточник: mos.ru

Понятно, москвичам хочется всего и сразу, но тем не менее на первом месте это персональная медицина и умный дом. Поэтому мы и сосредоточимся на этих двух темах. Москвичи, и скорее всего все россияне и весь мир, возможно, действительно хотят иметь Интернет вещей, помогающий персональной медицине или Умному дому, но для меня пока совершенно не очевидно, что люди готовы платить за это.

Сенсоры в медицине

Сенсор пульсовой волны

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

Источник: how2electronics.comИсточник: how2electronics.com

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

Источник: EuropePMCИсточник: EuropePMC

Да, это не просто синус, это сложная форма, она часто говорит врачам о том, что с нами происходит. Причем анализировать волну могут и умные алгоритмы. Что конкретно мы при помощи этого датчика измеряем? Прежде всего, пульс. Достаточно ли пульса? Не всегда. Например, можно посмотреть, насколько регулярен пульс, как часто меняется скорость сокращений сердца, это называется вариабельность (heart rate variability, HRV). Еще можно измерить насыщенность крови кислородом, эта переменная называется SpO2. Это, пожалуй, основное.

Небольшое лирическое отступление: мечта разработчиков оптических сенсоров - измерить сахар в крови. Это важно для диабетиков, это важно для контроля, как и что мы едим, но, насколько я понимаю, это очень сложная задача, и сейчас она еще не решена. Так что давайте думать больше про то, как часто сокращается наше сердце - это пульс, как меняется частота сердечных сокращений и насколько наша кровь насыщена кислородом.

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

Источник: stern.deИсточник: stern.de

Можно ли вытащить эти сенсоры и проникнуть на потребительский рынок? Это делается, к примеру, в носимых устройствах. Например, на корпусе часов Samsung Gear S3 Frontier есть небольшое окошечко, там стоят оптические элементы, которые светят на руку и вытаскивают эти данные.

Samsung Gear S3 FrontierSamsung Gear S3 Frontier

Я не думаю, что это очень важно абсолютно всем. Может быть, важно для атлетов. Но мы экспериментируем, смотрим, что конкретно можно сделать, какие проекты возможны. Например, в медицине пока что большинство датчиков с проводом - неприятно, неудобно, если вы лежите в кровати и повернулись на другой бок. Все ли можно сделать беспроводным через WiFi и Bluetooth? В принципе, была хорошая идея и даже есть попытки стандартизации - американское министерство здравоохранения говорит на эту тему уже несколько лет.

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

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

Подведу итог: если вас интересует измерение частоты сердечных сокращений, то в этой задаче используется не только оптика, но и видеокамера, и радиодиапазон.

Измеряем сопротивление

Теперь рассмотрим сенсор электросопротивления организма. По-научному это называется биоимпедансометрия. Импеданс - термин из электроники, связывает токи и напряжения. Био, потому что мы не кусок металла, не графитовый стержень - мы сложный объект, и наше сопротивление зависит от ряда факторов: насколько мы полные или тощие, сколько в нас воды; более того, на разных частотах наше сопротивления отличается, не константа.

Посмотрим несколько примеров, как измеряется импеданс. Вот эта большая колонка может находиться в клинике.

Источник: AVM Active SportИсточник: AVM Active Sport

Вот пример умных часов, которые измеряют ваш импеданс.

Источник: TomTomИсточник: TomTom

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

Источник: EMBИсточник: EMB

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

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

Измеряем электроактивность

Давайте перейдем к другим датчикам, связанным с нашим здоровьем: сенсор электроактивности организма. Это может быть электрокардиография: мы смотрим, как сердце ведет себя электрически, либо электроэнцефалография - это про наш мозг. Здесь очень простая теория: подключить электроды к поверхности нашего тела и смотреть, какие токи и напряжения у нас возникают. Можно измерить электрическое расстояние между различными частями тела, и чем больше измерительных точек мы используем, тем точнее будут наши измерения.

Источник: MedicalFuturistИсточник: MedicalFuturist

Тут я снова призываю помнить о том, что в быту это вряд ли сработает. Если вы в госпитале, либо вы профессиональный атлет, желающий улучшить свои показатели, то может быть, вы этим воспользуетесь. Но для большинства из нас обвешаться датчиками сложно, и вряд ли кто-то будет это делать в повседневности. Лучшее приложение, по всей видимости, будет наименее инвазивным, чтобы не не мучить пользователя бесконечным измерениями.

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

Источник: ECG MedicalИсточник: ECG Medical

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

Умный дом

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

Газовые сенсоры

Мне бы хотелось выделить для начала газовый сенсор. Какие газы нас волнуют? CO2 - углекислый газ. Мы не хотим находиться в помещении, где много углекислого газа. Если у нас газовая плита, то если в комнате появляется CH4 - метан - это проблема, может быть взрыв. Другие взрывчатые вещества тоже хотелось бы определять. Как это делается? Хорошо известен оптический способ, или, я бы даже сказал, спектроскопический, когда поглощение молекулами газа на определенной длине волны связано с концентрацией этого газа.

Источник: researchgate.netИсточник: researchgate.net

Бывают датчики электрохимические: взаимодействие молекул газа с поверхностью нашего электрического прибора может быть зарегистрировано электрическим способом.

Источник: OrientJChemИсточник: OrientJChem

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

Источник: Tokyo Institute of TechnologyИсточник: Tokyo Institute of Technology

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

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

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

Поиск предметов

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

Если начать с самых простых решений, то стоит сказать о пассивных RFID-метках. Это просто небольшая антенна, связанная с микросхемой, наверняка вы видели их на товарах в магазинах.

Источник: all-electronics.deИсточник: all-electronics.de

Другое решение - поставить GPS-сенсор, прикрепить его на машину или на кошку, и узнать, где она, даже во многих километрах от нас.

Источник: gps-tracking.com.uaИсточник: gps-tracking.com.ua

А если необходимо будет искать потерянные вещи на больших расстояниях? Скорее всего нам понадобятся батарейки. Хорошо, если батарейки хватит на несколько месяцев, но, например, в случае GPS-геолокации, она может служить только пару дней. И это плохая новость для нас, инженеров. Для такого кейса неприемлемо, чтобы пользователь часто менял или заряжал батарейку, и это нерешенная проблема. Если вначале я говорил, что для сенсоров все технологии известны и нужно найти лишь приложение для них, то здесь я бы сказал, что есть место для хорошей физики и радиоэлектроники.

Какие еще идеи для проектов я бы хотел предложить? Может быть, это звучит футуристически, но если будет решена проблема с батарейками и мы можем пометить вещи, то возможно компьютерная система сможет навести порядок, если вы не способны сделать это сами? Может ли система запомнить, что такое порядок, когда вещи находятся на своих местах, и если вдруг вещь окажется не на своем месте, система вежливо нас попросит положить эту вещь на место? Это реально моя любимая идея, мне кажется, здесь очень большие приложения, потому что мы не самый аккуратный биологический вид на этой планете, и мы постоянно боремся с бардаком в доме и на работе. Если мы сможем электронным способом навести порядок, это было бы классно.

Заключение

Итак, давайте посмотрим, о чем мы сегодня говорили. Мы поговорили о том, какие направления Интернета вещей нам интересны: это персональное здоровье, это Умный дом. Мы коротко обсудили, какие сенсоры для этого используются и дали примеры, как эти сенсоры могли бы быть встроены в приложения, которые потенциально могут найти своих потребителей.

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

Далее, при создании ваших решений Интернета вещей, я рекомендую руководствоваться следующими принципами.

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

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

  2. Защита данных. Используйте криптографию с самого начала; что бы вы ни делали, ваши данные должны быть защищены! Тем более, если мы говорим о таких чувствительных вещах, как персональная медицина.

  3. Эффективное энергопотребление. Как я уже говорил, если вы хотите использовать батарейки, подумайте, как часто потребитель захочет менять их? Ваш продукт должен быть настолько энергоэффективным, чтобы он работал на батарейке многие годы, либо вы могли использовать методы передачи энергии на расстоянии.

Я хотел бы завершить лекцию, с моей точки зрения, идеальным устройством - Умной розеткой! Реально, когда я думаю про умную розетку, она удовлетворяет всем принципам, о которых я только что говорил: прозрачность и беспроводность. По определению, в розетке всегда есть электричество, вам не нужно думать о батарейках. Вы не добавляете ничего нового, вы не навешиваете ничего на себя. И если в этой розетке сделать модульную систему и добавить разъемы для новых расширений, мне кажется, это могло бы быть удачной идеей для стартапа.

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

Источник: astra-media.byИсточник: astra-media.by

Если есть вопросы, пишите в комментариях. Я и мои коллеги в Samsung Research Russia всегда рады пообщаться с талантливыми интересующимися людьми.

Видео лекции

Авторы

Станислав Полонский Начальник управления перспективных исследований и разработок Исследовательского центра Samsung

Татьяна Волкова Автор учебной программы трека по Интернету вещей IT Академии Samsung, специалист по программам корпоративной социальной ответственности Исследовательского центра Samsung

Ссылки

Если вам понравился материал, то ознакомьтесь и с другими статьями тех же авторов:

  1. Статья Татьяны Волковой График Гартнера 2019: о чём все эти модные слова?

  2. Статья Станислава Полонского 5G - где и кому он нужен?

Подробнее..

Разработка универсального счетчика импульсов

09.02.2021 14:04:30 | Автор: admin

В производстве и на конвейерных линиях часто возникает задача подсчета продукции или операций оборудования. Во многих случаях станки уже имеют комплекс аппаратных и программных средств, позволяющих получить данную информацию. Также существуют специализированные счетчики, адаптированные под конкретную задачу или оборудование. Но при наличии разнотипного оборудования затраты на программное сопряжение становятся существенными. Хотелось бы иметь простой универсальный счетчик, который легко адаптируется под разные задачи и передает события на сервер для дальнейшей аналитики. Об опыте разработке такого счетчика и пойдет речь в данной статье.

Оптические датчики и их особенности

Чаще всего при подсчете продукции или отслеживании механического перемещения внешним датчиком используются оптические датчики барьерного, рефлекторного или диффузионного типа.

Рисунок 1. Типы датчиков (И - источник, П - приемник, О - объект).Рисунок 1. Типы датчиков (И - источник, П - приемник, О - объект).

Принцип работы барьерного датчика очень простой - имеются разнесенные в пространстве источник света и приемник, между ними проходят объекты, тем самым закрывая источник света от приемника. Полученный сигнал с фотоприемника коррелирует с прохождением объекта и практически не требует обработки. Однако системы с таким датчиком не лишены недостатков - обычно это несколько модулей, требуется прокладка кабелей и юстировка оптической системы. В случае рефлекторного и диффузионного типа датчиков установка проще, так как источник и приемник находятся в одном корпусе. Рефлекторный датчик принимает отраженный от объекта или специальной отражающей метки свет, а диффузионный - рассеянный, учитывая при этом его интенсивность. Но для датчиков этих типов полученный сигнал требует дальнейшей обработки. Вне зависимости от выбранного типа датчика, для счета обычно используется независимый микрокомпьютерный или микропроцессорный блок как отдельное устройство.

Первый прототип датчика

Так как нам хотелось бы иметь устройство в едином корпусе, максимально адаптируемое под разные задачи, было решено: во-первых, использовать датчик работающий на отражение, во-вторых, реализовать блок подсчета на встроенном компьютере.

За отправную точку было решено взять аналоговую часть универсального тахометра, который работает на отраженном свете. В этом случае на движущийся механизм (например, вал) крепится яркая светоотражающая метка, наводится луч света, и прибор показывает частоту вращения. Источником света может выступать как лазер, так и обычный светодиод. В первом прототипе нашего счетчика импульсов за источник света был взят светодиод, использовалась линза с фокусным расстоянием 35 мм. На одном операционном усилителе был собран компаратор, на другом буферный элемент. Также была собрана цепочка, обеспечивающая плавающий порог срабатывания компаратора.

Принципиальная схема
Рисунок 2. Первый прототип датчика - принципиальная схема.Рисунок 2. Первый прототип датчика - принципиальная схема.

Испытания показали работоспособность в диапазоне 10-30 см с очень контрастными метками (использовали световозвращающий скотч). Но такой результат нас еще не устраивает, так так датчик на просвет работает на значительно больших расстояниях. Также система оказалась чувствительна к включению/выключению освещения в помещении, и при использовании подобного подхода от этого недостатка избавиться не получится.

Второй прототип датчика

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

Принципиальная схема
Рисунок 3. Второй прототип датчика - принципиальная схема.Рисунок 3. Второй прототип датчика - принципиальная схема.

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

Третий прототип датчика

В результате проведенных опытов стало понятно, что нельзя обойтись без дополнительной настройки системы, которую можно осуществить только с помощью микроконтроллера. Также для исключения влияния помех от фонового освещения решили добавить модуляцию опорного сигнала и преобразование Фурье на приемнике. Корпус уже был разработан и изготовлен на предыдущих этапах, и нам хотелось вписаться в его габариты. Так выбор пал на практически единственный вариант - STM32G030J6M6 Cortex - M0+ c ADC 2.5Msps в корпусе SOIC-8. Отличное решение для непрерывной обработки данных от АЦП. Общение с микроконтроллером осуществляется по шине I2C.

Принципиальная схема
Рисунок 4. Третий прототип датчика - принципиальная схема.Рисунок 4. Третий прототип датчика - принципиальная схема.

На операционном усилителе собран трансимпедансный усилитель тока фотодиода. Лазер модулируется дискретным сигналом от таймера, потому что в данном случае нет необходимости получать чистый синус. Для совместимости с предыдущими решениями был сделан дискретный вывод для использования аппаратного счетчика событий (1й пин разъема P1), а конфигурация осуществляется один раз при старте системы. Таким образом, сохраняется полная преемственность с уже написанным ПО.

В микроконтроллере реализованы генерация сигнала ШИМ, обработка оцифрованных данных и общение по I2C. За генерацию ШИМ отвечает таймер, синхронизированный с АЦП. Данные передаются в память по DMA и обрабатываются по половинам - пока заполняется первая половина буфера, вторая анализируется. Сам алгоритм обработки данных получится следующий:

Рисунок 5. Алгоритм обработки данныхРисунок 5. Алгоритм обработки данных

Микрокомпьютер

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

  • возможность запускать программу на Python 3,

  • место для пары сетевых библиотек,

  • интерфейсы Ethernet и Wi-Fi для связи с сервером,

  • питание по micro USB или PoE,

  • производительность - не критично,

  • время включения - не более 2 минут,

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

Сначала мы использовали Orange Pi zero, однако, учитывая их немалые габариты и невозможность нормально сделать PoE, решено было поискать другие варианты. Так взгляд пал на одноплатный компьютер VoCore, характеристики которого полностью подходили под задачу. Изучив предложения на китайском рынке, был найден очень похожий вариант выпускаемый массово - процессор RT5350, 32Mb RAM, 8/16Mb Flash.

Рисунок 6. Одноплатный компьютер VoCore.Рисунок 6. Одноплатный компьютер VoCore.

Он немного больше, чем оригинальный VoCore, зато под модулем остается место для размещения компонентов, а также у модуля есть удобный разъем для подключения к основной плате. Схематика незначительно отличается от оригинального VoCore, так что конфигурацию от VoCore можно легко адаптировать под китайского товарища.

Конструктив

Рисунок 7. 3Д модель счетчика.Рисунок 7. 3Д модель счетчика.

Для удобство калибровки системы было решено дать одну степень свободы оптическому датчику, разместив его в отдельной поворотной голове.

Рисунок 8. Поворотная часть корпуса.Рисунок 8. Поворотная часть корпуса.

От люфта и случайного поворота защищает пружина и фрикционная шайба. Для большинства задач этого оказывалось достаточно. Материнская плата, модуль PoE и сам компьютер расположены максимально компактно в основной части корпуса.

Рисунок 9. Основная часть корпуса.Рисунок 9. Основная часть корпуса.

Так как партии пока относительно небольшие корпус изготавливается методом SLS печати.

Итак, в итоге у нас получилась следующая архитектура устройства:

  • вычислительный модуль (одноплатный компьютер),

  • основная плата, на которой расположены разъемы Ethernet, USB, I2C, светодиоды и кнопка,

  • плата питания (устройство может питаться как от microUSB так и от PoE).

Подсчет срабатываний

Теперь пара слов о том, как реализован подсчет срабатываний датчика. Независимо от типа датчика, алгоритм подсчета импульсов остается одинаковым. Выход датчика подключается к GPIO процессора. Количество импульсов подсчитывалось через GPIO interrupt. Для этого требуется настроить GPIO на вход и включить прерывания. Об этом хорошо написано, например, тут. Число срабатываний можно посмотреть командой cat /proc/interrupts | grep gpiolib. Если же требуется реагировать на каждое событие или записывать время его срабатывания, то уже придется написать простую программу. Данный подход хорошо себя зарекомендовал и является необходимым и достаточным источником данных для подобного класса датчиков. В случае датчика с микроконтроллером, нужно перед началом работы загрузить необходимые параметры по I2C.

Заключение

Итак, что мы имеем на выходе? Компактное устройство для подсчета импульсов с оптическим датчиком и готовой реализацией отправки данных на сервер по Ethernet или WiFi. Была реализована передача данных по MQTT. Адаптивная архитектура также позволяет легко подключать практически любой другой датчик по I2C или SPI через переходник. На данный момент имеются такие варианты счетчиков: лазерный с аналоговой обработкой сигналов, лазерный с цифровой обработкой сигналов, а также индукционный счетчик для подключения внешнего промышленного индукционного датчика. Разработанный корпус позволил осуществлять поворот оптического модуля, а также его замену на другой тип датчика. В ближайших планах хотим подключить тепловизионный датчик для мониторинга нагруженных узлов в производстве.

Подробнее..

Категории

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

  • Имя: Макс
    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