ROS 2 از طریق مش بی سیم: تنظیمات DDS QoS برای تیم های ربات موبایل

تیم‌های ربات‌های سیار اغلب در آزمایشگاه به‌طور قابل‌اطمینانی ارتباط برقرار می‌کنند، سپس فرمان‌های تاخیری، به‌روزرسانی‌های حسگر از دست رفته یا بازیابی آهسته در هنگام تغییر مسیرهای مش ایجاد می‌کنند. الف مش بی سیم ROS 2 پهنای باند نوسانی، از دست دادن بسته ها و تغییر تعداد پرش را اضافه می کند، در حالی که DDS می تواند داده هایی را که قبلاً قدیمی هستند، مجددا ارسال یا در صف قرار دهد. تنظیمات QoS به کنترل قابلیت اطمینان، تاریخچه، عمق، دوام، ضرب‌الاجل و طول عمر برای هر موضوع کمک می‌کند، اما خط‌مشی‌های ناسازگار و مشترک ناسازگار می‌توانند تحویل را به طور کامل متوقف کنند.

نکته کلیدی این است که بدانید کدام جریان به هر نمونه نیاز دارد، کدام یک فقط به جدیدترین نمونه نیاز دارد، و چگونه می توان از غلبه کردن بارهای بزرگ به یک پیوند بازیابی جلوگیری کرد.

با ترافیک شروع کنید نه منوی QoS

تصمیم بگیرید که تازگی یا کامل بودن اهمیت بیشتری دارد

با این سوال شروع کنید که وقتی پیامی گم می شود چه اتفاقی می افتد و وقتی دیر می رسد چه اتفاقی می افتد. اسکن های LiDAR، فریم های دوربین، کیلومتر شماری، به روز رسانی های محلی سازی، و تله متری حرکتی به طور مداوم جایگزین می شوند. از دست دادن یک نمونه ممکن است قابل قبول باشد، در حالی که تحویل آن پس از چندین نمونه جدیدتر می تواند تصمیمات محلی را خراب کند یا زمان پردازش را تلف کند.

انتقال ماموریت، تکالیف وظایف، تغییرات پیکربندی، رویدادهای ایمنی و برخی از انتقال نقشه نیازمندی های متفاوتی دارند. یک رویداد گسسته از دست رفته ممکن است ربات ها را در حالت های عملیاتی ناسازگار بگذارد، بنابراین ارسال مجدد محدود می تواند توجیه شود. این تمایز بیشتر از نوع محموله به تنهایی مهم است: یک فرمان سرعت کوچک می تواند در صورت کهنه بودن خطرناک باشد، در حالی که یک عکس فوری نقشه بزرگ ممکن است پس از تأخیر مفید باقی بماند.

طبقه بندی ترافیک بر اساس تازگی و کامل بودن از یک اشتباه رایج مش بی سیم ROS 2 جلوگیری می کند - تنظیم هر موضوع روی RELIABLE زیرا مطمئن تر به نظر می رسد. DDS قابل اعتماد نمونه‌های شناسایی نشده را حفظ می‌کند و داده‌های از دست رفته را مجدداً ارسال می‌کند، و سربار ایجاد می‌کند که بهترین ارتباطات از آن جلوگیری می‌کند. بنابراین پروفایل استاندارد داده‌های حسگر ROS 2 از قابلیت اطمینان بهترین تلاش با صف کوچک‌تر استفاده می‌کند، جایی که تحویل به موقع عموماً بیشتر از دریافت هر خواندن مهم است.

به هر موضوع بودجه تحویل بدهید

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

بار پیشنهادی را از روی اندازه بار سریالی، نرخ انتشار و تعداد مقصدها تخمین بزنید. سپس آن رقم را با توان اندازه گیری شده چند هاپ به جای نرخ اسمی داده رادیو مقایسه کنید. ظرفیت پذیرش، ارسال مجدد، ترافیک کشف، ترافیک مدیریت مسیر و ناشران همزمان را بگذارید.

