میری روبوٹکس تحقیق کا باب

یہ تحریر روبوٹکس کے حوالے سے میرے سفر کو بیان کرتی ہے، جو 2015 میں ہائی اسکول کے دوران FRC میں روبوٹکس کے لیے اپنے شوق کی دریافت سے شروع ہوا اور فروری 2021 سے ستمبر 2021 تک کولوراڈو اسکول آف مائنز کی ہیومن سینٹرڈ روبوٹکس (HCR) لیب میں تحقیقی معاون کے طور پر میرے وقت تک جاری رہا۔ یاد رہے کہ 2022 کے اواخر سے HCR لیب کولوراڈو اسکول آف مائنز سے یونیورسٹی آف میساچوسٹس ایمہرسٹ منتقل ہو چکی ہے، اور اس کی ویب سائٹ بھی hcr.mines.edu سے hcr.cs.umass.edu منتقل ہو گئی ہے۔

پس منظر

میں نے کولوراڈو اسکول آف مائنز میں اپنی انڈرگریجویٹ تعلیم خزاں 2018 کے سمسٹر میں شروع کی۔ میرا تخصص کمپیوٹر سائنس تھا، جس میں روبوٹکس اور ذہین نظاموں پر توجہ مرکوز تھی۔ اور میں نے بہار 2022 میں گریجویشن کی۔

میں خوش قسمت تھا کہ مجھے زندگی میں بہت جلد اپنے شوق کو دریافت کرنے کا موقع مل گیا۔ ہائی اسکول کے دوران، میں نے یہ جاننے میں خاصا وقت صرف کیا کہ مجھے کیا پسند ہے اور میں کس کام میں اچھا ہو سکتا ہوں۔ کچھ آزمائش اور غلطی کے بعد، میں یہ سمجھنے میں کامیاب رہا کہ میرا شوق کمپیوٹر سائنس ہے۔ لیکن اسی دوران مجھے یہ بھی معلوم ہوا کہ کوڈ کے ذریعے چیزیں بنانے سے مجھے بے حد محبت ہے۔

مائنز میں مجھے ڈاکٹر ہاؤ ژانگ کی نگرانی میں مائنز کی ہیومن سینٹرڈ روبوٹکس (HCR) لیب میں کام کرنے کا موقع ملا۔ میری ڈاکٹر ژانگ سے پہلی ملاقات بہار 2020 میں ان کی کلاس “ہیومن سینٹرڈ روبوٹکس” (CSCI473) کے ذریعے ہوئی، اور COVID اور کورس ورک کی افراتفری کے بعد، مجھے بہار 2021 کے آغاز میں ان کی لیب میں کام کرنے کا موقع ملا۔

ہیومن سینٹرڈ روبوٹکس (CSCI473) کلاس

مائنز کی ہیومن سینٹرڈ روبوٹکس (CSCI473) میری کالج کی تعلیم کے دوران ان چند کلاسوں میں سے ایک تھی جنہوں نے مجھ پر گہرا اثر ڈالا۔ یہ کلاس ڈاکٹر ہاؤ ژانگ نے پڑھائی۔ کلاس کے لیے ہمارا پورا گریڈ صرف تین منصوبوں پر مشتمل تھا، جن میں سے ہر ایک نے ایک مشکل مسئلہ پیش کیا اور روبوٹکس کے بنیادی تصورات متعارف کرائے۔ ان منصوبوں میں شامل تھے:

1. روبوٹ آپریٹنگ سسٹم (ROS) سیکھنا
2. روبوٹ کے دیوار کے ساتھ چلنے کے لیے تقویتی تعلیم
3. اسکیلیٹن پر مبنی نمائندگیوں کا استعمال کرتے ہوئے انسانی رویوں کو سمجھنا

روبوٹ آپریٹنگ سسٹم (ROS) سیکھنا

یہ پہلا منصوبہ تھا جو ہمیں دیا گیا۔ اس منصوبے میں تین کام شامل تھے:

1. ترقیاتی ماحول ترتیب دینا
2. Gazebo سمیولیٹر کو سمجھنا
3. ROS کا “ہیلو ورلڈ” لکھنا

کام 1 اور 2 کے لیے ہمیں صرف اپنا ترقیاتی ماحول ترتیب دینا اور Gazebo کے تعارفی ٹیوٹوریل پر عمل کرنا تھا۔ اس میں شامل تھا:

• ROS Melodic ترتیب دینا، جو میں نے اپنے 2011 کے HP لیپ ٹاپ پر کیا، اور وہ اس کام کے لیے کافی تھا
• ROS اور Gazebo انسٹال اور تشکیل دینا
• gazebosim کے ٹیوٹوریل اور e-manual کے ٹیوٹوریل سے گزرنا

دوسری طرف، کام 3 ایک حقیقی چیلنج تھا۔ اس کام میں turtlesim استعمال کرتے ہوئے کچھوے سے مائنز کا “M” لوگو بنوانا تھا:

یہ کام، اگرچہ سننے میں آسان لگتا تھا، لیکن جتنا دکھائی دیتا تھا اس سے کہیں زیادہ مشکل تھا۔ اس منصوبے نے بالآخر مجھے اوپن-لوپ اور کلوزڈ-لوپ نظاموں کے تصور سے متعارف کرایا۔ منصوبے کی مکمل تفصیل کے لیے csci473-p1.pdf دیکھیں، یا ROS موو ٹرٹل منصوبے کے صفحے پر اس منصوبے اور میرے حل کے بارے میں مزید جان سکتے ہیں۔

روبوٹ کے دیوار کے ساتھ چلنے کے لیے تقویتی تعلیم

یہ دوسرا منصوبہ تھا جو ہمیں دیا گیا، اور یہ ان مشکل ترین منصوبوں میں سے ایک تھا جن پر میں نے کالج میں کبھی کام کیا۔ منصوبے کی تفصیل درج ذیل تھی:

اس منصوبے میں طلبہ ایسے تقویتی تعلیمی الگورتھم ڈیزائن اور نافذ کریں گے جو ایک خودمختار متحرک روبوٹ کو دیوار کے ساتھ چلنے اور رکاوٹوں سے ٹکرانے سے بچنے کی تعلیم دیں گے۔ طلبہ ROS Melodic میں Gazebo سمیولیشن استعمال کرتے ہوئے Triton نامی ہمہ جہتی متحرک روبوٹ کی نقل تیار کریں گے، اور انہیں فراہم کیے گئے ماحول کے نقشے کو استعمال کریں گے۔ طلبہ روبوٹ پر موجود لیزر رینج اسکینر کو محسوس کرنے اور سیکھنے کے لیے استعمال کریں گے، جبکہ روبوٹ کو اسٹیئرنگ اور رفتار کی کمانڈز کے ذریعے کنٹرول کیا جائے گا۔ طلبہ کے لیے ضروری ہے کہ وہ یہ منصوبہ Ubuntu 18.04 LTS پر چلنے والے ROS Melodic میں C++ یا Python استعمال کرتے ہوئے پروگرام کریں (یعنی وہی ترقیاتی ماحول جو منصوبہ 1 میں استعمال کیا گیا تھا)۔ اس کے علاوہ، طلبہ کے لیے ضروری ہے کہ وہ LATEX استعمال کرتے ہوئے معیاری IEEE روبوٹکس کانفرنسوں کے فارمیٹ کے مطابق ایک رپورٹ لکھیں۔

تقویتی تعلیمی الگورتھم کے لیے ہمیں Q-Learning استعمال کرنے کی ہدایت دی گئی تھی۔ ہم نے کلاس کی جانب سے فراہم کردہ Stingray Gazebo سمیولیشن ماحول بھی استعمال کیا۔ Stingray میں Triton ماڈل اور طبیعیات سے متعلق منطق شامل تھی۔ ہمیں روبوٹ کے چلنے کے لیے ایک بھول بھلیاں بھی فراہم کی گئی تھی۔ مجموعی طور پر، ماحول کچھ اس طرح دکھائی دیتا تھا:

میں نے اپنا حل کبھی GitHub یا ویب پر شائع نہیں کیا، کیونکہ وہ زیادہ اچھا نہیں تھا اور اس میں بہت سی خامیاں تھیں۔ اس کے علاوہ، کوڈ کو درست ماحول میں چلانا کافی مشکل اور پریشان کن ہے۔ تاہم، میرے پاس ایک ڈیمو ویڈیو موجود ہے جو میں نے کلاس میں جمع کرائی تھی، جس میں میرا حل دکھایا گیا ہے۔ آپ اسے یہاں دیکھ سکتے ہیں:

منصوبے کی مکمل تفصیل کے لیے csci473-p2.pdf دیکھیں۔

اسکیلیٹن پر مبنی نمائندگیوں کا استعمال کرتے ہوئے انسانی رویوں کو سمجھنا

تیسرے منصوبے کے لیے منصوبے کی تفصیل درج ذیل تھی:

اس منصوبے میں طلبہ اسکیلیٹن پر مبنی متعدد نمائندگیاں (قابلِ تسلیم 1) نافذ کریں گے اور Support Vector Machines (SVMs) (قابلِ تسلیم 2) استعمال کرتے ہوئے انسانی رویوں کی درجہ بندی کریں گے۔ اس مقصد کے لیے Kinect V1 سینسر سے جمع کیے گئے عوامی سرگرمی کے ڈیٹاسیٹ کو استعمال کیا جائے گا۔ مزید برآں، طلبہ کے لیے ضروری ہے کہ وہ قابلِ تسلیم 3 میں LATEX استعمال کرتے ہوئے معیاری IEEE روبوٹکس کانفرنسوں کے فارمیٹ کے مطابق ایک رپورٹ لکھیں۔

یہ منصوبہ مشکل تھا، لیکن دوسرے منصوبے جتنا مشکل نہیں تھا۔ بنیادی مقصد MSR Daily Activity 3D Dataset سے حاصل کردہ Kinect V1 سینسر ڈیٹا اور Support Vector Machines استعمال کرتے ہوئے بعض انسانی حرکات یا رویوں کی درجہ بندی کرنا تھا۔ منصوبے کی مکمل تفصیل کے لیے csci473-p3.pdf دیکھیں، یا Predict Human Actions Using LIBSVM بلاگ پوسٹ پر اس منصوبے اور میرے حل کے بارے میں مزید جان سکتے ہیں۔

CSCI473 کا اختتام

