موضوعات 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 الخاص بالروبوت، وهو ما يريده المشغّل البعيد عادةً. إذا كان شيء في المكدس يعتمد على البث أو multicast بدلاً من ذلك، فيجب تقييم ذلك الشرط على حدة؛ وتحويل النفق إلى TAP لإرضاء أداة واحدة يوسّع الشبكة لكل مشارك.

توقف هنا إذا كان المسار أو مسار العودة مفقودًا. الناشر الذي يستجيب على مضيفه لكن لا يمكن الوصول إليه من محطة العمل لديه مشكلة توجيه، لا مشكلة ROS.

الخطوة 4: اسمح بمحادثة النظير وراقب موضوعًا واحدًا

افتح فقط المنافذ التي تحتاجها المحادثة المتفاوض عليها، وقيّد كل قاعدة بالمشاركين المعلنين. مستمع master ليس مرحّلًا لحمولات الموضوعات، لذا فإن السماح به وحده يترك نقطة نهاية الناشر مغلقة. أبقِ مستمعي ROS على حدود VPN الخاصة بدلًا من تعريضهم للإنترنت العام.

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

راقب موضوعًا واحدًا غير ضار من الناشر الحقيقي إلى المشترك الحقيقي، وأكد نقطة النهاية المعلنة ومسار الرد معًا. رسالة واحدة تثبت أن المسار يعمل؛ ومعدل ثابت يثبت أنه يبقى مفتوحًا. أبقِ التحكم في المشغّلات وفحوصات السلامة خارج هذا الاختبار الشبكي المحض، لأن موضوعًا عاملًا لا يشهد بأن الروبوت عامل. سجّل إصدار ROS وزوج نقطتي النهاية الذي لاحظته، ليتمكن الشخص التالي من التمييز بين تغيّر طوبولوجي وتراجع.

تكتمل القائمة عندما يصبح URI المعلن قابلاً للوصول من المشترك، ويكون المنفذ المتفاوض عليه مفتوحًا لذلك النظير وحده، ويتدفق موضوع معلن واحد، وتُكتب قيم البيئة لكلا المضيفين. لن يتلقى ROS 1 القديم إصلاحات في هذا المجال، لذا فإن السجل هو الجزء الذي يظل يعمل بعد تغيّر الأشخاص.