‏تكامل INS مع ROS2 للمنصات الروبوتية ذاتية التشغيل من الجيل الجديد

لماذا يلزم تكامل INS مع ROS2 للروبوتات ذاتية التشغيل؟

تحتاج الروبوتات ذاتية التشغيل إلى معلومات مستمرة وموثوقة عن الموضع والسرعة والوضعية من أجل التموضع وتخطيط المسار والتحكم. وقد لا يوفّر GNSS وحده ملاحة دون انقطاع بسبب حجب الإشارة أو التداخل أو بيئات انقطاع GNSS.

يتيح دمج INS مع ROS2 للروبوتات ما يلي:

1. تقدير مستمر للموضع والسرعة والوضعية

2. الحفاظ على الملاحة أثناء انقطاعات GNSS المؤقتة

3. إجراء الملاحة التقديرية (dead reckoning) في ظروف انقطاع GNSS

4. دمج بيانات INS مع GNSS وLiDAR والكاميرات وقياسات المسافة (odometry)

5. تزويد منظومة الاستقلالية والتحكم في ROS2 ببيانات ملاحة عالية المعدل
   

يجمع Pollux 3 بين C-SWaP منخفض جدًا وملاحة عالية الأداء، ما يجعله مناسبًا جدًا للمنصات الروبوتية ذاتية التشغيل المدمجة.

تشمل القدرات الرئيسية:

1. تصميم فائق الصغر وخفيف الوزن ومنخفض الاستهلاك للطاقة (SWaP منخفض)

2. دقة عالية في الوضعية والاتجاه

3. تقدير دقيق للموضع والسرعة

4. ملاحة تقديرية موثوقة في ظروف انقطاع GNSS

5. مخرجات ملاحة بمعدل 200 Hz، وبيانات IMU حتى 1000 Hz

6. مشغّل ROS2 مخصص لتبسيط التكامل

7. GNSS متعدد الكوكبات مدمج ودمج مستشعرات قائم على EKF

8. مصمم للطائرات المسيّرة والمركبات الأرضية غير المأهولة والروبوتات

9. سلسلة توريد مضمونة

10. مؤهل للاستخدام العسكري (MIL) / بدرجة حماية IP65 عند الاقتضاء
    

وخلاصة القول إن ROS2 يوفّر إطار الاستقلالية، بينما يوفّر Pollux 3 العمود الفقري الموثوق للملاحة في المنصات الروبوتية ذاتية التشغيل.

لماذا تهم دقة الملاحة في الروبوتات ذاتية التشغيل

تعتمد الأنظمة ذاتية التشغيل الحديثة على عدة مستشعرات للتموضع والإدراك. ولكل من الكاميرات وLiDAR ومرمّزات العجلات حدودها.

ويسدّ نظام الملاحة بالقصور الذاتي هذه الفجوات بتقدير ما يلي باستمرار:

1. الموضع

2. السرعة

3. الاتجاه

4. السرعة الزاوية

5. التسارع

عندما يتوافر GNSS، يدمج Pollux 3 تحديد الموضع بالأقمار الصناعية مع القياسات القصورية عبر خوارزميات متقدمة لدمج المستشعرات، ليقدّم بيانات ملاحة سلسة وموثوقة حتى أثناء انقطاعات GNSS المؤقتة.

وهذا يمكّن الروبوتات من الحفاظ على تموضع مستقر في البيئات المتغيرة والصعبة.

مشغّل Pollux 3 ROS2

صُمّم مشغّل Pollux 3 ROS2 بوصفه عقدة بدورة حياة مُدارة (managed lifecycle node) ومكوّنًا قابلًا للتركيب (composable component). وهو ينشر مواضيع ROS2 المتوافقة مع REP-103 وREP-105 وREP-145، ما يتيح التوافق مع حزم ROS2 الشائعة دون الحاجة إلى برمجيات وسيطة مخصصة. وإلى جانب مواضيع ROS2 القياسية، يتيح المشغّل أيضًا تدفقات بيانات Aeron الخام للمستخدمين المتقدمين وأغراض التشخيص.

