Моя версия костюма отслеживания движений

    Предыстория


    Много времени утекло с того момента, как я стал начинающим «ардуинщиком». После заказа «стартового набора» из поднебесной и поморгал светодиодами, и покрутил сервоприводами, и даже собрал простенькую платформу Гью-Стюарта из кусков упаковочного полиэтилена, скрепок, кнопок и копеечных сервоприводов SG90.

    image

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

    С этой платформы и началась, может быть даже кому-то интересная история. Управлять платформой с помощью клавиатуры или джойстиком интересно, но управлять ею датчиком положения в пространстве — интереснее вдвойне. Пробуя корректно заставить работать очень известный датчик от TDK — InvenSense MPU-9250, вспомнилась статья уважаемого ObelardO — «Как я делал костюм захвата движений» и затаилась идея в голове повторить этот опыт.

    Что из этого получилось, можно увидеть и прочесть под катом.

    Перепробовав всевозможные фильтры, свободно доступные в интернете, перерыв github и все общедоступные форумы, я не нашел практически нигде нет корректного кода для Arduino и MPU-9250. Скорее всего я не умею готовить чего-то напутал с математикой фильтров, но ни один из найденных у меня корректно не заработал. Зато после всех изысканий — я смог существенно подтянуть знания в трехмерном евклидовом пространстве, математике кватернионов и бикватернионов.

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

    Подключаем Blender к Arduino


    Моей настольной ОС уже давно (наверное с выходом Windows 10) является Ubuntu — на тот момент 14.04, сейчас 18.04. Далее все манипуляции буду приводить для этой ОС.
    Установка Blender тривиальна и не требует никакого описания, я использую версию 2.79b, так как там есть модуль Blender Game Engine.

    Для установки необходимых сторонних библиотек:

    pip3 install “нужная библиотека”

    После установки pySerial, мы можем читать из порта данные о кватернионе напрямую в Blender и крутить кубик, подключив его следующим образом:

    Blender script
    import mathutils
    import serial
     
    qw = 0.0
    qx = 0.0
    qy = 0.0
    qz = 0.0
     
    arduino = serial.Serial()
    arduino.baudrate = 115200
    arduino.port = '/dev/ttyUSB0'
     
    def Port():
        global qw, qx, qy, qz
        global arduino
        data = arduino.readline().strip()
        quat = data.decode('ascii').split(',')
        qw, qx, qy, qz = [float(s) for s in quat]
        print(qw)
        print(qx)
        print(qy)
        print(qz)
     
    def Cube():
        global qw, qx, qy, qz
        scene = bge.logic.getCurrentScene()
        cont = bge.logic.getCurrentController()
        obj = cont.owner
        obj['qw'] = qw
        obj['qx'] = qx
        obj['qy'] = qy
        obj['qz'] = qz
        quat_cube = mathutils.Quaternion((obj['qw'], obj['qx'], obj['qy'], obj['qz'])) 
        quat_cube.normalize()
        obj.localOrientation = quat_cube()
     
    def Close():
        global arduino
        arduino.close()
     
    def Start():
        global arduino
        arduino.open()


    Arduino отдает нам кватернион в текстовом виде:

    Serial.print(q.w, 4);
    Serial.print(",");
    Serial.print(q.x, 4);
    Serial.print(",");
    Serial.print(q.y, 4);
    Serial.print(",");
    Serial.println(q.z, 4);

    Кубик на экране никак не хотел вращаться даже отдаленно напоминая реальные движения датчика в пространстве, движения были очень «шумны» и неестественны.

    InvenSense Digital Motion Processor (DMP)


    В конце концов я добрался до «магического» Digital Motion Processor (DMP). Плохо искал Оказалось, не существует корректного кода MPU-9250 с DMP для младших моделей Arduino (в моем случае я перепробовал Uno/Mini/Рro Mini с процессором 328p), даже нигде в документации на датчик не указано, что он умеет 9-ти осевые кватернионы (кватернион рассчитывается на показаниях акселерометра, гироскопа и магнитометра). Можно сказать — я немного лукавлю, и кое-где это написано, но кроме фраз «да, умеет» никаких более инструкций и т.п. просто нет. Покупать плату разработчика или более мощную Arduino Zero мне очень не хотелось и я засел за инструкции по датчику, очень много гуглил и искал код. Одним днем удача мне улыбнулась — я нашел на одном корейском сайте реализацию прошивки для процессора 328p и датчика MPU-9250. Если честно, в дальнейшем я не стал разбираться чем именно эта прошивка отличается от других, лежащих в репозиториях на github, но она работала и выдавала 6-ти осевой кватернион из IMU (6-ти осевой — значит, кватернион рассчитывается на показаниях акселерометра и гироскопа).

    Попробовав получить данные магнитометра — я получил `NaN`.
    То есть цифровой компас не отдавал свои значения в DMP, соответственно этот сопроцессор на датчике его не обрабатывал, но движения были как «небо и земля», по сравнению с другими реализациями.

    Ну где наша не пропадала? Изучив на тот момент всю доступную документацию по датчику, множество вариантов всевозможного кода для него и продолжая изучать проблему сразу бросилось в глаза — корейский код DMP написан для датчика MPU-9150, который снят с производства. Откорректировав некоторые значения (магнитометр в датчике другой и имеет другой адрес), я был очень удивлен и поражен, что все заработало. Более того, я не только смог получать данные о магнитном поле, но и сам кватернион стал более стабильным — в режиме покоя на столе практически отсутствует дрифт вокруг оси Z (максимальная проверка проводилась около 10 часов). Некоторое смещение происходило только когда я за шнурок отчаянно крутил датчик, мне кажется — это связано с ограничением в 2g или глюками в работе магнитометра. При работе DMP, когда ускорение датчика превышает некоторый порог и данные магнитометра перестают коррелировать с остальными параметрами, DMP перестает учитывать магнитометр при вычислении кватерниона и он становится из 9-ти осевого, 6-ти осевым.
    Косвенно это упоминание есть в документе «Motion Driver 6.0 — Features User Guide» от InvenSense, где MPL library каждые 5 сек. проверяет корректность данных от магнитометра и в зависимости от этого использует эти данные в расчетах или нет.

    Схема


    За основу расположения датчиков на человеке мною была принята следующая картинка:

    image
    «Биомеханика» Автор: Владимир Иванович Дубровский

    Где светлыми квадратами и цифрами обозначены центры масс частей тела человека, а буквой «S» и черным квадратом центр массы тела человека -итого 15 датчиков — для светлых квадратов и центра массы. Для такого количества датчиков очень напрашивается использование двух I2C 8-ми канальных мультиплексоров (подобное было в костюме упоминаемом в самом начале). Ну а что — дешево и сердито. После некоторых экспериментов я решил использовать связку WeMos D1 mini + MPU-9250 + Battery Shield + MQTT протокол по нескольким для меня причинам:

    • Исключение проводного подключения — много соединительных проводов, неизбежные путаница, сложность “одевания и снятия” и возможные электромагнитные наводки.
    • Перенос части вычислений с ПК — с одной стороны, ресурсов у любого ПК по сравнению с Arduino более чем достаточно, с другой стороны обработка одного кватерниона одним ESP8266 не сильно ресурсоемкая задача.
    • При использовании мультиплексоров я не смог бы перенести математику на микроконтроллер — время считывания данных с датчика около 2 мс, при 15 датчиках это бы заняло 30 мс. Я же использую скорость опроса 50 Гц, т.е. хочу получать новые данные каждые 20 мс, т.е. у меня просто не оставалось бы времени на обработку и корректировку полученных данных.
    • Использование протокола MQTT позволит сэкономить полосу пропускания (передаем только необходимые значения когда нужно), к тому же данный протокол быстрее стандартного http.
    • Древовидная структура каналов, и правила подписки и публикации сообщений, как по мне более подходит для реализации.
    • Возможность передачи дополнительных данных по запросу, кроме кватернионов. Т.е. организация двусторонней связи через сообщения (Start — Stop — Calibration — DeepSleep).
    • Универсальность для одного модуля — взаимозаменяемость без перепайки.
    • Использование обычной беспроводной сети, обновление «по воздуху» прошивок.

    Так как человеческое тело для Blender со скелетом “Game engine” я просто сгенерировал в MakeHuman и обозвал его “adam”, а для беспроводной сети я использую отдельную точку доступа с внутренней сетью 192.168.50.0/24, то общая схема датчиков имеет следующий вид:

    image

    Из этой картинки понятно — каналы для сообщений будут иметь вид “adam/head" / ”adam/thigh_r" / ”adam/hand_l" и т.п., а для подписки на нужные достаточно подписаться у брокера соединений на канал “adam/#". Думаю пояснения требует только один “root” — это вектор перемещения в пространстве одноименной кости, которая задает местоположение центра модели, но для удобства обработки на стороне ПК я перевожу этот вектор в кватернион с нулевой скалярной частью, все остальные — “настоящие” кватернионы, которыми задаются положения костей в пространстве.

    Немного математики


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

    Я же опишу некоторые моменты использованию векторов и кватернионов в своем проекте:

    • Процесс калибровки запускаемый с ПК — для этого человек должен принять позу “Т”, с ПК запускается команда для всех датчиков, а каждый датчик запоминает свой сопряженный кватернион. При умножении которого на получаемый мы получаем единичный. Делается это потому что датчики калибруются от 20 до 60 секунд, при этом идет девиация по оси Z.
    • Отдельно нужно наверно описать вектор перемещения. В процессе калибровки я беру “идеальный” вектор силы тяжести, поворачиваю его на настоящий кватернион, отнимаю вектор акселерометра датчика от полученного “идеального” в координатах настоящего кватерниона. И создаю вектор корректировки суммой “идеального” и разницы.
    • При каком либо перемещении в пространстве, я поворачиваю корректировочный вектор на обратный настоящему, нахожу разницу между этим вектором и вектором акселерометра и поворачиваю на настоящий кватернион. Из полученного вектора и рассчитываю новое положение для кости root.
    • Проверка разности кватернионов. Эту функцию используем для понимания есть ли изменения в сравнении с предыдущим отправленным значением или нет. Я не нашел плохо искал нужную функцию, поэтому использовал следующую из английской Википедии — норма разности это расстояние между двумя кватернионами. Т.е. если норма разности менее какого-то значения = кватернионы практически равны.
    • Трансляция кватернионов в систему координат кости. Тут все относительно просто — берем векторную часть кватерниона и создаем новый кватернион, где перемещаем векторные части как в Blender и/или если необходимо делаем часть с обратным знаком. Для этого нужно понимать как именно будет расположен датчик на теле и эта часть должна быть “твердым телом” с костью в Blender.Например для “adam/head" такая трансляцию будет (w, y, z, x) (расположение кости z — вперед, x — влево, y — вверх, а датчик расположен x, y, z соответственно и на лбу).
    • Для того, чтобы вращения вычисляемые от датчика правильно применялись, нужно знать кватернион кости. Я его поместил сразу в прошивку, но ничего не мешает нам передать его в контроллер при отпарвки команды калибровки (как пример). Чтобы применить вращение от датчика на кости нужно обратный кватернион кости умножить на нужный и затем умножить на прямой.

    Сборка


    Общая схема соединения WeMos D1 Mini + MPU 9250 не содержит ничего необычного и уверен не требует объяснений.

    image

    Итак в новый год я заказал себе подарок на сумму аж в $125:

    • WeMos D1 Mini — 16 шт.
    • WeMos Battery Shield — 16 шт.
    • WeMos Prototype Board — 16 шт.
    • GY 9250 — 16 шт.
    • Lithium Polymer LiPo Rechargeable Battery JST 2.5mm 1200mAh 3.7V — 15 шт. размерами около 50x34x6мм.

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

    Кстати Китай — такой Китай, на одной платке D1 была плохо припаяна ESP8266, один датчик 9250 имел КЗ между ножками. Процент брака более 6%, но на мою удачу с помощью фена эти проблемы легко решались.

    image

    Фото промежуточное без MPU9250.

    И вот вопреки благодаря COVID-19 за счет удаленной работы и экономии примерно 3-х часов в день на дороге туда-обратно смог более плотно приступить к финальной сборке.
    При походе в строймаг были куплены:

    20-ти метровая бобина черного ремня 30мм. — цена 155 грн.

    Пряжки для ремня D30мм черные 2 шт. в количестве 8 уп. — цена 38,50 грн/уп.

    И началось:

    image

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

    Итог


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


    Нужно сделать несколько пояснений:

    • Видео снималось со второй попытки.
    • Я не дождался нормальной калибровки датчиков, так как после первой попытки прошивал их.
    • Ремни — очень неудобный способ крепления, постоянно съезжают, нужно поправлять, невозможно закрепить чтобы корректно переносились движения на кости.
    • Я забыл надеть датчики на ступни.
    • Честно — было очень лень переснимать, уверен, что для понимания того, что происходит этого достаточно.
    • Также в данном видео нет перемещения, Blender как-то странно себя ведет с костями, но со стандартным кубом все получалось более-менее приемлемо.
    • Разумеется все это дело буду дорабатывать, есть куда стремиться.

    Послесловие


    Сейчас в разработке собственная платка, где все компоненты будут расположены на площади 34х50 мм (примерный размер используемых аккумуляторов). Также планирую добавить на нее более удобную кнопку Reset и RGB-светодиод для сигнализации (работа, калибровка, передача данных и т.п.).

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

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

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

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 46

      +1
      Совет, попробуйте для калибровки наложить на датчики qr-коды или что по проще, и снимать себя несколькими FullHD/8k-камерами (хотя последнее может быть дорого) и вычислять положение уже по изображениям.
        0
        Получится что-то вроде kinect но с обычными камерами?
          0
          Недавно в статье об умных комбайнах писали, что для решения их задачи оказалось достаточно только изображения с камер без спутниковой навигации
            0
            Вот честно — не представляю, какие ресурсы нужны, чтобы, например с 3-х 8k камер в режиме реального времени отслеживать маркеры, поворачивать и распознавать их. Что-то вроде 2-х процессорного сервера на Xeon Silver?
            Опять же в этом случае нужно «готовить» помещение, для расчета математики на лету.
              0
              Для КАЛИБРОВКИ реального времени не нужно!

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

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

              Я точно видел проекты распознавания ярких точек в реалтайме (30-60fps) на основе дешевых микроконтроллеров и не fullhd камер, т.е. устанавливаем отражатели в целевых точках и светим на них от камеры.

              Если вы найдете soc платы с процессором, поддерживающим fpga и прямым доступом к CMOS HD камеры то большие шансы что можно сделать сверхбыстрое и достаточно точное (миллиметры погрешности на расстоянии метры) распознавание координат.
                0
                Oculus Rift использует 3 FullHD камеры (без цвета) и всё это вполне работает на 60Гц.

                Оптика не заменяет акселерометры, а дополняет их. Оптика — 60Гц, акселерометры — 1000Гц.

                При этом собственно oculus sensor можно заставить определяться как видеокамеру (он собственно и есть видеокамера), поэтому вся обработка происходит не в нём.
                  0
                  Там железо свое анализирует поток с камер, вы знаете что из общедоступного задешево можно самодельщикам найти? и даже в этом случае готовый софт наверное не найдете, а пилить самому не просто.
                    0
                    Камера с WiiMote есть за недорого. Отслеживает до 4-х точек одновременно с разрешением 1024х768, углы обзора 33х23 градуса.
                      0
                      его же хрен купишь кроме как с рук
                        0
                        По ссылке не сходили? Китайцы уже все сделали, готовый модуль и библиотека под Arduino. Правда цена в два раза выше китайского Wiimote в сборе ;)
                          0
                          зашел
                          Resolution is 128x96 pixel, with hardware image processing, which can track four objects (IR emitting or reflecting objects)
                            0
                            Это физическое разрешение сенсора, он с аппаратной обработкой и отдает потом разрешение в 1024х768. Этот же сенсор (или аналог) используется в WiiMote.
                            image
                            Кстати у этого производителя PixArt Imaging Inc. — есть сенсоры с физическим разрешением 98х98 пикселей, но отдают картинку разрешением 4096х4096, с 16 отслеживаемых точек одновременно.
                              +1
                              Наверное тут все же речь идет не о картинке а о угловом разрешении координат вычисляемых источников освещения? Потому что картинку тут вообще не нужно передавать.

                              Потому что когда я слышу о растровом разрешении, я сразу добавляю возможности использования полутонов для вычисления координат. Кстати при этом погрешности в граничных ситуациях плохие, т.е. если будет паразитная засветка или еще какие помехи, будут глюки.
                                0
                                В точку. Прошу прощения за некоторую простоту (относительно картинки) в моем сообщении. Кому нужно — поняли, что я имею ввиду.
                                Для человеческого восприятия мне проще употреблять такие аналогии.
                      0
                      Обычный oculus sensor железом разве что занижает разрешение камеры. На ПК через USB идёт обычный поток видео. Вся обработка — софтовая.

                      Update: doc-ok.org/?p=1138

              +1
              Не совсем понимаю зачем QR коды. Да и камеры с такими высокими разрешениями. «контроллеры» у нас однозначные, калибруем их без человека, одеваем на нужные места и всё. обычной световой индикации хватит чтоб сопоставить, так как мы знаем что контроллер 1.1 будет в нижней части. Остальное дело техники.
              с PsEye и мувами что то подобное на пк и делают www.youtube.com/watch?v=JuQQM32k2mU
                0
                да можно по очереди откалибровать каждый датчик, qr код позволит сделать это быстрее и одновременно все (qr-код тут само собой не обязателен но для него написано очень большое количество готовых библиотек)
                  0
                  QR избыточны и не нужны в данном случае совсем. Это в принципе не проблема которая требует особого внимания. Внимание требует совместимость с существующим ПО. Какой смысл от крутой железки в вакууме, в отрыве от имеющейся экосистемы.
                0
                Все таки правильно говорят «утро вечера мудренее». Я все таки понял что вы советуете — поправьте меня, если я не так понял.
                В моем проекте «калибровка» — это соответствие положения датчика и человека в позе «Т». Для этого я сейчас использую нажатие кнопки и задержку в пару секунд, чтобы принять положение правильное.
                Если мы снимаем на обычную вебку человека, то для сопоставления позы и начальной позиции, достаточно распознать что человек принял нужную стартовую позу. Можно даже обойтись без маркеров, таких как QR-код или светодиод. Отличная идея, спасибо!
                  0
                  и вам будет достаточно этой точности?

                  я считал что калибровка — это определение дельты для совмещения реальных координат с теми что выдают датчики.

                  пример — вы встаете в позу T, вопрос, то что вы при этом руки сделаете не параллельны земле вас не волнует?
                    0
                    Вот как раз с вектором тяжести (т.е. параллельности земле) все очень хорошо с этими датчиками. Не очень хорошо с магнитным полем ;)
                      0
                      Это был пример, вы можете встать под углом в каких то 5 градусов к плоскости камеры и не заметить этого, какие это создаст глюки в будущем, наверное отдельный вопрос.

                      Я пойму игры танцы, там точность не нужна, но вот взаимодействие с виртуальными предметами — вот где вылезут все косяки калибровки.
                  –1
                  вообще есть очень дещовый вариант от Клапана Steamvr tracking. Он весьма круто работает и легко вычесляется + по железу нужны лиш TS4112 и контролер для вычисления положения по данным с них.
                  0
                  Насколько это точнее чем тупо нацепить на себя уйму lighthouse-шайб?

                  Используется своя модель вместо готовых full body tracking-совместимых аватаров для того же vrchat'а? Опять же, для повышенной точности без всяких dynamic bone?
                    0
                    Данные «шайбы» чисто оптические девайсы. Уверен, что их огромное количество в поле зрения камер — не оправдает данный подход. Именно поэтому существуют проекты по прямой и обратной кинематике с двумя подобными трекерами на ступнях, за счет ограничений физических человеческого тела (кстати я не вводил их — это существенно улучшит позиционирование).
                    Как минус вышеупомянутых устройств то, что из них нельзя забирать ускорения из конечностей и они обязательно должны быть видны камерам.
                      0
                      Они не в поле зрения камер, они и есть недокамеры (на деле — тупо набор IR-датчиков) + акселерометры (поэтому в какой-то степени работают даже если lighthouse слегка исчезнет из поля зрения) + софт.

                      Вроде как раньше поддерживалось до 16 штук (минус шлем и два контроллера = 13), потом подняли лимит до 64.
                        0
                        Очень даже может быть. Такой себе WiiMote с обзором 360/180, тогда понятно откуда такая цена.
                        Относительно точности — у меня сейчас в контроллерах стоит отправлять данные только если есть изменения около 1 градуса. Если понизить до десятитысячной единичного кватерниона — будет около 0.1 градуса, но в таком случае идет постоянная передача данных — Blender начинает «тупить».
                          0
                          Такая цена диктуется исключительно рынком. На деле весь lighthouse — набор IR-диодов (делает вспышку), 1 IR лазер с мотором (делает сканирование) и немного обвязки для управления этим. Совместимые девайсы, включая эти шайбы, тупо считают задержку между «вспышкой» и «сканированием» на IR-сенсорах (которых много тупо чтобы хоть несколько из них видели маяк). И это всё используется для компенсации дрифта акселерометров потому, что для собственно отслеживания 100Гц — мало.

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

                          Proof-of-concept DIY датчики (без акселерометров) давали ~2мм точность.
                            0
                            Такая цена диктуется исключительно рынком.

                            Наверно именно об этом мой пост. Как за недорого самому буквально «на коленке» можно собрать систему, которая может по точности быть не в 10 раз хуже чем Perception Neuron.
                    0
                    А не могли-бы вы поделится вашим скетчем реализующим 9ти осевой DMP интересно сравнить результаты с подобными датчиками BNO 055, mpu 6050 а также работу датчика с другими фильтрами.
                      +1
                      Вот клон моих изысканий. После допиливания коррекции я скрыл свой обновленный код. Возможно как наиграюсь и доделаю до «вменяемого» состояния открою для всех. Сейчас стыдно его показывать. Все таки я люблю Open Sourсe :)
                        0
                        Спасибо.
                          0
                          Не за что, там в коде несколько уловок математических, в личку пишите — если что ;)
                      0
                      Вдохновленный проектом Сhordata я тоже пробовал сделать костюм, правда, полностью проводной вариант на базе Raspberry Pi Zero W -> TCA9548a (Свич на 8 линий I2C) -> MPU9250 (по два на каждую линию I2C, эта микросхема позволяет). Соединительные провода и розетки телефонные RJ12. Крепление датчиков сделал с помощью эластичого бинта с пришитыми кусками липучки. Везде держалось нормально, только на груди иногда спозало. Суммано получается достаточно дешево — порядка 200 дол за костюм на 16 датчиков. Для эстетики можно бинт покрасить или заказать черный, т.к. телесного вида смотрится не очень.
                      Для Raspberry Pi наТорнадо(Питон) написал сервер управления (websocket) и передачи данных (UDP) и модуль сбора данных от датчиков и фильтрации данных (Madgwick Filter).
                      Через Wi-Fi подключался к ноуту с проектом на Unity 3D (клиенты websocket и UDP). Суммарная задержка получилась порядка 25-30 мс.
                      Картинки посмотреть можно здесь
                      Проблемы, которые заставили приостановить:
                      — Закрепить датчики достаточно сложно и долго.
                      — Калибровка датчиков зависит от многих факторов и требуется каждый раз при включении.
                      — Поскольку датчики отслеживают только изменения положения, то накапливаются ошибки, а настроить фильтр чтобы работал достаточно адекватно у меня не получилось.
                      Те же Chordata и Kat Loco не смогли пока все проблемы победить.
                      К сожалению, мой код сырой поэтому не стал выкладывать на GitHub, но если кому интересно могу поделится тем что есть.
                      В тоже время успехи видео систем таких как OpenPose, AlfaPose и т.д., которые позволяют получить 2D скелет с такими же задержками и без датчиков и связанных с ними проблем. Перевод 2D в 3D сейчас актуальная тема и уже есть ряд решений, например вот, которые позволяют это делать (с помощью нескольких камер, как кариант с помощью одной стерео камеры). Вот сейчас пробую с этой стороны к проблеме подойти.
                        0
                        Вот наверное поэтому и я не стал использовать фильтры. Мне наверно тупо не хватает мозгов понять что внутри них происходит.
                        Для варианта Kat Loco вообще расчеты не нужно, быстро не смог найти поищите историю одного японца который получил на одном акселерометре в WiiMote точность распознавания жестов под 95%.
                        P.S. Я от просмотра тремора конечностей на видео чуть не вырвал… А концепция интересная — да.
                          0
                          С фильтрами (Калмана и Маджика) не сложно, они просто сглаживают резкие скачки. Для их использования нет необходимости понимать, как они это делают. Но в целом система с IMU мне показалась сложной для повседневного использования.
                          По поводу использования WiiMote. Там, вроде как, не IMU, a инфракрастные датчики, т.е. принцип как у оптической мыши. Использование той или иной системы от назначения зависит.
                          Для full body tracking вот неплохой обзор. Для IMU видел, но не пробовал, только у XSens вроде адекватные, но дорогие системы.
                          +1
                          Инерциальные датчики очень быстрые и хорошо отслеживают изменение положения, но не само положение. Для этого нужны медленные, но точные оптические камеры. Только такая коммбинация даст хороший результат. К ней в итоге и пришли все производители VR-устройств. С телом все то же самое — только датчиков больше и задача в итоге сложнее.
                          Ну и фильтр Калмана или подбный обязателен для сведения всех сенсоров.

                          Пытаться делать на встроенном фильтре DMP — это ИМХО вообще тупик. Фильтр не учитывает специфику задачи, он скорее для умных устройств подходит.
                            0
                            Технически, ещё живы VR-устройства без камер вообще и та же htc говорит, что не собирается сворачивать линейку lighthouse-девайсов.
                              0
                              Относительно камер чуть выше написал. Мое мнение что будущее все таки за IMU + оптические сенсоры, упомянутые в моем комментарии.
                                0
                                Lighthouse классная вещь. Но смысл такой же, только не камера видит сенсор, а сенсор видит излучающий сканирующий луч с базовых станций. Как и с камерами, будут сложности с затенением датчиков, т.е. нужно много базовых станций размещать и много датчиков на каждом узле. На VR-шлеме их достатончо много, например.
                                  0
                                  Я кстати уже подумываю дополнить. Есть пара камер которые могут 1080p с 30 FPS. Мне ведь нужно понимать перемещения (думаю будет лучше если связать камеры и акселерометр) + компенсировать повороты по оси Z (так как все равно плывут) + сделать ограничения как у человека.
                                    0
                                    Камера дает текущую позицию всех датчиков в своей проекции, нужно как минимум две камеры для триангуляции. Для референсной ориентации нужно использовать информацию с двух сенсоров на кости, но это не дает кватернион, а дает только два степени свободы из трех. В общем, задачка еще та. Много нужно достраивать в условиях нехватки информации.
                                      0
                                      Поэтому и написал
                                      Есть пара камер
                                        0
                                        Если использовать полноценные камеры то вместо точечных источников света можно использовать линейные — т.е. полоска, а еще помним камеры цветные, это значит можно использовать цвет и переходы, вот уже не только угол но и направление.

                                        Т.е. достаточно на кисти рук закрепитьполоску с градиентом перехода от одного цвета к другому (это будет идентификатор и направление) то две камеры смогут дать достаточную информацию о положении кисти руки

                                        но к сожалению не существует доступного железа чтобы проделывать эти вычисления в реальном времени хотя бы со скоростью обработки видеокадров в 30fps, от силы десяток для 720HD на мощном процессоре с видеоускорением.
                                          0
                                          habr.com/ru/company/cognitivepilot/blog/497098

                                          У них все крутиться на NVIDIA TX2
                                            0
                                            Там 2мбит камера и порядка 10 кадров в секунду, но да, проект впечатляющий.

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

                                            Я говорил о железе, в который можно подать сырой поток с CMOS чипа камеры прямо в память процессора или даже видеопроцессора.

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

                            Самое читаемое