مسیر یادگیری ROS 2  ·  کتاب آموزشی تصویری

فصل هجدهم: از شبیه‌سازی تا ARCHO واقعی

مرحله‌ای که همه‌چیز ناگهان واقعی می‌شود
پیش‌نیاز: فصل ۷ تا ۱۷
پروژه پیوسته: ARCHO فیزیکی
تمرکز: Bringup، کالیبراسیون، ایمنی
زمان مطالعه: ۱۳۰ تا ۱۵۰ دقیقه
در این فصل چه می‌خوانیم ۱۸.۱چه چیزی تغییر می‌کند، چه چیزی نه ۱۸.۲ترتیب Bringup روی سخت‌افزار واقعی ۱۸.۳Preflight Checklist ۱۸.۴تست چرخ‌ها و حرکت Open Loop ۱۸.۵کالیبراسیون Wheel Radius و Wheel Separation ۱۸.۶تست توقف: یک لایه ایمنی کافی نیست ۱۸.۷راه‌اندازی خودکار با systemd ۱۸.۸Logging و Observability ۱۸.۹شکاف Simulation-to-Reality ۱۸.۱۰جمع‌بندی، واژه‌نامه و تمرین‌ها

۱۸.۱چه چیزی تغییر می‌کند، چه چیزی نه

این فصل جمع‌بندی همه فصل‌های قبلی است: خبر خوب این است که وقتی از Gazebo به سخت‌افزار واقعی ARCHO می‌روی، بیشتر معماری‌ای که ساختی دست‌نخورده می‌ماند.

flowchart LR subgraph SIM["شبیه‌سازی"] A1["ros2_control"] --> A2["gz_ros2_control"] --> A3["Virtual Joints"] end subgraph REAL["ربات واقعی"] B1["ros2_control"] --> B2["Custom Hardware Interface"] --> B3["CAN / Serial / EtherCAT"] --> B4["Motor Drivers"] end style A1 fill:#eef0ff,stroke:#3d4bf5 style B1 fill:#eef0ff,stroke:#3d4bf5
لایهتغییر می‌کند؟
Nav2، SLAM، Controllersخیر
نام‌گذاری TF، URDFخیر
Topicهای سطح بالاخیر
Hardware Interface (لایه پایین‌ترین ros2_control)بله — این تنها قسمتی است که واقعاً عوض می‌شود
🧠 چرا این معماری این‌قدر ارزشمند است

دقیقاً به همین دلیل در فصل ۸ به‌قدر کافی روی جداسازی Hardware Interface از بقیه معماری تأکید کردیم. اگر آن جداسازی درست انجام شده باشد، انتقال از شبیه‌سازی به واقعیت فقط یک تعویض لایه پایینی است، نه بازنویسی کل سیستم.

۱۸.۲ترتیب Bringup روی سخت‌افزار واقعی

  1. تغذیه برق و ایمنی (Power and Safety)
  2. میکروکنترلر (MCU)
  3. درایورهای موتور
  4. سنسورها
  5. Hardware Interface
  6. robot_state_publisher
  7. robot_localization
  8. SLAM یا AMCL
  9. Nav2
  10. Mission Manager
⚠️ چرا ترتیب اهمیت دارد

دقیقاً همان دلیلی که در فصل ۱۲ درباره Lifecycle Nodes یاد گرفتی: اگر Nav2 قبل از آماده‌شدن Localization فعال شود، ممکن است تصمیم‌های خطرناکی بگیرد. این ترتیب Bringup، همان اصل را روی کل سیستم فیزیکی پیاده می‌کند.

۱۸.۳Preflight Checklist

قبل از هر حرکت اول ARCHO روی زمین واقعی:

  • Emergency Stop سالم و در دسترس است.
  • چرخ‌ها از زمین بلند نگه داشته شده‌اند (برای اولین تست).
  • جهت Encoder صحیح است.
  • جهت موتور صحیح است.
  • Current Limit تنظیم شده است.
  • Watchdog فعال است.
  • cmd_vel صفر است (قبل از شروع تست).
  • TF کامل است — هیچ فریمی گم نیست.
  • LiDAR داده معتبر منتشر می‌کند.
  • باتری سالم است.
  • محدوده تست فیزیکی خالی از افراد و مانع است.

۱۸.۴تست چرخ‌ها و حرکت Open Loop

