ua-hosting.company: выделенный сервер в Нидерландах 2 х Intel Dodeca-Core Xeon E5-2650 v4 128GB DDR4 6x480 SSD 1Gbps 100 ТВ — $249 / месяц
×Закрыть

Пошук людей у великому офісі: як ми подружили бікони з розумними годинниками

Бікони — це вдале рішення для використання всередині будівлі, але компанія Estimote вирішила піти далі і створила nearables — бікони, що використовують технологію BLE. Ми приємно вражені результатами, яких їм вдалося досягнути. Отже, ми спробували витиснути всі соки з Estimote nearables і поєднували їх із мобільними та носимими пристроями, щоби зрозуміти, на що вони здатні у реальності — про це і розповімо у статті.

Забігаючи наперед, пропонуємо коротке відео, в якому ми поділилися своїми враженнями і показали результати нашого дослідження:

Проблема пошуку людей у великих офісах

Під час нашого експерименту ми вирішили використати nearables для стеження за тим, як працівники нашої компанії переміщуються офісом. Насправді це не настільки страшно, як звучить. Компанії з великими офісами завжди стикаються з цією проблемою: як дізнатися місцеперебування працівника у будівлі, особливо якщо він постійно зайнятий на нарадах у різних кімнатах і рідко буває на своєму робочу місці. Очевидно, що для цього ви можете скористатися магією мобільного зв’язку, але по-перше, не всі носять зі собою свої мобільні (звучить дивно, але це правда), а по-друге, переривати нараду телефонним дзвінком — не надто ввічливо. Значно легше — просто дізнатися, де можна знайти людину в даний момент, і вирішити з нею термінове питання під час особистої розмови.

Описана ситуація звучить як типовий кейс використання біконів, але ми обрали для експерименту саме її, адже самі часто стикаємося з проблемою пошуку працівників у нашому шестиповерховому офісі. Ми також планували, що наш експериментальний додаток у подальшому стане основою для проведення статистичної аналітики і оптимізації розміщення працівників всередині нашої компанії.

Ідея додатку

Нас не цікавлять банальні рішення, тому ідею поєднання nearables зі звичайними телефонами ми відкинули одразу. Натомість, як пристрої для трекання ми взяли розумні годинники Android Wear та Apple Watch. Оскільки ми повністю від’єднали розумні годинники від телефонів, наш додаток повинен був на 100% працювати автономно. Іншою причиною, чому ми обрали розумні годинники для свого експерименту, було бажання перевірити, чи справляться вони з цим завданням, зважаючи на усі їхні обмеження: Bluetooth з низьким енергоспоживанням, API, передачу HTTP, фонові сервіси тощо.

Ідея проста: ми прикріпляємо nearables у всіх ключових точках нашого офісу — біля входу, у ліфтах, на кухнях, у спортзалі тощо. Усі UUID nearables ми під’єднуємо до кожної з цих точок. Паралельно, наші працівники інсталюють додаток на своїх розумних годинниках і реєструють їх (це, безсумнівно, вимагає їхньої згоди). Це єдина дія, що вимагається від користувачів.

Ми задумали, що, у першу чергу, додаток повинен виконувати такі фукнції:
— Логуватися (через телефон);
— Давати дозвіл на фоновий сервіс, який буде взаємодіяти з біконами (на розумному годиннику);
— Надсилати UUID, отримані від nearables, розпізнаних поблизу — разом з ІD користувача і поточним часом (на розумному годиннику);
— Показувати на дисплеї точки перебування працівників, опираючись на серверні дані («пріоритетних» працівників — на розумному годиннику і телефоні; усіх працівників — тільки на телефоні).

Додаткові функції включатимуть:
— Можливість маркувати працівників, яких ви шукаєте найчастіше, як «пріоритетних», щоби інформація про місце їхнього перебування зберігалася окремо (на телефоні);
— Можливість пошуку людей за іменем (на телефоні).

Як це повинно було працювати

Коли ми працювали з шаблонами на смартфонах, у нас не виникало жодних проблем, пов’язаних з SDK. Тому ми сподівалися, що з розумними годинниками також все пройде гладко. За нашим задумом, розумний годинник повинен був отримувати інформацію з найближчого nearable, надсилати її серверу, щоб інформація про ваше поточне місце розташування ставала доступною для інших користувачів. Звучить нескладно, правда?

Android

