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 زنوه جایگزینی مشروع است، اما مسیریاب آن وابستگی دیگری می‌شود که باید از طریق تونل در دسترس باشد.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

در آن RMW مسیریاب کشف را در چیدمان پیش‌فرض Jazzy حمل می‌کند و کشف چندپخشی آنجا غیرفعال است، پس این وابستگی به یادداشت‌های شما تعلق دارد نه به فرضی وام‌گرفته از میان‌افزار دیگر. بار کاری را ثابت نگه دارید وقتی یک تنظیم را تغییر می‌دهید، سپس آزمون echo را تکرار کنید و جهت، نرخ پیام و شرایط پیوند را ثبت کنید. مقایسه را دو بار اجرا کنید تا بهبود واقعی از اتصال دوباره شانس‌آور جدا شود. اگر تغییری کشف را بهتر کند در حالی که تحویل همان بماند، سرویس معرفی را جابه‌جا کرده‌اید، نه مسیر داده را.