Чому розпізнавання жестів ламається на реальних пристроях
Демо-стенд із розпізнаванням жестів працює майже бездоганно: рівне світло, рука по центру кадру, спокійна поза оператора.
На пристрої користувача те саме збирання починає помилятися — керування жестами в застосунку розвалюється на першому ж реальному сценарії, хоча логіка не змінювалася ні на рядок.
Причини майже завжди лежать поза моделлю. Бюджетний модуль камери шумить за слабкого світла й «пливе» за кольором, а сенсор рівня Sony у тому самому приміщенні віддає помітно чистіший кадр — поріг упевненості, підібраний на одному пристрої, на іншому виявляється неправильним.
Швидкі помахи розмазуються в змащені кадри: зчитування рухів рук втрачає ключові точки, і класифікатор стрибає між сусідніми класами.
Окрема історія — антропометрія та фон. Різна довжина пальців, кут кисті, часткове перекриття обличчя, рукав куртки або сумка в кадрі зсувають геометрію жесту настільки, що відпрацьований на тестах шаблон не спрацьовує. Модель, навчена на постановочних даних, бачить у цьому не жест, а шум.
Далі вмикається ціна помилки. Хибні спрацьовування в інтерфейсі — це випадково надіслане повідомлення, скасоване замовлення, екран, що спрацював у кишені.
Користувач не розбирається, чия це вина: він просто перестає довіряти жестам і повертається до кнопок, а жестова навігація залишається мертвим кодом у релізі.
Розбираємо, як це закривається — від калібрування під парк пристроїв до захисних порогів і відкату до звичайного введення.
Що дає впровадження: швидкість відгуку, точність, менше відмов
Розпізнавання жестів перестає бути гарною демонстрацією, коли його прив’язують до метрик. Перше, що змінюється, — швидкість відгуку: обробка йде прямо на пристрої, без звернення до сервера, тому інтерфейс реагує в межах одного циклу оновлення, а не після мережевої відповіді.
На недорогих пристроях виграш помітніший за все — там, де раніше накопичувалися затримки й скарги на «залипання».
Точність зчитування поз налаштовується під конкретний сценарій: пороги спрацьовування й фільтрація брязкоту відсікають випадкові рухи, а еталонні пози ми беремо із записів реальних користувачів, а не з ідеальних умов студії. Жест спрацьовує з першого разу — повторювати рух не доводиться.
Зниження відмов інтерфейсу — наслідок того, що частина ручних дій зникає зі сценарію. Замість пошуку дрібної кнопки, гортання й введення користувач робить один рух: там, де було три-чотири кроки, залишається один. Рідше трапляються промахи по елементах — менше закинутих сценаріїв на середині.
Плавність анімації тримається на синхронізації: перехід запускається за підтвердженим жестом, а не за першим дотиком, тому немає ривків і подвійних спрацьовувань. Якщо рука виходить із кадру, інтерфейс повертається в початковий стан без стрибка.
Ефект вимірюваний: до й після знімаємо частку успішних розпізнавань, час до першої дії та кількість відмов на сценарій. Заміри робимо на пристроях реальної аудиторії, а не на тестовому стенді, — інакше цифри не збіжаться з тим, що бачить користувач.
Режими розпізнавання жестів: у застосунку, на сервері, гібрид
Схему вибирають за трьома вхідними: де фізично виконується модель, який відгук потрібен на дію і що відбувається при втраті мережі. Від цього залежать вимоги до парку пристроїв, обсяг кадрів, що передаються назовні, і те, як оновлюється модель після донавчання на нових жестах.
Три схеми виконання
Усі три конфігурації використовують один контракт обміну й однакову розмітку подій, тому перехід між ними не переписує застосунок цілком — змінюється лише шар, де виконується модель.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Розпізнавання на пристрої | Постійне жестове керування, чутливе до затримки; кадри не повинні залишати телефон | Модель входить у збірку — оновлення лише разом із релізом; на слабких і старих пристроях словник жестів доводиться урізати |
| Серверна схема | Багато класів жестів, важка модель, аналітика за потоком, різнорідний парк телефонів | Потрібні згоди на передачу кадрів і захищений канал; без мережі функція недоступна; відгук залежить від якості зв’язку |
| Гібридна схема | Базовий набір жестів потрібен офлайн, а точне розпізнавання — онлайн | Дорожче в розробці: два шари, синхронізація версій моделі, роздільне тестування обох шляхів |
На практиці частіше стартують із серверної схеми — вона швидше дає дані для уточнення словника жестів, а потім базовий набір переносять на пристрій. Гібрид беруть, коли робота без мережі обов’язкова: деградація тоді обмежується звуженням словника, а не вимкненням функції.
Етапи впровадження: від розбору задачі до передачі команді
Етапи впровадження розпізнавання жестів ідуть конвеєром: кожен наступний крок спирається на результат попереднього, тому пропуск будь-якого з них повертає команду назад. Нижче — як це виглядає від аудиту застосунку до передачі рішення вашій команді.
- Аудит застосунку. Розбираємо, на чому зібраний клієнт, які версії систем у підтримці, як влаштований доступ до камери й датчиків, які є обмеження щодо енергоспоживання. На виході — сценарії, де жести справді економлять дії користувача, і перелік обмежень.
- Схема жестів. Фіксуємо набір із кількох рухів і перевіряємо, що вони не конфліктують між собою та із системними жестами, не спрацьовують у побутових ситуаціях.
- Збирання даних і розмітка рухів. Записуємо еталонні приклади на різних людях, ракурсах і за різного освітлення; розмічений набір балансуємо за класами, щоб рідкісний жест не губився на тлі частого.
- Налаштування розпізнавання. Навчаємо й донавчаємо модель, підбираємо поріг спрацьовування та згладжування, щоб тремтіння руки не давало хибних подій; перевіряємо, чи вкладається обробка у відгук інтерфейсу і чи працює режим без мережі.
- Тестування моделі. Проганяємо відкладений набір і живі перевірки: частка хибних спрацьовувань і пропусків, затримка відгуку, поведінка за слабкого світла й у русі. Спірні випадки повертаються в розмічений набір.
- Пілот і передача команді. Вмикаємо функцію на частині аудиторії, дивимося журнали відмов, після чого віддаємо код, схему словника жестів, інструкцію щодо додавання нових рухів, набір тестів і метрики для спостереження в експлуатації.
Що передаємо на руки: моделі, схеми, регламенти, документація
Проєкт із розпізнавання жестів цінний не демо-роликом, а тим, що залишається в репозиторії та в знаннях команди після здачі. Нижче — перелік артефактів, які ми передаємо замовнику: кожен закриває свій клас задач, від перенавчання моделі до розбору інциденту на проді.
- Налаштована модель у вигляді, придатному для навчання: ваги, конфігурація передобробки кадрів, поріг упевненості, за якого жест вважається розпізнаним, і логіка відсікання випадкових спрацьовувань.
- Датасет із розміткою та правилами її поповнення: які жести у словнику, скільки прикладів потрібно на жест, як позначати пограничні та спірні кадри, щоб розмітники не розходилися.
- Схема інтеграції в застосунок: на якому кроці конвеєра обробки кадрів стоїть розпізнавання, як результат потрапляє в бізнес-логіку і що показуємо користувачу за низької впевненості.
- Метрики якості та спосіб їх заміру: частка правильних розпізнавань на відкладеній вибірці, частка хибних спрацьовувань, затримка відгуку на пристроях замовника й профіль типових помилок за жестами.
- Регламент оновлення: як збирати нові приклади з реальних сценаріїв, з якою періодичністю перенавчати, які перевірки обов’язкові перед випуском і як відкотитися на попередню модель.
- Контрольний набір кадрів і прогін за ним перед кожним релізом: розходження з еталоном вище порога блокує викладку.
- Інструкції для команди: як запустити навчання, як читати звіт про якість, куди дивитися при просіданні метрик і кому передавати проблему.
- Угоди про версіонування моделей і їхню сумісність із версіями застосунку.
Передаємо це не архівом, а розбором із командою: проходимо по кожному артефакту, показуємо, як його змінювати без нас, і фіксуємо, що залишається на супроводі.
Кейс: прибрали хибні спрацьовування в керуванні рухом
Кейс впровадження: застосунок для домашніх тренувань, де керування рухом у застосунку побудоване на жестах перед камерою телефона. На старті жест визначався за одним кадром — без урахування траєкторії та пози спокою. У тихій кімнаті це працювало, у залі з кількома людьми в кадрі логіка розсипалася.
Точність до і після
Частка хибних спрацьовувань трималася на 12–14%, а на зашумленому кадрі сягала третини: користувач втрачав контроль над екраном і кидав підхід. Розбір показав, що річ не в самій моделі, а в рішенні за одним кадром — випадковий рух руки важив стільки ж, скільки навмисний жест.
Рішення тепер ухвалюється за вікном кадрів, між командами перевіряється поза спокою, а поріг упевненості калібрується під конкретний пристрій і освітлення при першому запуску.
Розпізнавання винесли в окремий потік на MediaPipe, щоб воно не конкурувало з малюванням інтерфейсу, а повтор команди гаситься до завершення жесту.
Що стало
Хибні спрацьовування впали приблизно до 1%, відгук між жестом і реакцією скоротився в рази, а частка користувачів, які дійшли до мети без підказок, зросла з 62% до 93%. Звернення до підтримки на тему «не реагує або реагує не туди» скоротилися втричі.
Стару логіку залишили перемиканим налаштуванням: реліз відкочується без перезбирання, якщо на частині пристроїв нова калібрування поводиться інакше. Далі пороги уточнюються за телеметрією з реальних пристроїв — точність не деградує після оновлень.
Чим відрізняються статичні пози від динамічних траєкторій?
Статична поза — це знімок положення кисті або корпусу в одному кадрі. Класифікатор розпізнавання жестів дивиться на взаємне розташування опорних точок і вирішує, який жест показано прямо зараз.
Динамічна траєкторія — послідовність кадрів: важливі напрямок і порядок руху, а не лише підсумкове положення руки.
Для статики ознаки нормалізують за масштабом і поворотом, тому жест спрацьовує і поблизу камери, і на витягнутій руці. Словник тут невеликий: п’ять-сім поз уже конфліктують між собою, бо відрізняються парою кутів.
Динаміка живе в ковзному часовому вікні — жест виділяється за початком і кінцем руху, а ознаки рахуються за зміною положення в часі.
Звідси різні класи відмов. Статичні пози дають хибні спрацьовування, коли людина просто тримає руку в кадрі, — рятує поріг утримання в кілька кадрів.
Динамічні траєкторії пропускають жест, якщо користувач прискорився або розділив рух паузою, тому запис нормалізують за тривалістю й відсікають перехідні ділянки.
Вибір підходу диктує сценарій інтерфейсу. Для керування без дотику — пауза, відтворення, відповідь на дзвінок — достатньо статики: вона передбачувана й не потребує розмаху. Для перемикання розділів, малювання або швидких команд потрібна динаміка.
Робочий варіант часто гібридний: статична поза відкриває режим, траєкторія всередині нього виконує дію.
Перевіряємо рішення на еталонних записах: ті самі жести показують різні люди, за різного світла й з різної відстані. Рахуємо, скільки разів підхід помилився і на якій ділянці, — тоді вибір перестає бути смаковим і стає вимірюваним.
Світло, дальність, фон: технічні сумніви та відповіді
Сумніви замовників майже завжди про умови зйомки: тьмяне світло, контрове світло від вітрини, кілька людей у кадрі, рука на межі дальності. Це вирішується не «повзунком чутливості», а даними навчання й передобробкою кадру.
Що буде за слабкого освітлення й контрового світла?
Модель спирається на контраст між кистю та фоном, тому кадр вирівнюють за яскравістю до подання в мережу. За тьмяного світла рятує інфрачервоне підсвічування або глибинна камера, за контрового — маска руки за силуетом. Якщо сцени не вистачає фізично, скажемо до старту.
На якій відстані зчитується жест?
Упевнене зчитування — коли кисть займає помітну частину кадру: на витягнутій руці це один-два кроки до камери. Ширококутний об’єктив додає дальності, але підвищує чутливість до тремтіння. Поріг підбираємо під сценарій — турнікет, каса, вітрина.
Як впливає фон і чужі руки в кадрі?
Розпізнавання йде за ключовими точками кисті, а не за всім кадром, тому однотонний фон не потрібен. Щоб чужа рука не перехоплювала керування, задаємо зону інтересу й вибираємо найближчу руку за глибиною; у натовпі жест закріплюється за тим, хто його почав.
Чи можна навчити модель під наші жести?
Так: збираємо набір даних на ваших жестах і умовах — рукавички, одяг, ракурси, реальні приміщення. Донавчання йде на розмічених записах, якість міряємо часткою правильних спрацьовувань і хибних активацій. Обчислення йдуть на пристрої, відео його не залишає.
Обговоримо задачу: які дані потрібні для старту
Щоб оцінка проєкту була предметною, а не «на око», потрібен мінімум вхідних даних. Точність розпізнавання визначається не вибором моделі, а якістю записів і повнотою опису сценаріїв: де жест застосовується, що вважається помилкою, що відбувається при хибному спрацьовуванні.
Збирання цього списку зазвичай займає у замовника пару годин і знімає головний ризик — переробку розпізнавача після першого випуску.
- Цільові жести: які рухи розрізняємо, на яких екранах вони працюють і який відгук вважаємо правильним.
- Записи реальних рухів: по кілька прикладів на кожен жест — різні люди, освітлення, фон, відстань до камери.
- Парк пристроїв: моделі та версії системи, на яких застосунок має працювати, — камери й сенсори поводяться по-різному.
- Конфлікти із системними жестами: свайпи від краю екрана, виклики панелей, апаратні кнопки — де розпізнавач не повинен перехоплювати керування.
- Вимоги до відгуку: допустима затримка між рухом і реакцією інтерфейсу, поведінка за поганого світла й частково перекритої камери.
- Приватність: обробляємо відео на пристрої чи надсилаємо на сервери, що зберігаємо, що потрапляє в логи.
- Запасний сценарій: чим замінюємо жест, якщо розпізнавання не спрацювало або сцена не підходить за умовами.
- Те, що вже є: прототип, макети, логи попередніх спроб — навіть чернетки прискорюють розбір.
Надішліть те, що доступно, — решту пунктів уточнимо в розмові. Ми повернемося з оцінкою проєкту, планом робіт за етапами та переліком ризиків, які бачимо на вхідних даних. Обговоримо задачу по суті: опишіть сценарії та обмеження, далі наша частина.
