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