Система розпізнавання жестів: від MediaPipe до продакшену

Розпізнавання жестів: де ламається пілот і чому

Прототип розпізнавання жестів майже завжди працює на демо: одна рука в кадрі, рівне світло, оператор повторює жест за сценарієм. У робочому навантаженні картина інша — кілька людей у зоні видимості, перекриття, різний масштаб долоні, зміна освітлення протягом дня.

Точність розпізнавання на демо-стенді та на реальному потоці розходяться в рази, і саме тут пілот зупиняється: жест то спрацьовує, то ні, а оператор перестає довіряти жестовому інтерфейсу.

Розберемо, де саме ламається перехід від прототипу до продакшену. Перша точка відмови — дані: модель навчали на записах однієї людини й одного приміщення, тому на нових людях і ракурсах вона помиляється передбачувано.

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

Четверта точка — поведінка на межі: коли рука виходить із кадру, перекривається або людина просто відпочиває, система має мовчати, а не видавати випадковий жест.

П'ята — відсутність зворотного зв'язку: користувач не розуміє, розпізнано жест чи ні, і повторює рух, накопичуючи хибні спрацювання. Шоста — відсутність метрик: без логування подій і частки вірних спрацювань неможливо зрозуміти, чи стало краще після доопрацювання.

Прототип жестів відповідає на питання «чи можна це розпізнати». Продакшен відповідає на інше питання — «чи працює це стабільно на живих людях щодня».

Між ними лежить збір і розмітка реальних даних, калібрування порогів спрацювання, контроль затримки та зрозуміла індикація для користувача. Нижче розбираємо, як це закривається інженерно.

Що дає промислове розпізнавання жестів

Промислова система відрізняється від демо не середньою точністю на тестовому наборі, а поведінкою на найгіршому кадрі: контрове світло з вікна, строкатий фон складу, рука в рукавичці, кілька людей у кадрі одночасно.

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

Стійкість до світла та фону дає зв'язка: нормалізація кадру перед подачею в модель, навчання на розширеному наборі зі штучно зіпсованим освітленням і відсікання областей за глибиною або за трекінгом кисті.

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

Затримка відгуку перестає «плавати»: конвеєр будуємо так, щоб обробка йшла потоково, з фіксованим бюджетом на кадр, а важкі етапи не блокували вивід.

На практиці це стабільні 60–100 мс від жесту до реакції інтерфейсу — достатньо, щоб керування відчувалося миттєвим, а не запізнілим.

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

Частка хибних спрацювань падає з десятків за зміну до одиниць, і оператор перестає боротися із системою.

Моделі збираємо на MediaPipe і навчаємо під конкретний сценарій — жести, ракурси та фон замовника, а не абстрактний набір. Далі — замір на ваших даних: знімаємо еталонні записи, вважаємо точність за зрізами і тільки після цього фіксуємо пороги.

Підходи до розпізнавання жестів та їх обмеження

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

Різниця проявляється на довгій дистанції: методи розпізнавання, що дають точність на демо, часто деградують при зміні освітлення чи ракурсу. Тому ми закладаємо запас за даними та сценаріями вже на етапі прототипу, а не після запуску.

Ключове питання — не який метод обрати, а як пов'язати трекінг кисті з логікою застосунку: де закінчується розпізнавання жесту й починається реакція інтерфейсу. Помилки на цій межі дають хибні спрацювання частіше, ніж сама модель.

Як ми ведемо проєкт розпізнавання жестів

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

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

Етапи проєкту

1. Постановка задачі та словник жестів. Фіксуємо список жестів, їхні візуальні відмінності та конфліктні пари (наприклад, схожі положення пальців). Визначаємо цільову точність і допустимі хибні спрацювання.
2. Збір і розмітка даних. Записуємо відео з реальних ракурсів і умов освітлення, розмічаємо кадри. Окремо готуємо «складні» приклади: частково перекриті руки, рух, різні типи шкіри та одягу.
3. Прототип на MediaPipe. Збираємо швидкий прототип на готових моделях трекінгу рук, щоб оцінити, чи вистачає точності без навчання власної мережі. Це дешевий спосіб відсіяти нереалістичні вимоги до вкладень у розмітку.
4. Навчання та донавчання моделі. Якщо прототипу недостатньо, навчаємо класифікатор на зібраних даних, підбираємо архітектуру та пороги впевненості. Перевіряємо модель на відкладеній вибірці, а не на тих кадрах, що використовувалися під час навчання.
5. Перевірка моделі. Проганяємо систему на записах, яких модель не бачила: інші люди, інше освітлення, інша камера. Рахуємо точність за кожним жестом окремо — середній показник приховує провали на окремих класах.
6. Інтеграція та оптимізація. Вбудовуємо модель у цільовий застосунок, налаштовуємо потокову обробку кадрів і поведінку при втраті трекінгу. Досягаємо стабільного відгуку без просідань при тривалій роботі.
7. Передача системи замовнику. Передаємо код, ваги моделі, інструкцію з розгортання та донавчання на нових даних. Проводимо навчання команди та фіксуємо порядок оновлення словника жестів.

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

Артефакти та налаштування, які залишаються у замовника

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

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

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

