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

فصل نوزدهم: QoS، DDS، Diagnostics و معماری ایمنی

از «کار می‌کند» تا «قابل‌اعتماد در تولید»
پیش‌نیاز: فصل ۲ (Topic/Service/Action)، فصل ۱۸
پروژه پیوسته: ARCHO در محیط تولیدی
مفاهیم: DDS، QoS، Diagnostics، Safety Layers
زمان مطالعه: ۱۵۰ تا ۱۷۰ دقیقه
در این فصل چه می‌خوانیم ۱۹.۱DDS: قلب پنهان ارتباطات ROS 2 ۱۹.۲چرا QoS وجود دارد ۱۹.۳سیاست‌های QoS یکی‌یکی ۱۹.۴ناسازگاری QoS: وقتی Topic هست ولی داده نمی‌آید ۱۹.۵ROS_DOMAIN_ID و RMW ۱۹.۶مرور کامل: چه زمانی Topic، Service، Action یا Parameter ۱۹.۷Diagnostics: ARCHO باید بگوید سالم است یا نه ۱۹.۸معماری ایمنی چندلایه ۱۹.۹جمع‌بندی، واژه‌نامه و تمرین‌ها

۱۹.۱DDS: قلب پنهان ارتباطات ROS 2

از فصل ۲ تا اینجا، بارها با Topic، Service و Action کار کردیم بدون این‌که بپرسیم واقعاً پیام‌ها چطور از یک Node به Node دیگر می‌رسند. جواب این سؤال، یکی از مهم‌ترین تفاوت‌های ROS 2 با نسل قبلی‌اش (ROS 1) است: ROS 2 روی یک Middleware استاندارد صنعتی به‌نام DDS ساخته شده.

📖 DDS چه کارهایی را مدیریت می‌کند
  • Discovery — پیدا کردن خودکار Nodeهای دیگر روی شبکه
  • انتقال واقعی پیام‌ها
  • Quality of Service (QoS)
  • ارتباط بین Processهای مختلف روی یک کامپیوتر
  • ارتباط بین چند کامپیوتر مختلف
  • Serialization (تبدیل داده به فرمت قابل انتقال)
  • امنیت ارتباطی
flowchart TB A["ROS 2 Node"] --> B["rclcpp / rclpy"] --> C["rcl"] --> D["RMW"] --> E["DDS Implementation"] --> F["Network"] style D fill:#eef0ff,stroke:#3d4bf5 style E fill:#f4effe,stroke:#8b5cf6

۱۹.۲چرا QoS وجود دارد

🧠 همه داده‌ها ارزش یکسانی ندارند

اگر یکی از هزار اسکن LiDAR گم شود، معمولاً فاجعه‌ای رخ نمی‌دهد. اما اگر فرمان توقف اضطراری ARCHO گم شود، این می‌تواند خطرناک باشد. یک نقشه ممکن است دیر منتشر شود، اما هر Subscriber جدید باید بتواند آخرین نسخه‌اش را بگیرد — حتی اگر بعد از انتشار اولیه روشن شده باشد. به همین دلیل، یک رفتار ارتباطی ثابت برای همه پیام‌ها اصلاً منطقی نیست.

QoS (Quality of Service) دقیقاً همین را تنظیم می‌کند: هر Topic می‌تواند رفتار ارتباطی خودش را داشته باشد.

۱۹.۳سیاست‌های QoS یکی‌یکی

Reliability

حالترفتارمناسب برای
Reliableپیام حتماً باید تحویل داده شود؛ اگر بسته گم شود، دوباره تلاش می‌شودParameter Event، تنظیمات، فرمان‌های حساس غیر Real-time
Best Effortاگر پیام رسید خوب، اگر نرسید پیام بعدی می‌آیدCamera Stream، LiDAR، داده سنسور سریع، شبکه WiFi ضعیف

Durability

