أبحاث روبوتات مختبر HCR

تسرد هذه المشاركة رحلتي في مجال الروبوتات، بدءًا من اكتشاف شغفي بالروبوتات في FRC خلال المدرسة الثانوية في 2015 وحتى وقت عملي كمساعد بحث في مختبر الروبوتات المتمحور حول الإنسان (HCR) بمدرسة كولورادو للمعادن من فبراير 2021 إلى سبتمبر 2021. لاحظ أنه منذ أواخر 2022، انتقل مختبر HCR من مدرسة كولورادو للمعادن إلى جامعة ماساتشوستس أمهرست، بالإضافة إلى موقعه من hcr.mines.edu إلى hcr.cs.umass.edu.

الخلفية

بدأت دراستي الجامعية في مدرسة كولورادو للمعادن في فصل خريف 2018. كان تخصصي علوم الحاسوب مع تركيز على الروبوتات والأنظمة الذكية. وتخرجت في ربيع 2022.

كنت محظوظًا لأنني وجدت شغفي مبكرًا في حياتي. خلال المدرسة الثانوية، قضيت وقتًا كبيرًا لأحدد ما أحب وما يمكن أن أكون جيدًا فيه. بعد بعض التجربة والخطأ، تمكنت من اكتشاف أن شغفي هو علوم الحاسوب. ولكن خلال هذا الوقت أيضًا اكتشفت أن لدي حبًا هائلًا للبناء عبر الشيفرة.

في معادن، حصلت على فرصة للعمل في مختبر الروبوتات المتمحور حول الإنسان (HCR) التابع للمعادن تحت إشراف الدكتور هاو تشانغ. التقيت بالدكتور تشانغ لأول مرة في ربيع 2020 من خلال صفه “الروبوتات المتمحورة حول الإنسان” (CSCI473)، وبعد فوضى كوفيد والعمل الدراسي، تمكنت من العمل في مختبره في أوائل ربيع 2021.

صف الروبوتات المتمحورة حول الإنسان (CSCI473)

كان صف الروبوتات المتمحورة حول الإنسان (CSCI473) في معادن أحد القليل من الصفوف في تجربتي الجامعية التي كان لها تأثير عميق عليّ. تم تدريس الصف بواسطة الدكتور هاو تشانغ. كان تقييمنا للصف يتكون من ثلاثة مشاريع فقط، كل منها قدم مشكلة تحديّة قدمت مفاهيم أساسية في الروبوتات. هذه المشاريع شملت:

1. تعلم نظام تشغيل الروبوت (ROS)
2. التعلم المعزز لتتبع جدار الروبوت
3. فهم الروبوت لسلوكيات البشر باستخدام تمثيلات قائمة على الهيكل العظمي

🧩 تعلم نظام تشغيل الروبوت (ROS)

كان هذا أول مشروع كُلفنا به. يتكون المشروع من ثلاث مهام:

1. إعداد بيئة التطوير
2. فهم محاكي Gazebo
3. كتابة ROS “Hello World”

بالنسبة للمهمتين 1 و2، كان علينا فقط إعداد بيئة التطوير الخاصة بنا واتباع مقدمة لتعليم Gazebo. شمل ذلك:

• إعداد ROS Melodic، وهو ما قمت به على حاسوبي المحمول HP لعام 2011 وكان كافيًا
• تثبيت وتكوين ROS وGazebo
• المرور عبر دليل gazebosim وdالـ e-manual.

المهمة 3، من ناحية أخرى، كانت تحديًا حقيقيًا. كانت المهمة هي استخدام turtlesim وجعل السلحفاة ترسم شعار “M” الخاص بمعادن:

هذه المهمة، رغم أنها بدت بسيطة، كانت أصعب مما تبدو. قدم هذا المشروع في النهاية مفهوم الأنظمة المفتوحة (Open-Loop) والمغلقة (Closed-Loop). يمكنك معرفة المزيد عن هذا المشروع وحلي على صفحة مشروع ROS Move Turtle.

🧩 التعلم المعزز لتتبع جدار الروبوت

كان هذا المشروع الثاني الذي كُلفنا به، وكان أحد أصعب المشاريع التي عملت عليها في الكلية. كان وصف المشروع كما يلي:

في هذا المشروع، سيقوم الطلاب بتصميم وتنفيذ خوارزميات التعلم المعزز لتعليم روبوت متنقل ذاتي التوجيه تتبع جدار وتجنب الاصطدام بالعقبات. سيستخدم الطلاب محاكاة Gazebo في ROS Melodic لمحاكاة روبوت متنقل متعدد الاتجاهات يُدعى ترايتون، باستخدام خريطة بيئية تُزودهم بها. سيستخدم الطلاب ماسح ليزر على الروبوت لأداء الاستشعار والتعلم، حيث يتم التحكم في الروبوت باستخدام أوامر التوجيه والسرعة. يُطلب من الطلاب برمجة هذا المشروع باستخدام C++ أو Python في ROS Melodic يعمل على Ubuntu 18.04 LTS (أي بيئة التطوير نفسها المستخدمة في المشروع 1). كما يُطلب من الطلاب كتابة تقرير وفق تنسيق مؤتمرات IEEE الروبوتية القياسية باستخدام LATEX.

بالنسبة لخوارزمية التعلم المعزز، تم توجيهنا لاستخدام Q-Learning. استخدمنا أيضًا بيئة محاكاة Stingray التي وفرتها الصف. كان Stingray يتضمن نموذج ترايتون ومنطق الفيزياء. كما تم تزويدنا بمتاهة للروبوت لتتبعها. في المجمل، بدت البيئة هكذا:

للوصف الكامل للمشروع، اطلع على csci473-p2.pdf. لم أنشر حلي على GitHub أو الويب لأنه لم يكن جيدًا وكان مليئًا بالعيوب. أيضًا، تشغيل الكود في البيئة الصحيحة صعب ومزعج. ومع ذلك، لدي فيديو توضيحي قدمته للصف، يُظهر حلي. يمكنك مشاهدته هنا:

