הטמעת זיהוי תנוחות באפליקציה לנייד

זיהוי תנוחות באפליקציה לנייד: היכן אובד הדיוק

זיהוי תנוחות באפליקציה לנייד הוא צינור עיבוד בן שלוש חוליות: פריים מהמצלמה, המודל, והשלד על המסך. הדיוק אובד לא במודל עצמו, אלא במפרקים — בין הפריים לחישוב, בין פריים לפריים, בין ציפיות המוצר לתקציב הזמן במכשיר. המדד על סט הבדיקה נשמר, אבל ביד של המשתמש השלד רועד ונסחף.

שגיאות בהערכת תנוחה נראות לרוב כרעידה של נקודות העוגן. המודל מפרש כל פריים בנפרד, ולכן הרעש של הגלאי בכפות הידיים, בכפות הרגליים ובאזורי חפיפה לא נבלם אלא עובר לקואורדינטות.

בלי ייצוב זמני — מעקב אחר נקודה בין פריימים, החלקה, חיזוי על פריים שהוחמץ — זווית הכיפוף מחושבת עם פיזור, וספירת החזרות מתחילה לשקר.

הכשל השני הוא אי-התאמה בזמן בין זרם הווידאו למודל. התור של הפריימים גדל, החישוב מתבצע על פריים מיושן, והסימון מצויר מעל הפריים הנוכחי: השלד מגיע באיחור ו"שוחה" לצד הגוף. עבור ספירת חזרות אלו שלבים אבודים של התנועה. הפתרון הוא השלכה של פריימים מיושנים לפי חותמת זמן והפרדה בין זרם המצלמה לזרם החישוב.

השלישי הוא התקציב של מכשיר חלש. המכשיר לא עומד בזרם, מתחמם ומוריד תדר, ואז האפליקציה או מדלגת על פריימים או מחליפה סוג מודל תוך כדי ריצה. אנחנו מחשבים מראש כמה זמן נשאר לכל פריים, וקובעים דעיכה צפויה: חישוב בתדירות נמוכה יותר, אינטרפולציה בין תנוחות, והתנהגות כנה של הממשק. נפרט כיצד זה נסגר בפועל.

אפקט מדיד: מה משתנה במוצר לאחר ההטמעה

האפקט הראשון נראה לעין — השהיית התגובה. כל עוד סימון השלד רץ על פריים מלא, בין תנועת האדם לתגובת הממשק הצטבר תור של כמה פריימים: המשתמש פיגר אחרי ההנחיה, ואת התרגיל היה צריך להתחיל מחדש.

לאחר העברת הענף הראשי למודל קל לפי נקודות מפתח, השהיית התגובה הצטמצמה לפריים-שניים — הממשק מגיב כמעט ברגע התנועה, גם כשהאדם מאיץ.

עמידות לאובדן פריים היא המדד שעליו אב-טיפוס בדרך כלל מתפרק. בעבר פריים אחד מטושטש או חסום איפס את ההיסטוריה, וספירת החזרות נסחפה. כעת התנוחה משוחזרת לפי חלון זמני: החמצה לא מאפסת את המסלול, ושיעור הפריימים האבודים בתנועות מהירות יורד מיחידות אחוזים לעשיריות האחוז.

המדידות ב-MLPerf Mobile וההרצות שלנו על אנשים אמיתיים מתלכדות: ענפים קלים שומרים על דיוק במקום שבו הכבדים כבר לא עומדים בקצב התנועה.

הכיסוי של מכשירים חלשים מתרחב לא "לפי העין" אלא לפי תקציב החישוב. המשאב שהתפנה מופנה להחלקת השלד ולבדיקת סבירות אנטומית — זיהוי תנוחות באפליקציה לנייד עובד על מכשירים שבעבר הוצאנו מהתמיכה, ואינו דורש בנייה נפרדת לכל דגם.

העיקר הוא הפחתת סוג התקלות: נעלמת הקטגוריה ההמונית של פניות "לא מזהה אותי".

פריימים עם דמות חלקית, תאורה צדית או אדם שנכנס לפריים באופן חלקי כבר לא מפיקים שגיאה: השלד מושלם לפי הנקודות הנראות עם הערכת מהימנות, ותנוחה שנויה במחלוקת מסומנת ברכות — בהצעה לתקן את המצב, ולא בהודעת תקלה.

מצבי הפעולה של המודל: במכשיר, בענן, היברידי

