سناریوی پروژه
یک مسیر کوتاه با مانع یا خط تعریف کن و ربات را مجبور کن سناریو را در زمان مشخص انجام دهد. هدف اصلی سرعت خام نیست؛ تکرارپذیری، قابلیت عیب‌یابی و آمادگی تیم است.
این پروژه Capstone مسیر است؛ یعنی قرار نیست فقط چند مرحله را تیک بزنی. باید نشان بدهی می‌توانی چیزی که در ماژول‌های قبل یاد گرفتی را به یک سیستم قابل تست تبدیل کنی، خطا را پیدا کنی و تصمیم طراحی را با شواهد توضیح بدهی.
هدف‌های مهندسی
- ساخت رباتی که یک سناریوی مشخص را چند بار با نتیجه نزدیک تکرار کند.
- تهیه Test Plan و چک‌لیست روز مسابقه.
- ثبت خطاها و اصلاح نسخه قبل از اجرای نهایی.
وسایل و پیش‌نیازهای اجرایی
- شاسی ربات
- دو موتور گیربکس‌دار
- درایور موتور
- باتری مناسب
- Arduino یا ESP32
- حداقل دو سنسور
- مولتی‌متر
- قطعات یدکی پایه
قبل از شروع، نسخه ابزارها، مدل قطعات و محدودیت‌هایی که ممکن است نتیجه را عوض کنند ثبت کن. اگر قطعه جایگزین استفاده می‌کنی، تفاوتش را هم بنویس.
روش اجرای پیشنهادی
پروژه را به یک‌باره Integrate نکن. این ترتیب را حفظ کن:
- Baseline: کوچک‌ترین بخش قابل تست را مستقل بالا بیاور.
- Interface test: ارتباط بین دو بخش را جدا بررسی کن.
- Integration: بخش‌ها را یکی‌یکی اضافه کن، نه همزمان.
- Fault test: یک خطای واقعی ایجاد یا شبیه‌سازی کن و Recovery را ببین.
- Repeatability: سناریوی اصلی را چند بار با شرایط مشابه اجرا کن.
- Review: نتیجه را با معیارهای Deliverable مقایسه کن و فقط بعد از آن پروژه را Complete کن.
Definition of Done
- سه اجرای متوالی با نتیجه ثبت‌شده.
- جدول تست و خطاها.
- نسخه کد و چک‌لیست نهایی تیم.
این موارد «شرح کار» نیستند؛ معیار پایان پروژه هستند. برای هر مورد باید یک شاهد داشته باشی: عدد، Log، عکس، ویدئوی کوتاه، فایل طراحی یا نتیجه چند Run.
جدول تست پیشنهادی
| Run | شرایط شروع | تغییر/نسخه | نتیجه | Pass/Fail | نکته |
|---|---|---|---|---|---|
| 1 | حالت پایه | نسخه A | … | … | … |
| 2 | همان شرایط | نسخه A | … | … | … |
| 3 | یک محدودیت سخت‌تر | نسخه A | … | … | … |
اگر Runها تفاوت زیادی دارند، قبل از بهینه‌سازی سرعت یا ظاهر، دلیل نبود تکرارپذیری را پیدا کن.
عیب‌یابی بدون حدس
وقتی پروژه کار نمی‌کند، آخرین جایی را پیدا کن که می‌دانی درست کار می‌کند. از همان نقطه به جلو Interfaceها را یکی‌یکی تست کن. همزمان چند چیز را تغییر نده. یک Failure log کوتاه نگه دار:
- علامت خطا چه بود؟
- در چه شرایطی تکرار شد؟
- فرض اصلی چه بود؟
- چه تستی فرض را رد یا تایید کرد؟
- تغییر نهایی چه بود و آیا دوباره تست شد؟
ایمنی و حفاظت از تجهیزات
- باتری و سیم‌های موتور را قبل از هر تست بررسی کن.
- هنگام تست حرکت، فضای آزاد و کلید قطع سریع داشته باش.
ایمنی را بخشی از طراحی بدان، نه کاری که بعد از ساخت اضافه شود. در پروژه‌های متحرک همیشه فضای تست کنترل‌شده و روش توقف سریع داشته باش؛ در پروژه‌های الکتریکی قبل از تغییر سیم‌کشی تغذیه را قطع کن.
گزارش نهایی تیم
در یادداشت پروژه فقط ننویس «کار کرد». حداقل این چهار مورد را ثبت کن:
- نسخه نهایی سخت‌افزار/کد/فایل طراحی.
- نتیجه چند تست و معیار قبولی.
- یک Failure واقعی و مسیر پیدا کردن علت.
- یک تصمیمی که اگر پروژه را دوباره شروع می‌کردی عوض می‌کردی.
Challenge اختیاری
وقتی نسخه پایه پایدار شد، فقط یک محدودیت را سخت‌تر کن: زمان کمتر، نویز بیشتر، وزن بیشتر، شبکه ضعیف‌تر، نور متفاوت یا بار بیشتر. دوباره همان Test Plan را اجرا کن و ببین Margin طراحی چقدر است.