🧩 فهم الروبوت لسلوكيات البشر باستخدام تمثيلات قائمة على الهيكل العظمي

كان وصف المشروع الثالث كما يلي:

في هذا المشروع، سيقوم الطلاب بتنفيذ عدة تمثيلات قائمة على الهيكل العظمي (المُنتج 1) واستخدام آلات الدعم الناقل (SVMs) (المُنتج 2) لتصنيف سلوكيات البشر باستخدام مجموعة بيانات نشاطية عامة تم جمعها من حساس Kinect V1. بالإضافة إلى ذلك، يُطلب من الطلاب كتابة تقرير وفق تنسيق مؤتمرات IEEE الروبوتية القياسية باستخدام LATEX في المُنتج 3.

كان هذا المشروع تحديًا لكنه لم يكن صعبًا كالبرنامج الثاني. الهدف الرئيسي كان استخدام بيانات حساس Kinect V1 من مجموعة بيانات MSR Daily Activity 3D، واستخدام آلات الدعم الناقل لتصنيف بعض الأفعال/السلوكيات البشرية. يمكنك معرفة المزيد عن هذا المشروع وحلي على صفحة مشروع Predict Human Actions Using LIBSVM.

خاتمة CSCI473

يُعد CSCI473 أحد، إن لم يكن أفضل، الصفوف التي أخذتها خلال دراستي الجامعية في معادن. علمتني جميع هذه المشاريع الكثير وسمحت لي بامتلاك كتالوج رائع من المشاريع لأستعرضه وأشير إليه في سيرتي الذاتية. كان أيضًا أول صف شعرت فيه أنني في مكاني، حيث لم أكن أبدًا طالبًا جيدًا في الاختبارات لكنني تميزت في إكمال المشاريع. ومن خلال هذا الصف التقيت بالدكتور هاو تشانغ، الذي ساعدني لاحقًا في الحصول على وظيفة كمساعد بحث في مختبر الروبوتات المتمحور حول الإنسان (HCR) بمعادن.

جلسة مجال علوم الحاسوب (الصيف 2020)

خلال صيف 2020، بين إكمال CSCI473 والانضمام إلى مختبر HCR، أخذت CSCI370 أو “هندسة البرمجيات المتقدمة” كجزء من برنامج علوم الحاسوب الجامعي في مدرسة كولورادو للمعادن. يُعد CSCI370 دورة تجعل الطلاب يصممون، ينفذون، ويوثقون حلولًا برمجية لشركة. يسمح للطلاب بتطبيق معرفتهم المكتسبة في الدورات على مشاكل علوم الحاسوب الواقعية. يمكنك معرفة المزيد عن الدورة هنا.

في الدورة، يمكنك اختيار المشروع/الشركة التي ستعمل عليها. وفرت الدورة ملفات PDF تفصل كل مشروع وشركة. في النهاية قررت العمل على مشروع نشرته شركة Lunar Outpost بعنوان “الكشف في الوقت الحقيقي عن انزلاق العجلات وتصحيح الأخطاء لتحسين الملاحة القمرية”. نظرًا لطول الاسم، سنطلق على المشروع اسم “كشف انزلاق العجلات”.

المشكلة

Lunar Outpost هي شركة ناشئة تحاول إنشاء مركبات قمرية ذاتية. على القمر، هناك الكثير من الغبار القمري المعروف بأنه يسبب الكثير من انزلاق العجلات. هذا غير مثالي لأن انزلاق العجلات يمكن أن يتسبب في فقدان الأنظمة الذاتية لموقعها الحقيقي. على الأرض، يتم حل هذه المشكلة باستخدام بيانات GPS لتصحيح أي إزاحة ناتجة عن انزلاق العجلات. لكن المشكلة مع GPS هي أنه يعمل فقط بوجود أكثر من 30+ قمر صناعي ملاحي يدور باستمرار حول الأرض وينقل إشارات فريدة تسمح للكمبيوترات بحساب موقعها. ولكن على القمر لا يوجد حاليًا GPS. لذا يجب استخدام طريقة أخرى غير GPS لاكتشاف انزلاق العجلات. يمكن الاطلاع على تقرير أكثر تفصيلًا عن مشكلة المشروع هنا.

الفريق

هذا المشروع لم يكن مشروعًا بسيطًا، لذا كان لابد من إنجازه ضمن فريق. كان الفريق يتألف من خمسة طلاب من مدرسة كولورادو للمعادن:

هذا المشروع لم يكن مشروعًا بسيطًا، لذا كان لابد من إنجازه ضمن فريق. كان هذا الفريق يتألف من محمد يلماز (أنا)، كين بروس، برادون أو’كالاغان، ليام ويليامز، وكيفن غرانت.

المشروع تطلب منا معرفة بعض ROS، C++، Python، Linux، Raspberry Pi، وArduino. كان لدى معظمنا خبرة في واحدة أو أكثر من هذه التقنيات لكنني كنت الوحيد الذي لديه خبرة في ROS لأنني استخدمته في صف الروبوتات المتمحورة حول الإنسان (CSCI473) خلال فصل ربيع 2020. بسبب ذلك، في البداية، ساعدت الجميع على التعرف على ROS وكيفية التطوير به.

التحديات

في هذا المشروع كان هناك الكثير من التحديات. لكن أكبر تحدٍ واجهناه هو عدم القدرة على الوصول إلى روبوت حقيقي للاختبار. كان ذلك بسبب كوفيد الذي جعل كل شيء عن بُعد ومنعنا من العمل في مختبر/مباني القاعدة القمرية. نتيجة لذلك، اضطررنا لاستخدام المحاكاة.

كما اطلعنا على بعض الأبحاث الأكاديمية من مختبر الملاحة بجامعة WVU للحصول على فكرة حول كيفية حل مشكلة انزلاق العجلات لحالة استخدام القاعدة القمرية. وهذا، بالنسبة لنا كطلاب جامعيين في السنة الثانية والثالثة، كان أصعب مما توقعنا.