CSCI473 میری انڈرگریجویٹ تعلیم کے دوران لی گئی بہترین کلاسوں میں سے ایک تھی، اگر بہترین نہ بھی ہو، جو میں نے مائنز میں لی۔ ان تمام منصوبوں نے مجھے بہت کچھ سکھایا اور مجھے ایسے منصوبوں کا ایک عمدہ مجموعہ بنانے کا موقع دیا جن پر غور کیا جا سکتا تھا اور جن کا اپنے ریزیومے میں حوالہ دیا جا سکتا تھا۔ یہ وہ پہلی کلاس بھی تھی جس میں مجھے محسوس ہوا کہ میں اپنے عنصر میں ہوں، کیونکہ میں کبھی اچھا ٹیسٹ دینے والا نہیں تھا لیکن منصوبے مکمل کرنے میں بہترین تھا۔ اسی کلاس کے ذریعے میری ڈاکٹر ہاؤ ژانگ سے بھی ملاقات ہوئی، جنہوں نے بالآخر مائنز کی ہیومن-سینٹرڈ روبوٹکس (HCR) لیب میں تحقیقی معاون کی حیثیت حاصل کرنے میں میری مدد کی۔

CS فیلڈ سیشن (موسمِ گرما 2020)

موسمِ گرما 2020 کے دوران، CSCI473 مکمل کرنے اور HCR لیب میں شامل ہونے کے درمیان، میں نے کولوراڈو اسکول آف مائنز میں اپنے CS انڈرگریجویٹ پروگرام کے حصے کے طور پر CSCI370 یا “ایڈوانسڈ سافٹ ویئر انجینئرنگ” لیا۔ CSCI370 ایک ایسا کورس ہے جس میں طلبہ کسی کمپنی کے لیے سافٹ ویئر سے متعلق حل ڈیزائن، نافذ اور دستاویزی شکل میں پیش کرتے ہیں۔ یہ طلبہ کو اپنے کورس ورک کے علم کو حقیقی دنیا کے کمپیوٹر سائنس مسائل پر لاگو کرنے کا موقع دیتا ہے۔ آپ کورس کے بارے میں یہاں مزید جان سکتے ہیں۔

کورس میں آپ یہ فیصلہ کر سکتے ہیں کہ آپ کس منصوبے یا کمپنی پر کام کریں گے۔ کورس میں ہر منصوبے اور کمپنی کی تفصیل پر مشتمل PDFs فراہم کی گئی تھیں۔ بالآخر میں نے Lunar Outpost نامی کمپنی کی جانب سے پیش کیے گئے ایک منصوبے پر کام کرنے کا فیصلہ کیا، جس کا نام تھا “بہتر قمری نیویگیشن کے لیے حقیقی وقت میں پہیے کے پھسلاؤ کی شناخت اور خرابیوں کی اصلاح”۔ چونکہ یہ نام طویل ہے، اس لیے اس منصوبے کو “پہیے کے پھسلاؤ کی شناخت” کا مستعار نام دے دیتے ہیں۔

مسئلہ

Lunar Outpost ایک اسٹارٹ اپ ہے جو خودمختار قمری روورز بنانے کی کوشش کر رہا ہے۔ چاند پر بہت سی قمری گرد موجود ہے جو پہیوں کے بہت زیادہ پھسلنے کا سبب بنتی ہے۔ یہ صورتِ حال مثالی نہیں ہے، کیونکہ پہیوں کا پھسلاؤ خودمختار نظاموں کو ان کے حقیقی دنیا کے مقام کا تعین کھو دینے کا سبب بن سکتا ہے۔ زمین پر اس مسئلے کو GPS ڈیٹا استعمال کرتے ہوئے پہیوں کے پھسلاؤ سے پیدا ہونے والے کسی بھی انحراف کی اصلاح کے ذریعے حل کیا جاتا ہے۔ لیکن GPS کا مسئلہ یہ ہے کہ یہ صرف اس لیے کام کرتا ہے کہ 30+ نیویگیشن سیٹلائٹس مسلسل زمین کے گرد مدار میں گردش کرتے اور منفرد سگنلز منتقل کرتے رہتے ہیں، جو کمپیوٹروں کو اپنا مقام حساب کرنے کی اجازت دیتے ہیں۔ لیکن چاند پر فی الحال GPS جیسی کوئی چیز موجود نہیں ہے۔ یہ جانتے ہوئے، پہیوں کے پھسلاؤ کی شناخت کے لیے GPS کے علاوہ کوئی دوسرا طریقہ استعمال کرنا ہوگا۔ منصوبے کے مسئلے کی مزید تفصیلی رپورٹ یہاں دیکھی جا سکتی ہے۔

ٹیم

یہ منصوبہ کوئی سادہ منصوبہ نہیں تھا، اس لیے اسے ایک ٹیم کی صورت میں مکمل کرنا ضروری تھا۔ ٹیم کولوراڈو اسکول آف مائنز کے پانچ ساتھی طلبہ پر مشتمل تھی:

یہ منصوبہ کوئی سادہ منصوبہ نہیں تھا، اس لیے اسے ایک ٹیم کی صورت میں مکمل کرنا ضروری تھا۔ اس ٹیم میں Mehmet Yilmaz (میں)، Kane Bruce، Braedon O’Callaghan، Liam Williams، اور Kevin Grant شامل تھے۔

اس منصوبے کے لیے ضروری تھا کہ ہمیں کچھ ROS، C++، Python، Linux، Raspberry Pi، اور Arduino کا علم ہو۔ ہم میں سے بیشتر کو ان ٹیکنالوجیز میں سے ایک یا زیادہ کا تجربہ تھا، لیکن ROS کا تجربہ صرف میرے پاس تھا، کیونکہ میں نے بہار 2020 کے سمسٹر کے دوران اپنی ہیومن سینٹرڈ روبوٹکس (CSCI473) کلاس میں ROS استعمال کیا تھا۔ اس وجہ سے، ابتدا ہی میں، میں نے سب کو ROS اور اس کے لیے ترقی کرنے کے طریقے سے واقف کرانے میں مدد کی۔

چیلنجز

اس منصوبے میں بہت سے چیلنجز تھے۔ لیکن سب سے بڑا چیلنج جس کا ہمیں سامنا تھا، وہ جانچ کے لیے حقیقی دنیا کے روبوٹ تک رسائی نہ ہونا تھا۔ اس کی وجہ COVID تھی، جس نے ہر چیز کو دور دراز بنا دیا اور ہمیں Lunar Outpost کی لیبارٹری/عمارتوں میں کام کرنے سے روک دیا۔ اس وجہ سے ہمیں سمیولیشنز استعمال کرنی پڑیں۔

اس کے علاوہ، ہم نے WVU Navigation Lab کی کچھ علمی تحقیق کا جائزہ لیا تاکہ یہ اندازہ حاصل کیا جا سکے کہ Wheel Slippage کے مسئلے کو Lunar Outpost کے استعمال کے معاملے کے لیے کیسے حل کیا جا سکتا ہے، جو ہمارے لیے، بطور انڈرگریجویٹ سوفومورز اور جونیئرز، ہماری توقع سے زیادہ مشکل تھا۔

ایک اور چیلنج اس منصوبے پر کام کرنے کے لیے ہمارے پاس موجود وقت کی مقدار تھی۔ CSCI370 ایک ماہ کی کلاس ہے۔ لیکن یہ مسئلہ بذاتِ خود ایک بہت بڑا مسئلہ ہے، جسے بہت سی کمپنیاں اور ماہرینِ تعلیم کئی دہائیوں سے حل یا مکمل کرنے کی کوشش کر رہے ہیں۔ لہٰذا اس مسئلے کو حل کرنے کے لیے ایک مہینہ بالکل بھی کافی وقت نہیں ہے۔ لیکن ان تمام چیلنجز کے باوجود ہم نے جدوجہد جاری رکھی اور اس بات کو یقینی بنایا کہ کام مکمل کر کے پیش کریں۔

نتیجہ

تمام تحقیق اور ترقی کے مراحل سے گزرنے کے بعد، ہم نے طے کیا کہ چاند کی طبیعیات کو ڈیجیٹل طور پر درست انداز میں سمیولیٹ کرنا تقریباً ناممکن ہے، اس لیے سمیولیشن میں اس الگورتھم کو آزمانا حقیقتاً بے فائدہ ہے اور خلا اور چاند پر پہیوں کے پھسلنے کی شناخت کے حوالے سے کوئی بامعنی تحقیق فراہم نہیں کرے گا۔ ہم اس نتیجے پر پہنچے کہ ریت جیسی چیز اور حقیقی ہارڈویئر، مثلاً Husky روبوٹ، استعمال کرتے ہوئے مناسب جانچ کا ماحول قائم کرنا اس قسم کی تحقیق کے لیے کہیں زیادہ اہم ہے۔ ہم نے wheel slippage detection کوڈ کو ROS node کے طور پر کام کرنے کے لیے اپ ڈیٹ کیا، اور یہ درست طور پر کام کرتا تھا اور جانچ کے لیے حقیقی ہارڈویئر میں آسانی سے درآمد کیا جا سکتا تھا۔ اس منصوبے نے مجھے قائدانہ کردار ادا کرنے، اپنے ساتھیوں کو ROS development کے بارے میں تعلیم دینے، اور Python، ROS، اور Gazebo کے ساتھ تجربہ حاصل کرنے کا موقع دیا، جبکہ میں ایک ایسے پیچیدہ مسئلے سے نمٹ رہا تھا جس کا مجھے پہلے کبھی سامنا نہیں ہوا تھا۔ سب سے اہم بات یہ ہے کہ اس تجربے نے روبوٹکس کے لیے میرے شوق کو مزید مضبوط کیا اور اس شعبے میں تحقیق کرنے کی میری خواہش کو تقویت دی، جس نے میرے روبوٹکس کے سفر میں آنے والے اگلے مرحلے کی بنیاد رکھ دی۔

HCR Lab میں آغاز

CSCI473 مکمل کرنے، 2020 کے موسمِ گرما میں اپنا CS Field Session کرنے، اور Fall 2020 semester مکمل کرنے کے بعد، میں نے روبوٹکس میں تحقیق کرنے کا فیصلہ کیا۔ CSCI473 اور CS Field Session دونوں میں میرے تجربات اتنے عمدہ تھے کہ میں نے فیصلہ کیا کہ میں HCR Lab کے لیے تحقیق کرنا چاہتا ہوں۔ چونکہ میں ایک سال پہلے Dr. Zhang سے مل چکا تھا، اس لیے میں نے جنوری 2021 میں انہیں ای میل کر کے پوچھنے کا فیصلہ کیا کہ آیا لیبارٹری میں کوئی مواقع موجود ہیں۔ تقریباً 2 ہفتوں کے اندر، Dr. Zhang نے دلچسپی کا اظہار کیا، مجھے تحقیق کے اختیارات پیش کیے، اور لیبارٹری میں ایک کردار کی پیشکش کی۔ اس کے بعد میں نے فروری 2021 میں لیبارٹری کے لیے کام شروع کر دیا۔

تعارفی ویڈیو

