דברים שלמדתי מרובוט מקולקל

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

רובוט משליך כדורים, אבל לא עכשיו
רובוט משליך כדורים, אבל לא עכשיו

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

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

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

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

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

מה קרה שם

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

התיכוניסטים בחרו להתמקד בתוכנת השליטה. ברובוט, כך סיפרו, מותקן בקר ייחודי לתחרויות אלה, בשם roboRIO. זהו מודול עצמאי ומשוכלל עם מעבד חזק ומערכת הפעלה, ששולט בכל הקלט והפלט האלקטרוניים. במקרה של הרובוט הזה, ה-roboRIO מתקשר עם מחשב PC רגיל באמצעות נתב אלחוטי. במחשב מותקנת התוכנה הראשית (כתובה ב-LabVIEW) שאוספת את הפקודות מהג'ויסטיק, מעבדת נתונים ושולחת הנחיות לרובוט. ההשערה כעת הייתה שמישהו העלה תוכנה לא נכונה, או "שיחק" עם התוכנה הנוכחית, כך שהפקודה לסובב את הרצועה לירי הכדור לא נשלחה.

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

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

מה אפשר ללמוד מזה

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

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

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

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

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

 

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *