CC BY
69
Использование концепции конструкторов приложений для построения мобильных браузеров дополненной реальности без необходимости программирования
И.Н. Баулин, МГУ им. М.В. Ломоносова, магистр-выпускник,
baulin. ivan@gmail. com
В работе рассматриваются возможности автоматического построения приложений дополненной реальности. В основу работы положена магистерская диссертация, выполненная автором в лаборатории Открытых Информационных Технологий факультета ВМК МГУ.
Понятие дополненной реальности
Дополненная реальность (далее по тексту будут использоваться англоязычные термины Augmented Reality, AR) - это одна из разновидностей виртуальной реальности; представляет собой реальность, в которой виртуальные трехмерные объекты интегрируются в реальное трехмерное окружение (то есть реальное окружение дополняется виртуальными элементами). Главное отличие этих терминов состоит в том, что в виртуальной реальности пользователь полностью погружается в виртуальное окружение и перестает видеть реальные объекты вокруг себя, в дополненной же реальности реальные объекты так или иначе продолжают быть доступны пользователю, но они интегрируется с виртуальными элементами. В идеале эта интеграция должна быть незаметна для человека.
Для иллюстрации можно привести один из самых знаменитых примеров дополненной реальности, изображенной в кино. В кинофильме «Терминатор 2» зрения робота обладало возможностью выводить на экран всю информацию об окружающих объектах одновременно с реальной картинкой.(см. Рис. 1)
Рис. 1. Пример дополненной реальности
Исторически для накладывания виртуальных объектов на реальное изображение использовались разнообразные специальные устройства -шлемы дополненной реальности, видеоочки и т.д. Для того чтобы избежать привязки термина дополненной реальности к конкретным технологиям Рональд Азума в своей ставшей классической работе "A Survey of Augmented Reality" [1] дал определение дополненной реальности как систему, которая
30) Дополняет реальный мир виртуальными элементами
31) Дополнение происходит в реальном времени
32) Дополнение должно происходить в трехмерном пространстве
Стоит отдельно отметить, что в определении дополненной реальности крайне важна интерактивность происходящего. Таким образом, отснятый на видеокамеру материал, который был впоследствии совмещен с виртуальными элементами (такое повсеместно используется в кино) не может быть примером системы дополненной реальности.
Дополненная реальность в мобильных устройствах
В настоящий момент с развитием вычислительной техники и появлением новых технологий дополненная реальность становится доступной простым пользователям. Системы дополненной реальности обычно обладают тремя основными компонентами - собственно само устройство, система позиционирования и система отображения. В качестве системы отображения в мобильных устройствах используется камера мобильного телефона. Для позиционирования мобильного устройства и построения некой виртуальной модели реального мира (для последующего дополнения этой модели виртуальными элементами) может использоваться как информация, поступающая с встроенного в телефон GPS датчика и G-сенсора, так и использоваться заранее предопределенные изображения-маркеры, которые распознаются мобильными устрой-
ствами посредством алгоритмов машинного зрения. Развитие современных мобильных устройств достигло такого уровня, что их вычислительная мощь позволяет реализовывать реальные прикладные AR-системы.
Одна из основных задач любого AR приложения - каким-то образом привязать виртуальные объекты к объектам реального мира, но для этого сначала необходимо получить представление о том, как выглядит реальный мир, извлечь необходимую метаинформацию об окружающем пользователя реальном окружении. Для этих целей существует два основных подхода - trackable surfaces и геопозиционирование.
Trackable surfaces (общераспространенного перевода на русский данного термина пока нет, далее по тексту будет использован наиболее адекватный с точки зрения автора перевод - отслеживаемые поверхности) - это подход получения информации об окружающем реальном мире посредством поиска в этом реальном мире заранее известных приложению отслеживаемых поверхностей. То есть мобильное приложение, используя алгоритмы машинного зрения, ищет в реальном мире одну из известных этому приложению картинок. В случае успеха поиска строит относительно этой картинки модельную систему координат, после чего дополняет ее виртуальными элементами. Подход tracka-ble surfaces можно считать развитием идеи QR кодов - матричных черно-белых кодов, используемых для кодирования информации об объекте, которые можно прочитать сканирующим оборудованием, в том числе камерой мобильного телефона. Одной из самых известных разработок в этом направлении - программный набор для создания AR приложений от компании Qualcomm.
Геопозиционирование - подход к получению информации об окружающем реальном мире на основе данных о географическом местоположении пользователя и направлении камеры его мобильного телефона. Информация о геокоординатах получается посредством встроенного в телефон GPS датчика, а информация о направлении - с встроенного в телефон G-сенсора. Получив эту информацию мобильное приложение также способно выстроить модельную систему координат и дополнить эту систему координат виртуальными объектами, связанными с данным географическим местом. Такой подход реализован в двух самых известных на сегодняшний день браузерах дополненной реальности - Layar и Wikitude.
Браузеры дополненной реальности
Рассмотрим, что представляет собой типичный браузер дополненной реальности на примере одного из самых распространённых подобных продуктов - голландском AR браузере Layar.
□ ТййЛ© 7:02 АМ
Рис. 2. AR браузер Layar
Как мы видим на рисунке 2 картинка, получаемая с камеры мобильного устройства, дополняется виртуальными элементами, которые привязываются к так называемым точкам интереса. Точка интереса связана с конкретными географическими координатами и определяет ту мета-информацию, которая будет выдана пользователю. Набор точек интересов группируется в слои дополненной реальности. Каждый слой дополненной реальности определяет тот контент, который будет доступен пользователю.
Layar по сути представляет собой систему управления и отображения различных слоев дополненной реальности. Сами слои создаются сторонними разработчиками в рамках той архитектуры, которую предоставляет голландский сервис. На рисунке 3 изображена архитектура данной системы. Схема взята из документации программного интерфейса Layar . [2]
Рис. 3 архитектура Layar
Клиентская часть (Layar app) - представляет собой приложение для мобильного устройства, которое инкапсулирует в себе всю работу по взаимодействию с аппаратными ресурсами мобильного устройства (GPS модуль, G-сенсор, камера) и освобождает разработчиков новой функциональности от обязанности вникать в детали реализации под конкретную мобильную платформу. Клиентское приложение отвечает за рендеринг виртуальных элементов поверх видеопотока с камеры и за взаимодействие с сервером Layar.
Мобильный клиент обращается за всей необходимой информацией к серверу Layar. Общение происходит посредством Layar Client API. Детали реализации этого программного интерфейса скрыты от конечных пользователей и разработчиков новых слоев. На сервере Layar хранится только статическая информация. Она включает в себя информацию об используемом слое. Вся эта информация предварительно загружается сторонним разработчиком новой функциональности через специально созданный веб-сайт (Layar Provisioning WebSite). К фиксированной информации в первую очередь относится информация о внешнем виде слоя. При создании собственного слоя можно изменять цвета всех элементов управления, а также менять логотипы и баннеры в пользовательском интерфейсе мобильного клиента. Благодаря этому внешний вид различных слоев может достаточно сильно отличаться. Кроме того на веб-сайте определяются фиксированный набор фильтров, связанных со слоем.
Вся динамическая информация, в частности информация о списке точек интереса для данной местности подгружается динамически в тот момент, когда пользователь загрузил данный слой. В этом сервер Layar работает как прокси-сервер к серверу разработчиков. Для реализации этого взаимодействия используется так называемый Layar Developer API. Этот программный интерфейс полностью открыт сторонним разработчикам и тщательно задокументирован.
Динамическая информация об уровне подгружается в реальном времени с сервера разработчика. Интерфейс взаимодействия сервера Layar с веб-сервисом, который должен предоставить разработчик уровня, открыт и хорошо документирован. Для запроса информации о точках интереса, связанных с текущей локацией, используется протокол HTTP.
Архитектура браузера дополненной реальности Wikitude хоть и отличается от Layar, но в целом, на него похожа. В ней также присутствует клиент, отвечающий за геопозиционирование и рендеринг данных, есть сервер, отвечающий за обработку клиентских запросов, и есть механизм получения контента с удаленных серверов посредством вызова веб-сервисов.
Идея программного посредника для динамического извлечения контента для браузеров дополненной реальности
Описанная выше архитектура браузеров дополненной реальности предоставляет хорошие возможности к применению популярной сейчас концепции пользовательского контента (в работе используются также англоязычный термин user generated content - UGC) в приложениях дополненной реальности.
Понятие User Generated Content тесно и неразрывно связано с понятиями Web 2.0 и participative web (дословно можно перевести как «общий» интернет). Понятие participative web основано на быстро развивающихся в интернете сервисах, которые дают конечным пользователям возможности способствовать созданию, оцениванию и распространению интернет контента, а также настройки веб-приложений под себя. [3] UGC дает большие преимущества онлайн сервисам по сравнению с традиционными веб-ресурсами, где контент обновляется исключительно администратором ресурса. В наполнении ресурса участвуют несравнимо большее число человек, каждый из которых как конечный пользователь сервиса заинтересован в том, чтобы выкладывать имеющийся у него контент (как медиаданные - видеоролики, фотографии, так и имеющиеся у человека сведения, знания). Кроме того сами пользователи обычно имеют обычно возможность оценивать (обсуждать, комменти-
ровать и даже редактировать) имеющийся материал, что делает его лучше (актуальнее и т.д.). Подавляющее большинство из получивших недавно широкое распространение веб-сервисов как раз, так или иначе, реализуют у себя концепцию UGC. В качестве примера можно привести модные сейчас социальные сети (Facebook, MySpace, LinkedIn и т.д.), сервисы онлайн хранения фотографий (Flickr, Picasa Web Albums), Youtube, LiveJournal и, конечно, Wikipedia.
Общая идея предлагаемого подхода к реализации User Generated Content в AR приложениях состоит в том, чтобы расширить функции серверного приложения (серверного посредника), с которого мобильный клиент, так или иначе, загружает необходимый ему контент. Серверное приложение должно выступать как некий программный посредник, с которым можно легко интегрировать различных поставщиков контента. Предполагается, что данные поставщики контента наполняются пользовательским контентом. То есть серверное приложение должно работать с несколькими поставщиками контента, брать на себя и скрывать от мобильного приложения все детали программных вызовов, специфичных для каждого отдельного поставщика контента. Серверное приложение должно быть способно динамически (без перекомпиляции) подключать и отключать поставщиков контента или по запросу мобильного клиента (если мы предоставляем пользователю сведения об источниках контента), или по желанию администратора системы. То есть в случае пришедшего от мобильного клиента запроса на выдачу контента задачей предлагаемого программного посредника является обработка пришедшего запроса, формирование новых запросов к используемым поставщикам контента в известных им терминах и обработка пришедших результатов в один единый ответ мобильному клиенту.
Второй важной характеристикой серверного посредника - возможность работы с ним одновременно нескольких браузеров дополненной реальности. На самом деле массив информации, запрашиваемый браузерами дополненной реальности очень похож. Семантически это обычно одна и та же информация (некоторый ресурс, ссылка на него, текстовое описание, географическое положение). Синтаксически же одна и та же семантика скрывается за вызовами разных программных интерфейсов. Задача программного посредника:
• понимать синтаксис разных программных интерфейсов разных браузеров дополненной реальности
• обеспечивать возможность выбора некоторой группы поставщиков контента из списка доступных (или всех)
• запрашивать у поставщиков контента необходимый набор точек интереса (независимо от того с какого браузера дополненной реальности пришел вызов)
• формировать корректный серверный ответ в том формате, в каком его ждет соответствующий браузер дополненной реальности.
• позволять легко добавлять в систему новых поставщиков контента и новые браузеры дополненной реальности
Идея программного посредника с расширенным функционалом применима для любого браузера дополненной реальности, где присутствует возможность запрашивать требуемый контент с удаленных серверов поставщиков данных. В той или иной форме такой возможностью обладают и Layar, и Wikitude, рассмотренные в предыдущем разделе.
Общая схема предлагаемого подхода изображена на рисунке 4. На схеме отсутствуют упоминания о каких-то конкретных браузерах дополненной реальности, протоколах или поставщиках данных. Данная схема универсальна и может быть использована при работе с различными системами.
Рис. 4 общая схема серверного посредника для динамического извлечения контента от разных поставщиков контента
Возможность создания конструкторов приложений для построения браузеров дополненной реальности
Одним из основных преимуществ предлагаемого выше подхода является то, что данный подход позволяет отказаться от использования программирования при создании слоев дополненной реальности. В данный момент, для создания нового слоя для браузера Layar необходима
• разработка своего собственного веб-сервиса, способного общаться с сервером Layar посредством API
• необходимы средства для поддержания данного сервиса в непрерывно работающем состоянии, способного оперативно обрабатывать запросы от большого количества пользователей.
Таким образом, для создания нового слоя требуются инвестиции как в разработку слоя группой профессиональных разработчиков, так и в поддержания данного слоя в рабочем состоянии. В этом отношении выглядит привлекательным применение идеи конструкторов приложений (App Wizards) в области браузеров дополненной реальности.
Конструктор приложений обычно представляет собой систему, которая позволяет пользователям на лету создавать свои собственные приложения без необходимости что-то программировать. Например, типичный App Wizard выглядит так
1. Пользователь заходит на некий веб-сайт, где ему предлагается создать собственное приложение
2. Пользователь выбирает параметры внешнего вида будущего приложения
3. Пользователь указывает ссылку на rss feed, который будет служить поставщиком контента для будущего приложения
4. Пользователь инициирует генерацию нового приложения в соответствие с заданными параметрами.
5. На выходе получается скомпилированная программа, созданная без усилий программистов.
В качестве примеров подобных систем можно привести такие продукты, как Ovi App Wizard от компании Nokia и App Inventor от компании Google.
Основная структура предлагаемого конструктора браузеров дополненной реальности изображена на рисунке 5.
Рис. 5 общая схема конструктора браузеров дополненной реальности
Пользователь управляет созданием своего браузера дополненной реальности через специальный веб-сайт. На этом веб-сайте он может выбрать и настроить внешний вид будущего приложения, а также указать тот контент, который будет выдаваться пользователю.
Спецификой браузеров дополненной реальности является то, что необходимый набор точек интереса (фактически предоставляемый контент) зависит не только от выбранного приложения (слоя), но и от текущего географического местоположения пользователя. Поэтому конструктор браузеров дополненной реальности неизбежно должен строить не только клиентскую часть приложения (как в классических конструкторах приложения), но и каким-то образом реализовывать серверную часть, с которой клиент будет динамически запрашивать необходимый набор точек интереса. Для реализации серверной части используется идея серверного посредника, описанная в предыдущем разделе.
При выборе контента пользователь может создать свои собственные точки интереса или же настроить использование уже существующих поставщиков контента. Для добавления новых точек интереса в создаваемое приложение теоретически можно использовать любой формат, поддерживающий геокодирование информации. В данный момент наибольшее распространение получили форматы KML, используемый в Google Maps, и Geo-RSS. Также не составит труда добавить поддержку формата ARML, специально созданного для хранения информации о точках интереса для браузеров дополненной реальности и продвигаемого разработчиками AR-браузера Wikitude[4].
Также возможно будет и использование внешних поставщиков контента, с содержимым, наполняемым самим пользователями - Flickr, Pi-
casa Web Albums, Twitter, etc. Для каждого подобного поставщика контента может быть создан специальный адаптер, инкапсулирующий в себе взаимодействие серверного посредника с поставщиком контента посредством специфичного API. Таким образом, пользователь сможет подключить любой сервис контента, для которого в системе существует адаптер, и, настроив необходимую фильтрацию контента, использовать его в своем будущем приложении.
При инициировании пользователем генерации нового приложения будут происходить следующие вещи. Во-первых, будет генерироваться мобильное приложение, скомпилированное под необходимую платформу. Для генерации приложения под каждую отдельную платформу будет использоваться некоторый базовый каркас приложения, способный производить рендеринг виртуальных объектов поверх видеопотока с камеры, обрабатывать показания GPS-датчика и G-сенсора, а также взаимодействовать с серверным посредником в рамках данной платформы. Разумеется, данный каркас будет различным для различных платформ, но различные приложения, созданные конструктором приложения под одну платформу, будут, по сути, различаться только заданным внешним видом.
Во-вторых, информация о новом приложении будет добавляться в серверный посредник. Серверный посредник будет служить для динамического предоставления информации обо всех точках интереса, доступных данному приложению в запрашиваемой географической области. Серверный посредник будет агрегировать весь доступный контент от выбранных пользователем поставщиков контента (по выбранным пользователем условиям фильтрации контента), а также использовать указанные пользователем фиды, с геокодированной информацией.
Помимо динамического извлечения информации от сторонних поставщиков контента, пользователю будет также дана возможность загружать массивы геокодированной информации о точках интереса в локальную базу данных на серверном посреднике. Получением данных из локальной базы будет также управлять серверный посредник, используя её наряду с внешними поставщиками контента абсолютно непрозрачно для пользователя.
Таким образом, предлагаемая система успешно реализует в себе идею применение концепции конструкторов приложений к браузерам дополненной реальности.
Заключение
В статье была рассмотрена возможность создания конструктора приложений для построения браузеров дополненной реальности. Конструктор приложений дает возможность создавать браузеры дополненной реальности с уникальным внешним видом и с уникальным контен-
том. Конструктор бразуеров дополненной реальности позволяет избавиться от необходимости привлечения услуг профессиональных программистов для создания новых слоёв дополненной реальности, а также освобождает от необходимости заниматься поддержкой веб-сервисов, созданных для динамического предоставления точек интереса для заданной географической области. В статье рассмотрены необходимые условия создания такой системы. В частности, рассмотрены все необходимые функциональные особенности серверного посредника, отвечающего за динамическое получение пользовательского контента отёёё разных поставщиков контента и его динамическую интеграцию.
Литература
1. R. Azuma, A Survey of Augmented Reality
[HTML] (http://www.cs.unc.edu/~azuma/ARpresence.pdf)
2. Layar Developer Wiki
[HTML] (http://layar.pbworks.eom/w/page/7783228/FrontPage)
3. Graham Vickery and Sacha Wunsch-Vincent, Participative Web And User-Created Content
[HTML] (http://www.oecd.org/dataoecd/57/14/38393115.pdf)
4. Markus Tripp, Martin Lechner, ARML Specification for Wikitude 4 [HTML] (http://www.openarml.org/wikitude4.html)