حالترفتار
VolatileSubscriber فقط پیام‌هایی را می‌گیرد که بعد از اتصالش منتشر شوند؛ پیام‌های قبلی را نمی‌بیند
Transient LocalPublisher آخرین داده را نگه می‌دارد تا Subscriberهای جدید هم بتوانند آن را بگیرند — مثلاً برای Map

History

حالترفتار
Keep Last (depth=N)فقط N پیام آخر نگه داشته می‌شود
Keep Allهمه پیام‌ها تا محدودیت منابع سیستم نگه داشته می‌شوند — می‌تواند حافظه زیادی مصرف کند

Deadline، Lifespan و Liveliness

سیاستمعنیمثال
Deadlineحداقل هر چند وقت یک‌بار باید پیام برسدLiDAR باید هر ۱۰۰ میلی‌ثانیه پیام بدهد؛ در غیر این‌صورت Deadline Missed گزارش می‌شود — بسیار مفید برای Health Monitoring
Lifespanپیام تا چه مدت معتبر استفرمان سرعت مربوط به ۵ ثانیه قبل دیگر نباید اجرا شود
Livelinessآیا Publisher هنوز زنده استاگر Publisher فرمان موتور از بین برود، سیستم می‌تواند فرمان را خودکار صفر کند

۱۹.۴ناسازگاری QoS: وقتی Topic هست ولی داده نمی‌آید

⚠️ یکی از سردرگم‌کننده‌ترین باگ‌های ROS 2

فرض کن LiDAR ARCHO با Best Effort منتشر می‌کند، اما یک Subscriber جدید فقط Reliable قبول می‌کند. نتیجه: ارتباط اصلاً تشکیل نمی‌شود یا رفتار مورد انتظار رخ نمی‌دهد — و نشانه‌اش این است که /scan در ros2 topic list دیده می‌شود، اما هیچ داده‌ای دریافت نمی‌شود.

dev@archo:~$ ros2 topic info /scan --verbose Publisher count: 1 QoS profile: Reliability: BEST_EFFORT Subscription count: 1 QoS profile: Reliability: RELIABLE

این دستور دقیقاً همان‌جایی است که ناسازگاری بین Publisher و Subscriber را پیدا می‌کنی.

۱۹.۵ROS_DOMAIN_ID و RMW

📖 ROS_DOMAIN_ID مثل یک کانال ارتباطی جداگانه است
export ROS_DOMAIN_ID=20

سیستم‌هایی با Domain ID متفاوت معمولاً یک ROS Graph مشترک نمی‌بینند. مثلاً یک آزمایشگاه می‌تواند Domain 10 و آزمایشگاه دیگر Domain 20 باشد تا ترافیک Discoveryشان با هم قاطی نشود.

⚠️ Domain ID یک مکانیزم امنیتی نیست

Domain ID فقط Discovery را جدا می‌کند، نه ارتباط را رمزنگاری یا محافظت می‌کند. اتکا به Domain ID یا رمز عبور WiFi برای امنیت واقعی کافی نیست — این موضوعی است که در فصل‌های بعدی درباره امنیت (اگر در ادامه مسیر پیش برویم) بیشتر بررسی می‌شود.

📖 RMW چیست

ROS Middleware — لایه‌ای است که ROS 2 را به یک پیاده‌سازی واقعی DDS (مثل Cyclone DDS یا Fast DDS) متصل می‌کند. همان‌طور که در نمودار بالا دیدیم، این لایه بین rcl و خود DDS قرار می‌گیرد و به ROS 2 اجازه می‌دهد بدون تغییر کد، بین چند پیاده‌سازی DDS مختلف سوییچ کند.

📖 جمله طلایی QoS

QoS تعیین نمی‌کند پیام چه داده‌ای داشته باشد؛ تعیین می‌کند آن داده چقدر قابل‌اعتماد، ماندگار، تازه و به‌موقع منتقل شود.

۱۹.۶مرور کامل: چه زمانی Topic، Service، Action یا Parameter