الميزات الرئيسية

يوفّر مشغّل ROS2 ما يلي:

1. تكامل INS المدعوم بـ GNSS

2. بنية العقدة ذات دورة الحياة

3. مكوّنات ROS2 القابلة للتركيب

4. الامتثال لـ REP-103 وREP-105 وREP-145

5. مواضيع ROS2 القياسية والخام

6. جودة خدمة (QoS) قابلة للضبط

7. تشخيصات ومراقبة صحة مدمجة

8. خدمات معايرة الجهاز

9. دعم TF الثابت والديناميكي

10. اتصال تسلسلي متين مع إعادة اتصال تلقائية

11. بيانات إسناد خارجية عبر عقدة ROS2 لدعم الإسناد على متن المنصة.

تتيح هذه القدرات للمطورين دمج Pollux 3 بكفاءة في الأنظمة الروبوتية ذاتية التشغيل مع الحفاظ على موثوقية تدفق البيانات والتشخيص.

متوافق مع أبرز أطر الملاحة في ROS2

صُمّم مشغّل Pollux 3 ROS2 ليتكامل مع أطر الملاحة الشائعة في ROS2، ومنها:

1. robot_localization

2. Nav2

3. navsat_transform_node

ولأن المشغّل يلتزم بمعايير REP في ROS2، يستطيع المطورون استخدام هذه الأطر دون طبقات وصل إضافية، ما يقلل زمن التكامل وتعقيده.

كيف تدمج نظام الملاحة بالقصور الذاتي (INS) مع ROS2 للروبوتات ذاتية التشغيل؟

يستطيع المطورون دمج Pollux 3 بسرعة في مساحة عمل ROS2 باستخدام بنية المستودع المقدَّمة وسير عمل الاستخراج الجزئي (sparse checkout) وعملية البناء بـ colcon. وتدعم الحزمة توزيعتَي ROS2 Humble وJazzy، وتتضمن حزم عرض توضيحية لتصوير RViz وGazebo.

تطبيقات فعلية - يناسب Pollux 3:

1. ملاحة الطائرات المسيّرة

2. المركبات الأرضية ذاتية القيادة (UGV)

3. الروبوتات المتنقلة ذاتية التشغيل (AMR)

4. روبوتات المستودعات

5. روبوتات التعدين

6. الروبوتات الدفاعية

7. الروبوتات الزراعية

8. روبوتات التوصيل

9. روبوتات الفحص
   
   

لماذا يختار مهندسو الروبوتات Pollux 3

يجمع Pollux 3 بين ملاحة قصورية عالية الأداء وتكامل سلس مع ROS2، ما يمكّن فرق الهندسة من تسريع التطوير مع الحفاظ على دقة الملاحة.

وبدلًا من استثمار موارد هندسية ثمينة في تكامل مستشعرات مخصص، يستطيع المطورون نشر حل ملاحة جاهز للإنتاج ومتوافق مع منظومة ROS2 الأوسع.

سواء كنت تبني روبوتات ذاتية التشغيل أو طائرات مسيّرة أو مركبات أرضية غير مأهولة (UGV) أو أنظمة أتمتة صناعية، يوفّر Pollux 3 الأداء والموثوقية والمرونة اللازمة للمنصات ذاتية التشغيل من الجيل الجديد.

هل أنت مستعد لتسريع تطوير ROS2 لديك؟

اكتشف كيف يمكن لـ Pollux 3 تبسيط تكامل الملاحة في تطبيقك الروبوتي ذاتي التشغيل.

الخطوات التالية:

1. اطلب عرضًا حيًّا للمنتج.

2. نزّل ورقة بيانات Pollux 3.

3. اطّلع على وثائق مشغّل ROS2.

4. تواصل مع فريق الهندسة في Aeron Systems للحصول على دعم التكامل.

Aeron Pollux 3: دليل تكامل ROS2