Кейс: розпізнавання жестів на виробничій лінії

Оператор на лінії керував рольгангом з пульта: щоб подати заготовку, потрібно було зняти руки з деталі, знайти потрібну кнопку й повернутися до позиції.

На перемиканнях втрачалися секунди, а на захисних рукавичках кнопки спрацьовували через раз — оператор тиснув сильніше, пульт зношувався, лінія зупинялася на незаплановані простої.

Пілот зібрали на камері над робочим місцем і моделі розпізнавання жестів. Перша версія на тестовому стенді давала близько 70% вірних спрацьовувань: заважали відблиски від цехового освітлення та схожі жести «стоп» і «подати».

Перезібрали датасет під реальні умови цеху, додали другий ракурс і обмежили набір команд шістьма однозначними жестами.

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

Метрики до і після

Жестове керування закрило головний сценарій — подачу й зупинку без відриву рук від деталі. Хибні спрацьовування пішли за рахунок порогу впевненості: команда виконується лише за стійкого утримання жесту, а не за одиночним кадром.

Відкат до пульта залишився як резервний режим — оператор перемикається на нього однією кнопкою, якщо камера забруднилася або змістилася.

Кейс розпізнавання показав головне: метрики впровадження вирішуються не моделлю, а умовами зйомки та дисципліною набору даних під конкретну виробничу лінію.

Чим відрізняється розпізнавання жестів від трекінгу рук?

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

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

Трекінг — це безперервний потік координат, який оновлюється на кожному кадрі. Він не знає про сенс: рука в кадрі — вже результат. Класифікація жестів працює поверх нього і розв'язує задачу розпізнавання образів: бере послідовність поз за вікно часу і присвоює їй клас.

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

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

Якщо прибрати нижній шар, класифікатор доведеться вчити на сирих пікселях — це кратно більше даних і гірше переноситься на нову сцену, освітлення і камеру.

Якщо прибрати верхній, отримаємо гарну візуалізацію скелета, але не жестовий ввід, який можна прив'язати до дії в інтерфейсі.

Різниця підходів проявляється і в метриках. Для трекінгу рахуємо частку кадрів з коректно знайденою кистю і стабільність координат — тремтіння на межах і при перекритті пальцями.

Для класифікації — точність за класами, повноту і матрицю помилок: які жести система плутає між собою. Жест «вказати» і «свайп» розрізняються не позою, а динамікою, тому класифікатору потрібне часове вікно, а не окремий кадр.

Звідси й різне налагодження: трекінг лагодять на рівні камери, світла і передобробки, класифікацію — на рівні розмітки, балансу класів і порогів впевненості.

Для замовника це зводиться до одного питання: що має відбутися на виході системи. Якщо потрібна візуалізація положення рук або керування курсором за координатами — достатньо трекінгу рук.

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

Часті технічні сумніви щодо розпізнавання жестів

Розпізнавання жестів ламається не на моделі, а на вхідних даних: зміна освітлення, ракурс кисті, фон, синхронність потоків з кількох камер. Тому перше питання до підрядника — не «який фреймворк», а «як ви вимірюєте точність жестів на нашому сценарії».

Метрика має рахуватися на вашому матеріалі: частка правильно розпізнаних жестів, частка пропущених спрацювань, затримка між жестом і реакцією системи. Без цього розмова про точність залишається теоретичною.

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

Часто можна — якщо у наявних камер стабільний потік і передбачувана експозиція. Для жестів критичні частота кадрів і відсутність сильного стиснення: артефакти кодека з'їдають дрібну моторику пальців.

Ми перевіряємо ваші камери на тестовому стенді й говоримо прямо, де вистачить поточного парку, а де потрібна заміна. Це знімає ризик купити обладнання, яке не вирішує задачу.

Як розпізнавання жестів вбудовується в наш продукт?

Інтеграція йде через сервісний інтерфейс: ваш продукт надсилає потік або кадри й отримує події з розпізнаним жестом і рівнем впевненості. Логіка реакції залишається на вашій стороні — ми не зашиваємо бізнес-правила в модель. Такий контур переживає заміну моделі й не вимагає переписувати продукт при наступному оновленні.

Що якщо точність на нашому сценарії виявиться нижчою за очікувану?

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

Обговоримо задачу розпізнавання жестів

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

Далі ми фіксуємо рамки і повертаємося з оцінкою та планом. Що знадобиться від вас для старту:

• Відеозаписи або живий потік з реальних умов зйомки — світло, фон, ракурс, швидкість жестів.
• Список жестів з описом, які з них критичні, а які можна розпізнавати з меншою точністю.
• Сценарій використання жестового інтерфейсу: хто і в який момент подає жест, що система має зробити у відповідь.
• Вимоги до затримки реакції — наскільки швидко інтерфейс зобов'язаний відгукуватися на жест.
• Обмеження щодо обладнання та середовища: де стоїть камера, чи є сторонні в кадрі, чи змінюється освітлення.
• Допустима частка помилок і що робити, коли жест не розпізнано — ігнорувати, перепитати чи відкотити дію.
• Точки інтеграції: з якою системою пов'язуємо розпізнавання і яким каналом передаємо результат.

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