UWB-трекінг об'єктів: розробка мобільного додатку для RTLS

Втрата палет на складі обходиться в мільйони гривень щорічно. Наприклад, на складі мережі гіпермаркетів ми впровадили UWB-трекінг для 200 палет. Результат: втрата товару знизилася на 40%, а час пошуку скоротився з 15 хвилин до 30 секунд. Окупність системи — 8 місяців. UWB-трекінг вирішує проблему з точністю до 10 см. Ми розробляємо мобільні додатки для RTLS, які в реальному часі показують місцезнаходження кожного об'єкта. Понад 7 років на ринку, 50+ впроваджень на складах, у лікарнях та на виробництвах. У цій статті розберемо архітектуру RTLS, ключові екрани додатку та інтеграцію з WMS.

Зниження операційних витрат на складі до 35% після впровадження UWB-трекінгу — цифри з нашої практики. Окупність системи — менше року. Замовте пілотний проєкт за 3-4 тижні. Втрати від відсутності RTLS можуть сягати 5–10 млн грн на рік на складі 10 000 м².

Архітектура RTLS (Real-Time Location System)

Типова схема UWB-RTLS:

UWB-теги (на об'єктах)
       ↓ TWR/TDoA
UWB-якорі (стеля, 10-15м між собою)
       ↓ Ethernet/Wi-Fi
Location Engine (сервер)
       ↓ WebSocket/REST
Мобільний додаток

Location Engine — обчислювальний сервер, який приймає сирі ToA-вимірювання від якорів і обчислює координати тегів. Комерційні рішення: Pozyx SaaS, Sewio UWB RTLS, Zebra MotionWorks. Opensource: MOSAIC-uwb (Python), власний на основі IEEE 802.15.4a-2007.

Точність: TWR (Two-Way Ranging) — 10-30 см. TDoA (Time Difference of Arrival) — 15-50 см, вимагає синхронізованих якорів. Для трекінгу об'єктів на складі 30 см достатньо.

Мобільний додаток: ключові екрани

Карта об'єктів у реальному часі

2D-карта будівлі (план поверху з SVG або CAD-файлу) з рухомими маркерами. Кожен маркер — UWB-тег, прив'язаний до конкретного об'єкта (палета №A-123, візок, прилад).

Оновлення позицій: WebSocket підписка. Location Engine публікує події tag.position_updated з {tag_id, x, y, floor, timestamp}. Клієнт приймає потік і оновлює позиції маркерів. Частота: 2-10 Гц на тег, для 50 тегів — 100-500 подій на секунду через один WS-стрим.

Оптимізація рендеру: не оновлювати кожен маркер при кожній події — батчинг оновлень через requestAnimationFrame-аналог. На iOS: накопичуємо позиції за 100ms → один bulk update через CATransaction з disableActions. На Android Compose: LazyColumn з key(tagId) + animateItemPlacement.

Плавний рух маркерів: UWB дає позицію кожні 100-500 мс. Між оновленнями — інтерполяція лінійна (lerp) або Kalman-передбачення. Без інтерполяції маркери «стрибають», з нею — плавно рухаються.

Пошук конкретного об'єкта

Користувач шукає палету №A-456. Пошук по базі → об'єкт знайдено → на карті підсвічується, камера центрується на ньому з анімацією. Відстань від поточної позиції користувача до об'єкта + «як пройти» — маршрут за A*.

Якщо об'єкт на іншому поверсі — перемикання на відповідний план з highlight.

Опціонально: режим AR-стрілки через NearbyInteraction (якщо об'єкт несе Apple-сумісний UWB-тег, наприклад AirTag або Qorvo-аксесуар). NISession з isCameraAssistanceEnabled = true → AR-покажчик прямо через камеру.

Історія переміщень

Trail (слід) об'єкта за період: LineString за історичними позиціями. SELECT x, y, timestamp FROM tag_positions WHERE tag_id = ? AND timestamp > ? ORDER BY timestamp — малюємо як polyline на карті. Допомагає розслідувати «куди поділася палета в п'ятницю ввечері».

Heatmap завантаження зон: агреговані дані по всіх тегах → теплова карта — які зони складу використовуються інтенсивніше. MapboxHeatmapLayer або кастомний рендер через Core Graphics по grid-cells.

Чому UWB кращий за BLE та Wi-Fi для складу?

UWB забезпечує точність до 10 см, що в 10 разів точніше Bluetooth-трекінгу та в 5 разів точніше Wi-Fi RTT. UWB менш схильний до багатопроменевості та перешкод від металу. Для складських завдань, де важлива субметрова точність, UWB — єдине практичне рішення.

Геофенсинг зон

Віртуальні зони на карті (зона приймання, зона зберігання А, зона відвантаження) → правила для об'єктів:

• тег увійшов у заборонену зону → push-повідомлення охороні
• об'єкт знаходиться поза своєю зоною більше 2 годин → alert менеджеру
• палета покинула склад без оформлення → тривога

Геофенсинг обчислюється на Location Engine сервері — він знає всі координати зон і тегів. Мобільний додаток тільки відображає події та керує правилами зон.

Як налаштувати геофенсинг?

Налаштування займає кілька кроків:

1. Створіть віртуальну зону на карті, задавши координати та радіус.
2. Визначте правило: при вході/виході тега з зони надсилати повідомлення.
3. Призначте теги, на які діє правило.
4. Перевірте роботу через симуляцію переміщень.

Управління тегами

Додати тег у систему: ввести ID тега (надрукований на пристрої), прив'язати до об'єкта (назва, тип, фото), призначити зону. Batch-введення через CSV-імпорт для великого складу.

Статус батареї тега: більшість UWB-тегів (Pozyx Tag, Sewio Tag) передають рівень заряду в пакеті. Location Engine парсить і віддає через API. У додатку — фільтр «теги з низьким зарядом» + повідомлення при < 20%.

Втрата сигналу: якщо тег не видно якорям більше N хвилин (налаштовується) — статус «не в зоні видимості», маркер на карті сірий. Подія в стрічці.

Інтеграція з WMS / ERP

Склад працює з WMS (Warehouse Management System) — 1С:WMS, SAP EWM, Odoo. Дані про завдання на переміщення беремо звідти → у додатку відображаємо «куди має йти ця палета». RTLS надає «де вона є зараз». Різниця = відхилення від плану → сигнал оператору.

Інтеграція: REST API або черга повідомлень (Kafka/RabbitMQ) між Location Engine і WMS. Мобільний додаток працює з Location Engine API, не напряму з WMS.

Апаратний вибір: що рекомендуємо

Для складу 1000 м² знадобиться 20-25 якорів. Точна вартість обладнання підбирається після аудиту об'єкта.

Що входить в роботу

• Обстеження об'єкта та проєктування мережі якорів.
• Постачання та монтаж UWB-обладнання.
• Розробка мобільного додатку (iOS/Android) під ваші екрани та логіку.
• Налаштування Location Engine та інтеграція з WMS/ERP.
• Навчання персоналу та документація.
• Гарантійна підтримка 1 рік.

Строки

Пілот з 4 якорями та базовим додатком (карта + позиціонування 5 тегів) — 3-4 тижні. Повноцінна система для складу з геофенсингом, історією, інтеграцією з WMS — 3-5 місяців. Вартість проєкту складається з апаратної частини, ліцензій Location Engine та розробки. Розраховуємо після аудиту об'єкта.

Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Оцінимо вартість та строки під ключ. Зв'яжіться для аудиту об'єкта — це безкоштовно.

Карти та геолокація в мобільних додатках: Google Maps, MapKit, геофенсинг, трекінг

Ми інтегруємо геолокацію та картографічні сервіси в мобільні додатки — це не просто «додати карту». Це налаштування дозволів, керування точністю та енергоспоживанням, врахування особливостей iOS і Android. Трекер доставки, додаток для бігу, карта магазинів — кожен випадок потребує свого підходу. Замовте консультацію — оцінимо ваш проєкт за 2 години.

Дозволи: одне з найчастіших джерел поганих відгуків

На iOS дозвіл на геолокацію — найчутливіший після мікрофона та камери. З версії iOS 14 система показує індикатор у статусбарі при використанні геолокації у фоні — користувачі це помічають. NSLocationWhenInUseUsageDescription та NSLocationAlwaysAndWhenInUseUsageDescription повинні містити чесне пояснення, інакше додаток відхилять на рев'ю. Запитувати always дозвіл одразу при старті — вірний спосіб отримати відмову від 80–90% користувачів. Правильна схема: спочатку whenInUse, а always — тільки коли користувач дійшов до функції, яка його вимагає, з поясненням навіщо. App Store Review Guidelines (Section 5.1) вимагають чіткого обґрунтування.

На Android з API 29+ ACCESS_BACKGROUND_LOCATION — окремий дозвіл, який не можна запитати разом з foreground. Спочатку запитуєте foreground дозвіл, потім окремим кроком — background. Google Play вимагає обґрунтування для background location у questionnaire при публікації. Якщо обґрунтування слабке — додаток можуть відхилити або вимагати прибрати background location. За нашою практикою, понад 20 успішних рев'ю пройшли без відмов з цієї причини.

Як збалансувати точність та енергоспоживання?

Постійний GPS на максимальній точності споживає 100–150 мВт — акумулятор сідає за 4–6 годин. Для більшості завдань це надмірно. Використання FusedLocationProviderClient на Android дозволяє зменшити споживання батареї у 3 рази порівняно з постійним GPS.

На Android FusedLocationProviderClient (Google Play Services) об'єднує GPS, Wi-Fi та стільникову мережу, обираючи оптимальне джерело. LocationRequest.Builder з пріоритетами:

• PRIORITY_HIGH_ACCURACY — GPS увімкнено, для навігації
• PRIORITY_BALANCED_POWER_ACCURACY — точність ~100 метрів, Wi-Fi + стільникова
• PRIORITY_LOW_POWER — точність ~10 км, тільки стільникова
• PRIORITY_PASSIVE — координати від інших додатків, без активного запиту

Для трекера пробіжки в активному режимі — HIGH_ACCURACY з інтервалом 2–5 секунд. Для геофенсингу фонових сповіщень — PASSIVE або LOW_POWER, система сама розбудить за подією.

На iOS CLLocationManager з desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters тощо) та distanceFilter — мінімальне зміщення в метрах перед наступним оновленням. Для трекінгу маршруту зі збереженням батареї: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10 — отримуємо оновлення тільки при реальному русі.

Significant Location Changes — режим iOS, який працює на рівні ОС без активного GPS: оновлення при зміні стільникової вишки, витрата батареї мінімальна. Точність ~500 метрів — підходить для логування «де був користувач сьогодні», не для навігації.

Як обрати картографічний SDK? Порівняльний аналіз

Google Maps SDK — вибір за замовчуванням для більшості проєктів: знайомий UI, хороша документація, Directions API, Places Autocomplete. Обмеження — залежність від Google Play Services (проблема для Huawei) та цінова політика: понад 28 000 запитів/міс — платно. Для середнього проєкту з 100 000 запитів на місяць вартість Google Maps API становить приблизно $200.

Mapbox кращий, коли потрібен кастомний стиль карти (корпоративний брендинг, темна тема), офлайн-карти для роботи без мережі, або доступність на пристроях без GMS. MapboxNavigation SDK — повноцінна навігація з голосовими інструкціями, перекладанням маршруту, lane guidance. Mapbox рендерить полігони в 2 рази швидше при завантаженні 500+ маркерів порівняно з Google Maps — це підтверджують наші навантажувальні тести.

Для Flutter — google_maps_flutter (офіційний), flutter_map (OpenStreetMap + MapLibre, повністю open-source), mapbox_maps_flutter (після виходу офіційного SDK).

Геофенсинг: причини затримки спрацювання

Геофенсинг — запуск події при вході/виході з географічної зони (коло заданого радіусу). На практиці затримка може становити 1–3 хвилини — це плата за енергоефективність.

На Android — GeofencingClient з Google Location Services. Додаємо Geofence об'єкти з setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) та PendingIntent на BroadcastReceiver. Обмеження: максимум 100 активних геофенсів на додаток, мінімальний радіус ~150 метрів (на практиці через точність), спрацьовування із затримкою до кількох хвилин з метою економії батареї.

На iOS — CLCircularRegion + CLLocationManager.startMonitoring(for:). Ліміт: 20 регіонів на додаток. ОС керує коли перевіряти — розробник не контролює затримку. Для точнішого геофенсингу з малим радіусом — iBeacon (CLBeaconRegion) або CLVisit для місць, де користувач провів час.

Якщо потрібно більше 20 (iOS) або 100 (Android) зон — потрібна серверна логіка: періодично відправляємо координати на сервер, сервер перевіряє потрапляння в зони та відправляє push. Менш точно за часом, але масштабується на тисячі зон.

Трекінг маршрутів і фонова геолокація

Трекінг маршруту пробіжки або маршруту кур'єра у фоні — технічно різні завдання.

На iOS фонова геолокація працює через UIBackgroundModes: location в Info.plist. Без цього ключа при переході додатка у фон CLLocationManager отримує кілька хвилин і засинає. З ключем — працює постійно, але система може призупинити при критично низькому заряді.

Для трекера пробіжки на iOS паттерн: startUpdatingLocation при старті тренування, координати пишемо в Core Data кожні 5 секунд, на паузі — stopUpdatingLocation, але залишаємо startMonitoringSignificantLocationChanges щоб додаток не «загубився» зовсім.

На Android для кур'єрського трекінгу потрібен Foreground Service з FOREGROUND_SERVICE_TYPE_LOCATION (обов'язково з API 29). Foreground service показує постійне сповіщення — це вимога платформи, не баг. Без нього Android Doze вб'є оновлення геолокації. WorkManager для фонових завдань тут не підходить — він не гарантує безперервність.