تُدخل حزمة aeron_pollux_driver نظام الملاحة بالقصور الذاتي PLX3 إلى ROS2 بوصفه مكوّنًا من الدرجة الأولى: مواضيع مستشعرات متوافقة مع المعايير، وعقدة بدورة حياة مُدارة، وتشخيصات مدمجة، ووصولًا إلى الحزم الخام للمستخدمين المتقدمين. يقودك هذا الدليل من الصندوق المغلق إلى نظام PLX3 يغذّي منظومة الملاحة لديك. وللاطلاع على المرجع الكامل للمعاملات والمواضيع والخدمات، راجع دليل المستخدم الكامل في المستودع.

ما تحصل عليه: مواضيع sensor_msgs/ nav_msgs قياسية جاهزة للاستخدام مع robot_localization وNav2 وRViz؛ ومجموعة كاملة من حزم PLX3 الخام معاد نشرها بوحدات الإرسال للتسجيل والمقدِّرات المخصصة؛ وبثًّا ثابتًا لـ TF مدفوعًا بالمعاملات لوحدة IMU وهوائي GNSS؛ وخدمات وقت التشغيل للمعايرة والتحكم بالجهاز؛ وثماني مهام تشخيص على /diagnostics.

1. إعداد العتاد

يبثّ PLX3 عبر RS232/UART. صِله بالمضيف عبر محوّل RS232 إلى USB فيظهر بوصفه جهازًا تسلسليًا، يكون عادةً /dev/ttyUSB0. وخطوتان لمرة واحدة على المضيف تمنعان أكثر أعطال التشغيل الأول شيوعًا:

أذونات المنفذ التسلسلي. أضف المستخدم الخاص بك إلى المجموعة dialout، ثم سجّل الخروج والدخول من جديد:

sudo usermod -aG dialout $USER

اسم جهاز ثابت. /dev/ttyUSB* قد يتغير ترقيمه بعد إعادة التشغيل. ثبّت اسمًا ثابتًا إما بقاعدة udev التي تأتي مع الحزمة (تربط محوّلك برابط رمزي إلى /dev/aeron_pollux وهي الأفضل للروبوت المنشور) أو بالمسار المدمج في النواة /dev/serial/by-id/... (دون sudo، ويعمل تحت WSL2). ويجب أن تطابق قاعدة udev معرّفات USB للمحوّل، لأن PLX3 يقع خلفه. راجع دليل المستخدم §1.1 للأوامر الدقيقة.

2. التثبيت

ARN_DRIVERS مستودع موحّد (monorepo)، لذلك يجلب الاستخراج الجزئي (sparse checkout) حزمة PLX3 فقط بدلًا من كل مشغّلات Aeron:

cd ~/ros2_ws/src 

git clone --filter=blob:none --sparse https://github.com/aeron-systems/ARN_DRIVERS.git

cd ARN_DRIVERS

git sparse-checkout set ROS2/pollux3/v01.00/aeron_pollux_driver

يتتبع colcon المجلد src/ تلقائيًا للعثور على الحزمة، فلا حاجة إلى رابط رمزي. بعد ذلك حلّ التبعيات وابنِ من جذر مساحة العمل:

cd ~/ros2_ws 

sudo rosdep init      #first time on this machine only (harmless warning if already done)

rosdep update

rosdep install --from-paths src -y --ignore-src
 
colcon build --packages-up-to aeron_pollux_driver

source install/setup.bash

للتحديث لاحقًا، يكفي تنفيذ git pull داخل ARN_DRIVERS ليحدّث الحزمة المستخرجة فقط.

3. بدء سريع

#Launch (auto-configures+auto-activates)
 
ros2 launch aeron_pollux_driver aeron_driver.launch.py \
    
device_path:=/dev/aeron_pollux baud_rate:=921600 

#Watch data and confirm health 

ros2 topic echo /imu/data 

ros2 topic echo /navsat/fix 

ros2 topic echo /diagnostics 

ros2 run rqt_runtime_monitor rqt_runtime_monitor

إذا لم يكن المنفذ موجودًا أو كان معدل الباود خاطئًا، تبقى العقدة غير مهيّأة وتسجّل السبب. تحقق من وحدة التحكم أولًا.

