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