ترافیک داخلی ربات را از شبکه مشترک دور نگه دارید

هر موضوع ROS 2 نباید از مرزهای ربات عبور کند. فیدهای خام دوربین، ابرهای نقطه کامل، داده های اشکال زدایی، و خروجی های ادراک متوسط ​​اغلب در داخل رباتی هستند که آنها را تولید می کند. انتشار فقط شناسایی، ردیابی شی، طرح‌های محلی، کاهش ابرها یا تغییرات نقشه، تقاضای کانال مشترک را بدون تغییر رفتار DDS کاهش می‌دهد.

این مرحله فیلتر به ویژه در شبکه بی سیم ROS 2 چند رباتی ارزشمند است، جایی که یک جریان غیرضروری با نرخ بالا می تواند ظرفیت مورد نیاز چندین موضوع هماهنگی را مصرف کند. حذف ترافیک معمولاً سیستم قابل پیش بینی تری نسبت به تلاش برای محافظت از یک پیوند بارگذاری شده با صف های عمیق تر و تلاش های مجدد اضافی ایجاد می کند.

نمایه های QoS عملی برای موضوعات متداول ناوگان

جریان حسگر و حالت به‌روزرسانی مکرر

موضوعات حسگر و حالت با نرخ بالا معمولاً به جدیدترین نمونه موجود نیاز دارند، نه یک توالی کامل تاریخی. یک نمایه شروع عملی BEST_EFFORT، VOLATILE، و KEEP_LAST با عمق بین یک تا پنج است. عمق یک مناسب داده‌هایی است که فوراً جایگزین آن می‌شوند، در حالی که یک صف کمی بزرگ‌تر ممکن است تأخیرهای کوتاه زمان‌بندی برگشت تماس را بدون ایجاد یک بک لاگ طولانی جذب کند.

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

مشخصات دقیق باید منعکس کننده مصرف کننده باشد. یک گره محلی برای جلوگیری از موانع ممکن است نیاز به اسکن های مکرر با حداقل سن داشته باشد، در حالی که داشبورد ناوگان می تواند نرخ به روز رسانی کمتری را بپذیرد. ارسال هر دو از طریق مش بی سیم ROS 2 یکسان به این معنی نیست که به قابلیت اطمینان، عمق یا طول عمر یکسانی نیاز دارند.

دستورات و رویدادهای هماهنگی نیاز به برخورد متفاوتی دارند

دستورات پیوسته و رویدادهای هماهنگی گسسته نباید یک نمایه پیش فرض را به اشتراک بگذارند. جریان‌های سرعت، فرمان و تصحیح شکل‌گیری مکرراً تجدید می‌شوند، بنابراین نمونه‌های قدیمی نباید پشت ارسال مجدد صف بکشند. یک تاریخچه کم عمق، طول عمر کوتاه، و مهلت زمانی در سطح برنامه کمک می کند تا اطمینان حاصل شود که یک ربات با ناپدید شدن دستورات جدید متوقف می شود یا وارد حالت بازگشتی تعریف شده می شود.

پذیرش کار، تغییرات حالت عملیاتی و انتقال ماموریت ممکن است به تحویل قابل اطمینان نیاز داشته باشد زیرا هر رویداد حالت مشترک را تغییر می دهد. حتی در این صورت، تاریخ باید محدود بماند. پخش مجدد یک توالی طولانی از دستورات جایگزین شده پس از بازیابی مسیر می تواند مضرتر از گزارش وقفه و همگام سازی مجدد وضعیت فعلی ماموریت باشد.

قابلیت اطمینان DDS تنها یک لایه حفاظتی است. هر ربات متحرک باید انقضای فرمان محلی، محدودیت‌های حرکتی و رفتار قطع ارتباط را مستقل از شبکه اعمال کند. مش بی سیم ROS 2 می تواند انعطاف پذیری دسترسی و مسیر را بهبود بخشد، اما نمی تواند تصمیم بگیرد که آیا یک فرمان قدیمی هنوز ایمن است یا خیر.

