«کد یکسان برای شبیه‌ساز و سخت‌افزار»؛ هدف پروژه جدید ROS 2

آیا سیاست‌های ناوبری که در محیط مجازی آموخته شده‌اند، در برابر اصطکاک و نویز یک اتاق نشیمن واقعی دوام می‌آورند؟ این پرسش هسته مرکزی ساخت یک ربات جاروبرقی مبتنی بر Raspberry Pi 5 است که اکنون به عنوان بستری برای بررسی «شکاف شبیه‌ساز به واقعیت» (Sim-to-Real Gap) عمل می‌کند؛ یکی از دشوارترین مسائل در حوزه رباتیک.

طبق یک گزارش مهندسی مفصل که در ۷ اوت ۲۰۲۶ منتشر شد، این سیستم برای رقابت با جاروبرقی‌های تجاری طراحی نشده، بلکه هدف آن اعتبارسنجی انتقال بحرانی از محیط‌های مجازی به فیزیکی است. اکثر پروژه‌های رباتیک آماتور هنگام خروج از محیط دیجیتال شکست می‌خورند، زیرا نرم‌افزار آن‌ها برای فیزیک ایده‌آل شبیه‌ساز بهینه‌سازی شده است. این پروژه با اعمال یک مرز معماری سخت‌گیرانه از این تله می‌گریزد تا گره‌های ناوبری، مکان‌یابی و کنترل هرگز نفهمند که در حال صحبت با یک پلاگین Gazebo هستند یا یک درایور موتور فیزیکی.

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

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

زیرساخت سخت‌افزاری

طراحی شاسی ربات از صفر می‌تواند به یک مسیر بی‌پایان و زمان‌بر تبدیل شود. جای‌گذاری چرخ‌ها، تعیین مرکز جرم، هندسه چرخ‌های کمکی (Caster) و نصب موتورها می‌تواند هفته‌ها زمان توسعه را پیش از نوشتن حتی یک خط کد ناوبری ببلعد. توسعه‌دهنده برای جلوگیری از این اتلاف وقت، مدل CAD یک جاروبرقی — که از نظر بصری مشابه Xiaomi Mi Robot Vacuum است — را از GrabCAD گرفت و وارد Onshape کرد.

از آنجا، فضای داخلی برای جای دادن یک Raspberry Pi 5، یک بسته باتری متناسب با بودجه توان مصرفی واقعی، و نقاط نصب برای RPLIDAR و IMU تغییر یافت. این شاسی دایره‌ای با سیستم رانش تفاضلی (Differential Drive) و یک چرخ کمکی پشتی، هندسه‌ای است که به‌طور گسترده مستند شده است. هر آموزش Nav2 و پلاگین ros2_control برای رانش تفاضلی، چیزی شبیه به این هندسه را فرض می‌کند و این به توسعه‌دهنده اجازه داد تا به جای اختراع مجدد شاسی‌ای که هزاران مهندس پیش از او حل کرده‌اند، بر روی پشته نرم‌افزاری تمرکز کند.

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

مشخصات فنی سخت‌افزار

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

• پردازش: Raspberry Pi 5
• سنجش فاصله: RPLIDAR (لیدار دوبعدی صفحه‌ای)
• سنجش اینرسی: IMU برای تعیین جهت و جهت‌گیری
• اودومتری: انکودرهای چرخ روی هر دو موتور رانش
• عمق: Intel RealSense (به عنوان گزینه اختیاری؛ برای اودومتری بصری آینده و برنامه‌ریزهای محلی یادگیرنده)
• عملگرها: رانش تفاضلی با دو چرخ محرک، یک چرخ کمکی پشتی، یک موتور جارو و یک موتور برس
• تغذیه: BMS سفارشی و مدار شارژ
• شاسی: پلتفرم دایره‌ای فرم-خلاء (اصلاح‌شده در Onshape)

معماری نرم‌افزار و لایه انتزاعی

سیستم روی Ubuntu 24.04 با استفاده از ROS 2 Jazzy و Gazebo Harmonic اجرا می‌شود. حیاتی‌ترین تصمیم طراحی، استفاده از ros2_control است. با پیاده‌سازی یک SystemInterface برای ربات واقعی و یک پلاگین Gazebo برای شبیه‌ساز، توسعه‌دهنده تفاوت‌ها را تنها در یک فایل Xacro محصور کرده است.

