Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Совет, попробуйте для калибровки наложить на датчики qr-коды или что по проще, и снимать себя несколькими FullHD/8k-камерами (хотя последнее может быть дорого) и вычислять положение уже по изображениям.
Получится что-то вроде kinect но с обычными камерами?
Недавно в статье об умных комбайнах писали, что для решения их задачи оказалось достаточно только изображения с камер без спутниковой навигации
Вот честно — не представляю, какие ресурсы нужны, чтобы, например с 3-х 8k камер в режиме реального времени отслеживать маркеры, поворачивать и распознавать их. Что-то вроде 2-х процессорного сервера на Xeon Silver?
Опять же в этом случае нужно «готовить» помещение, для расчета математики на лету.
Опять же в этом случае нужно «готовить» помещение, для расчета математики на лету.
Для КАЛИБРОВКИ реального времени не нужно!
К сожалению даже HD камер не хватит никаких процессоров для реалтайма, так как для адекватной отзывчивости игр требуется не больше пары десятков миллисекунд
Теоритически можно что то сделать с gpgpu, если вы сможете получить сырой поток uncompressed от камеры напрямую в видеокарту и там его анализировать, львиное время тут будет тратиться именно на доставку видеопотока от камеры до видеопроцессора.
Я точно видел проекты распознавания ярких точек в реалтайме (30-60fps) на основе дешевых микроконтроллеров и не fullhd камер, т.е. устанавливаем отражатели в целевых точках и светим на них от камеры.
Если вы найдете soc платы с процессором, поддерживающим fpga и прямым доступом к CMOS HD камеры то большие шансы что можно сделать сверхбыстрое и достаточно точное (миллиметры погрешности на расстоянии метры) распознавание координат.
К сожалению даже HD камер не хватит никаких процессоров для реалтайма, так как для адекватной отзывчивости игр требуется не больше пары десятков миллисекунд
Теоритически можно что то сделать с gpgpu, если вы сможете получить сырой поток uncompressed от камеры напрямую в видеокарту и там его анализировать, львиное время тут будет тратиться именно на доставку видеопотока от камеры до видеопроцессора.
Я точно видел проекты распознавания ярких точек в реалтайме (30-60fps) на основе дешевых микроконтроллеров и не fullhd камер, т.е. устанавливаем отражатели в целевых точках и светим на них от камеры.
Если вы найдете soc платы с процессором, поддерживающим fpga и прямым доступом к CMOS HD камеры то большие шансы что можно сделать сверхбыстрое и достаточно точное (миллиметры погрешности на расстоянии метры) распознавание координат.
Oculus Rift использует 3 FullHD камеры (без цвета) и всё это вполне работает на 60Гц.
Оптика не заменяет акселерометры, а дополняет их. Оптика — 60Гц, акселерометры — 1000Гц.
При этом собственно oculus sensor можно заставить определяться как видеокамеру (он собственно и есть видеокамера), поэтому вся обработка происходит не в нём.
Оптика не заменяет акселерометры, а дополняет их. Оптика — 60Гц, акселерометры — 1000Гц.
При этом собственно oculus sensor можно заставить определяться как видеокамеру (он собственно и есть видеокамера), поэтому вся обработка происходит не в нём.
Там железо свое анализирует поток с камер, вы знаете что из общедоступного задешево можно самодельщикам найти? и даже в этом случае готовый софт наверное не найдете, а пилить самому не просто.
Камера с WiiMote есть за недорого. Отслеживает до 4-х точек одновременно с разрешением 1024х768, углы обзора 33х23 градуса.
его же хрен купишь кроме как с рук
По ссылке не сходили? Китайцы уже все сделали, готовый модуль и библиотека под Arduino. Правда цена в два раза выше китайского Wiimote в сборе ;)
зашел
Resolution is 128x96 pixel, with hardware image processing, which can track four objects (IR emitting or reflecting objects)
Это физическое разрешение сенсора, он с аппаратной обработкой и отдает потом разрешение в 1024х768. Этот же сенсор (или аналог) используется в WiiMote.
Кстати у этого производителя PixArt Imaging Inc. — есть сенсоры с физическим разрешением 98х98 пикселей, но отдают картинку разрешением 4096х4096, с 16 отслеживаемых точек одновременно.
Кстати у этого производителя PixArt Imaging Inc. — есть сенсоры с физическим разрешением 98х98 пикселей, но отдают картинку разрешением 4096х4096, с 16 отслеживаемых точек одновременно.
Наверное тут все же речь идет не о картинке а о угловом разрешении координат вычисляемых источников освещения? Потому что картинку тут вообще не нужно передавать.
Потому что когда я слышу о растровом разрешении, я сразу добавляю возможности использования полутонов для вычисления координат. Кстати при этом погрешности в граничных ситуациях плохие, т.е. если будет паразитная засветка или еще какие помехи, будут глюки.
Потому что когда я слышу о растровом разрешении, я сразу добавляю возможности использования полутонов для вычисления координат. Кстати при этом погрешности в граничных ситуациях плохие, т.е. если будет паразитная засветка или еще какие помехи, будут глюки.
Обычный oculus sensor железом разве что занижает разрешение камеры. На ПК через USB идёт обычный поток видео. Вся обработка — софтовая.
Update: doc-ok.org/?p=1138
Update: doc-ok.org/?p=1138
Не совсем понимаю зачем QR коды. Да и камеры с такими высокими разрешениями. «контроллеры» у нас однозначные, калибруем их без человека, одеваем на нужные места и всё. обычной световой индикации хватит чтоб сопоставить, так как мы знаем что контроллер 1.1 будет в нижней части. Остальное дело техники.
с PsEye и мувами что то подобное на пк и делают www.youtube.com/watch?v=JuQQM32k2mU
с PsEye и мувами что то подобное на пк и делают www.youtube.com/watch?v=JuQQM32k2mU
Все таки правильно говорят «утро вечера мудренее». Я все таки понял что вы советуете — поправьте меня, если я не так понял.
В моем проекте «калибровка» — это соответствие положения датчика и человека в позе «Т». Для этого я сейчас использую нажатие кнопки и задержку в пару секунд, чтобы принять положение правильное.
Если мы снимаем на обычную вебку человека, то для сопоставления позы и начальной позиции, достаточно распознать что человек принял нужную стартовую позу. Можно даже обойтись без маркеров, таких как QR-код или светодиод. Отличная идея, спасибо!
В моем проекте «калибровка» — это соответствие положения датчика и человека в позе «Т». Для этого я сейчас использую нажатие кнопки и задержку в пару секунд, чтобы принять положение правильное.
Если мы снимаем на обычную вебку человека, то для сопоставления позы и начальной позиции, достаточно распознать что человек принял нужную стартовую позу. Можно даже обойтись без маркеров, таких как QR-код или светодиод. Отличная идея, спасибо!
и вам будет достаточно этой точности?
я считал что калибровка — это определение дельты для совмещения реальных координат с теми что выдают датчики.
пример — вы встаете в позу T, вопрос, то что вы при этом руки сделаете не параллельны земле вас не волнует?
я считал что калибровка — это определение дельты для совмещения реальных координат с теми что выдают датчики.
пример — вы встаете в позу T, вопрос, то что вы при этом руки сделаете не параллельны земле вас не волнует?
вообще есть очень дещовый вариант от Клапана Steamvr tracking. Он весьма круто работает и легко вычесляется + по железу нужны лиш TS4112 и контролер для вычисления положения по данным с них.
Насколько это точнее чем тупо нацепить на себя уйму lighthouse-шайб?
Используется своя модель вместо готовых full body tracking-совместимых аватаров для того же vrchat'а? Опять же, для повышенной точности без всяких dynamic bone?
Используется своя модель вместо готовых full body tracking-совместимых аватаров для того же vrchat'а? Опять же, для повышенной точности без всяких dynamic bone?
Данные «шайбы» чисто оптические девайсы. Уверен, что их огромное количество в поле зрения камер — не оправдает данный подход. Именно поэтому существуют проекты по прямой и обратной кинематике с двумя подобными трекерами на ступнях, за счет ограничений физических человеческого тела (кстати я не вводил их — это существенно улучшит позиционирование).
Как минус вышеупомянутых устройств то, что из них нельзя забирать ускорения из конечностей и они обязательно должны быть видны камерам.
Как минус вышеупомянутых устройств то, что из них нельзя забирать ускорения из конечностей и они обязательно должны быть видны камерам.
Они не в поле зрения камер, они и есть недокамеры (на деле — тупо набор IR-датчиков) + акселерометры (поэтому в какой-то степени работают даже если lighthouse слегка исчезнет из поля зрения) + софт.
Вроде как раньше поддерживалось до 16 штук (минус шлем и два контроллера = 13), потом подняли лимит до 64.
Вроде как раньше поддерживалось до 16 штук (минус шлем и два контроллера = 13), потом подняли лимит до 64.
Очень даже может быть. Такой себе WiiMote с обзором 360/180, тогда понятно откуда такая цена.
Относительно точности — у меня сейчас в контроллерах стоит отправлять данные только если есть изменения около 1 градуса. Если понизить до десятитысячной единичного кватерниона — будет около 0.1 градуса, но в таком случае идет постоянная передача данных — Blender начинает «тупить».
Относительно точности — у меня сейчас в контроллерах стоит отправлять данные только если есть изменения около 1 градуса. Если понизить до десятитысячной единичного кватерниона — будет около 0.1 градуса, но в таком случае идет постоянная передача данных — Blender начинает «тупить».
Такая цена диктуется исключительно рынком. На деле весь lighthouse — набор IR-диодов (делает вспышку), 1 IR лазер с мотором (делает сканирование) и немного обвязки для управления этим. Совместимые девайсы, включая эти шайбы, тупо считают задержку между «вспышкой» и «сканированием» на IR-сенсорах (которых много тупо чтобы хоть несколько из них видели маяк). И это всё используется для компенсации дрифта акселерометров потому, что для собственно отслеживания 100Гц — мало.
На деле железо для того, чтобы это повторить, должно быть дёшево, но я подозреваю, что это всё запатентовано по уши.
Proof-of-concept DIY датчики (без акселерометров) давали ~2мм точность.
На деле железо для того, чтобы это повторить, должно быть дёшево, но я подозреваю, что это всё запатентовано по уши.
Proof-of-concept DIY датчики (без акселерометров) давали ~2мм точность.
Вот наверное поэтому и я не стал использовать фильтры. Мне наверно тупо не хватает мозгов понять что внутри них происходит.
Для варианта Kat Loco вообще расчеты не нужно,быстро не смог найти поищите историю одного японца который получил на одном акселерометре в WiiMote точность распознавания жестов под 95%.
P.S. Я от просмотра тремора конечностей на видео чуть не вырвал… А концепция интересная — да.
Для варианта Kat Loco вообще расчеты не нужно,
P.S. Я от просмотра тремора конечностей на видео чуть не вырвал… А концепция интересная — да.
Инерциальные датчики очень быстрые и хорошо отслеживают изменение положения, но не само положение. Для этого нужны медленные, но точные оптические камеры. Только такая коммбинация даст хороший результат. К ней в итоге и пришли все производители VR-устройств. С телом все то же самое — только датчиков больше и задача в итоге сложнее.
Ну и фильтр Калмана или подбный обязателен для сведения всех сенсоров.
Пытаться делать на встроенном фильтре DMP — это ИМХО вообще тупик. Фильтр не учитывает специфику задачи, он скорее для умных устройств подходит.
Ну и фильтр Калмана или подбный обязателен для сведения всех сенсоров.
Пытаться делать на встроенном фильтре DMP — это ИМХО вообще тупик. Фильтр не учитывает специфику задачи, он скорее для умных устройств подходит.
Технически, ещё живы VR-устройства без камер вообще и та же htc говорит, что не собирается сворачивать линейку lighthouse-девайсов.
Относительно камер чуть выше написал. Мое мнение что будущее все таки за IMU + оптические сенсоры, упомянутые в моем комментарии.
Lighthouse классная вещь. Но смысл такой же, только не камера видит сенсор, а сенсор видит излучающий сканирующий луч с базовых станций. Как и с камерами, будут сложности с затенением датчиков, т.е. нужно много базовых станций размещать и много датчиков на каждом узле. На VR-шлеме их достатончо много, например.
Я кстати уже подумываю дополнить. Есть пара камер которые могут 1080p с 30 FPS. Мне ведь нужно понимать перемещения (думаю будет лучше если связать камеры и акселерометр) + компенсировать повороты по оси Z (так как все равно плывут) + сделать ограничения как у человека.
Камера дает текущую позицию всех датчиков в своей проекции, нужно как минимум две камеры для триангуляции. Для референсной ориентации нужно использовать информацию с двух сенсоров на кости, но это не дает кватернион, а дает только два степени свободы из трех. В общем, задачка еще та. Много нужно достраивать в условиях нехватки информации.
Поэтому и написал
Есть пара камер
Если использовать полноценные камеры то вместо точечных источников света можно использовать линейные — т.е. полоска, а еще помним камеры цветные, это значит можно использовать цвет и переходы, вот уже не только угол но и направление.
Т.е. достаточно на кисти рук закрепитьполоску с градиентом перехода от одного цвета к другому (это будет идентификатор и направление) то две камеры смогут дать достаточную информацию о положении кисти руки
но к сожалению не существует доступного железа чтобы проделывать эти вычисления в реальном времени хотя бы со скоростью обработки видеокадров в 30fps, от силы десяток для 720HD на мощном процессоре с видеоускорением.
Т.е. достаточно на кисти рук закрепитьполоску с градиентом перехода от одного цвета к другому (это будет идентификатор и направление) то две камеры смогут дать достаточную информацию о положении кисти руки
но к сожалению не существует доступного железа чтобы проделывать эти вычисления в реальном времени хотя бы со скоростью обработки видеокадров в 30fps, от силы десяток для 720HD на мощном процессоре с видеоускорением.
Там 2мбит камера и порядка 10 кадров в секунду, но да, проект впечатляющий.
В реалтайме брать данные из камер, огромная проблема в том, что тратится приличное время на декодирование и перевод в необходимый формат плюс загрузка в GPU, даже на низком уровне это приличные задержки, а еще нужно время на обработку собственно сигнала (спасибо детектирование ярких пятен с градиентой все же простой алгоритм).
Я говорил о железе, в который можно подать сырой поток с CMOS чипа камеры прямо в память процессора или даже видеопроцессора.
В реалтайме брать данные из камер, огромная проблема в том, что тратится приличное время на декодирование и перевод в необходимый формат плюс загрузка в GPU, даже на низком уровне это приличные задержки, а еще нужно время на обработку собственно сигнала (спасибо детектирование ярких пятен с градиентой все же простой алгоритм).
Я говорил о железе, в который можно подать сырой поток с CMOS чипа камеры прямо в память процессора или даже видеопроцессора.
Вы слишком усложнили решение, так как ошиблись с определением времени опроса датчика.
Согласно документации, минимальная задержка составляет 0.1ms, т е 200 раз меньше, чем Вы посчитали.
Кроме того, все модули датчиков можно по SPI или I2C подключить к одной ESP8266.
В итоге набор железа для костюма с 16 датчиками обойдется всего в 50 долларов.
Используя передачу данных по ESP-NOW либо UDP получите задержку не более 0.01 сек, что эквивалентно 100 кадрам в секунду.
Согласно документации, минимальная задержка составляет 0.1ms, т е 200 раз меньше, чем Вы посчитали.
Кроме того, все модули датчиков можно по SPI или I2C подключить к одной ESP8266.
В итоге набор железа для костюма с 16 датчиками обойдется всего в 50 долларов.
Используя передачу данных по ESP-NOW либо UDP получите задержку не более 0.01 сек, что эквивалентно 100 кадрам в секунду.
Дело не во времени опроса — дело во времени передачи буфера размером 48 Байт 50 раз в секунду по шине I2C.
Датчики MPU-9250 имеют один неизменяемый адрес и все датчики нужно было подключать через мультиплексор, я об этом писал в статье.
Хотелось избавиться от проводов, как в Perception Neuron — что сильно упрощает снятие/надевание костюма.
Датчики MPU-9250 имеют один неизменяемый адрес и все датчики нужно было подключать через мультиплексор, я об этом писал в статье.
Хотелось избавиться от проводов, как в Perception Neuron — что сильно упрощает снятие/надевание костюма.
1) шина I2C как минимум 400 кГц это 40 000 байт в секунду, а у вас всего 2500 байт в секунду.
2) есть еще у MPU-9250 SPI, это еще в 20 раз быстрее.
2) есть еще у MPU-9250 SPI, это еще в 20 раз быстрее.
Мне кажется или вы "не читатель"?
Кроме забора данных, их ещё нужно обработать и переслать. Да и можно просто взять и переписать пару библиотек под SPI шину, потратить несколько месяцев на отладку, просто потому что вся передача данных не вмещается в I2C.
SPI для данного датчика работает на частоте 1 МГц.
и еще
у вас 16 шт ESP каждая потребляет 330 ма в режиме передача и 80 ма в режиме приема по wifi, т е ваш костюм кушает от 1A*h до 4 Аh.
Очевидно что одна ESP кушает в 16 раз меньше и не забивает эфир, как в случае 16 штук.
У Вас получилась отличная глушилка для соседей.
Более того, у ESP приемник и передатчик работают на одном и том же канале.
Работа 16 ESP приведет к коллизии в эфире и потере данных.
у вас 16 шт ESP каждая потребляет 330 ма в режиме передача и 80 ма в режиме приема по wifi, т е ваш костюм кушает от 1A*h до 4 Аh.
Очевидно что одна ESP кушает в 16 раз меньше и не забивает эфир, как в случае 16 штук.
У Вас получилась отличная глушилка для соседей.
Более того, у ESP приемник и передатчик работают на одном и том же канале.
Работа 16 ESP приведет к коллизии в эфире и потере данных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Моя версия костюма отслеживания движений