مرحله اول: تست هر چرخ جداگانه

Command positive
      ↓
Wheel rotates forward?

اگر جواب منفی بود، این چهار مورد را به‌ترتیب بررسی کن: جهت موتور، جهت Encoder، علامت Command، و Mapping درایور.

مرحله دوم: تست Open Loop با سرعت‌های افزایشی

هرگز از سرعت بالا شروع نکن. ترتیب امن:

0.05 m/s
0.10 m/s
0.20 m/s
0.30 m/s

در هر مرحله، پیش از افزایش سرعت مطمئن شو ARCHO دقیقاً همان‌طور که انتظار داری حرکت می‌کند.

۱۸.۵کالیبراسیون Wheel Radius و Wheel Separation

کالیبراسیون شعاع چرخ

به ARCHO فرمان می‌دهی ۵ متر مستقیم برود، اما فاصله واقعی طی‌شده ۴.۸ متر است:

ضریب اصلاح = 5 / 4.8 = 1.0417
new_radius = old_radius × 1.0417

کالیبراسیون فاصله بین چرخ‌ها (Wheel Separation)

به ARCHO فرمان یک چرخش کامل می‌دهی، اما به‌جای ۳۶۰ درجه فقط ۳۳۰ درجه واقعاً می‌چرخد:

🔧 چرا این کالیبراسیون حیاتی است

این دقیقاً همان پارامترهایی هستند که در فصل ۸ در controllers.yaml برای diff_drive_controller تنظیم کردیم (wheel_radius، wheel_separation). اگر این مقادیر با هندسه واقعی ARCHO دقیقاً هم‌خوانی نداشته باشند، Odometry (فصل ۹) از همان ابتدا دچار خطای سیستماتیک می‌شود — و این خطا مستقیم به SLAM و Nav2 هم منتقل خواهد شد.

۱۸.۶تست توقف: یک لایه ایمنی کافی نیست

باید در تمام این شرایط تست کنی که ARCHO واقعاً متوقف می‌شود:

flowchart TB A["High-Level Command"] --> B["ROS Watchdog"] B --> C["MCU Watchdog"] C --> D["Motor Driver Enable"] D --> E["Mechanical / Electrical Brake"] style B fill:#fdeeec,stroke:#d64a3c style C fill:#fdeeec,stroke:#d64a3c
⚠️ یک لایه ایمنی کافی نیست

یادت هست در فصل ۱۶ روی Watchdog مستقل روی ESP32 تأکید کردیم؟ اینجا دلیلش کاملاً روشن می‌شود: اگر فقط به Watchdog سطح ROS تکیه کنی و همان کامپیوتری که ROS روی آن اجرا می‌شود کرش کند، هیچ لایه‌ای باقی نمی‌ماند که ARCHO را متوقف کند. ایمنی واقعی از تکرار (Redundancy) لایه‌ها می‌آید، نه از یک نقطه شکست واحد.

۱۸.۷راه‌اندازی خودکار با systemd

برای این‌که ARCHO بعد از هر قطعی برق یا ری‌استارت، بدون دخالت انسان دوباره بالا بیاید:

# /etc/systemd/system/archo-bringup.service
[Unit]
Description=ARCHO ROS 2 Bringup
After=network-online.target

[Service]
Type=simple
User=robot
ExecStart=/usr/local/bin/start_archo.sh
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target
#!/bin/bash
# /usr/local/bin/start_archo.sh
source /opt/ros/jazzy/setup.bash
source /home/robot/archo_ws/install/setup.bash
exec ros2 launch archo_bringup real_robot.launch.py

۱۸.۸Logging و Observability

وقتی ARCHO در انبار واقعی و بدون نظارت مستقیم کار می‌کند، باید بتوانی به این سؤال‌ها جواب بدهی:

ابزارکاربرد
rosbag2ضبط کامل داده برای بازپخش و تحلیل بعدی
diagnostic_msgsگزارش استاندارد سلامت هر زیرسیستم
/diagnosticsTopic مرکزی جمع‌آوری وضعیت سلامت
Prometheus یا مشابهمانیتورینگ متریک‌ها در طول زمان
Log Rotationجلوگیری از پرشدن دیسک
Health Heartbeatتشخیص سریع این‌که یک زیرسیستم از کار افتاده
ros2 bag record \
  /scan \
  /imu/data \
  /odometry/filtered \
  /tf \
  /tf_static \
  /diagnostics

