Object tracking: чому трек об'єктів губиться в застосунку
Object tracking зривається не тоді, коли об'єкт виходить із кадру, а раніше — коли опорних ознак стає менше, ніж потрібно для стійкої оцінки пози.
Швидкий прохід камери дає змаз і просідання різкості: ознаки розмиваються, і трекер починає не уточнювати положення, а вгадувати його.
Зміна ракурсу додає друге обмеження — на плоских і однотонних ділянках немає за що зачепитися, тому масштаб і нахил об'єкта розходяться з реальними.
Окремий клас відмов — перекриття об'єкта: рука, перехожий або сусідній предмет на секунду-дві закривають опорну область, і набір видимих ознак обнуляється.
ARCore і споріднені платформи в цей момент переходять у повторну локалізацію, а до її завершення прив'язка або завмирає, або стрибає на схожу область поруч.
Слабке світло посилює все перелічене: шум сенсора й м'які тіні дають хибні межі, об'єкт знаходиться, але зі зміщенням на кілька сантиметрів.
Ціна цих збоїв вимірюється не в кадрах, а в поведінці користувача. Віртуальна модель зіскакує з експоната, підказка лягає повз вузол обладнання, оператор сканує полицю повторно, а частина сесій закінчується на першому ж зриві.
У підтримку надходить «застосунок не працює» — хоча причина в утраті треку, а розпізнавання й логіка відпрацювали штатно.
На практиці такий сценарій закривається поєднанням: стійке розпізнавання на вході, повторна локалізація після перекриття, передбачення пози між кадрами й пороги впевненості, за яких застосунок чесно просить навести камеру замість того, щоб показувати зміщений шар. Розбираємо, як це влаштовано і які сценарії зйомки варто перевіряти до релізу.
Що дає стабільний трекінг: точність, швидкість, менше збоїв
Стабільний object tracking перевіряється не відчуттям «наче працює», а часткою успішних треків: на наборі тестових сцен об'єкт доводиться до кінця сесії в більшості прогонів, а не губиться на середині.
Метрика рахується по всій вибірці — різні ракурси, освітлення, швидкість руху, — а не за однією вдалою демонстрацією.
Час до першого кадру з розпізнаванням теж стає передбачуваним: сцена ініціалізується за частки секунди, і користувач бачить підказку раніше, ніж встигає вирішити, що застосунок не відповідає.
Це наслідок прогріву моделей і передзавантаження словника об'єктів, а не везіння на конкретному пристрої.
Головний ефект — класи відмов, які зникають повністю. Сцена перестає зриватися при частковому перекритті об'єкта, при різкому русі камери, при слабкому світлі й відблиску, а хибні спрацювання на схожих за формою предметах відсікаються на рівні відбору гіпотез.
Стійкість треку — окрема метрика: після короткого перекриття об'єкт повертається з тим самим ідентифікатором, а не заводиться заново. Без цього лічильник об'єктів і прив'язка підказок до конкретного предмета розвалюються на першому ж перекритті.
Нарешті, робота на середніх пристроях: та сама частка успішних треків тримається на апаратурі середнього сегмента, а не лише на топових моделях. Це досягається обмеженням обчислювального навантаження на кадр і адаптацією частоти обробки під поточний запас продуктивності.
Режими object tracking: порівняння підходів та обмежень
Режим трекінгу обирають за трьома осями: стійкість треку, свобода сценарію, вартість обчислень. Маркерний трекінг дає передбачувану геометрію — поза відновлюється за кутами мітки відомого розміру, помилка не накопичується за сесію.
Трекінг за ознаками сцени спирається на природні точки — кути, контури, текстури — і не вимагає готувати майданчик. Зворотний бік: на однотонних і глянцевих поверхнях ознак не вистачає, дрейф накопичується, потрібна періодична перевірка за опорним кадром.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Маркерний трекінг | Потрібна повторюваність стенда й точна поза об'єкта | Мітка має бути в кадрі; перекриття або засвітлення рвуть трек |
| Трекінг за ознаками сцени | Довільний фон, майданчик готувати не можна | Дрейф накопичується, просідання на однотонних і глянцевих поверхнях |
| Гібридна схема | Потрібні свобода сценарію й стійкість на довгих сесіях | Складніше налаштування: два контури, пріоритети перемикання, калібрування |
| Обробка на пристрої | Відгук критичний, канал нестабільний, кадри не покидають пристрій | Менше запасу за складністю моделі та кількістю об'єктів у кадрі |
| Обробка в хмарі | Важкі моделі, зйомка з різних пристроїв, кілька потоків | Залежність від каналу, затримка, передавання та зберігання кадрів |
Гібридна схема ділить навантаження: уточнення пози — на пристрої, важка перевірка — у хмарі за розрідженими кадрами. На розборі задачі дивимося, який режим витримає ваш сценарій на довгій сесії.
Як відбувається впровадження: етапи інженерної роботи
Впровадження трекінгу — це не підключення бібліотеки, а налаштування під конкретну сцену: те, що впевнено працює на тестовому стенді, розсипається за іншого світла або матеріалу поверхні. Тому ми йдемо від умов експлуатації до параметрів алгоритму, а не навпаки.
- Аудит сцени. Розбираємо, як об'єкт виглядає в реальних умовах: перепади освітлення, відблиски на глянці, фонові текстури, швидкість руху камери, типові перекриття. На виході — перелік умов, у яких розпізнавання зобов'язане працювати.
- Схема опорних ознак. Визначаємо, за що чіпляється трекінг: природні особливості поверхні, геометрія об'єкта або маркери. Ознаки добираємо так, щоб вони читалися під кутом і на робочій відстані.
- Налаштування трекінгу. Задаємо пороги спрацювання, фільтрацію тремтіння прив'язки, поведінку при частковому перекритті й правила переініціалізації після втрати об'єкта.
- Перевірка на реальних сценаріях. Прогоняємо рішення на майданчику з тими пристроями й світлом, де воно буде жити. Фіксуємо частку успішних захоплень, час відновлення після втрати та стабільність прив'язаних елементів.
- Доопрацювання за результатами перевірок. Розширюємо набір ознак, змінюємо ракурси обходу, додаємо підказки при невпевненому захопленні — доки метрики не вийдуть на узгоджений рівень.
- Передача рішення. Віддаємо документацію щодо конфігурації, схему опорних ознак, набір тестових сценаріїв та інструкції для команди, яка супроводжуватиме продукт.
Пакет передачі: схеми сцен, набори об'єктів, регламенти
Після приймання в команди замовника залишається не демонстраційний прототип, а робоча система з повним комплектом матеріалів.
Усе, що ми налаштовували під час проєкту, передається в редагованому вигляді — щоб наступна зміна сцени або поповнення каталогу не вимагали нас як єдиних носіїв знання.
- Конфігурації розпізнавання — профіль під кожен майданчик: пороги спрацювання, допустимі ракурси й дистанції, поведінка при слабкому освітленні. Профіль правиться без перезбирання застосунку.
- Схеми сцен — розмітка зон зйомки, прив'язка опорних елементів, вимоги до фону й світла. Нова сцена розгортається за схемою, а не методом проб.
- Картки об'єктів — еталонні зразки, ознаки зіставлення й межі, за якими результат вважається недостовірним, із поясненням причини кожної межі.
- Набори об'єктів — колекції під конкретні задачі, розведені за версіями: демонстраційні, робочі, архівні, з історією правок і відповідальним.
- Регламент оновлення — порядок введення й виведення об'єкта: підготовка зразків, перевірка на тестовій сцені, строк уведення в роботу, умови відкату до попередньої версії набору.
- Регламент розбору інцидентів — які події фіксуються, як відрізнити збій розпізнавання від помилки сцени, кому й у який строк надходить звернення.
- Документація рішення — архітектурна схема, точки інтеграції з вашими системами, формати обміну, чек-ліст приймання та перелік відомих обмежень.
Склад пакета узгоджуємо на старті проєкту: ви заздалегідь бачите, що залишиться всередині вашої команди і за якими документами вона зможе працювати самостійно.
Кейс впровадження: трек об'єктів на складі та в роздрібі
У розподільчому центрі мережі магазинів облік тримався на ручних обходах: комірник із терміналом збору даних проходив зону й звіряв палети з адресами зберігання за паперовим аркушем.
Один обхід займав 25-30 хвилин, повна звірка складу розтягувалася майже на зміну, а розбіжності спливали лише на інвентаризації. У торговельній залі картина та сама — викладку перевіряли очима, порожню полицю помічали через день-два, коли покупець уже пішов.
Пілот, що отримав робочу назву Склад-Трек, зібрали як застосунок із камерою на штатному смартфоні зміни.
Комірник наводить камеру на палету або полицю — розпізнавання визначає товар і утримує об'єкт у кадрі під час руху, лічильник перераховує одиниці й прив'язує їх до адреси зберігання. Дані надходять в облікову систему одразу, без ручного введення й другого проходу.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Обхід зони | 25-30 хвилин | 6-8 хвилин |
| Розбіжність залишків | 4-5% | менше 1% |
| Пошук товару за зміну | близько 3 годин | 40 хвилин |
| Ручні операції при звірці | весь цикл | один контрольний прохід |
Стійкість утримання виявилася вирішальною деталлю: якщо палету частково заслонили або її везли повз стелаж, трек не губився й супроводжував об'єкт далі.
На ділянках зі слабким світлом додали локальне підсвічування й донавчання на знімках самого складу — розпізнавання вийшло на 96-97% правильних спрацювань.
Зміна перестала простоювати на пошуку: простої скоротилися з годин до хвилин, вивільнений час пішов на приймання й роботу з браком, а не на звірку. Той самий контур перенесли в роздріб — обхід зали став займати один прохід замість двох.
Чим відстеження відрізняється від розпізнавання і чи потрібні обидва?
Розпізнавання об'єкта відповідає на питання «що це»: модель знаходить об'єкт у кадрі й повертає клас із рамкою. Про наступний кадр вона не пам'ятає нічого — при повторному проході той самий об'єкт отримає новий номер, а при короткому перекритті просто зникне й з'явиться знову.
Утримання треку — це ідентифікація між кадрами: система передбачає положення об'єкта, зіставляє його з попереднім станом і веде одну мітку, поки об'єкт у полі зору. Звідси береться рівна рамка без тремтіння й коректний підрахунок унікальних об'єктів.
Вибір режиму диктує задача. Якщо потрібна відповідь «чи є об'єкт і який» — достатньо розпізнавання. Якщо важлива безперервність у часі — підрахунок об'єктів, що проходять, траєкторія, реакція інтерфейсу на рух — без утримання треку не обійтися.
На практиці ми майже завжди будуємо поєднання підходів, як це зроблено в платформенному інструментарії рівня ARKit: розпізнавання періодично перезапускає трек при втраті, а легкий трекер утримує об'єкт між запусками.
Частка кадрів, де працює важка модель, падає, картинка залишається стабільною, а вартість обчислень перестає зростати разом із тривалістю сесії.
Технічні питання: слабкі пристрої, світло, масштабування
Слабке світло й пристрої середнього класу ми перевіряємо одним сценарієм: знімаємо той самий об'єкт при падінні освітленості й дивимося, на якому моменті трек іде в пошук замість хибної рамки.
Опора лише на колір тут не працює — ознаки доповнюються геометрією контуру й рухом, а поріг упевненості налаштовується так, щоб загублений об'єкт позначався загубленим, а не «залипав» на сторонньому предметі.
Зростання кількості об'єктів і офлайн-режим вирішуються архітектурно. На пристрої одночасно ведеться обмежена кількість активних треків, решта чекають у черзі й піднімаються за пріоритетом зони; перенавчання під нові класи не розширює навантаження на кадр.
Модель і ваги лежать локально, тому розпізнавання йде без мережі, а хмара підключається для аналітики й оновлення моделі.
Що відбувається при слабкому освітленні?
Контраст падає, і колірні ознаки перестають розділяти об'єкт і фон. Трек переходить на градієнти й геометрію, рідше оновлює позицію й утримує ідентифікатор довше, ніж встигає «перескочити» на сусідній предмет. Якщо об'єкт пішов із кадру, трек закривається — хибних спрацювань не залишається.
Чи потягне застосунок пристрій середнього класу?
Так. Модель квантизується й рахується на нейронному прискорювачі, детекція запускається не на кожному кадрі, а трекінг між запусками утримує позицію. Нагрівання й витрату батареї ми замірюємо на цільовому парку пристроїв до релізу, а не після.
Чи працює розпізнавання без мережі?
Так, ваги й логіка трекінгу лежать у застосунку, тому об'єкт відстежується в офлайні без затримки на запит. Мережа потрібна для збору статистики й донавчання: накопичені дані надходять при появі зв'язку, локальні результати при цьому не губляться.
Обговоримо задачу: підберемо режим і повернемося з оцінкою
Щоб повернутися з планом робіт та оцінкою строків, а не із загальними міркуваннями, потрібен мінімум вхідних даних.
Чим конкретніше постановка задачі, тим точніше ми підберемо режим трекінгу — за маркером, за природними ознаками об'єкта або гібридний — і тим менше переробок буде на етапі інтеграції із застосунком.
Що надіслати для розбору:
- сценарій використання: що потрапляє в кадр, з якої відстані й під якими кутами, рухається об'єкт чи стоїть;
- цільові об'єкти й умови зйомки — освітлення, фон, відблиски, перекриття іншими предметами;
- вимоги до стійкості треку: утримання при частковому перекритті, при тремтінні камери, кілька об'єктів одночасно;
- обмеження платформи: парк пристроїв, версії операційної системи, чи потрібна робота без мережі;
- що вже є — прототип, вихідні тривимірні моделі, дизайн, доступи до тестового стенда;
- критерії приймання у вимірюваному вигляді: частка правильних розпізнавань, час виходу на трек, допустима затримка реакції.
За підсумками обговорення ви отримуєте план робіт з етапами й точками контролю, схему архітектури з розподілом навантаження між пристроєм і сервером, оцінку строків за кожним етапом і сценарій пілотного запуску на обмеженому наборі об'єктів — його зазвичай достатньо, щоб перевірити якість розпізнавання до повного складання. Опишіть задачу в тому вигляді, у якому вона є, — повернемося з оцінкою й планом.