یہ میری تعارفی ویڈیو ہے، جو میں نے HCR Lab میں شامل ہونے کے چند ماہ بعد ریکارڈ کی تھی۔ یہ مئی 2021 میں ریکارڈ کی گئی تھی اور اس تحقیق کا احاطہ کرتی ہے جس پر میں 2021 کے موسمِ گرما کے دوران HCR Lab میں توجہ مرکوز کرنے والا تھا:

میرا منصوبہ

HCR Lab میں اپنے وقت کے دوران، میری بنیادی توجہ Triton منصوبے پر رہی۔ Triton منصوبہ ایک موبائل روبوٹ ہے جسے Colorado School of Mines کی Human Centered Robotics Lab نے تیار کیا ہے۔ یہ ایک مثلث نما omni-wheel زمینی روبوٹ ہے جو NVIDIA کے Jetson Nano سے چلتا ہے۔

سادہ جائزے کے طور پر، Triton درج ذیل حصوں پر مشتمل تھا:

• NVIDIA Jetson Nano
• NVIDIA کا Seed Studio A205 Carrier Board
• Arduino Mega
• 64 GB Micro SD Card
• حسبِ ضرورت 3D پرنٹ شدہ جسم
• 3 میکینم پہیے
• 1 AR بیٹری
• بہتر برقی تقسیم اور وائرنگ کے لیے حسبِ ضرورت سرکٹس
• Intel کا Realsense D435 کیمرہ
• کچھ LEDs

اسے تقریباً 2018-2020 کے دوران تعلیمی مقاصد کے لیے ایک روبوٹ کے طور پر ڈیزائن، تعمیر اور تیار کیا گیا تھا۔ جب میں شامل ہوا، Triton کافی حد تک قائم ہو چکا تھا، اور لیبارٹری اس کا نیا ورژن بنانے پر غور کر رہی تھی۔ تاہم، Triton کا بنیادی مسئلہ اس کا سافٹ ویئر تھا۔ Triton حرکت کر سکتا تھا، چارج ہو سکتا تھا، اور بنیادی معنوں میں کام کر سکتا تھا، لیکن حقیقت میں کوئی ذہین کام نہیں کرتا تھا۔ اس میں مزید جدید حرکات کرنے کی صلاحیت بھی موجود نہیں تھی۔

اس مسئلے کو حل کرنے کے لیے، لیبارٹری نے ایک ایسا علاقہ قائم کیا جہاں ہم Triton کا سراغ رکھ سکتے تھے۔ اس مقصد کے لیے انہوں نے 2 میٹر بائی 2 میٹر کا ایک علاقہ بنایا، جس میں فرش سے تقریباً 6-7 فٹ بلند، مربع نما شکل میں 8 Optitrack Flex (Infrared Red) کیمرے نصب کیے گئے تھے۔

اس علاقے کی تعمیر کے ساتھ ساتھ، ہر Triton کے جسم کے اوپر تین سرمئی کروی گیندیں بھی منسلک کی گئی تھیں۔

اس ترتیب کے ذریعے ہم نے مؤثر طور پر اپنا ایک چھوٹے پیمانے کا GPS نظام بنا لیا تھا، جس سے ہمیں اپنی دلچسپی کے علاقے میں موجود Triton کے میٹروں میں عین محددات حاصل کرنے کی اجازت ملتی تھی۔ Optitrack کے انفرا ریڈ کیمروں اور مثلث نما شکل میں موجود Optitrack کی سرمئی گیندوں کو استعمال کرتے ہوئے، ہم اپنے علاقے میں Triton کے عین محددات کا تعین کر سکتے تھے۔ اس سے ہمیں حرکت میں بہتر درستگی کے لیے ایک closed-loop نظام نافذ کرنے کی اجازت ملی۔

Optitrack نظام مناسب طور پر calibrate کیے جانے پر تقریباً 120Hz کی رفتار سے sub-millimeter accuracy کے ساتھ پوزیشن اور سمت کا ڈیٹا فراہم کرتا تھا۔ ہر Triton کے تین عکاس markers ایک منفرد مثلثی نمونہ بناتے تھے، جسے نظام ایک rigid body کے طور پر track کر سکتا تھا۔ coordinate system کو اس طرح calibrate کیا گیا تھا کہ (0,0) tracking area کے مرکز میں ہو، جبکہ X اور Y axes کمرے کی ساخت کے ساتھ ہم سمت ہوں۔ لیکن اس قدر درست positioning data کے باوجود، Triton کو حرکت میں اب بھی مشکلات کا سامنا تھا۔

اس ترتیب کے ساتھ، Triton کو فراہم کی جانے والی ایک بنیادی خصوصیت کسی مخصوص coordinate تک پہنچنے کی صلاحیت تھی۔ صارف یا اس کا سافٹ ویئر اپنے دلچسپی کے علاقے کے اندر ایک (x, y) coordinate فراہم کر سکتا تھا۔ اس کے بعد روبوٹ اس coordinate تک جتنی تیزی، درستگی اور روانی سے ممکن ہو، حرکت کرتا۔ جب میں شامل ہوا، یہ خصوصیت موجود تھی، لیکن یہ بہت اچھی طرح کام نہیں کر رہی تھی۔ یہاں ایک سادہ animation ہے جو دکھاتی ہے کہ اصل moving logic کیسے کام کرتی تھی:

میں نے اصل solution کو عمل میں ریکارڈ نہیں کیا تھا، اس لیے میں نے یہ سادہ animation بنائی جو آپ کو پرانی moving logic کو عمل میں دکھاتی ہے۔ یہ جانتے ہوئے، اس طریقے میں مسائل کیا ہیں؟

1. یہ واقعی بہت سست ہے
2. یہ روبوٹ کو کسی مخصوص نقطے تک پہنچنے کے لیے بہت زیادہ جگہ گھیرنے پر مجبور کرتا ہے۔ اس کی وجہ سے جب متعدد Tritons حرکت کر رہے ہوں تو ہمارے لیے اس solution کو استعمال کرنا مشکل ہو گیا۔

تو یہ رویہ کیوں ہو رہا تھا؟ مسئلہ یہ تھا کہ Triton پہلے مڑتا تھا، اپنے alpha کو تبدیل کرتے ہوئے، یہاں تک کہ مخصوص margin of error کے اندر target point کی سمت اشارہ کرنے لگتا۔ پھر وہ تیزی سے آگے بڑھتا، اور جب اس کا theta target سے مخصوص مقدار میں ہٹ جاتا تو رک کر دوبارہ مڑنا شروع کر دیتا، یہاں تک کہ alpha target goal کے لیے قابلِ قبول حد کے اندر آ جاتا۔ پھر وہ دوبارہ تیزی سے آگے بڑھتا اور یہ عمل اس وقت تک جاری رکھتا جب تک وہ نقطے تک نہ پہنچ جاتا۔ اس کے علاوہ، جیسے جیسے وہ goal point کے قریب پہنچتا جاتا، turning اور sprinting کی رفتار بہت کم ہوتی جاتی تاکہ یہ یقینی بنایا جا سکے کہ وہ goal point سے آگے نہ نکل جائے۔ اس کے نتیجے میں Triton کی حرکت غیر فطری ہو گئی، اسے target point تک پہنچنے میں بہت زیادہ وقت لگتا، اور کسی مخصوص target point تک پہنچنے کے لیے بہت زیادہ جگہ درکار ہوتی۔ لہٰذا ان تمام مسائل کی وجہ سے، اور یہ دیکھتے ہوئے کہ Triton منصوبے کی ترقی کے لیے یہ خصوصیت کتنی ضروری تھی، جب میں نے HCR Lab میں کام شروع کیا تو میرا پہلا کام زیادہ مؤثر solutions تیار کرنا تھا، جو Triton کو goal point تک بہتر انداز میں navigate کرنے کی اجازت دیتے۔

یہ جانتے ہوئے، میں نے اس مسئلے سے نمٹنے کے بہترین ممکنہ طریقے پر تحقیق کرنے میں بہت وقت صرف کیا۔ اتفاق سے، میں Mines میں Introduction to Feedback Control Systems (EENG307) نامی ایک کلاس لے رہا تھا۔ اس کلاس کے آغاز میں ہم نے Open-loop controllers اور Closed-loop controllers کے تصور کے بارے میں سیکھا۔ یہ جاننے کے بعد، اور اس کلاس کے پروفیسر اور اپنے ذہین روم میٹ کے ساتھ ہونے والی کچھ گفتگو کے بعد، یہ واضح ہو گیا کہ Triton کو goal point تک پہنچانے کا یہ مقصد ایک closed-loop system کا مسئلہ تھا۔

اب، وسیع پیمانے پر testing اور research کے بعد، میں نے Tritons کے لیے controller کے دو الگ طریقے تیار کیے:

طریقہ 1: Distance-Theta Controller

اس طریقے میں بیک وقت چلنے والے دو الگ proportional controllers استعمال کیے گئے:

• Distance Controller: target تک Euclidean distance کا حساب لگاتا تھا اور آگے/پیچھے کی velocity متعین کرنے کے لیے proportional gain لاگو کرتا تھا
• Theta Controller: روبوٹ کی موجودہ heading اور target کی جانب مطلوبہ heading کے درمیان angular error کا حساب لگاتا تھا، اور rotational velocity کے لیے ایک الگ proportional gain لاگو کرتا تھا

الگورتھم مسلسل target تک Euclidean distance اور روبوٹ کی موجودہ heading اور مطلوبہ سمت کے درمیان angular error کا حساب لگاتا تھا۔ بالترتیب linear اور angular velocities پیدا کرنے کے لیے دو الگ proportional gains لاگو کیے جاتے تھے۔

اس کے نتیجے میں Triton قدرتی طور پر ہدف کی طرف مڑتے ہوئے بیک وقت آگے بڑھنے لگا، جس سے ہموار خم دار راستے تشکیل پائے۔ اس کا بنیادی فائدہ یہ تھا کہ روبوٹ ہمیشہ اپنا اگلا رخ منزل کی طرف رکھتا تھا، جو کیمرہ پر مبنی ایپلی کیشنز کے لیے نہایت اہم تھا۔

طریقہ 2: X-Y کوآرڈینیٹ کنٹرولر

اس طریقے میں روبوٹ کو 2D پلاٹر کی طرح سمجھا گیا، جس میں X اور Y حرکت کو آزادانہ طور پر کنٹرول کیا جاتا تھا:

• X کنٹرولر: X-کوآرڈینیٹ کی خطا کی بنیاد پر مشرق-مغرب کی حرکت کو براہِ راست کنٹرول کرتا تھا
• Y کنٹرولر: Y-کوآرڈینیٹ کی خطا کی بنیاد پر شمال-جنوب کی حرکت کو براہِ راست کنٹرول کرتا تھا