حالا که DDS و QoS را فهمیدی، وقت خوبی است که چهار نوع ارتباط اصلی ROS 2 (که در فصل ۲ و ۳ با آن‌ها کار کردیم) را یک‌جا مرور کنیم:

نوعمناسب برایمثال در ARCHO
Topicجریان پیوسته داده؛ Publisher لازم نیست بداند چه کسی گوش می‌دهدLiDAR Scan، IMU، Encoder، Battery Status، Camera Image
Serviceدرخواست و پاسخ سریع و کوتاه؛ برای کار طولانی مناسب نیستReset Odometry، Clear Fault، Enable Motor، Get Firmware Version
Actionکاری که زمان می‌برد و به Goal/Feedback/Result و Cancel نیاز داردNavigate to Pose، Dock Robot، Follow Waypoints، Calibrate Wheels
Parameterتنظیم رفتار یک Node؛ نامناسب برای داده سریع سنسورmax_velocity، wheel_radius، safety_distance، controller_frequency
flowchart TB Q1["داده پیوسته؟"] -->|بله| T["Topic"] Q2["درخواست فوری و کوتاه؟"] -->|بله| S["Service"] Q3["کار طولانی با Progress و Cancel؟"] -->|بله| A["Action"] Q4["تنظیمات یک Node؟"] -->|بله| P["Parameter"] style T fill:#eef0ff,stroke:#3d4bf5 style S fill:#eafaf3,stroke:#0e9e6e style A fill:#f4effe,stroke:#8b5cf6 style P fill:#fdf3e4,stroke:#c8862c

۱۹.۷Diagnostics: ARCHO باید بگوید سالم است یا نه

یک ربات صنعتی فقط نباید کار کند؛ باید بتواند به این سؤال جواب بدهد: «من سالم هستم یا نه؟»

وضعیت‌های سلامت

وضعیتمعنی
OKهمه‌چیز طبیعی است
WARNمشکلی هست ولی هنوز خطرناک نیست
ERRORخطای جدی رخ داده
STALEداده‌ای که از این جزء دریافت می‌کنیم دیگر به‌روز نیست

مثال یک لحظه از وضعیت ARCHO:

LiDAR:        OK
IMU:          OK
Battery:      WARN
Motor Driver: ERROR
Camera:       STALE

Health Manager

flowchart LR L["LiDAR Driver"] --> HM["Health Manager"] I["IMU Driver"] --> HM M["Motor Driver"] --> HM B["Battery Driver"] --> HM LO["Localization"] --> HM N["Nav2"] --> HM style HM fill:#3d4bf5,color:#fff

Health Manager بر اساس همه این ورودی‌ها تصمیم می‌گیرد: آیا مأموریت ادامه پیدا کند؟ آیا سرعت کم شود؟ آیا ARCHO کاملاً متوقف شود؟ آیا اپراتور مطلع شود؟

Heartbeat و Timeout سنسورها

📖 Heartbeat چیست

پیامی ساده که فقط می‌گوید «من هنوز زنده‌ام». مثلاً MCU هر ۵۰ میلی‌ثانیه یک Heartbeat می‌فرستد. اگر کامپیوتر اصلی برای ۳۰۰ میلی‌ثانیه Heartbeat نبیند، نتیجه می‌گیرد MCU قطع شده — دقیقاً همان اصل Watchdog که در فصل ۱۶ و ۱۸ دیدیم. 

now - last_scan_time > 0.5 second
      ↓
LiDAR Timeout
      ↓
Controller stop → Mission pause → Operator notification

شدت خطا (Fault Severity)

سطحمثال
InfoMap loaded
WarningBattery below 30%
Recoverable ErrorLiDAR temporarily unavailable
Critical ErrorMotor overcurrent، Emergency stop active

State Machine سلامت کلی سیستم

