ROS 2 דרך VPN: הגילוי אינו נתיב הנתונים

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

מה שרת הגילוי נושא בפועל

ב-Fast DDS שרת Discovery Server מפיץ מידע על נקודות קצה: מי מפרסם, מי נרשם ומה ה-QoS שכל אחד מצפה לו. לאחר שהעמיתים יודעים זה על זה, נתוני המשתמש עוברים ישירות ביניהם ולא דרך אותו שרת. הגעה לשרת מוכיחה שהמתווך של ההיכרויות עונה, ולא יותר. VPN מנותב עדיין זקוק לנתיב עובד בשני הכיוונים בין הכתובות שהעמיתים מכריזים עליהן.

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

קראו את ה-RMW שהצמתים באמת משתמשים בו

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

printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20

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

בדקו גילוי ונתונים כשתי תוצאות

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

ros2 topic info /chatter --verbose
ros2 topic echo /chatter --once

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

שנו תלות אחת בכל פעם

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

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

תחת אותו RMW הנתב נושא את הגילוי בסידור ברירת המחדל של Jazzy, וגילוי multicast מושבת שם, לכן התלות שייכת להערות שלכם ולא להנחה שאולה מתוכנת ביניים אחרת. החזיקו את עומס העבודה קבוע בזמן שאתם משנים הגדרה אחת, ואז חזרו על בדיקת echo ורשמו כיוון, קצב הודעות ותנאי קישור. הריצו את ההשוואה פעמיים כדי להפריד שיפור אמיתי מחיבור מחדש בר-מזל. אם שינוי משפר את הגילוי בעוד המסירה נשארת זהה, העברתם את שירות ההיכרות ולא את נתיב הנתונים.