نقشه‌ها، پیکربندی و روبات‌هایی که دیر به هم می‌پیوندند

از RELIABLE با TRANSIENT_LOCAL زمانی که یک ربات در حال پیوستن یا اتصال مجدد به آخرین وضعیت منتشر شده نیاز دارد، استفاده کنید. نقشه‌های کنونی، ژئوفنس‌ها، حالت‌های عملیاتی مشترک، و عکس‌های فوری پیکربندی اغلب با این الگو مطابقت دارند. KEEP_LAST(1) معمولاً مناسب‌تر از حفظ هر نسخه است زیرا فقط جدیدترین عکس فوری کامل از نظر عملیاتی مرتبط باقی می‌ماند.

KEEP_ALL باید برای داده هایی رزرو شود که توالی کامل آنها واقعاً مهم است و نیازهای منابع آنها مشخص است. نگه داشتن تمام فضای ذخیره‌سازی تابع محدودیت‌های منابع میان‌افزار است، بنابراین تضمین نامحدودی نیست. دوام گذرا-محلی همچنین ناشر را مسئول حفظ نمونه‌ها برای اشتراک‌های دیررس می‌کند.

سازگاری باید از هر دو طرف بررسی شود. یک ناشر با بهترین تلاش نمی تواند یک مشترک قابل اعتماد را راضی کند، و یک ناشر فرار نمی تواند یک اشتراک گذرا-محلی را راضی کند. ناشران قابل اعتماد می توانند به مشترکین با بهترین تلاش خدمات ارائه دهند، در حالی که ناشران محلی موقت می توانند پیام های جدیدی را برای مشترکین بی ثبات ارسال کنند. تحویل تاریخی حفظ شده به تنظیمات محلی-گذرا سازگار نیاز دارد.

جلوگیری از انتقال پیام های بزرگ به لینک

قبل از افزودن تلاش های مجدد، تکه تکه شدن را کاهش دهید

تصاویر، شبکه های اشغال و ابرهای متراکم نقطه قبل از عبور از شبکه به واحدهای حمل و نقل متعدد تقسیم می شوند. هنگامی که یک دیتاگرام بزرگ UDP در لایه IP تکه تکه می شود، از دست دادن یک قطعه از بازسازی کامل دیتاگرام جلوگیری می کند. قطعات باقیمانده می توانند بافرهای هسته را تا زمانی که منقضی شوند اشغال کنند و باعث شود که اتصال متوقف شده و ترافیک جدیدتر مسدود شود.

تخریب بار بزرگ در اتصالات ROS 2 بی سیم معمولاً با سه مکانیسم متصل مرتبط است: تکه تکه شدن بیش از حد IP، زمان‌بندی ناکارآمد ارسال مجدد، و انفجار بافر احتقانی. تغییرات پارامترهای DDS سازگار با استانداردها می تواند این اثرات را بدون نیاز به پروتکل کاربردی متفاوت کاهش دهد.

مسیر واقعی MTU را در سراسر شبکه بی سیم کامل ROS 2، از جمله رمزگذاری، تونل ها، رابط های مجازی و هر بخش مسیریابی اندازه گیری کنید. در جایی که پیکربندی حمل و نقل اجازه می دهد، اندازه پیام RTPS یا UDP را به اندازه کافی کاهش دهید تا از تکه تکه شدن لایه شبکه جلوگیری کنید. مقدار محاسبه شده از یک MTU اترنت 1500 بایتی تنها یک فرضیه شروع است زیرا هدرها و کپسوله سازی می توانند اندازه قابل استفاده را کاهش دهند.

صف های تاریخچه را کوچکتر از پنجره بازیابی نگه دارید