اس عمل میں X اور Y کوآرڈینیٹ کی خطاؤں کو آزادانہ طور پر شمار کیا گیا، علیحدہ تناسبی گینز لاگو کیے گئے، اور پھر گردش کی میٹرکس استعمال کرتے ہوئے عالمی رفتار کے ان اجزا کو روبوٹ کے مقامی کوآرڈینیٹ فریم میں تبدیل کیا گیا۔ یہ تبدیلی اس لیے ضروری تھی کیونکہ روبوٹ کے اومنی-وہیل ڈرائیو ٹرین کو عالمی کوآرڈینیٹس کے بجائے اپنے ہی حوالہ جاتی فریم میں رفتار درکار تھی۔ اس طریقے نے اہداف تک جانے والے سب سے براہِ راست راستے پیدا کیے اور یہ نمایاں طور پر تیز تھا، لیکن روبوٹ کا رخ بدلتا رہتا تھا کیونکہ سمت کے لیے کوئی واضح کنٹرول موجود نہیں تھا۔

طریقہ #1 کے لیے، میں نے اپنے موو ٹرٹل (TurtleSim) بلاگ میں اس طریقے کی مکمل تفصیل بیان کی ہے۔ میں پُرزور سفارش کرتا ہوں کہ آپ یہ بلاگ پڑھیں تاکہ یہ جان سکیں کہ عمومی طور پر PID کنٹرولرز کیسے کام کرتے ہیں، نیز طریقہ #1 کیسے کام کرتا ہے۔ میں نے طریقہ #1 ROS کے TurtleSim کا استعمال کرتے ہوئے تیار کیا، پھر اس کو Triton میں منتقل کیا اور زیادہ حقیقی دنیا کے ماحول کو مدِنظر رکھنے کے لیے اس میں تبدیلیاں کیں۔

طریقہ #2 نے ایک بالکل مختلف لیکن اتنا ہی مؤثر طریقہ استعمال کیا۔ روبوٹ کے رخ اور ہدف تک فاصلے کے بارے میں سوچنے کے بجائے، یہ طریقہ حرکت کو کوآرڈینیٹ کے میدان کے مسئلے کے طور پر لیتا ہے۔ کنٹرولر مسلسل X اور Y دونوں سمتوں کی خطا کو الگ الگ شمار کرتا ہے۔ مثال کے طور پر، اگر روبوٹ کو (0,0) سے (2,3) تک حرکت کرنی ہو، تو وہ اسے X میں 2 میٹر اور Y میں 3 میٹر کی خطا کو درست کرنے کی ضرورت کے طور پر دیکھتا ہے۔ دو تناسبی کنٹرولرز بیک وقت کام کرتے تھے: ایک X-خطا کی بنیاد پر X سمت میں روبوٹ کی رفتار کو ایڈجسٹ کرتا تھا، جبکہ دوسرا Y سمت کی حرکت کو سنبھالتا تھا۔ اس سے ہدف تک زیادہ براہِ راست راستہ تشکیل پاتا تھا، بالکل اسی طرح جیسے 3D پرنٹر کا ہیڈ حرکت کرتا ہے، اور ہموار ترچھی حرکات ممکن ہوتی تھیں۔ روبوٹ کو اپنے ہدف کی طرف رخ کرنے کی ضرورت نہیں تھی، جس نے اس طریقے کو تنگ جگہوں یا ایسی صورتِ حال میں خاص طور پر مؤثر بنا دیا جہاں درست پوزیشننگ درکار ہو۔

دونوں طریقے اصل طریقے کے مقابلے میں نمایاں طور پر تیز اور زیادہ قابلِ اعتماد ثابت ہوئے۔ ان نئے طریقوں کو عملی صورت میں دیکھنے کے لیے Tritons in Action Playlist دیکھیں، جس میں تمام Tritons کو نئے طریقوں کے ساتھ عملی طور پر کام کرتے دکھایا گیا ہے۔

جو کام پہلے نقطہ بہ نقطہ سادہ حرکت کے لیے 30-45 سیکنڈ لیتا تھا، اب تقریباً 8-12 سیکنڈ میں مکمل ہو جاتا تھا۔ اس سے بھی اہم بات یہ تھی کہ Triton اب تنگ جگہوں میں زیادہ مؤثر طریقے سے راستہ بنا سکتا تھا، جو ہمارے متعدد روبوٹس والے منظرناموں کے لیے مفید ثابت ہوا۔

تیاری کے چیلنجز اور خرابیوں کی تلاش

ان کنٹرولرز کو نافذ کرنا آسان نہیں تھا اور اس میں خرابیوں کی تلاش کے کئی اہم چیلنجز شامل تھے:

کوآرڈینیٹ سسٹم کی تبدیلیاں: سب سے مشکل پہلوؤں میں سے ایک کوآرڈینیٹ کی تبدیلیوں کو درست طور پر انجام دینا تھا۔ Optitrack سسٹم اپنا ڈیٹا اپنے کوآرڈینیٹ فریم میں فراہم کرتا تھا، روبوٹ کا اپنا مقامی کوآرڈینیٹ فریم تھا، اور مجھے ان دونوں کے درمیان درست طور پر تبدیلی کرنی تھی۔ ابتدائی نفاذ میں روبوٹس غلط سمتوں میں حرکت کرتے تھے کیونکہ میں گردش کی میٹرکس کے حسابات کو آپس میں ملا بیٹھا تھا۔

حقیقی دنیا کا رویہ بمقابلہ مثالی رویہ: سب سے بڑا چیلنج ان حقیقی دنیا کے عوامل کو مدِنظر رکھنا تھا جو نصابی کنٹرول تھیوری میں نظر نہیں آتے۔ روبوٹ کے پہیوں میں رگڑ کی خصوصیات مختلف تھیں، موٹرز یکساں ردِعمل نہیں دیتی تھیں، اور Optitrack سے کنٹرول سافٹ ویئر اور پھر روبوٹ کے Arduino تک مواصلاتی سلسلے میں ہمیشہ کچھ نہ کچھ تاخیر موجود رہتی تھی۔ میں نے ان طبعی حقائق کو مدِنظر رکھنے کے لیے تناسبی گینز کو بہتر بنانے اور ڈیڈ بینڈ فلٹرز شامل کرنے میں کئی ہفتے صرف کیے۔

ارتعاش اور استحکام کے مسائل: میرے ابتدائی نفاذ میں ارتعاش کے مسائل تھے، جن میں روبوٹس اپنے اہداف سے آگے نکل جاتے اور پھر آگے پیچھے ڈگمگاتے رہتے تھے۔ اس سے مجھے PID کنٹرولرز میں مشتق اجزا کی اہمیت اور گین کی درست ترتیب کی ضرورت کا علم ہوا۔ آخرکار میں نے مکمل PID کے بجائے احتیاط سے ترتیب دیے گئے گینز کے ساتھ زیادہ تر تناسبی کنٹرول اختیار کیا، کیونکہ زیادہ تر ایپلی کیشنز کے لیے سسٹم کی اندرونی نم داری کافی تھی۔

متعدد روبوٹس کی مداخلت: جب متعدد روبوٹس بیک وقت کام کر رہے تھے تو مجھے مداخلت کے غیر متوقع نمونے دریافت ہوئے۔ کبھی کبھی روبوٹس ایک ہی جگہ کے لیے “لڑتے” تھے یا تعطل کی ایسی صورتِ حال پیدا کر دیتے تھے جس میں وہ ایک دوسرے کا راستہ غیر معینہ مدت تک روکے رکھتے تھے۔ اس کے نتیجے میں مجھے ہم آہنگی کے طریقۂ کار اور تصادم سے بچاؤ کے الگورتھم نافذ کرنے پڑے۔

متعدد Triton کا کنٹرول سسٹم

جب میں نے ایک Triton کی حرکت کا مسئلہ حل کر لیا، تو لیب کا اگلا چیلنج متعدد Tritons کو بیک وقت مل کر کام کروانا تھا۔ یہ میری بنیادی توجہ کے شعبوں میں شامل ہو گیا اور بالآخر منصوبے میں ایک اہم योगदान ثابت ہوا۔

اصل سسٹم ایک وقت میں صرف ایک Triton کو کنٹرول کر سکتا تھا، جس سے تحقیق کے امکانات بہت محدود ہو گئے تھے۔ لیب ایسے منظرناموں کی نقل تیار کرنا چاہتی تھی جن میں متعدد خودمختار گاڑیوں کو اپنی حرکات میں ہم آہنگی پیدا کرنے کی ضرورت ہو، مثلاً خودکار گاڑیوں کا ٹریفک کے بہاؤ کو بہتر بنانے اور بہتر SLAM (بیک وقت مقامی تعین اور نقشہ سازی) نقشے بنانے کے لیے ایک دوسرے سے رابطہ کرنا۔

اس مسئلے کو حل کرنے کے لیے میں نے Python کی multiprocessing لائبریری استعمال کرتے ہوئے کثیر عمل کاری کا طریقہ نافذ کیا۔ ہر Triton کو اپنا مخصوص عمل دیا گیا جو مرکزی کنٹرول سسٹم کے ذریعے ہم آہنگ رہتے ہوئے آزادانہ طور پر چل سکتا تھا۔ اس سے متعدد Tritons ایک دوسرے کے کنٹرول لوپس میں مداخلت کیے بغیر بیک وقت حرکت کر سکتے تھے۔

متعدد روبوٹس کے طرزِ تعمیر کا ڈیزائن

میرے تیار کردہ سسٹم کے طرزِ تعمیر میں کئی اہم اجزا شامل تھے:

مرکزی کنٹرولر کا عمل: یہ مرکزی ہم آہنگ کنندہ کے طور پر کام کرتا تھا، صارف کے انٹرفیس کے تعاملات، راستے کی منصوبہ بندی، اور روبوٹس کے درمیان اعلیٰ سطحی ہم آہنگی کو سنبھالتا تھا۔ یہ عالمی حالت برقرار رکھتا اور انفرادی روبوٹ کے اعمال کو احکامات بھیجتا تھا۔

انفرادی روبوٹ کے اعمال: ہر Triton کا اپنا مخصوص Python عمل تھا جو یہ کام سنبھالتا تھا:

• تقریباً 50Hz پر حقیقی وقت میں PID کنٹرول کے حسابات
• روبوٹ کے ہارڈویئر (Arduino/Jetson) کے ساتھ مواصلت
• مقامی راستے پر عمل درآمد اور رکاوٹوں سے بچاؤ
• مرکزی کنٹرولر کو حالت کی رپورٹ واپس بھیجنا