שלושת המסלולים נבדלים לא ב"איכות המודל" אלא במקום שבו מחושבות נקודות המפתח של השלד, ובאופן שבו הרשת, הסוללה והפרטיות מתנהגות בהתאם. קובעים את המצב לפני תחילת הפיתוח: ממנו תלויים הארכיטקטורה של האפליקציה, דרישות המכשירים ורשימת התרחישים שבכלל יש טעם להבטיח.

היברידי אינו אפשרות "בינונית" אלא תוכנית ניתנת להחלפה. אנחנו מניחים סט אחיד של מחלקות ועיבוד-בדיעבד משותף, כדי שבמעבר מהענן למכשיר הנקודות לא "יקפצו". ההחלפה עצמה נקבעת לפי תנאים: זמינות הערוץ, רמת הטעינה, סוג התרגיל.

את המגבלות בודקים על סט פיילוט של מכשירים אמיתיים: שיעור הפריימים שפוענחו ללא השהיה, ההתנהגות בערוץ חלש, העמידות לגוף חסום חלקית. לפי המדידות האלה בוחרים מסלול ומקבעים אותו בתיעוד הטכני יחד עם ההתנהגות בזמן דעיכה — מה רואה המשתמש אם הפענוח אינו זמין.

שלבי ההטמעה: מביקורת נתונים ועד מסירת המסלול

סדר השלבים כאן חשוב יותר מהקצב: אם מתחילים מהמודל ולא מהנתונים, העבודה חוזרת לסימון מחדש, והקבלה הופכת לוויכוח על מספרים. אנחנו מנהלים את הפרויקט כך שכל שלב יתבסס על תוצאה שכבר אושרה בשלב הקודם.

1. ביקורת נתונים. בוחנים כיצד המשתמשים מצלמים בפועל: זוויות, תאורה, חפיפות, אורך הסשנים. התוצר הוא רשימת תרחישים שהפתרון חייב לטפל בהם, והערכה של היקף הסימון.

2. הכנת הסימון. מסמנים נקודות מפתח של השלד וקובעים כללים לפריימים שנויים במחלוקת — גפיים חסומות, יציאה של האדם מגבולות הפריים. משווים בין המסמנים, אחרת המודל לומד מסתירות.

3. תכנון המסלול. מחליטים מה מחושב במכשיר ומה בשרת, כיצד האפליקציה מתנהגת בלי רשת וכיצד מעדכנים את המודל בלי להוציא גרסה חדשה.

4. כיול המודל. מאמנים מחדש על הקורפוס שלנו, בודקים בנפרד תנוחות נדירות וזוויות קיצוניות, ומוודאים שהדיוק לא יורד במכשירים חלשים.

5. אופטימיזציה. מודדים התחממות, צריכת סוללה והשהיית תגובה במכשירים אמיתיים: דיוק שבגללו הטלפון מתחמם לא נכנס למוצר.

6. בדיקת קבלה. מריצים סט מוסכם של תרחישים ומדדים, בודקים תאורה גרועה וניתוק רשת. סטייה מהסף מחזירה לשלב המתאים, ולא "תיקון לפי העין".

7. מסירת המסלול. מוסרים קוד אינטגרציה, תרשים המסלול, סקריפטים של סימון ואימון, תיעוד לעדכון המודל וצ'ק-ליסט לאבחון, ומכשירים את צוות הלקוח.

הרכב המסירה: תצורות מודל, תרשימי זרימה, נהלים

אנחנו מוסרים לא אב-טיפוס הדגמתי אלא מסירה עובדת, שצוות התחזוקה חי איתה בלעדינו. כל חפץ תוכנה משויך לתרחיש שלו: אימון על נתונים חדשים, פריסת עדכון, חזרה לאחור, חקירת תקלה במכשיר של הלקוח. להלן מה שנשאר פיזית אצלכם במאגר הקוד ובבסיס הידע לאחר המסירה.