Якщо ви використовуєте одну і ту ж систему на телефоні і розумному годиннику, це означає, що ви можете використовувати усі існуючі бібліотеки, анімації та SDK на маленькому екрані. Тому ми мали намір використати SDK від Estimote на годиннику таким самим чином, як ми робили це на телефоні. Зважаючи на зміни в Android Wear, пов’язані з появою підтримки Wi-Fi (якщо він доступний на апаратному рівні), ми хотіли використати безпровідну мережу для пересилання даних зі стікера на сервер.

iOS

Ми вже бачили, як пошук біконів працює на iOS, коли тестували SDK Estimote. У моделі watchOS 2 передбачена можливість доступу до хардверної частини годинника і комунікація напряму зі знайомими Wi-Fi точками. Саме тому нам дуже кортіло дізнатися, чи, працюючи в автономному режимі, додатки Apple Watch зможуть розпізнавати бікони Estimote.

Як це працювало насправді

Android

На щастя, у нас не виникло проблем із запуском Estimote SDK на годиннику Android Wear. Хлопці з Estimote створили вичерпні зразки, тому ми витратили небагато часу на написання простого сервісу під розумний годинник для комунікації з nearables у фоновому режимі.

Проте, ми все-таки зіткнулися з деякими проблемами. Наприклад, ми не могли покластися на SDK у обробці подій, коли ґаджет з’являється чи зникає із радіуса досяжності nearable. Це працювало з біконами, але не зі стікерами. Ми просто-напросто не отримували від стікерів жодних сигналів. Тоді ми пішли в обхід і використали іншу опцію: слухача (the listener), який опрацьовує кожну подію, отриману з nearable (близько двох подій за секунду). І вуаля — нам вдалося отримати дані від стікера. Тоді прийшов час передавати їх на сервер.

Раніше для пересилки даних з годинника на сервер ми використовували один із DataLayerAPI, щоби передавати інформацію на телефон, яку би той надсилав на сервер. Але чи можливо пересилати дані з годинника безпосередньо на сервер за допомогою Wi-Fi? Відповідь: так.

Але тут є декілька нюансів, до яких ви повинні бути готові:
— Розумний годинник не повинен бути приєднаним до телефону.
— Розумний годинник повинен бути під’єднаний до Wi-Fi-мережі.

Окрім цього, майте на увазі, що Wi-Fi-звязок може бути автоматично втрачений, коли заряд батареї буде низький (це може бути закладено в налаштуваннях годинника).

Дотримуючись цих вказівок, ви можете використовувати свій звичний код для того, щоби надсилати HTTP-запити. До прикладу ми використовували OkHttp-бібліотеку. Так ми відображали дані про місце перебування потрібних нам людей. Тут є один мінус — ви не можете налаштувати свій додаток, допоки не під’єднаєте годинник до телефону. В загальному, ось так це працювало на моєму столі, де лежали nearables, телефон і годинник.

watchOS

Моніторинг nearables за допомогою існуючого Estimote WatchKit SDK працював лише на моделі watchOS 1. Самі додатки працюють на iPhone, а Apple Watch в цьому випадку використовується тут лише для виведення сповіщень на екран. Оскільки на моделі OS2 додатки запускаються безпосередньо на годиннику, ми не можемо тут використати цей SDK. Ми пробували різні обхідні шляхи, щоби примусити Apple Watch знаходити nearables, але виглядає на те, що Apple добряче постарався, аби унеможливити цю функцію на своєму розумному годиннику.

Більше технічних деталей представлено у нашому R&D-блозі.

iOS

Ми створили простий демо-додаток, який би шукав «знайомі» nearables і надсилав оновлення про місце перебування користувачів на сервер. Для того, щоби додаток здійснював фоновий моніторинг, для нього має бути дозволений фоновий режим: «Додаток комунікує через CoreBluethooth».

Існує 2 API, які дозволяють пошук біконів на iOS-платформі, використовуючи Estimote SDK:
— Пошук в радіусі. Запускається лише коли пристрій вловлює поблизу бікон. Спрацьовує приблизно 2 рази на секунду, якщо користувач перебуває поблизу бікона;
— Моніторинг. Запускається, коли користувач входить або виходить із зони бікона. Є дві опції, доступні під час роботи з API. Перша — сканувати середовище, шукаючи бікони у зоні досяжності. Друга — полювати лише на бікони зі спеціальними характеристиками.