stateDiagram-v2 [*] --> BOOTING BOOTING --> INITIALIZING INITIALIZING --> READY READY --> RUNNING RUNNING --> DEGRADED DEGRADED --> RUNNING RUNNING --> FAULT DEGRADED --> FAULT FAULT --> RECOVERY RECOVERY --> READY

مثلاً اگر دوربین ARCHO از کار بیفتد اما Navigation بتواند فقط با LiDAR ادامه دهد، سیستم به حالت DEGRADED می‌رود — نه متوقف، اما با قابلیت کاهش‌یافته. اگر Encoder از کار بیفتد، این یک خطای جدی‌تر است و سیستم به FAULT می‌رود.

۱۹.۸معماری ایمنی چندلایه

⚠️ یک فرض اشتباه رایج

نباید فرض کنیم «چون Nodeهای ROS 2 سالم هستند، پس ربات ایمن است». نرم‌افزار ممکن است Crash کند، شبکه قطع شود، یک Topic اشتباه منتشر شود، CPU هنگ کند، یا یک فرمان قدیمی به‌اشتباه باقی بماند. به همین دلیل ایمنی واقعی نمی‌تواند فقط در یک لایه نرم‌افزاری باشد.

سه نوع Stop

نوعرفتار
Normal StopController سرعت را به‌آرامی به صفر می‌رساند
Protective Stopبه‌دلیل مشاهده انسان یا مانع خطرناک، توقف سریع اما کنترل‌شده
Emergency Stopقطع کاملاً سخت‌افزاری انرژی محرک‌ها — نباید فقط یک Topic نرم‌افزاری باشد

شش لایه ایمنی

flowchart TB L1["Layer 1: Nav2 Collision Avoidance"] --> L2["Layer 2: Software Safety Supervisor"] L2 --> L3["Layer 3: MCU Watchdog"] L3 --> L4["Layer 4: Motor Driver Protections"] L4 --> L5["Layer 5: Safety Relay / E-Stop Circuit"] L5 --> L6["Layer 6: Mechanical Brake"] style L1 fill:#eef0ff,stroke:#3d4bf5 style L6 fill:#fdeeec,stroke:#d64a3c
🧠 چرا شش لایه، نه یک لایه

اگر Layer 1 (اجتناب هوشمند از برخورد در Nav2) به هر دلیلی شکست بخورد، لایه‌های پایین‌تر همچنان باید بتوانند خطر را محدود کنند. این دقیقاً همان درسی است که در فصل ۱۸ درباره «یک لایه ایمنی کافی نیست» گرفتیم — اینجا آن اصل را به یک معماری کامل شش‌لایه تبدیل می‌کنیم.

Safety Supervisor

flowchart TB A["Nav2 cmd_vel"] --> S["Safety Supervisor"] S --> Q1["E-stop فعال؟"] S --> Q2["انسان خیلی نزدیک؟"] S --> Q3["Localization گم شده؟"] S --> Q4["Motor Fault؟"] S --> Q5["Command Timeout؟"] S --> O["safe_cmd_vel"] style S fill:#3d4bf5,color:#fff style O fill:#eafaf3,stroke:#0e9e6e

ورودی Safety Supervisor: cmd_vel، مناطق ایمنی LiDAR، Bumper، E-stop، خطاهای موتور، کیفیت Localization و وضعیت باتری. خروجی: safe_cmd_vel، motor_enable، protective_stop.

محدودیت سرعت منطقه‌ای

منطقهسرعت مجاز
فضای باز انبار۰.۸ متر بر ثانیه
نزدیک انسان۰.۳ متر بر ثانیه
محدوده Docking۰.۱ متر بر ثانیه

این محدودیت‌ها می‌توانند بر اساس نقشه، داده LiDAR زنده، موقعیت فعلی، نوع مأموریت و حضور انسان به‌صورت پویا تغییر کنند.

Bumper: آخرین لایه فیزیکی

flowchart LR A["Bumper Pressed"] --> B["Immediate Motor Stop"] --> C["Mission Cancel"] --> D["Reverse Only After Validation"] style A fill:#fdeeec,stroke:#d64a3c
⚠️ هرگز بلافاصله عقب نرو