مشترکہ میموری کے ذریعے مواصلت: میں نے اعمال کے درمیان مؤثر مواصلت کے لیے Python کی multiprocessing.shared_memory اور Queue اشیا استعمال کیں۔ اس سے نیٹ ورک مواصلت کے اضافی بوجھ کے بغیر حقیقی وقت میں ہم آہنگی ممکن ہوئی۔

ہم آہنگی کے طریقۂ کار: تصادم سے بچنے جیسے مواقع پر متعدد روبوٹس کے درمیان تنازعات روکنے کے لیے میں نے سیمفورز اور لاکس نافذ کیے، جن کی مدد سے روبوٹس کام کی جگہ کے مخصوص حصوں تک خصوصی رسائی کی درخواست کر سکتے تھے۔

چیلنج یہ تھا کہ تمام روبوٹس اپنے کنٹرول لوپس آزادانہ طور پر چلا سکیں اور اس کے ساتھ عالمی ہم آہنگی بھی برقرار رہے۔ ہر روبوٹ کا عمل اپنے PID حسابات چلاتا اور موٹر کے احکامات براہِ راست ہارڈویئر کو بھیجتا تھا، جبکہ مرکزی عمل تصادم سے بچاؤ اور راستے کی منصوبہ بندی جیسی اعلیٰ سطحی ہم آہنگی سنبھالتا تھا۔

متعدد Tritons کے سسٹم نے تحقیق کے بالکل نئے امکانات پیدا کر دیے۔ اب ہم یہ نقل تیار کر سکتے تھے:

• گاڑی سے گاڑی مواصلت کے منظرنامے
• رکاوٹوں سے بچاؤ کے ساتھ مربوط راستے کی منصوبہ بندی
• جھنڈ کی روبوٹکس کے طرزِ عمل
• متعدد ایجنٹوں کی SLAM نقشہ سازی
• تشکیل کا کنٹرول اور پیروی کے طرزِ عمل

متعدد Tritons کے بیک وقت چلنے کی صورت میں لیب کا سیٹ اپ کچھ یوں دکھائی دیتا تھا:

میں نے ایک صارف دوست انٹرفیس بھی تیار کیا جس کے ذریعے محققین ہر Triton کے لیے راستے بصری طور پر متعین کر سکتے تھے۔ آپ literally وہ راستہ بنا سکتے تھے جس پر آپ چاہتے تھے کہ ہر روبوٹ چلے، اور وہ کامل ہم آہنگی کے ساتھ ان راستوں پر عمل کرتے تھے۔ یہ پیچیدہ تجربات ترتیب دینے کے لیے بے حد مفید تھا، کیونکہ ہر حرکت کو دستی طور پر کوڈ کرنے کی ضرورت نہیں رہتی تھی۔

یہ سسٹم بیک وقت 5 Tritons تک سنبھال سکتا تھا، جن میں سے ہر ایک اپنے PID کنٹرولرز چلاتا، جبکہ مرکزی کنٹرول سسٹم کے ذریعے ان کے درمیان ہم آہنگی برقرار رکھی جاتی تھی۔ کارکردگی متاثر کن تھی، کیونکہ تمام روبوٹس ایک ٹیم کے طور پر کام کرتے ہوئے بھی اپنی انفرادی درستگی برقرار رکھتے تھے۔

یہاں ایک پلے لسٹ ہے جس میں Tritons کو عملی طور پر دکھایا گیا ہے، ایک روبوٹ کے کنٹرول سے لے کر متعدد روبوٹس کی ہم آہنگی تک: Tritons کے عملی مظاہرے کی پلے لسٹ

گہرائی کے سینسر کا انضمام اور کوآرڈینیٹ کی درستی

ایک اور بڑی پیش رفت جس پر میں نے کام کیا، اس میں ہر Triton پر نصب Intel RealSense D435 گہرائی والے کیمروں کا استعمال شامل تھا۔ اگرچہ Optitrack سسٹم نے ہمیں انتہائی درست پوزیشننگ کا ڈیٹا فراہم کیا، لیکن میں یہ جانچنا چاہتا تھا کہ روبوٹس اپنی فضائی آگاہی بہتر بنانے اور کوآرڈینیٹ کی غلطیوں کو درست کرنے کے لیے اپنے آن بورڈ سینسرز کو کس طرح استعمال کر سکتے ہیں۔

خیال یہ تھا کہ Tritons اپنے قریبی علاقے میں موجود دوسرے Tritons کا پتا لگانے اور ان کی پوزیشنوں کا باہمی حوالہ لینے کے لیے اپنے گہرائی والے سینسرز استعمال کر سکتے ہیں۔ اس کے متعدد مقاصد ہوتے:

1. غلطی کی درستی: اگر Optitrack سسٹم میں کیلیبریشن کا کوئی بہاؤ یا عارضی رکاوٹ پیدا ہو جاتی، تو روبوٹس درست کوآرڈینیٹ سسٹمز برقرار رکھنے کے لیے ایک دوسرے کی پوزیشنوں کی بصری تصدیق استعمال کر سکتے تھے۔

2. بہتر بنایا گیا SLAM: متعدد روبوٹس کے گہرائی کے سینسرز کے ساتھ مل کر کام کرنے سے، ہم ماحول کے کہیں زیادہ بھرپور نقشے بنا سکتے تھے جن میں اضافی ڈیٹا پوائنٹس شامل ہوتے۔

3. تصادم سے بچاؤ: حقیقی وقت میں گہرائی محسوس کرنے کی صلاحیت روبوٹس کو ایک دوسرے کا پتا لگانے اور ان سے بچنے کے قابل بناتی، خواہ مرکزی کنٹرول سسٹم میں مواصلاتی تاخیر ہی کیوں نہ ہو۔

میں نے ایسے الگورتھمز کے ساتھ تجربات شروع کیے جو Tritons کو یہ کام کرنے کے قابل بناتے:

• اپنی مخصوص تکونی شکل اور منعکس کرنے والے گولہ نما نشانات استعمال کرتے ہوئے دوسرے Tritons کا پتا لگانا
• گہرائی کے ڈیٹا کے ذریعے باہمی مقامات اور سمتوں کا حساب لگانا
• ان پیمائشوں کا Optitrack ڈیٹا کے ساتھ موازنہ کرکے فرق کی نشاندہی کرنا
• درستگی برقرار رکھنے کے لیے ممکنہ طور پر حقیقی وقت میں اپنے محدداتی نظام کو ایڈجسٹ کرنا

کمپیوٹر وژن کے تجربات

میں نے کمپیوٹر وژن پائپ لائن کے ساتھ تجربات کرنے میں خاصا وقت صرف کیا، جو کئی مراحل میں کام کرتی تھی:

گہرائی کے ڈیٹا کی پروسیسنگ: Intel RealSense D435 نے RGB اور گہرائی، دونوں کے ڈیٹا اسٹریمز فراہم کیے۔ میں نے بنیادی طور پر گہرائی کے ڈیٹا کے ساتھ کام کیا، جو 30Hz پر فاصلے کی پیمائشوں کی 640x480 صف کی صورت میں آتا تھا۔ پہلا چیلنج اس شور زدہ گہرائی کے ڈیٹا کو فلٹر کرنا تھا تاکہ بامعنی ہندسی معلومات اخذ کی جا سکیں۔

آبجیکٹ کا پتا لگانے کی کوششیں: میں نے متعدد مراحل پر مشتمل پتا لگانے والے الگورتھمز کے ساتھ تجربات کیے۔ مجھے گہرائی کی تصویر کو تقسیم کرکے فرش کی سطح پر موجود آبجیکٹس کی شناخت کرنے میں کچھ کامیابی ملی (دیواروں، چھت وغیرہ کو خارج کرتے ہوئے) اور ایسے آبجیکٹس تلاش کرنے کی کوشش کی جن کی جسامت کی خصوصیات درست ہوں، یعنی تقریباً 0.3x0.3 میٹر کا زمینی نقشہ۔ میں نے Triton کے مخصوص خاکے کی شناخت کے لیے کناروں کا پتا لگانے اور ہندسی تجزیے کا استعمال کرنے کی کوشش کی، جن کے نتائج ملے جلے رہے۔

نشانیوں کی شناخت کے تجربات: ہر Triton پر موجود تین منعکس کرنے والے گولے پتا لگانے کی سب سے زیادہ امید افزا خصوصیت معلوم ہوتے تھے۔ میں نے گہرائی کی تصویر میں تین روشن دھبوں کے مخصوص تکونی نمونے کی شناخت کے لیے blob detection الگورتھمز کے ساتھ تجربات کیے۔ قابو میں رکھی گئی روشنی کے حالات میں مجھے کچھ امید افزا نتائج ملے، اگرچہ یہ مستقل طور پر قابلِ اعتماد نہیں تھے۔

محدّداتی امتزاج کی تحقیق: میں نے بصارت پر مبنی مقام کے تخمینوں کو Optitrack ڈیٹا کے ساتھ ملانے کے طریقوں پر تحقیق کی، جس میں بنیادی Kalman filter کے نفاذ بھی شامل تھے۔ تصور یہ تھا کہ دستیاب ہونے کی صورت میں Optitrack ڈیٹا کو زیادہ وزن دیا جائے، لیکن ضرورت پڑنے پر بصارت کے ڈیٹا پر انحصار کیا جائے، اگرچہ لیب میں میرا وقت ختم ہونے سے پہلے میں اسے مکمل طور پر فعال نہیں کر سکا۔

کارکردگی کے چیلنجز: روبوٹ کے کنٹرول لوپس کے ساتھ ساتھ اس تمام پروسیسنگ کو حقیقی وقت میں چلانا مشکل ثابت ہوا۔ میں نے الگورتھمز کو تقریباً 10-15Hz پر چلانے کے لیے اصلاحی طریقوں کے ساتھ تجربات کیے، تاکہ Jetson Nano کی پروسیسنگ صلاحیتوں پر ضرورت سے زیادہ بوجھ نہ پڑے۔

بدقسمتی سے، میں اس کمپیوٹر وژن کے کام کو مکمل طور پر مکمل کرنے سے پہلے لیب چھوڑنے پر مجبور ہوگیا۔ اگرچہ مجھے ابتدائی طور پر کچھ امید افزا نتائج ملے اور میں نے گہرائی کے سینسر کی پروسیسنگ کے بارے میں بہت کچھ سیکھا، لیکن میں سسٹم کو مکمل طور پر قابلِ اعتماد حالت تک نہیں پہنچا سکا۔ یہ تحقیق کی ایک دلچسپ سمت بنی رہی جس پر ممکنہ طور پر دوسرے لوگ مزید کام کرسکتے تھے۔

یہاں کمپیوٹر وژن الگورتھمز کی جانچ کرتے ہوئے میری ایک ویڈیو ہے:

یہاں دکھایا گیا ہے کہ میرے تجربات کے دوران گہرائی کے سینسر کا منظر کیسا دکھائی دیتا تھا:

اگرچہ میں گہرائی کے سینسر کے انضمام کا کام مکمل نہیں کر سکا، لیکن اس تصور نے خودکار گاڑی چلانے کے منظرناموں کی نقل جیسے اطلاقات کے لیے امید پیدا کی، جہاں گاڑیوں کو صرف بیرونی بنیادی ڈھانچے پر انحصار کیے بغیر ایک دوسرے سے باخبر رہنے کی ضرورت ہوتی ہے۔ تحقیق کی جس سمت کی میں نے تلاش شروع کی تھی، وہ ممکنہ طور پر لیب میں مستقبل کے کام میں حصہ ڈال سکتی ہے۔

دستاویز کاری اور علم کا تحفظ

HCR Lab میں میری سب سے اہم خدمات میں سے ایک، اور شاید وہ خدمت جس پر مجھے سب سے زیادہ فخر ہے، تمام منصوبے کی دستاویزات کو منظم کرنا اور محفوظ رکھنا تھی۔ جب میں لیب میں شامل ہوا، تو Triton منصوبے کا علم متعدد پلیٹ فارمز اور فارمیٹس میں بکھرا ہوا تھا۔ اہم معلومات ان ذرائع میں پھیلی ہوئی تھیں:

• مختلف Google Drive اکاؤنٹس، جو فارغ التحصیل ہونے والے مختلف طلبہ سے وابستہ تھے
• پرانی ای میلز، جو ان باکسز میں دبی ہوئی تھیں
• بے ترتیب Dropbox فولڈرز
• متعدد GitHub ریپوزٹریز
• غیر مستقل تنظیم والی GitLab ریپوزٹریز
• ہاتھ سے لکھے ہوئے نوٹس، جنہیں صرف مخصوص لوگ ہی سمجھ سکتے تھے

یہ بکھری ہوئی دستاویز کاری ایک بہت بڑا مسئلہ تھی۔ نئے طلبہ صرف یہ سمجھنے کی کوشش میں کئی ہفتے صرف کردیتے تھے کہ آغاز کیسے کیا جائے، اور لوگوں کے فارغ التحصیل ہونے یا لیب چھوڑنے پر قیمتی علم مسلسل ضائع ہوتا رہتا تھا۔

میں نے اس مسئلے کو منظم طریقے سے حل کرنے کی ذمہ داری خود لی۔ میں نے Triton منصوبے سے متعلق دستاویزات، کوڈ، ویڈیو اور نوٹس کے ہر حصے کو تلاش کرنے میں بے شمار گھنٹے صرف کیے۔ پھر میں نے ہر چیز کو ایک واضح، منطقی ساخت کے ساتھ مرکزی GitLab ریپوزٹری میں منظم کیا۔

مرکزی دستاویز کاری میں یہ چیزیں شامل تھیں:

• تیاری کی رہنما کتابیں: شروع سے Tritons کو جوڑنے کے لیے مرحلہ وار ہدایات
• سافٹ ویئر کی تنصیب: ترقیاتی ماحول قائم کرنے کے لیے مکمل رہنما کتابیں
• کوڈ کی دستاویز کاری: واضح وضاحتوں کے ساتھ اچھی طرح تبصرہ شدہ کوڈ
• ہارڈ ویئر کی خصوصیات: پرزوں کی تفصیلی فہرستیں، وائرنگ کے خاکے اور PCB ڈیزائنز
• خرابیوں کے ازالے کی رہنما کتابیں: عام مسائل اور ان کے حل
• ویڈیو ٹیوٹوریلز: میں نے YouTube پر تعلیمی ویڈیوز بنائیں اور اپ لوڈ کیں، جن میں Optitrack کیلیبریشن کے تفصیلی ٹیوٹوریلز بھی شامل تھے:

میں نے دستاویز کاری کے معیارات بھی قائم کیے تاکہ مستقبل کی خدمات منظم اور قابلِ رسائی رہیں۔ میری بنائی ہوئی ریپوزٹری کی ساخت لیب میں بعد کے تمام کام کی بنیاد بن گئی۔

موجودہ دستاویز کاری کو صرف منظم کرنے کے علاوہ، میں نے کئی اصل رہنما کتابیں اور ٹیوٹوریلز بھی بنائے جنہوں نے علم کے ذخیرے میں موجود اہم خلا کو پُر کیا۔ ان میں لیب کے نئے اراکین کے لیے تنصیب کی تفصیلی ہدایات، خرابیوں کے ازالے کی جامع رہنما کتابیں، اور پیچیدہ طریقۂ کار کی ویڈیو وضاحتیں شامل تھیں۔

اس کا اثر فوری بھی تھا اور دیرپا بھی۔ نئے طلبہ ہفتوں کے بجائے دنوں میں کام سے واقف ہوسکتے تھے۔ میری بنائی ہوئی دستاویزاتی ریپوزٹری آج بھی لیب میں استعمال ہورہی ہے، میرے جانے کے کئی سال بعد بھی۔ یہ Triton منصوبے کے لیے معلومات کا واحد مستند ذریعہ بن گئی اور مستقبل کے محققین کے بے شمار گھنٹے/دن بچائے۔

رہنمائی اور علم کی منتقلی

HCR Lab میں میرے وقت کا سب سے زیادہ اطمینان بخش پہلو دوسروں کی رہنمائی کرنے اور اپنے حاصل کردہ علم کو بانٹنے کا موقع تھا۔ جیسے جیسے میرا کام آگے بڑھا اور میں Triton سسٹمز کے ساتھ زیادہ تجربہ کار ہوتا گیا، میں نے ٹیم کے نئے اراکین کی تربیت کی بڑھتی ہوئی ذمہ داری سنبھال لی۔

لیب میں آنے والے جانشینوں کی رہنمائی

جب میں اپنی ڈگری مکمل کرنے اور eBay میں اپنے کام پر توجہ دینے کے لیے بالآخر لیب چھوڑنے کی تیاری کررہا تھا، تو میں نے اس بات کو یقینی بنایا کہ دو ایسے لوگوں کو مکمل تربیت دوں جو میرے جانے کے بعد Triton منصوبے کی ذمہ داری سنبھالتے۔ یہ صرف انہیں یہ دکھانے کے بارے میں نہیں تھا کہ چیزیں کیسے کام کرتی ہیں، بلکہ اس بات کو یقینی بنانے کے بارے میں تھا کہ وہ بنیادی اصولوں کو حقیقی طور پر سمجھیں، تاکہ وہ جدت کا عمل جاری رکھ سکیں۔

میں نے ان کے ساتھ مل کر کام کرنے میں کئی ہفتے صرف کیے اور ان موضوعات کا جائزہ لیا:

• PID کنٹرول سسٹمز کی ریاضیاتی بنیادیں
• متعدد روبوٹس کو مربوط کرنے کے لیے ملٹی پروسیسنگ کا فنِ تعمیر
• گہرائی کے سینسر کا انضمام اور کمپیوٹر وژن الگورتھمز
• دستاویز کاری کا نظام اور اسے برقرار رکھنے کا طریقہ
• ڈیبگنگ کی تکنیکیں اور عام خرابی کے طریقے

علم کی منتقلی انتہائی جامع تھی۔ ہم نے حقیقی ڈیبگنگ سیشنز ایک ساتھ کیے، میں نے ان سے موجودہ کوڈ میں ترمیم اور توسیع کروائی، اور میں نے یہ یقینی بنایا کہ وہ آزادانہ طور پر نئے Tritons کو شروع سے ترتیب دے سکیں۔

ہائی اسکول رہنمائی پروگرام

شاید اس سے بھی زیادہ اطمینان بخش تجربہ لیب کے عوامی رابطہ پروگرام کے ذریعے ایک ہائی اسکول کی طالبہ کی رہنمائی کرنا تھا۔ یہ کسی شخص کو اس کی تعلیم کے ابتدائی اور تشکیل دینے والے مرحلے میں روبوٹکس، کمپیوٹر سائنس اور تحقیق سے متعارف کرانے کا ایک بہترین موقع تھا۔

میں نے ایک جامع نصاب تیار کیا جس میں یہ موضوعات شامل تھے:

کمپیوٹر سائنس کی بنیادی باتیں:

• Python کو بنیادی زبان کے طور پر استعمال کرتے ہوئے پروگرامنگ کے تصورات
• آبجیکٹ اورینٹڈ پروگرامنگ کا تعارف
• الگورتھمز اور ڈیٹا اسٹرکچرز کی سمجھ

روبوٹکس کے تصورات:

• سینسرز کیسے کام کرتے ہیں اور ان کے ساتھ انٹرفیس کیسے کیا جاتا ہے
• ایکچیویٹر کنٹرول اور موٹر سسٹمز
• خودکار سسٹمز اور فیڈبیک کنٹرول کی بنیادی باتیں

ROS (روبوٹ آپریٹنگ سسٹم):

• پبلش/سبسکرائب پیغام رسانی کے نظام کو سمجھنا
• نوڈز اور سروسز بنانا
• لانچ فائلز اور پیرامیٹر سرورز کے ساتھ کام کرنا

عملی منصوبے کا کام:

• ہم نے Triton کے سر پر موجود LED سسٹم کو کنٹرول کرنے والی ROS سروس بنانے میں تعاون کیا
• اس نے صاف، دستاویزی کوڈ لکھنا سیکھا جو ہمارے موجودہ سسٹمز کے ساتھ مربوط تھا
• اس کی بنائی ہوئی LED کنٹرول سروس Triton کے کوڈ بیس کا مستقل حصہ بن گئی

اس رہنمائی کو خاص بنانے والی بات یہ تھی کہ میں نے اسے پروگرامنگ کے بارے میں تقریباً کچھ نہ جاننے سے لے کر ایک فعال تحقیقی منصوبے میں بامعنی کوڈ شامل کرنے تک ترقی کرتے دیکھا۔ وہ “متغیر کیا ہوتا ہے؟” پوچھنے سے لے کر ROS مواصلاتی مسائل کو آزادانہ طور پر ڈیبگ کرنے اور اپنی سروس کے نفاذ لکھنے تک پہنچ گئی۔

اس کے تیار کردہ LED کنٹرول سسٹم نے محققین کو سادہ ROS کمانڈز کے ذریعے Triton کے سر کے LEDs کے رنگ اور پیٹرنز آسانی سے تبدیل کرنے کی اجازت دی۔ یہ شاید سادہ معلوم ہو، لیکن اس کے لیے ROS کے آرکیٹیکچر، ہارڈویئر انٹرفیسنگ، اور سافٹ ویئر ڈیزائن پیٹرنز کو سمجھنا ضروری تھا۔ اس کی شراکت آج بھی لیب میں استعمال کی جا رہی ہے۔