تحدٍ آخر واجهناه هو مقدار الوقت المتاح لنا للعمل على هذا المشروع. مادة CSCI370 هي مادة تستغرق شهرًا واحدًا. لكن المشكلة نفسها مشكلة ضخمة تحاول العديد من الشركات والأكاديميين حلها/تحسينها منذ عقود. لذا فإن شهرًا واحدًا بعيد كل البعد عن كفاية الوقت لحل هذه المسألة. ومع ذلك، رغم كل هذه التحديات، استمرينا وتأكدنا من الإنجاز.

الخلاصة

بعد العمل عبر جميع الأبحاث والتطوير، قررنا أنه من شبه المستحيل محاكاة فيزياء القمر بشكل صحيح رقميًا، لذا فإن تجربة هذا الخوارزم في محاكاة لا فائدة منها ولن تُنتج أي بحث ذي معنى في كشف انزلاق العجلات في الفضاء وعلى القمر. استنتجنا أن إعداد بيئة اختبار مناسبة باستخدام شيء مثل الرمل ومعدات حقيقية، مثل روبوت Husky، هو أكثر أهمية لهذا النوع من الأبحاث. قمنا بتحديث كود كشف انزلاق العجلات ليعمل كعقدة ROS وقد عمل بشكل صحيح ويمكن استيراده بسهولة إلى معدات حقيقية للاختبار. سمح لي هذا المشروع بتولي دور قيادي، وتعليم زملائي تطوير ROS، واكتساب خبرة مع Python وROS وGazebo أثناء معالجة مشكلة معقدة لم أواجهها من قبل. والأهم من ذلك، أن هذه التجربة رسخت شغفي بالروبوتات وعززت رغبتي في متابعة البحث في هذا المجال، ممهدةً الطريق لما سيأتي لاحقًا في رحلتي الروبوتية.

البدء في مختبر HCR

بعد إكمال CSCI473، وجلسة CS Field في صيف 2020، وفصل خريف 2020، قررت متابعة البحث في مجال الروبوتات. كانت لدي تجارب رائعة مع كل من CSCI473 وجلسة CS Field لدرجة أنني قررت أن أريد البحث في مختبر HCR. بما أنني التقيت بالدكتور تشانغ في العام السابق، قررت مراسلته عبر البريد الإلكتروني وسؤاله عن أي فرص قد تكون متاحة في المختبر في يناير 2021. خلال حوالي أسبوعين، أبدى الدكتور تشانغ اهتمامه، قدم لي خيارات البحث، وعرض عليّ دورًا في المختبر. ثم بدأت العمل في المختبر في فبراير 2021.

فيديو المقدمة

إليك فيديو المقدمة الذي سجلته بعد بضعة أشهر من انضمامي إلى مختبر HCR. تم تسجيله في مايو 2021 ويغطي البحث الذي سأركز عليه في مختبر HCR خلال صيف 2021:

مشروعي

خلال وقتي في مختبر HCR، ركزت أساسًا على مشروع Triton. مشروع Triton هو روبوت متحرك تم تطويره بواسطة مختبر الروبوتات المتمحور حول الإنسان في كلية كولورادو للمعادن. إنه روبوت أرضي ثلاثي الأوجه بعجلات أومني مدعوم من Jetson Nano من NVIDIA.

يتكون Triton، في نظرة بسيطة، من الأجزاء التالية:

• Jetson Nano من NVIDIA
• لوحة حامل Seed Studio A205 من NVIDIA
• Arduino Mega
• بطاقة Micro SD سعة 64 جيجابايت
• هيكل مطبوع ثلاثي الأبعاد مخصص
• 3 عجلات ميكانوم
• بطارية AR واحدة
• دوائر مخصصة لتوزيع الطاقة وتوصيل الأسلاك بشكل أمثل
• كاميرا Intel Realsense D435
• بعض مصابيح LED

تم تصميمه وبناؤه وتصنيعه بين عامي 2018-2020 كروبوت لأغراض تعليمية. بحلول الوقت الذي انضممت فيه، كان Triton قد استقر إلى حد كبير، وكان المختبر يفكر في صنع نسخة جديدة منه. ومع ذلك، كانت المشكلة الرئيسية في Triton هي برمجياته. كان بإمكان Triton التحرك والشحن والعمل بشكل أساسي لكنه لم يكن يقوم بأي شيء ذكي. بل كان يفتقر حتى إلى القدرة على تنفيذ حركات أكثر تقدمًا.

لبدء معالجة ذلك، أنشأ المختبر مساحة يمكننا من خلالها تتبع Triton. للقيام بذلك، أنشأوا مساحة 2 متر × 2 متر مع 8 كاميرات Optitrack Flex (أشعة تحت حمراء) في شكل مربع على ارتفاع حوالي 6-7 أقدام فوق الأرض.

بالإضافة إلى بناء هذه المنطقة، كان لكل Triton ثلاث كرات رمادية ملحقة بأعلى جسمه.

بهذا الإعداد، بنينا فعليًا نظام GPS صغير النطاق يسمح لنا بالحصول على الإحداثيات الدقيقة بالمتر لـ Triton في منطقة اهتمامنا. باستخدام كاميرات Optitrack تحت الحمراء والكرات الرمادية في شكل مثلث، كنا نستطيع تحديد الإحداثيات الدقيقة لـ Triton في منطقتنا. هذا مكننا من تطبيق نظام حلقة مغلقة لتحسين دقة الحركة.

يوفر نظام Optitrack بيانات الموقع والاتجاه بحوالي 120 هرتز مع دقة تحت المليمتر عند المعايرة الصحيحة. تشكل العلامات العاكسة الثلاثة لكل Triton نمطًا مثلثيًا فريدًا يمكن للنظام تتبعه كجسم صلب. تم معايرة نظام الإحداثيات بحيث يكون (0,0) في مركز منطقة التتبع، مع محوري X وY متوازيين مع هندسة الغرفة. ولكن بالرغم من هذه البيانات الدقيقة للموقع، لا يزال Triton يواجه صعوبات في الحركة.

