Предисловие
В своем небольшом городе я занимаюсь решением нетривиальных технических задач. Так и в этот раз, организаторы одного шоу, в котором должна была выступить гимнастка со своей программой, решили добавить в ее представление некоторую «изюминку». А именно, выводить на экраны силуэт гимнастки, который бы повторял ее движения и как-то взаимодействовал с прочими эффектами, да так, чтобы все было интерактивно. Решить задачу «в лоб» не удалось. 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 датчика, это не лучшим образом повлияло на стабильность, а когда у меня закончились транзисторы я решил использовать более компактные и стабильные микросхемы.
Единственное сохранившееся фото с той стадии (извиняюсь за качество):
Гейт-контроллер
Устройство, которое будет сочетать в себе эти микросхемы и позволять общаться с множеством датчиков 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-пластик.
Для моделирования была выбрана программа 123D-Design. Программа интуитивно понятна, и любой, кто хоть немного имеет опыт работы в редакторах трехмерной графики быстро ее освоит.
Далее распечатал все корпусы, подключил датчики к контроллеру через тонкие 4-ех контактные провода, сделал крепления для датчиков, собрал все воедино и получил готовый, автономный, носимый костюм. Для первого прототипа вполне годится.
Софт
Ввиду некоторых обстоятельств, я отложил Unity3D «на потом», сроки поджимали и нужно было быстро написать программу для визуализации. Я уже давно работаю с графическим движком Xors3D (Может кто знает такой) и на этот раз он меня не подвел. Однако после того как он себя оправдал, я не вернулся к Unity, а продолжил разработку визуальной среды для костюма именно на этом движке.
Список текущих возможностей:
- Визуализация — в программе отображается модель человека, которая в реальном времени повторяет все движения за человеком в костюме
- Авто-калибровка — позволяет в любое время моментально калибровать костюм
- Позиционирование — модель так же перемещается в пространстве как и человек, может приседать, ходить и т.п.
- Запись/воспроизведение — все движения можно записывать и воспроизводить
- Режим взгляда от первого лица — предусмотрен вывод изображения для oculus rift и других шлемов виртуальной реальности.
- Интерактивность — человек носящий костюм может воздействовать на виртуальный мир. Пинать мячи, открывать двери, крутить карусель и т.д. (физический движек)
Заключение
На данный момент проект имеет 1 полностью рабочий, автономный, носимый и беспроводной прототип и все необходимое программное обеспечение. На разработку этого костюма ушло 8 месяцев (2 из которых я отдыхал, итого 6), но для меня это целая эпоха. За время проекта я прокачал свои навыки, попробовал и сделал много того, в чем раньше слабо разбирался, смог немного заработать.
Когда я начинал, был только интерес «а как это работает?» и о существовании подобных костюмов я еще не знал. Однако за время разработки как минимум 3 подобных проекта вышли на краудфандинговые площадки, и мне захотелось как-то развить impulse в качестве коммерческого проекта, но крайне тяжело заявить о себе сидя в Забайкальском крае. Сейчас не хватает мотивации сесть за второй прототип, уже беспроводной и на базе 9-ти осевых сенсоров, так что скорее всего этот проект останется для меня просто огромным и полезным опытом. В этой статье я хотел резюмировать всю проведенную работу, правда тут не отображено и 20% от нее. Не всем будут интересны тонны кода и часы пайки, 3d-печати, множество проб и ошибок, куча израсходованного материала, однако я постараюсь ответить на подобные вопросы в комментариях.
Комментарии (82)
Firelander
30.03.2016 17:15+2Крутой результат для сделанного практически "на коленке" прототипа. Мне трудно поверить, что одних только датчиков угловых положений достаточно для довольно-таки неплохого захвата движений. Не думаете переходить на более производительную платформу? Какие-нибудь Cortex-M3/M4 подошли бы идеально для вашей задачи, так как ардуина инерциалку хоть переваривает, но на пределе своих возможностей.
ObelardO
30.03.2016 18:48Спасибо! Да что кривить, действительно на коленке.
Не только угловые ускорения учитываются, акселерометр и гироскоп работают вместе, компенсирую друг-друга.
Необходимости в более производительной платформе пока нет, Atmega328 имеет достаточный ресурс, чтобы опрашивать 11 датчиков 50 раз в секунду и все это отсылать (контроллер практически ничего не вычислят, только переключается и отсылает данные, большую работу на себя берет dmp каждого датчика и софт на стороне приемника).
Fabian_red
30.03.2016 17:41+1"Однако появилась проблема нулевого дрейфа, но об этом позже."
А можно чуть подробней?ObelardO
30.03.2016 18:52+1Забыл раскрыть этот нюанс. Если коротко, то вертикальной оси Y не за что "заякориться", так горизонтальные оси отталкиваются от вектора гравитации, а ось Y ему сонаправленна. Вычисления угла по оси Y вычисляются программно, на основе осей X Z, а вот в 9-ти осевых датчиках (mpu9xxx) добавлен магнитометр, который встроен и сразу компенсирует дрейфы.
ObelardO
30.03.2016 19:19Угол по оси Y вычисляются программно*
Rumlin
31.03.2016 14:29А по поводу
организаторы одного шоу, в котором должна была выступить гимнастка со своей программой, решили добавить в ее представление некоторую «изюминку»
- выступила?
Честно говоря в конце статьи ожидал видео выступления гимнастки.
- выступила?
riv_shiell
30.03.2016 18:40+2А можно поделиться кодом для фильтра Калмана к ардуине? Или самой математикой под него?
ObelardO
30.03.2016 18:55+1Фильтр калмана отпал за ненадобностью, датчики из коробки умеют комплементарный фильтр и dmp. Разве что можно использовать вторичную фильтрацию уже на приемнике.
riv_shiell
30.03.2016 19:07+2А может всё таки остались наброски для фильтра с самой математикой?..
з.ы. Сам пытался, но никак не выходило составить коэффициент КалманаObelardO
30.03.2016 19:22Конкретно с того периода исходники не остались, но я точно помню что пользовался статьей, где была реализация на Си, но это все на забугорных форумах)
Watcover3396
30.03.2016 18:41+6«Не всем будут интересны тонны кода и часы пайки, 3d-печати, множество проб и ошибок, куча израсходованного материала, однако я постараюсь ответить на подобные вопросы в комментариях.»
По-моему, как раз таки многие сюда за этим и приходят, например мне всегда были интересны статьи с тонной описания технических/софтварных деталей.
Кстати из-за подобных статей и стал читать Хабрахабр в 2012 году, а потом еще и Geektimes.ObelardO
30.03.2016 18:57+2Мне кажется такой Хабр как раз и закончился в 2012 году… Я постараюсь отвечать на конкретно интересующие вопросы, в статью вынес более общие моменты, хотя и не обошлось без ухода в подробности.
diller61
31.03.2016 12:45вероятно по той причине что авторы не выкладывают эти материалы, по всей видимости считая их коммерческой тайной что ли
Dolbe
30.03.2016 18:42Очень интересная тема!
Скажите пожалуйста, как вы решили проблему нулевого дрейфа?
Есть одна, более важная, на мой взгляд, проблема, с которой я столкнулся при работе с MPU-6050 (да вообще с любым сенсором, сочетающим в себе акселерометр и гироскоп). Проблема состоит в том, что акселерометр изначально не знает, повернут ли он «головой» (ось Z) вверх или вниз. Как вы ее решили?ObelardO
30.03.2016 19:09Спасибо!
С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.
На счет второй проблемы — она куда проще дрейфов, ее я решил в голове еще за долго до того, как она предстала передо мной. Для начала, в 3D модели соответствующая кость должна иметь якорь, который повернут так же, как реальный датчик (например на ноге он закреплен вертикально, так и на модели якорь повернут вертикально, так же со всеми осями) Далее когда начинается трекинг, мы получаем значения с сенсоров, берем разницу между полученными углами с сенсора и углами кости 3D-модели и вычитаем ее из каждого полученного значения. Проще говоря — мы знаем что в самом начале нога должна быть повернута на 0 градусов, а с датчика пришло 45 — то мы запоминаем 45 и вычитаем их из каждого следующего значения. Есть нюанс с поворотом между 180 и -179 градусов, он тоже решаем.ProLimit
30.03.2016 20:09Не хочу вас расстраивать, но 9-ти осевым датчиком проблема тоже не решается, особенно в помещении — компасс крайне недостоверен, да и калибровать его нужно в реальном окружении, а не на заводе. В проф. системах учитываются все кинематические связи между датчиками, ограничения человеческого тела. Этим можно минимизировать дрейф (фактически усердняется десяток дрейфов) но не полностью убрать. Сильно помогает температурная компенсация или стабилизация.
ObelardO
30.03.2016 20:44Соглашусь, однако 9-ти осевые сенсоры все же имеют механизмы для борьбы с дрейфом.
Dolbe
30.03.2016 20:24Да, такой метод компенсации я тоже сразу попробовал.
Датчики с магнитометром очень хорошо подходят для того, чтобы уменьшать дрейф. Подумываю приобрести и попробовать. У меня в очень сыром варианте сбора данных, если резко трясти датчиком перпендикулярно вектору гравитации, то он очень легко сбивается направление по Z (что и вызвано этим самым дрейфом).
Вторая проблема остается проблемой, потому что при инициализации каждый датчик должен находиться в каком-то положении с не очень большой погрешностью.
А по поводу Вашего гейт-контроллера — частоту опроса датчиков не сильно уменьшает? Сколько датчиков потянет с необходимой частотой опроса? Может есть смысл посмотреть в сторону MPU-6000? Это тоже самое, только он умеет SPI, а туда, вроде, можно подключить больше датчиков без особых проблем со скоростью опроса, насколько мне известно.
Еще вопрос: Так как Вы включили DMP на датчиках, Ардуино служит просто для сбора значений со всех датчиков и отправки их на компьютер? Вы каким-то обрахом дополнительно обрабатываете эти данные потом на компьютере?ObelardO
30.03.2016 20:55Практически не уменьшает. Пробовал 11 датчиков на частоте 50гц — нормально себя чувствуют, сейчас частота чуть пониже, т.к. даже 1 датчик подключенный напрямую на высоких частотах ведет себя недостаточно стабильно.
С SPI так же были эксперименты, но далеко они не зашли (6050 не подходят, как Вы верно заметили нужны 6000, но я не видел подобных сборок в природе). Вообще на практике провода между датчиками оказались неудобными, так что сейчас курс в сторону wifi или bt.
DMP при инициализации получает код от Atmega328 (все же от Arduino там только она и есть) это по-большому счету конфигурация, которую я подстраивал для оптимальной работы множества датчиков. По большому счету верно, контроллер служит только для коммутации всех датчиков, запаковки и отправки данных на компьютер. Вся математика перенесена на компьютер, это позволяет разгрузить контроллер, чтобы бы тот справлялся с частотой и количеством опрашиваемых датчиков.Dolbe
31.03.2016 09:03Правильно я все-таки понял, что при первом запуске/калибровке необходимо, чтобы датчики находились на "своих положениях" относительно вектора гравитации и ни в коем случае не перевернуты? Или вы во время движения определяете валидность данных, зная ограничения углов костей и суставов?
ObelardO
31.03.2016 11:14При первом запуске нужно подождать 10 секунд для калибровки, далее человек принимают туже позу что и 3D-модель (будь то Т-поза или как в данном случае — руки по швам) и начинается трекинг. Датчики в основном повернуты вертикально.
Anna_McFly
30.03.2016 18:42Интересный проект, а главное — получен видимый результат. Вдохновило.
Если все же будете приступать к беспроводной версии, то желаю удачи.
Snowtomcat
30.03.2016 18:42+2Вот это интерес у человека! Провернуть, практически в одного, такое, над чем работают целые студии спецэффектов, это круто, просто жму руку и желаю дальнейших удач.
Я считаю, что с такой движущей силой географическое положение не имеет значения — надо выходить на рынок, особенно в свете начинающегося бума 3D-очков (Oculus Rift etc.)ObelardO
30.03.2016 19:14+1Спасибо!
Да я элементарно на какую-либо игровую выставку или конференцию не имею выхода и возможности участия. На местных уже все знают, но это потолок. Пробовал проект в качестве стартапа, но дальнейшего развития не вижу, не понравилась вся эта движуха.
no1D
30.03.2016 19:27Планируется реализовывать экспорт данных в нормальных общепринятых форматах типа BVH, ну или хотя бы в виде облака точек для начала? Без экспорта только на поиграться сгодится ведь, какие уж там спецэффекты.
ObelardO
30.03.2016 19:46Можно много чего сделать и довести все до ума, но я признаться устал от проекта. На стороне приемника предусмотрен "стрим" данных в сеть, т.е. подцепиться можно практически из любой среды, а вот экспорт вещь необходимая — согласен. Пока есть свой текстовый и бинарный вид, где хранятся записанные анимации в видео углов поворота датчиков во фреймах времени, возможно из этого материала получиться наладить экспорт.
no1D
30.03.2016 20:20По третьей ссылке в выдаче гугла по запросу BVH пример лежит в каком виде данные организуются, я признаться ни разу не программист, в прошлом тридешник, как я понимаю формат чисто текстовый и описывает сначала иерархию, а потом сдвиг и вращение корня скелета и каждого джоинта скелета во времени, затем собственно фреймрейт захвата и данные по корню и каждому джоинту в виде строки, новая строка — новый кадр. В вашем случае нужно сначала вращение и сдвиг датчиков интерпретировать в вращение и сдвиг джоинтов скелета, а потом их тупо записать, тут разве что расстояние между датчиками (длину конечностей) может понадобиться вводить, не знаю как у вас калибровка реализована и учитывает ли она это. В общем то даже если экспорт не делать, чтобы к игровому движку прицепить захват движения всё равно нужно чтобы был связный скелет на выходе, возможно даже с кинематикой, а не отдельно болтающиеся кости. ЗЫ: устали — открывайте исходники) норот я думаю подтянется допиливать, на кикстартере полно проектов подобных, но цены негуманные, и закрытое всё. А можно сделать ход конем и запилить что то совместимое с YEI 3-Space например (тоже ценник огого, но открытые исходники), или какие там ещё есть проекты подобные, кстати можете вкратце в комментариях отписать что и чем от вашего проекта отличается?
ObelardO
30.03.2016 21:11Посмотрел бегло что такое BVH — думаю разберусь, при необходимости. Но пока это только вопрос конвертирования моего типа хранения анимации. И тут уже кому как удобнее, тот с тем форматом и работает, сделаю я BVH, как тут же набегут те, кому подавай все тоже самое в FBX. Ни к чему распыляться на такие вещи, на мой взгляд, это уход в сторону от основной цели, я все же физически не смогу угодить всем.
Открывать исходники — это если уж если костюм совсем в шкафу залежится.
На счет подобных проектов — да много их уже, и расписывать о них стоит в отдельной статье, но все они отличаются друг от друга ровно как нынешние шлемы виртуальной реальности.
Сейчас я вообще сомневаюсь в жизнеспособности всей это надувной "vR революции", имхо все угомонятся как с 3D телевизорами.no1D
31.03.2016 12:28Я в игры практически не играю, VR не слишком интересуюсь, мне ваш проект интересен с точки зрения как раз таки захвата движения для анимации и кино. Форматов действительно куча, просто BVH — один из самых примитивных, он почти везде поддерживается, в случае чего можно конвертировать во всё что угодно уже в 3д редакторе, FBX это всё же формат для 3д моделей в общем, а не конкретно скелетной анимации. От статьи про мокап костюмы не отказался бы, тем более от человека в теме.
FokkerFace
30.03.2016 19:34Я не совсем понял что вы имеете в виду под «движухой», но сейчас самый пик для стартапов по теме VR — первые партии Oculus Rift уже отправлены покупателям, и скоро они захотят «расширить функционал», full-body трэкинг для VR это то чего «в коробке» не предлагает ни Oculus, ни HTC, ни Sony. Есть целевая аудитория, а у вас практически есть решение в железе, с чётким осознанием что осталось доделать.
Во первых, на вашем месте, я бы отправил короткую презентацию вашего проекта в Oculus и HTC с просьбой предоставить дев-кит их очков, для помощи в разработке и тестировании. За «спросить» денег не берут, а вы можете как получить неплохой гаджет (и тем самым оживить собственный интерес к теме) так и получить предложение работы.
Во вторых серьёзней оцените возможность запуска стартапа на кикстартере. Я могу ошибаться, но мне кажется в вашем костюме бюджет всего железа — до 50ти баксов. За $99 баксов вы пару сотен таких китов точно продадите, пощупаете рынок, получите неплохой капитал для продолжения самостоятельной работы.ObelardO
30.03.2016 19:53+1Верно, среда благоприятная и уже есть несколько стартапов на том же кикстартере с full-body системами, некоторые из них совершеннее мой поделки. На кикстартер выходов у меня нет, а то что те же Oculus откликнуться — слабо верится. Себестоимость 150$, может чуть поменьше.
Mistx
30.03.2016 19:21Судя по всему, вам пора кооперироваться с производителями очков и игроделами. Интересные MMO проекты можно сделать…
ObelardO
30.03.2016 19:31Я открыт для любых предложений :)
Eugeny1987
31.03.2016 11:15Можете создать такой же костюм для захвата движения всего человека?
ObelardO
31.03.2016 11:19Могу. Сейчас используются только 11 датчиков, устройство рассчитано на 15 (кисти и стопы не отслеживаются). Остаются только пальцы, сгибы которых можно определять с помощью специальных перчаток, или тем же Leap3D.
Eugeny1987
31.03.2016 11:20Получить бы что-то такое, только по-бюджетнее
https://neuronmocap.com/content/product/32-neuron-alum-editionObelardO
31.03.2016 11:41Это как раз один из тех проектов, которые вылезли за период разработки. Имхо не стоит он своих денег, хотя использованы 32 датчика. Из них 16 только на кисти рук — это я считаю избыточность.
Пока только отличие в количестве сенсоров, 15 против 32. Ну красиво все у них, да.Eugeny1987
31.03.2016 12:31вот на хабре про них https://habrahabr.ru/post/236423/
в период их "кикстартерства" они говорили что цены поднимутся в пределах 40%, но в реале увидели, почти 300 %ObelardO
31.03.2016 18:47Пока это выглядит невероятным, покупать приставку за 450$ (или апгрейдить пк) затем шлем за ~450$, а потом еще и такой костюм за 1.5K$. Сомнительное это все удовольствие.
Ta10s
30.03.2016 19:23Расскажите, как победили дрейф нуля у гироскопов на длительных периодах (2+ часа) без использования дополнительных магнитных датчиков?
ObelardO
30.03.2016 19:27С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.
Длительные периоды не предполагались, но способ с программной компенсацией хоть как-то улучшил ситуацию. Могу заметить еще такой момент, чем выше частота работы сенсоров, тем быстрее они (логично) дрейфуют. Мну был нужен реалтайм, поэтому датчики опрашиваются раз 30 в секунда (при 50 уже не такие стабильные значения), если же режим реального времени не так важен, и нужно использовать сенсор на длительной период, то можно понизить частоту его работу, хоть до 1 опроса в секунду.Rumlin
31.03.2016 14:34По поводу "не такие стабильные значения" — посмотрите осциллографом напряжение питания. Скорее всего нестабильность питания и можно устранить припаяв дополнительные конденсаторы по питанию.
Tirarex
30.03.2016 19:27Молодец, глянул ранее на булке, классный проект!
Не думал о Esp8266 и передачи данных по wifi?ObelardO
30.03.2016 19:30Спасибо! Я как раз видел на ютубе твои эксперименты с Esp8266.
Конечно думал, уже лежит 12-версии и 1 9-ти осевой сенсор, если подружу их — то вообще здорово, будет множество автономных сенсоров, независимых друг от друга, в этом и заключается идея второго прототипа. Если подружить не получиться, наверное буду использовать контроллеры для связи между mpu и esp, а esp будет как uart-wifi транслятор.
Mr_Destiny
30.03.2016 19:30Во-первых, хочу выразить свое восхищение — рабочий, красиво выглядящий (!!) прототип за пол года — потрясающе.
Кроме того хочу спросить пару технических деталей:
1) Что в итоге отдает датчик движения, что с этим делает центральный контроллер, и что получает комп. На особых подробностях не настаиваю, но буду признателен :)
2) Я погуглил по дмп и MPU-6050, и как-то там глухо — если можете, поделитесь информацией как оно работает (ну или где почитать, можно на англ). Вообще, техническая статья про то как из датчика-акселерометра получается кватернионы, я думаю, будет принята с признательностью не одним мной
3) На компе, вы как-то заботитесь о том чтобы «человечек» стыковался как следует, или углы настолько хорошо определяются что можно просто поворачивать палочки-руки/ноги? Кватернионы — это тупо вращения, а вокруг чего вращать то? Хотя если MPU передает скорость, то тогда все проще. В общем, если не затруднит, расскажите по-подробней как сырые данные переходят в человечка.ObelardO
30.03.2016 19:42Большое спасибо!
1) После всех манипуляций и конфигураций dmp, сенсоры отдают свои углы в пространстве в виде кватерниона. Это dmp умеет "из коробки" и позволяет не заботиться о шарнирном замке. Центральный контроллер поочередно получает данные с каждого сенсора, запаковывает это все и отправляет по bluetooth на приемник много раз в секунду, никаких вычислений практически не производит.
2) В том-то и дело, информации мало. Это только в последнее время что-то появляется, за счет моды на DIY квадрокоптеры и прочее. В первую очередь много полезного нашел на . А так же тут
3) На компе много о чем приходиться заботиться, т.к. по факту имеем только углы поворота всех сенсоров. Трекинг в пространстве сделан программно (пока не идеален, нужны сенсоры на стопы)
MPU передают только углы в виде кватерниона, все остальное уже на стороне приемника.Mr_Destiny
30.03.2016 19:51Ваши ссылки не отобразились :(
Да, я заметил что он ногами проскальзывает (и, я так понимаю, прыгать не умеет?)
Мм, я тут посмотрел, есть штука https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/MPU6050.h
И в этой штуке есть функции типа «GetAccel...» Оно скорее всего не проходит через DMP и требует фильтрации, да и вообще не понятно, но наверно лучше чем ничего?ObelardO
30.03.2016 20:01www.i2cdevlib.com
www.geekmomprojects.com/mpu-6050-redux-dmp-data-fusion-vs-complementary-filter
Из-за отсутствия датчиков на стопах (используются 11 из 15). Прыгать умеет, но перемещается только в плоскости.
В правильном направлении идете, все верно. Но там же есть и dmpGetAccel :)Mr_Destiny
30.03.2016 20:05Понятно, спасибо. Будем посмотреть.
Всяческих вам успехов с доработкой!
mahowik
04.04.2016 04:13Посмотрите этот скетч https://github.com/JJulio/b-robot/blob/master/B_ROBOT/B_ROBOT.ino
У Жозе Жулио обычно рабочие вещи…
SuperFamicom
30.03.2016 19:43Привет! Я тоже был на НТТМе. У меня есть несколько вопросов. Напиши мне в вк: vk.com/tvisf
AkimovUriy
30.03.2016 20:24М… Да…
Мы когда то в конторе пытались реализовать нечто подобное, но увы… Побоялись сложности проекта (12 человек) а Вы в одиночку потянули проект и в принципе у Вас готовый прототип для первого релиза. Не останавливайтесь не в коем случае. Это уже готовый проект для монетизации.
Сделайте последний шаг. Я даже скинул эту статью паре серьезных контор за бугром. Может заинтересуются.
Еще раз повторюсь, Я в шоке.ObelardO
30.03.2016 20:30Спасибо за отзыв! В особенности за распространение.
В данном случае моя одержимость идеей переборола страхи, хотя бывали моменты когда "ну совсем ничего не получалось", без этого никуда.
Я как раз таки остановился, ибо слабо представляю что делать дальше, о каком последнем шаге идет речь?
Еще раз спасибо :)
HOMPAIN
30.03.2016 21:13Для подключения большого числа датчиков удобно использовать 16 канальный(для 15 датчиков) мультиплексор/демультиплексор. На нём вы 4 пинами задаёте двоичное число(номер датчика) и он соединяет пин от нужного датчика с управляющим пином. Цена такой микросхемки 30р и она заменяет вашу сложную схему с кучей транзисторов.
Также вы рвёте все пины от датчиков(как я понял по схеме), а достаточно разорвать только пин, по которому от него приходит ответ.
Ещё вместо i2c лучше использовать spi интерфейс. I2c гораздо медленнее и в arduino он реализован программно.ObelardO
30.03.2016 21:23Использование транзисторов — это лишь пробный период, внимательнее прочитайте раздел статьи "Контроллер".
В данном случае с I2C приходится рвать 2 пина.
Стандартная библиотека wire действительно не отличается скоростью, поэтому я использовал стороннюю i2cdevlib. Spi интерфейс не предусмотрен на mpu6050, и насколько мне известно проблема c адресами сохраняется.
mikkab
31.03.2016 07:48Класно! Не пробовали компенсировать дрейф несколькими разнонаправленными датчиками в точке? я с mpu9255 хотел так попробовать, но руки не дошли.
ObelardO
31.03.2016 07:51Спасибо! Думал над этим, есть 3 но: 1 — дрейфы у датчиков могут быть разными, и на входе будет дрейф в эту разницу. 2 — совершенно не факт, что сенсоры будут дрейфовать в разные стороны, у меня они начали вертеться в одну. 3 — стоимость примерно в 2 раза выше.
Dolbe
31.03.2016 08:56Так если это сработало бы, не обязательно же брать такие же датчики (6-осевые). Для компенсации дрейфа с основного датчика нужен дополнительно только акселерометр, и то, может быть даже одноосевой, а он стоит копейки, по сравнению с 6-осевыми..
it2manager
31.03.2016 13:12… Напиши мне на почту свои контакты, попробуем свести тебя с нужными людьми. s2sa@rambler.ru
SvSh123
31.03.2016 16:48Осталось добавить сенсорные перчатки:
https://geektimes.ru/post/258608/
:)
Превосходно! Сделать такое на ардуинке...ObelardO
31.03.2016 18:52Бюджетный вариант резистора сгиба, занятно) Я уже присмотрел этот способ для пальцев, хотя есть и готовые решения в виде перчаток.Уже выше писал что только их и не хватает)
Спасибо! В конечном счете все же не на ардуине, как никак свой контроллер получился.
sillywilly
Классно. Желаю вам удачи. Есть ориентировочная цена-то?
ObelardO
Спасибо! себестоимость 150$