این یعنی پشته سطح بالا — شامل Navigation2 (Nav2)، SLAM Toolbox و robot_localization — در هر دو محیط یکسان باقی می‌ماند. لایه رابط سخت‌افزاری، مرز انتزاعی است. هر چیزی بالای این خط — از برنامه‌ریز، نقشه‌های هزینه (Costmaps)، فیلتر EKF و درخت‌های رفتاری — فقط داده‌های /scan ، /imu ، /odom ، /cmd_vel و /tf را می‌بیند بدون اینکه بداند منبع آن‌ها کجاست.

برای بهره‌وری حداکثری، تفکیک زبانی دقیقی صورت گرفته است:

• C++: برای بخش‌های حساس به عملکرد، از جمله حلقه‌های کنترل، فیلترینگ پیام‌ها و رابط‌های سخت‌افزاری سفارشی ros2_control.
• Python: برای ارکستراسیون، شرایط منطقی سنگین در درخت‌های رفتاری، ماشین‌های وضعیت (State Machines) و اسکریپت‌های ابزاری.

ساختار URDF و Xacro

برای مدیریت نسخه‌های شبیه‌سازی‌شده و فیزیکی، توصیفات ربات به جای یک فایل URDF واحد و یکپارچه، به فایل‌های Xacro ماژولار تقسیم شده‌اند. ساختار به شرح زیر سازماندهی شده است:

• vacuum_bot.urdf.xacro: فایل سطح بالا که تمام زیر-ماژول‌ها را فراخوانی می‌کند.
• base.xacro: تعریف شاسی، چرخ‌های کمکی و خواص اینرسی.
• wheels.xacro: تعریف مفاصل و لینک‌های چرخ‌های محرک.
• lidar.xacro و imu.xacro: تعریف نقاط نصب و فریم‌های سنسورها.
• ros2_control.xacro: شامل تگ‌های رابط سخت‌افزاری و یک سوئیچ برای انتخاب بین شبیه‌ساز و واقعیت.

در فایل ros2_control.xacro یک آرگومان Xacro به نام use_sim وجود دارد که پلاگین سخت‌افزاری را کنترل می‌کند. اگر مقدار آن true باشد، gz_ros2_control/GazeboSimSystem بارگذاری می‌شود؛ اگر false باشد، vacuum_bot_hardware/VacuumBotSystemHardware بارگذاری شده و پورت سریال (مثلاً /dev/ttyUSB0) مشخص می‌گردد. تمام هندسه لینک‌ها، محدودیت‌های مفاصل و تانسورهای اینرسی در هر دو حالت یکسان باقی می‌مانند.

حل لرزش مکان‌یابی

یکی از چالش‌های فنی اصلی، پایداری مکان‌یابی بود. تست‌های اولیه نشان داد که انتشار مستقیم داده‌های SLAM به لینک پایه (base link) باعث لرزش شدید و مشهود ربات روی سطوح فرش‌شده می‌شود. این اتفاق به این دلیل رخ می‌داد که اودومتری خام چرخ‌ها نویزی است و اصلاحات تطبیق لیدار با فرکانس بالا در حال مبارزه با این نویز بود.

برای حل این مشکل، یک ساختار مکان‌یابی دو لایه پیاده شد:
۱. تلفیق EKF: گره EKF در robot_localization داده‌های اودومتری انکودر چرخ را با داده‌های IMU ترکیب می‌کند تا یک تبدیل odom $ \rightarrow $ base_link نرم و بدون لرزش ایجاد کند.
۲. اصلاح SLAM: ابزار SLAM Toolbox (که در حالت async آنلاین اجرا می‌شود) یا AMCL، اصلاحات map $ \rightarrow $ odom را فراهم می‌کنند.

این جداسازی باعث شد SLAM Toolbox پیش‌فرض بسیار نرم‌تری برای اصلاح داشته باشد که تأثیری نامتناسب و بسیار مثبت بر کیفیت نقشه نهایی گذاشت.

واقعیت‌های ادغام سنسورها

ادغام سنسورها در عمل سخت‌تر از آنچه شبیه‌ساز پیشنهاد می‌داد بود. توسعه‌دهنده اشاره کرد که قرارداد فریم (Frame Convention) درایور RPLIDAR با نصب فیزیکی مطابقت نداشت و نیاز به یک اصلاح ۱۸۰ درجه‌ای در محور Yaw داشت. این موضوع ابتدا به اشتباه به عنوان خطای پیکربندی SLAM تشخیص داده شد، زیرا نقشه حاصل به‌صورت آینه‌ای و چرخان ظاهر می‌شد.