Якщо обидві ці опції чудово працюють, коли додаток перебуває у фоновому режимі, то, коли телефон заблокований, вони поводяться трохи по-іншому:
— Пошук в радіусі не працює, якщо додаток працює у фоновому режимі. Це було зроблено для того, щоби у фоновому режимі додаток не запускався надто часто, коли користувач перебуває біля бікона;
— Моніторинг працює лише якщо ви хочете отримувати сповіщення про те, що ви увійшли у зону того чи іншого бікона, чи вийшли з неї. Це означає, що ми не можемо отримувати сповіщення про всі навколишні бікони, коли додаток працює у фоновому режимі.

І ще одна річ. Якщо користувач вимкнув додаток, система не буде запускати його, навіть якщо у радіусі був знайдений знайомий бікон. Вимикаючи додаток, користувач дає знак, що він більше не хоче, щоби додаток виконував які-небудь функції, тому це досить логічно, що він буде запускатися самостійно. Однак, якщо додаток був зупинений системою (наприклад, через перевантаженість пам’яті), iOS запустить його і повідомить про впольований бікон.

Поведінка у реальних умовах

Зрозуміло, що тестування у реальних умовах дало нам більше цікавих нюансів і допомогло виявити проблеми, яких ми до того не помічали. Nearables виявилися не надто надійними, адже кожен з них поводився по-різному. Інтенсивність сигналу для одного і того ж nearable у тих самих умовах суттєво відрізнялися. Більше того, чотири стікери перестали працювати ще до завершення нашого тестування.

Ось два найважливіші висновки:
— Середня відстань, яка повинна бути між біконом і ґаджетом, щоби між ними встановився зв’язок, складає близько 1 метра. Чи цього достатньо? Насправді ні.
— Часу, щоби виявити бікон, у найкращому випадку потрібно до 3 секунд — що не так вже й погано.

Було цікаво спостерігати за тим, як різні перешкоди впливають на роботу nearables. Наприклад, двері ніяк не вплинули на інтенсивність сигналу, на відміну від склянок з водою (знову ж так, різні стікери поводили себе по-різному).

Характеристика/критерій Пристрій Результат Коментарі
Оптимальна відстань між пристроями Розумний годинник 1 м Зі збільшенням відстані, сигнал стає нестабільним
Максимальна відстань між пристроями Розумний годинник 2 м На цій відстані сигнал слабшає, часто nearable стає невидимим
Час з’єднання з nearable Розумний годинник 3-15 сек. Час з’єднання залежить від якості сигналу nearable

Час з’єднання:

Відстань Час з’єднання nearable з розумним годинником
0,2 м 2-3 сек.
1 м 4-5 сек.
2 м 6-15 сек.
Характеристика/критерій Пристрій Результати Коментарі
Перешкоди для nearables
(перерваний сигнал)
Розумний годинник Відсутній сигнал Смартфони, ноутбуки, монітори, мікрохвильові печі, холодильники, керамічні горнята з водою, люди — якщо щось із цих об’єктів з’являється на шляху, сигнал пропадає повністю або частково
Жодних перешкод для nearables (сигнал не перерваний) Розумний годинник Сигнал є Двері, одяг, верхній одяг, сумки
З’єднання декількох nearables з одним розумним годинником Розумний годинник ОК (4 nearables) На дисплеї відображається інформація тільки про останні вловлені nearables
З’єднання 2+ годинників з одним nearable Розумний годинник ОК (2 nearables) Кількість під’єднаних пристроїв не впливає на сигнал nearable

Підсумки

Незважаючи на все це, ми вважаємо, що нам вдалося досягти своєї початкової цілі з Android Wear. Додаток отримував інформацію від біконів, що перебували у зоні досяжності, надсилав її на сервер, а також отримував інформацію про розміщення інших біконів — при тому що додаток був встановлений на розумному годиннику, від’єднаному від смартфона.

З watchOS нам вдалося досягнути своєї мети лише частково.

Отже, наш експеримент з nearables залишив нам змішані відчуття. Тобто ми не були вражені результатами. В основному через те, що хоча nearables працюють без суттєвих затримок у часі, їх відстань до об’єктів не повинна перевищувати 1 метра. Однак якщо заглянете на сайт estimote.com, то побачите, що стікери промарковані статусом «В очікуванні на сертифікацію», проте нам пощастило їх отримати. Ми також використовували ранні версії SDK (першу версію для Android) і, сподіваємося, що багато проблем вже було виправлено і багато чого вдосконалено у пізніших версіях. Одне ми можемо сказати напевне: бікони — це дивовижна технологія, яка має великий потенціал для розвитку у майбутньому.


Стаття написана у свівавторстві з Богданом Мельничуком. Дякуємо Марті Чавазі за адаптацію з англійської.

  • Популярное

