מ-UART ל-EtherCAT: מתי רובוט גדל מעבר לבקרת מנועים סריאלית

מדריך הנדסי · תוכנת רובוטיקה · זמן קריאה 16 דקות

בקרת מנועים דרך קישור סריאלי היא פתרון נכון לעיתים קרובות יותר ממה שנוח להודות. קו UART, מסגרת עם CRC, מנגנון Watchdog קטן בקושחה ומימוש צנוע של ros2_control יכולים לקחת רובוט אמיתי רחוק מאוד. בסיס דיפרנציאלי, ראש pan-tilt, גריפר, או מתקן מעבדה עם שני צירים יכולים לעבוד מצוין כך: זול, שקוף, וקל לדיבוג עם לוגיק אנלייזר.

אבל יש לזה תקרה.

התקרה הזו בדרך כלל לא מופיעה ככשל דרמטי. היא מופיעה כסדרה של סימפטומים בשטח: הרובוט נוסע יפה ב-20Hz והופך עצבני ב-100Hz; ציר אחד מתחיל תנועה כמה מילישניות לפני ציר אחר; מתאם USB מוסיף יותר latency מכל זמן המחזור; ה-Watchdog בקושחה מציל את הרובוט, אבל המחשב הראשי לא באמת יודע באיזה מצב נמצא הדרייב. בשלב הזה השאלה כבר אינה "איך שולחים פקודת מהירות?". השאלה היא איך בונים בקרת תנועה מבוזרת.

זה הרגע שבו UART מפסיק להיות כבל נוח והופך להיות הארכיטקטורה.

המאמר הזה הוא המשך טבעי למאמר על כתיבת ros2_control hardware interface: אותו רובוט, אותו controller_manager, אבל שכבת כוננים אחרת לגמרי מתחת. נתחיל מתקציב התזמון של קישור סריאלי, נראה איפה הוא נשבר, ואז נמפה את אותו חוזה read() -> update() -> write() אל EtherCAT וכונני CiA 402 / DS402.

שינוי הארכיטקטורה

עם בקר מנוע סריאלי, המחשב הראשי בדרך כלל מנהל זרם יחיד של פקודות, והקושחה מנהלת את הלולאות הפנימיות. עם EtherCAT, המחשב הראשי הופך ל-master בזמן אמת, וכל דרייב הופך לנקודת קצה מסונכרנת של process data.

גבול התוכנה לא משתנה באופן דרמטי. בשני המקרים ros2_control עדיין רואה state interfaces ו-command interfaces. ההבדל הוא במה ששכבת החומרה חייבת להבטיח. ממשק סריאלי הוא מתרגם. ממשק EtherCAT הוא משתתף במחזור בקרה בזמן אמת.

1. תקציב התזמון של UART

החישוב השימושי ביותר עבור UART פשוט מאוד. ב-8N1, כל byte עולה עשרה bit times: סיבית התחלה, שמונה סיביות מידע וסיבית עצירה. בקצב B, זמן האפיק למחזור בקרה אחד הוא:

T_bus = 10 * (N_tx + N_rx) / B

כאשר:

• N_tx הוא מספר הבתים מהמחשב אל הדרייב במחזור.
• N_rx הוא מספר הבתים מהדרייב אל המחשב במחזור.
• B הוא קצב ה-UART ב-bit/s.

נניח שבסיס דיפרנציאלי שולח מסגרת פקודה של 13 בתים ומקבל מסגרת מצב של 21 בתים ב-115200 baud:

T_bus = 10 * (13 + 21) / 115200
      = 2.95 ms

ב-50Hz זה נראה סביר:

T_loop = 20 ms
U_bus  = T_bus / T_loop = 14.8%

ב-100Hz זה עדיין אפשרי:

T_loop = 10 ms
U_bus  = 29.5%

אבל ברובוט אמיתי, 29.5% הוא לא רק מספר על הנייר. הוא לא כולל זמן דרייבר במערכת ההפעלה, buffering ב-USB, parsing בקושחה, שגיאות, retries, או השפעה של עומס CPU. כהיוריסטיקת שטח, כדאי להשאיר את זמן האפיק מתחת לכ-30% מזמן המחזור:

U_bus = T_bus / T_loop < 0.3

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

2. Latency הוא חלק מהמערכת הפיזיקלית

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

הקשר הפשוט בין delay לבין phase lag הוא:

phi_delay = -omega_c * T_delay

או במעלות:

phi_delay_deg = -360 * f_c * T_delay

אם תדר החיתוך של הלולאה הוא 20Hz וה-delay האפקטיבי הוא 5ms:

phi_delay_deg = -360 * 20 * 0.005 = -36 deg

זה מספיק כדי להפוך לולאה יציבה-בקושי ללולאה עצבנית. זו הסיבה שהבעיה לא נראית כמו "התקשורת איטית". היא נראית כמו overshoot, רעידות, following error, או תנועה לא מסונכרנת בין צירים. מערכות ROS 2 בזמן אמת חושפות latency כבעיה של כל ה-stack: חומרה, קושחה, מערכת הפעלה, ספריות וקוד האפליקציה כולם תורמים למסלול.

3. מתי UART עדיין פתרון טוב

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

UART עדיין בחירה טובה כאשר:

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

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

בין UART ל-EtherCAT יש גם אפשרויות ביניים כמו RS-485 multidrop, CAN/CANopen ו-CAN-FD. הן יכולות להיות מצוינות כאשר חסינות תקשורת וחיווט רב-צמתי חשובים יותר מתנועה מסונכרנת ברמת תת-מילישניה.

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

4. הסימנים שהמערכת גדלה מעבר ל-UART

המעבר ל-EtherCAT מוצדק כאשר לפחות אחד מהדברים הבאים מתחיל להיות נכון:

• מחזור הבקרה מתקרב לזמן השידור של המסגרות.
• מספר הצירים גדל, וכל ציר מוסיף פקודות, מצב, latency וטיפול בתקלות.
• הצירים חייבים ללכוד setpoints באותו זמן אפקטיבי.
• הדרייבים צריכים mode סטנדרטי, statusword, fault reaction ו-quick stop.
• הרובוט צריך לעבוד מול דרייבים ממספר יצרנים בלי לשכתב את כל הממשק.
• ה-controller בצד ROS 2, ולא הקושחה, צריך להיות בעל פרופיל התנועה.

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

5. מה EtherCAT מוסיף

EtherCAT אינו רק UART מהיר יותר. הוא משנה את מודל התקשורת.

במקום שהמחשב ישלח packet לכל דרייב ויחכה לתשובה, EtherCAT מחליף process data מחזורי על פני כל הרשת. כל מחזור מכיל את ה-setpoints, המצבים, הסטטוסים וה-diagnostics הדרושים לבקרה. הדרייבים לא "עונים לשיחה"; הם משתתפים במחזור משותף.

התוצאה המעשית:

• זמן המחזור מוגדר וברור.
• ה-master יודע אם מחזור הוחמץ.
• כל הדרייבים מקבלים process data באותו קצב.
• distributed clocks מאפשרים סנכרון מדויק יותר בין צירים.
• fault handling יכול להיות סטנדרטי ולא vendor-specific.

זה ש-DC "מופעל" בקונפיגורציה לא מספיק; צריך לוודא את מצב הסנכרון בפועל בדרייב, את תקופת/היסט Sync0, ואת מדדי ה-working counter ו-cycle miss שנמדדים בזמן ריצה.

זו הסיבה ש-EtherCAT נפוץ ברובוטיקה תעשייתית, מכונות CNC, מערכות packaging, AGV/AMR מתקדמים וכל מערכת שבה "כמעט באותו זמן" אינו מספיק.

6. DS402: שפה משותפת לדרייבים

CiA 402, שנקרא הרבה פעמים DS402, הוא פרופיל דרייבים ובקרת תנועה. הוא מגדיר state machine, אובייקטים כמו controlword ו-statusword, מצבי פעולה, fault handling וחלק גדול מהשפה המשותפת בין master ל-drive.

כלל מעשי: משתמשים ב-PDOs ל-process data מחזורי בזמן אמת; משתמשים ב-SDOs לקונפיגורציה, commissioning ו-diagnostics מחוץ למסלול החם.

