اعتباراً من Ubuntu 22.04 أو يونيو 2025، لم يعد الدعم الرسمي الأساسي يوفّر ترقيات لنظام ROS1، ويُوصى باستخدام نظام ROS2. يتميّز ROS2 في البنية المعمارية والزمن الحقيقي والأمان وقابلية التوسع البيئي بشكل ملحوظ عن ROS1. إذا كنت تبدأ مشروعاً جديداً، يُنصح باستخدام ROS2 مباشرة، أما إذا كنت بحاجة إلى الترحيل، فيجب الموازنة بين الموارد الحالية والمكاسب طويلة الأمد. للاطلاع على علاقة دعم إصدارات Ubuntu بالتفصيل، راجع الرابط. العلاقة بين ROS وإصدارات Ubuntu المختلفة، فيما يلي مقارنة بين الإطارين لتحليل:
| إصدار ROS 2 | إصدار Ubuntu | إصدار LTS أم لا | وقت الإصدار |
| جازي | 24.04 (Noble) | نعم (LTS) | 2024 |
| Kilted | 24.04 (Noble) | لا | 2025-05 |
التاريخ والتطور
- ROS1: طُوّر بواسطة جامعة ستانفورد وWillow Garage، مع التركيز على البحث والنماذج الأولية.
- ROS2: أُطلق في عام 2014، ويستهدف الروبوتات ذات المستوى الصناعي باستخدام وسيط DDS لتحسين قدرات الزمن الحقيقي، ودعم المنصات المتعددة، والأمان.
الخلاصة: ROS1 أكثر ملاءمة للبحث والنماذج الأولية، بينما ROS2 مثالي للنشر الصناعي والتجاري.
2. هيكلية النظام
| الأبعاد | ROS1 | ROS2 |
| الهيكلية الأساسية | تعتمد بنية مركزية، وتستند إلى عقدة Master (مدير العقد) لتحقيق تسجيل العقد والتواصل بينها. | بنية موزعة، تواصل مباشر بين العقد دون الحاجة إلى Master، مع دعم آلية الاكتشاف الديناميكي. |
| نموذج الاتصال | نظام اتصال مخصص يعتمد على بروتوكول TCP/UDP، ويعاني من مشاكل مثل التأخير، وفقدان الحزم، وعدم القدرة على التشفير. | بروتوكول تواصل معياري يعتمد على DDS، ويدعم الزمن الحقيقي والتشفير والتفاعل عبر المنصات. |
| الموثوقية | يعتمد على TCP للاتصال من نظير إلى نظير، وهو عرضة لفقدان الحزم. | يضمن النقل الموثوق عبر سياسات QoS (مثل Reliable). |
| نظام الترجمة | يستخدم نظامي rosbuild (في الإصدارات المبكرة) وcatkin للترجمة. | قدّم نظام ترجمة آلياً يدعم إدارة تبعيات أكثر مرونة وبناء متعدد اللغات. |
3. تجربة المستخدم
| الأبعاد | ROS1 | ROS2 |
| منحنى التعلم | موارد مجتمعية غنية وتوثيق ناضج، مناسب للمبتدئين. | الميزات الجديدة تزيد من تكلفة التعلم (مثل إعداد DDS، وتصحيح الأخطاء في الزمن الحقيقي)، لكنها أكثر قابلية للصيانة على المدى الطويل. |
| تكاليف الترقية | تحتاج مشاريع ROS 1 إلى إعادة هيكلة منطق التواصل وإدارة العقد ونظام الترجمة للانتقال إلى ROS 2. | تتوفر أدوات ترحيل (مثل ros1_bridge) للتواصل بين عقد ROS 1 وROS 2. |
| أدوات التصحيح وسلسلة الأدوات | يعتمد على أدوات مثل roslaunch وrviz، وعملية التصحيح أكثر تقليدية. | إطار عمل launch جديد (يدعم إعدادات Python)، ونظام تسجيل مدمج، وأدوات اختبار أفضل. |
| المجتمع والنظام البيئي | النظام البيئي كبير، لكن بعض الميزات يصعب توسيعها بسبب القيود المعمارية. | الميزات الجديدة أسهل في الدمج (مثل التكامل الأعمق مع Gazebo وتقنيات الويب)، والنظام البيئي في توسع مستمر. |
4. مقارنة التقنيات الرئيسية
| الأبعاد | ROS1 | ROS2 |
| اتصال العقد | يتم إنشاء الاتصال من نظير إلى نظير عبر تسجيل Master. | تكتشف العقد بعضها البعض وتتواصل مباشرة عبر DDS تلقائيًا. |
| الرسائل | يستخدم أنواع رسائل مخصصة (.msg)، ويعتمد على تنفيذ roscpp/rospy. | يولّد رسائل متعددة اللغات بناءً على IDL (لغة تعريف الواجهة) لتوافق أفضل. |
| تحمّل الأخطاء | قد يؤدي فشل Master إلى تعطل النظام بالكامل. | بنية موزعة تتجنب نقطة الفشل الواحدة، ويمكن للعقد الانضمام/المغادرة ديناميكيًا. |
5. الاختلافات في الصياغة
| الأبعاد | ROS1 | ROS2 |
| صياغة إنشاء العقد | يستخدم ros::NodeHandle لإدارة العقد، ويعتمد على roscore لتشغيل المدير المركزي. | يستخدم rclcpp::Node أو rclpy::Node لإنشاء العقد مباشرة دون الحاجة إلى roscore، ويدعم البنية الموزّعة. |
| آلية الاتصال | يعتمد على بروتوكول TCP/UDP مخصص لتحقيق التواصل، ويتطلب إدارة يدوية لتسجيل العقد واكتشافها. | يعتمد على معيار DDS (خدمة توزيع البيانات)، وتكتشف العقد بعضها البعض وتتواصل تلقائياً. |
| تعريف الرسائل | يستخدم ملف .msg لتعريف نوع الرسالة، ويعتمد على تنفيذ roscpp/rospy. | يستخدم IDL (لغة تعريف الواجهة) لتوليد رسائل متعددة اللغات لتوافق أفضل. |
| ملفات Launch | يستخدم XML لكتابة ملف .launch، بوظيفة واحدة، ويصعب إعداده ديناميكياً. | يستخدم Python لكتابة ملف .launch.py لدعم المنطق الديناميكي (مثل الأحكام الشرطية وتمرير المعاملات). |
6. الاختلافات في الاستخدام الفعلي
| الأبعاد | ROS1 | ROS2 |
| دعم اللغات المتعددة | يدعم بشكل أساسي C++ وPython؛ أما اللغات الأخرى فتحتاج إلى تكييف. | دعم موسّع للغات إضافية (مثل Rust وJava) وتوافق عبر اللغات عبر لغة تعريف الواجهة (IDL). |
| نظام الترجمة | يعتمد على نظام الترجمة catkin، ويتطلب الالتزام الصارم بهيكل مساحة العمل. | يستخدم نظام البناء ament لإدارة تبعيات أكثر مرونة وبناء متعدد اللغات. |
| دعم في الوقت الفعلي | أداء ضعيف في الزمن الحقيقي، ويصعب تلبية احتياجات التحكم الصناعي في الزمن الحقيقي. | يحسّن دعم الأنظمة في الزمن الحقيقي (مثل rclcpp في ROS 2 الذي يوفر جدولة خيوط في الزمن الحقيقي). |
| الأمن | يفتقر إلى آليات التشفير والمصادقة الأصلية. | يدعم امتدادات أمان DDS (DDS-Security) لتوفير المصادقة وتشفير البيانات والتحكم في الوصول. |
| دعم المنصات المتعددة | يعمل بشكل أساسي على أنظمة Linux، مع دعم محدود لنظامي Windows/macOS. | يدعم منصات متعددة مثل Linux وWindows وmacOS وRTOS وغيرها، ويقسم المنصات بوضوح إلى Tier 1 (مدعومة رسميًا) وTier 2 (مدعومة من المجتمع) لتعزيز التوافق عبر الأنظمة. |
| أدوات التصحيح | يعتمد على أدوات تقليدية مثل roslaunch وrviz، ونظام التسجيل بسيط نسبيًا. | يوفر نظام تسجيل مدمجاً (مثل RCLCPP_INFO)، ودعماً لسكربتات Python، وأدوات اختبار أفضل. |
| تحمّل الأخطاء | قد يؤدي فشل roscore إلى تعطل النظام بالكامل. | بنية موزعة تتجنب نقطة الفشل الواحدة، ويمكن للعقد الانضمام/المغادرة ديناميكيًا. |
7. سيناريوهات التطبيق النموذجية
- ROS 1: التعليم، المشاريع البحثية (مثل ملاحة الروبوتات المتنقلة، SLAM)، والسيناريوهات التي لا تتطلب زمن حقيقي أو أماناً عالياً. إذا كان المشروع ناضجاً ولا يتطلب ميزات الزمن الحقيقي أو الأمان أو المنصات المتعددة، ويعتمد على موارد بيئية كبيرة من ROS 1، فاستمر في استخدام ROS 1.
- ROS 2: الأتمتة الصناعية، القيادة الذاتية، الطائرات المسيّرة، وغيرها من السيناريوهات التي تتطلب زمن حقيقي وأماناً ودعماً عبر المنصات، بالإضافة إلى الصيانة طويلة الأمد للمشاريع واسعة النطاق (مثل توصيل الروبوتات، بما في ذلكالروبوتات الصناعية، والروبوتات الطبية). المشاريع التي تتطلب استقرارًا بمستوى صناعي، أو تحكمًا في الزمن الحقيقي، أو تشفيرًا آمنًا، أو نشرًا عبر منصات متعددة يُفضَّل استخدام ROS 2 لها.
8. توافق الأجهزة والمنصات
- يدعم بشكل أساسي Linux (Ubuntu).
- RO يدعم أصلاً Linux وWindows وmacOS والمنصات المدمجة.
9. النظام البيئي ودعم المجتمع
- ROS1: عدد كبير من الحزم ومجتمع نشط.
- ROS2: نظام بيئي سريع النمو، لكن عدد الحزم لا يزال في مرحلة اللحاق.
الخلاصة: يمتلك ROS1 نظامًا بيئيًا ناضجًا، بينما يلحق ROS2 به بسرعة.
10. تكاليف الترقية والانتقال
- واجهات البرمجة (APIs) غير متوافقة، مما يتطلب إعادة كتابة الكود.
- قد تحتاج برامج التشغيل إلى تكييف؛ ويمكن أن يساعد ros1_bridge في الترقية التدريجية.
الخلاصة: تكاليف الترحيل مرتفعة، لكن يمكن تقليل المخاطر عبر الترقية على مراحل.
11. معايير الأمن والصناعة
- ROS1: لا توجد آليات أمان أصلية.
- ROS2: يتوافق مع معايير أمان DDS، ويمكنه التكامل مع OPC UA وTSN.
الخلاصة: ROS2 أكثر ملاءمة للتطبيقات الحساسة للأمان والصناعية.
الاتجاهات المستقبلية وخارطة الطريق
- ROS1Noetic هو الإصدار النهائي، وسيتم صيانته حتى عام 2025.
- ROS2 يتبع استراتيجية الدعم طويل الأمد (LTS) مع تحديثات ميزات نشطة.
الخلاصة: الاتجاه واضح لصالح ROS2.
الخلاصة والتوصيات
For الباحثون أو المبتدئون، يبقى ROS1 خيارًا ناضجًا ومستقرًا؛ أما المستخدمون الصناعيون أو الفرق التجارية، فإن مزايا ROS2 في الأنظمة الموزعة، والزمن الحقيقي، والأمان تحقق قيمة طويلة الأجل.
نصائح عملية: قيّم إصدار ROS مبكرًا في تخطيط المشروع، واتخذ القرار بناءً على نضج النظام البيئي وقدرات الفريق.