همگام‌سازی زمانی و سینک شدن داده‌ها نیز چالش‌برانگیز بود. IMU و انکودرها با نرخ‌های متفاوتی داده می‌فرستند و EKF نسبت به کوواریانس نویز فرآیند در رابطه با این نرخ‌ها حساس است. یک پیکربندی اولیه که بیش از حد به IMU اعتماد داشت، منجر به رانش جهت (Drift) در هنگام چرخش خالص در جایگاه شد؛ جایی که در واقع اودومتری چرخ‌ها قابل‌اعتمادتر از بایاس ژیروسکوپ IMU است.

علاوه بر این، پروژه خطر «تنظیمات خیالی» (Fantasy Tuning) را برجسته می‌کند. سنسورهای پیش‌فرض Gazebo بیش از حد ایده‌آل هستند. برای مقابله با این موضوع، توسعه‌دهنده نویز گوسی (Gaussian Noise) را به لیدار و IMU شبیه‌سازی‌شده اضافه کرد تا با دیتاشیت‌های سخت‌افزاری مطابقت یابد. این کار باعث شد تنظیمات تورم نقشه هزینه (Costmap Inflation) و کوواریانس EKF از همان ابتدا واقع‌بینانه باشند.

ناوبری و درخت‌های رفتاری

Nav2 با برنامه‌ریز محلی DWB و برنامه‌ریز جهانی NavFn پیکربندی شده است. سیستم از یک مجموعه گره‌های مدیریت‌شده با چرخه حیات (Lifecycle-managed) شامل سرور کنترلر، سرور برنامه‌ریز، سرور رفتار و ناوبری BT استفاده می‌کند.

به دلیل شاسی دایره‌ای با ارتفاع کم، رفتارهای بازیابی (Recovery Behaviors) در XML درخت رفتاری تعدیل شدند. در حالی که چرخش در جایگاه یک بازیابی امن است، عقب‌گرد در یک اتاق شلوغ به دلیل میدان دید محدود در پشت ربات و ارتفاع کم نصب سنسورها، ریسک بالایی دارد.

پارامترهای کلیدی در nav2_params.yaml عبارتند از:

• controller_frequency: ۲۰.۰ هرتز
• max_vel_x: ۰.۲۶ متر بر ثانیه (به‌طور عمدی محافظه‌کارانه برای در نظر گرفتن تراکشن کمتر روی فرش واقعی در مقایسه با اصطکاک ایده‌آل شبیه‌ساز)
• max_vel_theta: ۱.۰ رادیان بر ثانیه
• xy_goal_tolerance: ۰.۱۵ متر

سازماندهی پکیج‌ها به عنوان مهندسی

برای جلوگیری از «درهم‌تنیدگی»، فضای کاری به پکیج‌های مجزا بر اساس مسئولیت تقسیم شده است. این کار مانع از آن می‌شود که هزینه‌های یک ساختار تخت (Flat Structure) ماه‌ها بعد هنگام تعویض قطعات ظاهر شود:

• vacuum_bot_description: شامل URDF، Xacro و مش‌ها.
• vacuum_bot_bringup: ارکستراسیون سطح بالا و فایل‌های لانچ.
• vacuum_bot_hardware: رابط ros2_control دنیای واقعی (فقط برای ربات واقعی).
• vacuum_bot_gazebo: فایل‌های محیط (World)، لانچ‌های مخصوص شبیه‌ساز و تنظیمات نویز سنسور.
• vacuum_bot_navigation: پارامترهای Nav2 و XML درخت رفتاری.
• vacuum_bot_localization: تنظیمات EKF و پارامترهای SLAM Toolbox.
• vacuum_bot_msgs: پیام‌های سفارشی برای وضعیت باتری و وضعیت داک.

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

گردش‌کار عیب‌یابی: TF، rqt و Rosbag

بیشتر زمان پروژه صرف عیب‌یابی‌های خسته‌کننده شده است. توسعه‌دهنده بر روی یک مجموعه ابزار خاص تکیه می‌کند:

• tf2_tools view_frames: برای تولید PDF از درخت TF، که مشکل فریم آینه‌ای لیدار را سریع‌تر از RViz شناسایی کرد.
• rqt_graph: برای تایید اینکه بازتعریف (Remap) تاپیک‌ها در گراف بزرگ گره‌های Nav2 واقعاً اعمال شده است.
• Rosbags: یک سیاست سخت‌گیرانه برای ضبط هر اجرای سخت‌افزاری و شبیه‌سازی تا اطمینان حاصل شود که شکست‌های جالب برای تحلیل ثبت شده‌اند.
• RViz2: استفاده از پرسپکتیوهای ذخیره‌شده برای زمینه‌های مختلف (ساخت نقشه SLAM، بازرسی نقشه هزینه و بررسی‌های TF).

