מערכת בינה מלאכותית לזיהוי סביבה עבור מציאות רבודה (הבנת סצנה)

Scene Understanding AR: היכן נשבר זיהוי הסביבה

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

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

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

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

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

מה נותן זיהוי סצנה יציב באפליקציות AR

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

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

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

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

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

שיטות לזיהוי הסביבה: השוואת גישות

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

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

איך אנחנו מיישמים זיהוי סצנה: שלבי העבודה

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

1. ניתוח המשימה ותרחישי היעד. אנחנו מגדירים מה בדיוק מזהים — מישורים, מידות החלל, עצמים בודדים, תאורה — באילו מכשירים זה יעבוד ובאיזו תאורה. קריטריוני הקבלה נרשמים בכתב לפני תחילת העבודה.
2. ביקורת נתונים. אוספים הקלטות של סשנים אמיתיים מהמכשירים המיועדים, מתייגים פריימי ייחוס ובודקים התאמה בין המתייגים. כאן גם מזהים חוסר בדוגמאות בזוויות נדירות ובתאורה חלשה.
3. אב-טיפוס על סט קטן. בודקים את המקום המסוכן ביותר — בדרך כלל יציבות העיגון של אובייקטים וירטואליים לסצנה נעה. משווים חלופות לפי שיעור התראות שווא והשהיית תגובה.
4. כיוונון לנתוני הלקוח. מאמנים את המודל מחדש על הסט שנאסף, מכווננים ספי הפעלה, מוסיפים סינון רעידות וייצוב מיקום העצמים בין פריימים.
5. בדיקה בתרחישים אמיתיים. מריצים את המערכת באתר: משנים תאורה, מוסיפים הסתרות ותנועת אנשים. בודקים היכן הדיוק יורד וחוזרים לכיוונון.
6. קבלת המערכת. ריצה חוזרת לפי קריטריונים מוסכמים עם דוח: מדדים לכל תרחיש, רשימת מגבלות ידועות וניתוח מקרים שנויים במחלוקת.
7. העברה לצוות. תיעוד לתיוג נתונים חדשים, נוהל אימון מחדש ונוהל ברור לחזרה לאחור אם עדכון הרע את התוצאה.

תרשימים, תצורות ונוהלי תחזוקה

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

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

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

מקרה בוחן: זיהוי הסביבה באפליקציית ניווט

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

מה היה

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

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

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

מה השתנה

שיעור הסשנים שנשברו ירד מ-28% ל-7%, הכניסה למצב עבודה — מ-12 ל-3 שניות, ושיעור העיגונים התקינים עלה ל-96%. אורך הסשן הממוצע כמעט הוכפל: אנשים התחילו להגיע לסוף המסלול, ולא לנטוש את הניווט באמצע.

במה זיהוי סצנה שונה ממעקב מישור?

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

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

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

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

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

שאלות טכניות נפוצות על זיהוי הסביבה

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

האם נדרש רכיב ענן?

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

אפשר לחבר למודול שכבר פרוס?

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

איך בודקים יציבות?

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

מה קורה אחרי ההשקה?

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

בואו נדון במשימת זיהוי סצנה

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

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

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