در طول یک وقفه مسیر، یک ناشر قابل اعتماد می‌تواند به تولید پیام‌ها ادامه دهد در حالی که تأییدیه‌ها نرسیده‌اند. نمونه های تایید نشده در تاریخ جمع می شوند تا زمانی که به محدودیت های منابع برسند. هنگامی که اتصال باز می گردد، مسیر بازیابی شده باید همزمان انتشارات جاری، کنترل ترافیک و بک لاگ حفظ شده را داشته باشد.

عمق تاریخچه را از تعداد نمونه هایی که پس از اتصال مجدد مفید باقی می مانند، انتخاب کنید. یک جریان حالت 20 هرتز با عمر مفید 250 میلی ثانیه به ندرت به ده ها نمونه در صف نیاز دارد. بسیاری از آنها در حال حاضر کهنه شده بودند. حالت قابل تعویض باید به نفع آخرین نمونه باشد، در حالی که توالی رویدادهای ضروری به یک طرح بازیابی محدود نیاز دارند.

نمونه های قابل اعتماد بزرگ نیاز به بررسی اضافی دارند: آیا ضعیف ترین مسیر مورد انتظار می تواند صف را بدون تاخیر در ترافیک فعلی تخلیه کند؟ یک تاریخچه عمیق ممکن است از دست دادن فوری داده ها را کاهش دهد، اما استفاده از حافظه، زمان بازیابی و احتمال افزایش ترافیک پس از قطع را نیز افزایش می دهد. سابقه حفظ بیش از حد می تواند انفجارهای بافری ایجاد کند که پس از بازگشت اتصال، تراکم را بدتر می کند.

مراقب انفجارهای ارسال مجدد باشید

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

به جای اعمال یک مقدار در سطح ناوگان، زمان‌بندی ارسال مجدد را در فاصله انتشار هر موضوع آزمایش کنید. تأخیر بازیابی، تأخیر دم، جیتر، سربار بسته کنترلی و بار CPU را پس از هر تغییر اندازه گیری کنید. سیگنالینگ بازیابی سریعتر ممکن است اندازه تاخیر و انفجار را کاهش دهد، اما ترافیک کنترل بیش از حد می تواند پردازش و پهنای باند را مصرف کند.

هیچ تنظیم زمان‌بندی نمی‌تواند مش بی‌سیم ROS 2 را که بار پیشنهادی آن از بازده قابل استفاده بیشتر است، نجات دهد. وقتی پیوند اشباع باقی می ماند، تلاش های مجدد، ترافیک را به مسیری که قبلاً بارگذاری شده است اضافه می کند.

در عوض تصمیم بگیرید که چه زمانی محموله را تغییر دهید

تنظیم QoS باید در جایی به پایان برسد که معماری برنامه به مشکل بزرگ‌تر تبدیل شود. هنگامی که جریان های بصری بر کانال غالب است، وضوح تصویر، کیفیت رمزگذاری یا نرخ فریم را کاهش دهید. ابرهای نقطه‌ای را قبل از انتقال برش دهید یا نمونه‌برداری کنید و ردیابی‌های شی، نتایج قابل عبور یا به‌روزرسانی‌های نقشه محلی را زمانی که هم تیمی‌ها به مشاهدات خام نیاز ندارند منتشر کنید.

پردازش لبه اغلب تمیزترین راه حل را ارائه می دهد. هر ربات می تواند داده های حسگر پهنای باند بالا را به صورت محلی حفظ کند و تنها اطلاعات مورد نیاز برای هماهنگی را توزیع کند. این یک مصالحه در قابلیت اطمینان DDS نیست. این یک تصمیم عمدی برای تطبیق تقاضای ارتباط با ظرفیت فیزیکی شبکه تلفن همراه است.

نمایه را روی ربات های متحرک تست کنید، نه فقط یک شبکه نیمکت