يُضبط معدل الإخراج على الجهاز لا في المشغّل. اضبط معدلات الحزم الخاصة بـ Pollux 3 في واجهة Aeron Connect Suite قبل النشر، ثم اضبط data_rate_hz في المشغّل ليطابقها كي يعرف تشخيص المعدل ما يتوقعه. لمزيد من المعلومات، راجع قسم AICS في دليل مستخدم Pollux 3 INS.

4. عقدة دورة الحياة

المشغّل عقدة بدورة حياة مُدارة وهذا بالضبط ما تريده على روبوت يقرر فيه منسّق متى تعمل المستشعرات. وهو ينتقل unconfigured → inactive → active: تتحقق مرحلة configure من المعاملات وتفتح المنفذ وتبثّ إطارات TF الثابتة (دون بيانات بعد)؛ وتبدأ مرحلة activate خيط الإدخال والإخراج فتتدفق البيانات. ويؤدي ملف الإطلاق المرفق المرحلتين معًا. ولتحكم بالانتقالات بنفسك (اختبار التشغيل الأولي أو التنسيق الخارجي)، أطلق باستخدام auto_configure:=false auto_activate:=false واستخدم ros2 lifecycle set /ins_driver <transition>. والعقدة مسجّلة أيضًا بوصفها مكوّنًا قابلًا للتركيب لمشاركة العملية مع بقية خط المعالجة لديك.

5. ما الذي يُنشر

المواضيع القياسية: تستهلكها مباشرة حزم ROS2 الجاهزة، وكلها بنظام ENU/FLU ووحدات SI:

/imu/data (sensor_msgs/Imu)، /imu/mag، /imu/temperature، /imu/pressure، /imu/velocity (التواء في إطار الجسم، غير مشروط بـ GNSS)، /navsat/fix و/navsat/status (دائمًا RELIABLE كي لا تفوّت حزم الملاحة أي تحديد للموضع)، /navsat/ecef، /odom (الحل المدمج لنظام PLX3)، /time_reference، /tf + /tf_static، و/diagnostics.

مواضيع الحزم الخام: كل حزمة أصلية من Pollux 3 بوحدات الإرسال، للتسجيل والمقدِّرات المخصصة: /aeron/nav_fused, /aeron/nav_extended, /aeron/sensors, /aeron/gnss_extended, /aeron/gnss, /aeron/device_info, /aeron/status, /aeron/calib_progress.

