Реальность — виртуальная и физическая. Проблемы взаимодействия

Виртуальная реальность замещает для человека физическую реальность, но при этом человек продолжает взаимодействовать с физической реальностью. Чем меньше виртуальная релаьность отличается от физических сигналов получаемых телом, тем сильнее погружение и восприятие виртуальной реальности. В тоже время современные методы взаимодействия с виртуальной реальностью достаточно примитивны и не могут обеспечить точного соответствия. Данная статья попытка обобщить мои мысли по поводу устройств взаимодействия с виртуальной реальностью и поделиться опытом работы над проектом костюма отслеживания полного положения тела с использованием акселерометров.

Небольшой экскурс в текущее положение дел

Еще с давних времен меня интересовала тема виртуальной реальности и взаимодействия с ней. В середине 90-х, еще в школе, когда мне в первые удалось попробовать шлем VFX1, я был впечатлен открывающимися возможностями, хотя этот опыт и был несколько подпорчен восстанием вестибулярного аппарата. С тех пор я с интересом следил за развитием направления. Думаю многие со мной согласятся, что виртуальная реальность (а так же дополненная реальность как ее развитие) является будущим взаимодействия человека и машины. Когда, в начале 2010-х, начался очередной всплеск интереса к виртуальной реальности, благодаря шлему Oculus Rift, я ожидал быстрого развития этой области. К сожалению новый рывок в основном свелся к играм, что объяснимо, т.к. игры являются ярчайшим примером виртуальной реальности и очевидным направлением ее развития. Это направление легко доступно и требует меньше ресурсов для получения осязаемого результата. Но эта концентрация на играх сильно ударила по всем остальным вариантам использования виртуальной реальности. В то же время, в области виртуальной реальности, наблюдается своего рода проблема курицы и яйца. Широкое распространение невозможно пока оборудование дорогое, а оборудование дорогое, потому что серийность низкая. Ограничение сценариев использования только играми еще сильнее снижает количество потенциальных пользователей. Тем не менее, в области разработки шлемов, заметен серьезный прогресс. В первую очередь интересен прогресс в области дешевого (и массового) шлемостроения. Здесь тон задает Meta Quest. Хоть как-то пытается с ними конкурировать PicoVR, за спиной которых стоит ByteDance с Тик-Током. Обе компании тесно связаны с социальными сетями и рассматривают виртуальную реальности в контексте своего основного бизнеса, что, в целом, тоже очевидное применение виртуальной реальности.

Несколько хуже обстоят дела с устройствами ввода для взаимодействия с виртуальной реальностью. Основным методом сейчас являются 6dof контроллеры, имеющие на борту несколько кнопок и джойстики разного вида. Этого достаточно для перемещения и взаимодействия с предметами внутри виртуальной реальности. В то же время такой подход имеет и некоторые недостатки. Контроллер может давать достаточно точные ощущения для виртуального инструмента, который можно держать в одной руке. Там же где необходимо взаимодействие с использованием двух рук, контроллеры могут причинять неимоверные боль и страдания. Например использование двуручного оружия в играх, когда необходимо соблюдать точное положение обоих контроллеров, чтобы прицелиться в противника. Не имея обратной связи в виде физического предмета соединяющего контроллеры, это может быть достаточно неприятным процессом. Подобные проблемы пытаются решать либо создавая специализированные контроллеры, повторяющие формы инструмента, либо делая дополнительную обвязку, позволяющую закрепить контроллеры в нужных местах и обеспечивающую необходимую обратную физическую связь. Все это еще больше удорожает и усложняет контроллеры, что не способствует широкому распространению подобных устройств. Еще больше данная проблема проявляется в случае дополненной реальности, где предполагается взаимодействие с реальным миром и реальными предметами. Для такого применения контроллеры вообще неприемлемы. Глупо было-бы считать, что никто не видит этой проблемы и не пытается ее решить. Есть разные варианты решения этой проблемы, но наиболее простым для разработчиков шлемов видится оптическое отслеживание кистей рук. И в какой-то мере оно даже работает, хоть и не без нареканий. В принципе оптическое отслеживание имеет проблемы, которые хоть и не делают его бесполезным, но серьезно осложняют жизнь. Отслеживаемый объект должен находиться в области видимости сенсора, что в реальной жизни не всегда возможно. Объект должен быть освещен в достаточной мере. Слишком много или слишком мало света и могут начаться проблемы с отслеживанием. Такой подход сносно работает при использовании оборудования в специально подготовленном помещении, но имеет явные проблемы при выходе из подготовленной области. Так отслеживание с помощью инфракрасных камер начинает давать сбои при выходе на солнце. И в принципе камеры плохо работают в сумерках или темноте. Кроме того анализ данных с камер с приличной частотой кадров, требует серьезных вычислительных ресурсов. Ресурсы затраченные на трекинг отбираются у основной задачи. Такие проблемы не способствуют более широкому распространению технологий виртуальной и дополненной реальности.