مسیرها و شکست هایی که ناوگان با آن مواجه می شود را دوباره بسازید

یک تست یک هاپ ثابت نمی تواند یک شبکه بی سیم ROS 2 موبایل را نشان دهد. اعتبارسنجی باید شامل کوتاه ترین مسیر، حداکثر تعداد پرش برنامه ریزی شده، حرکت بین موقعیت های رله، افزایش تداخل، ترافیک نامتقارن، قطعی کوتاه، قطعی طولانی، اتصال مجدد، اتصال دیرهنگام و انتشار همزمان توسط چندین روبات باشد.

تأخیر بیش از حد متوسط ​​را ثبت کنید. اندازه گیری های مفید عبارتند از:

●  دریافت فرکانس به روز رسانی و نرخ از دست دادن پیام.

●  سن پیام، تأخیر میانه، تأخیر دم، و لرزش.

●  زمان کشف یا اتصال مجدد پس از تغییر مسیر.

●  رشد صف نویسنده و خواننده در طول وقفه.

●  زمان مورد نیاز برای پاک کردن داده های مفید ذخیره شده.

●  استفاده از CPU و حافظه برای ناشران و مشترکین.

هر نتیجه را با بودجه تحویلی که قبلا ایجاد شده بود ارزیابی کنید. یک موضوع محلی سازی ممکن است شکست بخورد زیرا فرکانس به روز رسانی آن کمتر از نیاز کنترل است، حتی زمانی که هر نمونه در نهایت می رسد. برعکس، اگر در پنجره بازیابی مجاز تکمیل شود، ممکن است انتقال نقشه با وجود تأخیر بالاتر انجام شود.

از تله متری مش برای توضیح رفتار DDS استفاده کنید

معیارهای ROS 2 آنچه را که برنامه تجربه می‌کند نشان می‌دهد، در حالی که تله‌متری مش به توضیح علت وقوع آن کمک می‌کند. عملکرد موضوع را با تعداد پرش، تغییرات توپولوژی، قدرت سیگنال، نسبت سیگنال به نویز، ترافیک آپلود و دانلود و زمان بندی سوئیچ مسیر مقایسه کنید. همبستگی هر دو لایه مانع از سرزنش تیم‌ها به QoS برای تغییر مسیر رادیویی یا مقصر دانستن مش به دلیل تنظیمات ناسازگار و مشترک می‌شود.

ماژول‌های WDS MIMOmesh OEM/ODM و واحدهای هوابرد سبک وزن از معماری تمام IP با مسیریابی پویا بدون مرکز و حالت‌های رله چند هاپ استفاده می‌کنند. توابع مدیریت شبکه آنها توپولوژی، قدرت میدان، SNR، ترافیک، فاصله گره و اطلاعات وضعیت عملیاتی را ارائه می دهند که مهندسان می توانند با تاخیر، از دست دادن و رفتار صف ROS 2 مقایسه کنند.

نرخ داده های محصول و ارقام تاخیر تک پرش باید به جای تضمین عملکرد برنامه، مرجع برنامه ریزی باقی بمانند. رفتار واقعی انتها به انتها همچنین شامل عمق مسیر، اشغال کانال، بازیابی بسته ها، سریال سازی، صف های میان افزار و پردازش گره می شود. در یک حرکت شبکه بی سیم ROS 2 ، بازدهی اندازه گیری شده در ضعیف ترین مسیر عملیاتی باید نرخ انتشار و محدودیت تاریخ را افزایش دهد.

یک متغیر را در یک زمان تغییر دهید

با تأیید نام موضوعات، انواع پیام ها و سازگاری QoS شروع کنید. آزمایش کشف جدا از انتقال داده، زیرا گره‌ای که هرگز همتای خود را کشف نمی‌کند، با شکست بسته‌های از دست دادن نقطه پایانی همسان مواجه است. رویدادهای ناسازگار-QoS می‌توانند به برنامه‌ها کمک کنند تا عدم تطابق خط‌مشی‌ها را به جای ناشناخته ماندن خرابی شناسایی کنند.