مع هذا الإعداد، كانت إحدى الميزات الأساسية التي أردنا توفيرها لـ Triton هي القدرة على التحرك إلى إحداثيات محددة. يمكن للمستخدم أو برمجياته تقديم إحداثيات (x, y) داخل منطقة اهتمامهم. ثم يتحرك الروبوت إلى تلك الإحداثيات بأسرع ما يمكن، بدقة، وبسلاسة. عندما انضممت، كانت هذه الميزة موجودة لكنها لم تكن تعمل جيدًا. إليكم رسمًا متحركًا بسيطًا يوضح كيف كان يعمل منطق الحركة الأصلي:

لم أسجل الحل الأصلي أثناء التنفيذ، لذا أنشأت هذا الرسم المتحرك البسيط الذي يوضح لك منطق الحركة القديم أثناء التنفيذ. بمعرفتك لهذا، ما هي المشكلات في هذه الطريقة؟

1. إنها بطيئة جدًا
2. تجعل الروبوت يشغل مساحة كبيرة فقط للوصول إلى نقطة محددة. وهذا جعل من الصعب علينا استخدام هذا الحل عندما يتحرك عدة Tritons في آنٍ واحد.

فلماذا يحدث هذا السلوك؟ المشكلة كانت أن Triton أولاً يدور، مغيرًا قيمة ألفا، حتى يتجه نحو النقطة المستهدفة ضمن هامش خطأ محدد. ثم يندفع إلى الأمام، وبعد أن يصبح ثيتا بعيدًا عن الهدف بكمية معينة، يتوقف ويبدأ بالدوران مرة أخرى حتى تكون ألفا ضمن النطاق المقبول للهدف. ثم يندفع مرة أخرى ويستمر في ذلك حتى يصل إلى النقطة. أيضًا، كلما اقترب من نقطة الهدف، يصبح السرعة في الدوران والاندفاع أبطأ كثيرًا لضمان عدم تجاوز الهدف. أدى ذلك إلى حركة غير طبيعية لـ Triton، تستغرق وقتًا طويلًا للوصول إلى نقطة الهدف، وتحتاج إلى مساحة كبيرة للوصول إلى نقطة محددة. لذا، مع كل هذه المشكلات، وبالنظر إلى أهمية هذه الميزة لتطوير مشروع Triton، عندما بدأت العمل في مختبر HCR، كانت مهمتي الأولى هي تطوير حلول أكثر فاعلية تسمح لـ Triton بالتنقل بشكل أفضل إلى نقطة الهدف.

معرفًا بذلك، قضيت الكثير من الوقت في البحث عن أفضل طريقة ممكنة لمعالجة هذه المشكلة. من المفارقات أنني كنت أدرس مادة مقدمة أنظمة التحكم الراجعة (EENG307) في Mines. في بداية تلك المادة، تعلمنا عن مفهوم المتحكمات المفتوحة الحلقة والمتحكمات المغلقة الحلقة. مع علمي بذلك، وبعد مناقشة مع أستاذ تلك المادة وزميلي الذكي في السكن، أصبح واضحًا أن هدف نقل Triton إلى نقطة الهدف هو مشكلة نظام حلقة مغلقة.

الآن، بعد اختبارات وبحوث مكثفة، طورت نهجين مميزين للتحكم في Tritons:

الطريقة 1: متحكم المسافة-ثيتا

استخدم هذا النهج متحكمين متناسبين منفصلين يعملان في وقت واحد:

• متحكم المسافة: يحسب المسافة الإقليدية إلى الهدف ويطبق كسبًا متناسبًا لتحديد السرعة الأمامية/الخلفية
• متحكم ثيتا: يحسب الخطأ الزاوي بين توجيه الروبوت الحالي والاتجاه المطلوب نحو الهدف، مطبقًا كسبًا متناسبًا منفصلًا للسرعة الدورانية

يحسب الخوارزم باستمرار المسافة الإقليدية إلى الهدف والخطأ الزاوي بين توجيه الروبوت الحالي والاتجاه المطلوب. يتم تطبيق كسبين متناسبين منفصلين لتوليد السرعات الخطية والزواية على التوالي.

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

الطريقة 2: متحكم إحداثيات X-Y

هذا النهج عالج الروبوت كأنه رسام ثنائي الأبعاد، مع تحكم مستقل في حركة X و Y:

• متحكم X: تم التحكم مباشرةً في حركة الشرق‑الغرب بناءً على خطأ إحداثي X
• متحكم Y: تم التحكم مباشرةً في حركة الشمال‑الجنوب بناءً على خطأ إحداثي Y

حسب التنفيذ أخطاء إحداثيات X و Y بشكل مستقل، وطبق مكاسب نسبية منفصلة، ثم حول هذه مكونات السرعة العالمية إلى إطار الإحداثيات المحلي للروبوت باستخدام مصفوفات الدوران. كان هذا التحويل ضروريًا لأن نظام الدفع بالعجلات المتعددة للروبوت يتطلب سرعات في إطاره المرجعي الخاص، وليس في الإحداثيات العالمية. أنتجت هذه الطريقة أقصر المسارات إلى الأهداف وكانت أسرع بشكل ملحوظ، لكن اتجاه الروبوت كان ينحرف لأن لا يوجد تحكم صريح في التوجه.

بالنسبة للطريقة #1، قمت بشرح كامل لهذه الطريقة في مدونتي مدونة تحريك السلحفاة (TurtleSim). أوصي بشدة بقراءة هذه المدونة للحصول على جميع التفاصيل حول كيفية عمل متحكمات PID بشكل عام، وكذلك كيفية عمل الطريقة #1. طورت الطريقة #1 باستخدام TurtleSim الخاص بـ ROS، ثم نقلت ذلك الكود إلى الـ Triton وقمت بتحديثه ليتناسب مع بيئة أكثر واقعية.

