VPN کے ذریعے ROS 2: دریافت ڈیٹا کا راستہ نہیں

VPN کے مخالف سروں پر دو ROS 2 نوڈ ایک دوسرے کے موضوعات کی فہرست بنا سکتے ہیں اور پھر بھی ایک بھی پیغام نہیں پہنچا سکتے۔ دریافت اور صارف کا ڈیٹا الگ راستوں والے الگ تبادلے ہیں، اور دریافت سرور پے لوڈ منتقل نہیں کرتا۔ ایک کو جانچنا اور دوسرے کو فرض کر لینا ہی وہ طریقہ ہے جس سے ٹیمیں مڈل ویئر بدلنے لگتی ہیں جب ٹنل نے کبھی ڈیٹا اٹھایا ہی نہیں۔ نیچے کا طریقہ کار کچھ بھی بدلنے سے پہلے دونوں نتائج کو الگ کرتا ہے۔

دریافت سرور واقعی کیا اٹھاتا ہے

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 راستہ اکثر صرف ایک طرف سے ظاہر ہوتا ہے۔

ایک وقت میں ایک انحصار بدلیں

جب ڈیٹا کا راستہ ناکام ہو، تو ایک ہی سیشن میں مڈل ویئر، دریافت موڈ اور پیغام کا سائز بدلنے سے بچیں، کیونکہ اس کے بعد کسی نتیجے کو منسوب نہیں کیا جا سکے گا۔ Zenoh RMW ایک جائز متبادل ہے، لیکن اس کا راؤٹر ٹنل کے ذریعے قابل رسائی ایک اور انحصار بن جاتا ہے۔

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

اس RMW کے تحت راؤٹر Jazzy کی ڈیفالٹ ترتیب میں دریافت اٹھاتا ہے، اور وہاں ملٹی کاسٹ دریافت بند ہے، لہٰذا یہ انحصار کسی دوسرے مڈل ویئر سے مستعار فرض میں نہیں بلکہ آپ کے نوٹس میں ہونا چاہیے۔ ایک سیٹنگ بدلتے وقت ورک لوڈ کو مستقل رکھیں، پھر echo ٹیسٹ دہرائیں اور سمت، پیغام کی شرح اور لنک کے حالات درج کریں۔ حقیقی بہتری کو خوش قسمتی کے دوبارہ رابطے سے الگ کرنے کے لیے موازنہ دو بار چلائیں۔ اگر کوئی تبدیلی دریافت کو بہتر کرے جبکہ ترسیل ویسی ہی رہے، تو آپ نے تعارف سروس منتقل کی ہے، ڈیٹا کا راستہ نہیں۔