تستخدم مواضيع /aeron/* أنواعًا مخصصة هي aeron_pollux_driver/msg/*، لذلك نفّذ تحميل غلاف مساحة العمل (source install/setup.bash) قبل تنفيذ ros2 topic echo عليها. ويوجد المرجع الكامل لكل حقل وتفاصيل QoS في دليل المستخدم §6.

يُخرج Pollux 3 بيانات قصورية معايَرة فقط، ولا يوجد تدفق IMU خام (imu/data_raw).

6. الإعدادات التي يجب ضبطها

كل الإعدادات معاملات ROS2 عادية. والمسار الدائم هو ملف YAML للمعاملات يُمرَّر عند الإطلاق (params_file:=your.yaml)؛ ويمكن أيضًا ضبط المعاملات القابلة للتغيير أثناء التشغيل مباشرة بـ ros2 param set. وهناك أمران يجب على كل مُدمِج ضبطهما.

▸ تحويلات التركيب

يبثّ المشغّل تحويلين ثابتين من معاملاتك: base_link → imu_link (وضعية INS) وbase_link → gnss_link (ذراع الرافعة للهوائي). والإزاحات بالأمتار، في إطار الجسم وفق REP-103: x للأمام وy لليسار وz للأعلى:

/**:  
ros__parameters:    
mounting_translation:             # base_link → INS
x:  0.12         #12 cm forward      
y: -0.04         #4 cm right (y is left-positive)  
z:  0.18         #18 cm up    
mounting_rotation:           # only if the INS is physically rotated     
roll: 0.0      
pitch: 0.0      
yaw: 0.0    
gnss_mounting_translation:    # base_link → antenna      
x: -0.20      
y:  0.00      
z:  1.20

تحقق بتنفيذ ros2 run tf2_ros tf2_echo base_link imu_link. وهناك قاعدتان: هذه المعاملات هندسة على جانب ROS فقط (لا تُرسل أبدًا إلى INS، بل تخبر العقد اللاحقة بمكان وجود المستشعرات)، وينبغي تطبيق كل إزاحة فيزيائية مرة واحدة فقط، إما في الجهاز أو في ROS2، وليس في الاثنين معًا.

▸ تباينات القياس (Covariances)

يأتي المشغّل بتباينات مؤقتة متحفظة، فأعد ضبطها لتناسب منصتك. وتلتقط أداة مساعدة مرفقة جميع المستشعرات بينما يبقى الروبوت ساكنًا وتطبع قيمًا جاهزة بصيغة YAML:

ros2 run aeron_pollux_driver estimate_variances.py 60 > measured_vars.yaml

استخدم الحد الأدنى المقاس مباشرة للجيروسكوب ومقياس التسارع ومقياس المغنطة. وعامِل orientation_variance في حالة السكون بوصفه حدًّا أدنى فقط، وخذه من ورقة البيانات أو من الاختبار الديناميكي بدلًا من ذلك. أما تباين موضع GNSS فلا يحتاج إلى ضبط: إذ يملؤه المشغّل افتراضيًا مباشرة من الدقة التي يبلّغ عنها PLX3 نفسه.

7. الدمج مع منظومة الملاحة لديك

PLX3 نظام INS كامل: فهو يدمج بياناته القصورية وبيانات GNSS على متنه وينشر حل ملاحة كاملًا. وعلى خلاف IMU مجردة مع مستقبِل GNSS، لا تحتاج إلى مقدِّر على جانب المضيف للحصول على الوضعية، فالتقدير يجري فعلًا على الجهاز.

▸ الموصى به: استهلاك الحل المدمج مباشرة

غذِّ منظومة الملاحة لديك (مثل Nav2) بـ /odom بوصفه مصدر التموضع، واترك المشغّل يملك التحويل odom → base_link:

ros2 param set /ins_driver publish_tf true

/odom ينشر وضعية ENU محلية مثبّتة عند أول تحديد للموضع بـ GNSS، ثم يستمر عبر الانقطاعات اللاحقة بفضل الملاحة التقديرية في PLX3. وهو مشروط بـ GNSS: فيبقى صامتًا إلى أن يُحصَل على أول تحديد للموضع (انظر §5). وهذا هو المسار الصحيح لأغلب التكاملات والتطبيقات. navsat_transform_node يمكنه أيضًا استهلاك /navsat/fix مباشرة إذا احتجت إلى إطار خريطة مرجعي جغرافيًا؛ وهو يستخدم ذراع الرافعة المبثوثة base_link → gnss_link لإسناد التحديد إلى base_link.

▸ اختياري: المزج مع قياس مسافة العجلات أو مستشعرات محلية أخرى

إذا كانت منصتك تحتوي على مرمّزات عجلات أو مصادر محلية أخرى تريد دمجها مع INS، يمكنك تشغيل مرشّح على جانب المضيف مثل ekf_node من robot_localization: وانتبه إلى أنها حزمة ROS تعمل على حاسوبك وليست وضعًا في Pollux 3. ويمكنك أيضًا تغذية INS ببيانات عدّاد مسافة خارجي مباشرة عبر بروتوكول الاتصال الثنائي من Aeron. ولأن الجهاز يُخرج حلًّا مدمجًا أصلًا، فاعتبر أيًّا من المسارين خيارًا مقصودًا لا الأصل، وتجنّب إعادة دمج معلومات سبق لـ INS أن دمجها. والتوصيل المعتاد يغذّي المرشّح بالاتجاه والسرعات الزاوية والتسارع من INS مع قياس مسافة العجلات، ويُبقي publish_tf في المشغّل على قيمته الافتراضية false، فيملك المرشّح الخارجي odom → base_link:

ekf_filter_node:                      # robot_localization (host-side) — not a Pollux 3 mode               
    ros__parameters:    
        imu0: /imu/data    
        imu0_config: [false, false, false,       # x, y, z              
                      true,  true,  true,        # roll, pitch, yaw              
                      false, false, false,       # vx, vy, vz
                      true,  true,  true,        # vroll, vpitch, vyaw
                      true,  true,  true]        # ax, ay, az

      imu0_remove_gravitational_acceleration: true     # Pollux 3 outputs specific force (REP-145)

يجوز لناشر واحد فقط أن يملك odom → base_link. فإذا كان مرشّح خارجي يملكه، فأبقِ publish_tf في المشغّل على false؛ وإذا كان المشغّل يملكه، فلا تشغّل مرشّحًا منافسًا. وجود ناشرين على التحويل نفسه علة معروفة في TF.

وللعمل بلا GNSS تمامًا، يواصل حل INS الملاحة التقديرية بمفرده أو يدمج إسنادًا خارجيًا إن توافر؛ ويمكنك أيضًا دمج /imu/data و/imu/velocity (وكلاهما غير مشروط بـ GNSS) في مقدِّرك الخاص. وكل اسم موضوع وخدمة قابل لإعادة التعيين (--ros-args -r imu/data:=/vehicle/imu، أو قائمة remappings=[...] في ملف الإطلاق الخاص بك)، كما يضيف الإطلاق بـ namespace:=<prefix> بادئة إلى كل شيء دفعة واحدة.

8. المعايرة والتشغيل

معايرة مقياس المغنطة، عند تغيّر البيئة المغناطيسية:

ros2 service call /calibrate_ins aeron_pollux_driver/srv/CalibrateIns   #START (default) 
ros2 topic echo /aeron/calib_progress                                   #rotate slowly about Z 
ros2 service call /reboot_device std_srvs/srv/Trigger                   #reboot to apply

يتوقف المشغّل ويحفظ تلقائيًا قرابة 100%؛ ولا تسري المعاملات الجديدة إلا بعد إعادة التشغيل.

التحقق من مشغّل قيد التشغيل. /diagnostics هو أول مكان تنظر فيه عند الشك بوجود خلل: فمهامه الثماني تبلّغ عن انقطاع الوصلة وحالات خطأ الباود (وصول بايتات دون فك ترميز) وتدهور GNSS ونمو الذاكرة. ويؤكد rqt_graph أن اتصالاتك بالعقد اللاحقة موجودة فعلًا.

الإيقاف النظيف مهم. المنفذ التسلسلي مورد حصري تديره النواة، لذلك أوقف المشغّل بضغطة Ctrl+C واحدة في طرفية الإطلاق، فتغلق دوال دورة الحياة المنفذ وتخرج بنظافة. أما الضغطة الثانية فتتصاعد إلى SIGTERM وتتخطى الدوال وقد تترك المنفذ مقفلًا (الرسالة "Device or resource busy" عند الإطلاق التالي). وتجد دليل الفحص والإيقاف الكامل في operations.md.

9. استكشاف الأعطال

10. المرجع والدعم

1. المرجع الكامل للمعاملات والمواضيع والخدمات: user_guide.md

2. دليل المشغّل (فحص مشغّل قيد التشغيل وإيقافه): operations.md

3. المصدر والمشكلات والإصدارات: github.com/aeron-systems/ARN_DRIVERS

4. إعداد الجهاز (معدلات الإخراج وذراع رافعة الهوائي وترميز الاتجاه): Aeron Connect Suite

5. الدعم: تواصل مع Aeron Systems مع ذكر إصدار المشغّل وتوزيعة ROS2 ولقطة من /diagnostics. وتُصدر حزمة aeron_pollux_driver بموجب ترخيص Apache-2.0.

استكشف صفحة منتج Pollux 3 للاطلاع على المواصفات التفصيلية والميزات الرئيسية وقدرات التكامل، أو تواصل مع خبرائنا لمناقشة متطلبات تطبيقك.

المؤلف: Vinayak Pundhir (مطوّر برمجيات مدمجة)