זיהוי מחוות: היכן הפיילוט נשבר ומדוע
אב הטיפוס לזיהוי מחוות כמעט תמיד עובד בהדגמה: יד אחת בפריים, תאורה אחידה, המפעיל חוזר על המחווה לפי התסריט. בעומס עבודה אמיתי התמונה שונה — כמה אנשים בשדה הראייה, חפיפות, קנה מידה שונה של כף היד, שינויי תאורה במהלך היום.
דיוק הזיהוי בעמדת ההדגמה ובזרימה האמיתית נבדלים פי כמה, ובדיוק כאן הפיילוט נעצר: המחווה לפעמים מזוהה ולפעמים לא, והמפעיל מפסיק לסמוך על ממשק המחוות.
נפרק היכן בדיוק נשבר המעבר מאב טיפוס לפרודקשן. נקודת הכשל הראשונה — נתונים: המודל אומן על הקלטות של אדם אחד וחדר אחד, ולכן על אנשים וזוויות חדשים הוא טועה באופן צפוי.
השנייה — תיוג: מחוות הדומות במסלול כף היד אך שונות במשמעות מתויגות כמחלקה אחת, והמסווג פיזית אינו יכול להבדיל ביניהן. השלישית — השהיה: מודל כבד על חומרה חלשה מגיב לאט יותר ממה שאדם מזיז את ידו, והממשק "צף".
הנקודה הרביעית — התנהגות בגבול: כאשר היד יוצאת מהפריים, נחסמת או שהאדם פשוט נח, המערכת צריכה לשתוק ולא להפיק מחווה אקראית. החמישית — היעדר משוב: המשתמש אינו מבין אם המחווה זוהתה או לא, וחוזר על התנועה, ובכך accumulates הפעלות שגויות.
השישית — היעדר מדדים: בלי לוגים של אירועים ושיעור הפעלות נכונות אי אפשר להבין אם נעשה טוב יותר לאחר השיפור.
אב הטיפוס למחוות עונה על השאלה "האם אפשר לזהות זאת". הפרודקשן עונה על שאלה אחרת — "האם זה עובד ביציבות על אנשים חיים כל יום". ביניהם נמצאים איסוף ותיוג של נתונים אמיתיים, כיול ספי הפעלה, בקרת השהיה ואינדיקציה ברורה למשתמש. להלן נפרק כיצד זה נסגר מבחינה הנדסית.
מה נותנת זיהוי מחוות תעשייתי
מערכת תעשייתית נבדלת מדמו לא בדיוק ממוצע על סט בדיקה, אלא בהתנהגות בפריים הגרוע ביותר: אור נגדי מהחלון, רקע ססגוני של מחסן, יד בכפפה, כמה אנשים בפריים בו-זמנית.
לכן את המדד מחשבים לא "באופן כללי", אלא לפי חתכים — בנפרד לפי תנאי תאורה, לפי סוגי מחוות ולפי שיעור ההתראות השווא על רקע שבו אין מחוות כלל.
עמידות לאור ולרקע נותנת שילוב: נרמול הפריים לפני הזנה למודל, אימון על סט מורחב עם תאורה שהושחתה באופן מלאכותי וחתיכת אזורים לפי עומק או לפי מעקב כף היד.
כתוצאה מכך זיהוי מחוות לא מתפרק בעת החלפת שעות היום וסידור מחדש של הציוד, וסף הביטחון מכוון בהתאם למשימה — במקום מסוים חשוב יותר לא להחמיץ מחווה, במקום אחר לא לתפוס אחת מיותרת.
השהיית התגובה מפסיקה "לנוע": את הצינור בונים כך שהעיבוד יתבצע בזרימה, עם תקציב קבוע לפריים, ושלבים כבדים לא יחסמו את הפלט. בפועל אלו 60–100 מ"ש יציבים מהמחווה ועד לתגובת הממשק — מספיק כדי שהשליטה תרגיש מיידית ולא מושהית.
התראות שווא מפחיתים בשלוש שיטות: אישור זמני (המחווה צריכה להחזיק מעמד כמה פריימים), הצמדה מרחבית לאזור האינטראקציה ומסווג נפרד ל"תנועות דומות אך לא מטרתיות". שיעור ההתראות השווא יורד מעשרות למשמרת ליחידות, והמפעיל מפסיק להיאבק במערכת.
מודלים מרכיבים על MediaPipe ומאמנים לתרחיש הספציפי — מחוות, זוויות צילום ורקע של הלקוח, ולא סט מופשט. בהמשך — מדידה על הנתונים שלכם: מצלמים הקלטות ייחוס, מחשבים דיוק לפי חתכים ורק לאחר מכן קובעים את הספים.
גישות לזיהוי מחוות ומגבלותיהן
הבחירה בשיטת זיהוי מחוות נקבעת לא על פי "אופנתיות" המודל, אלא על פי תנאי הצילום: רקע, תאורה, מספר מצלמות, השהיית תגובה מותרת. להלן — אפשרויות עבודה שממש בוחרים ביניהן בתחילת הפרויקט, והגבולות של תחולת השימוש בהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מעקב קלאסי אחר כף היד לפי נקודות מפתח | מצלמה אחת, זווית חזיתית, מחוות ידיים בפריים קרוב | מאבד את כף היד בחפיפת אצבעות, בתנועה מהירה, בניגודיות נמוכה מול הרקע |
| מודל שלד על זרם וידאו | נדרשות מחוות דינמיות ומסלול תנועה | רגיש לזווית, דורש כיול לסצנה |
| סיווג לפי עומק (חיישן עומק) | תאורה לקויה, רקע מורכב, מספר ידיים | תלות בחיישן ספציפי, הגבלה לפי מרחק |
| היברידי: מעקב + מסווג רשת נוירונים | פרודקשן עם זרם משתמשים ותנאים שונים | מורכב יותר לתחזוקה, נדרש איסוף נתונים לסצנת הלקוח |
ההבדל מתגלה למרחק ארוך: שיטות זיהוי שמספקות דיוק בהדגמה, לעיתים קרובות מדרדרות בעת שינוי תאורה או זווית. לכן אנחנו מקצים מרווח בנתונים ובתרחישים כבר בשלב האב-טיפוס, ולא לאחר ההשקה.
השאלה המרכזית — לא איזו שיטה לבחור, אלא כיצד לקשר את מעקב כף היד עם הלוגיקה של האפליקציה: היכן מסתיים זיהוי המחווה ומתחילה תגובת הממשק. שגיאות בגבול הזה מייצרות הפעלות שגויות לעיתים קרובות יותר מהמודל עצמו.
איך אנחנו מנהלים פרויקט זיהוי מחוות
העבודה על מערכת זיהוי מחוות מתחילה לא בבחירת מודל, אלא בתיעוד איזו מחווה נחשבת נכונה ובאילו תנאים היא מזוהה. לכן השלב הראשון הוא איסוף דרישות: רשימת מחוות, השהיית תגובה מותרת, תרחישי שימוש, מגבלות תאורה וזווית מצלמה. התוצר — מילון מחוות מוסכם וקריטריוני קבלה שלפיהם נבדקת כל איטרציה בהמשך.
שלבי הפרויקט
- הגדרת המשימה ומילון המחוות. מתעדים את רשימת המחוות, את ההבדלים החזותיים ביניהן ואת הזוגות המתנגשים (למשל תנוחות אצבעות דומות). קובעים דיוק יעד וזיהויים שגויים מותרים.
- איסוף ותיוג נתונים. מצלמים וידאו מזוויות ותנאי תאורה אמיתיים, ומתייגים פריימים. בנפרד מכינים דוגמאות "קשות": ידיים מוסתרות חלקית, תנועה, סוגי עור ולבוש שונים.
- אב טיפוס על MediaPipe. בונים אב טיפוס מהיר על מודלים מוכנים למעקב אחר ידיים, כדי להעריך אם הדיוק מספיק ללא אימון רשת משלנו. זו דרך זולה לסנן דרישות לא ריאליות לפני השקעה בתיוג.
- אימון ואימון מחדש של המודל. אם אב הטיפוס אינו מספיק, מאמנים מסווג על הנתונים שנאספו, בוחרים ארכיטקטורה וספי ביטחון. בודקים את המודל על סט נתונים נפרד, ולא על הפריימים ששימשו באימון.
- בדיקת המודל. מריצים את המערכת על הקלטות שהמודל לא ראה: אנשים אחרים, תאורה אחרת, מצלמה אחרת. מחשבים דיוק לכל מחווה בנפרד — מדד ממוצע מסתיר כשלים במחלקות בודדות.
- אינטגרציה ואופטימיזציה. משתילים את המודל באפליקציית היעד, מגדירים עיבוד זרימה של פריימים והתנהגות בעת אובדן מעקב. משיגים תגובה יציבה ללא ירידות בביצועים בעבודה ממושכת.
- מסירת המערכת ללקוח. מוסרים קוד, משקולות מודל, הוראות פריסה ואימון מחדש על נתונים חדשים. מעבירים הדרכה לצוות וקובעים נוהל לעדכון מילון המחוות.
כל שלב מסתיים בארטיפקט שניתן לבדוק: מילון מחוות, מערך נתונים מתויג, דוח דיוק, אב טיפוס עובד. זה מאפשר לעצור את הפרויקט בשלב מוקדם אם הדרישות אינן מתיישבות עם המציאות, ולא לבזבז משאבים על פתרון חלש מראש.
ארטיפקטים והגדרות שנשארים אצל הלקוח
אנחנו מעבירים לא "קבצי מקור על הדיסק", אלא מערכת עובדת עם התנהגות משוכפלת. להלן מה שנשאר פיזית אצל הלקוח לאחר הפעלת זיהוי מחוות: תצורות, תרשימים, נהלים ותיעוד, שלפיהם ניתן לפתח את המערכת בלעדינו.
- תצורת המודל — משקולות הרשת המאומנת, היפר-פרמטרים של אינפרנס, ספי ביטחון לכל מחווה ומילון מחלקות. עם סט זה, אימון מחדש על מחוות חדשות משוכפל אחד לאחד, ולא "כמו שיצא בפעם הקודמת".
- תרשימי אינטגרציה — דיאגרמות זרימה מהמצלמה ועד לצרכן האירוע: היכן מתבצע לכידת פריימים, היכן האינפרנס, היכן הבאפרינג וכיצד התוצאה עוברת למערכת שלכם. עם נקודות כשל מפורשות והתנהגות בעת אובדן פריימים.
- תיעוד המערכת — תיאור הארכיטקטורה, פורמטים של נתוני קלט ופלט, דרישות לחומרה ולרשת, הוראות להרצה מקומית של סטנד לניפוי באגים.
- נהלי תפעול — סדר עדכון המודל, כללי חזרה לגרסה קודמת, בקרת סחיפת דיוק בזיהוי מחוות ותדירות כיול מחדש לתאורה חדשה או לסידור מצלמות חדש.
- סט תרחישי בדיקה — רצפי וידאו ייחוס עם תיוג, שעליהם נבדק שאחרי כל שינוי הדיוק לא ירד.
- סקריפטים לפריסה — התקנה אוטומטית על סביבת היעד ובנייה חוזרת, כך שהסטנד עולה באופן זהה אצלכם ואצלנו.
- מטריצת הרשאות ותפקידים — מי יכול לשנות ספים, מי לעדכן את המודל, מי רק לצפות במטריקות; עם יומן שינויים.
כל ארטיפקט ניתן לאימות: אנחנו מריצים פריסה בצד שלכם ומוודאים שהצוות משכפל את התוצאה לפי התיעוד ללא רמזים מאיתנו. אם משהו נשאר רק בהתכתבות — זו לא העברה, אלא תלות בקבלן.
מקרה בוחן: זיהוי מחוות בקו ייצור
מפעיל בקו שלט במסוע גלילים מהשלט הרחוק: כדי להזין את חלק העבודה, היה עליו להסיר את הידיים מהחלק, לאתר את הכפתור הנכון ולחזור לעמדה. בהחלפות אבדו שניות, וכפפות המגן גרמו לכפתורים להגיב לסירוגין — המפעיל לחץ חזק יותר, השלט הרחוק נשחק, והקו נעצר לעצירות לא מתוכננות.
את הפיילוט הרכיבו על מצלמה מעל עמדת העבודה ועל מודל לזיהוי מחוות. הגרסה הראשונה על סטנד בדיקה הניבה כ-70% הפעלות נכונות: הפריעו הבזקים מתאורת המפעל ומחוות דומות של "עצור" ו"הזן".
אוסף הנתונים נבנה מחדש לתנאי המפעל האמיתיים, נוספה זווית צילום שנייה, ומערך הפקודות הוגבל לשש מחוות חד-משמעיות.
MediaPipe בשלב האב-טיפוס איפשר לבדוק במהירות את ההשערה על הקלטות מהקו, אך לייצור הועבר האינפרנס למודול חישוב מקומי לצד המצלמה — הפריימים אינם יוצאים לרשת חיצונית, והתגובה אינה תלויה בערוץ התקשורת.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור המחוות שזוהו | ~70% בסטנד | 96-98% במשמרת |
| השהיית תגובה | 400-600 מ"ש בשלט הרחוק | עד 150 מ"ש |
| הפעלות שגויות | 1 ל-8-10 פקודות | 1 ל-200+ פקודות |
| עצירת הקו בהחלפות | עצירות קבועות | מקרים בודדים |
שליטה במחוות סגרה את התרחיש המרכזי — הזנה ועצירה בלי להסיר את הידיים מהחלק. ההפעלות השגויות נעלמו הודות לסף הביטחון: הפקודה מבוצעת רק כשהמחווה מוחזקת באופן יציב, ולא לפי פריים בודד. החזרה לשלט הרחוק נשארה כמצב גיבוי — המפעיל עובר אליו בלחיצת כפתור אחת, אם המצלמה התלכלכה או זזה.
מקרה הבוחן של הזיהוי הראה את העיקר: מדדי ההטמעה נקבעים לא על ידי המודל, אלא על ידי תנאי הצילום ומשמעת איסוף הנתונים עבור קו ייצור מסוים.
במה שונה זיהוי מחוות ממעקב אחר ידיים?
מעקב אחר ידיים עונה על השאלה "היכן היד ואיך ממוקמות האצבעות", זיהוי מחוות — "מה האדם רוצה לומר בכך". הראשון מספק גיאומטריה: קואורדינטות של כף היד והמפרקים בפריים, תנוחת כף היד, וקטור התנועה.
השני הופך את הגיאומטריה הזו לתווית בדידה — "עצור", "אוקיי", "הצבע", "החלקה". אלו משימות שונות עם מחיר שגיאה שונה, וערבוב ביניהן הוא הסיבה הנפוצה ביותר לכך שאב-טיפוס עובד בהדגמה ומתפרק בשטח.
מעקב הוא זרם רציף של קואורדינטות, שמתעדכן בכל פריים. הוא לא יודע על משמעות: יד בפריים — זו כבר תוצאה. סיווג מחוות פועל מעליו ופותר משימת זיהוי תבניות: לוקח רצף תנוחות בחלון זמן ומקצה לו מחלקה.
מכאן ההבדל המרכזי בדרישות — למעקב חשובים יציבות ותדירות עדכון הקואורדינטות, ולמסווג חשובים תיוג ועמידות לשונות: אותה מחווה אנשים שונים מציגים באופן שונה, עם אמפליטודה ומהירות שונות.
בפועל אלו שתי שכבות של אותו צינור עיבוד. התחתונה — מעקב אחר ידיים: היא מספקת קואורדינטות מנורמלות, אינוואריאנטיות למיקום האדם בפריים ולקנה מידה. העליונה — סיווג: לפי חלון זמן של תנוחות ומסלולים קובעת את המחווה ומסננת התראות שווא.
אם מסירים את השכבה התחתונה, את המסווג יהיה צריך ללמד על פיקסלים גולמיים — זה פי כמה יותר נתונים ופחות עובר היטב לסצנה, תאורה ומצלמה חדשות. אם מסירים את העליונה, נקבל ויזואליזציה יפה של שלד, אבל לא קלט מחוות שאפשר לקשור לפעולה בממשק.
ההבדל בין הגישות בא לידי ביטוי גם במטריקות. עבור מעקב מחשבים את שיעור הפריימים עם כף יד שזוהתה נכון ואת יציבות הקואורדינטות — רעידות בגבולות ובחפיפה של אצבעות. עבור סיווג — דיוק לפי מחלקות, recall ומטריצת בלבול: אילו מחוות המערכת מבלבלת ביניהן.
המחווה "הצבע" ו"החלקה" נבדלות לא בתנוחה אלא בדינמיקה, ולכן למסווג דרוש חלון זמן, ולא פריים בודד. מכאן גם הדיבאג השונה: מעקב מתקנים ברמת המצלמה, התאורה והעיבוד המקדים, סיווג — ברמת התיוג, איזון המחלקות וספי הביטחון.
עבור הלקוח זה מצטמצם לשאלה אחת: מה צריך לקרות ביציאה של המערכת. אם נדרשת ויזואליזציה של מיקום הידיים או שליטה בסמן לפי קואורדינטות — די במעקב אחר ידיים.
אם נדרש קלט מחוות כפקודה — "אשר", "בטל", "החלף" — בלי שכבת סיווג מחוות אי אפשר להסתדר, והיא בדיוק זו שקובעת את הדיוק ואת הצפיות של המוצר.
ספקות טכניים נפוצים בזיהוי מחוות
זיהוי מחוות נשבר לא על המודל, אלא על נתוני הקלט: שינוי תאורה, זווית היד, הרקע, סינכרוניות הזרמים ממספר מצלמות. לכן השאלה הראשונה לקבלן היא לא "איזה פריימוורק", אלא "איך אתם מודדים דיוק מחוות בתרחיש שלנו".
המדד חייב להיות מחושב על החומר שלכם: שיעור המחוות שזוהו נכון, שיעור ההפעלות שהוחמצו, ההשהיה בין המחווה לתגובת המערכת. בלי זה, השיחה על דיוק נשארת תיאורטית.
עד כמה הדיוק יורד בתאורה לקויה ומה עושים עם זה?
הדעיכה תלויה בשאלה אם אנחנו עובדים עם זרם RGB או עם עומק. בתאורת נגד ובשעת בין הערביים קווי המתאר של היד מיטשטשים, והמודל מתחיל לבלבל בין מחוות קרובות.
זה לא נפתר ב"שיפור המודל", אלא בהכנת הקלט: תאורת אינפרא-אדום, מסנן פולריזציה, כיול חשיפה בהתאם לסצנה, ובמידת האפשר — מעבר למצלמת עומק. אנחנו מצלמים מראש סט בדיקה בתנאים האמיתיים שלכם וקובעים באיזו תאורה הדיוק נשאר סביר.
אילו מצלמות יתאימו והאם אפשר להסתפק באלה שכבר מותקנות?
לעתים קרובות כן — אם למצלמות הקיימות יש זרם יציב וחשיפה צפויה. עבור מחוות קריטיים קצב הפריימים והיעדר דחיסה חזקה: ארטיפקטים של קודק אוכלים את המוטוריקה העדינה של האצבעות. אנחנו בודקים את המצלמות שלכם על סטנד בדיקה ואומרים ישירות היכן יצבור המצאי הנוכחי, והיכן נדרשת החלפה. זה מסיר את הסיכון לקנות ציוד שלא פותר את המשימה.
איך זיהוי מחוות משתלב במוצר שלנו?
האינטגרציה מתבצעת דרך ממשק שירות: המוצר שלכם שולח זרם או פריימים ומקבל אירועים עם המחווה שזוהתה ורמת הביטחון. לוגיקת התגובה נשארת בצד שלכם — אנחנו לא תופרים חוקי עסק לתוך המודל. קונטור כזה שורד החלפת מודל ואינו דורש לכתוב מחדש את המוצר בעדכון הבא.
מה אם הדיוק בתרחיש שלנו יתגלה כנמוך מהצפוי?
אנחנו קובעים מדדי יעד לפני ההתחלה ובודקים אותם על החומר שלכם, ולא על סטים ציבוריים. אם הסף לא מושג, יש מנופים ברורים: אימון נוסף על הנתונים שלכם, החלפת חיישן, צמצום סט המחוות לאלה שזוהות באופן יציב. אתם רואים איזה מהם נותן תוצאה, ומחליטים אם להמשיך או לעצור.
בואו נדון במשימת זיהוי מחוות
כדי שהשיחה תהיה עניינית ולא "ספרו על המשימה במילים כלליות", די בארבע נקודות פתיחה: אילו מחוות ובאיזו כמות מזהים, על איזה ציוד המערכת עובדת (מצלמה, עומק, חיישנים אינפרא-אדומים), באיזה מצב — אופליין על המכשיר או דרך שרת, ומה קורה כאשר זיהוי נכשל. זה מספיק כדי להעריך את הפרויקט ולהרכיב תוכנית עבודה, בלי להיכנס לאב-טיפוס מוקדם מדי.
בהמשך אנחנו מקבעים את המסגרת וחוזרים עם הערכה ותוכנית. מה יידרש מכם להתחלה:
- הקלטות וידאו או זרם חי מתנאי צילום אמיתיים — תאורה, רקע, זווית, מהירות המחוות.
- רשימת מחוות עם תיאור, אילו מהן קריטיות ואילו ניתן לזהות בדיוק נמוך יותר.
- תרחיש שימוש בממשק מחוות: מי ובאיזה רגע מבצע מחווה, ומה המערכת צריכה לעשות בתגובה.
- דרישות לזמן השהיה של התגובה — כמה מהר הממשק חייב להגיב למחווה.
- מגבלות על הציוד והסביבה: היכן ממוקמת המצלמה, האם יש אנשים זרים בפריים, האם התאורה משתנה.
- שיעור שגיאות מותר ומה לעשות כאשר מחווה לא זוהתה — להתעלם, לשאול שוב או לבטל את הפעולה.
- נקודות אינטגרציה: עם איזו מערכת מחברים את הזיהוי ובאיזה ערוץ מעבירים את התוצאה.
לפי נקודות פתיחה אלה אנחנו מעריכים את היקף תיוג הנתונים, את מורכבות המודל ואת לוחות הזמנים. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.