استخدمت الطريقة #2 نهجًا مختلفًا تمامًا ولكنه فعال بالمثل. بدلاً من التفكير في توجيه الروبوت والمسافة إلى الهدف، تتعامل هذه الطريقة مع الحركة كمسألة مستوى إحداثيات. يقوم المتحكم بحساب الخطأ في كل من اتجاهي X و Y بشكل منفصل بشكل مستمر. على سبيل المثال، إذا كان الروبوت يحتاج إلى التحرك من (0,0) إلى (2,3)، فإنه يرى ذلك كضرورة تصحيح خطأ بمقدار 2 متر في X و3 أمتار في Y. عمل متحكمان نسبيان في آنٍ واحد: أحدهما يضبط سرعة الروبوت في اتجاه X بناءً على خطأ X، بينما يتعامل الآخر مع حركة اتجاه Y بناءً على خطأ Y. هذا خلق مسارًا أكثر مباشرةً إلى الهدف، مشابهًا لكيفية تحرك رأس طابعة ثلاثية الأبعاد، وسمح بحركات قطرية سلسة. لم يكن الروبوت بحاجة إلى الدوران صراحةً لمواجهة هدفه، مما جعل هذه الطريقة فعّالة بشكل خاص في الأماكن الضيقة أو عندما يتطلب تموضع دقيق.

كانت كلتا الطريقتين أسرع بشكل ملحوظ وأكثر موثوقية من النهج الأصلي. للتحقق من هذه الطرق الجديدة قيد التنفيذ، اطلع على قائمة تشغيل ترايتونز في العمل، التي تُظهر جميع ترايتونز في العمل مع الطرق الجديدة.

ما كان يستغرق 30‑45 ثانية لحركة بسيطة من نقطة إلى أخرى أصبح الآن يستغرق حوالي 8‑12 ثانية. والأهم من ذلك، أصبح بإمكان ترايتون الآن التنقل بكفاءة أكبر في الأماكن الضيقة، مما أصبح مفيدًا لسيناريوهات الروبوتات المتعددة لدينا.

تحديات التطوير وتصحيح الأخطاء

لم يكن تنفيذ هذه المتحكمات أمرًا بسيطًا وشمل عدة تحديات تصحيح أخطاء هامة:

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

العالم الحقيقي مقابل السلوك المثالي: كان أكبر تحدٍ هو مراعاة العوامل الواقعية التي لا تظهر في نظرية التحكم من الكتب الدراسية. كانت عجلات الروبوت لها خصائص احتكاك مختلفة، ولم تستجب المحركات بشكل متماثل، وكان هناك دائمًا بعض الكمون في سلسلة الاتصال من Optitrack إلى برنامج التحكم إلى أردوينو الروبوت. قضيت أسابيع في ضبط المكاسب النسبية وإضافة مرشحات نطاق ميت لمراعاة هذه الواقعيات الفيزيائية.

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

تداخل الروبوتات المتعددة: عندما عملت عدة روبوتات في وقت واحد، اكتشفت أنماط تداخل غير متوقعة. كانت الروبوتات أحيانًا “تتنازع” على نفس المساحة أو تخلق حالات توقف حيث كانت تحجز بعضها البعض إلى ما لا نهاية. أدى ذلك إلى تنفيذ آليات تنسيق وخوارزميات تجنب التصادم.

نظام التحكم المتعدد ترايتون

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

كان النظام الأصلي قادرًا على التحكم في ترايتون واحد فقط في كل مرة، مما حدّ بشدة إمكانيات البحث. أراد المختبر محاكاة سيناريوهات حيث تحتاج عدة مركبات ذاتية القيادة إلى تنسيق حركاتها، مثل السيارات ذاتية القيادة التي تتواصل مع بعضها البعض لتحسين تدفق المرور وإنشاء خرائط SLAM (التحديد والتخطيط المتزامن) أفضل.

لحل ذلك، نفذت نهجًا متعدد العمليات باستخدام مكتبة multiprocessing في بايثون. حصل كل ترايتون على عملية مخصصة خاصة به يمكنها العمل بشكل مستقل مع استمرار تنسيقها من قبل نظام تحكم مركزي. سمح ذلك لعدة ترايتونات بالتحرك في وقت واحد دون التداخل مع حلقات التحكم الخاصة ببعضها.

تصميم بنية الروبوتات المتعددة

تتكون بنية النظام التي طورتها من عدة مكونات رئيسية:

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

عمليات الروبوت الفردية: كان لكل ترايتون عمليته المخصصة في بايثون التي تعالج:

• حسابات التحكم PID في الوقت الحقيقي بسرعة ~50Hz
• التواصل مع عتاد الروبوت (Arduino/Jetson)
• تنفيذ المسار المحلي وتجنب العقبات
• إبلاغ الحالة مرةً إلى المتحكم الرئيسي

الاتصال بالذاكرة المشتركة: استخدمت multiprocessing.shared_memory وQueue في بايثون لتمكين التواصل الفعال بين العمليات. سمح ذلك بالتنسيق في الوقت الحقيقي دون عبء التواصل الشبكي.

آليات المزامنة: لمنع التعارض عندما تحتاج عدة روبوتات إلى التنسيق (مثل تجنب التصادمات)، نفذت semaphores وlocks التي تسمح للروبوتات بطلب وصول حصري إلى مناطق معينة من مساحة العمل.

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

فتح نظام متعدد ترايتون إمكانيات بحثية جديدة تمامًا. أصبح بإمكاننا الآن محاكاة:

• سيناريوهات التواصل بين المركبات
• تخطيط مسار منسق مع تجنب العقبات
• سلوكيات الروبوتات الجماعية
• رسم خرائط SLAM متعددة الوكلاء
• التحكم في التشكيل وسلوكيات المتابعة

هذا ما كان يبدو عليه إعداد المختبر مع تشغيل عدة ترايتونات في وقت واحد:

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

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

