Благодаря Хабрахабру и Google к нам в лабораторию робототехники Сколтеха на неделю попал дев-кит планшет проекта Google Tango. Мы не только протестировали данное устройство, но и написали небольшое демо по управлению мобильным роботом в режиме дополненной реальности. Но об этом чуть позже, сначала немного об устройстве и наших впечатлениях от него.
Думаю многие из вас уже слышали о данном проекте и неплохо представляют что он из себя представляет. Если вкратце, то это платформа компьютерного зрения и локализации нацеленная на применение в мобильных устройствах. Используя данные с двух камер (широкоугольной и обычной), датчика глубины (по сути Kinect в миниатюре), акселерометров, гироскопов и барометра устройство проекта Google Tango способно воспринимать окружающее трёхмерное пространство и отслеживать своё положение в нём. Громадная заслуга группы инженеров ATAP (Advanced Technology and Projects) заключается не только в том, что они смогли уместить всё это оборудование в мобильном устройстве, но и в том что у них вышло разработать дружелюбное к разработчику высокоуровневое SDK, которое берёт на себя основную тяжёлую работу по обработке данных с сенсоров и проведению необходимых преобразований, позволяя разработчику работать с удобными абстракциями. Так же в лучших традициях Google нам доступна документация высокого качества, позволяющая достаточно быстро освоиться с устройством даже разработчикам без опыта разработки приложений под Android.
Принцип работы
Устройство по сути имеет два основных режима локализации: с Area Learning и без него. В первом режиме мы предварительно сканируем помещение и строим его карту (к сожалению это делается offline, т.е. сначала обработка накопленных данных, потом использование результата в виде файла ADF — Area Description File), после чего мы можем весьма точно локализоваться в изученном помещении, компенсировать дрейф и справляться с проблемой временной потери трекинга. (например, при закрытии сенсоров рукой или другим слишком близко поднесённым объектом)
Второй режим позволяет нам проводить локализацию в пространстве и отслеживание движение устройства безо всякой предварительной подготовки. Работает он на основе совмещения данных со всех датчиков: IMU (Inertial Measurment Unit), визуальной одометрии по особым точкам изображения широкоугольной камеры, датчика глубины и т.д. Но т.к. нам неизвестны точки за которые мы могли бы зацепиться, в данном режиме координаты устройства будут подвержены дрейфу за счёт постоянно накапливающейся ошибки. (см. иллюстрацию) Кроме того имеется риск потери трекинга, корректное восстановление из которого в данном режиме в общем случае невозможно.
Пользуясь данными локализации (т.е. по сути зная с некоторой точностью координаты и ориентацию устройства относительно помещения) и имея трёхмерное облако точек с датчика глубины мы имеем возможность создавать приложения дополненной реальности ранее принципиально невозможные на мобильных устройствах. Логичным продолжением была бы установка Tango на очки дополненной реальности (следующая итерация Google Glass наподобии Hololens?), но пока мы можем воспользоваться эрзац-заменителем в виде Google Cardboard.
Разумеется одним из первых вопросов к устройству является его точность. В документации, разумеется, касаются данного вопроса, но мы не могли отказать себе в желании проверить самим заявления о точности в несколько сантиметров в оптимальных условиях.
Т.к. мы были весьма ограничены по времени, то решили всего лишь сделать кустарную оценку сверху используя в качестве инструмента стол с известными размерами. (два на три метра) Перемещая устройство из одного угла стола в другой по кривой траектории с отклонением от стола вплоть до двух метров мы записывали глобальные координаты (с и без Area Learning) в каждой из точек, после чего рассчитывали расстояние между данными точками и сравнивали с тем, что должно было получиться. Итоги следующие:
По понятным причинам точность сильно зависит от помещения в котором проводятся измерения. В помещении с хорошим освещением (устройство плохо относится к прямому солнечному свету) и большим количеством особых точек вполне реально добиться точности в пару сантиметров. Но в плохих условиях устройство быстро теряет трекинг, IMU конечно до поры до времени выручает, но его возможности весьма ограничены. Поэтому мы и бросили идею поставить танго на индустриальную робо-руку и измерить таким образом точность, ибо комната с роботом плохой пример «обычного» помещения.
Теперь о точности датчика глубины. Проверять его точность мы решили снимая облака точек для плоских объектов (пола, стен, столов) и анализируя насколько хорошо точки ложатся на плоскость. На оптимальной дистанции 0.5-4 м точность обычно составляла около 0.5 см, но на некоторых поверхностях точность падала в 2-3 раза, например на поле нашей лаборатории, покрытом черно-белым ковром в крапинку. Похоже текстура играла злую шутку с алгоритмами определения глубины основанными на структурированном ИК излучении.
Если кратко, то Google на высоте. Думаю как только Tango устройства попадут в широкую продажу, то отбоя от разработчиков не будет не только из-за уникальных возможностей устройства, но и из-за простоты программирования приложений для него. Фраза во вступлении, о том что с девайсом может освоиться даже разработчик без опыта программирования под Android — эксперементально подтверждённый факт, т.к. основной разработчик для Tango нашего демо управления роботом — Марко Симик (иностранный магистр нашей лаборатории), практически не имел опыта разработки под Android, но тем не менее смог за пару дней смог изучить инструменты и API в объёме достаточном для написания простеньких приложений.
Но хватит похвал. Tango Service представляет собой сервис работающий отдельным процессом. Общая структура программного стека показана на иллюстрации.
SDK предоставляет возможность работать с C++, Java и Unity. Порядок примерно соответствует их «высокоуровневости». Разумеется разработчики игр скорее всего оценят по достоинству возможность использования Unity и будут преимущественно выбирать данный вариант. Если же вы хотите работать напрямую с AIDL (Android Interface Definition Language) или другими Java приложениями, то Java API для вас. Разработчики же желающие разрабатывать приложения с Android NDK и иметь более полный контроль выберут C API.
Во всех трёх вариантах API практически идентично и предоставляет инструменты для съёма данных с устройства, управлением им и проведения необходимых преобразований из различных систем координат. (коих имеется аж 6 штук)
Думаю, пересказывать документацию смысла мало, лучше просто ознакомиться с ней.
Однако, с дев-китом ситуация обстояла далеко не идеально. Временами Tango Service падал и либо отказывался работать, либо выдавал шум на выходе. В подобных случаях помогала только перезагрузка. Вообще чувствовалась некоторая сырость устройства, будем надеяться что это свойство дев-кита и в коммерчески доступных устройствах эти детские болячки будут исправлены.
Кроме того стоит отметить что устройство достаточно ощутимо нагревается, особенно в приложениях с 3D гафикой. Тут, к сожалению, принципиально поменять ситуацию вряд ли получится, т.к. тяжёлые вычисления производить надо в любом случае. Так что на продолжительную работу Tango устройств при активном использовании, думаю, рассчитывать не приходится. Для оценки можете взять свой телефон или планшет и запустить на нём 3D игру, примерное время жизни устройства думаю будет плюс-минус совпадать.
Кроме того не стоит ожидать чудес от построения карт. Примерно качество можно увидеть например в этом видео.
Плюс стоит помнить, что устройство не является волшебной палочкой и у него имеются собственные ограничения, которые весьма вероятно послужат сдерживающим фактором при его консьюмерском использовании, ибо обычный пользователь не подозревает об особенностях используемых алгоритмов локализации, поэтому во время игры на Tango устройстве он может сталкиваться с весьма неприятными лагами, прыжками и прочими проявлениями неидеальности работы. Например, мы так и не смогли сыграть в игры поставлявшиеся с устройством так, что бы уверено сказать, что они готовы для обычных пользователей, скорее всего текущие игры они опишут просто как «глючные и непонятные». Но возможно это просто симптом сырости устройства.
Видео с конечным результатом недельного знакомства с Google Tango:
Исходный код скриптов для Unity опубликован на Гитхабе.
Не секрет, что виртуальная реальность являются нарастающим трендом. Но обычно она рассматривается с точки зрения добавления виртуального к реальному, мы же захотели, если можно так выразиться, добавить реального в виртуальное. На наш взгляд для настоящей виртуальной реальности недостаточно добавить виртуального оверлея, необходима обратная связь от виртуального к реальному. Примерно в том же ключе следовала работа из MIT по добавлению виртуальных интерфейсов для физических объектов.
В нашем случае мы решили сделать виртуальный интерфейс для вполне реального мобильного робота. Т.к. мы были весьма ограничены по времени, то решили ограничиться лишь управлением роботом посредством задания точек куда ехать роботу в реальном пространстве. Разумеется данную идею можно продолжать множеством направлений: добавлять дополнительные интерфейсы для робота (например, «голограмму» человека над роботом, визуализировать обмен данными между роботами), создавать обратную связь (например, показывая запланированную траекторию робота), делать игры совмещающие реальное и виртуальное (например, собирать виртуальные объекты реальной машинкой) и тому подобное.
Но даже простое исполнении контроля робота через задание целевых точек может оказаться весьма полезной фичей, особенно на производствах в которых становится всё больше и больше роботов.
Не говоря уже о потенциальных возможностях развития идей использования Google Tango для контроля физических объектов.
Для реализации данной идеи мы решили использовать Unity API, как наиболее простое и лёгкое для построения демо приложения в виду своей высокоуровневости. Для повышения надёжности определения координат мы использовали локализацию с использованием Area Learning. (на практике, вероятнее всего, роботы будут использоваться в известных помещениях, промерить которые не составит труда). Конечно можно было обойтись и без него, но точность и надёжность значительно от этого пострадают.
Разумеется, что бы приложение заработало желательно, что бы робот имел собственные средства навигации в пространстве, иначе нам постоянно придётся держать робота в области видимости устройства, что согласитесь не очень удобно. В нашем мобильном роботе использовался двухмерный лазерный сканер Hokuyo-04LX и программное обеспечение реализующие SLAM (одновременная локализация и картографирование), на выходе которого мы получали карту занятости (occupancy grid) окружающей местности, используя которую мы уже можем планировать траекторию движения робота. (софт для робота был по большей части самописным, но всё то же самое можно сделать используя готовые модули в ROS).
Теперь нам остаётся только сопоставить глобальные координаты устройства и робота, причём первые координаты уже выровнены по горизонтали посредством использования акселерометра, так что нам нужно по сути локализовать робота и его ориентацию в глобальном двухмерном пространстве устройства, после чего мы сможем проводить преобразования координат целевых точек из системы планшета в систему робота.
Для того что бы реализовать данную задумку приложению необходимо было включить в себя три фичи: трекинг движения, Area Learning и получение карты глубин. (или иначе говоря трёхмерного облака точек) Использование приложения проходит по следующему пути:
Причём стоит отметить, что отмечая положение робота мы узнаём только его координату, но не направление, тут мы пошли на ухищрение и упростили задачу создав правило, что робота надо всегда выбирать стоя строго сзади него. Конечно в общем случае робота можно детектировать по специальным меткам (скажем отображающимся на экране или наклеенным на корпусе) или же вообще используя нейронные сети на основе TensorFlow. Но опят же сказались ограничения по времени.
Исходники в репозитории (ссылка выше) содержат лишь три скрипта: выбор файла ADF, сплеш-скрин инициализации (релокализации) после выбора ADF, основной скрипт управления и UI. Что бы воспользоваться этими скриптами достаточно добавить их в пример AreaLearning.
Unity скрипты исполняются определённым образом, имеется 3 главных коллбека, которые мы используем в нашем демо:
В итоге у нас получилась следующая структура:
Код управления робота, думаем, выходит за рамки данной статьи, поэтому на данный момент не публикуется.
По итогам нашего знакомства могу с уверенностью сказать: Google Tango чрезвычайно многообещающее устройство, которое способно совершить в ближайшие года переворот в том, что мы считаем мобильными устройствами. В общем, весьма маловероятно что данный проект закончит как Glass и Wave. Разумеется на данный момент устройства не лишены детских болячек, и как любая технология имеют свои пределы и особенности, но первое будет поправлено, а ко второму, думаю, пользователи и разработчики постепенно привыкнут.
Таким образом, мы считаем, что давно навзревавший бум виртуальной реальности по видимому скоро раскроется в полную силу, и Google Tango явно намерен возглавить его посредством своей простоты программирования, дружелюбия к разработчикам, сложившейся Android экосистемы, в так же активного продвижения Google.
Статья автора Дмитрия Сенашенко, в рамках конкурса «Device Lab от Google».
Думаю многие из вас уже слышали о данном проекте и неплохо представляют что он из себя представляет. Если вкратце, то это платформа компьютерного зрения и локализации нацеленная на применение в мобильных устройствах. Используя данные с двух камер (широкоугольной и обычной), датчика глубины (по сути Kinect в миниатюре), акселерометров, гироскопов и барометра устройство проекта Google Tango способно воспринимать окружающее трёхмерное пространство и отслеживать своё положение в нём. Громадная заслуга группы инженеров ATAP (Advanced Technology and Projects) заключается не только в том, что они смогли уместить всё это оборудование в мобильном устройстве, но и в том что у них вышло разработать дружелюбное к разработчику высокоуровневое SDK, которое берёт на себя основную тяжёлую работу по обработке данных с сенсоров и проведению необходимых преобразований, позволяя разработчику работать с удобными абстракциями. Так же в лучших традициях Google нам доступна документация высокого качества, позволяющая достаточно быстро освоиться с устройством даже разработчикам без опыта разработки приложений под Android.
Об устройстве
Принцип работы
Устройство по сути имеет два основных режима локализации: с Area Learning и без него. В первом режиме мы предварительно сканируем помещение и строим его карту (к сожалению это делается offline, т.е. сначала обработка накопленных данных, потом использование результата в виде файла ADF — Area Description File), после чего мы можем весьма точно локализоваться в изученном помещении, компенсировать дрейф и справляться с проблемой временной потери трекинга. (например, при закрытии сенсоров рукой или другим слишком близко поднесённым объектом)
Второй режим позволяет нам проводить локализацию в пространстве и отслеживание движение устройства безо всякой предварительной подготовки. Работает он на основе совмещения данных со всех датчиков: IMU (Inertial Measurment Unit), визуальной одометрии по особым точкам изображения широкоугольной камеры, датчика глубины и т.д. Но т.к. нам неизвестны точки за которые мы могли бы зацепиться, в данном режиме координаты устройства будут подвержены дрейфу за счёт постоянно накапливающейся ошибки. (см. иллюстрацию) Кроме того имеется риск потери трекинга, корректное восстановление из которого в данном режиме в общем случае невозможно.
Пользуясь данными локализации (т.е. по сути зная с некоторой точностью координаты и ориентацию устройства относительно помещения) и имея трёхмерное облако точек с датчика глубины мы имеем возможность создавать приложения дополненной реальности ранее принципиально невозможные на мобильных устройствах. Логичным продолжением была бы установка Tango на очки дополненной реальности (следующая итерация Google Glass наподобии Hololens?), но пока мы можем воспользоваться эрзац-заменителем в виде Google Cardboard.
Немного о точности
Разумеется одним из первых вопросов к устройству является его точность. В документации, разумеется, касаются данного вопроса, но мы не могли отказать себе в желании проверить самим заявления о точности в несколько сантиметров в оптимальных условиях.
Т.к. мы были весьма ограничены по времени, то решили всего лишь сделать кустарную оценку сверху используя в качестве инструмента стол с известными размерами. (два на три метра) Перемещая устройство из одного угла стола в другой по кривой траектории с отклонением от стола вплоть до двух метров мы записывали глобальные координаты (с и без Area Learning) в каждой из точек, после чего рассчитывали расстояние между данными точками и сравнивали с тем, что должно было получиться. Итоги следующие:
- Среднее отклонение составило 2-3 см, в худших случаях вплоть до 5-6 см
- Точность с Area Learning и без него на траекториях 15-20 метров кардинально не отличаются, что говорит о достаточно высоком качестве локализации по визуальной одометрии и IMU
- Ориентация устройства влияет на координаты с ошибкой вплоть до 5 см (в т.ч. и с использованием Area Learning), т.е. если вернуть устройство в исходную точку, но повёрнутым, его координаты будут несколько иными
По понятным причинам точность сильно зависит от помещения в котором проводятся измерения. В помещении с хорошим освещением (устройство плохо относится к прямому солнечному свету) и большим количеством особых точек вполне реально добиться точности в пару сантиметров. Но в плохих условиях устройство быстро теряет трекинг, IMU конечно до поры до времени выручает, но его возможности весьма ограничены. Поэтому мы и бросили идею поставить танго на индустриальную робо-руку и измерить таким образом точность, ибо комната с роботом плохой пример «обычного» помещения.
Теперь о точности датчика глубины. Проверять его точность мы решили снимая облака точек для плоских объектов (пола, стен, столов) и анализируя насколько хорошо точки ложатся на плоскость. На оптимальной дистанции 0.5-4 м точность обычно составляла около 0.5 см, но на некоторых поверхностях точность падала в 2-3 раза, например на поле нашей лаборатории, покрытом черно-белым ковром в крапинку. Похоже текстура играла злую шутку с алгоритмами определения глубины основанными на структурированном ИК излучении.
Об SDK и API
Если кратко, то Google на высоте. Думаю как только Tango устройства попадут в широкую продажу, то отбоя от разработчиков не будет не только из-за уникальных возможностей устройства, но и из-за простоты программирования приложений для него. Фраза во вступлении, о том что с девайсом может освоиться даже разработчик без опыта программирования под Android — эксперементально подтверждённый факт, т.к. основной разработчик для Tango нашего демо управления роботом — Марко Симик (иностранный магистр нашей лаборатории), практически не имел опыта разработки под Android, но тем не менее смог за пару дней смог изучить инструменты и API в объёме достаточном для написания простеньких приложений.
Но хватит похвал. Tango Service представляет собой сервис работающий отдельным процессом. Общая структура программного стека показана на иллюстрации.
SDK предоставляет возможность работать с C++, Java и Unity. Порядок примерно соответствует их «высокоуровневости». Разумеется разработчики игр скорее всего оценят по достоинству возможность использования Unity и будут преимущественно выбирать данный вариант. Если же вы хотите работать напрямую с AIDL (Android Interface Definition Language) или другими Java приложениями, то Java API для вас. Разработчики же желающие разрабатывать приложения с Android NDK и иметь более полный контроль выберут C API.
Во всех трёх вариантах API практически идентично и предоставляет инструменты для съёма данных с устройства, управлением им и проведения необходимых преобразований из различных систем координат. (коих имеется аж 6 штук)
Думаю, пересказывать документацию смысла мало, лучше просто ознакомиться с ней.
Ложка дёгтя
Однако, с дев-китом ситуация обстояла далеко не идеально. Временами Tango Service падал и либо отказывался работать, либо выдавал шум на выходе. В подобных случаях помогала только перезагрузка. Вообще чувствовалась некоторая сырость устройства, будем надеяться что это свойство дев-кита и в коммерчески доступных устройствах эти детские болячки будут исправлены.
Кроме того стоит отметить что устройство достаточно ощутимо нагревается, особенно в приложениях с 3D гафикой. Тут, к сожалению, принципиально поменять ситуацию вряд ли получится, т.к. тяжёлые вычисления производить надо в любом случае. Так что на продолжительную работу Tango устройств при активном использовании, думаю, рассчитывать не приходится. Для оценки можете взять свой телефон или планшет и запустить на нём 3D игру, примерное время жизни устройства думаю будет плюс-минус совпадать.
Кроме того не стоит ожидать чудес от построения карт. Примерно качество можно увидеть например в этом видео.
Плюс стоит помнить, что устройство не является волшебной палочкой и у него имеются собственные ограничения, которые весьма вероятно послужат сдерживающим фактором при его консьюмерском использовании, ибо обычный пользователь не подозревает об особенностях используемых алгоритмов локализации, поэтому во время игры на Tango устройстве он может сталкиваться с весьма неприятными лагами, прыжками и прочими проявлениями неидеальности работы. Например, мы так и не смогли сыграть в игры поставлявшиеся с устройством так, что бы уверено сказать, что они готовы для обычных пользователей, скорее всего текущие игры они опишут просто как «глючные и непонятные». Но возможно это просто симптом сырости устройства.
Демо: управляем роботом
Видео с конечным результатом недельного знакомства с Google Tango:
Исходный код скриптов для Unity опубликован на Гитхабе.
Идея
Не секрет, что виртуальная реальность являются нарастающим трендом. Но обычно она рассматривается с точки зрения добавления виртуального к реальному, мы же захотели, если можно так выразиться, добавить реального в виртуальное. На наш взгляд для настоящей виртуальной реальности недостаточно добавить виртуального оверлея, необходима обратная связь от виртуального к реальному. Примерно в том же ключе следовала работа из MIT по добавлению виртуальных интерфейсов для физических объектов.
В нашем случае мы решили сделать виртуальный интерфейс для вполне реального мобильного робота. Т.к. мы были весьма ограничены по времени, то решили ограничиться лишь управлением роботом посредством задания точек куда ехать роботу в реальном пространстве. Разумеется данную идею можно продолжать множеством направлений: добавлять дополнительные интерфейсы для робота (например, «голограмму» человека над роботом, визуализировать обмен данными между роботами), создавать обратную связь (например, показывая запланированную траекторию робота), делать игры совмещающие реальное и виртуальное (например, собирать виртуальные объекты реальной машинкой) и тому подобное.
Но даже простое исполнении контроля робота через задание целевых точек может оказаться весьма полезной фичей, особенно на производствах в которых становится всё больше и больше роботов.
Не говоря уже о потенциальных возможностях развития идей использования Google Tango для контроля физических объектов.
Исполнение
Для реализации данной идеи мы решили использовать Unity API, как наиболее простое и лёгкое для построения демо приложения в виду своей высокоуровневости. Для повышения надёжности определения координат мы использовали локализацию с использованием Area Learning. (на практике, вероятнее всего, роботы будут использоваться в известных помещениях, промерить которые не составит труда). Конечно можно было обойтись и без него, но точность и надёжность значительно от этого пострадают.
Разумеется, что бы приложение заработало желательно, что бы робот имел собственные средства навигации в пространстве, иначе нам постоянно придётся держать робота в области видимости устройства, что согласитесь не очень удобно. В нашем мобильном роботе использовался двухмерный лазерный сканер Hokuyo-04LX и программное обеспечение реализующие SLAM (одновременная локализация и картографирование), на выходе которого мы получали карту занятости (occupancy grid) окружающей местности, используя которую мы уже можем планировать траекторию движения робота. (софт для робота был по большей части самописным, но всё то же самое можно сделать используя готовые модули в ROS).
Теперь нам остаётся только сопоставить глобальные координаты устройства и робота, причём первые координаты уже выровнены по горизонтали посредством использования акселерометра, так что нам нужно по сути локализовать робота и его ориентацию в глобальном двухмерном пространстве устройства, после чего мы сможем проводить преобразования координат целевых точек из системы планшета в систему робота.
Для того что бы реализовать данную задумку приложению необходимо было включить в себя три фичи: трекинг движения, Area Learning и получение карты глубин. (или иначе говоря трёхмерного облака точек) Использование приложения проходит по следующему пути:
- Записать Area Description File (ADF), т.е. провести Area Learning помещения в котором будет использоваться программа
- Загрузить полученный ADF, подвигать немного устройство дабы устройство распознало особые точки и произвело собственную локализацию
- Отметить положение робота
- Отметить целевую точку и нажать кнопку исполнения команды
Причём стоит отметить, что отмечая положение робота мы узнаём только его координату, но не направление, тут мы пошли на ухищрение и упростили задачу создав правило, что робота надо всегда выбирать стоя строго сзади него. Конечно в общем случае робота можно детектировать по специальным меткам (скажем отображающимся на экране или наклеенным на корпусе) или же вообще используя нейронные сети на основе TensorFlow. Но опят же сказались ограничения по времени.
Код
Исходники в репозитории (ссылка выше) содержат лишь три скрипта: выбор файла ADF, сплеш-скрин инициализации (релокализации) после выбора ADF, основной скрипт управления и UI. Что бы воспользоваться этими скриптами достаточно добавить их в пример AreaLearning.
Unity скрипты исполняются определённым образом, имеется 3 главных коллбека, которые мы используем в нашем демо:
- Start() запускается при запуске приложения
- Update() запускается при каждом обновлении кадра
- OnGUI() запускается несколько раз за кадр
В итоге у нас получилась следующая структура:
- Start() назначает коллбеки к соответвующим событиям
- Update() обрабатывает касания к экрану и при необходимости запускает корутину для нахождения глобальных координат соответствующих тапнутым координатам экрана, плюс рисует красный маркер при успешном выборе точки
- OnTangoDepthAvailable, OnTangoPoseAvailable коллбеки ожидающие событий от Tango и устанавливающих соответствующие флаги при запуске
- _WaitForTouch корутины ожидающие тапа по экрану после нажатия одной из кнопок, после чего вызывает корутину для вычисления глобальных координат соответствующих месту тапа
- _WaitForDepth ожидает карту глубин (трёхмерное облако точек) и находит координаты точки в глобальной системе отсчёта для заданной координаты на экране
- _WaitForRequest обрабатывает посылку команды роботу, в нашем случае это был простой GET запрос
Код управления робота, думаем, выходит за рамки данной статьи, поэтому на данный момент не публикуется.
Заключение
По итогам нашего знакомства могу с уверенностью сказать: Google Tango чрезвычайно многообещающее устройство, которое способно совершить в ближайшие года переворот в том, что мы считаем мобильными устройствами. В общем, весьма маловероятно что данный проект закончит как Glass и Wave. Разумеется на данный момент устройства не лишены детских болячек, и как любая технология имеют свои пределы и особенности, но первое будет поправлено, а ко второму, думаю, пользователи и разработчики постепенно привыкнут.
Таким образом, мы считаем, что давно навзревавший бум виртуальной реальности по видимому скоро раскроется в полную силу, и Google Tango явно намерен возглавить его посредством своей простоты программирования, дружелюбия к разработчикам, сложившейся Android экосистемы, в так же активного продвижения Google.
Поделиться с друзьями