הערך של DS402 אינו רק במהירות. הערך הוא בכך שתנועה הופכת למעבר מצב ברור:

• Switch On Disabled
• Ready To Switch On
• Switched On
• Operation Enabled
• Quick Stop Active
• Fault

במערכת סריאלית פשוטה, קל לכתוב פקודה כמו ENABLE=1 ולגלות שכל יצרן, וכל קושחה, מפרשים אותה אחרת. ב-DS402, יש רצף controlword/statusword מוגדר. עדיין יש הבדלי vendor, אבל שפת הבסיס הרבה יותר יציבה.

7. מצבי פעולה: CSP, CSV ו-CST

במערכות רובוטיות נפוצים במיוחד שלושה cyclic synchronous modes:

• CSP - Cyclic Synchronous Position
• CSV - Cyclic Synchronous Velocity
• CST - Cyclic Synchronous Torque

ב-CSP, ה-master שולח target position בכל מחזור. הדרייב סוגר את הלולאות הפנימיות ומדווח actual position/statusword. זה מתאים לזרועות רובוטיות ולמערכות trajectory שבהן joint_trajectory_controller מייצר setpoints.

ב-CSV, ה-master שולח target velocity. זה מתאים לבסיסים ניידים, מסועים, spindle-ים או מערכות שבהן המהירות היא המשתנה המרכזי.

ב-CST, ה-master שולח target torque. זה מתאים לבקרה מתקדמת יותר, force control, impedance control או מערכות שבהן ROS 2 צריך להיות קרוב יותר ללולאה הדינמית. זה גם דורש תכנון זהיר יותר של זמן אמת ובטיחות.

8. מיפוי ל-ros2_control

הדרך לחשוב על ros2_control היא לא "איך שולחים packet לדרייב", אלא "אילו ממשקי מצב ופקודה אני מייצא לבקרים".

בממשק חומרה מבוסס EtherCAT, read() בדרך כלל:

• קורא actual position, velocity או torque מה-PDOs.
• קורא statusword ו-diagnostics.
• מעדכן state interfaces של כל joint.
• מתרגם fault/warning למידע ש-ROS 2 יכול לפרסם.

write() בדרך כלל:

• בודק שהפקודה לא stale.
• מפעיל את state machine של DS402.
• כותב target position/velocity/torque.
• מעדכן controlword.
• מוודא שלא שולחים setpoints לפני שהדרייב מוכן.

עיקרון חשוב: לא כדאי לערבב "enable sequence" עם "פקודת תנועה". הפעלת דרייב היא state transition. תנועה היא setpoint מחזורי. ערבוב ביניהם גורם ל-recovery לא צפוי אחרי fault.

9. תקציב מחזור ב-EtherCAT

גם EtherCAT לא מבטל פיזיקה. עדיין צריך תקציב זמן:

T_compute + T_bus + T_margin <= T_cycle

כאשר:

• T_compute הוא זמן החישוב בצד המחשב וה-stack.
• T_bus הוא זמן החלפת process data.
• T_margin הוא מרווח מתוכנן ל-jitter, diagnostics ועומס.
• T_cycle הוא מחזור הבקרה המוגדר.

אם בוחרים מחזור של 1ms:

T_cycle = 1 ms

אי אפשר להתייחס ל-1ms כאל "בערך". זה אומר שה-thread של הבקרה, ה-EtherCAT master, מערכת ההפעלה והקונפיגורציה של הדרייבים צריכים לעמוד בתקציב באופן עקבי. אחרת fault של missed cycle אינו באג. הוא אבחון נכון.

אזהרת הגירה:

EtherCAT מספק חילוף process data מחזורי ודטרמיניסטי ברמת ה-fieldbus. הוא לא הופך אוטומטית את Linux, את ה-user-space master, את מחולל ה-trajectory או את ה-hardware interface של ros2_control לדטרמיניסטיים.

10. Watchdogs עוברים למספר שכבות

במערכת UART פשוטה יש לרוב Watchdog אחד ברור: אם לא התקבלה פקודת host במשך T_watchdog, עצור את המנועים.