هذه قائمة تشغيل تُظهر ترايتونز في العمل، من التحكم بروبوت واحد إلى تنسيق الروبوتات المتعددة: قائمة تشغيل ترايتونز في العمل

دمج مستشعر العمق وتصحيح الإحداثيات

تقدم كبير آخر عملت عليه كان يتعلق باستخدام كاميرات العمق Intel RealSense D435 المثبتة على كل ترايتون. بينما قدم نظام Optitrack لنا بيانات تموضع دقيقة للغاية، أردت استكشاف كيفية استخدام الروبوتات لأجهزة الاستشعار المدمجة لديها لتحسين الوعي المكاني وتصحيح أخطاء الإحداثيات.

كانت الفكرة أن ترايتونات يمكنها استخدام مستشعرات العمق الخاصة بها لاكتشاف ترايتونات أخرى في محيطها ومقارنة مواقعها. سيفيد ذلك في عدة أغراض:

1. تصحيح الخطأ: إذا كان نظام Optitrack يعاني من أي انحراف في المعايرة أو حجب مؤقت، يمكن للروبوتات استخدام التأكيد البصري لمواقع بعضها البعض للحفاظ على أنظمة إحداثيات دقيقة.

2. تحسين SLAM: من خلال وجود عدة روبوتات مزودة بمستشعرات عمق تعمل معًا، يمكننا إنشاء خرائط أكثر غنىً للبيئة مع نقاط بيانات متكررة.

3. تجنب الاصطدام: سيسمح الاستشعار العمق في الوقت الحقيقي للروبوتات بالكشف عن بعضها البعض وتجنبها حتى إذا كان نظام التحكم المركزي يعاني من تأخيرات في الاتصال.

بدأت أجرّب خوارزميات تسمح لتريتونات بـ:

• اكتشاف تريتونات أخرى باستخدام شكلها المثلث المميز وعلامات الكرات العاكسة
• حساب المواضع والاتجاهات النسبية باستخدام بيانات العمق
• مقارنة هذه القياسات مع بيانات Optitrack لتحديد الفروقات
• تعديل نظام الإحداثيات الخاص بهم في الوقت الحقيقي للحفاظ على الدقة

تجارب الرؤية الحاسوبية

قضيت وقتًا كبيرًا أجرّب خط أنابيب الرؤية الحاسوبية الذي يعمل في عدة مراحل:

معالجة بيانات العمق: قدمت Intel RealSense D435 كل من تدفقات بيانات RGB والعمق. عملت أساسًا مع بيانات العمق، التي كانت تأتي كمصفوفة 640x480 من قياسات المسافة عند 30 هرتز. التحدي الأول كان تصفية هذه البيانات الضوضائية لاستخراج معلومات هندسية ذات معنى.

محاولات اكتشاف الكائنات: جرّبت خوارزميات اكتشاف متعددة المراحل. حققت بعض النجاح في تقسيم صورة العمق لتحديد الكائنات على مستوى الأرض (مع تصفية الجدران والسقف، إلخ) والبحث عن كائنات ذات الخصائص الحجمية المناسبة، تقريبًا بصمة 0.3×0.3 متر. حاولت استخدام اكتشاف الحواف والتحليل الهندسي لتحديد ملف تريتون المميز، وكانت النتائج مختلطة.

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

بحث دمج الإحداثيات: بحثت عن أساليب دمج تقديرات الموقع المستندة إلى الرؤية مع بيانات Optitrack، بما في ذلك تطبيقات مرشح كالمان الأساسي. كان المفهوم هو إعطاء وزن أكبر لبيانات Optitrack عندما تكون متاحة، والاعتماد على الرؤية عند الحاجة، رغم أنني لم أتمكن من تشغيل ذلك بالكامل قبل انتهاء فترة عملي في المختبر.

تحديات الأداء: كان تشغيل كل هذه المعالجة في الوقت الحقيقي جنبًا إلى جنب مع حلقات التحكم في الروبوت تحديًا كبيرًا. جرّبت أساليب تحسين لتشغيل الخوارزميات عند حوالي 10-15 هرتز دون إغراق قدرات معالجة Jetson Nano.

للأسف، اضطررت لمغادرة المختبر قبل أن أتمكن من إكمال عمل الرؤية الحاسوبية هذا بالكامل. رغم أنني حصلت على بعض النتائج المبكرة الواعدة وتعلمت الكثير عن معالجة مستشعر العمق، لم أتمكن من جعل النظام موثوقًا بالكامل. ظل ذلك اتجاهًا بحثيًا مثيرًا يمكن للآخرين البناء عليه.

إليك فيديو لي وأنا أختبر خوارزميات الرؤية الحاسوبية:

هذا ما كان يبدو عليه عرض مستشعر العمق خلال تجاربي:

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

توثيق وحفظ المعرفة

كان أحد أهم إسهاماتي في مختبر HCR، وربما الأكثر فخرًا بالنسبة لي، هو تنظيم وحفظ جميع وثائق المشروع. عندما انضممت إلى المختبر، كان معرفة مشروع تريتون موزعة عبر منصات وصيغ متعددة. انتشرت المعلومات الحرجة عبر:

• حسابات Google Drive مختلفة تخص طلابًا تخرجوا
• رسائل بريد إلكتروني قديمة مدفونة في الصناديق الواردة
• مجلدات Dropbox عشوائية
• مستودعات GitHub متعددة
• مستودعات GitLab ذات تنظيم غير متسق
• ملاحظات مكتوبة بخط اليد لا يمكن تفسيرها إلا من قبل أشخاص محددين

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

تحملت مسؤولية حل هذه المشكلة بشكل منهجي. قضيت ساعات لا تحصى أبحث عن كل قطعة من الوثائق، الكود، الفيديو، والملاحظة المتعلقة بمشروع تريتون. ثم نظمت كل شيء في مستودع GitLab مركزي بهيكل واضح ومنطقي.

