سناریوی پروژه
این پروژه تمام زنجیره Robot State → TF/Odometry → SLAM → Map → Planner → Command را در محیط امن شبیه‌سازی کنار هم می‌گذارد.
این پروژه Capstone مسیر است؛ یعنی قرار نیست فقط چند مرحله را تیک بزنی. باید نشان بدهی می‌توانی چیزی که در ماژول‌های قبل یاد گرفتی را به یک سیستم قابل تست تبدیل کنی، خطا را پیدا کنی و تصمیم طراحی را با شواهد توضیح بدهی.
هدف‌های مهندسی
- اجرای Nodeهای اصلی و مشاهده Topicها.
- ساخت نقشه از محیط شبیه‌سازی.
- ارسال Goal و مشاهده مسیر/رفتار Navigation.
وسایل و پیش‌نیازهای اجرایی
- کامپیوتر Linux
- ROS2
- شبیه‌ساز سازگار مثل Gazebo
- پکیج ربات نمونه
- حداقل ۸GB RAM پیشنهادی
قبل از شروع، نسخه ابزارها، مدل قطعات و محدودیت‌هایی که ممکن است نتیجه را عوض کنند ثبت کن. اگر قطعه جایگزین استفاده می‌کنی، تفاوتش را هم بنویس.
روش اجرای پیشنهادی
پروژه را به یک‌باره Integrate نکن. این ترتیب را حفظ کن:
- Baseline: کوچک‌ترین بخش قابل تست را مستقل بالا بیاور.
- Interface test: ارتباط بین دو بخش را جدا بررسی کن.
- Integration: بخش‌ها را یکی‌یکی اضافه کن، نه همزمان.
- Fault test: یک خطای واقعی ایجاد یا شبیه‌سازی کن و Recovery را ببین.
- Repeatability: سناریوی اصلی را چند بار با شرایط مشابه اجرا کن.
- Review: نتیجه را با معیارهای Deliverable مقایسه کن و فقط بعد از آن پروژه را Complete کن.
Definition of Done
- فایل Map ذخیره‌شده.
- Screenshot یا Log از Navigation موفق.
- نمودار Topic/TFهای اصلی.
این موارد «شرح کار» نیستند؛ معیار پایان پروژه هستند. برای هر مورد باید یک شاهد داشته باشی: عدد، Log، عکس، ویدئوی کوتاه، فایل طراحی یا نتیجه چند Run.
جدول تست پیشنهادی
| Run | شرایط شروع | تغییر/نسخه | نتیجه | Pass/Fail | نکته |
|---|---|---|---|---|---|
| 1 | حالت پایه | نسخه A | … | … | … |
| 2 | همان شرایط | نسخه A | … | … | … |
| 3 | یک محدودیت سخت‌تر | نسخه A | … | … | … |
اگر Runها تفاوت زیادی دارند، قبل از بهینه‌سازی سرعت یا ظاهر، دلیل نبود تکرارپذیری را پیدا کن.
عیب‌یابی بدون حدس
وقتی پروژه کار نمی‌کند، آخرین جایی را پیدا کن که می‌دانی درست کار می‌کند. از همان نقطه به جلو Interfaceها را یکی‌یکی تست کن. همزمان چند چیز را تغییر نده. یک Failure log کوتاه نگه دار:
- علامت خطا چه بود؟
- در چه شرایطی تکرار شد؟
- فرض اصلی چه بود؟
- چه تستی فرض را رد یا تایید کرد؟
- تغییر نهایی چه بود و آیا دوباره تست شد؟
ایمنی و حفاظت از تجهیزات
- این پروژه نرم‌افزاری است؛ اگر بعدا روی ربات واقعی اجرا شد، سرعت اولیه را محدود کن و E-stop داشته باش.
ایمنی را بخشی از طراحی بدان، نه کاری که بعد از ساخت اضافه شود. در پروژه‌های متحرک همیشه فضای تست کنترل‌شده و روش توقف سریع داشته باش؛ در پروژه‌های الکتریکی قبل از تغییر سیم‌کشی تغذیه را قطع کن.
گزارش نهایی تیم
در یادداشت پروژه فقط ننویس «کار کرد». حداقل این چهار مورد را ثبت کن:
- نسخه نهایی سخت‌افزار/کد/فایل طراحی.
- نتیجه چند تست و معیار قبولی.
- یک Failure واقعی و مسیر پیدا کردن علت.
- یک تصمیمی که اگر پروژه را دوباره شروع می‌کردی عوض می‌کردی.
Challenge اختیاری
وقتی نسخه پایه پایدار شد، فقط یک محدودیت را سخت‌تر کن: زمان کمتر، نویز بیشتر، وزن بیشتر، شبکه ضعیف‌تر، نور متفاوت یا بار بیشتر. دوباره همان Test Plan را اجرا کن و ببین Margin طراحی چقدر است.