مینٹورشپ میرے لیے بھی اتنی ہی تعلیمی تھی جتنی اس کے لیے۔ اس نے مجھے پیچیدہ تصورات کو قابلِ فہم حصوں میں تقسیم کرنے اور اس بات کے بنیادی اصولوں پر واقعی غور کرنے پر مجبور کیا کہ ہم کیا کر رہے تھے۔ کسی اور کو تعلیم دینے نے مجھے ایک بہتر انجینئر اور محقق بنایا۔

پی ایچ ڈی کی تحقیق کے ساتھ تعاون

لیب میں میرے وقت کے سب سے زیادہ پیشہ ورانہ طور پر اطمینان بخش پہلوؤں میں سے ایک Peng کے ساتھ قریبی تعاون تھا، جو ایک پی ایچ ڈی طالب علم تھا اور جس کی تحقیق خودکار گاڑیوں کے الگورتھمز پر مرکوز تھی۔ Triton سسٹم میں کی گئی میری سافٹ ویئر بہتریوں نے اس کی ڈاکٹریٹ تحقیق میں مدد فراہم کی۔

Peng کی تحقیق میں خودکار گاڑیوں کے منظرناموں کی نقل کرنے کے لیے درست اور قابلِ اعتماد کثیر روبوٹ ہم آہنگی درکار تھی۔ حرکت کے کنٹرول اور کثیر روبوٹ سسٹمز میں میری بہتریوں سے پہلے، ان تجربات کا انعقاد کہیں زیادہ مشکل تھا۔ روبوٹس سست، کم درست، اور ایک دوسرے کے ساتھ مؤثر طریقے سے کام کرنے سے قاصر تھے۔

میری شراکت نے Peng کی تحقیق میں کئی شعبوں میں مدد کی:

چوراہوں کے انتظام کے مطالعات: بہتر PID کنٹرولرز اور کثیر روبوٹ ہم آہنگی کے ساتھ، Peng ایسے چوراہوں کے منظرناموں کی نقل کر سکتا تھا جہاں متعدد “گاڑیوں” (Tritons) کو اپنی حرکات میں ہم آہنگی پیدا کرنا ہوتی تھی۔ بہتر ٹائمنگ اور پوزیشننگ نے ان مطالعات کو زیادہ قابلِ عمل بنانے میں مدد کی۔

گاڑی سے گاڑی مواصلات: میرے تیار کردہ ملٹی پروسیسنگ فریم ورک نے Peng کو نقلی گاڑیوں کے درمیان مواصلاتی پروٹوکولز نافذ کرنے اور ان کی جانچ کرنے کی اجازت دی۔ ہر Triton دوسروں کے ساتھ ہم آہنگی برقرار رکھتے ہوئے فیصلے کر سکتا تھا، بالکل اسی طرح جیسے خودکار گاڑیوں کو کام کرنے کی ضرورت پڑ سکتی ہے۔

SLAM اور نقشہ سازی کی تحقیق: گہرائی کے سینسر کے انضمام پر کیے گئے کام نے Peng کو اس کی بیک وقت مقام یابی اور نقشہ سازی کی تحقیق کے لیے اضافی ڈیٹا فراہم کیا۔ مربوط سینسنگ صلاحیتوں کے حامل متعدد روبوٹس نے زیادہ جامع نقشہ سازی کے تجربات کو ممکن بنایا۔

ہماری شراکت کو خاص طور پر قیمتی بنانے والی بات یہ تھی کہ یہ صرف میری طرف سے اس کی تحقیق میں مدد نہیں تھی، بلکہ ایک حقیقی شراکت داری تھی۔ خودمختار گاڑیوں کے نظریاتی پہلوؤں کے بارے میں Peng کی سمجھ نے میری عملی تنصیبات کی رہنمائی میں مدد کی۔ اس کی رائے اور ضروریات نے مجھے سسٹمز کو زیادہ مضبوط اور قابل بنانے پر اکسایا۔

ہم نے لیب میں کئی گھنٹے اکٹھے گزارے، منظرناموں کی ڈیبگنگ کی، مختلف کنٹرول حکمتِ عملیوں پر گفتگو کی، اور یہ دریافت کیا کہ Triton پلیٹ فارم کیا کچھ انجام دے سکتا ہے۔ Peng ایک ساتھی کے ساتھ ساتھ دوست بھی بن گیا، اور اس کے ساتھ کام کرنے نے مجھے اس بارے میں بہت کچھ سکھایا کہ علمی تحقیق حقیقت میں کیسے کام کرتی ہے۔

میرے بنائے ہوئے سسٹمز Peng کے مقالۂ تحقیق کے کام کا ایک مفید حصہ بن گئے۔ اپنی عملی انجینئرنگ شراکتوں کو خودمختار گاڑیوں کی ٹیکنالوجی میں تحقیق کی معاونت کرتے دیکھنا واقعی باعثِ اطمینان تھا۔ اس نے خود کو اس بات میں میری دلچسپی کو مزید مضبوط کیا کہ ٹھوس انجینئرنگ اور تحقیق مل کر مفید نتائج کیسے پیدا کر سکتی ہیں۔

لیب چھوڑنے کے بعد بھی Peng اور میں رابطے میں رہے۔ یہ جاننا کہ میری روانگی کے بعد بھی میرا کام اہم تحقیق میں اپنا حصہ ڈالتا رہا، انتہائی اطمینان بخش تھا۔

LLM سے پہلے کے ترقیاتی دور کا نقطۂ نظر

یہ بات قابلِ ذکر ہے کہ یہ تمام کام سافٹ ویئر ڈویلپمنٹ کے LLM سے پہلے کے دور میں مکمل کیا گیا تھا۔ یہ سب کچھ 2020 سے 2021 (بنیادی طور پر 2021) کے درمیان ہوا، اس سے پہلے کہ ChatGPT، Claude، Perplexity، یا Cursor IDE جیسے مصنوعی ذہانت سے چلنے والے ڈویلپمنٹ ٹولز موجود ہوتے۔

کوڈ کی ہر سطر شروع سے لکھی گئی، ہر الگورتھم پر علمی مقالوں اور درسی کتابوں کے ذریعے تحقیق کی گئی، اور ہر ڈیبگنگ سیشن میں پرنٹ اسٹیٹمنٹس، ڈیبگرز، اور منظم جانچ جیسے روایتی طریقے شامل تھے۔ جب میں کسی کوآرڈینیٹ ٹرانسفارمیشن یا PID ٹیوننگ کے مسئلے میں پھنس جاتا، تو میں کسی AI اسسٹنٹ سے تصور کی وضاحت یا مسئلے کی ڈیبگنگ میں مدد کے لیے نہیں کہہ سکتا تھا۔

اس سے ترقیاتی عمل نمایاں طور پر زیادہ مشکل، لیکن زیادہ تعلیمی بھی بن گیا۔ مجھے یہ کام کرنے پڑتے تھے:

ہر چیز پر دستی طور پر تحقیق کرنا: PID کنٹرول تھیوری کو سمجھنے کا مطلب درسی کتابیں اور علمی مقالے پڑھنا تھا۔ کوآرڈینیٹ ٹرانسفارمیشنز کو سمجھنے کے لیے ریاضی کو ہاتھ سے حل کرنا پڑتا تھا۔ عمل درآمد سے پہلے ہر تصور کو مکمل طور پر سمجھنا ضروری تھا۔

AI کی مدد کے بغیر ڈیبگنگ کرنا: جب روبوٹس غیر متوقع سمتوں میں حرکت کرتے یا اہداف کے گرد ارتعاش کرتے، تو مجھے منطق کے ہر مرحلے کا منظم طریقے سے سراغ لگانا، ڈیبگ آؤٹ پٹس شامل کرنا، اور ایک ایک کر کے مفروضوں کی جانچ کرنا پڑتی تھی۔ ممکنہ مسائل تجویز کرنے یا خرابی کے نمونوں کی تشریح میں مدد دینے کے لیے کوئی AI موجود نہیں تھا۔

بنیادی اصولوں سے سیکھنا: اس صلاحیت کے بغیر کہ میں فوراً پوچھ سکوں، “روبوٹکس کے لیے Python میں ملٹی پروسیسنگ کیسے نافذ کروں؟"، مجھے بنیادی تصورات کو گہرائی سے سمجھنا پڑا۔ اس نے مجھے ہم وقتی پروگرامنگ، کنٹرول سسٹمز، اور کمپیوٹر وژن میں مضبوط بنیاد قائم کرنے پر مجبور کیا۔

دستاویز کاری انتہائی اہم تھی: چونکہ میں بعد میں کوڈ کی وضاحت کے لیے AI پر انحصار نہیں کر سکتا تھا، اس لیے مجھے انتہائی واضح دستاویز کاری اور تبصرے لکھنے پڑتے تھے۔ یہ نظم و ضبط بعد میں دوسروں کو علم منتقل کرتے وقت بے حد قیمتی ثابت ہوا۔

پیچھے مڑ کر دیکھنے پر، اگرچہ جدید AI ٹولز ترقی کے کئی پہلوؤں کو تیز کر دیتے، لیکن ان کے بغیر کام کرنے نے مجھے گہری مسئلہ حل کرنے کی مہارتیں اور بنیادی سسٹمز کی زیادہ جامع سمجھ پیدا کرنے پر مجبور کیا۔ یہ سوچنا دلچسپ ہے کہ آج کے دستیاب ترقیاتی ٹولز کے ساتھ یہ منصوبہ کتنا مختلف ہو سکتا تھا۔

چھوڑنے کا مشکل فیصلہ

جتنا مجھے HCR لیب میں کام کرنا پسند تھا، 2021 کے آخر تک مجھے ایک ایسے مشکل فیصلے کا سامنا کرنا پڑا جس کا سامنا بہت سے طلبہ کرتے ہیں: متعدد مواقع اور ذمہ داریوں میں توازن قائم کرنا۔ میں بیک وقت eBay میں کل وقتی سافٹ ویئر انجینئر کے طور پر کام کر رہا تھا، Mines میں کمپیوٹر سائنس کی ڈگری مکمل کر رہا تھا، اور HCR لیب میں تحقیق میں حصہ لے رہا تھا۔

eBay کا موقع اہم تھا؛ یہ میرا پہلا بڑا سافٹ ویئر انجینئرنگ کا عہدہ تھا، اس نے صنعت کا انمول تجربہ فراہم کیا، اور مجھے ایک مستحکم آمدنی دی۔ تاہم، کل وقتی کام برقرار رکھنا، اپنی ڈگری مکمل کرنا، اور تحقیق میں بامعنی طور پر حصہ لینا محض ناقابلِ عمل تھا۔ کسی نہ کسی چیز کو قربان کرنا تھا۔

