30.03.2016 13:25
ObelardO 82 10500 Источник


Предисловие


В своем небольшом городе я занимаюсь решением нетривиальных технических задач. Так и в этот раз, организаторы одного шоу, в котором должна была выступить гимнастка со своей программой, решили добавить в ее представление некоторую «изюминку». А именно, выводить на экраны силуэт гимнастки, который бы повторял ее движения и как-то взаимодействовал с прочими эффектами, да так, чтобы все было интерактивно. Решить задачу «в лоб» не удалось. Kinect явно не справлялся со своей задачей и не был способен произвести захват движений человека, который удален от него на расстояние минимум 10 метров, к тому же в темноте. Так было принято решение сделать что-то «свое». Забегая вперед, скажу что выступление так и не состоялось, однако я настолько загорелся идеей, что продолжил свои эксперименты в качестве отдельного проекта, который впоследствии получил название impulse.

Начало работы




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

  • Arduino UNO — всем известный контроллер-конструктор, который позволяет за короткое время разработать прототип.
  • HC-06 — bluetooth модуль, послужит как средство беспроводной коммуникации. Модуль очень простой, имеет UART-интерфейс.
  • MPU-6050 — единственные доступные для меня инерционные датчики на тот момент. Приобрел сразу 2, чтобы проверить как они работают в паре, ведь в будущем необходимо использовать до 15 датчиков в одной системе. Этот сенсор сочетает в себе акселерометр и гироскоп, а так же датчик температуры для корректировки выходных данных.

Получив все из этого списка мне уже не терпелось увидеть mpu в действии. На официальном форуме Arduino присутствовали несколько примеров использования этих датчиков, один из них я и использовал. Для подключения сенсоров используется 5 пинов (контактов):

  • VCC, GND — тут все понятно, питание и земля. Стоит отметить что рабочее напряжение сенсора 3.3v, но и на 5v он чувствует себя неплохо. Потребляемая мощность меньше 0.05Ah
  • SCL, SDA — собственно пины, по которым происходит «общение» с сенсором. Эти пины отвечает за интерфейс i2c. Этот интерфейс реализует коммутацию между устройствами на одной шине, другими словами шина — это улица, а дома на ней — устройства.
  • INT — пин для прерываний. Как только данные на сенсоре готовы, главный контролер забирает их по прерыванию.

Однако этот пример выводил в терминал только «сырые» значения с акселерометра, и для преобразования в привычные углы был написан код, а далее и реализован Фильтр Калмана, и все это вместе занимало уже порядка 70% ресурсов Arduino UNO. Тем не менее, в терминал уже приходили довольно плавные значения углов, устройство довольно шустро ориентировалось в пространстве, правда всего пару минут, после чего FIFO буфер переполнялся. Но Оно работало!



Стабилизируем!


Постепенно радость от рабочего датчика омрачалась продолжительностью работы всей системы. Сколько я не боролся с FIFO-буфером, он переполнялся. Тут стоит отметить что информации на то время о данных сенсорах и вообще подобных системах было мало, и ее приходилось собирать буквально по крупицам. Решив, что проблема кроется в реализации интерфейса i2c начал гуглить в этом направлении и нашел пользовательскую библиотеку I2Cdev, призванную заменить стандартную библиотеку wire для arduino. Приятным сюрпризом оказались вложенные примеры использования этой библиотеки в связке с mpu-6050. Перестроив проект на этой библиотеке, я так же получал сырые данные и преобразовывал их в углы своим кодом, но никаких переполнений уже не было. Эта была маленькая победа. В дальнейшем, изучая внутренности библиотеки я обнаружил много полезного. Так например, теперь используются данные с обоих сенсоров — и акселерометра и гироскопа. Дело в том, что акселерометр позволяет определять точные углы наклона прибора только в состоянии покоя, пока на него не действуют внешние силы, а компенсировать эти самые силы призван гироскоп. Очевидным стало использование данных с обоих сенсоров, и тут нашел применение комплементарный фильтр. Однако появилась проблема нулевого дрейфа, но об этом позже.

Больше сенсоров!


