Как я делал костюм захвата движений



Предисловие


В своем небольшом городе я занимаюсь решением нетривиальных технических задач. Так и в этот раз, организаторы одного шоу, в котором должна была выступить гимнастка со своей программой, решили добавить в ее представление некоторую «изюминку». А именно, выводить на экраны силуэт гимнастки, который бы повторял ее движения и как-то взаимодействовал с прочими эффектами, да так, чтобы все было интерактивно. Решить задачу «в лоб» не удалось. 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-печати, множество проб и ошибок, куча израсходованного материала, однако я постараюсь ответить на подобные вопросы в комментариях.
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 83
  • +1
    Классно. Желаю вам удачи. Есть ориентировочная цена-то?
    • +3
      Спасибо! себестоимость 150$
    • +2
      Крутой результат для сделанного практически "на коленке" прототипа. Мне трудно поверить, что одних только датчиков угловых положений достаточно для довольно-таки неплохого захвата движений. Не думаете переходить на более производительную платформу? Какие-нибудь Cortex-M3/M4 подошли бы идеально для вашей задачи, так как ардуина инерциалку хоть переваривает, но на пределе своих возможностей.
      • 0
        Спасибо! Да что кривить, действительно на коленке.
        Не только угловые ускорения учитываются, акселерометр и гироскоп работают вместе, компенсирую друг-друга.
        Необходимости в более производительной платформе пока нет, Atmega328 имеет достаточный ресурс, чтобы опрашивать 11 датчиков 50 раз в секунду и все это отсылать (контроллер практически ничего не вычислят, только переключается и отсылает данные, большую работу на себя берет dmp каждого датчика и софт на стороне приемника).
      • +1
        "Однако появилась проблема нулевого дрейфа, но об этом позже."
        А можно чуть подробней?
        • +1
          Забыл раскрыть этот нюанс. Если коротко, то вертикальной оси Y не за что "заякориться", так горизонтальные оси отталкиваются от вектора гравитации, а ось Y ему сонаправленна. Вычисления угла по оси Y вычисляются программно, на основе осей X Z, а вот в 9-ти осевых датчиках (mpu9xxx) добавлен магнитометр, который встроен и сразу компенсирует дрейфы.
          • 0
            Угол по оси Y вычисляются программно*
            • 0
              А по поводу
              организаторы одного шоу, в котором должна была выступить гимнастка со своей программой, решили добавить в ее представление некоторую «изюминку»

              • выступила?
                Честно говоря в конце статьи ожидал видео выступления гимнастки.
              • 0
                Забегая вперед, скажу что выступление так и не состоялось,
          • 0
            мимо
          • +2
            А можно поделиться кодом для фильтра Калмана к ардуине? Или самой математикой под него?
            • +1
              Фильтр калмана отпал за ненадобностью, датчики из коробки умеют комплементарный фильтр и dmp. Разве что можно использовать вторичную фильтрацию уже на приемнике.
              • +2
                А может всё таки остались наброски для фильтра с самой математикой?..
                з.ы. Сам пытался, но никак не выходило составить коэффициент Калмана
                • 0
                  Конкретно с того периода исходники не остались, но я точно помню что пользовался статьей, где была реализация на Си, но это все на забугорных форумах)
            • +6
              «Не всем будут интересны тонны кода и часы пайки, 3d-печати, множество проб и ошибок, куча израсходованного материала, однако я постараюсь ответить на подобные вопросы в комментариях.»
              По-моему, как раз таки многие сюда за этим и приходят, например мне всегда были интересны статьи с тонной описания технических/софтварных деталей.
              Кстати из-за подобных статей и стал читать Хабрахабр в 2012 году, а потом еще и Geektimes.
              • +2
                Мне кажется такой Хабр как раз и закончился в 2012 году… Я постараюсь отвечать на конкретно интересующие вопросы, в статью вынес более общие моменты, хотя и не обошлось без ухода в подробности.
                • 0
                  так давайте возвращать «такой» Хабр
                  • 0
                    вероятно по той причине что авторы не выкладывают эти материалы, по всей видимости считая их коммерческой тайной что ли
                • 0
                  Очень интересная тема!
                  Скажите пожалуйста, как вы решили проблему нулевого дрейфа?
                  Есть одна, более важная, на мой взгляд, проблема, с которой я столкнулся при работе с MPU-6050 (да вообще с любым сенсором, сочетающим в себе акселерометр и гироскоп). Проблема состоит в том, что акселерометр изначально не знает, повернут ли он «головой» (ось Z) вверх или вниз. Как вы ее решили?
                  • 0
                    Спасибо!
                    С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.
                    На счет второй проблемы — она куда проще дрейфов, ее я решил в голове еще за долго до того, как она предстала передо мной. Для начала, в 3D модели соответствующая кость должна иметь якорь, который повернут так же, как реальный датчик (например на ноге он закреплен вертикально, так и на модели якорь повернут вертикально, так же со всеми осями) Далее когда начинается трекинг, мы получаем значения с сенсоров, берем разницу между полученными углами с сенсора и углами кости 3D-модели и вычитаем ее из каждого полученного значения. Проще говоря — мы знаем что в самом начале нога должна быть повернута на 0 градусов, а с датчика пришло 45 — то мы запоминаем 45 и вычитаем их из каждого следующего значения. Есть нюанс с поворотом между 180 и -179 градусов, он тоже решаем.
                    • 0
                      Не хочу вас расстраивать, но 9-ти осевым датчиком проблема тоже не решается, особенно в помещении — компасс крайне недостоверен, да и калибровать его нужно в реальном окружении, а не на заводе. В проф. системах учитываются все кинематические связи между датчиками, ограничения человеческого тела. Этим можно минимизировать дрейф (фактически усердняется десяток дрейфов) но не полностью убрать. Сильно помогает температурная компенсация или стабилизация.
                      • 0
                        Соглашусь, однако 9-ти осевые сенсоры все же имеют механизмы для борьбы с дрейфом.
                      • 0
                        Да, такой метод компенсации я тоже сразу попробовал.
                        Датчики с магнитометром очень хорошо подходят для того, чтобы уменьшать дрейф. Подумываю приобрести и попробовать. У меня в очень сыром варианте сбора данных, если резко трясти датчиком перпендикулярно вектору гравитации, то он очень легко сбивается направление по Z (что и вызвано этим самым дрейфом).
                        Вторая проблема остается проблемой, потому что при инициализации каждый датчик должен находиться в каком-то положении с не очень большой погрешностью.
                        А по поводу Вашего гейт-контроллера — частоту опроса датчиков не сильно уменьшает? Сколько датчиков потянет с необходимой частотой опроса? Может есть смысл посмотреть в сторону MPU-6000? Это тоже самое, только он умеет SPI, а туда, вроде, можно подключить больше датчиков без особых проблем со скоростью опроса, насколько мне известно.
                        Еще вопрос: Так как Вы включили DMP на датчиках, Ардуино служит просто для сбора значений со всех датчиков и отправки их на компьютер? Вы каким-то обрахом дополнительно обрабатываете эти данные потом на компьютере?
                        • 0
                          Практически не уменьшает. Пробовал 11 датчиков на частоте 50гц — нормально себя чувствуют, сейчас частота чуть пониже, т.к. даже 1 датчик подключенный напрямую на высоких частотах ведет себя недостаточно стабильно.
                          С SPI так же были эксперименты, но далеко они не зашли (6050 не подходят, как Вы верно заметили нужны 6000, но я не видел подобных сборок в природе). Вообще на практике провода между датчиками оказались неудобными, так что сейчас курс в сторону wifi или bt.
                          DMP при инициализации получает код от Atmega328 (все же от Arduino там только она и есть) это по-большому счету конфигурация, которую я подстраивал для оптимальной работы множества датчиков. По большому счету верно, контроллер служит только для коммутации всех датчиков, запаковки и отправки данных на компьютер. Вся математика перенесена на компьютер, это позволяет разгрузить контроллер, чтобы бы тот справлялся с частотой и количеством опрашиваемых датчиков.
                          • 0
                            Правильно я все-таки понял, что при первом запуске/калибровке необходимо, чтобы датчики находились на "своих положениях" относительно вектора гравитации и ни в коем случае не перевернуты? Или вы во время движения определяете валидность данных, зная ограничения углов костей и суставов?
                            • 0
                              При первом запуске нужно подождать 10 секунд для калибровки, далее человек принимают туже позу что и 3D-модель (будь то Т-поза или как в данном случае — руки по швам) и начинается трекинг. Датчики в основном повернуты вертикально.
                    • 0
                      Интересный проект, а главное — получен видимый результат. Вдохновило.
                      Если все же будете приступать к беспроводной версии, то желаю удачи.
                    • +2
                      Вот это интерес у человека! Провернуть, практически в одного, такое, над чем работают целые студии спецэффектов, это круто, просто жму руку и желаю дальнейших удач.
                      Я считаю, что с такой движущей силой географическое положение не имеет значения — надо выходить на рынок, особенно в свете начинающегося бума 3D-очков (Oculus Rift etc.)
                      • +1
                        Спасибо!
                        Да я элементарно на какую-либо игровую выставку или конференцию не имею выхода и возможности участия. На местных уже все знают, но это потолок. Пробовал проект в качестве стартапа, но дальнейшего развития не вижу, не понравилась вся эта движуха.
                        • 0
                          Планируется реализовывать экспорт данных в нормальных общепринятых форматах типа BVH, ну или хотя бы в виде облака точек для начала? Без экспорта только на поиграться сгодится ведь, какие уж там спецэффекты.
                          • 0
                            Можно много чего сделать и довести все до ума, но я признаться устал от проекта. На стороне приемника предусмотрен "стрим" данных в сеть, т.е. подцепиться можно практически из любой среды, а вот экспорт вещь необходимая — согласен. Пока есть свой текстовый и бинарный вид, где хранятся записанные анимации в видео углов поворота датчиков во фреймах времени, возможно из этого материала получиться наладить экспорт.
                            • 0
                              По третьей ссылке в выдаче гугла по запросу BVH пример лежит в каком виде данные организуются, я признаться ни разу не программист, в прошлом тридешник, как я понимаю формат чисто текстовый и описывает сначала иерархию, а потом сдвиг и вращение корня скелета и каждого джоинта скелета во времени, затем собственно фреймрейт захвата и данные по корню и каждому джоинту в виде строки, новая строка — новый кадр. В вашем случае нужно сначала вращение и сдвиг датчиков интерпретировать в вращение и сдвиг джоинтов скелета, а потом их тупо записать, тут разве что расстояние между датчиками (длину конечностей) может понадобиться вводить, не знаю как у вас калибровка реализована и учитывает ли она это. В общем то даже если экспорт не делать, чтобы к игровому движку прицепить захват движения всё равно нужно чтобы был связный скелет на выходе, возможно даже с кинематикой, а не отдельно болтающиеся кости. ЗЫ: устали — открывайте исходники) норот я думаю подтянется допиливать, на кикстартере полно проектов подобных, но цены негуманные, и закрытое всё. А можно сделать ход конем и запилить что то совместимое с YEI 3-Space например (тоже ценник огого, но открытые исходники), или какие там ещё есть проекты подобные, кстати можете вкратце в комментариях отписать что и чем от вашего проекта отличается?
                              • 0
                                Посмотрел бегло что такое BVH — думаю разберусь, при необходимости. Но пока это только вопрос конвертирования моего типа хранения анимации. И тут уже кому как удобнее, тот с тем форматом и работает, сделаю я BVH, как тут же набегут те, кому подавай все тоже самое в FBX. Ни к чему распыляться на такие вещи, на мой взгляд, это уход в сторону от основной цели, я все же физически не смогу угодить всем.
                                Открывать исходники — это если уж если костюм совсем в шкафу залежится.
                                На счет подобных проектов — да много их уже, и расписывать о них стоит в отдельной статье, но все они отличаются друг от друга ровно как нынешние шлемы виртуальной реальности.
                                Сейчас я вообще сомневаюсь в жизнеспособности всей это надувной "vR революции", имхо все угомонятся как с 3D телевизорами.
                                • 0
                                  Я в игры практически не играю, VR не слишком интересуюсь, мне ваш проект интересен с точки зрения как раз таки захвата движения для анимации и кино. Форматов действительно куча, просто BVH — один из самых примитивных, он почти везде поддерживается, в случае чего можно конвертировать во всё что угодно уже в 3д редакторе, FBX это всё же формат для 3д моделей в общем, а не конкретно скелетной анимации. От статьи про мокап костюмы не отказался бы, тем более от человека в теме.
                                  • 0
                                    Хорошо, я возьму на примету этот формат.
                                    Да вообще толковую статью про мокап можно сделать, но это как время будет.
                                    • +1
                                      Подписался на вас, буду ждать новостей. Успехов с проектом!
                          • 0
                            Я не совсем понял что вы имеете в виду под «движухой», но сейчас самый пик для стартапов по теме VR — первые партии Oculus Rift уже отправлены покупателям, и скоро они захотят «расширить функционал», full-body трэкинг для VR это то чего «в коробке» не предлагает ни Oculus, ни HTC, ни Sony. Есть целевая аудитория, а у вас практически есть решение в железе, с чётким осознанием что осталось доделать.
                            Во первых, на вашем месте, я бы отправил короткую презентацию вашего проекта в Oculus и HTC с просьбой предоставить дев-кит их очков, для помощи в разработке и тестировании. За «спросить» денег не берут, а вы можете как получить неплохой гаджет (и тем самым оживить собственный интерес к теме) так и получить предложение работы.
                            Во вторых серьёзней оцените возможность запуска стартапа на кикстартере. Я могу ошибаться, но мне кажется в вашем костюме бюджет всего железа — до 50ти баксов. За $99 баксов вы пару сотен таких китов точно продадите, пощупаете рынок, получите неплохой капитал для продолжения самостоятельной работы.
                            • +1
                              Верно, среда благоприятная и уже есть несколько стартапов на том же кикстартере с full-body системами, некоторые из них совершеннее мой поделки. На кикстартер выходов у меня нет, а то что те же Oculus откликнуться — слабо верится. Себестоимость 150$, может чуть поменьше.
                        • 0
                          Судя по всему, вам пора кооперироваться с производителями очков и игроделами. Интересные MMO проекты можно сделать…
                          • 0
                            Я открыт для любых предложений :)
                            • 0
                              Можете создать такой же костюм для захвата движения всего человека?
                              • 0
                                Могу. Сейчас используются только 11 датчиков, устройство рассчитано на 15 (кисти и стопы не отслеживаются). Остаются только пальцы, сгибы которых можно определять с помощью специальных перчаток, или тем же Leap3D.
                                • 0
                                  Получить бы что-то такое, только по-бюджетнее
                                  https://neuronmocap.com/content/product/32-neuron-alum-edition
                                  • 0
                                    Это как раз один из тех проектов, которые вылезли за период разработки. Имхо не стоит он своих денег, хотя использованы 32 датчика. Из них 16 только на кисти рук — это я считаю избыточность.
                                    Пока только отличие в количестве сенсоров, 15 против 32. Ну красиво все у них, да.
                                    • 0
                                      вот на хабре про них https://habrahabr.ru/post/236423/
                                      в период их "кикстартерства" они говорили что цены поднимутся в пределах 40%, но в реале увидели, почти 300 %
                                      • 0
                                        Пока это выглядит невероятным, покупать приставку за 450$ (или апгрейдить пк) затем шлем за ~450$, а потом еще и такой костюм за 1.5K$. Сомнительное это все удовольствие.
                                        • 0
                                          мне только костюм нужен, с программой в которой работа с костюмом ведется
                                      • 0
                                        ObelardO есть какие-нибудь новости по этому проекту?

                                        добавьтесь )
                                        вконтакте — id326920759
                            • 0
                              Расскажите, как победили дрейф нуля у гироскопов на длительных периодах (2+ часа) без использования дополнительных магнитных датчиков?
                              • 0
                                С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.

                                Длительные периоды не предполагались, но способ с программной компенсацией хоть как-то улучшил ситуацию. Могу заметить еще такой момент, чем выше частота работы сенсоров, тем быстрее они (логично) дрейфуют. Мну был нужен реалтайм, поэтому датчики опрашиваются раз 30 в секунда (при 50 уже не такие стабильные значения), если же режим реального времени не так важен, и нужно использовать сенсор на длительной период, то можно понизить частоту его работу, хоть до 1 опроса в секунду.
                                • 0
                                  По поводу "не такие стабильные значения" — посмотрите осциллографом напряжение питания. Скорее всего нестабильность питания и можно устранить припаяв дополнительные конденсаторы по питанию.
                                  • 0
                                    Верное замечание. На каждом сенсоре предусмотрен конденсатор на питании.
                                    • 0
                                      Вероятнее всего его емкости не хватает для компенсации чрезмерной длины проводников к плате контроллера. Изготовители платы не думали, что длина проводов будет больше 10-15 см.
                              • 0
                                Молодец, глянул ранее на булке, классный проект!
                                Не думал о Esp8266 и передачи данных по wifi?
                                • 0
                                  Спасибо! Я как раз видел на ютубе твои эксперименты с Esp8266.
                                  Конечно думал, уже лежит 12-версии и 1 9-ти осевой сенсор, если подружу их — то вообще здорово, будет множество автономных сенсоров, независимых друг от друга, в этом и заключается идея второго прототипа. Если подружить не получиться, наверное буду использовать контроллеры для связи между mpu и esp, а esp будет как uart-wifi транслятор.
                                • 0
                                  Во-первых, хочу выразить свое восхищение — рабочий, красиво выглядящий (!!) прототип за пол года — потрясающе.

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

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

                                      Мм, я тут посмотрел, есть штука https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/MPU6050.h
                                      И в этой штуке есть функции типа «GetAccel...» Оно скорее всего не проходит через DMP и требует фильтрации, да и вообще не понятно, но наверно лучше чем ничего?
                                      • 0
                                        www.i2cdevlib.com
                                        www.geekmomprojects.com/mpu-6050-redux-dmp-data-fusion-vs-complementary-filter
                                        Из-за отсутствия датчиков на стопах (используются 11 из 15). Прыгать умеет, но перемещается только в плоскости.
                                        В правильном направлении идете, все верно. Но там же есть и dmpGetAccel :)
                                        • 0
                                          Понятно, спасибо. Будем посмотреть.

                                          Всяческих вам успехов с доработкой!
                                          • 0
                                            Благодарю!
                                            • 0
                                              Посмотрите этот скетч https://github.com/JJulio/b-robot/blob/master/B_ROBOT/B_ROBOT.ino
                                              У Жозе Жулио обычно рабочие вещи…
                                    • 0
                                      Привет! Я тоже был на НТТМе. У меня есть несколько вопросов. Напиши мне в вк: vk.com/tvisf
                                      • 0
                                        Рад видеть земляка, отписал.
                                      • 0
                                        М… Да…
                                        Мы когда то в конторе пытались реализовать нечто подобное, но увы… Побоялись сложности проекта (12 человек) а Вы в одиночку потянули проект и в принципе у Вас готовый прототип для первого релиза. Не останавливайтесь не в коем случае. Это уже готовый проект для монетизации.
                                        Сделайте последний шаг. Я даже скинул эту статью паре серьезных контор за бугром. Может заинтересуются.
                                        Еще раз повторюсь, Я в шоке.
                                        • 0
                                          Спасибо за отзыв! В особенности за распространение.
                                          В данном случае моя одержимость идеей переборола страхи, хотя бывали моменты когда "ну совсем ничего не получалось", без этого никуда.
                                          Я как раз таки остановился, ибо слабо представляю что делать дальше, о каком последнем шаге идет речь?
                                          Еще раз спасибо :)
                                        • 0
                                          К этому добавить шлем VR, беговой шар, и можно играть в ММО игры на выносливость :)
                                          • 0
                                            Беговой шар не обязателен, если есть открытая местность)
                                          • 0
                                            Для подключения большого числа датчиков удобно использовать 16 канальный(для 15 датчиков) мультиплексор/демультиплексор. На нём вы 4 пинами задаёте двоичное число(номер датчика) и он соединяет пин от нужного датчика с управляющим пином. Цена такой микросхемки 30р и она заменяет вашу сложную схему с кучей транзисторов.
                                            Также вы рвёте все пины от датчиков(как я понял по схеме), а достаточно разорвать только пин, по которому от него приходит ответ.
                                            Ещё вместо i2c лучше использовать spi интерфейс. I2c гораздо медленнее и в arduino он реализован программно.
                                            • 0
                                              Использование транзисторов — это лишь пробный период, внимательнее прочитайте раздел статьи "Контроллер".
                                              В данном случае с I2C приходится рвать 2 пина.
                                              Стандартная библиотека wire действительно не отличается скоростью, поэтому я использовал стороннюю i2cdevlib. Spi интерфейс не предусмотрен на mpu6050, и насколько мне известно проблема c адресами сохраняется.
                                            • 0
                                              Класно! Не пробовали компенсировать дрейф несколькими разнонаправленными датчиками в точке? я с mpu9255 хотел так попробовать, но руки не дошли.
                                              • 0
                                                Спасибо! Думал над этим, есть 3 но: 1 — дрейфы у датчиков могут быть разными, и на входе будет дрейф в эту разницу. 2 — совершенно не факт, что сенсоры будут дрейфовать в разные стороны, у меня они начали вертеться в одну. 3 — стоимость примерно в 2 раза выше.
                                                • 0
                                                  Так если это сработало бы, не обязательно же брать такие же датчики (6-осевые). Для компенсации дрейфа с основного датчика нужен дополнительно только акселерометр, и то, может быть даже одноосевой, а он стоит копейки, по сравнению с 6-осевыми..
                                                  • 0
                                                    Думаю можно попробовать, спасибо.
                                              • +1
                                                Это просто шедеврально! Можем обменяться контактами для обсуждения вашего проекта?
                                                • 0
                                                  Спасибо!
                                                  Ну разумеется. Моя почта указанна в видео.
                                                • +2
                                                  Шикарная реализация сложной задачи. Рекомендую задуматься о коммерческой версии, я бы приобрел такой костюм. Аналоги стоят неподъемных денег.
                                                  • 0
                                                    Спасибо!
                                                    Задумаюсь, может на какой площадке стоит выступить, пока я буду занят вторым прототипом.
                                                • 0
                                                  … Напиши мне на почту свои контакты, попробуем свести тебя с нужными людьми. s2sa@rambler.ru
                                                  • 0
                                                    Осталось добавить сенсорные перчатки:
                                                    https://geektimes.ru/post/258608/
                                                    :)
                                                    Превосходно! Сделать такое на ардуинке...
                                                    • 0
                                                      Бюджетный вариант резистора сгиба, занятно) Я уже присмотрел этот способ для пальцев, хотя есть и готовые решения в виде перчаток.Уже выше писал что только их и не хватает)
                                                      Спасибо! В конечном счете все же не на ардуине, как никак свой контроллер получился.

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