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