شملت الوثائق المركزية:

• دلائل التجميع: إرشادات خطوة بخطوة لتجميع تريتونات من الصفر
• إعداد البرمجيات: دلائل كاملة لإعداد بيئة التطوير
• توثيق الكود: كود مُعلّق جيدًا مع شروحات واضحة
• مواصفات الأجهزة: قوائم أجزاء مفصلة، مخططات توصيل، وتصاميم PCB
• دلائل استكشاف الأخطاء: مشاكل شائعة وحلولها
• دروس فيديو: أنشأت وحمّلت فيديوهات تعليمية على YouTube، بما في ذلك دروس تفصيلية لت calibrate Optitrack:

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

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

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

الإرشاد ونقل المعرفة

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

إرشاد خلفاء المختبر

أثناء استعدادي للمغادرة النهائية من المختبر للتركيز على إكمال درجتي وعملِي في eBay، تأكدت من تدريب شخصين بدقة سيتوليان مشروع تريتون بعد رحيلي. لم يكن الأمر مجرد إظهار كيفية عمل الأشياء، بل كان لضمان فهمهم العميق للمبادئ الأساسية حتى يتمكنوا من الاستمرار في الابتكار.

قضيت أسابيع أعمل عن كثب معهم، مرورًا بـ:

• الأسس الرياضية لأنظمة التحكم PID
• بنية المعالجة المتعددة لتنسيق عدة روبوتات
• دمج مستشعر العمق وخوارزميات الرؤية الحاسوبية
• نظام الوثائق وكيفية صيانته
• تقنيات استكشاف الأخطاء وأنماط الفشل الشائعة

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

برنامج إرشاد طلاب الثانوية

ربما كان أكثر ما يرضيني هو تجربتي في إرشاد طالب ثانوي عبر برنامج التوعية بالمختبر. كانت فرصة رائعة لتعريف شخص ما بالروبوتات، علوم الحاسوب، والبحث في مرحلة تكوينية من تعليمه.

صممت منهجًا شاملًا شمل:

أساسيات علوم الحاسوب:

• مفاهيم البرمجة باستخدام Python كلغة أساسية
• مقدمة في البرمجة الكائنية التوجه
• فهم الخوارزميات وهياكل البيانات

مفاهيم الروبوتات:

• كيفية عمل المستشعرات وكيفية التفاعل معها
• التحكم في المشغلات وأنظمة المحركات
• أساسيات الأنظمة الذاتية والتحكم الراجع

ROS (نظام تشغيل الروبوت):

• فهم نظام الرسائل النشر/الاشتراك
• إنشاء العقد والخدمات
• العمل مع ملفات الإطلاق وخوادم المعلمات

عمل مشروع عملي:

• تعاونّا على إنشاء خدمة ROS تتحكم في نظام LED على رأس تريتون
• تعلمت كتابة كود نظيف موثّق يندمج مع أنظمتنا الحالية
• أصبحت خدمة التحكم في LED التي أنشأتها جزءًا دائمًا من قاعدة كود تريتون

ما جعل هذا الإرشاد مميزًا بشكل خاص هو مشاهدتها تتطور من عدم معرفة تقريبًا بالبرمجة إلى مساهمة بكود ذي معنى في مشروع بحثي نشط. انتقلت من سؤال “ما هو المتغيّر؟” إلى استكشاف أخطاء التواصل في ROS بشكل مستقل وكتابة تطبيقات خدماتها الخاصة.

سمح نظام التحكم في LED الذي طورته للباحثين بتغيير ألوان وأنماط LED على رأس تريتون بسهولة عبر أوامر ROS بسيطة. قد يبدو ذلك بسيطًا، لكنه استلزم فهم بنية ROS، التفاعل مع العتاد، وأنماط تصميم البرمجيات السليمة. لا يزال إسهامها يُستخدم في المختبر اليوم.

The mentorship was as educational for me as it was for her. It forced me to break down complex concepts into digestible pieces and really think about the fundamentals of what we were doing. Teaching someone else made me a better engineer and researcher.

التعاون مع بحث الدكتوراه

One of the most professionally rewarding aspects of my time in the lab was working closely with Peng, a PhD student whose research focused on self-driving car algorithms. The software improvements I had made to the Triton system helped support his doctoral research.

Peng’s research required precise, reliable multi-robot coordination to simulate self-driving car scenarios. Before my improvements to the movement control and multi-robot systems, these experiments were much more difficult to conduct. The robots were slower, less accurate, and couldn’t work together as effectively.

My contributions helped Peng’s research in several areas:

دراسات إدارة التقاطع: With the improved PID controllers and multi-robot coordination, Peng could simulate intersection scenarios where multiple “vehicles” (Tritons) needed to coordinate their movements. The better timing and positioning helped make these studies more feasible.

الاتصال بين المركبات: The multi-processing framework I developed allowed Peng to implement and test communication protocols between simulated vehicles. Each Triton could make decisions while still coordinating with others, similar to how self-driving cars might need to operate.

بحث SLAM والرسم الخرائطي: The depth sensor integration work provided Peng with additional data for his simultaneous localization and mapping research. Having multiple robots with coordinated sensing capabilities allowed for more comprehensive mapping experiments.

What made our collaboration particularly valuable was that it wasn’t just me helping his research, it was a genuine partnership. Peng’s understanding of the theoretical aspects of autonomous vehicles helped inform my practical implementations. His feedback and requirements pushed me to make the systems more robust and capable.

We spent many hours in the lab together, debugging scenarios, discussing different control strategies, and exploring what the Triton platform could accomplish. Peng became both a colleague and a friend, and working with him taught me a lot about how academic research actually works.

The systems I built became a useful part of Peng’s dissertation work. Seeing my practical engineering contributions support research in autonomous vehicle technology was really fulfilling. It reinforced my interest in how solid engineering and research can work together to create useful outcomes.

Even after I left the lab, Peng and I stayed in touch. Knowing that my work continued to contribute to important research even after my departure was extremely rewarding.