И вновь подводный камень. На этот раз проблема, которая предстала передо мной, заключалась в использовании второго датчика mpu-6050. Я уже приводил аналогию i2c интерфейса в этой статье, где шина — это улица, а устройства — дома. Представим что пакет данных, которые должны добраться до определенного устройства — это почтальон. Почтальону необходимо 2 вещи — посылка и адрес, и у каждого дома есть свой уникальный адрес, так и у устройств должны быть свои адреса. Проблема заключается именно в адресе датчика mpu-6050, он один на все такие датчики — 0x68. Этот адрес прошивается в контроллер датчика еще на заводе, а найти прошивку и изменить адрес для каждого датчика не представляется возможным. Забугорные форумы выдали один вариант решения — подключение сенсоров друг за другом, одна нога первого сенсора подключается к пину AD0 второго, и становится доступным по адресу 0x69, но такой способ предполагает использование не более 2 mpu и я сразу его отбросил.

Решением стали транзисторы. Идея заключалась в том, чтобы перед каждым датчиком поставить по паре транзисторов на пины i2c и открывать их поочередно. Алгоритм простой — необходимо считать данные с 5-го датчика, закрываем все гейты кроме 5-го (или открываем его при необходимости) и производим считывание, дальше подобным образом получаем данные с остальных. Результат видно на первом фото в этой статье, и он вполне себе работоспособный. Подобным образом мне удалось подключить 4 датчика, это не лучшим образом повлияло на стабильность, а когда у меня закончились транзисторы я решил использовать более компактные и стабильные микросхемы.

схема подключения
image

Единственное сохранившееся фото с той стадии (извиняюсь за качество):



Гейт-контроллер


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

с пылу с жару






Теперь остается проверить устройство в действии. Подключив сразу 10 датчиков, в мониторе появилось ровно столько же приятных сообщений об успешной инициализации — устройство работает!



Гимбл лок, кватернионы, визуализация


Гимбл лок, по-русски шарнирный замок или же складывание рамок — неприятное явление в области гироскопов и в некоторых случаях ориентирования в пространстве. Без долгого объяснения этого явления (есть хорошо объясняющие и наглядные видео на эту тему) я лишь скажу, что этот самый шарнирный замок не позволяет вертеть сенсором на все 360. Оси X Z (отклонения от горизонтальной плоскости) ограниченны примерно от -45 до 45 градусов, и не определяются корректно за этими пределами. Подробнее изучив эту тему, оказалось что решение находится у меня под носом. MPU-6050 это шестиосевые датчики, и на борту у них присутствует dmp. Dmp (DIgital Motion Processor) занимается всем тем, что я так долго писал в основном коде для прошивки главного контроллера, и даже фильтрует значения. К тому же, dmp может выводить данные в виде кватернионов, что позволяет обойти шарнирный замок, а так же это позволяет уменьшить размер пересылаемых пакетов. На этом моменте продолжилось мое знакомство с кватернионами, ранее я работал с ними в Unity3D и имел какое-то представление. Говоря простым языком, кватернион — это система чисел (4 числа) которая описывает поворот чего-либо в пространстве. Как раз вспомнив про Unity, я попробовал изобразить нечто такое:



Контроллер


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



Корпус


Устройство постепенно обретало свой финальный вид, и следующим шагом было логично сделать корпус. Очевидное решение — это заказать или обратиться к услугам 3D-печати. Но это все просто и неинтересно, поэтому на пару c другом приобрели свой собственный 3D-принтер. Ввиду отсутствия любой инструкции собирали его на интуитивном уровне, но все получилось. Вообще сборка, настройка, и сама подготовка к печати заслуживают отдельной статьи, но сейчас не об этом. Использовав весь пробный материал, оставалось только ждать пока придет ABS-пластик.

3D Принтер




Для моделирования была выбрана программа 123D-Design. Программа интуитивно понятна, и любой, кто хоть немного имеет опыт работы в редакторах трехмерной графики быстро ее освоит.



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







Софт


Ввиду некоторых обстоятельств, я отложил Unity3D «на потом», сроки поджимали и нужно было быстро написать программу для визуализации. Я уже давно работаю с графическим движком Xors3D (Может кто знает такой) и на этот раз он меня не подвел. Однако после того как он себя оправдал, я не вернулся к Unity, а продолжил разработку визуальной среды для костюма именно на этом движке.



Список текущих возможностей:

  • Визуализация — в программе отображается модель человека, которая в реальном времени повторяет все движения за человеком в костюме
  • Авто-калибровка — позволяет в любое время моментально калибровать костюм
  • Позиционирование — модель так же перемещается в пространстве как и человек, может приседать, ходить и т.п.
  • Запись/воспроизведение — все движения можно записывать и воспроизводить
  • Режим взгляда от первого лица — предусмотрен вывод изображения для oculus rift и других шлемов виртуальной реальности.
  • Интерактивность — человек носящий костюм может воздействовать на виртуальный мир. Пинать мячи, открывать двери, крутить карусель и т.д. (физический движек)

