লাইভ প্রসেসিং নাকি রেকর্ড করা ডেটা: আসলে কীসের VPN দরকার?
রোবটের কোন কাজটি নেটওয়ার্ক পেরোবে তা ঠিক করুন: সময়োপযোগী ফলাফল, পর্যবেক্ষণ টেলিমেট্রি নাকি রেকর্ড করা ডেটাসেট। তিনটি শর্ত, তারপর bag কমান্ড।
এক ঘর দূরে গেলেই যে রোবট অকেজো হয়ে যায়, তার VPN সমস্যার বহু আগেই লিংক সমস্যা বা ওয়ার্কলোড সমস্যা থাকে। এনক্রিপশন একটি পথ রক্ষা করে; এটি রেডিও কভারেজ বাড়ায় না, আর দূরের গণনা আগে শেষ করিয়েও দেয় না। আপনার সামনের সিদ্ধান্তটি হলো কোন কাজটি সত্যিই নেটওয়ার্ক পেরোতে হবে, আর সেই উত্তর সাধারণত মানুষের প্রত্যাশার চেয়ে বেশি ট্রাফিক সরিয়ে দেয়। তিনটি শর্তই এটি ঠিক করে, আর থ্রুপুট তাদের একটি নয়।
তিনটি বিন্যাস, নির্ভরতা নিয়ে একটি প্রশ্ন
সারণিটি বিন্যাসগুলোকে আলাদা করে এভাবে যে লিংকের উপর কী নির্ভর করে, ডায়াগ্রামে কোন সফটওয়্যার দেখা যায় তা দিয়ে নয়।
| Arrangement | What depends on the link | What stays onboard |
|---|---|---|
| Live remote processing | The exchange and any timely result the workstation returns | Only what the remote step does not block |
| Onboard processing, remote observation | The declared telemetry or display stream | The processing loop itself |
| Local recording, later analysis | Transfer of one selected dataset | The entire run, including raw sensors |
সেই সারণির কোনো সারিই নিরাপত্তার যুক্তি নয়। নিয়ন্ত্রণ ও নিরাপত্তা কার্যাবলির এখনও বিলম্ব, প্যাকেট হারানো ও সংযোগ বিচ্ছিন্ন হওয়ার জন্য যোগ্য উত্তর দরকার, আর কোনো টানেল সূচক তা দেয় না। সারণিটি বলে নির্ভরতাটি কোথায় থাকে, আর সেটাই সেই অংশ যা একটি নেটওয়ার্ক নকশা সত্যিই বদলাতে পারে।
শর্ত এক: উত্তরটি কি সময়োপযোগী হতে হবে?
যদি দূরের ফলাফল কোনো নিয়ন্ত্রককে খাওয়ায়, নেটওয়ার্ক নিয়ন্ত্রণ লুপের ভিতরে থাকে, আর তার বিলম্ব, জিটার ও বিচ্ছিন্নতা নিয়ন্ত্রণের বৈশিষ্ট্য হয়ে ওঠে। যদি একই ফলাফল কেবল একটি ডিসপ্লে, ড্যাশবোর্ড বা দেখতে থাকা একজন মানুষকে খাওয়ায়, তবে একই বিলম্ব নিছক সৌন্দর্যের বিষয়।
বেতার লিংকে ক্লোজড-লুপ কাজ সম্ভব, আর বেশিরভাগ “VPN ধীর” প্রতিবেদনের উৎসও এখানেই, কারণ টানেলটি দৃশ্যমান উপাদান আর রেডিও ও রাউটিং হলো কারণ। টানেলের নিজের পিং নয়, বাস্তব বার্তার রাউন্ড ট্রিপ মাপুন, তারপর জিজ্ঞাসা করুন সংখ্যাটি লুপের বাজেটে ফিট করে কি না। না ফিট করলে ধাপটি অনবোর্ডে নিয়ে যান, ঘরের কেউ নিয়ন্ত্রণ করে না এমন লিংকের জন্য আরও কঠোর সার্ভিস লেভেল নিয়ে দরকষাকষি করার বদলে। মাপা সংখ্যাটি যে পরিস্থিতিতে নেওয়া হয়েছে তা সহ লিখে রাখুন, কারণ পরের প্রতিবেদন সেগুলো ছাড়াই আসবে।
শর্ত দুই: কোন হার, দিক ও বিঘ্ন আপনি ঘোষণা করতে পারেন?
ডেটা, হার, দিক এবং অ্যাপ্লিকেশন যে দীর্ঘতম বিঘ্ন সহ্য করে তা লিখে রাখুন। উজানের ক্যামেরা স্ট্রিম আর ডাউনস্ট্রিম কমান্ড চ্যানেল ভিন্নভাবে ব্যর্থ হয়, আর স্থির পরিদর্শন যে বিঘ্ন সহ্য করে তা চলমান কাজ শেষ করে দেবে।
বিকল্প তুলনা করার সময় ভৌত সংযুক্তি ও টানেল আলাদা রাখুন, কারণ শক্তিশালী রেডিও আর ছোট ওয়ার্কলোড ভিন্ন ভিন্ন মেরামত। বড় ট্রান্সফার শেষ পর্যন্ত সম্পন্ন হওয়া সময়-সংবেদনশীল ফলাফল ধারাবাহিকভাবে আসার কোনো প্রমাণ নয়, আর সুস্থ টানেল তার পেছনের রেডিও সম্পর্কে কোনো প্রমাণ নয়।
তারপর চাহিদা রক্ষা না করে তা কমান। পর্যবেক্ষণ স্ট্রিম ডাউনস্যাম্পল করুন, সারাংশ বা ডেল্টা পাঠান, এবং কাঁচা সেন্সর ডেটা অনবোর্ডে রাখুন যেখানে সংরক্ষণ সস্তা আর প্রেরণ নয়। ছোট পেলোড দ্রুত লিংকের পক্ষে যুক্তি দুর্বল করে, আর প্রায়ই তার প্রয়োজনই সরিয়ে দেয়।
শর্ত তিন: কে এটি দেখবে, আর কী স্থানীয় থাকবে
পর্যবেক্ষণ সাধারণত প্রসেসিংয়ের চেয়ে অনেক ছোট প্রয়োজন। যদি একজন মানুষকে ক্যামেরা দেখতে হয় এবং পরে একটি লগ থাকতে হয়, সেটি টেলিমেট্রি প্লাস স্টোরেজ; যদি একটি মডেল চালাতে হয়, আগে জিজ্ঞাসা করুন এটি কি কেবল তার ফলাফল পাঠিয়ে অনবোর্ডে চলতে পারে। ভারী ধাপটি অনবোর্ডে নিয়ে গেলে সিঙ্ক্রোনাস নির্ভরতা সরে যায় আর একটি পুনরায় চেষ্টা করার মতো ট্রান্সফার থেকে যায়।
একই রোবটে দুটি ROS অংশগ্রহণকারী থাকা নিজে নিজে একটি টানেলের যৌক্তিকতা দেয় না। নোডের নাগাল, অ্যাপ্লিকেশন অনুমোদন আর স্থানীয় পুনরুদ্ধার পরিকল্পনা আলাদা সমস্যা, আর একটি VPN কেবল প্রথমটির উত্তর দেয়, তাও কেবল যে ট্রাফিককে তার মধ্য দিয়ে রাউট করতে বলা হয় তার জন্য।
ডেটাসেট রেকর্ড করা নিজস্ব নকশা, নিজস্ব কমান্ডসহ
সংস্করণ-নির্দিষ্ট উদাহরণের জন্য, ROS 2 Jazzy রেকর্ডিং টিউটোরিয়াল নির্বাচিত টপিক রেকর্ড করা, ফলাফল bag পরীক্ষা করা এবং তা পুনরায় চালানো কভার করে। অনুমোদিত পর্যবেক্ষণ টপিকগুলো রেকর্ড করুন, রানটির নাম দিন, আর মেসেজ ডেফিনিশন ও কনফিগারেশন তার পাশে রাখুন।
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42
টুলটি সহজ করে দেয় বলে প্রতিটি টপিক রেকর্ড করবেন না। স্টোরেজ ভরে যায়, ক্যামেরা ও অবস্থান ডেটা সংবেদনশীলতা বহন করে, আর লেবেলহীন টপিকের bag পরেরবার যিনি খুলবেন তার জন্য বিশ্লেষণের সমস্যা। স্থাপিত ডিস্ট্রিবিউশনও কমান্ড নির্ধারণ করে: ROS 1 bag-এর জন্য লেখা টুলিং ROS 2 bag-এ স্থানান্তরিত হয় না, তাই ডকুমেন্টেশন রোবটে ইনস্টল করা সংস্করণের সঙ্গে মিলিয়ে নিন।
বিচ্ছিন্ন বিশ্লেষণ বা সিমুলেশন পরিবেশে পুনরায় চালান। রেকর্ড করা কমান্ড টপিক লাইভ রোবটের অ্যাকচুয়েটরে পুনরায় চালানো একটি দুর্ঘটনা, আর প্রতিরোধ হলো আলাদা ROS ডোমেইন বা লুপে কোনো হার্ডওয়্যারই না থাকা।
নির্ভরতাটি কোথায় থাকবে তা ঠিক করুন এবং লিখে রাখুন: একটি VPN এমন একটি বিনিময় রক্ষা করে যা ঘটতেই হবে, অনবোর্ড প্রসেসিং এমন বিনিময় সরিয়ে দেয় যার কখনোই সিঙ্ক্রোনাস হওয়ার দরকার ছিল না, আর রেকর্ড করা ডেটাসেট লাইভ গ্রাহককে পরের কোনো গ্রাহক দিয়ে বদলে দেয়। তারপর কেউ নকশাকে সমাপ্ত বলার আগে, স্থানীয় কাজ চলমান রেখেই, সংযোগহীন অবস্থাটি ইচ্ছাকৃতভাবে পরীক্ষা করুন।