Как стать автором
Обновить
27
0

Пользователь

Отправить сообщение
Беговой шар не обязателен, если есть открытая местность)
Спасибо за отзыв! В особенности за распространение.
В данном случае моя одержимость идеей переборола страхи, хотя бывали моменты когда "ну совсем ничего не получалось", без этого никуда.
Я как раз таки остановился, ибо слабо представляю что делать дальше, о каком последнем шаге идет речь?
Еще раз спасибо :)
www.i2cdevlib.com
www.geekmomprojects.com/mpu-6050-redux-dmp-data-fusion-vs-complementary-filter
Из-за отсутствия датчиков на стопах (используются 11 из 15). Прыгать умеет, но перемещается только в плоскости.
В правильном направлении идете, все верно. Но там же есть и dmpGetAccel :)
Верно, среда благоприятная и уже есть несколько стартапов на том же кикстартере с full-body системами, некоторые из них совершеннее мой поделки. На кикстартер выходов у меня нет, а то что те же Oculus откликнуться — слабо верится. Себестоимость 150$, может чуть поменьше.
Можно много чего сделать и довести все до ума, но я признаться устал от проекта. На стороне приемника предусмотрен "стрим" данных в сеть, т.е. подцепиться можно практически из любой среды, а вот экспорт вещь необходимая — согласен. Пока есть свой текстовый и бинарный вид, где хранятся записанные анимации в видео углов поворота датчиков во фреймах времени, возможно из этого материала получиться наладить экспорт.
Рад видеть земляка, отписал.
Большое спасибо!
1) После всех манипуляций и конфигураций dmp, сенсоры отдают свои углы в пространстве в виде кватерниона. Это dmp умеет "из коробки" и позволяет не заботиться о шарнирном замке. Центральный контроллер поочередно получает данные с каждого сенсора, запаковывает это все и отправляет по bluetooth на приемник много раз в секунду, никаких вычислений практически не производит.
2) В том-то и дело, информации мало. Это только в последнее время что-то появляется, за счет моды на DIY квадрокоптеры и прочее. В первую очередь много полезного нашел на . А так же тут
3) На компе много о чем приходиться заботиться, т.к. по факту имеем только углы поворота всех сенсоров. Трекинг в пространстве сделан программно (пока не идеален, нужны сенсоры на стопы)
MPU передают только углы в виде кватерниона, все остальное уже на стороне приемника.
Я открыт для любых предложений :)
Спасибо! Я как раз видел на ютубе твои эксперименты с Esp8266.
Конечно думал, уже лежит 12-версии и 1 9-ти осевой сенсор, если подружу их — то вообще здорово, будет множество автономных сенсоров, независимых друг от друга, в этом и заключается идея второго прототипа. Если подружить не получиться, наверное буду использовать контроллеры для связи между mpu и esp, а esp будет как uart-wifi транслятор.
С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.

Длительные периоды не предполагались, но способ с программной компенсацией хоть как-то улучшил ситуацию. Могу заметить еще такой момент, чем выше частота работы сенсоров, тем быстрее они (логично) дрейфуют. Мну был нужен реалтайм, поэтому датчики опрашиваются раз 30 в секунда (при 50 уже не такие стабильные значения), если же режим реального времени не так важен, и нужно использовать сенсор на длительной период, то можно понизить частоту его работу, хоть до 1 опроса в секунду.
Конкретно с того периода исходники не остались, но я точно помню что пользовался статьей, где была реализация на Си, но это все на забугорных форумах)
Угол по оси Y вычисляются программно*
Спасибо!
Да я элементарно на какую-либо игровую выставку или конференцию не имею выхода и возможности участия. На местных уже все знают, но это потолок. Пробовал проект в качестве стартапа, но дальнейшего развития не вижу, не понравилась вся эта движуха.
Спасибо!
С помощью программной компенсации, т.е. костюм в состоянии покоя передавал данные, определялся дрейф, например 0.01градус/сек., далее это значение просто вычиталось каждую секунду. Метод себя не совсем оправдал, т.к. величина дрейфа зависит от движений датчика, если его сильно трясти или вертеть, то и дрейфовать он может непредсказуемо. Проблема решается 9-ти освевым датчиками, которые на аппаратном уровне компенсируют дрейфы.
На счет второй проблемы — она куда проще дрейфов, ее я решил в голове еще за долго до того, как она предстала передо мной. Для начала, в 3D модели соответствующая кость должна иметь якорь, который повернут так же, как реальный датчик (например на ноге он закреплен вертикально, так и на модели якорь повернут вертикально, так же со всеми осями) Далее когда начинается трекинг, мы получаем значения с сенсоров, берем разницу между полученными углами с сенсора и углами кости 3D-модели и вычитаем ее из каждого полученного значения. Проще говоря — мы знаем что в самом начале нога должна быть повернута на 0 градусов, а с датчика пришло 45 — то мы запоминаем 45 и вычитаем их из каждого следующего значения. Есть нюанс с поворотом между 180 и -179 градусов, он тоже решаем.
Мне кажется такой Хабр как раз и закончился в 2012 году… Я постараюсь отвечать на конкретно интересующие вопросы, в статью вынес более общие моменты, хотя и не обошлось без ухода в подробности.
Фильтр калмана отпал за ненадобностью, датчики из коробки умеют комплементарный фильтр и dmp. Разве что можно использовать вторичную фильтрацию уже на приемнике.
Забыл раскрыть этот нюанс. Если коротко, то вертикальной оси Y не за что "заякориться", так горизонтальные оси отталкиваются от вектора гравитации, а ось Y ему сонаправленна. Вычисления угла по оси Y вычисляются программно, на основе осей X Z, а вот в 9-ти осевых датчиках (mpu9xxx) добавлен магнитометр, который встроен и сразу компенсирует дрейфы.
Спасибо! Да что кривить, действительно на коленке.
Не только угловые ускорения учитываются, акселерометр и гироскоп работают вместе, компенсирую друг-друга.
Необходимости в более производительной платформе пока нет, Atmega328 имеет достаточный ресурс, чтобы опрашивать 11 датчиков 50 раз в секунду и все это отсылать (контроллер практически ничего не вычислят, только переключается и отсылает данные, большую работу на себя берет dmp каждого датчика и софт на стороне приемника).

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность