تا اینجا فرض کردیم ARCHO یک کامپیوتر واحد دارد که همهچیز — از Nav2 تا کنترل موتور — را اجرا میکند. در دنیای واقعی، این فرض بهندرت درست است. یک بازوی رباتیک واقعی معمولاً از سهلایه سختافزاری متفاوت تشکیل شده که هرکدام برای کار خودشان بهینهاند.
کنترل موتور به یک حلقه Real-Time بسیار سریع و قابلپیشبینی نیاز دارد — مثلاً هزار بار در ثانیه. یک کامپیوتر Linux معمولی که همزمان Nav2، SLAM و پردازش تصویر اجرا میکند، نمیتواند این تضمین زمانی را بدهد. به همین دلیل معماریهای صنعتی، کنترل موتور را از پردازش سنگین جدا میکنند.
NVIDIA Jetson برای کارهای پردازشی سنگین طراحی شده:
بهتر است Jetson فرمانهای سطح بالا (مثل سرعت هدف) را از طریق CAN، Ethernet یا Serial به یک میکروکنترلر جدا بفرستد، نه اینکه خودش مستقیماً درایور موتور را کنترل کند.
Jetson
│
▼
CAN / Ethernet / Serial
│
▼
Microcontroller
│
▼
Motor Drivers| نکته مهم Jetson | چرا اهمیت دارد |
|---|---|
| توان و خنککاری | پردازش سنگین گرمای زیادی تولید میکند و نیاز به خنککننده مناسب دارد |
| فضای ذخیرهسازی | مدلهای AI و Logها میتوانند حجم زیادی بگیرند |
| نسخه JetPack | سازگاری درایورها و کتابخانهها به نسخه JetPack بستگی دارد |
| سازگاری CUDA | هر مدل AI با نسخه خاصی از CUDA تست شده |
| راهاندازی خودکار Nodeها | بعد از قطعی برق، سیستم باید بدون دخالت انسان دوباره بالا بیاید |
| Log Rotation | بدون آن، دیسک بهمرور پر میشود |
| Watchdog و محدودیت حرارتی | از overheating و freeze شدن سیستم جلوگیری میکند |
Raspberry Pi برای کارهای سبکتر مناسب است:
| مناسب برای | محدود برای |
|---|---|
| LiDAR Driver | مدلهای AI سنگین |
| Sensor Gateway | چند دوربین عمقسنج همزمان |
| ROS Bridge | Visual SLAM سنگین |
| کنترل سطح متوسط، Telemetry | |
| رباتهای آموزشی سبک |
Raspberry Pi
│
├── ROS 2
├── LiDAR Driver
├── IMU Driver
├── robot_localization
└── Basic Nav2ESP32 معمولاً یک ROS 2 کامل مثل کامپیوتر اجرا نمیکند. دو مسیر رایج برای اتصال آن به دنیای ROS 2 وجود دارد:
micro-ROS همان مفاهیم آشنای ROS 2 — Publisher، Subscriber، Service، Timer — را به میکروکنترلرها میآورد. اما چون منابع MCU (RAM، Flash، CPU، شبکه) بسیار محدودتر از یک کامپیوتر است، معماری کامل ROS 2 را نباید عیناً روی آن کپی کرد.
| وظایف مناسب ESP32 | وظایف نامناسب ESP32 |
|---|---|
| خواندن Encoder | SLAM |
| PID سرعت موتور | Nav2 |
| خواندن سنسورهای ساده | پردازش Point Cloud |
| Watchdog | مدلهای هوش مصنوعی بزرگ |
| فرمان ترمز و کنترل چراغ | |
| ارسال Telemetry |
اگر ESP32 برای مدت مشخصی (مثلاً ۳۰۰ میلیثانیه) هیچ فرمان جدیدی از لایه بالاتر دریافت نکند، باید خودش تصمیم بگیرد که فرمان موتور را صفر کند و ترمز بگیرد — بدون اینکه منتظر دستور از Jetson یا Raspberry Pi بماند. اگر لایه بالاتر (به هر دلیلی، حتی کرش نرمافزار) قطع شود، ARCHO نباید با آخرین فرمان دریافتی به حرکت ادامه دهد.
No command for 300 ms
↓
Motor command = 0
↓
Brakeاین یکی از مهمترین اصول ایمنی در هر ربات صنعتی واقعی است — و چون بهقدری حیاتی است، باید مستقل از کل معماری نرمافزاری بالادستی روی همان میکروکنترلر پیاده شود.
در یک نسخه صنعتی ARCHO با بازوی برداشت: Jetson مسئول Nav2، تشخیص جسم با AI، دوربین و SLAM بصری است. این تصمیمهای سطح بالا از طریق یک لینک ارتباطی (CAN یا Serial) به یک میکروکنترلر (ESP32 یا STM32) فرستاده میشوند که خودش مستقیماً Encoder را میخواند، حلقه PID موتور را میبندد، Watchdog را اجرا میکند و به دکمه Emergency Stop واکنش نشان میدهد — کاملاً مستقل از اینکه Jetson سالم است یا نه.
| لایه | مسئولیت اصلی |
|---|---|
| Jetson | پردازش سنگین: AI، Perception، SLAM بصری، Nav2 |
| Raspberry Pi | Gateway یا پردازش سبک: LiDAR Driver، Telemetry |
| MCU (ESP32/STM32) | کنترل Real-Time: Encoder، PID، Watchdog، Emergency Stop |
حالا میدانی چرا یک ARCHO واقعی بهندرت روی یک کامپیوتر واحد اجرا میشود. پردازش سنگین (Jetson)، Gateway سبک (Raspberry Pi) و کنترل Real-Time بیواسطه موتور (ESP32 با Watchdog مستقل) هرکدام نقش متفاوتی دارند و این تفکیک، هم عملکرد را بهتر میکند و هم ایمنی سیستم را تضمین میکند.
پروژه ARCHO اکنون یک معماری سختافزاری سهلایه دارد: Jetson برای Nav2 و AI، یک ESP32 با Watchdog مستقل برای کنترل مستقیم موتور و Encoder.
در فصل هفدهم به شبکههای صنعتی میرویم که این لایهها را واقعاً به هم متصل میکنند: CAN Bus و EtherCAT.