נושאי ROS 1 דרך VPN: עקבו אחר נקודת הקצה המוכרזת

תחנת העבודה שלכם מגיעה ל-master של ROS 1 דרך המנהרה, ובכל זאת מציגה רשימת נושאים ריקה. התבנית הזו נפוצה: רישום master והעברת נושאים הם שני שיחות שונות, ורק הראשונה עוברת דרך ה-master. הרשימה שלהלן עוברת את השיחה השנייה: נקודת הקצה שהמפרסם מכריז עליה, הכתובת שהמנוי חייב להצליח להגיע אליה, וההרשאה שמאפשרת לזוג לדבר. כל מה שכאן מתייחס רק ל-ROS 1 הישן, שחלון התמיכה של Noetic שלו הסתיים במאי 2025.

שלב 1: הוכיחו שחיבור ה-master אינו חיבור הנושא

התחילו בהפרדה בין מה שעובד למה שלא. rostopic list מוצלח מוכיח שה-shell שלכם מצליח להגיע לפורט ה-XMLRPC של ה-master ושה-master מכיר נושאים; הוא לא אומר דבר על כך האם מנוי יכול להגיע למפרסם. שלוש הפקודות שלהלן הופכות את ההבחנה לגלויה, וכולן לקריאה בלבד.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

הפלט של rostopic info מציין את URI הצומת של המפרסם, שהוא כתובת XMLRPC על המארח של המפרסם. הכתובת הזו היא מה שהמנוי שלכם יקרא לה בהמשך, ולכן היא חייבת להיות נגישה מכל מקום שבו המנוי רץ. אם היא מצביעה על ממשק שקיים רק ב-LAN של הרובוט עצמו, חיפוש ה-master מצליח והנתונים לעולם לא מגיעים.

שלב 2: קראו את נקודת הקצה המוכרזת מהצומת עצמו

ROS 1 בוחר את זהות המארח המוכרזת שלו מתוך ROS_IP או ROS_HOSTNAME כשאחד מהם מוגדר, ואחרת נופל חזרה לפתרון השמות של המארח עצמו. בדקו את הסביבה של התהליך שהופעל בפועל, מפני שיחידת systemd, מכולה או מסוף שני יכולים לשאת ערך שונה מה-shell שבו הבדיקה שלכם עבדה.

echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host

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

עצרו כאן אם ה-URI המוכרז משתמש בכתובת שאף עמית לא יכול לנתב אליה. שום עבודה על חומת האש לא תתקן שם שנפתר לממשק הלא נכון.

שלב 3: הפכו את הכתובת המוכרזת לניתנת לפתרון ולניתוב

כשה-URI ביד, בדקו נגישות ממארח המנוי ולא מהרובוט. פורט TCPROS נבחר במהלך המשא ומתן, ולכן הבדיקה המוקדמת השימושית היא פורט XMLRPC והבדיקה המאוחרת השימושית היא ה-socket שהוקם. מסלול שקיים רק בכיוון אחד הוא כשל נפוץ ב-VPN מנותבים, ונתיב החזרה חשוב כמו הנתיב קדימה.

ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2

ממשק TUN מנותב נושא את שיחות ה-IP האלה בלי להרחיב את מקטע ה-Ethernet של הרובוט, וזה בדרך כלל מה שמפעיל מרוחק רוצה. אם משהו במחסנית תלוי במקום זה בשידור או ב-multicast, יש להעריך את הדרישה הזו בנפרד; הפיכת המנהרה ל-TAP כדי לספק כלי אחד מרחיבה את הרשת לכל משתתף.

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

שלב 4: אפשרו את שיחת העמיתים וצפו בנושא אחד

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

rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker

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

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