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 পরীক্ষা পুনরাবৃত্তি করুন এবং দিক, বার্তার হার ও লিংকের অবস্থা লিপিবদ্ধ করুন। প্রকৃত উন্নতি আর ভাগ্যবান পুনঃসংযোগ আলাদা করতে তুলনাটি দুবার চালান। যদি কোনো পরিবর্তন ডিসকভারি উন্নত করে কিন্তু ডেলিভারি একই থাকে, তবে আপনি পরিচয় পরিষেবা সরিয়েছেন, ডেটা পাথ নয়।