وقتی Bumper فشرده می‌شود، ARCHO هرگز نباید بی‌درنگ و بدون بررسی خودکار عقب برود — ممکن است مانع یا حتی یک انسان درست پشت آن ایستاده باشد.

📖 جمله طلایی Safety

ایمنی واقعی یعنی حتی وقتی نرم‌افزار سطح بالا اشتباه می‌کند، سخت‌افزار و کنترل پایین‌دست اجازه ایجاد وضعیت خطرناک نمی‌دهند.

۱۹.۹جمع‌بندی فصل نوزدهم

ARCHO حالا نه‌تنها کار می‌کند، بلکه می‌داند چطور با شرایط نامطلوب شبکه کنار بیاید (QoS)، چطور بگوید کجای بدنش سالم نیست (Diagnostics)، و چطور حتی وقتی چیزی در نرم‌افزار اشتباه می‌رود، در برابر آسیب به خودش یا انسان‌های اطراف محافظت کند (معماری ایمنی چندلایه). این‌ها همان تفاوت‌هایی هستند که یک پروژه دانشجویی را از یک محصول صنعتی واقعی جدا می‌کنند.

✅ نقطه بازبینی یادگیری
  • می‌توانم تفاوت Reliable و Best Effort را با مثال توضیح دهم.
  • می‌دانم چرا Transient Local برای Map مناسب‌تر از Volatile است.
  • می‌توانم علامت رایج یک ناسازگاری QoS را تشخیص دهم و با چه دستوری بررسی‌اش کنم.
  • می‌دانم چرا ROS_DOMAIN_ID یک مکانیزم امنیتی نیست.
  • می‌توانم چهار وضعیت سلامت (OK/WARN/ERROR/STALE) را با مثال توضیح دهم.
  • می‌دانم چرا ایمنی باید در شش لایه مستقل طراحی شود، نه یک لایه.
🌍 ارتباط با پروژه اصلی

پروژه ARCHO اکنون یک Health Manager با چهار سطح وضعیت، یک Safety Supervisor با شش لایه ایمنی مستقل، و QoS Profileهای درست‌تنظیم‌شده برای هر نوع داده (سنسور سریع در برابر فرمان حیاتی) دارد.

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

در فصل بیستم — فصل پایانی این مسیر — همه چیزهایی که در این ۱۹ فصل ساختیم را کنار هم می‌گذاریم و معماری کامل صنعتی نهایی ARCHO را می‌بینیم.

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

DDS
Data Distribution Service؛ استاندارد Middleware زیرساخت ارتباطی ROS 2.
QoS (Quality of Service)
مجموعه سیاست‌هایی که رفتار قابلیت‌اطمینان، ماندگاری و به‌موقع‌بودن ارتباط یک Topic را تعیین می‌کنند.
RMW
ROS Middleware؛ لایه‌ای که ROS 2 را به یک پیاده‌سازی خاص DDS متصل می‌کند.
ROS_DOMAIN_ID
شناسه‌ای که Discovery چند سیستم ROS 2 مستقل را از هم جدا می‌کند.
Diagnostic Aggregator
سیستمی که وضعیت سلامت همه زیرسیستم‌ها را جمع‌آوری و خلاصه می‌کند.
Heartbeat
پیام دوره‌ای ساده که زنده‌بودن یک زیرسیستم را تأیید می‌کند.
Safety Supervisor
لایه نرم‌افزاری که فرمان نهایی حرکت را بر اساس شرایط ایمنی فیلتر می‌کند.
Protective Stop
توقف سریع اما کنترل‌شده به‌دلیل خطر آشکار، بین Normal Stop و Emergency Stop.

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

فصل نوزدهم از کتاب «مسیر یادگیری ROS 2»
فصل بعد: معماری نهایی صنعتی ARCHO (فصل پایانی) →