דרכי עבודה בכתיבת תוכנה לרובוט - מאת גיל טופמן

 

התוכנה אשר תפעיל את הרובוט היא מורכבת למדי, ויש להתייחס אליה כך.

הנה כמה מאפיינים רלוונטיים לכתיבת תוכנה לרובוט (מסוג רובונר):

·        התוכנה לרובוט מורכבת משורות קוד רבות, בסדר גודל בינוני.

·        כתיבת התוכנה מתבצעת ע"י צוות תוכנה. (מספר אנשים).

• התוכנה צריכה לפעול בשילוב עם חומרה.

 

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

 

כתיבה בצוות דורשת משמעת גבוהה וכתיבה מסודרת!

 

שימוש בקבועים

 

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

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

 

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

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

 

         על מנת לחסוך את כל הבעיות שהוזכרו במיקום החישנים, יש לעבוד עם קבועים (Constants), לדוגמא:

 

ATD0 equ 1234

ATD1 equ 1235

ATD2 equ 1236

 

IR_FL equ ATD0  ; front left sensor

IR_FR equ ATD1  ; front right sensor

…

         בדוגמא זו שאר הקוד בתוכנה יעבוד עם IR_FL ו IR_FR ולא עם  ATD0 ו ATD1. כך, כאשר ישונה חיבור החישנים, השינוי היחיד בתוכנה יהיה בקבועים, ויחסכו הרבה כאבי ראש בהמשך הדרך. 

 

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

 

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

 

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

 

 

שימוש בקבצים מרובים

 

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

 

        הדרך לעשות זאת היא באמצעות הפקודה #INCLUDE. #include היא precompiler statement, משמע שהיא מעובדת ע"י הקומפיילר לפני הקומפילציה האמיתית של הקוד. הוראה זו מוסיפה לתוכנה את תוכן הקובץ המתבקש. נהוג לכתוב שורות אלה בתחילת התוכנה. שימוש:

#INCLUDE <שם_קובץ_כולל_נתיב_אם_צריך>

(לדוגמאות ופירוט נוסף יש לקרוא במדריך ה-Compiler)

 

כתיבת תוכנה בצוות

 

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

 

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

 

; הסבר לקטע קוד

;  קריאה ונירמול קריאת חישן עצירת הרובוט,

label_x:

            MOVW           LEFT_SPEED, 0                     ;stop the right wheel

            MOVW           RIGHT_SPEED, 0                   ;stop the right wheel

            LDD                IR_LF                                      ;read the sensor

            JSR                  FIX_READING                       ;normalize the reading

            JSR                  CONVERT_TO_CM              ; convert to cm

           

        הדוגמא ממחישה ריווח נכון, אך יש בעיה אחרת: מהי -  אתם שואלים בתמיהה??

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

אז מהן הערות נכונות? הערות המסבירות דברים מסובכים והערות המסבירות באופן כללי מה עושות שורות הקוד שיבואו בהמשך.

 

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

לדוגמא:

; The turn function will cause the robot to turn left with specified radius in cm

; input  Accumulator A = radius

;  22/01/02 – David

;           the first implementation of the code

; 28/01/02 – Moshe

;           Fixed an error in the calculation formula

TURN_LEFT:

…

 

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

 

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

 

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

 

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

 

חזרה