Заключение


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

Когда я начинал, был только интерес «а как это работает?» и о существовании подобных костюмов я еще не знал. Однако за время разработки как минимум 3 подобных проекта вышли на краудфандинговые площадки, и мне захотелось как-то развить impulse в качестве коммерческого проекта, но крайне тяжело заявить о себе сидя в Забайкальском крае. Сейчас не хватает мотивации сесть за второй прототип, уже беспроводной и на базе 9-ти осевых сенсоров, так что скорее всего этот проект останется для меня просто огромным и полезным опытом. В этой статье я хотел резюмировать всю проведенную работу, правда тут не отображено и 20% от нее. Не всем будут интересны тонны кода и часы пайки, 3d-печати, множество проб и ошибок, куча израсходованного материала, однако я постараюсь ответить на подобные вопросы в комментариях.

Комментарии (82)


  1. sillywilly
    30.03.2016 17:10
    #9141864
    +1

    Классно. Желаю вам удачи. Есть ориентировочная цена-то?


    1. ObelardO
      30.03.2016 18:38
      #9142062
      +3

      Спасибо! себестоимость 150$


  1. Firelander
    30.03.2016 17:15
    #9141886
    +2

    Крутой результат для сделанного практически "на коленке" прототипа. Мне трудно поверить, что одних только датчиков угловых положений достаточно для довольно-таки неплохого захвата движений. Не думаете переходить на более производительную платформу? Какие-нибудь Cortex-M3/M4 подошли бы идеально для вашей задачи, так как ардуина инерциалку хоть переваривает, но на пределе своих возможностей.


    1. ObelardO
      30.03.2016 18:48
      #9142136

      Спасибо! Да что кривить, действительно на коленке.
      Не только угловые ускорения учитываются, акселерометр и гироскоп работают вместе, компенсирую друг-друга.
      Необходимости в более производительной платформе пока нет, Atmega328 имеет достаточный ресурс, чтобы опрашивать 11 датчиков 50 раз в секунду и все это отсылать (контроллер практически ничего не вычислят, только переключается и отсылает данные, большую работу на себя берет dmp каждого датчика и софт на стороне приемника).


  1. Fabian_red
    30.03.2016 17:41
    #9141934
    +1

    "Однако появилась проблема нулевого дрейфа, но об этом позже."
    А можно чуть подробней?


    1. ObelardO
      30.03.2016 18:52
      #9142148
      +1

      Забыл раскрыть этот нюанс. Если коротко, то вертикальной оси Y не за что "заякориться", так горизонтальные оси отталкиваются от вектора гравитации, а ось Y ему сонаправленна. Вычисления угла по оси Y вычисляются программно, на основе осей X Z, а вот в 9-ти осевых датчиках (mpu9xxx) добавлен магнитометр, который встроен и сразу компенсирует дрейфы.


      1. ObelardO
        30.03.2016 19:19
        #9142238

        Угол по оси Y вычисляются программно*


        1. Rumlin
          31.03.2016 14:29
          #9144120

          А по поводу

          организаторы одного шоу, в котором должна была выступить гимнастка со своей программой, решили добавить в ее представление некоторую «изюминку»

          • выступила?
            Честно говоря в конце статьи ожидал видео выступления гимнастки.


          1. diller61
            31.03.2016 14:43
            #9144162

            Забегая вперед, скажу что выступление так и не состоялось,


    1. FokkerFace
      30.03.2016 19:15
      #9142230

      мимо


  1. riv_shiell
    30.03.2016 18:40
    #9142076
    +2

    А можно поделиться кодом для фильтра Калмана к ардуине? Или самой математикой под него?


    1. ObelardO
      30.03.2016 18:55
      #9142160
      +1

      Фильтр калмана отпал за ненадобностью, датчики из коробки умеют комплементарный фильтр и dmp. Разве что можно использовать вторичную фильтрацию уже на приемнике.


      1. riv_shiell
        30.03.2016 19:07
        #9142200
        +2

        А может всё таки остались наброски для фильтра с самой математикой?..
        з.ы. Сам пытался, но никак не выходило составить коэффициент Калмана


        1. ObelardO
          30.03.2016 19:22
          #9142250

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


  1. Watcover3396
    30.03.2016 18:41
    #9142080
    +6

    «Не всем будут интересны тонны кода и часы пайки, 3d-печати, множество проб и ошибок, куча израсходованного материала, однако я постараюсь ответить на подобные вопросы в комментариях.»
    По-моему, как раз таки многие сюда за этим и приходят, например мне всегда были интересны статьи с тонной описания технических/софтварных деталей.
    Кстати из-за подобных статей и стал читать Хабрахабр в 2012 году, а потом еще и Geektimes.


    1. ObelardO
      30.03.2016 18:57
      #9142170
      +2

      Мне кажется такой Хабр как раз и закончился в 2012 году… Я постараюсь отвечать на конкретно интересующие вопросы, в статью вынес более общие моменты, хотя и не обошлось без ухода в подробности.


      1. TIGER535
        31.03.2016 11:10
        #9143530

        так давайте возвращать «такой» Хабр


      1. diller61
        31.03.2016 12:45
        #9143840

        вероятно по той причине что авторы не выкладывают эти материалы, по всей видимости считая их коммерческой тайной что ли


  1. Dolbe
    30.03.2016 18:42
    #9142102

    Очень интересная тема!
    Скажите пожалуйста, как вы решили проблему нулевого дрейфа?
    Есть одна, более важная, на мой взгляд, проблема, с которой я столкнулся при работе с MPU-6050 (да вообще с любым сенсором, сочетающим в себе акселерометр и гироскоп). Проблема состоит в том, что акселерометр изначально не знает, повернут ли он «головой» (ось Z) вверх или вниз. Как вы ее решили?


    1. ObelardO
      30.03.2016 19:09
      #9142202

      Спасибо!
      С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.
      На счет второй проблемы — она куда проще дрейфов, ее я решил в голове еще за долго до того, как она предстала передо мной. Для начала, в 3D модели соответствующая кость должна иметь якорь, который повернут так же, как реальный датчик (например на ноге он закреплен вертикально, так и на модели якорь повернут вертикально, так же со всеми осями) Далее когда начинается трекинг, мы получаем значения с сенсоров, берем разницу между полученными углами с сенсора и углами кости 3D-модели и вычитаем ее из каждого полученного значения. Проще говоря — мы знаем что в самом начале нога должна быть повернута на 0 градусов, а с датчика пришло 45 — то мы запоминаем 45 и вычитаем их из каждого следующего значения. Есть нюанс с поворотом между 180 и -179 градусов, он тоже решаем.


      1. ProLimit
        30.03.2016 20:09
        #9142378

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


        1. ObelardO
          30.03.2016 20:44
          #9142464

          Соглашусь, однако 9-ти осевые сенсоры все же имеют механизмы для борьбы с дрейфом.


      1. Dolbe
        30.03.2016 20:24
        #9142408

        Да, такой метод компенсации я тоже сразу попробовал.
        Датчики с магнитометром очень хорошо подходят для того, чтобы уменьшать дрейф. Подумываю приобрести и попробовать. У меня в очень сыром варианте сбора данных, если резко трясти датчиком перпендикулярно вектору гравитации, то он очень легко сбивается направление по Z (что и вызвано этим самым дрейфом).
        Вторая проблема остается проблемой, потому что при инициализации каждый датчик должен находиться в каком-то положении с не очень большой погрешностью.
        А по поводу Вашего гейт-контроллера — частоту опроса датчиков не сильно уменьшает? Сколько датчиков потянет с необходимой частотой опроса? Может есть смысл посмотреть в сторону MPU-6000? Это тоже самое, только он умеет SPI, а туда, вроде, можно подключить больше датчиков без особых проблем со скоростью опроса, насколько мне известно.
        Еще вопрос: Так как Вы включили DMP на датчиках, Ардуино служит просто для сбора значений со всех датчиков и отправки их на компьютер? Вы каким-то обрахом дополнительно обрабатываете эти данные потом на компьютере?


        1. ObelardO
          30.03.2016 20:55
          #9142476

          Практически не уменьшает. Пробовал 11 датчиков на частоте 50гц — нормально себя чувствуют, сейчас частота чуть пониже, т.к. даже 1 датчик подключенный напрямую на высоких частотах ведет себя недостаточно стабильно.
          С SPI так же были эксперименты, но далеко они не зашли (6050 не подходят, как Вы верно заметили нужны 6000, но я не видел подобных сборок в природе). Вообще на практике провода между датчиками оказались неудобными, так что сейчас курс в сторону wifi или bt.
          DMP при инициализации получает код от Atmega328 (все же от Arduino там только она и есть) это по-большому счету конфигурация, которую я подстраивал для оптимальной работы множества датчиков. По большому счету верно, контроллер служит только для коммутации всех датчиков, запаковки и отправки данных на компьютер. Вся математика перенесена на компьютер, это позволяет разгрузить контроллер, чтобы бы тот справлялся с частотой и количеством опрашиваемых датчиков.


          1. Dolbe
            31.03.2016 09:03
            #9143226

            Правильно я все-таки понял, что при первом запуске/калибровке необходимо, чтобы датчики находились на "своих положениях" относительно вектора гравитации и ни в коем случае не перевернуты? Или вы во время движения определяете валидность данных, зная ограничения углов костей и суставов?


            1. ObelardO
              31.03.2016 11:14
              #9143548

              При первом запуске нужно подождать 10 секунд для калибровки, далее человек принимают туже позу что и 3D-модель (будь то Т-поза или как в данном случае — руки по швам) и начинается трекинг. Датчики в основном повернуты вертикально.


  1. Anna_McFly
    30.03.2016 18:42
    #9142106

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


    1. ObelardO
      30.03.2016 19:11
      #9142216

      Спасибо!


  1. Snowtomcat
    30.03.2016 18:42
    #9142108
    +2

    Вот это интерес у человека! Провернуть, практически в одного, такое, над чем работают целые студии спецэффектов, это круто, просто жму руку и желаю дальнейших удач.
    Я считаю, что с такой движущей силой географическое положение не имеет значения — надо выходить на рынок, особенно в свете начинающегося бума 3D-очков (Oculus Rift etc.)


    1. ObelardO
      30.03.2016 19:14
      #9142224
      +1

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


      1. no1D
        30.03.2016 19:27
        #9142264

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


        1. ObelardO
          30.03.2016 19:46
          #9142316

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


          1. no1D
            30.03.2016 20:20
            #9142396

            По третьей ссылке в выдаче гугла по запросу BVH пример лежит в каком виде данные организуются, я признаться ни разу не программист, в прошлом тридешник, как я понимаю формат чисто текстовый и описывает сначала иерархию, а потом сдвиг и вращение корня скелета и каждого джоинта скелета во времени, затем собственно фреймрейт захвата и данные по корню и каждому джоинту в виде строки, новая строка — новый кадр. В вашем случае нужно сначала вращение и сдвиг датчиков интерпретировать в вращение и сдвиг джоинтов скелета, а потом их тупо записать, тут разве что расстояние между датчиками (длину конечностей) может понадобиться вводить, не знаю как у вас калибровка реализована и учитывает ли она это. В общем то даже если экспорт не делать, чтобы к игровому движку прицепить захват движения всё равно нужно чтобы был связный скелет на выходе, возможно даже с кинематикой, а не отдельно болтающиеся кости. ЗЫ: устали — открывайте исходники) норот я думаю подтянется допиливать, на кикстартере полно проектов подобных, но цены негуманные, и закрытое всё. А можно сделать ход конем и запилить что то совместимое с YEI 3-Space например (тоже ценник огого, но открытые исходники), или какие там ещё есть проекты подобные, кстати можете вкратце в комментариях отписать что и чем от вашего проекта отличается?


            1. ObelardO
              30.03.2016 21:11
              #9142522

              Посмотрел бегло что такое BVH — думаю разберусь, при необходимости. Но пока это только вопрос конвертирования моего типа хранения анимации. И тут уже кому как удобнее, тот с тем форматом и работает, сделаю я BVH, как тут же набегут те, кому подавай все тоже самое в FBX. Ни к чему распыляться на такие вещи, на мой взгляд, это уход в сторону от основной цели, я все же физически не смогу угодить всем.
              Открывать исходники — это если уж если костюм совсем в шкафу залежится.
              На счет подобных проектов — да много их уже, и расписывать о них стоит в отдельной статье, но все они отличаются друг от друга ровно как нынешние шлемы виртуальной реальности.
              Сейчас я вообще сомневаюсь в жизнеспособности всей это надувной "vR революции", имхо все угомонятся как с 3D телевизорами.


              1. no1D
                31.03.2016 12:28
                #9143800

                Я в игры практически не играю, VR не слишком интересуюсь, мне ваш проект интересен с точки зрения как раз таки захвата движения для анимации и кино. Форматов действительно куча, просто BVH — один из самых примитивных, он почти везде поддерживается, в случае чего можно конвертировать во всё что угодно уже в 3д редакторе, FBX это всё же формат для 3д моделей в общем, а не конкретно скелетной анимации. От статьи про мокап костюмы не отказался бы, тем более от человека в теме.


                1. ObelardO
                  31.03.2016 18:44
                  #9144780

                  Хорошо, я возьму на примету этот формат.
                  Да вообще толковую статью про мокап можно сделать, но это как время будет.


                  1. no1D
                    31.03.2016 21:46
                    #9145274
                    +1

                    Подписался на вас, буду ждать новостей. Успехов с проектом!


      1. FokkerFace
        30.03.2016 19:34
        #9142284

        Я не совсем понял что вы имеете в виду под «движухой», но сейчас самый пик для стартапов по теме VR — первые партии Oculus Rift уже отправлены покупателям, и скоро они захотят «расширить функционал», full-body трэкинг для VR это то чего «в коробке» не предлагает ни Oculus, ни HTC, ни Sony. Есть целевая аудитория, а у вас практически есть решение в железе, с чётким осознанием что осталось доделать.
        Во первых, на вашем месте, я бы отправил короткую презентацию вашего проекта в Oculus и HTC с просьбой предоставить дев-кит их очков, для помощи в разработке и тестировании. За «спросить» денег не берут, а вы можете как получить неплохой гаджет (и тем самым оживить собственный интерес к теме) так и получить предложение работы.
        Во вторых серьёзней оцените возможность запуска стартапа на кикстартере. Я могу ошибаться, но мне кажется в вашем костюме бюджет всего железа — до 50ти баксов. За $99 баксов вы пару сотен таких китов точно продадите, пощупаете рынок, получите неплохой капитал для продолжения самостоятельной работы.


        1. ObelardO
          30.03.2016 19:53
          #9142328
          +1

          Верно, среда благоприятная и уже есть несколько стартапов на том же кикстартере с full-body системами, некоторые из них совершеннее мой поделки. На кикстартер выходов у меня нет, а то что те же Oculus откликнуться — слабо верится. Себестоимость 150$, может чуть поменьше.


  1. Mistx
    30.03.2016 19:21
    #9142242

    Судя по всему, вам пора кооперироваться с производителями очков и игроделами. Интересные MMO проекты можно сделать…


    1. ObelardO
      30.03.2016 19:31
      #9142280

      Я открыт для любых предложений :)


      1. Eugeny1987
        31.03.2016 11:15
        #9143554

        Можете создать такой же костюм для захвата движения всего человека?


        1. ObelardO
          31.03.2016 11:19
          #9143566

          Могу. Сейчас используются только 11 датчиков, устройство рассчитано на 15 (кисти и стопы не отслеживаются). Остаются только пальцы, сгибы которых можно определять с помощью специальных перчаток, или тем же Leap3D.


          1. Eugeny1987
            31.03.2016 11:20
            #9143574

            Получить бы что-то такое, только по-бюджетнее
            https://neuronmocap.com/content/product/32-neuron-alum-edition


            1. ObelardO
              31.03.2016 11:41
              #9143660

              Это как раз один из тех проектов, которые вылезли за период разработки. Имхо не стоит он своих денег, хотя использованы 32 датчика. Из них 16 только на кисти рук — это я считаю избыточность.
              Пока только отличие в количестве сенсоров, 15 против 32. Ну красиво все у них, да.


              1. Eugeny1987
                31.03.2016 12:31
                #9143810

                вот на хабре про них https://habrahabr.ru/post/236423/
                в период их "кикстартерства" они говорили что цены поднимутся в пределах 40%, но в реале увидели, почти 300 %


                1. ObelardO
                  31.03.2016 18:47
                  #9144788

                  Пока это выглядит невероятным, покупать приставку за 450$ (или апгрейдить пк) затем шлем за ~450$, а потом еще и такой костюм за 1.5K$. Сомнительное это все удовольствие.


                  1. Eugeny1987
                    31.03.2016 18:49
                    #9144798

                    мне только костюм нужен, с программой в которой работа с костюмом ведется


  1. Ta10s
    30.03.2016 19:23
    #9142254

    Расскажите, как победили дрейф нуля у гироскопов на длительных периодах (2+ часа) без использования дополнительных магнитных датчиков?


    1. ObelardO
      30.03.2016 19:27
      #9142262

      С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.

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


      1. Rumlin
        31.03.2016 14:34
        #9144134

        По поводу "не такие стабильные значения" — посмотрите осциллографом напряжение питания. Скорее всего нестабильность питания и можно устранить припаяв дополнительные конденсаторы по питанию.


        1. ObelardO
          31.03.2016 18:47
          #9144792

          Верное замечание. На каждом сенсоре предусмотрен конденсатор на питании.


          1. Rumlin
            31.03.2016 19:47
            #9144948

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


  1. Tirarex
    30.03.2016 19:27
    #9142268

    Молодец, глянул ранее на булке, классный проект!
    Не думал о Esp8266 и передачи данных по wifi?


    1. ObelardO
      30.03.2016 19:30
      #9142278

      Спасибо! Я как раз видел на ютубе твои эксперименты с Esp8266.
      Конечно думал, уже лежит 12-версии и 1 9-ти осевой сенсор, если подружу их — то вообще здорово, будет множество автономных сенсоров, независимых друг от друга, в этом и заключается идея второго прототипа. Если подружить не получиться, наверное буду использовать контроллеры для связи между mpu и esp, а esp будет как uart-wifi транслятор.


  1. Mr_Destiny
    30.03.2016 19:30
    #9142276

    Во-первых, хочу выразить свое восхищение — рабочий, красиво выглядящий (!!) прототип за пол года — потрясающе.

    Кроме того хочу спросить пару технических деталей:
    1) Что в итоге отдает датчик движения, что с этим делает центральный контроллер, и что получает комп. На особых подробностях не настаиваю, но буду признателен :)
    2) Я погуглил по дмп и MPU-6050, и как-то там глухо — если можете, поделитесь информацией как оно работает (ну или где почитать, можно на англ). Вообще, техническая статья про то как из датчика-акселерометра получается кватернионы, я думаю, будет принята с признательностью не одним мной
    3) На компе, вы как-то заботитесь о том чтобы «человечек» стыковался как следует, или углы настолько хорошо определяются что можно просто поворачивать палочки-руки/ноги? Кватернионы — это тупо вращения, а вокруг чего вращать то? Хотя если MPU передает скорость, то тогда все проще. В общем, если не затруднит, расскажите по-подробней как сырые данные переходят в человечка.


    1. ObelardO
      30.03.2016 19:42
      #9142304

      Большое спасибо!
      1) После всех манипуляций и конфигураций dmp, сенсоры отдают свои углы в пространстве в виде кватерниона. Это dmp умеет "из коробки" и позволяет не заботиться о шарнирном замке. Центральный контроллер поочередно получает данные с каждого сенсора, запаковывает это все и отправляет по bluetooth на приемник много раз в секунду, никаких вычислений практически не производит.
      2) В том-то и дело, информации мало. Это только в последнее время что-то появляется, за счет моды на DIY квадрокоптеры и прочее. В первую очередь много полезного нашел на . А так же тут
      3) На компе много о чем приходиться заботиться, т.к. по факту имеем только углы поворота всех сенсоров. Трекинг в пространстве сделан программно (пока не идеален, нужны сенсоры на стопы)
      MPU передают только углы в виде кватерниона, все остальное уже на стороне приемника.


      1. Mr_Destiny
        30.03.2016 19:51
        #9142320

        Ваши ссылки не отобразились :(

        Да, я заметил что он ногами проскальзывает (и, я так понимаю, прыгать не умеет?)

        Мм, я тут посмотрел, есть штука https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/MPU6050.h
        И в этой штуке есть функции типа «GetAccel...» Оно скорее всего не проходит через DMP и требует фильтрации, да и вообще не понятно, но наверно лучше чем ничего?


        1. ObelardO
          30.03.2016 20:01
          #9142348

          www.i2cdevlib.com
          www.geekmomprojects.com/mpu-6050-redux-dmp-data-fusion-vs-complementary-filter
          Из-за отсутствия датчиков на стопах (используются 11 из 15). Прыгать умеет, но перемещается только в плоскости.
          В правильном направлении идете, все верно. Но там же есть и dmpGetAccel :)


          1. Mr_Destiny
            30.03.2016 20:05
            #9142364

            Понятно, спасибо. Будем посмотреть.

            Всяческих вам успехов с доработкой!


            1. ObelardO
              30.03.2016 20:31
              #9142434

              Благодарю!


            1. mahowik
              04.04.2016 04:13
              #9150776

              Посмотрите этот скетч https://github.com/JJulio/b-robot/blob/master/B_ROBOT/B_ROBOT.ino
              У Жозе Жулио обычно рабочие вещи…


  1. SuperFamicom
    30.03.2016 19:43
    #9142306

    Привет! Я тоже был на НТТМе. У меня есть несколько вопросов. Напиши мне в вк: vk.com/tvisf


    1. ObelardO
      30.03.2016 19:43
      #9142310

      Рад видеть земляка, отписал.


  1. AkimovUriy
    30.03.2016 20:24
    #9142410

    М… Да…
    Мы когда то в конторе пытались реализовать нечто подобное, но увы… Побоялись сложности проекта (12 человек) а Вы в одиночку потянули проект и в принципе у Вас готовый прототип для первого релиза. Не останавливайтесь не в коем случае. Это уже готовый проект для монетизации.
    Сделайте последний шаг. Я даже скинул эту статью паре серьезных контор за бугром. Может заинтересуются.
    Еще раз повторюсь, Я в шоке.


    1. ObelardO
      30.03.2016 20:30
      #9142432

      Спасибо за отзыв! В особенности за распространение.
      В данном случае моя одержимость идеей переборола страхи, хотя бывали моменты когда "ну совсем ничего не получалось", без этого никуда.
      Я как раз таки остановился, ибо слабо представляю что делать дальше, о каком последнем шаге идет речь?
      Еще раз спасибо :)


  1. reji
    30.03.2016 20:29
    #9142426

    К этому добавить шлем VR, беговой шар, и можно играть в ММО игры на выносливость :)


    1. ObelardO
      30.03.2016 20:31
      #9142436

      Беговой шар не обязателен, если есть открытая местность)


  1. HOMPAIN
    30.03.2016 21:13
    #9142530

    Для подключения большого числа датчиков удобно использовать 16 канальный(для 15 датчиков) мультиплексор/демультиплексор. На нём вы 4 пинами задаёте двоичное число(номер датчика) и он соединяет пин от нужного датчика с управляющим пином. Цена такой микросхемки 30р и она заменяет вашу сложную схему с кучей транзисторов.
    Также вы рвёте все пины от датчиков(как я понял по схеме), а достаточно разорвать только пин, по которому от него приходит ответ.
    Ещё вместо i2c лучше использовать spi интерфейс. I2c гораздо медленнее и в arduino он реализован программно.


    1. ObelardO
      30.03.2016 21:23
      #9142550

      Использование транзисторов — это лишь пробный период, внимательнее прочитайте раздел статьи "Контроллер".
      В данном случае с I2C приходится рвать 2 пина.
      Стандартная библиотека wire действительно не отличается скоростью, поэтому я использовал стороннюю i2cdevlib. Spi интерфейс не предусмотрен на mpu6050, и насколько мне известно проблема c адресами сохраняется.


  1. mikkab
    31.03.2016 07:48
    #9143126

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


    1. ObelardO
      31.03.2016 07:51
      #9143128

      Спасибо! Думал над этим, есть 3 но: 1 — дрейфы у датчиков могут быть разными, и на входе будет дрейф в эту разницу. 2 — совершенно не факт, что сенсоры будут дрейфовать в разные стороны, у меня они начали вертеться в одну. 3 — стоимость примерно в 2 раза выше.


      1. Dolbe
        31.03.2016 08:56
        #9143212

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


        1. ObelardO
          31.03.2016 11:26
          #9143610

          Думаю можно попробовать, спасибо.


  1. senator14
    31.03.2016 10:36
    #9143424
    +1

    Это просто шедеврально! Можем обменяться контактами для обсуждения вашего проекта?


    1. ObelardO
      31.03.2016 11:21
      #9143578

      Спасибо!
      Ну разумеется. Моя почта указанна в видео.


  1. GolAlexey
    31.03.2016 11:22
    #9143580
    +2

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


    1. ObelardO
      31.03.2016 11:24
      #9143592

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


      1. Eugeny1987
        31.03.2016 12:35
        #9143818

        Я буду за ))


  1. it2manager
    31.03.2016 13:12
    #9143938

    … Напиши мне на почту свои контакты, попробуем свести тебя с нужными людьми. s2sa@rambler.ru


  1. SvSh123
    31.03.2016 16:48
    #9144510

    Осталось добавить сенсорные перчатки:
    https://geektimes.ru/post/258608/
    :)
    Превосходно! Сделать такое на ардуинке...


    1. ObelardO
      31.03.2016 18:52
      #9144808

      Бюджетный вариант резистора сгиба, занятно) Я уже присмотрел этот способ для пальцев, хотя есть и готовые решения в виде перчаток.Уже выше писал что только их и не хватает)
      Спасибо! В конечном счете все же не на ардуине, как никак свой контроллер получился.