جب میں نے ڈاکٹر Zhang سے لیب کے کام پر زیادہ توجہ دینے کے لیے اپنے کورسز کا بوجھ ممکنہ طور پر کم کرنے کے بارے میں بات کی، تو انہوں نے سختی سے اس کے خلاف مشورہ دیا۔ ان کی دلیل درست تھی: میری ڈگری مکمل کرنا ترجیح ہونی چاہیے، اور eBay میں صنعت کا تجربہ میرے کیریئر کی ترقی کے لیے قیمتی ہوگا۔ ان کا خیال تھا کہ تحقیق پر توجہ دینے کے لیے کلاسز چھوڑ دینا، اگرچہ پُرکشش تھا، طویل مدت میں بہترین فیصلہ نہیں ہو سکتا۔

چنانچہ ستمبر 2021 میں، لیب میں تقریباً 8 ماہ کی بھرپور محنت کے بعد، میں نے اپنی ڈگری مکمل کرنے اور eBay میں اپنے کام پر توجہ دینے کے لیے تحقیقی معاون کے کردار سے پیچھے ہٹنے کا مشکل فیصلہ کیا۔ اس وقت یہ ان مشکل ترین پیشہ ورانہ فیصلوں میں سے ایک تھا جو مجھے کرنا پڑا۔

لیب کو باضابطہ طور پر چھوڑنے کے بعد بھی، جب بھی کسی کو میرے بنائے ہوئے سسٹمز کے بارے میں مدد درکار ہوتی، میں مدد فراہم کرتا رہا۔ میں ضرورت کے مطابق دستاویز کاری کو اپ ڈیٹ کرتا، ڈیبگنگ سے متعلق سوالات کے جوابات دیتا، اور دور سے مسائل حل کرنے میں مدد کرتا۔ میرے قائم کردہ روابط اور منصوبے کی کامیابی میں میری کی گئی سرمایہ کاری صرف اس لیے ختم نہیں ہو گئی کہ میں اب باضابطہ طور پر ٹیم کا حصہ نہیں رہا تھا۔

غور و فکر اور ماضی پر نظر

اب، 2025 میں، چار سال بعد، میں خود کو اس وقت کے بارے میں پیچیدہ جذبات کے ساتھ غور کرتے ہوئے پاتا ہوں۔ میرے کیریئر کا راستہ ویب ڈویلپمنٹ اور AI/ML انجینئرنگ کی جانب گہرائی تک چلا گیا، ایسے شعبے جو بے حد اطمینان بخش رہے ہیں اور جنہوں نے ترقی اور اثراندازی کے زبردست مواقع فراہم کیے ہیں۔

پھر بھی میرے اندر کا ایک حصہ سوچتا ہے، “اگر ایسا ہوتا تو کیا ہوتا؟” روبوٹکس میرا حقیقی شوق تھا، اور سچ کہوں تو اب بھی ہے۔ جسمانی سسٹمز کے ساتھ کام کرنے، اپنے کوڈ کو حقیقی دنیا کی حرکت اور رویے میں تبدیل ہوتے دیکھنے میں کچھ ایسی بات ہے جس کی ویب ڈویلپمنٹ، حتیٰ کہ AI کا کام بھی، پوری طرح نقل نہیں کر سکتا۔

میں کبھی کبھی سوچتا ہوں کہ اگر میں نے کوئی مختلف راستہ اختیار کیا ہوتا تو کیا ہوتا۔ اگر مجھے روبوٹکس کی تحقیق میں رہنے کا کوئی طریقہ مل گیا ہوتا تو کیا ہوتا؟ اگر میں نے اپنی انڈرگریجویٹ ڈگری مکمل کرنے کے فوراً بعد گریجویٹ اسکول میں داخلہ لیا ہوتا تو کیا ہوتا؟ اگر میں نے صنعت کے تجربے کے مقابلے میں لیب کے کام کو ترجیح دینے کا انتخاب کیا ہوتا تو کیا ہوتا؟

لیکن میں یہ بھی تسلیم کرتا ہوں کہ ہر راستے کے اپنے سمجھوتے ہوتے ہیں۔ ویب ڈویلپمنٹ اور AI میں جو مہارتیں میں نے پیدا کیں، وہ بے حد قیمتی ثابت ہوئی ہیں۔ صنعت کے تجربے نے مجھے بڑے پیمانے پر سافٹ ویئر انجینئرنگ، صارف کے تجربے کے ڈیزائن، اور ایسی مصنوعات بنانے کے عملی چیلنجز کے بارے میں سکھایا جنہیں لاکھوں لوگ استعمال کرتے ہیں۔ ان تجربات نے مجموعی طور پر مجھے ایک بہتر انجینئر بنایا ہے۔

HCR لیب میں کیا گیا میرا کام آج بھی اس بات پر اثر انداز ہوتا ہے کہ میں مسائل سے کیسے نمٹتا ہوں۔ PID کنٹرول سسٹمز کے لیے درکار منظم سوچ اس طریقے میں نظر آتی ہے جس سے میں سافٹ ویئر سسٹمز میں فیڈبیک لوپس ڈیزائن کرتا ہوں۔ دستاویز کاری اور علم کے تحفظ کی جو مہارتیں میں نے پیدا کیں، وہ اس کے بعد ہر کردار میں بے حد قیمتی ثابت ہوئی ہیں۔ مینٹورشپ اور تعلیم دینے کے تجربے نے اس انداز کو تشکیل دیا ہے جس سے میں جونیئر ڈویلپرز کے ساتھ کام کرتا ہوں اور ٹیم کے اندر علم کے اشتراک میں حصہ لیتا ہوں۔

سب سے اہم بات یہ ہے کہ اس تجربے نے مجھے سکھایا کہ میں ایسے مشکل تکنیکی مسائل پر کام کرتے ہوئے بہترین کارکردگی دکھاتا ہوں جن کا حقیقی دنیا پر اثر ہو۔ چاہے وہ روبوٹ کی حرکت کے الگورتھمز کو بہتر بنانا ہو یا ایسے AI سسٹمز بنانا جو صارفین کو اپنے مقاصد حاصل کرنے میں مدد دیں، اطمینان ان مشکل مگر اہم مسائل کو حل کرنے سے حاصل ہوتا ہے۔

دیرپا اثر

HCR لیب کے تجربے پر نظر ڈالتے ہوئے، مجھے حیرت ہوتی ہے کہ میں نے نسبتاً مختصر عرصے میں کتنا کچھ حاصل کیا۔ میرے بنائے ہوئے سسٹمز نے بنیادی طور پر Triton پلیٹ فارم کے کام کرنے کا طریقہ بدل دیا، اور ان میں سے بہت سی بہتریاں آج بھی استعمال ہو رہی ہیں۔ میرے بنائے ہوئے دستاویز کاری کے ذخیرے نے پورے منصوبے کے لیے علمی بنیاد کا کام کیا۔ میرے قائم کردہ مینٹورشپ کے تعلقات نے ان لوگوں پر دیرپا اثر ڈالا جن کے ساتھ میں نے کام کیا۔

لیکن شاید سب سے اہم بات یہ تھی کہ اس تجربے نے مجھے دکھایا کہ جب میں ان مسائل پر کام کرتا ہوں جن کے بارے میں میں حقیقی طور پر پُرجوش ہوں تو میں کیا کچھ کر سکتا ہوں۔ ان آٹھ مہینوں میں، میں نے:

• روبوٹ کی نقل و حرکت کے کنٹرول کے نظام کو بہتر بنایا، جو پلیٹ فارم کی صلاحیت کو محدود کر رہا تھا
• شروع سے ایک کثیر روبوٹی ہم آہنگی کا نظام تیار کیا
• کمپیوٹر وژن اور سینسر فیوژن کی صلاحیتوں کو مربوط کیا
• جامع دستاویزات اور علم کے انتظام کا نظام تخلیق کیا
• کئی لوگوں کی رہنمائی کی اور علم کی منتقلی میں مدد کی
• خود مختار گاڑیوں میں پی ایچ ڈی سطح کی تحقیق کی معاونت کی

یہ صرف تکنیکی کامیابیوں کے بارے میں نہیں تھا، اگرچہ وہ میرے لیے بامعنی تھیں۔ یہ اس بات کو سیکھنے کے بارے میں تھا کہ ثابت قدمی اور منظم سوچ کے ساتھ، آپ انڈرگریجویٹ طالب علم ہوتے ہوئے بھی مفید خدمات انجام دے سکتے ہیں۔

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

اگرچہ میرے کیریئر نے مجھے دوسری سمتوں میں پہنچا دیا ہے، لیکن روبوٹکس کے لیے میرا جذبہ کم نہیں ہوا۔ میں اب بھی اس شعبے میں ہونے والی پیش رفت پر نظر رکھتا ہوں، روبوٹ لرننگ اور خود مختار نظاموں میں ہونے والی ترقی کے بارے میں پُرجوش ہوں، اور کبھی کبھار اپنے فارغ وقت میں ذاتی روبوٹکس منصوبوں پر کام کرتا ہوں۔

کون جانتا ہے کہ مستقبل میں کیا ہوگا؟ مصنوعی ذہانت اور مشین لرننگ میں جو مہارتیں میں تیار کر رہا ہوں، وہ روبوٹکس کے لیے بتدریج زیادہ متعلقہ ہوتی جا رہی ہیں۔ صنعت میں حاصل کیے گئے تجربے نے مجھے مضبوط اور قابلِ توسیع نظام بنانا سکھایا ہے۔ شاید مستقبل میں ایسا وقت آئے جب میرے تجربے کے یہ مختلف دھارے غیر متوقع طریقوں سے ایک دوسرے کے ساتھ جڑ جائیں۔

فی الحال، میں ایچ سی آر لیب میں گزارے ہوئے وقت اور اس سے حاصل ہونے والے تجربات کے لیے شکر گزار ہوں۔ یہ ایک تشکیلی دور تھا جس نے میری تکنیکی مہارتوں اور اس سمجھ، دونوں کو تشکیل دیا کہ مجھے کس قسم کا کام سب سے زیادہ اطمینان بخش محسوس ہوتا ہے۔ اگرچہ کبھی کبھار مجھے اس کی کمی محسوس ہوتی ہے، لیکن میں جانتا ہوں کہ وہاں سیکھے گئے اسباق اور تیار کیے گئے طریقۂ کار آج بھی میرے ہر کام پر اثر انداز ہوتے ہیں۔

ٹرائٹن روبوٹس اب بھی وہاں موجود ہیں، اب بھی محققین کی خدمت کر رہے ہیں، اور اب بھی اہم کام کو ممکن بنا رہے ہیں۔ اور یہ واقعی بہت شاندار بات ہے۔