Comments 83
Классно. Желаю вам удачи. Есть ориентировочная цена-то?
Крутой результат для сделанного практически "на коленке" прототипа. Мне трудно поверить, что одних только датчиков угловых положений достаточно для довольно-таки неплохого захвата движений. Не думаете переходить на более производительную платформу? Какие-нибудь Cortex-M3/M4 подошли бы идеально для вашей задачи, так как ардуина инерциалку хоть переваривает, но на пределе своих возможностей.
Спасибо! Да что кривить, действительно на коленке.
Не только угловые ускорения учитываются, акселерометр и гироскоп работают вместе, компенсирую друг-друга.
Необходимости в более производительной платформе пока нет, Atmega328 имеет достаточный ресурс, чтобы опрашивать 11 датчиков 50 раз в секунду и все это отсылать (контроллер практически ничего не вычислят, только переключается и отсылает данные, большую работу на себя берет dmp каждого датчика и софт на стороне приемника).
Не только угловые ускорения учитываются, акселерометр и гироскоп работают вместе, компенсирую друг-друга.
Необходимости в более производительной платформе пока нет, Atmega328 имеет достаточный ресурс, чтобы опрашивать 11 датчиков 50 раз в секунду и все это отсылать (контроллер практически ничего не вычислят, только переключается и отсылает данные, большую работу на себя берет dmp каждого датчика и софт на стороне приемника).
"Однако появилась проблема нулевого дрейфа, но об этом позже."
А можно чуть подробней?
А можно чуть подробней?
Забыл раскрыть этот нюанс. Если коротко, то вертикальной оси Y не за что "заякориться", так горизонтальные оси отталкиваются от вектора гравитации, а ось Y ему сонаправленна. Вычисления угла по оси Y вычисляются программно, на основе осей X Z, а вот в 9-ти осевых датчиках (mpu9xxx) добавлен магнитометр, который встроен и сразу компенсирует дрейфы.
мимо
А можно поделиться кодом для фильтра Калмана к ардуине? Или самой математикой под него?
«Не всем будут интересны тонны кода и часы пайки, 3d-печати, множество проб и ошибок, куча израсходованного материала, однако я постараюсь ответить на подобные вопросы в комментариях.»
По-моему, как раз таки многие сюда за этим и приходят, например мне всегда были интересны статьи с тонной описания технических/софтварных деталей.
Кстати из-за подобных статей и стал читать Хабрахабр в 2012 году, а потом еще и Geektimes.
По-моему, как раз таки многие сюда за этим и приходят, например мне всегда были интересны статьи с тонной описания технических/софтварных деталей.
Кстати из-за подобных статей и стал читать Хабрахабр в 2012 году, а потом еще и Geektimes.
Очень интересная тема!
Скажите пожалуйста, как вы решили проблему нулевого дрейфа?
Есть одна, более важная, на мой взгляд, проблема, с которой я столкнулся при работе с MPU-6050 (да вообще с любым сенсором, сочетающим в себе акселерометр и гироскоп). Проблема состоит в том, что акселерометр изначально не знает, повернут ли он «головой» (ось Z) вверх или вниз. Как вы ее решили?
Скажите пожалуйста, как вы решили проблему нулевого дрейфа?
Есть одна, более важная, на мой взгляд, проблема, с которой я столкнулся при работе с MPU-6050 (да вообще с любым сенсором, сочетающим в себе акселерометр и гироскоп). Проблема состоит в том, что акселерометр изначально не знает, повернут ли он «головой» (ось Z) вверх или вниз. Как вы ее решили?
Спасибо!
С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.
На счет второй проблемы — она куда проще дрейфов, ее я решил в голове еще за долго до того, как она предстала передо мной. Для начала, в 3D модели соответствующая кость должна иметь якорь, который повернут так же, как реальный датчик (например на ноге он закреплен вертикально, так и на модели якорь повернут вертикально, так же со всеми осями) Далее когда начинается трекинг, мы получаем значения с сенсоров, берем разницу между полученными углами с сенсора и углами кости 3D-модели и вычитаем ее из каждого полученного значения. Проще говоря — мы знаем что в самом начале нога должна быть повернута на 0 градусов, а с датчика пришло 45 — то мы запоминаем 45 и вычитаем их из каждого следующего значения. Есть нюанс с поворотом между 180 и -179 градусов, он тоже решаем.
С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.
На счет второй проблемы — она куда проще дрейфов, ее я решил в голове еще за долго до того, как она предстала передо мной. Для начала, в 3D модели соответствующая кость должна иметь якорь, который повернут так же, как реальный датчик (например на ноге он закреплен вертикально, так и на модели якорь повернут вертикально, так же со всеми осями) Далее когда начинается трекинг, мы получаем значения с сенсоров, берем разницу между полученными углами с сенсора и углами кости 3D-модели и вычитаем ее из каждого полученного значения. Проще говоря — мы знаем что в самом начале нога должна быть повернута на 0 градусов, а с датчика пришло 45 — то мы запоминаем 45 и вычитаем их из каждого следующего значения. Есть нюанс с поворотом между 180 и -179 градусов, он тоже решаем.
Не хочу вас расстраивать, но 9-ти осевым датчиком проблема тоже не решается, особенно в помещении — компасс крайне недостоверен, да и калибровать его нужно в реальном окружении, а не на заводе. В проф. системах учитываются все кинематические связи между датчиками, ограничения человеческого тела. Этим можно минимизировать дрейф (фактически усердняется десяток дрейфов) но не полностью убрать. Сильно помогает температурная компенсация или стабилизация.
Да, такой метод компенсации я тоже сразу попробовал.
Датчики с магнитометром очень хорошо подходят для того, чтобы уменьшать дрейф. Подумываю приобрести и попробовать. У меня в очень сыром варианте сбора данных, если резко трясти датчиком перпендикулярно вектору гравитации, то он очень легко сбивается направление по Z (что и вызвано этим самым дрейфом).
Вторая проблема остается проблемой, потому что при инициализации каждый датчик должен находиться в каком-то положении с не очень большой погрешностью.
А по поводу Вашего гейт-контроллера — частоту опроса датчиков не сильно уменьшает? Сколько датчиков потянет с необходимой частотой опроса? Может есть смысл посмотреть в сторону MPU-6000? Это тоже самое, только он умеет SPI, а туда, вроде, можно подключить больше датчиков без особых проблем со скоростью опроса, насколько мне известно.
Еще вопрос: Так как Вы включили DMP на датчиках, Ардуино служит просто для сбора значений со всех датчиков и отправки их на компьютер? Вы каким-то обрахом дополнительно обрабатываете эти данные потом на компьютере?
Датчики с магнитометром очень хорошо подходят для того, чтобы уменьшать дрейф. Подумываю приобрести и попробовать. У меня в очень сыром варианте сбора данных, если резко трясти датчиком перпендикулярно вектору гравитации, то он очень легко сбивается направление по Z (что и вызвано этим самым дрейфом).
Вторая проблема остается проблемой, потому что при инициализации каждый датчик должен находиться в каком-то положении с не очень большой погрешностью.
А по поводу Вашего гейт-контроллера — частоту опроса датчиков не сильно уменьшает? Сколько датчиков потянет с необходимой частотой опроса? Может есть смысл посмотреть в сторону MPU-6000? Это тоже самое, только он умеет SPI, а туда, вроде, можно подключить больше датчиков без особых проблем со скоростью опроса, насколько мне известно.
Еще вопрос: Так как Вы включили DMP на датчиках, Ардуино служит просто для сбора значений со всех датчиков и отправки их на компьютер? Вы каким-то обрахом дополнительно обрабатываете эти данные потом на компьютере?
Практически не уменьшает. Пробовал 11 датчиков на частоте 50гц — нормально себя чувствуют, сейчас частота чуть пониже, т.к. даже 1 датчик подключенный напрямую на высоких частотах ведет себя недостаточно стабильно.
С SPI так же были эксперименты, но далеко они не зашли (6050 не подходят, как Вы верно заметили нужны 6000, но я не видел подобных сборок в природе). Вообще на практике провода между датчиками оказались неудобными, так что сейчас курс в сторону wifi или bt.
DMP при инициализации получает код от Atmega328 (все же от Arduino там только она и есть) это по-большому счету конфигурация, которую я подстраивал для оптимальной работы множества датчиков. По большому счету верно, контроллер служит только для коммутации всех датчиков, запаковки и отправки данных на компьютер. Вся математика перенесена на компьютер, это позволяет разгрузить контроллер, чтобы бы тот справлялся с частотой и количеством опрашиваемых датчиков.
С SPI так же были эксперименты, но далеко они не зашли (6050 не подходят, как Вы верно заметили нужны 6000, но я не видел подобных сборок в природе). Вообще на практике провода между датчиками оказались неудобными, так что сейчас курс в сторону wifi или bt.
DMP при инициализации получает код от Atmega328 (все же от Arduino там только она и есть) это по-большому счету конфигурация, которую я подстраивал для оптимальной работы множества датчиков. По большому счету верно, контроллер служит только для коммутации всех датчиков, запаковки и отправки данных на компьютер. Вся математика перенесена на компьютер, это позволяет разгрузить контроллер, чтобы бы тот справлялся с частотой и количеством опрашиваемых датчиков.
Интересный проект, а главное — получен видимый результат. Вдохновило.
Если все же будете приступать к беспроводной версии, то желаю удачи.
Если все же будете приступать к беспроводной версии, то желаю удачи.
Вот это интерес у человека! Провернуть, практически в одного, такое, над чем работают целые студии спецэффектов, это круто, просто жму руку и желаю дальнейших удач.
Я считаю, что с такой движущей силой географическое положение не имеет значения — надо выходить на рынок, особенно в свете начинающегося бума 3D-очков (Oculus Rift etc.)
Я считаю, что с такой движущей силой географическое положение не имеет значения — надо выходить на рынок, особенно в свете начинающегося бума 3D-очков (Oculus Rift etc.)
Спасибо!
Да я элементарно на какую-либо игровую выставку или конференцию не имею выхода и возможности участия. На местных уже все знают, но это потолок. Пробовал проект в качестве стартапа, но дальнейшего развития не вижу, не понравилась вся эта движуха.
Да я элементарно на какую-либо игровую выставку или конференцию не имею выхода и возможности участия. На местных уже все знают, но это потолок. Пробовал проект в качестве стартапа, но дальнейшего развития не вижу, не понравилась вся эта движуха.
Планируется реализовывать экспорт данных в нормальных общепринятых форматах типа BVH, ну или хотя бы в виде облака точек для начала? Без экспорта только на поиграться сгодится ведь, какие уж там спецэффекты.
Можно много чего сделать и довести все до ума, но я признаться устал от проекта. На стороне приемника предусмотрен "стрим" данных в сеть, т.е. подцепиться можно практически из любой среды, а вот экспорт вещь необходимая — согласен. Пока есть свой текстовый и бинарный вид, где хранятся записанные анимации в видео углов поворота датчиков во фреймах времени, возможно из этого материала получиться наладить экспорт.
По третьей ссылке в выдаче гугла по запросу BVH пример лежит в каком виде данные организуются, я признаться ни разу не программист, в прошлом тридешник, как я понимаю формат чисто текстовый и описывает сначала иерархию, а потом сдвиг и вращение корня скелета и каждого джоинта скелета во времени, затем собственно фреймрейт захвата и данные по корню и каждому джоинту в виде строки, новая строка — новый кадр. В вашем случае нужно сначала вращение и сдвиг датчиков интерпретировать в вращение и сдвиг джоинтов скелета, а потом их тупо записать, тут разве что расстояние между датчиками (длину конечностей) может понадобиться вводить, не знаю как у вас калибровка реализована и учитывает ли она это. В общем то даже если экспорт не делать, чтобы к игровому движку прицепить захват движения всё равно нужно чтобы был связный скелет на выходе, возможно даже с кинематикой, а не отдельно болтающиеся кости. ЗЫ: устали — открывайте исходники) норот я думаю подтянется допиливать, на кикстартере полно проектов подобных, но цены негуманные, и закрытое всё. А можно сделать ход конем и запилить что то совместимое с YEI 3-Space например (тоже ценник огого, но открытые исходники), или какие там ещё есть проекты подобные, кстати можете вкратце в комментариях отписать что и чем от вашего проекта отличается?
Посмотрел бегло что такое BVH — думаю разберусь, при необходимости. Но пока это только вопрос конвертирования моего типа хранения анимации. И тут уже кому как удобнее, тот с тем форматом и работает, сделаю я BVH, как тут же набегут те, кому подавай все тоже самое в FBX. Ни к чему распыляться на такие вещи, на мой взгляд, это уход в сторону от основной цели, я все же физически не смогу угодить всем.
Открывать исходники — это если уж если костюм совсем в шкафу залежится.
На счет подобных проектов — да много их уже, и расписывать о них стоит в отдельной статье, но все они отличаются друг от друга ровно как нынешние шлемы виртуальной реальности.
Сейчас я вообще сомневаюсь в жизнеспособности всей это надувной "vR революции", имхо все угомонятся как с 3D телевизорами.
Открывать исходники — это если уж если костюм совсем в шкафу залежится.
На счет подобных проектов — да много их уже, и расписывать о них стоит в отдельной статье, но все они отличаются друг от друга ровно как нынешние шлемы виртуальной реальности.
Сейчас я вообще сомневаюсь в жизнеспособности всей это надувной "vR революции", имхо все угомонятся как с 3D телевизорами.
Я в игры практически не играю, VR не слишком интересуюсь, мне ваш проект интересен с точки зрения как раз таки захвата движения для анимации и кино. Форматов действительно куча, просто BVH — один из самых примитивных, он почти везде поддерживается, в случае чего можно конвертировать во всё что угодно уже в 3д редакторе, FBX это всё же формат для 3д моделей в общем, а не конкретно скелетной анимации. От статьи про мокап костюмы не отказался бы, тем более от человека в теме.
Я не совсем понял что вы имеете в виду под «движухой», но сейчас самый пик для стартапов по теме VR — первые партии Oculus Rift уже отправлены покупателям, и скоро они захотят «расширить функционал», full-body трэкинг для VR это то чего «в коробке» не предлагает ни Oculus, ни HTC, ни Sony. Есть целевая аудитория, а у вас практически есть решение в железе, с чётким осознанием что осталось доделать.
Во первых, на вашем месте, я бы отправил короткую презентацию вашего проекта в Oculus и HTC с просьбой предоставить дев-кит их очков, для помощи в разработке и тестировании. За «спросить» денег не берут, а вы можете как получить неплохой гаджет (и тем самым оживить собственный интерес к теме) так и получить предложение работы.
Во вторых серьёзней оцените возможность запуска стартапа на кикстартере. Я могу ошибаться, но мне кажется в вашем костюме бюджет всего железа — до 50ти баксов. За $99 баксов вы пару сотен таких китов точно продадите, пощупаете рынок, получите неплохой капитал для продолжения самостоятельной работы.
Во первых, на вашем месте, я бы отправил короткую презентацию вашего проекта в Oculus и HTC с просьбой предоставить дев-кит их очков, для помощи в разработке и тестировании. За «спросить» денег не берут, а вы можете как получить неплохой гаджет (и тем самым оживить собственный интерес к теме) так и получить предложение работы.
Во вторых серьёзней оцените возможность запуска стартапа на кикстартере. Я могу ошибаться, но мне кажется в вашем костюме бюджет всего железа — до 50ти баксов. За $99 баксов вы пару сотен таких китов точно продадите, пощупаете рынок, получите неплохой капитал для продолжения самостоятельной работы.
Судя по всему, вам пора кооперироваться с производителями очков и игроделами. Интересные MMO проекты можно сделать…
Я открыт для любых предложений :)
Можете создать такой же костюм для захвата движения всего человека?
Могу. Сейчас используются только 11 датчиков, устройство рассчитано на 15 (кисти и стопы не отслеживаются). Остаются только пальцы, сгибы которых можно определять с помощью специальных перчаток, или тем же Leap3D.
Получить бы что-то такое, только по-бюджетнее
https://neuronmocap.com/content/product/32-neuron-alum-edition
https://neuronmocap.com/content/product/32-neuron-alum-edition
Это как раз один из тех проектов, которые вылезли за период разработки. Имхо не стоит он своих денег, хотя использованы 32 датчика. Из них 16 только на кисти рук — это я считаю избыточность.
Пока только отличие в количестве сенсоров, 15 против 32. Ну красиво все у них, да.
Пока только отличие в количестве сенсоров, 15 против 32. Ну красиво все у них, да.
вот на хабре про них https://habrahabr.ru/post/236423/
в период их "кикстартерства" они говорили что цены поднимутся в пределах 40%, но в реале увидели, почти 300 %
в период их "кикстартерства" они говорили что цены поднимутся в пределах 40%, но в реале увидели, почти 300 %
Расскажите, как победили дрейф нуля у гироскопов на длительных периодах (2+ часа) без использования дополнительных магнитных датчиков?
С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.
Длительные периоды не предполагались, но способ с программной компенсацией хоть как-то улучшил ситуацию. Могу заметить еще такой момент, чем выше частота работы сенсоров, тем быстрее они (логично) дрейфуют. Мну был нужен реалтайм, поэтому датчики опрашиваются раз 30 в секунда (при 50 уже не такие стабильные значения), если же режим реального времени не так важен, и нужно использовать сенсор на длительной период, то можно понизить частоту его работу, хоть до 1 опроса в секунду.
Молодец, глянул ранее на булке, классный проект!
Не думал о Esp8266 и передачи данных по wifi?
Не думал о Esp8266 и передачи данных по wifi?
Спасибо! Я как раз видел на ютубе твои эксперименты с Esp8266.
Конечно думал, уже лежит 12-версии и 1 9-ти осевой сенсор, если подружу их — то вообще здорово, будет множество автономных сенсоров, независимых друг от друга, в этом и заключается идея второго прототипа. Если подружить не получиться, наверное буду использовать контроллеры для связи между mpu и esp, а esp будет как uart-wifi транслятор.
Конечно думал, уже лежит 12-версии и 1 9-ти осевой сенсор, если подружу их — то вообще здорово, будет множество автономных сенсоров, независимых друг от друга, в этом и заключается идея второго прототипа. Если подружить не получиться, наверное буду использовать контроллеры для связи между mpu и esp, а esp будет как uart-wifi транслятор.
Во-первых, хочу выразить свое восхищение — рабочий, красиво выглядящий (!!) прототип за пол года — потрясающе.
Кроме того хочу спросить пару технических деталей:
1) Что в итоге отдает датчик движения, что с этим делает центральный контроллер, и что получает комп. На особых подробностях не настаиваю, но буду признателен :)
2) Я погуглил по дмп и MPU-6050, и как-то там глухо — если можете, поделитесь информацией как оно работает (ну или где почитать, можно на англ). Вообще, техническая статья про то как из датчика-акселерометра получается кватернионы, я думаю, будет принята с признательностью не одним мной
3) На компе, вы как-то заботитесь о том чтобы «человечек» стыковался как следует, или углы настолько хорошо определяются что можно просто поворачивать палочки-руки/ноги? Кватернионы — это тупо вращения, а вокруг чего вращать то? Хотя если MPU передает скорость, то тогда все проще. В общем, если не затруднит, расскажите по-подробней как сырые данные переходят в человечка.
Кроме того хочу спросить пару технических деталей:
1) Что в итоге отдает датчик движения, что с этим делает центральный контроллер, и что получает комп. На особых подробностях не настаиваю, но буду признателен :)
2) Я погуглил по дмп и MPU-6050, и как-то там глухо — если можете, поделитесь информацией как оно работает (ну или где почитать, можно на англ). Вообще, техническая статья про то как из датчика-акселерометра получается кватернионы, я думаю, будет принята с признательностью не одним мной
3) На компе, вы как-то заботитесь о том чтобы «человечек» стыковался как следует, или углы настолько хорошо определяются что можно просто поворачивать палочки-руки/ноги? Кватернионы — это тупо вращения, а вокруг чего вращать то? Хотя если MPU передает скорость, то тогда все проще. В общем, если не затруднит, расскажите по-подробней как сырые данные переходят в человечка.
Большое спасибо!
1) После всех манипуляций и конфигураций dmp, сенсоры отдают свои углы в пространстве в виде кватерниона. Это dmp умеет "из коробки" и позволяет не заботиться о шарнирном замке. Центральный контроллер поочередно получает данные с каждого сенсора, запаковывает это все и отправляет по bluetooth на приемник много раз в секунду, никаких вычислений практически не производит.
2) В том-то и дело, информации мало. Это только в последнее время что-то появляется, за счет моды на DIY квадрокоптеры и прочее. В первую очередь много полезного нашел на . А так же тут
3) На компе много о чем приходиться заботиться, т.к. по факту имеем только углы поворота всех сенсоров. Трекинг в пространстве сделан программно (пока не идеален, нужны сенсоры на стопы)
MPU передают только углы в виде кватерниона, все остальное уже на стороне приемника.
1) После всех манипуляций и конфигураций dmp, сенсоры отдают свои углы в пространстве в виде кватерниона. Это dmp умеет "из коробки" и позволяет не заботиться о шарнирном замке. Центральный контроллер поочередно получает данные с каждого сенсора, запаковывает это все и отправляет по bluetooth на приемник много раз в секунду, никаких вычислений практически не производит.
2) В том-то и дело, информации мало. Это только в последнее время что-то появляется, за счет моды на DIY квадрокоптеры и прочее. В первую очередь много полезного нашел на . А так же тут
3) На компе много о чем приходиться заботиться, т.к. по факту имеем только углы поворота всех сенсоров. Трекинг в пространстве сделан программно (пока не идеален, нужны сенсоры на стопы)
MPU передают только углы в виде кватерниона, все остальное уже на стороне приемника.
Ваши ссылки не отобразились :(
Да, я заметил что он ногами проскальзывает (и, я так понимаю, прыгать не умеет?)
Мм, я тут посмотрел, есть штука https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/MPU6050.h
И в этой штуке есть функции типа «GetAccel...» Оно скорее всего не проходит через DMP и требует фильтрации, да и вообще не понятно, но наверно лучше чем ничего?
Да, я заметил что он ногами проскальзывает (и, я так понимаю, прыгать не умеет?)
Мм, я тут посмотрел, есть штука https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/MPU6050.h
И в этой штуке есть функции типа «GetAccel...» Оно скорее всего не проходит через DMP и требует фильтрации, да и вообще не понятно, но наверно лучше чем ничего?
www.i2cdevlib.com
www.geekmomprojects.com/mpu-6050-redux-dmp-data-fusion-vs-complementary-filter
Из-за отсутствия датчиков на стопах (используются 11 из 15). Прыгать умеет, но перемещается только в плоскости.
В правильном направлении идете, все верно. Но там же есть и dmpGetAccel :)
www.geekmomprojects.com/mpu-6050-redux-dmp-data-fusion-vs-complementary-filter
Из-за отсутствия датчиков на стопах (используются 11 из 15). Прыгать умеет, но перемещается только в плоскости.
В правильном направлении идете, все верно. Но там же есть и dmpGetAccel :)
Привет! Я тоже был на НТТМе. У меня есть несколько вопросов. Напиши мне в вк: vk.com/tvisf
М… Да…
Мы когда то в конторе пытались реализовать нечто подобное, но увы… Побоялись сложности проекта (12 человек) а Вы в одиночку потянули проект и в принципе у Вас готовый прототип для первого релиза. Не останавливайтесь не в коем случае. Это уже готовый проект для монетизации.
Сделайте последний шаг. Я даже скинул эту статью паре серьезных контор за бугром. Может заинтересуются.
Еще раз повторюсь, Я в шоке.
Мы когда то в конторе пытались реализовать нечто подобное, но увы… Побоялись сложности проекта (12 человек) а Вы в одиночку потянули проект и в принципе у Вас готовый прототип для первого релиза. Не останавливайтесь не в коем случае. Это уже готовый проект для монетизации.
Сделайте последний шаг. Я даже скинул эту статью паре серьезных контор за бугром. Может заинтересуются.
Еще раз повторюсь, Я в шоке.
Спасибо за отзыв! В особенности за распространение.
В данном случае моя одержимость идеей переборола страхи, хотя бывали моменты когда "ну совсем ничего не получалось", без этого никуда.
Я как раз таки остановился, ибо слабо представляю что делать дальше, о каком последнем шаге идет речь?
Еще раз спасибо :)
В данном случае моя одержимость идеей переборола страхи, хотя бывали моменты когда "ну совсем ничего не получалось", без этого никуда.
Я как раз таки остановился, ибо слабо представляю что делать дальше, о каком последнем шаге идет речь?
Еще раз спасибо :)
К этому добавить шлем VR, беговой шар, и можно играть в ММО игры на выносливость :)
Для подключения большого числа датчиков удобно использовать 16 канальный(для 15 датчиков) мультиплексор/демультиплексор. На нём вы 4 пинами задаёте двоичное число(номер датчика) и он соединяет пин от нужного датчика с управляющим пином. Цена такой микросхемки 30р и она заменяет вашу сложную схему с кучей транзисторов.
Также вы рвёте все пины от датчиков(как я понял по схеме), а достаточно разорвать только пин, по которому от него приходит ответ.
Ещё вместо i2c лучше использовать spi интерфейс. I2c гораздо медленнее и в arduino он реализован программно.
Также вы рвёте все пины от датчиков(как я понял по схеме), а достаточно разорвать только пин, по которому от него приходит ответ.
Ещё вместо i2c лучше использовать spi интерфейс. I2c гораздо медленнее и в arduino он реализован программно.
Использование транзисторов — это лишь пробный период, внимательнее прочитайте раздел статьи "Контроллер".
В данном случае с I2C приходится рвать 2 пина.
Стандартная библиотека wire действительно не отличается скоростью, поэтому я использовал стороннюю i2cdevlib. Spi интерфейс не предусмотрен на mpu6050, и насколько мне известно проблема c адресами сохраняется.
В данном случае с I2C приходится рвать 2 пина.
Стандартная библиотека wire действительно не отличается скоростью, поэтому я использовал стороннюю i2cdevlib. Spi интерфейс не предусмотрен на mpu6050, и насколько мне известно проблема c адресами сохраняется.
Класно! Не пробовали компенсировать дрейф несколькими разнонаправленными датчиками в точке? я с mpu9255 хотел так попробовать, но руки не дошли.
Это просто шедеврально! Можем обменяться контактами для обсуждения вашего проекта?
Шикарная реализация сложной задачи. Рекомендую задуматься о коммерческой версии, я бы приобрел такой костюм. Аналоги стоят неподъемных денег.
… Напиши мне на почту свои контакты, попробуем свести тебя с нужными людьми. s2sa@rambler.ru
Осталось добавить сенсорные перчатки:
https://geektimes.ru/post/258608/
:)
Превосходно! Сделать такое на ардуинке...
https://geektimes.ru/post/258608/
:)
Превосходно! Сделать такое на ардуинке...
Sign up to leave a comment.
Как я делал костюм захвата движений