Обзор проекта костюма отслеживания положения тела на основе акселерометров

На мой взгляд выходом из данной ситуации мог бы стать переход на альтернативные способы отслеживания. Неплохой альтернативой видится восстановление положения тела по костям скелета на основе данных с акселерометров. Акселерометр постоянно фиксирует ускорение свободного падения и получая значение ускорений по разным осям мы можем восстановить направление вектора гравитации и вычислить отклонение сенсора от него. Это не сильно поможет нам в определении положения кистей рук, но если прикрепить сенсоры в ключевых точках скелета, мы можем получить ориентацию каждой из костей. Составив кинематическую цепь для человеческого скелета и зная ориентацию каждой из костей мы можем рассчитать позицию каждого сустава при помощи алгоритмов прямой кинематики. Добавив к костюму еще и перчатки мы можем вычислить положение и ориентацию кистей рук, которые должны совпасть с положением контроллеров в руках. Добавив кнопки на перчатки, которые можно нажимать той же рукой мы сможем эмулировать поведение контроллера не используя контроллер. Для подобного решения могут использоваться достаточно дешевые 6dof акселерометры, подключаемые по протоколу i2c.

Данная идея пришла мне в голову достаточно давно и так и оставалась идеей пока пару лет назад у меня не нашлось время ей позаниматься. Модули 6dof IMU были закуплены давно и дожидались своего времени, поэтому я решил по быстрому накидать прототип взяв микроконтроллер с беспроводным интерфейсом так же завалявшийся под рукой. Микроконтроллером завалявшимся под рукой оказался ESP32-S2, его, а так же горку закупленных модулей GY-521 на основе MPU-6050 я и решил использовать для прототипа. Как водится, проект сразу же пошел не в ту сторону. Внезапно оказалось, что MPU-6050 поддерживает только один бит адресации, а ESP32-S2 содержит только два i2c контроллера. Что давало в общей сложности возможность подключения 4-х сенсоров, чего явно не достаточно для эмуляции человеческого скелета. Но в замен MPU-6050 может выступать как i2c контроллер для подчиненного устройства. Оригинальная задумка в том, чтобы можно было подключать внешний магнитометр и забирать данные с него совместно с данными встроенного акселерометра и гироскопа. Эту возможность и было решено использовать для расширения количества датчиков. К вторичной шине каждого датчика можно подключить два дополнительных датчика второго уровня и получать с них данные через датчики первого уровня. Изначально я планировал использовать только один контроллер, поэтому даже в два уровня датчиков не хватало для полноценного скелета. Поэтому было решено использовать три уровня датчиков. Сказано-сделано. Была написана прошивка, прозрачно конфигурировавшая всю сеть датчиков, и собиравшая с них данные. К сожалению реальность немного разочаровала. Для получения данных со второго уровня требовались десятки транзакций на первом уровне. С третьим уровнем счет уже шел на тысячи. Но отказываться от такой замечательной идеи не хотелось. Поэтому пришлось задействовать второй i2c контроллер и отказаться от третьего уровня. После того как базовая функциональность была отработана я занялся сборкой прототипа. И тут отвратительная реальность вновь показала свое неприглядное лицо. Выяснилось, что на более-менее длинных линиях, использующихся в прототипе транзакции в первичной и вторичных шинах i2c начинали оказывать влияние друг на друга, что приводило к потерям транзакций и таймаутам на шине. После продолжительных плясок с различными проводами и попытками устроить экранирование решение нашлось в использовании прерывания. MPU-6050 имеет возможность сообщить о наличии новых данных путем подъема прерывания на выделенную линию.

