Нещодавно до нас звернувся стартап із трекером активності для собак. Нашийник збирав дані з акселерометра (MPU-6050), але сирі дані не давали відповіді — активний пес чи відпочиває. Наша команда спроектувала мобільний додаток під iOS та Android, який класифікує поведінку через Core ML та TensorFlow Lite. За 8 тижнів ми впровадили BLE-синхронізацію, дашборд із трендами та геофенсинг. Гарантуємо стабільну роботу при будь-якому навантаженні — досвід понад 5 років у подібних проєктах. Зв'яжіться з нами для оцінки вашого проєкту.
Реалізація моніторингу активності улюбленця: від даних до висновків
Класифікація поведінки улюбленця за даними інерціальних датчиків — ключове завдання. Ми використовуємо комбінацію акселерометра та гіроскопа з частотою 50 Гц. На пристрої застосовується машинне навчання: Core ML на iOS, TensorFlow Lite на Android. Модель обробляє вікна по 2.5 секунди та видає один із шести класів активності.
Як класифікувати активність за даними з трекера?
Процес класифікації містить такі кроки:
- Збір даних з акселерометра (ADXL345) з частотою 50 Гц.
- Накопичення вікна з 125 семплів (2.5 секунди).
- Витяг ознак (середнє, дисперсія, енергія).
- Передача ознак у модель Core ML або TensorFlow Lite.
- Отримання передбачення класу.
Наші інженери оптимізували вікно зі ковзним кроком 25 семплів (50% перекриття) для плавного детектування переходів між активностями.
class PetActivityClassifier {
private let model: PetActivityMLModel
private var window: [[Double]] = []
private let windowSize = 125
private let strideSize = 25 // 50% перекриття
func processSample(x: Double, y: Double, z: Double) -> ActivityClass? {
window.append([x, y, z])
guard window.count >= windowSize else { return nil }
let input = try? MLMultiArray(shape: [1, NSNumber(value: windowSize), 3], dataType: .double)
for (i, sample) in window.enumerated() {
input?[i * 3] = NSNumber(value: sample[0])
input?[i * 3 + 1] = NSNumber(value: sample[1])
input?[i * 3 + 2] = NSNumber(value: sample[2])
}
window.removeFirst(strideSize)
guard let modelInput = input,
let prediction = try? model.prediction(input: modelInput) else { return nil }
return ActivityClass(rawValue: prediction.classLabel)
}
}
Для мобільних пристроїв ми конвертуємо модель з TensorFlow у Core ML через coremltools із підтримкою FP16 та int8 квантизації. На Android використовується делегат NNAPI для апаратного прискорення. Це знижує час інференсу до 5-10 мс на одному вікні, що дозволяє обробляти дані в реальному часі без впливу на UI-потік.
Синхронізація даних з трекера по BLE та LTE
| Протокол | Частота синхронізації | Споживання батареї | Затримка |
|---|---|---|---|
| BLE | При наближенні (кілька разів на день) | Низьке (1-2 мА·год за сесію) | 1-5 секунд |
| LTE-M (CAT-M1) | Кожні 1-5 хвилин | Середнє (100-500 мА·год на день) | < 1 секунди |
Для BLE використовуємо GATT з Indicate Characteristic та MTU 512. На Android запитуємо MTU через gatt.requestMtu(512), на iOS — через peripheral.maximumWriteValueLength(for: .withResponse). LTE-трекери працюють через REST API з JSON-пакетами.
Трекер накопичує агрегати активності (хвилинні зведення) та синхронізує по BLE при наближенні телефона. Протокол: GATT з Indicate Characteristic — трекер сповіщає про готовність даних, додаток читає пакетами по 20 байт (MTU за замовчуванням). Для прискорення запитуємо MTU 512. GPS-трекери з LTE-M синхронізуються через хмару. Мобільний додаток — клієнт до REST API. Геофенсинг реалізовано на сервері: зони «дім», «двір», пуш-сповіщення коли улюбленець вийшов за периметр.
Чому важливий правильний вибір протоколу синхронізації?
Від протоколу залежить час роботи трекера від батареї та актуальність даних. BLE підходить для щоденної синхронізації при поверненні додому, але не дає онлайн-трекінгу. LTE-M дозволяє відстежувати улюбленця в реальному часі, але вимагає частішої зарядки. Гібридна схема (BLE для детальної класифікації, LTE-M для GPS-позиціонування) оптимальна для більшості сценаріїв.
Дашборд здоров'я улюбленця
Добова статистика активності — основний екран. Кільцева діаграма активності за день: sleep, rest, walk, run, play. Трендові графіки по тижнях та місяцях. Метрики, які цікавлять власників: хвилини активного руху, дистанція (розраховується за кроками з акселерометра або GPS), калорії (груба оцінка за вагою улюбленця), якість сну (рухливість вночі), порівняння з попереднім тижнем. Пуши про аномалії — «Барсик сьогодні активний на 80% менше звичайного» — працюють через Firebase Cloud Messaging з серверною аналітикою по baseline за 7 днів.
Геолокація та геофенсинг
Для GPS-трекерів зі стільниковим зв'язком — періодичні позиції через API (кожні 1–5 хвилин у режимі економії батареї, кожні 10–30 секунд у режимі стеження). Карта — MapKit (iOS) або Google Maps SDK (Android) з історичним треком улюбленця за день. Геофенсинг на рівні додатка (CLRegion) працює тільки коли телефон у зоні. Надійніше — серверний геофенсинг з пушами. На власному досвіді переконалися: гібридна схема (додаток + сервер) дає 99% точності.
Що входить у розробку під ключ?
| Етап | Результат |
|---|---|
| Аналітика | Протокол трекера, план ML-моделі, API-специфікація |
| Проєктування | Дизайн-макети (Figma), архітектура додатка |
| Реалізація | iOS (Swift 5.9, SwiftUI) та/або Android (Kotlin, Jetpack Compose) |
| Інтеграція | BLE, хмарні сервіси (Firebase, Supabase), StoreKit 2 для підписок |
| Тестування | QA на реальних трекерах, навантажувальне тестування |
| Деплой | App Store та Google Play з сертифікатами та code signing |
| Підтримка | Моніторинг крашів, оновлення ML-моделі, оптимізація |
Входить повна документація, доступи до адмін-панелі, навчання. Стандартна гарантія на код — 6 місяців. Вартість розраховується індивідуально залежно від складності. Отримайте консультацію для вашого проєкту — ми допоможемо з вибором стеку та розрахуємо бюджет.
Як ми оцінюємо та виконуємо роботу?
- Збір даних: вивчаємо протокол трекера, вимоги до ML-моделі, бізнес-логіку.
- Аудит та аналіз: визначаємо оптимальний стек, архітектуру, ризики.
- Проєктування: створюємо дизайн-макети та технічну документацію.
- Оцінка: на основі аналізу формуємо точний кошторис та строки.
- Розробка: ітеративно реалізуємо функціонал, з регулярними демо.
- Тестування: покриваємо unit-тестами та проводимо QA на реальних пристроях.
- Запуск: публікуємо в магазини додатків, налаштовуємо моніторинг.
Орієнтовні строки: для BLE-трекера з класифікацією та дашбордом — 6–10 тижнів; з GPS та серверним геофенсингом — 3–4 місяці. Точний строк залежить від протоколу трекера та кількості платформ.
Типові помилки при розробці трекерів активності
На основі нашого досвіду, ось дві найпоширеніші помилки:
-
Ігнорування налаштування MTU. За замовчуванням BLE MTU складає 23 байти. Без збільшення до 512 передача даних триває набагато довше, що збільшує час сесії та енергоспоживання. Ми завжди запитуємо
MTU 512на обох платформах. - Неправильний вибір розміру вікна для ML. Занадто коротке вікно (< 1 секунди) не дає достатньо ознак, занадто довге (> 5 секунд) вносить затримку. Оптимум — 2.5 секунди з 50% перекриттям, перевірений нами на практиці.
Ми розробляємо мобільні додатки більше 5 років. За плечима понад 20 проєктів у категорії «Здоров'я та фітнес», включаючи інтеграції з HealthKit та Google Fit. Використовуємо сучасні підходи: StoreKit 2, App Tracking Transparency, Kotlin Multiplatform. Гарантуємо дотримання App Store Review Guidelines та політик конфіденційності. Досвід вирішення нестандартних завдань — наприклад, робота з INA219 для енергоспоживання нашийника — дозволяє передбачити вузькі місця до початку розробки.