مباحث ROS 1 روی VPN: نقطه پایانی اعلام‌شده را دنبال کنید

ایستگاه کاری شما از طریق تونل به master در ROS 1 می‌رسد و هنوز فهرست موضوع‌ها را خالی نشان می‌دهد. این الگو رایج است چون ثبت master و انتقال موضوع دو گفت‌وگوی متفاوت‌اند و فقط اولی از master می‌گذرد. فهرست زیر گفت‌وگوی دوم را طی می‌کند: نقطه پایانی که ناشر اعلام می‌کند، نشانی‌ای که مشترک باید بتواند به آن برسد، و مجوزی که به این زوج اجازه گفت‌وگو می‌دهد. همه‌چیز در اینجا فقط به ROS 1 قدیمی مربوط است که پنجره پشتیبانی Noetic آن در مه 2025 پایان یافت.

گام 1: ثابت کنید اتصال master همان اتصال موضوع نیست

با جدا کردن آنچه کار می‌کند از آنچه کار نمی‌کند شروع کنید. یک rostopic list موفق ثابت می‌کند که پوسته شما به پورت 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، یک کانتینر یا ترمینال دوم می‌تواند مقداری متفاوت از پوسته‌ای داشته باشد که آزمون شما در آن کار می‌کرد.

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

اعلام نام میزبان فقط وقتی کار می‌کند که هر همتا آن نام را به نشانی در دسترس مورد نظر تفکیک کند. اگر آن نام فقط درون شبکه خود ربات تفکیک شود، ایستگاه کاری در طرف دیگر تونل هیچ راهی برای استفاده از آن ندارد، و VPNی که هیچ پسوند DNS را هدایت نمی‌کند ناهماهنگی را بدتر می‌کند. تنظیم ROS_IP روی نشانی تونل تغییر کوچک‌تری است وقتی توپولوژی مسیریابی‌شده است. هر کدام را انتخاب کنید، آن را برای هر دو سر ثبت کنید، چون ناشر و مشترکی که بر سر هویت اختلاف دارند مذاکره می‌کنند و سپس نمی‌توانند متصل شوند.

اگر URI اعلام‌شده نشانی‌ای به کار می‌برد که هیچ همتایی نمی‌تواند به آن مسیریابی کند، اینجا توقف کنید. هیچ کاری با دیوار آتش نامی را که به رابط اشتباه تفکیک می‌شود درست نمی‌کند.

گام 3: نشانی اعلام‌شده را تفکیک‌پذیر و مسیریابی‌شده کنید

با URI در دست، دسترسی‌پذیری را از میزبان مشترک بیازمایید، نه از ربات. پورت TCPROS در طول مذاکره انتخاب می‌شود، پس آزمون زودهنگام سودمند پورت XMLRPC است و آزمون دیرهنگام سودمند سوکت برقرارشده. مسیری که فقط در یک جهت وجود دارد خرابی رایجی در 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 ربات حمل می‌کند، که معمولاً همان چیزی است که اپراتور از راه دور می‌خواهد. اگر چیزی در پشته به‌جای آن به broadcast یا multicast وابسته باشد، آن نیاز باید جداگانه ارزیابی شود؛ تبدیل تونل به TAP برای راضی کردن یک ابزار، شبکه را برای هر مشارکت‌کننده گسترده‌تر می‌کند.

اگر مسیر یا مسیر بازگشت وجود ندارد، اینجا توقف کنید. ناشری که روی میزبان خود پاسخ می‌دهد اما از ایستگاه کاری در دسترس نیست، مشکل مسیریابی دارد، نه مشکل ROS.

گام 4: گفت‌وگوی همتاها را مجاز کنید و یک موضوع را تماشا کنید

فقط پورت‌هایی را باز کنید که گفت‌وگوی مورد مذاکره نیاز دارد، و هر قاعده را به مشارکت‌کنندگان اعلام‌شده محدود کنید. شنونده master یک رله برای بار موضوع‌ها نیست، پس مجاز کردن تنها آن، نقطه پایانی ناشر را بسته نگه می‌دارد. شنونده‌های ROS را روی مرز VPN خصوصی نگه دارید، نه اینکه آن‌ها را به اینترنت عمومی آشکار کنید.

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

یک موضوع بی‌خطر را از ناشر واقعی به مشترک واقعی تماشا کنید و هم نقطه پایانی اعلام‌شده و هم مسیر پاسخ را تأیید کنید. یک پیام ثابت می‌کند مسیر کار می‌کند؛ نرخ پایدار ثابت می‌کند باز می‌ماند. کنترل محرک‌ها و بررسی‌های ایمنی را بیرون از این آزمون صرفاً شبکه‌ای نگه دارید، چون موضوعی که کار می‌کند رباتی را که کار می‌کند تأیید نمی‌کند. نسخه ROS و جفت نقطه پایانی را که مشاهده کردید ثبت کنید، تا نفر بعدی بتواند تغییر توپولوژی را از بازگشت‌پذیری تشخیص دهد.

فهرست زمانی کامل می‌شود که URI اعلام‌شده از مشترک در دسترس باشد، پورت مورد مذاکره فقط برای همان همتا باز باشد، یک موضوع اعلام‌شده جریان داشته باشد، و مقادیر محیط برای هر دو میزبان نوشته شده باشد. ROS 1 قدیمی در این حوزه اصلاحی دریافت نخواهد کرد، پس ثبت همان بخشی است که پس از تغییر افراد به کار خود ادامه می‌دهد.