Google Tango: керований роботом в режимі доповненої реальності

Завдяки Хабрахабру і Google до нас в лабораторію робототехніки Сколтеха на тиждень потрапив дів-кіт планшет проекту Google Tango. Ми не тільки протестували даний пристрій, але і написали невелике демо з управління мобільним роботом в режимі доповненої реальності. Але про це трохи пізніше, спочатку трохи про будову і наші враження від нього.

Стаття автора Дмитра Сенашенко, в рамках конкурсу <a href=«special.habrahabr.ru/google/lab>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 та отримання карти глибин. (або інакше кажучи тривимірного хмари точок) Використання програми проходить за наступним шляхом:

  1. Записати Area Description File (ADF), тобто провести Area Learning приміщення в якому буде використовуватися програма
  2. Завантажити отриманий ADF, посувати трохи пристрій щоб пристрій распознало особливі точки і виробило власну локалізацію
  3. Відзначити положення робота
  4. Відзначити цільову точку і натиснути кнопку виконання команди
Причому варто відзначити, що відзначаючи положення робота ми дізнаємося тільки його координату, але не напрям, тут ми пішли на хитрість і спростили завдання створивши правило, що робота треба завжди вибирати стоячи суворо позаду нього. Звичайно в загальному випадку робота можна детектувати за спеціальними мітками (скажімо відображаються на екрані або наклеєним на корпусі) або ж взагалі використовуючи нейронні мережі на основі 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.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.