כאשר מערכת מורכבת משני חלקים או יותר, שמעבירים פקודות או מידע מורכב זה לזה, מי מהם צריך להיות אחראי לעיבוד ולחישובים, ובאילו תנאים? הנה כמה שיקולים וכללי אצבע.
אחרי שהצלחתי להבין איך מפעילים את כל הפונקציות של הרובוט Macqueen, החלטתי בשלב ראשון לא להפוך אותו לאוטונומי, אלא לצוות אותו לג'ויסטיק מבוסס המיקרו:ביט שלי לצורך שליטה מרחוק, תוך שימוש בפונקציית התקשורת האלחוטית ("Radio") של כרטיסי המיקרו:ביט בשני הצדדים. במודול הג'ויסטיק הזה, כל לחצן מחובר לפין קלט נפרד של הכרטיס, והג'ויסטיק הקטן עצמו מחובר לשני פינים נוספים שמסוגלים לקרוא קלט אנלוגי עבור הצירים X ו-Y. בניגוד למקרה עם הרובוט, מיפוי הפינים היה ברור מאוד וקל למימוש בקוד. אבל השלב הבא הצריך קצת יותר חשיבה: איזה מידע בדיוק לשלוח ברדיו מהג'ויסטיק לרובוט?
כדי להבין טוב יותר את השאלה עצמה, ניקח מקרה מצומצם יותר, של רובוט שמסוגל לנסוע רק קדימה או אחורה (במהירויות שונות) ושל שלט רחוק עם ציר ג'ויסטיק יחיד. אם השלט יהיה "טיפש" לגמרי, פירוש הדבר שהוא פשוט ישלח את הקריאה האנלוגית אל הרובוט שוב ושוב בלולאה אינסופית. אפשרי? בהחלט, וזה בערך מה שעושים גם כיום בצעצועי שלט רחוק זולים. אבל האם זהו פתרון יעיל?
שידור מיידי כזה בלולאה אינסופית, אפילו אם נתעלם מכל פרמטר אחר, פשוט יחסל את הסוללה של השלט במהירות. מה כבר נפסיד אם נכניס השהייה של 10 אלפיות שנייה, למשל, בין שידור לשידור? כמו כן, בהתחשב בזה שכמו בארדואינו, קריאות אנלוגיות במיקרו:ביט הן 10 ביט אבל פלט PWM הוא 8 ביט בלבד, הרזולוציה המרבית תהיה מיותרת לגמרי. אפשר לבצע את המיפוי המתאים (חלוקה ב-4) כבר בשלט, וכך לקצץ כל שידור פי שניים – משני בייטים לאחד (מודול הרדיו עובד עם בייטים שלמים בלבד). פעולות ההשהייה והחישוב האלה יצרכו משמעותית פחות חשמל מאשר שידור.
אם כן, אפילו העברה של חלק זעיר מה"שכל" של המערכת מהרובוט אל השלט משפיעה לטובה על צריכת החשמל וגם משחררת המון עומס מאמצעי התקשורת. נניח כעת שהקונספט מצא חן בעינינו והחלטנו ללכת לקיצוניות השנייה: כל החישובים ייעשו בשלט, והרובוט יקבל אך ורק את השורה התחתונה, כלומר את ערכי ה-PWM הגולמיים שצריך להעביר לבקר המנוע. השלט גם יהיה חכם מספיק כדי לדעת לשדר רק כשהמשתמש משנה פיזית את מצב הג'ויסטיק (בתסריט הזה, לשם הפשטות, אנחנו לא חוששים משיבושים בשידור/קליטה).
זה יעבוד ויחסוך הרבה חשמל, אך יקשה עלינו מאוד כשננסה לשכלל את הרובוט – למשל אם ננטר את מצב הסוללה שלו. השלט הרי לא יידע מעצמו מה מצב הסוללה של הרובוט, ואם הלה יציית באופן עיוור לפקודות הוא עלול לרוקן אותה יותר מדי – מסוכן לסוללות ליתיום נטענות. אז עלינו לבחור כעת: האם הרובוט ישדר באופן "טיפש" את מצב הסוללה שלו לשלט, והשלט יפענח את המידע ויקבל את ההחלטות? או שניתן לרובוט חלק מה"שכל" כדי שהוא יוכל להחליט לבדו אם להפסיק לנסוע כשהסוללה מתרוקנת?
במבט מופשט יותר, המשחקים האלה מיתרגמים לשתי שאלות: 1) באיזה צד השימוש במשאבים יהיה יעיל, חסכוני או בטיחותי יותר, ו-2) מהו טווח הביטחון שבו אפשר להעביר פונקציונליות מצד לצד בלי שזה ייצור עומס יתר על ערוץ התקשורת עצמו. לשאלה הראשונה כדאי להוסיף עוד פרמטר, שפחות קשור לחומרה ויותר אלינו כמפתחים: מה המחיר, מבחינת עבודת פיתוח, של כל שינוי עתידי? הרי אם צד מסוים "טיפש" לגמרי, רק שולח מידע גולמי ומקבל פקודות ישירות, כמעט אף פעם לא נצטרך לשנות את הקוד שלו – וגם זה יכול להיות יתרון עצום. לדוגמה, אוכל לקחת את השלט הרחוק ה"טיפש" שהכנתי לרובוט ולהשתמש בו כמו שהוא גם במערכת אחרת לגמרי שאצור, כגון קונסולת משחקים בסיסית.
השלב הראשון בקבלת החלטה לגבי חלוקת ה"שכל" של המערכת חייב להיות הגדרה של גבולות הגזרה מבחינת ערוץ התקשורת (שאינו בהכרח אלחוטי, כמובן – זה כבר תלוי במערכת הספציפית). לדוגמה, אם חלקי המערכת מדברים ביניהם בשידורי אינפרה-אדום סטנדרטיים ומסוגלים להעביר רק כ-400 בייטים בשנייה, אז חייבים לוודא שהמידע שעובר מצד לצד לא יעבור את הרף הנמוך הזה.
בשלב שני, צריך לקבוע מהו המינימום של המידע שצריך להעביר כדי להבטיח תפקוד תקין של המערכת – והכוונה כאן לא למספר הבייטים הגולמי אלא לרמה הסמנטית, למשמעות של המידע. למשל, בלחצני השלט הרחוק שלי: האם הרובוט יצטרך לדעת רק מתי לחצתי על כל אחד, או גם מתי שחררתי אותו? (דמיינו למשל צופר של רכב, שגורם להשמעת הצליל רק כל עוד הוא לחוץ).
לאחר מכן יש לחפש חלקים במערכת עם מגבלות משמעותיות (על צריכת אנרגיה, זמן תגובה, נפח זיכרון וכו'): מה יתאים בהינתן המגבלות – להפוך את החלק הזה ל"טיפש" או ל"חכם"? כפי שראינו אין לזה תשובה אוניברסלית, הבחירה הנכונה תלויה במאפיינים הספציפיים של החלק והמערכת. אגב, אם בשלב זה נראה שהמגבלות מתחילות להעיק יותר מדי, יש סיכוי שעוד לא מאוחר מדי ואפשר לבחור חומרה אחרת, מתאימה יותר.
עד כאן עברנו על האילוצים הקשיחים של המערכת, אלה שאם נתעלם מהם היא פשוט לא תעבוד טוב (או בכלל). כעת אפשר להתחיל לחשוב על האילוצים הרכים: איזה פרוטוקול נוח לנו יותר להגדיר, לתכנת ולתחזק, האם יש איזשהו פרוטוקול סטנדרטי שנוכל לנצל וכדומה.
במערכת הרובוט+שלט שלי, החלטתי שהפקודות מכיוון השלט לרובוט יהיו גולמיות יחסית – מקבילות ל"לחצן X נלחץ" או "לחצן X שוחרר" – ויישלחו רק כשיש שינוי במצב השלט, פרט לערכי הג'ויסטיק האנלוגיים, שיישלחו לפחות פעם בשנייה גם אם כלום לא השתנה. הסיבה לכך, אותה הזכרתי ברמז למעלה, היא שהרובוט לא יכול להבדיל בין מצב שבו הוא לא מקבל פקודות חדשות כי המשתמש לא עשה כלום, לבין מצב שבו הוא לא מקבל פקודות חדשות כי השלט מחוץ לטווח. לעומת זאת, אם הוא מצפה שתגיע פקודה כל שנייה, הוא כן יוכל להבדיל בין המצבים ולעצור את עצמו די מהר במקרה של שיבוש או תקלה.
מבחינת הפיקוד, אם כך, רוב ה"שכל" של המערכת יהיה בצד הרובוט. אבל אני רוצה גם לשלוח מהרובוט קריאות חיישנים בחזרה אל השלט, כדי שהמיקרו:ביט שבו יוכל להציג למפעיל, על מטריצת הלדים, אינדיקציות למכשולים. בכיוון הזה של העברת מידע, הרובוט ישחק את תפקיד הטיפש וישלח ערכים גולמיים, ואילו השלט ה"חכם" יפענח את הנתונים ויעדכן את התצוגה שלו בהתאם. בשורה התחתונה, יוצא שכל חלק במערכת אחראי לעיבוד המתקדם של הנתונים שרלוונטיים לתפקוד שלו-עצמו. לא מפתיע, במיוחד בהתחשב בזה שלשני הצדדים כאן יש "מוח" זהה – אך כאמור, זו לא תמיד התשובה האופטימלית.