• תצורות מודל: משקולות, ספי מהימנות לנקודות מפתח, הגדרות רזולוציית קלט לפריים. לכל פרמטר יש הערה מה הוא משנה ועל איזה מדד הוא משפיע: שיעור התראות שווא, עמידות לגוף חסום חלקית, עבודה בתאורה חלשה.
• תרשימי זרימת נתונים: מקליטת הפריים ועד השלד בפלט. מסומן היכן יושב חוצץ, היכן פריימים נזרקים כשחסר זמן לעיבוד, מה קורה כשירידה בתדירות הצילום, וכיצד התור מתנהג תחת עומס.
• מדיניות גישה: אילו מודולים של האפליקציה פונים למודל, מה יוצא לחלק השרת ומה מחושב במכשיר. בנפרד — כללים לעבודה עם זרם הווידאו של המשתמש: היכן הוא נשמר, במה הוא מוסווה, ומתי הוא נמחק.
• נוהל עדכון המודל: מחזור מלא — סימון הקלטות חדשות, אימון מחדש, בדיקה על סט ייחוס, פריסה הדרגתית לחלק מהמשתמשים. עם קריטריוני חזרה לאחור: אם מדד היעד ירד, הגרסה הקודמת חוזרת בפקודה אחת.
• סט ייחוס לרגרסיה: הקלטות עם תוצאה מסומנת מראש, שעליהן מריצים כל בנייה חדשה. מאפשר לתפוס דעיכה לפני שחרור, ולא לפי תלונות בתמיכה.
• פרופילים לפי מחלקות מכשירים: היכן המודל מחשב פריימים בזמן אמת, היכן הוא עובר לגרסה מוקלת, והיכן הלוגיקה דועכת לניתוח פריימים בודדים במקום זרם.
• תיעוד תחזוקה: מפת מודולים, נקודות הרחבה לסוגי תנועה חדשים, רשימת מגבלות ידועות והוראות למהנדס תורן — מה לבדוק קודם כול כשהמדדים סוטים מהציפיות.

מקרה הטמעה: מדדים לפני ואחרי בעומס אמיתי

מקרה ההטמעה — אפליקציית מאמן לאימונים בבית: מצלמת הטלפון עוקבת אחר התנוחה, והמערכת מייעצת אם התרגיל מבוצע נכון. בנקודת ההתחלה שיעור התנוחות הנכונות על סט הבדיקה עמד על כ-68%, וזמן התגובה לשינוי מצב היה כחצי שנייה. בתנועות מהירות השלד "רעד", סקוואט נספר ככישלון, ומשתמשים נטשו את האימון באמצע.

מה שינינו במודל ובעיבוד

בנינו מחדש את הסימון לתנאי צילום אמיתיים — תאורה שונה, לבוש, פריים חלקי — ואימנו מחדש את המודל עם קוונטיזציה למאיץ נייד, כדי שהאינפרנס יחושב במכשיר עצמו, בלי פנייה לשרת.

הוספנו החלקה של נקודות המפתח לאורך רצף פריימים וספי מהימנות נפרדים לתרגילים סטטיים ולתרגילים דינמיים: השלד הפסיק "להתפרע", והמערכת למדה להבחין בין הפסקה בין חזרות לבין תנועה שהושלמה.

מדדים לפני ואחרי

שיעור התנוחות הנכונות על אותו סט עלה מ-68% ל-94%, וזמן התגובה הצטמצם לעשיריות השנייה. את המדידות השווינו לסימוני הייחוס של הסט הפתוח COCO, ולכן המספרים בני-השוואה בין שחרורים ואינם תלויים במי שהריץ את הבדיקה.

תופעת לוואי — שיעור האימונים שהושלמו עד הסוף עלה מ-41% ל-73%. לא סופרים "לפי העין": מדגם קבוע, הרצה על שלוש מחלקות מכשירים, דוח עם התפלגות שגיאות לפי סוגי תרגילים ובדיקת רגרסיה בכל שחרור — בעדכון הבא המדדים לא יירדו בלי ששמים לב.

האם צריך סימון משלכם אם מודל מוכן כבר עובד?

מודל מוכן כמו MediaPipe מאומן על נתונים המוניים: אדם בגובה מלא, מצלמה בגובה החזה, לבוש רגיל, אדם אחד בפריים. כל עוד התרחיש שלכם נכנס להתפלגות הזו, כיוונון נוסף כמעט לא מוסיף דבר — נקודות המפתח יציבות, ושבועות של סימון אינם נדרשים.

כיוונון נוסף סוגר את ההטיה, אבל אינו משנה את מהות המשימה. אם התנועות שלכם הן וריאציה של משימה כללית (אותו אדם, אותה הקרנה, לבוש או זווית אחרים), די לכוונן את המודל על כמה מאות פריימים מסומנים ולעקוב אחרי האיכות דווקא על התנועות שלכם, ולא בבדיקה כללית.

סימון משלכם הופך לחובה כשמשתנה מושא התצפית או המדד עצמו. ציוד בידיים, מנח כף היד באחיזה, קצב ותנועת המשרעת — מודל מוכן אינו מבחין בהבדלים כאלה: משתנה היעד שלו הוא "היכן המפרק", ואתם צריכים "האם התרגיל בוצע נכון". צריך לסמן לפי המשימה שלכם.

עלות שמירת האיכות אינה מחושבת חד-פעמית. סימון תנוחות הוא עשרות נקודות לפריים, עקביות בין המסמנים, שיעור בדיקה חוזרת, סט בדיקות רגרסיה למקרים שכבר נסגרו, וכיוונון חוזר על נתונים חדשים. בלי צינור העיבוד הזה האיכות על התנועות שלכם יורדת בכל שינוי של הסצנה.

הכלל המעשי פשוט: קודם מריצים את המודל המוכן על ההקלטה שלכם ומחלקים את השגיאות לשיטתיות ולאקראיות. את השיטתיות מרפא כיוונון נוסף, את האקראיות ואת התנועות "הלא נכונות" — רק סט מסומן משלכם. בפיילוט קצר רואים זאת בתוך ימים ספורים, וההחלטה נשענת על מדד ולא על ציפייה.

ספקות טכניים: דיוק, פרטיות, תקלות

הספקות לפני ההתחלה הם כמעט תמיד אותם ספקות: האם המודל יעמוד בתאורה גרועה, האם הווידאו ידלוף, מה יקרה לסוללה בסשן ארוך ומי אחראי לאיכות אחרי ההשקה. מהתשובות תלוי מה אנחנו מחשבים במכשיר ומה יוצא לשרת.

הווידאו יוצא לשרת?

הפריימים מעובדים במכשיר ואינם יוצאים החוצה — מועברות רק קואורדינטות של נקודות או מדדים מצטברים. עיבוד בשרת מופעל נקודתית, בהסכמת המשתמש ועם הצפנת הערוץ.

כמה זמן מחזיקה הסוללה?

החישובים אינם מתבצעים על כל פריים: הזרם מדולל, למודל מוזן פריים מוקטן, ובין סטים המצלמה נכבית. התחממות וצריכה נמדדות על מכשירים אמיתיים מהסדרה המיועדת.

מי אחראי לאיכות אחרי ההשקה?

הדיוק לא יורד מעצמו, אלא משינוי תנאים — אתר חדש, לבוש אחר, עדכון מערכת. לכן המסירה כוללת סט הקלטות בקרה ומדד שלפיו רואים את הירידה לפני תלונות המשתמשים.

נדון במשימה: אילו נתונים והרשאות נדרשים להתחלה

כדי לחזור עם הערכת עבודה ותוכנית הטמעה, די לנו במינימום של נתוני קלט — את השאר נבהיר תוך כדי. ככל שהתרחיש מתואר מדויק יותר, כך יש פחות הנחות באומדן וכך מוקדם יותר רואים את צווארי הבקבוק: למשל שחלק מהתנוחות אינן ניתנות להבחנה בתאורה חלשה, או שהתנועה מהירה מדי לעיבוד בזמן אמת.

• תרחיש: אילו תנועות ותנוחות מזהים, כמה אנשים בו-זמנית בפריים, מה קורה בשגיאה — הנחיה, הפסקה, חזרה על התרגיל.
• פלטפורמות יעד וגרסאות מערכת הפעלה מינימליות, רשימת דגמי מכשירים שהאפליקציה חייבת לעבוד עליהם ביציבות.
• מקור הווידאו: מצלמה בזמן אמת, הקלטה מהגלריה או זרם חיצוני. אם החישוב מתבצע במכשיר (למשל על MediaPipe), הווידאו לא עוזב את הטלפון — זה מסיר חלק מהשאלות בנוגע לפרטיות.
• רפרנסים: אפליקציות דומות, דוגמאות וידאו עם תנועות וניתוח מה בהן מוצא חן ומה לא מתאים לתרחיש שלכם.
• הרשאות גישה: מאגר קוד, חשבונות של חנויות אפליקציות, בניות בדיקה ומאגר מכשירים לבדיקה על חומרה אמיתית.
• מגבלות: דרישות לאחסון וידאו, עבודה בלי רשת, צריכת סוללה והתחממות המארז בסשן ממושך.
• לוחות זמנים ושלביוּת: האם יש תאריך קשיח, האם נדרש פיילוט על קבוצת משתמשים מוגבלת לפני השחרור.

שלחו את מה שכבר קיים — חלק מהסעיפים יכולים להישאר פתוחים, ואת ההערכה ותוכנית ההטמעה נבנה לפי השאר. תארו את המשימה בצורה חופשית: נחזור עם פירוט לפי שלבים, לוחות זמנים ורשימה של מה שנבדוק באב-הטיפוס הראשון.