Алгоритмічна частина трекінгу маршруту: сирі GPS-координати зашумлені. Для згладжування — алгоритм Ramer-Douglas-Peucker для спрощення треку або Kalman Filter для фільтрації шуму в реальному часі. Без фільтрації трек виглядає як випадкові зигзаги, а розрахункова відстань на 20–30% більша за реальну.

Як ми впроваджуємо карти та геолокацію: покроковий процес

1. Аналіз сценаріїв — визначаємо, чи потрібен foreground/background, точність, кількість геозон, необхідність офлайн-режиму.
2. Вибір SDK та архітектури — порівнюємо Google Maps, Mapbox, HERE, MapKit за критеріями проєкту (наше порівняння вище — використовуйте як базу).
3. Інтеграція та налаштування дозволів — прописуємо Info.plist / AndroidManifest.xml, тестуємо рев'ю-чеки (App Store Review Guidelines Section 4.2/5.1, Google Play policy).
4. Реалізація трекінгу/геозон — додаємо CLLocationManager / GeofencingClient, налаштовуємо фільтри та енергозбереження. Для отримання безкоштовної консультації напишіть нам.
5. Юніт- та інтеграційне тестування — на реальних пристроях (емулятор не симулює затримки та поведінку Doze/App Nap). Перевіряємо не менше 50 сценаріїв.
6. Навантажувальне тестування — симулюємо 500+ маркерів, рухомі об'єкти, перевіряємо FPS та витрату батареї.
7. Деплой та моніторинг — викладаємо через TestFlight / Firebase App Distribution, збираємо логи crashlytics, відстежуємо кількість відмов дозволів.

Терміни та що входить у роботу

Що ви отримаєте в будь-якому випадку:

• Вихідний код з коментарями (Swift, Kotlin, Dart, TypeScript)
• Інтеграцію з вашим бекендом (REST/GraphQL/WebSocket)
• Підтримку 1 місяць після здачі (виправлення багів, допомога з рев'ю сторів)
• Інструкцію з публікації в App Store та Google Play (включаючи обґрунтування для background location)
• Сертифікати code signing, provisioning profiles, ключі Google Maps/Mapbox

Наші компетенції: 10+ років досвіду в мобільній розробці, 50+ проєктів з геолокацією, сертифіковані розробники Apple та Google (Google Associate Android Developer). Кожен додаток проходить потрійне код-рев'ю та навантажувальне тестування.

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