15 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Слабкі місця цієї концепції — раз:
"

Нас не цікавлять банальні рішення, тому ідею поєднання nearables зі звичайними телефонами ми відкинули одразу.
Натомість, як пристрої для трекання ми взяли розумні годинники Android Wear та Apple Watch.
"
і два:
"
— Розумний годинник не повинен бути приєднаним до телефону.
"

З першого випливає, що всі (як мінімум, найважливіші) співробітники, котрі повинні бути trackable, мусять обов’язково носити розумні годинники, що на сьогодні само собою не відбувається. Відповідно, слід або оснащувати їх годинниками за кошт компанії (що сильно здорожує проект), або миритися з тим, що система буде неповнофункціональна, адже відслідковувати можна буде не всіх. Плюс використання особистого пристрою для стеження роботодавцем може породити правовий комнфлікт. Обмеження ОС в такому випадку теж грає проти проекту, адже випадають співробітники, у котрих Pebble, Tizen-основані Samsung, чи всяка китайчатина. Загалом, ідея погано суміщається з принципом BYOD, хоча явно під нього задумана.

З другого випливає, що годинник працює не в штатному режимі і не виконує тих функцій, заради яких він купувався — тобто відображення даних з телефона. Це спричинить незадоволення власників годинників і спонукає їх ухилятися від користування системою. Знову ж таки, малосумісно з принципом BYOD.

Я би на етапі планування проекту вирішив, що пріоритетніше — дотримання принципу BYOD і дешевизна для корпорації-експлуатанта, чи повнота охоплення штату і відповідно якість функціонування системи. Якщо надійна всеохоплююча система — я би будував її на власних тегах-брелоках (можна сумістити з ключем від приміщень, ідентификаційною картою і т.д.) чи браслетах (спеціалізованих чи універсальних, головне щоб дешеві буди — ну або несли додаткову функцію, як наприклад той жеSafeband). Якщо BYOD — то все ж таки на телефонах; єдиною вимогою від роботодавця буде тоді лише постійно включений Bluetooth.

І загальне зауваження: «Нас не цікавлять банальні рішення» — це підхід в принципі неправильний для продакта, бо саме банальні рішення найпростіші для розгортання та масштабування, адже опираються на вже наявний парк пристроїв.

Вот ещё один эксперимент
developer.sonymobile.com/...oney-and-add-extra-value
...
А вот эти ребята работают над промышленной реализацией
inlocationalliance.org
inlocationalliance.org/members/current-members
...
Обзор компаний и технологий
docs.google.com/...VecUwdl10rKul0/edit#gid=0

Теж саме можна зробити тільки в аеропортах та молах для телефону. Типу геопозиціювання в приміщеннях.

3-4 секунды на коннект — безумно много. Если сделать немножко железа, то можно уложиться в 0.3 секунды на коннект, с радиусом метров 10-20 и стоимостью одного девайса доллара так 3

Быстрым шагом можно пройти мимо и пока бикон

Из статьи видно насколько беспомощные умные часы на данном этапе.

Дійсно цікавий проект, і розробляти його весело було напевно.

Але як тільки уявляю собі графіки і діаграмки скільки часу хто проводить у вбиральні/кухні/тенісній... так одразу і електро-ошийник нагадує))

Ага інструмент репресій))

Круто! Але, на жаль, не в кожного є розумний годинник із відповідною ОС. А ці бікони розраховані на те, щоб кріпитися, а не носитися з собою?

Якраз стікери, які ми використовували і розраховані на це. Вони мають липку задню частину, що спочатку покрита плівкою. Добре кріпляться на стіни/двері..

Никакой прайваси в туалетах!

Спасибо за статью. Мы сейчас пилим внутренний проект с биконами у которого подпроектом может стать проект подобный вашему.
Для первого PoC (чтобы понять взлетит/не взлетит) выбрали Phonegap с плагином от Estimote для общения с блютусом. И что-то количество багов и недоступных опций в плагине так зашкаливает, что я подумываю плюнуть на Phonegap и переписать сразу на нативный код.

ПС: Еще отличие — что пишем под телефоны, а не часы.
ППС: Статью закинул в закладки проекта :)

даже у нативного не все так гладко с этими биконами. я советую либу altbeacon заюзать. можете глянуть мой открытый код приложения
github.com/vitas/beaconloc

Крутое решение с биконами(:

блин вот это годная статья. очень крутой эксперимент не считая моральной составляющей. жаль тут не будет такого бурного обсуждения как во вчерашней статье о undomigration

Подписаться на комментарии