یک مسیر و الگوی حرکتی قابل تکرار ایجاد کنید، سپس یک متغیر را در هر اجرا تنظیم کنید. قابلیت اطمینان، عمق، دوام، طول عمر، نرخ انتشار، اندازه بار، یا آستانه تکه تکه شدن را به طور مستقل تغییر دهید. تکرار همان سناریو تشخیص اینکه آیا بهبود ظاهری از تغییر QoS حاصل شده است یا از مسیر رادیویی بهتر، امکان پذیر است.

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

 

نتیجه گیری

ارتباطات ناوگان قابل اعتماد به تطبیق رفتار DDS با هدف هر موضوع بستگی دارد. جریان‌های حسگر تازه معمولاً به صف‌های کم‌عمق نیاز دارند، در حالی که رویدادهای مأموریت و روبات‌های اتصال مجدد ممکن است به قابلیت اطمینان محدود یا دوام گذرا-محلی نیاز داشته باشند. تکه تکه شدن، رشد عقب ماندگی، و بازده چند هاپ اندازه گیری شده باید نمایه نهایی را شکل دهد.

برای تیم‌هایی که مش بی‌سیم ROS 2 می‌سازند، شرکت فناوری Shenzhen Sinosun، با مسئولیت محدود، ماژول‌های OEM/ODM MIMOmesh و رادیوهای هوابرد سبک وزن را برای استقرار سیار و چند هاپ ارائه می‌کند. همراه با تست منظم QoS، این پلتفرم‌ها می‌توانند به کاهش ترافیک قدیمی، کوتاه کردن بازیابی و تمرکز پهنای باند مشترک روی داده‌های مفید کمک کنند.

 

سوالات متداول

س: آیا ROS 2 برای ارتباطات چند روباتی بی سیم مناسب است؟

پاسخ: بله، اما پیوندهای بی سیم به تنظیمات QoS مربوط به موضوع نیاز دارند. قابلیت اطمینان، عمق صف، دوام و نرخ بارگذاری باید منعکس کننده از دست دادن بسته، تأخیر، تحرک و پهنای باند موجود باشد.

س: کدام تنظیم قابلیت اطمینان QoS روی مش بی سیم ROS 2 بهتر عمل می کند؟

پاسخ: بهترین تلاش را برای جریان‌های حسگر به‌روزرسانی مکرر و تحویل قابل اطمینان محدود برای دستورات، رویدادهای مأموریت، نقشه‌ها یا داده‌های پیکربندی که نباید از دست داد، استفاده کنید.

س: چرا ناشران و مشترکین ROS 2 گاهی اوقات موفق به اتصال نمی شوند؟

A: خط مشی های QoS ناسازگار می تواند از ارتباطات جلوگیری کند. عدم تطابق معمول شامل تنظیمات قابل اطمینان، دوام، مهلت یا سرزندگی بین نمایه پیشنهادی ناشر و نمایه درخواستی مشترک است.

س: چگونه باید پیام های LiDAR یا دوربین بزرگ را از طریق شبکه مش مدیریت کرد؟

A: اندازه بار را کاهش دهید، از تقسیم IP جلوگیری کنید، نرخ انتشار را محدود کنید، و صف ها را کم عمق نگه دارید. پردازش محلی یا خروجی های فشرده اغلب بهتر از انتقال هر نمونه حسگر خام عمل می کند.

س: تیم های ربات متحرک باید از چه عمق تاریخچه ای استفاده کنند؟

A: عمق را با توجه به طول عمر پیام و نیازهای بازیابی انتخاب کنید. از عمق یک برای حالت قابل تعویض استفاده کنید، در حالی که رویدادهای ضروری ممکن است به یک صف بزرگتر اما کاملاً محدود نیاز داشته باشند.