مسیر ادغام با هوش مصنوعی

اگرچه سیستم فعلی کلاسیک است، هدف بلندمدت جایگزینی برنامه‌ریز محلی DWB با یک مدل یادگیرنده است. این به‌طور صریح یک پروژه «اول-هوش-مصنوعی» نیست؛ پشته سنتی به دلیل قابلیت عیب‌یابی و عدم نیاز به داده‌های آموزشی، ستون فقرات سیستم باقی می‌ماند.

پرسش پژوهشی محدود است: آیا یک برنامه‌ریز محلی که از طریق یادگیری تقلیدی (Imitation Learning) در برابر مسیرهای DWB یا از طریق یادگیری تقویتی در Gazebo آموزش دیده، می‌تواند ناوبری در محیط‌های شلوغ و پویا را بهبود بخشد؟ این رویکرد در واقع تقابلی است میان استفاده از یادگیری تقویتی در برابر منطق صلب برای حل مسائل پیچیده تصمیم‌گیری متوالی در محیط‌های متغیر. به‌ویژه در عبور از درها و شکاف‌های تنگ بین مبلمان که امتیازدهی مسیر DWB اغلب بیش از حد محافظه‌کار می‌شود.

برای پشتیبانی از این هدف، «تصادفی‌سازی دامنه» (Domain Randomization) در نظر گرفته شده است — یعنی تصادفی کردن ضرایب اصطکاک، نویز سنسور و نورپردازی در طول اپیزودهای آموزشی تا سیاست آموخته شده در برابر فیزیک یک دنیای واحد در Gazebo شکننده نباشد.

زیرساخت ابری برای ارزیابی

جالب است که اتونومی ربات کاملاً روی دستگاه (On-device) است و ابزارهای ابری فقط برای چرخه توسعه استفاده می‌شوند:

• ذخیره‌سازی: نگهداری لاگ‌های Gazebo و Rosbags برای مقایسه‌های تکرارپذیر شبیه‌ساز به واقعیت.
• Container Registry: تضمین اینکه ایمیج دقیق فضای کاری ROS 2 قابل بازسازی است.
• CI Pipeline: ساخت پکیج‌ها و اجرای تست‌های واحد هنگام Push برای شناسایی خطاها پیش از تست روی سخت‌افزار.

تحلیل: تغییر پارادایم رباتیک

این پروژه نشان‌دهنده تغییری به سمت مهندسی «اول-شبیه‌ساز» است که با شکاف Sim-to-Real به عنوان یک معیار قابل اندازه‌گیری برخورد می‌کند، نه به عنوان یک غافلگیری. با تبدیل رابط سخت‌افزاری به یک پلاگین قابل تعویض، توسعه‌دهنده هزینه تکرار را از ساعت‌ها (تست فیزیکی) به ثانیه‌ها (شبیه‌سازی) کاهش می‌دهد.

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

گام‌های بعدی

نقطه عطف فوری، اولین پاس مپینگ فیزیکی SLAM روی Raspberry Pi 5 است. گردش‌کار مورد نظر اکنون به مراحل نهایی می‌رود:
۱. استقرار پشته بدون تغییر ROS 2 روی ربات فیزیکی.
۲. اندازه‌گیری مستقیم شکاف Sim-to-Real (لغزش چرخ روی کف سخت در مقابل فرش، رانش مکان‌یابی و زمان‌بندی حلقه کنترل روی Pi 5).
۳. بازگرداندن این اندازه‌گیری‌ها به دقت شبیه‌ساز و تنظیم کنترلر.
۴. ادغام RealSense به عنوان سیگنال ثانویه برای مکان‌یابی و اجتناب از موانع.
۵. پیاده‌سازی تشخیص خودکار داک شارژ و رفتار اتصال به داک.

گام بعدی شما

• بررسی مستندات ros2_control برای پیاده‌سازی لایه‌های انتزاعی در پروژه‌های رباتیک شخصی.
• مطالعه مفهوم Domain Randomization برای کاهش اثر شکاف Sim-to-Real در مدل‌های یادگیری تقویتی.
• آزمایش ترکیب EKF و SLAM Toolbox برای حذف لرزش‌های مکان‌یابی در ربات‌های متحرک.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و پردازش لبه مراجعه کنید.