منظور: عصر ما قبل النماذج الكبيرة للغة في التطوير

It’s worth noting that all of this work was accomplished during the pre-LLM era of software development. All of this took place between 2020 to 2021 (mainly 2021), before ChatGPT, Claude, Perplexity, or AI-powered development tools like Cursor IDE existed.

Every line of code was written from scratch, every algorithm was researched through academic papers and textbooks, and every debugging session involved traditional methods like print statements, debuggers, and methodical testing. When I got stuck on a coordinate transformation or PID tuning problem, I couldn’t just ask an AI assistant to explain the concept or help debug the issue.

This made the development process significantly more challenging but also more educational. I had to:

ابحث عن كل شيء يدويًا: Understanding PID control theory meant reading textbooks and academic papers. Figuring out coordinate transformations required working through the math by hand. Every concept had to be fully understood before implementation.

تصحيح الأخطاء بدون مساعدة الذكاء الاصطناعي: When robots moved in unexpected directions or oscillated around targets, I had to methodically trace through the logic, add debug outputs, and test hypotheses one by one. There was no AI to suggest potential issues or help interpret error patterns.

تعلم من المبادئ الأساسية: Without the ability to quickly ask “how do I implement multi-processing in Python for robotics?” I had to understand the underlying concepts deeply. This forced me to build a solid foundation in concurrent programming, control systems, and computer vision.

التوثيق كان حاسمًا: Since I couldn’t rely on AI to explain code later, I had to write extremely clear documentation and comments. This discipline proved invaluable when transferring knowledge to others.

Looking back, while modern AI tools would have accelerated many aspects of the development, working without them forced me to develop deeper problem-solving skills and a more thorough understanding of the underlying systems. It’s fascinating to think how different this project might have been with today’s development tools available.

القرار الصعب بالمغادرة

As much as I loved working in the HCR Lab, by late 2021 I faced a difficult decision that many students encounter: balancing multiple opportunities and responsibilities. I was simultaneously working full-time as a software engineer at eBay, finishing my computer science degree at Mines, and contributing to research at the HCR Lab.

The eBay opportunity was significant; it was my first major software engineering role, provided invaluable industry experience, and provided me with a solid income. However, trying to maintain full-time work, complete my degree, and contribute meaningfully to research was simply unsustainable. Something had to give.

When I approached Dr. Zhang about potentially reducing my course load to focus more on the lab work, he strongly advised against it. His reasoning was sound: completing my degree should be the priority, and the industry experience at eBay would be valuable for my career development. He felt that dropping classes to focus on research, while tempting, might not be the best long-term decision.

So in September 2021, after about 8 months of intensive work in the lab, I made the difficult decision to step back from my research assistant role to focus on completing my degree and my work at eBay. It was one of the harder professional decisions I’ve had to make at the time.

Even after officially leaving the lab, I continued to provide support whenever anyone needed help with the systems I had built. I updated documentation as needed, answered questions about debugging, and helped troubleshoot issues remotely. The connections I had made and the investment I had in the project’s success didn’t just disappear because I was no longer officially part of the team.

تأملات ونظرة إلى الوراء

Now, in 2025, four years later, I find myself reflecting on that time with complex emotions. My career path took me deep into web development and AI/ML engineering, areas that have been incredibly rewarding and provided tremendous opportunities for growth and impact.

Yet there’s a part of me that wonders “what if.” Robotics was, and honestly still is, my true passion. There’s something about working with physical systems, seeing your code translate into real-world movement and behavior, that web development and even AI work can’t quite replicate.

I sometimes wonder what might have happened if I had taken a different path. What if I had found a way to stay in robotics research? What if I had pursued graduate school immediately after finishing my undergraduate degree? What if I had chosen to prioritize the lab work over the industry experience?

But I also recognize that every path has its trade-offs. The skills I developed in web development and AI have been incredibly valuable. The industry experience taught me about software engineering at scale, user experience design, and the practical challenges of building products that millions of people use. These experiences have made me a better engineer overall.

The work I did in the HCR Lab continues to influence how I approach problems today. The systematic thinking required for PID control systems shows up in how I design feedback loops in software systems. The documentation and knowledge preservation skills I developed have been invaluable in every role since. The experience of mentoring and teaching has shaped how I work with junior developers and contribute to team knowledge sharing.

Most importantly, the experience taught me that I thrive when working on challenging technical problems that have real-world impact. Whether that’s optimizing robot movement algorithms or building AI systems that help users accomplish their goals, the satisfaction comes from solving hard problems that matter.

الأثر الدائم

Looking back at the HCR Lab experience, I’m struck by how much I accomplished in a relatively short time. The systems I built fundamentally changed how the Triton platform operated, and many of those improvements are still being used today. The documentation repository I created became the knowledge base for the entire project. The mentorship relationships I formed had lasting impact on the people I worked with.

But perhaps most significantly, the experience showed

• حسّن نظام التحكم في حركة الروبوت الذي كان يحدّ من المنصة
• بنى نظام تنسيق متعدد الروبوتات من الصفر
• دمج قدرات الرؤية الحاسوبية ودمج المستشعرات
• أنشأ نظام توثيق وإدارة معرفة شامل
• قدم الإرشاد لعدة أشخاص وساعد في نقل المعرفة
• دعم أبحاث مستوى الدكتوراه في المركبات الذاتية القيادة

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

المستقبل والروبوتات

بينما أخذت مسيرتي المهنية مسارات أخرى، لم يتضاءل شغفي بالروبوتات. ما زلت أتابع التطورات في المجال، وأنا متحمس للتقدمات في تعلم الروبوتات والأنظمة الذاتية، وأحيانًا أعمل على مشاريع روبوتية شخصية في وقت فراغي.

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

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

الروبوتات لا تزال موجودة، لا تزال تخدم الباحثين، ولا تزال تمكّن الأعمال المهمة. وهذا أمر رائع حقًا.