במערכת EtherCAT טובה יש כמה שכבות:

היחס הבסיסי עבור Watchdog בקושחה או בדרייב הוא:

T_watchdog < T_hazard
T_watchdog > N_miss * T_loop

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

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

11. מסלול הגירה מעשי

הדרך הבטוחה לעבור מ-UART ל-EtherCAT אינה "לכתוב מחדש הכול". היא להפריד את מה ש-ROS 2 רואה ממה שהחומרה עושה.

שלב 1: הקפאת חוזה ה-joints

הגדר בדיוק אילו joints קיימים, אילו command interfaces הם מקבלים ואילו state interfaces הם מחזירים:

left_wheel_joint:
  command: velocity
  state: [position, velocity]

right_wheel_joint:
  command: velocity
  state: [position, velocity]

או לזרוע:

joint_i:
  command: position
  state: [position, velocity, effort]

החוזה הזה צריך להישאר יציב בזמן שאתה מחליף את שכבת התקשורת.

שלב 2: כתיבת SystemInterface חדש

אל תכניס EtherCAT לתוך ממשק UART קיים. כתוב SystemInterface חדש שמייצא את אותם joints, אבל מנהל master, PDOs ו-state machine פנימית.

שלב 3: בחירת mode ראשון

לבסיס נייד, CSV יכול להיות המעבר הטבעי ביותר. לזרוע, CSP בדרך כלל מתאים יותר כי trajectory controller מייצר position targets. CST הוא חזק, אבל לא כדאי להתחיל ממנו אם עוד לא הוכחת timing, scaling ו-safety.

שלב 4: מיפוי PDOs

בנה mapping מפורש:

אל תסמוך על זיכרון או על defaults של vendor. כתוב את ה-PDO map כמו חוזה.

שלב 5: activation בטוח

ב-on_activate():

• קרא actual position.
• seed את target position לערך בפועל.
• אפס פקודות stale.
• בצע את רצף controlword עד Operation Enabled.
• אל תשלח trajectory לפני שהדרייב באמת enabled.

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

שלב 6: בדיקות לפני תנועה

לפני שמניעים ציר:

• בדוק statusword ללא מומנט.
• בדוק שכל PDO מתעדכן.
• ודא שה-cycle counter יציב.
• ודא שה-Watchdog עושה את מה שאתה חושב.
• נתק את ה-master וראה שהדרייב מגיב נכון.
• בדוק Quick Stop.
• בדוק fault reset כתהליך מצב, לא כפקודה בודדת.

12. טבלת סימפטומים

13. ההחלטה

UART הוא דרך טובה לגרום לבקר מנוע לדבר עם ROS. EtherCAT הוא דרך טובה לגרום לקבוצת דרייבים להתנהג כמו מכונה אחת.

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

• יש יותר צירים ממה שקישורים סריאליים נקודתיים מנהלים בצורה נקייה.
• זמן המחזור קצר מספיק כך ש-jitter וזמן bus הופכים למשתני בקרה.
• מספר צירים חייבים ללכוד פקודות באותו זמן אפקטיבי.
• נדרשים מצבי דרייב, faults, quick stop ו-diagnostics בצורה סטנדרטית.
• רוצים להחליף יצרני דרייבים בלי לשכתב את חוזה הבקרה.
• ה-controller ברובוט, ולא הדרייב, צריך להיות בעל trajectory.

כלל התכנון הסופי:

Use UART while the drive is a smart peripheral.
Use EtherCAT when the drives are distributed parts of one motion controller.

וזה כל ההבדל: קישור סריאלי שולח פקודות. fieldbus מסנכרן תנועה.

---

המאמר מבוסס על ניסיון מעשי בבקרת מנועים embedded, תכנון hardware interfaces ל-ROS 2, מושגי דרייבים לפי CiA 402 וארכיטקטורת fieldbus של EtherCAT. תמיד יש לאמת PDO maps, ביטים ב-statusword, התנהגות תזמון וממשקי controller מול הדרייב הספציפי והפצת ROS 2 שנמצאים מולכם.