מדוע זיהוי מחוות נשבר במכשירים אמיתיים
עמדת הדגמה עם זיהוי מחוות עובדת כמעט ללא דופי: תאורה אחידה, יד במרכז הפריים, תנוחה רגועה של המפעיל. במכשיר של המשתמש אותה גרסה מתחילה לטעות — שליטה במחוות באפליקציה מתפרקת כבר בתרחיש אמיתי ראשון, אף שהלוגיקה לא השתנתה אף לא בשורה.
הסיבות כמעט תמיד נמצאות מחוץ למודל. מודול מצלמה תקציבי מרעיש באור חלש ו"שט" בצבע, וחיישן ברמה של Sony באותו חדר מפיק פריים נקי בהרבה — סף הביטחון, שנבחר במכשיר אחד, מתברר כלא נכון במכשיר אחר.
תנועות מהירות מטשטשות לפריימים מטושטשים: קריאת תנועות הידיים מאבדת נקודות מפתח, והמסווג מקפץ בין מחלקות שכנות.
סיפור נפרד — אנטרופומטריה ורקע. אורך אצבעות שונה, זווית כף היד, חפיפה חלקית של הפנים, שרוול מעיל או תיק בפריים מזיזים את הגיאומטריה של המחווה עד כדי כך שהתבנית המאומנת בבדיקות אינה פועלת. מודל שאומן על נתונים מבוימים רואה בזה לא מחווה, אלא רעש.
כאן נכנסת למשחק מחיר הטעות. הפעלות שגויות בממשק — זה הודעה שנשלחה בטעות, הזמנה שבוטלה, מסך שפועל בכיס. המשתמש לא מתעסק בשאלה של מי האשמה: הוא פשוט מפסיק לסמוך על מחוות וחוזר לכפתורים, וניווט במחוות נשאר קוד מת בגרסה.
אנחנו מפרקים איך זה נסגר — מכיול עבור מגוון מכשירים ועד ספי הגנה וחזרה לקלט רגיל.
מה נותן היישום: מהירות תגובה, דיוק, פחות כשלים
זיהוי מחוות מפסיק להיות הדגמה יפה כשמקשרים אותו למטריקות. הדבר הראשון שמשתנה — מהירות התגובה: העיבוד מתבצע ישירות במכשיר, בלי לפנות לשרת, ולכן הממשק מגיב בתוך מחזור עדכון אחד, ולא לאחר תגובת רשת. במכשירים זולים הרווח מורגש ביותר — שם, שבעבר הצטברו עיכובים ותלונות על "היתקעות".
דיוק קריאת התנוחות מכויל לתרחיש ספציפי: ספי הפעלה וסינון רעידות חוסמים תנועות אקראיות, ותנוחות ייחוס אנחנו לוקחים מהקלטות של משתמשים אמיתיים, ולא מתנאי אולפן אידיאליים. המחווה פועלת מהפעם הראשונה — אין צורך לחזור על התנועה.
צמצום הכשלים בממשק הוא תוצאה של כך שחלק מהפעולות הידניות יוצאות מהתרחיש. במקום לחפש כפתור קטן, לגלול ולהקליד, המשתמש עושה תנועה אחת: במקום שהיו שלושה-ארבעה צעדים, נשאר אחד. פחות פספוסים על אלמנטים — פחות תרחישים נטושים באמצע.
החלקות האנימציה נשענת על סנכרון: המעבר מופעל לפי מחווה מאושרת, ולא לפי נגיעה ראשונה, ולכן אין טלטלות והפעלות כפולות. אם היד יוצאת מהפריים, הממשק חוזר למצב ההתחלתי בלי קפיצה.
האפקט מדיד: לפני ואחרי אנחנו מודדים את שיעור הזיהויים המוצלחים, הזמן עד לפעולה הראשונה ומספר הכשלים לתרחיש. המדידות נעשות במכשירים של קהל אמיתי, ולא בעמדת בדיקה — אחרת המספרים לא יתאימו למה שהמשתמש רואה.
מצבי זיהוי מחוות: באפליקציה, בשרת, היברידי
את הסכמה בוחרים לפי שלושה משתנים: היכן פיזית מבוצע המודל, איזו תגובה נדרשת לפעולה ומה קורה באובדן רשת. מזה תלויות הדרישות למגוון המכשירים, נפח הפריימים המועברים החוצה והאופן שבו המודל מתעדכן לאחר אימון נוסף על מחוות חדשות.
שלוש סכמות ביצוע
כל שלוש הקונפיגורציות משתמשות בחוזה החלפה אחד ובסימון אירועים זהה, ולכן מעבר ביניהן לא מחייב לכתוב את האפליקציה מחדש — משתנה רק השכבה שבה מבוצע המודל.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| זיהוי במכשיר | שליטה קבועה במחוות, רגישה לעיכוב; פריימים לא צריכים לעזוב את הטלפון | המודל נכלל בגרסה — עדכון רק יחד עם מהדורה; במכשירים חלשים וישנים יש לקצץ את מילון המחוות |
| סכמת שרת | מחלקות מחוות רבות, מודל כבד, אנליטיקה לפי זרימה, מגוון טלפונים הטרוגני | דרושים הסכמים להעברת פריימים וערוץ מאובטח; ללא רשת הפונקציה אינה זמינה; התגובה תלויה באיכות הקישור |
| סכמה היברידית | סט מחוות בסיסי דרוש באופן לא מקוון, וזיהוי מדויק — באופן מקוון | יקר יותר בפיתוח: שתי שכבות, סנכרון גרסאות מודל, בדיקה נפרדת של שני המסלולים |
בפועל, לעתים קרובות מתחילים מסכמת שרת — היא מספקת מהר יותר נתונים לעידון מילון המחוות, ואחר כך מעבירים את הסט הבסיסי למכשיר. סכמה היברידית נלקחת כאשר עבודה ללא רשת הכרחית: אז ההידרדרות מוגבלת לצמצום המילון, ולא לניתוק הפונקציה.
שלבי יישום: מניתוח המשימה ועד מסירה לצוות
שלבי היישום של זיהוי מחוות מתנהלים כפס ייצור: כל שלב הבא נשען על התוצאה של הקודם, ולכן דילוג על כל אחד מהם מחזיר את הצוות אחורה. להלן — איך זה נראה מהביקורת של האפליקציה ועד מסירת הפתרון לצוות שלכם.
- ביקורת האפליקציה. מפרקים על מה בנוי הלקוח, אילו גרסאות מערכת נתמכות, איך בנויה הגישה למצלמה ולחיישנים, אילו מגבלות צריכת אנרגיה קיימות. בפלט — תרחישים שבהם מחוות באמת חוסכות פעולות למשתמש, ורשימת מגבלות.
- סכמת מחוות. קובעים סט של מספר תנועות ובודקים שהן לא מתנגשות ביניהן ובין מחוות מערכת, לא פועלות במצבי יומיום.
- איסוף נתונים וסימון תנועות. מקליטים דוגמאות ייחוס על אנשים שונים, מזוויות שונות ובתאורה שונה; את הסט המסומן מאזנים לפי מחלקות, כדי שמחווה נדירה לא תאבד על רקע נפוצה.
- כיול הזיהוי. מאמנים ומבצעים אימון נוסף למודל, בוחרים סף הפעלה והחלקה, כדי שרעידת יד לא תיצור אירועים שגויים; בודקים אם העיבוד נכנס במסגרת תגובת הממשק ואם מצב ללא רשת עובד.
- בדיקת המודל. מריצים מדגם שנשמר בצד ובדיקות חיות: שיעור הפעלות שגויות והחמצות, השהיית תגובה, התנהגות באור חלש ובתנועה. מקרים שנויים במחלוקת מוחזרים לסט המסומן.
- פיילוט ומסירה לצוות. מפעילים את הפונקציה על חלק מהקהל, בוחנים יומני כשלים, ולאחר מכן מוסרים קוד, סכמת מילון מחוות, הוראות להוספת תנועות חדשות, סט בדיקות ומטריקות למעקב בתפעול.
מה מוסרים לידיים: מודלים, סכמות, נהלים, תיעוד
פרויקט לזיהוי מחוות חשוב לא בגלל סרטון הדגמה, אלא בגלל מה שנשאר במאגר ובמידע של הצוות לאחר המסירה. להלן — רשימת ארטיפקטים שאנחנו מוסרים ללקוח: כל אחד מכסה סוג משלו של משימות, מאימון מחדש של המודל ועד לניתוח תקרית בפרודקשן.
- מודל מכויל בצורה ניתנת לאימון: משקלים, קונפיגורציית עיבוד מקדים של פריימים, סף ביטחון שבו מחווה נחשבת לזוהה, ולוגיקת חיתוך הפעלות אקראיות.
- מערך נתונים עם סימון וכללים להשלמתו: אילו מחוות במילון, כמה דוגמאות נדרשות למחווה, איך לסמן פריימים גבוליים ושנויים במחלוקת, כדי שמסמנים לא יחלקו ביניהם.
- סכמת אינטגרציה באפליקציה: באיזה שלב של צינור עיבוד הפריימים עומד הזיהוי, איך התוצאה עוברת ללוגיקה העסקית ומה מציגים למשתמש בביטחון נמוך.
- מדדי איכות ואופן מדידתם: שיעור הזיהויים הנכונים על מדגם שנשמר, שיעור הפעלות שגויות, השהיית תגובה במכשירי הלקוח ופרופיל שגיאות אופייניות לפי מחוות.
- נוהל עדכון: איך לאסוף דוגמאות חדשות מתרחישים אמיתיים, באיזו תדירות לבצע אימון מחדש, אילו בדיקות חובה לפני שחרור ואיך לחזור למודל הקודם.
- סט בקרה של פריימים והרצה עליו לפני כל מהדורה: סטייה מהתקן מעל הסף חוסמת את ההעלאה.
- הוראות לצוות: איך להפעיל אימון, איך לקרוא דוח איכות, לאן להסתכל בירידת מדדים ולמי להעביר את הבעיה.
- הסכמים לגבי גרסאות מודלים ותאימותם לגרסאות האפליקציה.
אנחנו מוסרים זאת לא כארכיון, אלא כניתוח עם הצוות: עוברים על כל ארטיפקט, מראים איך לשנות אותו בלעדינו, ומתעדים מה נשאר לתמיכה.
מקרה בוחן: הסרנו הפעלות שגויות בשליטה בתנועה
מקרה יישום: אפליקציה לאימוני בית, שבה השליטה בתנועה באפליקציה מבוססת על מחוות מול מצלמת הטלפון. בהתחלה המחווה זוהתה לפי פריים אחד — בלי להתחשב במסלול ובתנוחת מנוחה. בחדר שקט זה עבד, בחדר כושר עם כמה אנשים בפריים הלוגיקה התפרקה.
דיוק לפני ואחרי
שיעור ההפעלות השגויות החזיק מעמד על 12–14%, ובפריים רועש הגיע עד לשליש: המשתמש איבד שליטה על המסך והפסיק את הסט. הניתוח הראה שהבעיה לא במודל עצמו, אלא בהחלטה לפי פריים אחד — תנועת יד אקראית שקלה כמו מחווה מכוונת.
ההחלטה מתקבלת כעת לפי חלון של פריימים, בין פקודות נבדקת תנוחת מנוחה, וסף הביטחון מכויל למכשיר ולתאורה הספציפיים בהפעלה הראשונה. את הזיהוי העבירו לתהליכון נפרד על MediaPipe, כדי שלא יתחרה בציור הממשק, וחזרה על פקודה נחסמת עד לסיום המחווה.
מה השתנה
ההפעלות השגויות ירדו לכדי 1%, התגובה בין המחווה לתגובה הצטמצמה פי כמה, ושיעור המשתמשים שהגיעו ליעד ללא רמזים עלה מ-62% ל-93%. פניות לתמיכה בנושא "לא מגיב או מגיב לא נכון" פחתו פי שלושה.
את הלוגיקה הישנה השאירו כהגדרה ניתנת להחלפה: המהדורה מתבטלת בלי בנייה מחדש, אם בחלק מהמכשירים הכיול החדש מתנהג אחרת. בהמשך הספים מעודכנים לפי טלמטריה ממכשירים אמיתיים — הדיוק לא נסוג לאחר עדכונים.
במה נבדלות תנוחות סטטיות ממסלולים דינמיים?
תנוחה סטטית — זה צילום של מיקום כף היד או הגוף בפריים אחד. מסווג זיהוי המחוות מסתכל על המיקום ההדדי של נקודות עוגן ומחליט איזו מחווה מוצגת כעת. מסלול דינמי — רצף פריימים: חשובים הכיוון וסדר התנועה, ולא רק מיקום היד הסופי.
עבור סטטיקה המאפיינים מנורמלים לפי קנה מידה וסיבוב, ולכן המחווה פועלת גם מקרוב למצלמה וגם על יד מושטת. המילון כאן קטן: חמש-שבע תנוחות כבר מתנגשות ביניהן, כי הן נבדלות בכמה זוויות.
דינמיקה חיה בחלון זמן מחליק — המחווה מזוהה לפי התחלה וסוף התנועה, והמאפיינים מחושבים לפי שינוי המיקום בזמן.
מכאן סוגים שונים של כשלים. תנוחות סטטיות נותנות הפעלות שגויות כשאדם סתם מחזיק יד בפריים — מציל סף החזקה של כמה פריימים. מסלולים דינמיים מפספסים מחווה אם המשתמש האיץ או פיצל את התנועה בהפסקה, ולכן ההקלטה מנורמלת לפי משך וחותכים קטעי מעבר.
הבחירה בגישה מוכתבת על ידי תרחיש הממשק. לשליטה ללא נגיעה — השהיה, הפעלה, מענה לשיחה — די בסטטיקה: היא צפויה ואינה דורשת תנופה. למעבר בין מקטעים, ציור או פקודות מהירות דרושה דינמיקה. הגרסה העובדת היא לעתים קרובות היברידית: תנוחה סטטית פותחת מצב, ומסלול בתוכו מבצע את הפעולה.
בודקים את הפתרון על הקלטות ייחוס: אותן מחוות מציגים אנשים שונים, בתאורה שונה וממרחק שונה. סופרים כמה פעמים הגישה טעתה ובאיזה קטע — אז הבחירה מפסיקה להיות עניין של טעם והופכת למדידה.
תאורה, מרחק, רקע: ספקות טכניות ותשובות
ספקות של לקוחות כמעט תמיד עוסקים בתנאי הצילום: אור עמום, אור נגדי מחלון ראווה, כמה אנשים בפריים, יד בגבול הטווח. זה לא נפתר ב"סליידר רגישות", אלא בנתוני אימון ועיבוד מקדים של הפריים.
מה יקרה בתאורה חלשה ובאור נגדי?
המודל נשען על ניגודיות בין כף היד לרקע, ולכן הפריים מיושר לפי בהירות לפני העברה לרשת. בתאורה עמומה עוזרת תאורת אינפרא אדום או מצלמת עומק, באור נגדי — מסכת יד לפי צללית. אם הסצנה לא מספיקה פיזית, נגיד זאת לפני ההתחלה.
מאיזה מרחק נקראת המחווה?
קריאה בטוחה — כאשר כף היד תופסת חלק ניכר מהפריים: על יד מושטת זה צעד-שניים למצלמה. עדשה רחבת זווית מוסיפה טווח, אך מגבירה רגישות לרעידות. את הסף בוחרים לפי התרחיש — שער כניסה, קופה, חלון ראווה.
איך משפיעים רקע וידיים זרות בפריים?
הזיהוי מתבצע לפי נקודות מפתח של כף היד, ולא לפי כל הפריים, ולכן רקע אחיד אינו נחוץ. כדי שיד זרה לא תשתלט על השליטה, מגדירים אזור עניין ובוחרים את היד הקרובה ביותר לפי עומק; בקהל המחווה משויכת למי שהתחיל אותה.
האם אפשר לאמן את המודל למחוות שלנו?
כן: אוספים מערך נתונים על המחוות והתנאים שלכם — כפפות, לבוש, זוויות, חדרים אמיתיים. אימון נוסף מתבצע על הקלטות מסומנות, האיכות נמדדת לפי שיעור הפעלות נכונות והפעלות שגויות. החישוב מתבצע במכשיר, הווידאו לא עוזב אותו.
נדון במשימה: אילו נתונים דרושים להתחלה
כדי שהערכת הפרויקט תהיה עניינית, ולא "בעין", דרושים מינימום נתוני קלט. דיוק הזיהוי נקבע לא לפי בחירת המודל, אלא לפי איכות ההקלטות ושלמות תיאור התרחישים: היכן המחווה מיושמת, מה נחשב לטעות, מה קורה בהפעלה שגויה.
איסוף הרשימה הזו בדרך כלל אורך אצל הלקוח כמה שעות ומסיר את הסיכון העיקרי — עיבוד מחדש של המזהה לאחר המהדורה הראשונה.
- מחוות מטרה: אילו תנועות אנחנו מבדילים, באילו מסכים הן פועלות ואיזו תגובה נחשבת לנכונה.
- הקלטות של תנועות אמת: כמה דוגמאות לכל מחווה — אנשים שונים, תאורה, רקע, מרחק למצלמה.
- מגוון מכשירים: דגמים וגרסאות מערכת שעליהם האפליקציה צריכה לעבוד — מצלמות וחיישנים מתנהגים אחרת.
- התנגשויות עם מחוות מערכת: החלקות משולי המסך, קריאות לפאנלים, כפתורים פיזיים — היכן המזהה לא צריך להשתלט על השליטה.
- דרישות לתגובה: השהיה מותרת בין תנועה לתגובת הממשק, התנהגות בתאורה גרועה ובמצלמה חסומה חלקית.
- פרטיות: האם מעבדים וידאו במכשיר או שולחים לשרתים, מה נשמר, מה נכנס ליומנים.
- תרחיש גיבוי: במה מחליפים את המחווה אם הזיהוי לא עבד או שהסצנה לא מתאימה לתנאים.
- מה שכבר קיים: אב טיפוס, פריסות, יומנים של ניסיונות קודמים — אפילו טיוטות מאיצות את הניתוח.
שלחו את מה שזמין — את הסעיפים הנותרים נבהיר בשיחה. נחזור עם הערכת הפרויקט, תוכנית עבודה לפי שלבים ורשימת סיכונים שאנחנו רואים בנתוני הקלט. נדון במשימה לגופו של עניין: תארו תרחישים ומגבלות, והלאה החלק שלנו.