۱۸.۹شکاف Simulation-to-Reality

حتی با بهترین شبیه‌سازی Gazebo (فصل ۷)، دنیای واقعی همیشه غافلگیرت می‌کند:

شبیه‌سازیواقعیت
زمین کامل و صافلغزش و ناهمواری
چرخ ایده‌آلسایش، اختلاف جزئی بین چرخ‌ها
نویز کنترل‌شدهنویز واقعی و پیش‌بینی‌نشدنی
تأخیر کم و ثابتتأخیر متغیر شبکه و سخت‌افزار
سنسور تمیزگردوغبار، نور مستقیم، بازتاب سطوح
🔧 چطور این شکاف را کم کنیم
  • نویز واقعی به سنسورهای شبیه‌سازی‌شده اضافه کن.
  • تأخیر واقعی شبکه و پردازش را شبیه‌سازی کن.
  • جرم و اینرسی واقعی قطعات را در URDF وارد کن (نه مقادیر تقریبی).
  • ضریب اصطکاک واقعی زمین انبار را کالیبره کن.
  • محدودیت سرعت و شتاب واقعی موتورها را اعمال کن.
  • Domain Randomization انجام بده — یعنی در هر اجرای شبیه‌سازی، پارامترها را کمی تصادفی تغییر بده تا سیستم به‌جای یک دنیای ثابت، برای طیفی از شرایط ممکن مقاوم شود.

۱۸.۱۰جمع‌بندی فصل هجدهم

ARCHO حالا از یک شبیه‌سازی Gazebo به یک ربات فیزیکی واقعی تبدیل شده — با ترتیب Bringup کنترل‌شده، Preflight Checklist کامل، چرخ‌های کالیبره‌شده، چند لایه ایمنی مستقل، راه‌اندازی خودکار با systemd و یک سیستم Logging که همیشه می‌گوید چرا اتفاقی افتاد.

✅ نقطه بازبینی یادگیری
  • می‌توانم بگویم چرا فقط Hardware Interface تغییر می‌کند، نه کل معماری.
  • می‌دانم چرا ترتیب Bringup اهمیت دارد.
  • می‌توانم فرآیند کالیبراسیون Wheel Radius و Wheel Separation را توضیح دهم.
  • می‌دانم چرا یک لایه ایمنی کافی نیست و ایمنی باید چندلایه باشد.
  • می‌توانم حداقل سه تفاوت مهم بین شبیه‌سازی و واقعیت را نام ببرم.
🌍 ارتباط با پروژه اصلی

پروژه ARCHO اکنون یک نسخه فیزیکی کاملاً کالیبره‌شده دارد که با systemd به‌طور خودکار راه‌اندازی می‌شود، rosbag2 برای عیب‌یابی ضبط می‌کند و از یک زنجیره ایمنی چندلایه برخوردار است.

فصل بعد چه چیزی اضافه می‌کند

در فصل نوزدهم به سراغ استانداردهای تولیدی سطح صنعتی می‌رویم: QoS، DDS، Diagnostics و معماری ایمنی — چیزهایی که یک پروژه را از «کار می‌کند» به «قابل‌اعتماد در تولید» می‌رسانند.

واژه‌نامه فصل هجدهم

Preflight Checklist
فهرست بررسی‌های ایمنی و فنی که باید پیش از هر حرکت اول ربات انجام شوند.
Open Loop Test
تست حرکت با افزایش تدریجی سرعت، بدون تکیه بر بازخورد کامل سیستم.
Wheel Radius Calibration
تصحیح شعاع مؤثر چرخ بر اساس فاصله واقعی طی‌شده در برابر فاصله مورد انتظار.
Redundancy (ایمنی چندلایه)
طراحی چند لایه مستقل ایمنی، تا شکست یک لایه باعث شکست کامل سیستم نشود.
systemd
مدیر سرویس لینوکس که برای راه‌اندازی خودکار و پایدار Bringup ربات استفاده می‌شود.
Domain Randomization
تکنیک تصادفی‌کردن پارامترهای شبیه‌سازی برای کاهش شکاف Sim-to-Real.

خطاهای رایج فصل هجدهم — جمع‌بندی

فصل هجدهم از کتاب «مسیر یادگیری ROS 2»
فصل بعد: QoS، DDS، Diagnostics و ایمنی صنعتی →