הטיסה השישית של המסוק הרובוטי Ingenuity בשמי מאדים, ב-22 במאי השנה, כמעט הסתיימה באסון כשההליקופטר הזעיר החל להתנדנד הלוך-ושוב בזוויות מסוכנות. ניתוח התקלה יכול להיות רלוונטי לפיתוח מערכות אמבדד באופן כללי.
אנחנו חיים בתקופה מטורפת כל כך, שאפילו חדשות מדהימות כמו מסוק רובוטי שטס בכוכב הלכת מאדים הולכות לאיבוד בין הכותרות. בטיסה הראשונה עוד היה מספיק חידוש כדי שידברו עליה קצת – תצליח? לא תצליח? ובמיוחד אחרי הדרמה-זוטא של ה-Watchdog timer שמנע את ההמראה בניסיון הראשון. אבל מה שמענו בתקשורת מאז על שש הטיסות הנוספות [נכון ל-12 ביוני]?
ובכן, מסתבר שבטיסה השישית קרה משהו חדש וחריג, שלפחות למראית עין יכול היה להביא לקיצו-בטרם-עת של הרובוט הקטן. בגובה עשרה מטרים מעל הקרקע, אחרי שכבר התקדם מאה וחמישים מטרים במהירות אופקית של כארבעה מטרים לשנייה, המסוק התחיל להתנדנד פתאום הלוך-ושוב, עד כדי עשרים מעלות מהאנך. כיוון שתוכנית הטיסה נקבעת מראש ואי אפשר לבצע שינויים בזמן אמת, התנועה הבלתי-נשלטת נמשכה עוד 65 מטרים, עד שהמסוק הגיע ליעדו (בפספוס של כחמישה מטרים), נחת בהצלחה והתחיל לשדר את הטלמטריה והתמונות המפלילות למפעיליו.
לפי הכתבה הזו באתר נאס"א, הייצוב הדינמי של המסוק באטמוספרה הדלילה של מאדים מבוסס בעיקר על חיישני IMU (דומה, מן הסתם, לחיישנים איתם אנחנו עובדים בארדואינו), ולולאת בקרה שמבצעת קריאות ותיקונים 500 פעמים בשנייה. פרט ל-IMU, המערכת נעזרת גם בתמונות שמגיעות שלושים פעמים בשנייה ממצלמה שמכוונת כלפי מטה.
בעכברי המחשב האופטיים שלנו יש גם כן מצלמה קטנה. המיקרו-בקר שבהם מזהה תוואים בתמונה, רואה לאן הם "זזו" בתמונה הבאה שמגיעה, ולפי זה מבין לאיזה כיוון ומרחק המשתמש הזיז את העכבר. ב-Ingenuity קורה משהו דומה, רק משוכלל יותר, כי לא משתמש חיצוני מניע את הרובוט אלא הוא עצמו. המחשב מנבא, לפי מה שהוא יודע על מצב המערכת הנוכחי, לאן "יזוזו" התוואים בתמונה הבאה שתגיע. עם כל פריים חדש הוא משווה את הניבוי שלו לשינויים הנצפים בפועל, ועל ידי כך בודק את עצמו ומתקן סטיות שה-IMU פספסה מכל סיבה שהיא. כדי שהטריק הזה יעבוד, המחשב חייב לדעת בדיוק מתי כל תמונה צולמה, ואכן באיזשהו שלב בין מודול המצלמה לקוד העיבוד מתווספת לכל צילום חתימת זמן.
זוהי הנקודה שבה התחיל כל הבלגן. מסיבות שלא הוסברו, לצערי, פריים אחד ויחיד מהמצלמה הלך לאיבוד. זה כשלעצמו לא כל כך נורא, אבל מאותו רגע, כל פריים חדש שהגיע קיבל איכשהו את חתימת הזמן של הפריים שקדם לו. וזה כן נורא. המחשב קיבל פריים, אמר לעצמו "על סמך ה-IMU, התמונה הקודמת והזמן שבו התמונה החדשה צולמה, אני אמור לראות בה X", בדק וראה משהו אחר לגמרי. לדוגמה, בטיסה ישרה לגמרי, הוא יחשוב שהוא טס מהר מדי, כי מה שהוא חושב שהוא רואה בזמן t בעצם צולם מאוחר יותר, ב-t+1.
הזכרתי פה בעבר עיקרון בהנדסת אנוש, לפיו משוב למפעיל צריך להגיע בחלון זמן מוגבל. לדוגמה, אם טייס קרב מזיז את הסטיק, המטוס צריך להגיב תוך כמה עשרות אלפיות השנייה. אחרת, הטייס ירגיש – אפילו בצורה עוד לא מודעת – שהמטוס לא מגיב, והוא יטה את הסטיק יותר חזק. כשהתגובה תגיע סוף כל סוף, היא תהיה כמובן חזקה יותר ממה שהטייס התכוון מלכתחילה, ואז הוא ינסה לפצות לצד השני – שוב, פיצוי יתר, בגלל העיכוב בתגובה. לא חסרים סרטונים ביוטיוב של רובוטים שמנסים להתאזן על שני גלגלים ונקלעים ללולאת משוב הרסנית כזו.
להערכתי, דבר דומה קרה למסוק הרובוטי. בגלל הפער בחתימת הזמן נראה היה לו שמשהו לא בסדר והוא ניסה לפצות על כך. התמונות העדכניות אמנם שיקפו את הפיצוי, אבל חתימת הזמן שלהן הראתה שזה קרה כביכול מוקדם יותר, אולי עוד לפני שהוא נתן בכלל את הפקודות. המחשב מנסה לפצות בכיוון ההפוך על הסטייה הלא-צפויה החדשה, ומגלה לתדהמתו שהוא שוב פספס: כוח מסתורי כבר היטה את המסוק "בעבר", ואם הפקודה החדשה שלו תתבצע, הסטייה תהיה גדולה מדי… וחוזר חלילה.
לדברי נאס"א, מערכת הבקרה של המסוק סובלנית לסטיות בנתונים (טרם מצאתי פרטים מדויקים מה זה אומר), והדבר הציל את הטיסה. כמו כן, בשלבים האחרונים של הנחיתה המערכת עוברת להסתמך באופן בלעדי על ה-IMU כדי לשפר את זמני התגובה והדיוק, וזה הפסיק את כל התנודות שנגרמו מחתימות הזמן השגויות.
עד שלא יימצא מקור מוסמך טכני, אנחנו יכולים רק לשער איך קורה מצב שבו כל חתימות הזמן נכנסות ל"הפרש פאזה" כזה. הרי אם יש שעון זמן-אמיתי במערכת, אפשר היה לקרוא ממנו את השעה בדיוק כשנשלחת הפקודה לצלם תמונה חדשה (או שמגיע מידע שתמונה צולמה, אם מדובר במודול עצמאי). כך, גם אם תמונה אחת או שתיים ייצאו מסינכרון מסיבה כלשהי, השגיאה תהיה זמנית ולא תיגרר הלאה. לדעתי, "חתימת הזמן" של התמונות הושגה לא ישירות מהשעון, אלא על ידי הגדלה של מונה מספרי. במקרה כזה, כל פספוס – למשל, עיכוב חריג שמונע פעם אחת טיפול בפסיקת טיימר – ייצור פיגור בחתימות הזמן, שיימשך עד סוף הטיסה.
אותו הדבר יכול לקרות לא רק לרובוט, ולא רק לחתימות זמן, אלא לכל מידע סדרתי: מיספור רץ של דגימות, אינדקסים של חבילות מידע וכו': אם הפקת התגיות של הנתונים מנותקת איכשהו מהפקת הנתונים עצמם עלינו לדאוג לסינכרון זהיר שלהם, ואם התגיות אמורות להיות מסונכרנות עם מידע "חיצוני" כלשהו, צריך לוודא שהסינכרון הזה נשמר ולא להניח שתיאום התחלתי יחזיק מעמד לנצח.
עוד נקודה מעניינת: אם המסוק טס 4 מטרים לשנייה וצילם 30 פעמים בשנייה, זה אומר כ-13 ס"מ בין צילום לצילום. להבחין בהבדלים בתוואי הקרקע אחרי תנועה של 13 ס"מ מגובה 10 מטרים, זה הישג מרשים במידה מחשידה לרובוט כזה קטן. לדעתי, הצילומים טובים יותר לזיהוי שינויים בזווית של המסוק ביחס לאנך: זה גם יכול להסביר למה הנדנודים התחילו דווקא בנקודת הזמן בה המסוק שינה כיוון, ולא במאה וחמישים המטרים הקודמים בהם טס בקו ישר. אפשרות אחרת היא שפעולת הפנייה עצמה גרמה לעיכוב ששיבש את חתימות הזמן של התמונות, אבל המסוק כבר פנה בעבר ללא תקלות כאלה. אם יש לכם מידע נוסף, תנו קישור…