Благодаря прерыванию удалось изрядно сократить количество транзакций на шинах и уменьшить количество коллизий, что позволило добиться сносной стабильности. К сожалению все эти развлечения заняли прилично времени и выделенное время плавно подходило к концу. Пора было возвращаться к нормальной работе. Поэтому проект пришлось отложить в долгий ящик. Периодически я пытался вернуться к проекту, но свободного времени категорически не хватало. Было ясно, что в таком виде проект не жизнеспособен нужно менять подход. Решение нашлось в виде заказанных на алиэкспрессе i2c муксеров. Почему идея использовать муксер не пришла мне в голову сразу я затрудняюсь ответить. Это очевидно, поскольку они именно для этого и предназначены. Могу только предположить, что идея с иерархией датчиков казалась очень красивой и я невольно стал заложником этого решения. В общем после некоторого промежутка времени необходимость использования муксера стала очевидной. Устройства были заказаны и некоторое время лежали, дожидаясь своего времени. В этом году я таки решил взять себя в руки и доделать уже наконец прототип. Тем более, что появились уже и похожие устройства, в частности Slime VR. К тому же у меня появилось некоторое количество свободного времени.

Собрав прототип с использованием муксера, перешел на хостовую часть. На хосте решил использовать Monado. Monado — это opensource OpenXR service, который поддерживает различное VR оборудование и может быть интегрирован со Steam при необходимости. Есть экспериментальная поддержка Windows и Android, но их пока не пробовал. OpenXR абстрагирует железо от приложения. Сервис взаимодействует с железом через набор драйверов и предоставляет приложению доступ к абстрактной информации через API на основе экшенов. Приложение запрашивает информацию о необходимых экшенах, а сервис связывает запрошенные экшены с наиболее подходящими из доступных в железе. Так экшеном является положение и ориентация контроллера и при изменение данная информация передается в приложение. Так же экшенами передается информация о нажатиях кнопок. В базе API OpenXR поддерживает только отслеживание кистей рук, но как и все API от Khronos Group может быть расширено.

Таким образом, из коробки отслеживание скелета невозможно, но может быть добавлено через расширение. Это расширение должно поддерживаться со стороны приложения. То есть приложение должно знать про кости скелета и осознанно подписаться на изменение их ориентации и позиции, чтобы использовать эту информацию для рендеринга модели в самом приложении. С другой стороны на основании информации о скелете мы можем вычислить позицию и ориентацию кистей рук и передавать ее с помощью стандартных экшенов для рук. Что позволяет эмулировать контроллеры для любых OpenXR приложений. В свою очередь Monado может интегрироваться в SteamVR через OpenVR драйвер и выступать как источник устройств. Так что, теоретически, любое устройство поддерживаемое в Monado, может быть использовано любым приложением SteamVR. После некоторых плясок с бубном вокруг прямой кинематики, прототип удалось запустить и записать демку в тестовом OpenXR приложении.

Заключение

Дальнейшее развитие проекта мне видится в сторону создания костюма, дешевого и удобного для повседневного использования. Такой костюм в базе уже может использоваться как дешевый аналог оборудования для Motion Capture с выгрузкой в файл анимации, пригодный для дальнейшего использования с имеющимся ПО для 3d моделирования. Сейчас профессиональное оборудование для захвата движений, стоит достаточно больших денег и требует специальных студий для проведения сеансов захвата. Это сильно ограничивает количество людей, которые могут воспользоваться захватом движений. Если добавить к костюму перчатки, способные отслеживать ориентацию кисти руки, мы можем рассчитать положение и ориентацию контроллеров и передать их в качестве стандартных экшенов для рук. Если добавить кнопок на перчатки, можно полностью заменить контроллеры и это будет работать в любом OpenXR приложении и через интеграцию со Steam в любом SteamVR приложении. Так же некоторые приложения, например VRChat, позволяют передавать информацию о положении костей скелета снаружи. Такой костюм так-же может служить источником данных для этих приложений через несложную прослойку.