فصل پژوهش رباتیک من

این نوشته مسیر رباتیک من را بازگو می‌کند، از کشف علاقه‌ام به رباتیک در FRC در دوران دبیرستان در 2015 تا زمانم به‌عنوان دستیار پژوهشی در آزمایشگاه رباتیک انسان‌محور (HCR) مدرسهٔ معادن کلرادو از فوریهٔ 2021 تا سپتامبر 2021. توجه داشته باشید که از اواخر 2022، آزمایشگاه HCR از مدرسهٔ معادن کلرادو به دانشگاه ماساچوست امهرست منتقل شده است، همراه با وب‌سایتش از hcr.mines.edu به hcr.cs.umass.edu.

پیش‌زمینه

من تحصیلات کارشناسی خود را در مدرسهٔ معادن کلرادو در ترم پاییز 2018 آغاز کردم. رشتهٔ من علوم کامپیوتر با تمرکز بر رباتیک و سامانه‌های هوشمند بود. و در بهار 2022 فارغ‌التحصیل شدم.

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

در Mines، فرصت این را پیدا کردم که در آزمایشگاه رباتیک انسان‌محور (HCR) تحت نظر دکتر هائو ژانگ کار کنم. نخستین بار در بهار 2020 از طریق درس او با عنوان «رباتیک انسان‌محور» (CSCI473) با دکتر ژانگ آشنا شدم، و پس از آشوبِ کووید و درس‌ها، اوایل بهار 2021 توانستم در آزمایشگاهش کار کنم.

درس رباتیک انسان‌محور (CSCI473)

درس رباتیک انسان‌محور (CSCI473) در Mines یکی از معدود درس‌هایی بود که در تجربهٔ دانشگاهی‌ام تأثیری عمیق بر من گذاشت. این درس توسط دکتر هائو ژانگ تدریس می‌شد. تمام نمرهٔ ما در این درس فقط از سه پروژه تشکیل شده بود که هرکدام مسئله‌ای چالش‌برانگیز را مطرح می‌کردند و مفاهیم اصلی رباتیک را معرفی می‌کردند. این پروژه‌ها عبارت بودند از:

1. یادگیری سامانهٔ عامل ربات (ROS)
2. یادگیری تقویتی برای دنبال‌کردن دیوار توسط ربات
3. درک ربات از رفتارهای انسانی با استفاده از بازنمایی‌های مبتنی بر اسکلت

یادگیری سامانهٔ عامل ربات (ROS)

این نخستین پروژه‌ای بود که به ما محول شد. این پروژه از سه وظیفه تشکیل می‌شد:

1. راه‌اندازی محیط توسعه
2. درک شبیه‌ساز Gazebo
3. نوشتن یک «Hello World» در ROS

برای وظایف 1 و 2، فقط باید محیط توسعهٔ خود را راه‌اندازی می‌کردیم و یک آموزش مقدماتی Gazebo را دنبال می‌کردیم. این شامل موارد زیر بود:

• راه‌اندازی ROS Melodic، که من روی لپ‌تاپ HP سال 2011 خودم انجام دادم که به‌قدر کافی مناسب بود
• نصب و پیکربندی ROS و Gazebo
• گذراندن آموزش gazebosim و آموزش e-manual.

در مقابل، وظیفهٔ 3 یک چالش واقعی بود. این وظیفه این بود که از turtlesim استفاده کنیم و بگذاریم لاک‌پشت لوگوی «M» مربوط به Mines را رسم کند:

این وظیفه، هرچند ساده به نظر می‌رسید، از آنچه به نظر می‌آمد دشوارتر بود. این پروژه در نهایت مرا با مفهوم سامانه‌های حلقه‌باز و حلقه‌بسته آشنا کرد. برای توضیح کامل پروژه، به csci473-p1.pdf مراجعه کنید یا می‌توانید دربارهٔ این پروژه و راه‌حل من در صفحهٔ پروژهٔ ROS Move Turtle بیشتر بدانید.

یادگیری تقویتی برای دنبال‌کردن دیوار توسط ربات

این دومین پروژه‌ای بود که به ما محول شد و یکی از سخت‌ترین پروژه‌هایی بود که در دانشگاه روی آن کار کردم. شرح پروژه به این صورت بود:

در این پروژه، دانشجویان الگوریتم‌های یادگیری تقویتی را طراحی و پیاده‌سازی خواهند کرد تا به یک ربات متحرک خودران یاد بدهند که دیوار را دنبال کند و از برخورد با موانع جلوگیری کند. دانشجویان از شبیه‌سازی Gazebo در ROS Melodic برای شبیه‌سازی یک ربات متحرک همه‌جهته به نام Triton، و با استفاده از نقشهٔ محیطی که در اختیارشان قرار می‌گیرد، استفاده خواهند کرد. دانشجویان از یک اسکنر برد لیزری روی ربات برای انجام حس‌کردن و یادگیری استفاده خواهند کرد، در حالی که ربات با استفاده از فرمان‌های فرمان‌دهی و سرعت کنترل می‌شود. از دانشجویان خواسته می‌شود این پروژه را با استفاده از C++ یا Python در ROS Melodic که روی Ubuntu 18.04 LTS اجرا می‌شود برنامه‌نویسی کنند (یعنی همان محیط توسعه‌ای که در پروژهٔ 1 استفاده شد). همچنین، از دانشجویان خواسته می‌شود گزارشی را مطابق با قالب استاندارد کنفرانس‌های رباتیک IEEE با استفاده از LATEX بنویسند.

برای الگوریتم یادگیری تقویتی، از ما خواسته شد از Q-Learning استفاده کنیم. همچنین از محیط شبیه‌سازی Gazebo مربوط به Stingray که توسط کلاس ارائه شده بود، استفاده کردیم. Stingray شامل مدل Triton و منطق فیزیکی بود. همچنین یک هزارتو برای دنبال‌کردن ربات در اختیار ما قرار داده شد. در مجموع، محیط به این شکل بود:

من هیچ‌وقت راه‌حل خودم را در GitHub یا وب منتشر نکردم، چون خیلی خوب نبود و به‌شدت ایراد داشت. همچنین، اجرای کد در محیط درست بسیار دشوار و آزاردهنده است. با این حال، یک ویدیوی نمایشی دارم که برای کلاس ارائه کردم و راه‌حل من را نشان می‌دهد. می‌توانید آن را اینجا ببینید:

برای توضیح کامل پروژه، به csci473-p2.pdf مراجعه کنید

درک ربات از رفتارهای انسانی با استفاده از بازنمایی‌های مبتنی بر اسکلت

برای پروژهٔ سوم، شرح پروژه به این صورت بود:

در این پروژه، دانشجویان چندین بازنمایی مبتنی بر اسکلت را پیاده‌سازی خواهند کرد (تحویل‌دادنی 1) و از ماشین‌های بردار پشتیبان (SVMها) (تحویل‌دادنی 2) برای طبقه‌بندی رفتارهای انسانی با استفاده از یک مجموعه‌دادهٔ فعالیت عمومی که از یک حسگر Kinect V1 گردآوری شده است استفاده خواهند کرد. علاوه بر این، از دانشجویان خواسته می‌شود گزارشی مطابق با قالب استاندارد کنفرانس‌های رباتیک IEEE با استفاده از LATEX در تحویل‌دادنی 3 بنویسند.

این پروژه چالش‌برانگیز بود، اما به دشواری پروژهٔ دوم نبود. هدف اصلی این بود که از داده‌های حسگر Kinect V1، از مجموعه‌دادهٔ فعالیت روزانهٔ MSR 3D، و ماشین‌های بردار پشتیبان برای طبقه‌بندی برخی کنش‌ها/رفتارهای انسانی استفاده شود. برای توضیح کامل پروژه، به csci473-p3.pdf مراجعه کنید یا می‌توانید دربارهٔ این پروژه و راه‌حل من در نوشتهٔ وبلاگی پیش‌بینی اعمال انسانی با استفاده از LIBSVM بیشتر بدانید.

نتیجه‌گیری CSCI473

CSCI473 یکی از بهترین درس‌هایی بود، اگر نگوییم بهترین درسی، که در طول تحصیلات کارشناسی‌ام در Mines گذراندم. همهٔ این پروژه‌ها چیزهای زیادی به من آموختند و باعث شدند مجموعه‌ای عالی از پروژه‌ها داشته باشم که بتوانم به آن‌ها فکر کنم و در رزومه‌ام به آن‌ها ارجاع بدهم. همچنین این نخستین درسی بود که در آن احساس کردم در عنصر خودم هستم، چون هرگز در امتحان‌دادن خوب نبودم اما در تکمیل پروژه‌ها عالی عمل می‌کردم. همچنین از طریق همین درس بود که با دکتر هائو ژانگ آشنا شدم؛ کسی که در نهایت به من کمک کرد تا به‌عنوان دستیار پژوهشی در آزمایشگاه رباتیک انسان‌محور (HCR) در Mines جایگاهی به دست آورم.

نشست میدانی علوم کامپیوتر (تابستان 2020)

در تابستان 2020، میان تمام‌کردن CSCI473 و پیوستن به آزمایشگاه HCR، من CSCI370 یا «مهندسی نرم‌افزار پیشرفته» را به‌عنوان بخشی از برنامهٔ کارشناسی علوم کامپیوتر خود در مدرسهٔ معادن کلرادو گذراندم. CSCI370 درسی است که دانشجویان را وادار می‌کند راه‌حل‌های مرتبط با نرم‌افزار را برای یک شرکت طراحی، پیاده‌سازی و مستندسازی کنند. این درس به دانشجویان اجازه می‌دهد دانش درسی خود را در مسائل واقعی علوم کامپیوتر به کار بگیرند. می‌توانید دربارهٔ این درس اینجا بیشتر بدانید.

در این درس، شما می‌توانید تصمیم بگیرید روی چه پروژه/شرکتی کار کنید. این درس فایل‌های PDFای را ارائه می‌کرد که هر پروژه و شرکت را توضیح می‌دادند. در نهایت تصمیم گرفتم روی پروژه‌ای که توسط شرکتی به نام 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 از ROS در درس رباتیک انسان‌محور (CSCI473) استفاده کرده بودم. به همین دلیل، در همان ابتدا کمک کردم همه را با ROS و شیوهٔ توسعه برای آن به‌روز کنم.

چالش‌ها

در این پروژه چالش‌های زیادی وجود داشت. اما بزرگ‌ترین چالشی که با آن روبه‌رو شدیم، نداشتن دسترسی به یک ربات واقعی برای آزمایش بود. این به‌دلیل COVID بود که همه‌چیز را از راه دور کرد و مانع از کار کردن ما در آزمایشگاه/ساختمان‌های Lunar Outpost شد. به‌خاطر این موضوع، مجبور شدیم از شبیه‌سازی استفاده کنیم.

همچنین، برای اینکه ایده‌ای از این بگیریم که مشکل لغزش چرخ چگونه می‌تواند برای مورد استفاده‌ی Lunar Outpost حل شود، مقداری پژوهش آکادمیک از WVU Navigation Lab را بررسی کردیم؛ موضوعی که برای ما، به‌عنوان دانشجویان سال دوم و سوم کارشناسی، سخت‌تر از چیزی بود که انتظار داشتیم.

چالش دیگری که با آن روبه‌رو شدیم، مقدار زمانی بود که برای کار روی این پروژه داشتیم. CSCI370 یک کلاس یک‌ماهه است. اما خودِ مسئله، مسئله‌ای بسیار بزرگ است که بسیاری از شرکت‌ها و دانشگاه‌ها دهه‌هاست تلاش کرده‌اند آن را حل/کامل کنند. بنابراین یک ماه اصلاً زمان کافی برای حل این مسئله نیست. با این حال، با وجود همه‌ی این چالش‌ها، ادامه دادیم و مطمئن شدیم که خروجی را تحویل می‌دهیم.

نتیجه‌گیری

پس از بررسی تمام پژوهش‌ها و توسعه، متوجه شدیم که شبیه‌سازی فیزیک درستِ ماه به‌صورت دیجیتال تقریباً غیرممکن است، بنابراین واقعاً آزمایش این الگوریتم در یک شبیه‌سازی کار خوبی نیست و پژوهش معناداری درباره‌ی تشخیص لغزش چرخ در فضا و روی ماه به‌دست نخواهد داد. ما به این نتیجه رسیدیم که راه‌اندازی یک محیط آزمایش مناسب با استفاده از چیزی مثل شن و سخت‌افزار واقعی، مانند ربات Husky، برای این نوع پژوهش بسیار مهم‌تر است. ما کد تشخیص لغزش چرخ را به‌روزرسانی کردیم تا به‌صورت یک گره ROS کار کند و به‌درستی عمل می‌کرد و به‌راحتی می‌توانست برای آزمایش به سخت‌افزار واقعی وارد شود. این پروژه به من اجازه داد نقش رهبری بر عهده بگیرم، همکلاسی‌هایم را در توسعه‌ی ROS آموزش دهم، و هنگام مقابله با یک مسئله‌ی پیچیده که پیش از آن هرگز با آن روبه‌رو نشده بودم، تجربه‌ی کار با Python، ROS، و Gazebo را به‌دست آورم. مهم‌تر از همه، این تجربه اشتیاق من به رباتیک را بیش از پیش تثبیت کرد و تمایل من را برای دنبال کردن پژوهش در این حوزه تقویت کرد و زمینه را برای آنچه در ادامه‌ی مسیر رباتیک من رخ می‌داد، فراهم ساخت.

شروع در آزمایشگاه HCR

پس از گذراندن CSCI473، جلسه‌ی میدانی علوم کامپیوترم در تابستان 2020، و ترم پاییز 2020، تصمیم گرفتم پژوهش در حوزه‌ی رباتیک را دنبال کنم. من تجربه‌های بسیار خوبی هم از CSCI473 و هم از جلسه‌ی میدانی علوم کامپیوتر داشتم و به همین دلیل تصمیم گرفتم برای آزمایشگاه HCR پژوهش انجام دهم. چون یک سال قبل‌تر دکتر Zhang را ملاقات کرده بودم، تصمیم گرفتم برای او ایمیل بفرستم و درباره‌ی هرگونه فرصت احتمالی که آزمایشگاه ممکن است در ژانویه‌ی 2021 داشته باشد بپرسم. ظرف حدود 2 هفته، دکتر Zhang علاقه نشان داد، گزینه‌های پژوهشی را به من ارائه کرد، و یک نقش در آزمایشگاه به من پیشنهاد داد. سپس در فوریه‌ی 2021 شروع به کار برای آزمایشگاه کردم.

ویدیوی معرفی

این هم ویدیوی معرفی من که چند ماه بعد از شروع فعالیتم در آزمایشگاه HCR ضبط کردم. این ویدیو در مه 2021 ضبط شد و پژوهشی را که در تابستان 2021 در آزمایشگاه HCR روی آن تمرکز می‌کردم پوشش می‌دهد:

پروژه‌ی من

در طول مدت حضورم در آزمایشگاه HCR، عمدتاً روی پروژه‌ی Triton تمرکز داشتم. پروژه‌ی Triton یک ربات متحرک است که توسط Human Centered Robotics Lab در Colorado School of Mines توسعه داده شده است. این ربات یک ربات زمینی سه‌گوشِ اومنی‌ویل است که با Jetson Nano شرکت NVIDIA کار می‌کند.

Triton، در یک نمای کلی ساده، از بخش‌های زیر تشکیل شده بود:

• NVIDIA Jetson Nano
• برد حامل Seed Studio A205 شرکت NVIDIA
• Arduino Mega
• کارت Micro SD با ظرفیت 64 گیگابایت
• بدنه‌ی سفارشی چاپ سه‌بعدی
• 3 چرخ mecanum
• 1 باتری AR
• مدارهای سفارشی برای توزیع بهینه‌ی برق و سیم‌کشی
• دوربین Realsense D435 شرکت Intel
• چند LED

این ربات حدود سال‌های 2018 تا 2020 به‌عنوان رباتی با اهداف آموزشی طراحی، ساخته و تولید شد. تا زمانی که من به آن پیوستم، Triton تا حد زیادی جاافتاده بود و آزمایشگاه در حال بررسی ساخت نسخه‌ی جدیدی از آن بود. با این حال، مشکل اصلی Triton نرم‌افزار آن بود. Triton می‌توانست حرکت کند، شارژ شود، و در یک معنای پایه‌ای کار کند، اما واقعاً کار هوشمندانه‌ای انجام نمی‌داد. حتی توانایی انجام حرکات پیشرفته‌تر را هم نداشت.

برای شروعِ رسیدگی به این موضوع، آزمایشگاه فضایی را راه‌اندازی کرد که بتوانیم Triton را در آن ردیابی کنیم. برای این کار، آنها یک ناحیه‌ی 2 متر در 2 متر با 8 دوربین Optitrack Flex (فروسرخ) به‌شکل تقریباً مربعی و در ارتفاع حدود 6 تا 7 فوت بالاتر از کف ایجاد کردند.

در کنار ساخت این ناحیه، به هر Triton سه توپ کروی خاکستری در بالای بدنه‌اش متصل شد.

با این تنظیمات، ما عملاً سیستم GPS کوچک خودمان را ساخته بودیم که به ما اجازه می‌داد مختصات دقیق یک Triton را بر حسب متر در ناحیه‌ی موردنظرمان به‌دست آوریم. با استفاده از دوربین‌های فروسرخ Optitrack و کره‌های خاکستری Optitrack به‌شکل مثلثی، می‌توانستیم مختصات دقیق یک Triton را در ناحیه‌ی خود مشخص کنیم. این به ما اجازه می‌داد برای دقت بیشتر در حرکت، یک سیستم حلقه‌بسته اعمال کنیم.

سیستم Optitrack داده‌های موقعیت و جهت‌گیری را با نرخ حدود 120Hz و با دقت زیر میلی‌متر، زمانی که به‌درستی کالیبره شده باشد، فراهم می‌کرد. سه نشانگر بازتابی هر Triton یک الگوی مثلثی منحصربه‌فرد تشکیل می‌دادند که سیستم می‌توانست آن را به‌عنوان یک جسم صلب ردیابی کند. دستگاه مختصات به‌گونه‌ای کالیبره شده بود که (0,0) در مرکز ناحیه‌ی ردیابی قرار داشت و محورهای X و Y با هندسه‌ی اتاق هم‌راستا بودند. اما با وجود این داده‌های دقیقِ موقعیت‌یابی، Triton همچنان در حرکت مشکل داشت.

با این تنظیمات، یکی از ویژگی‌های اصلی که می‌خواستیم برای Triton فراهم کنیم، توانایی حرکت به یک مختصات مشخص بود. کاربر، یا نرم‌افزار او، می‌توانست یک مختصات (x, y) در محدوده‌ی موردنظر خود ارائه دهد. سپس ربات با بیشترین سرعت، دقت، و روانی ممکن به آن مختصات حرکت می‌کرد. وقتی من به آن پیوستم، این ویژگی وجود داشت اما خیلی خوب کار نمی‌کرد. در اینجا یک انیمیشن ساده نشان می‌دهد که منطق حرکت اولیه چگونه کار می‌کرد:

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

1. واقعاً کند است
2. باعث می‌شود ربات فقط برای رفتن به یک نقطه‌ی مشخص، فضای زیادی اشغال کند. این موضوع استفاده از این راه‌حل را زمانی که چند Triton هم‌زمان در حرکت بودند برای ما دشوار می‌کرد.

پس چرا این رفتار رخ می‌داد؟ مشکل این بود که Triton ابتدا می‌چرخید و alpha خود را تغییر می‌داد تا زمانی که در یک حاشیه‌ی خطای مشخص به سمت نقطه‌ی هدف قرار می‌گرفت. سپس با سرعت به جلو می‌دوید، و بعد از آنکه theta آن به‌اندازه‌ی مشخصی از هدف منحرف می‌شد، متوقف می‌شد و دوباره شروع به چرخیدن می‌کرد تا زمانی که alpha در محدوده‌ی قابل‌قبول برای هدف قرار بگیرد. سپس دوباره می‌دوید و همین کار را تا رسیدن به نقطه ادامه می‌داد. همچنین، هرچه به نقطه‌ی هدف نزدیک‌تر و نزدیک‌تر می‌شد، سرعت چرخش و دویدن بسیار کمتر می‌شد تا مطمئن شود از هدف عبور نمی‌کند. این باعث می‌شد Triton حرکتی غیرطبیعی داشته باشد، برای رسیدن به یک نقطه‌ی هدف خیلی طول بکشد، و برای رسیدن به یک هدف مشخص به فضای بسیار زیادی نیاز داشته باشد. بنابراین با وجود همه‌ی این مشکلات، و با توجه به اینکه این ویژگی تا چه اندازه برای توسعه‌ی پروژه‌ی Triton ضروری بود، وقتی کارم را در آزمایشگاه HCR شروع کردم، اولین وظیفه‌ام توسعه‌ی راه‌حل‌های مؤثرتری بود که به Triton اجازه دهند بهتر به سمت یک نقطه‌ی هدف ناوبری کند.

با دانستن این موضوع، زمان زیادی را صرف پژوهش درباره‌ی بهترین روش ممکن برای رسیدگی به این مسئله کردم. به‌طور جالبی، من در Mines کلاسی با عنوان Introduction to Feedback Control Systems (EENG307) می‌گذراندم. در اوایل آن کلاس، با مفهوم Open-loop controllers و Closed-loop controllers آشنا شدیم. با دانستن این موضوع، و پس از کمی گفت‌وگو با استاد آن کلاس و هم‌اتاقی باهوشم، روشن شد که این هدفِ رساندن Triton به یک نقطه‌ی هدف، یک مسئله‌ی سیستم حلقه‌بسته است.

اکنون، پس از آزمایش و پژوهش گسترده، دو رویکرد کنترلی متمایز برای Tritonها توسعه دادم:

روش 1: کنترل‌کننده‌ی فاصله-تتا

این رویکرد از دو کنترل‌کننده‌ی تناسبی جداگانه که به‌طور هم‌زمان اجرا می‌شدند استفاده می‌کرد:

• کنترل‌کننده‌ی فاصله: فاصله‌ی اقلیدسی تا هدف را محاسبه می‌کرد و برای تعیین سرعت رو‌به‌جلو/عقب ضریب تناسبی اعمال می‌کرد
• کنترل‌کننده‌ی تتا: خطای زاویه‌ای بین جهت فعلی ربات و جهت مطلوب به‌سمت هدف را محاسبه می‌کرد و برای سرعت چرخشی ضریب تناسبی جداگانه‌ای اعمال می‌کرد

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

این باعث شد که Triton به‌طور طبیعی به سمت هدف بچرخد و هم‌زمان به جلو حرکت کند و مسیرهای منحنیِ روانی ایجاد شود. مزیت کلیدی این بود که ربات همیشه وجه جلویی خود را رو به مقصد نگه می‌داشت، که برای کاربردهای مبتنی بر دوربین حیاتی بود.

روش ۲: کنترل‌کنندهٔ مختصات X-Y

این رویکرد با ربات مانند یک ترسیم‌گر دوبعدی رفتار می‌کرد، با کنترل مستقل حرکت X و Y:

• کنترل‌کنندهٔ X: حرکت شرق-غرب را بر اساس خطای مختصات X مستقیماً کنترل می‌کرد
• کنترل‌کنندهٔ Y: حرکت شمال-جنوب را بر اساس خطای مختصات Y مستقیماً کنترل می‌کرد

پیاده‌سازی، خطاهای مختصات X و Y را به‌صورت مستقل محاسبه می‌کرد، بهره‌های تناسبی جداگانه را اعمال می‌کرد، و سپس این مؤلفه‌های سرعت جهانی را با استفاده از ماتریس‌های چرخش به چارچوب مختصات محلی ربات تبدیل می‌کرد. این تبدیل ضروری بود، زیرا سامانهٔ محرکهٔ چرخ‌های omni ربات به سرعت‌هایی در چارچوب مرجع خودش نیاز داشت، نه در مختصات جهانی. این روش مستقیم‌ترین مسیرها را به سمت اهداف ایجاد می‌کرد و به‌طور قابل‌توجهی سریع‌تر بود، اما جهت‌گیری ربات دچار رانش می‌شد چون هیچ کنترل صریحی برای جهت‌گیری وجود نداشت.

برای روش #1، من این روش را به‌طور کامل در بلاگ Move Turtle (TurtleSim) خود به‌تفصیل توضیح دادم. به‌شدت توصیه می‌کنم این بلاگ را بخوانید تا همهٔ جزئیات مربوط به این‌که کنترل‌کننده‌های PID به‌طور کلی چگونه کار می‌کنند و همچنین روش #1 چگونه کار می‌کند را بدانید. من روش #1 را با استفاده از TurtleSim رُس توسعه دادم، سپس آن کد را به Triton منتقل کردم و آن را به‌روزرسانی کردم تا یک محیط واقعی‌تر را در نظر بگیرد.

روش #2 از رویکردی کاملاً متفاوت اما به همان اندازه مؤثر استفاده می‌کرد. به‌جای فکر کردن به جهت‌گیری ربات و فاصله تا هدف، این روش حرکت را مانند یک مسئلهٔ صفحهٔ مختصات در نظر می‌گیرد. کنترل‌کننده به‌طور مداوم خطا را در هر دو جهت X و Y به‌صورت جداگانه محاسبه می‌کند. برای مثال، اگر ربات نیاز داشته باشد از (0,0) به (2,3) حرکت کند، این را به‌صورت نیاز به اصلاح یک خطای ۲ متری در X و یک خطای ۳ متری در Y می‌بیند. دو کنترل‌کنندهٔ تناسبی به‌طور هم‌زمان کار می‌کردند: یکی سرعت ربات را در جهت X بر اساس خطای X تنظیم می‌کرد، در حالی که دیگری حرکت در جهت Y را بر اساس خطای Y بر عهده داشت. این کار مسیر مستقیم‌تری به سمت هدف ایجاد می‌کرد، مشابه نحوهٔ حرکت هدِ یک چاپگر سه‌بعدی، و امکان حرکت‌های موربِ روان را فراهم می‌کرد. ربات نیازی نداشت که صریحاً برای روبه‌رو شدن با هدفش بچرخد، و این روش را به‌ویژه در فضاهای تنگ یا زمانی که موقعیت‌یابی دقیق مورد نیاز است، بسیار مؤثر می‌کرد.

هر دو روش ثابت کردند که به‌طور قابل‌توجهی سریع‌تر و قابل‌اعتمادتر از رویکرد اولیه هستند. برای دیدن این روش‌های جدید در عمل، به فهرست پخش Tritons in Action سر بزنید، که همهٔ Tritonها را در حال کار با روش‌های جدید نشان می‌دهد.

آنچه پیش‌تر برای یک حرکت سادهٔ نقطه‌به‌نقطه ۳۰ تا ۴۵ ثانیه زمان می‌برد، اکنون حدود ۸ تا ۱۲ ثانیه طول می‌کشید. مهم‌تر از آن، Triton اکنون می‌توانست در فضاهای تنگ با کارایی بیشتری ناوبری کند، که برای سناریوهای چندرباتهٔ ما مفید شد.

چالش‌های توسعه و اشکال‌زدایی

پیاده‌سازی این کنترل‌کننده‌ها سرراست نبود و شامل چندین چالش مهم اشکال‌زدایی می‌شد:

تبدیلات سیستم مختصات: یکی از دشوارترین جنبه‌ها این بود که تبدیلات مختصات را درست انجام دهم. سامانهٔ Optitrack داده‌ها را در چارچوب مختصات خودش فراهم می‌کرد، ربات چارچوب مختصات محلی خودش را داشت، و من باید بین آن‌ها به‌دقت تبدیل می‌کردم. پیاده‌سازی‌های اولیه باعث می‌شدند ربات‌ها در جهت‌های اشتباه حرکت کنند، چون محاسبات ماتریس چرخش را با هم اشتباه گرفته بودم.

رفتار دنیای واقعی در برابر رفتار ایده‌آل: بزرگ‌ترین چالش، در نظر گرفتن عوامل دنیای واقعی بود که در نظریهٔ کنترلِ کتابی ظاهر نمی‌شوند. چرخ‌های ربات ویژگی‌های اصطکاکی متفاوتی داشتند، موتور‌ها دقیقاً به یک شکل پاسخ نمی‌دادند، و همیشه مقداری تأخیر در زنجیرهٔ ارتباطی از Optitrack تا نرم‌افزار کنترل و سپس آردوینوی ربات وجود داشت. من هفته‌ها صرف تنظیم بهره‌های تناسبی و افزودن فیلترهای ناحیهٔ مرده کردم تا این واقعیت‌های فیزیکی را در نظر بگیرم.

مشکلات نوسان و پایداری: نخستین پیاده‌سازی‌های من دچار مشکلات نوسان بودند، به‌طوری‌که ربات‌ها از اهدافشان عبور می‌کردند و به جلو و عقب می‌لرزیدند. این موضوع اهمیت جمله‌های مشتق‌گیر در کنترل‌کننده‌های PID و نیاز به تنظیم درست بهره‌ها را به من آموخت. در نهایت، به‌جای PID کامل، عمدتاً بر کنترل تناسبی با بهره‌های دقیقاً تنظیم‌شده تکیه کردم، چون میرایی ذاتی سامانه برای بیشتر کاربردها کافی بود.

تداخل چندرباته: وقتی چند ربات به‌طور هم‌زمان کار می‌کردند، الگوهای تداخلی غیرمنتظره‌ای کشف کردم. ربات‌ها گاهی بر سر یک فضای مشترک «با هم می‌جنگیدند» یا موقعیت‌های بن‌بست ایجاد می‌کردند که در آن‌ها یکدیگر را برای مدت نامحدود مسدود می‌کردند. این مسئله مرا به پیاده‌سازی سازوکارهای هماهنگی و الگوریتم‌های اجتناب از برخورد سوق داد.

سامانهٔ کنترل چند-Triton

وقتی مشکل حرکت یک Triton را حل کردم، چالش بعدیِ آزمایشگاه این بود که چند Triton را هم‌زمان با هم کار کند. این موضوع به یکی از حوزه‌های اصلی تمرکز من تبدیل شد و در نهایت به یک مشارکت مهم در پروژه انجامید.

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

برای حل این مسئله، من یک رویکرد چندپردازشی با استفاده از کتابخانهٔ multiprocessing پایتون پیاده‌سازی کردم. به هر Triton فرایند اختصاصی خودش داده شد که می‌توانست به‌طور مستقل اجرا شود، در حالی که همچنان توسط یک سامانهٔ کنترل مرکزی هماهنگ می‌شد. این کار به چند Triton اجازه می‌داد که به‌طور هم‌زمان حرکت کنند بدون آن‌که در حلقه‌های کنترل یکدیگر اختلال ایجاد کنند.

طراحی معماری چندرباته

معماری سامانه‌ای که توسعه دادم از چند مؤلفهٔ کلیدی تشکیل می‌شد:

فرایند کنترل‌کنندهٔ اصلی: این بخش به‌عنوان هماهنگ‌کنندهٔ مرکزی عمل می‌کرد و تعاملات رابط کاربری، برنامه‌ریزی مسیر و هماهنگی سطح بالا میان ربات‌ها را مدیریت می‌کرد. این فرایند حالت جهانی را نگه می‌داشت و فرمان‌ها را میان فرایندهای ربات‌های منفرد توزیع می‌کرد.

فرایندهای ربات‌های منفرد: هر Triton فرایند پایتون اختصاصی خودش را داشت که موارد زیر را انجام می‌داد:

• محاسبات کنترل PID بلادرنگ با نرخ حدود 50Hz
• ارتباط با سخت‌افزار ربات (Arduino/Jetson)
• اجرای مسیر محلی و اجتناب از مانع
• گزارش وضعیت به کنترل‌کنندهٔ اصلی

ارتباط با حافظهٔ مشترک: من از shared_memory و اشیای Queue در پایتون استفاده کردم تا ارتباط کارآمد میان فرایندها را امکان‌پذیر کنم. این کار هماهنگی بلادرنگ را بدون سربار ارتباط شبکه فراهم می‌کرد.

سازوکارهای همگام‌سازی: برای جلوگیری از تعارض زمانی که چند ربات باید هماهنگ می‌شدند (مانند اجتناب از برخورد)، من سمافور‌ها و قفل‌هایی پیاده‌سازی کردم که به ربات‌ها اجازه می‌داد برای دسترسی انحصاری به نواحی خاصی از فضای کار درخواست بدهند.

چالش این بود که اطمینان حاصل شود همهٔ ربات‌ها می‌توانند حلقه‌های کنترل خود را به‌طور مستقل اجرا کنند و در عین حال هماهنگی جهانی را حفظ کنند. هر فرایند ربات محاسبات PID خودش را اجرا می‌کرد و فرمان‌های موتور را مستقیماً به سخت‌افزار می‌فرستاد، در حالی که فرایند اصلی هماهنگی‌های سطح بالاتر مانند اجتناب از برخورد و برنامه‌ریزی مسیر را بر عهده داشت.

سامانهٔ چند-Triton امکان‌های پژوهشی کاملاً جدیدی را گشود. اکنون می‌توانستیم موارد زیر را شبیه‌سازی کنیم:

• سناریوهای ارتباط وسیله‌به‌وسیله
• برنامه‌ریزی مسیر هماهنگ همراه با اجتناب از مانع
• رفتارهای رباتیک ازدحامی
• نقشه‌برداری SLAM چندعاملی
• کنترل آرایش و رفتارهای دنبال‌کردن

در ادامه، آنچه چیدمان آزمایشگاه با اجرای هم‌زمان چند Triton به نظر می‌رسید:

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

این سامانه می‌توانست تا 5 Triton را به‌طور هم‌زمان مدیریت کند، که هرکدام کنترل‌کننده‌های PID خود را اجرا می‌کردند و از طریق سامانهٔ کنترل مرکزی هماهنگ می‌شدند. عملکرد چشمگیر بود، به‌طوری‌که همهٔ ربات‌ها در حالی که به‌عنوان یک تیم با هم کار می‌کردند، دقت فردی خود را حفظ می‌کردند.

در اینجا یک فهرست پخش هست که Tritonها را در حال کار نشان می‌دهد، از کنترل تک‌رباته تا هماهنگی چندرباته: فهرست پخش Tritons in Action

یکپارچه‌سازی حسگر عمق و تصحیح مختصات

یکی دیگر از پیشرفت‌های مهمی که روی آن کار کردم، بهره‌گیری از دوربین‌های عمق Intel RealSense D435 بود که روی هر Triton نصب شده بودند. در حالی که سامانهٔ Optitrack به ما داده‌های موقعیت‌یابی فوق‌العاده دقیقی می‌داد، من می‌خواستم بررسی کنم که ربات‌ها چگونه می‌توانند از حسگرهای روی خود برای بهبود آگاهی فضایی‌شان و تصحیح خطاهای مختصات استفاده کنند.

ایده این بود که Tritonها بتوانند از حسگرهای عمق خود برای شناسایی Tritonهای دیگر در پیرامونشان و تطبیق متقابل موقعیت‌هایشان استفاده کنند. این کار چندین هدف را برآورده می‌کرد:

1. تصحیح خطا: اگر سامانهٔ Optitrack هرگونه رانشِ کالیبراسیون یا انسداد موقت داشت، ربات‌ها می‌توانستند از تأیید بصری موقعیت یکدیگر برای حفظ سامانه‌های مختصات دقیق استفاده کنند.

2. SLAM پیشرفته: با همکاری چندین ربات مجهز به حسگر عمق، می‌توانستیم نقشه‌های بسیار غنی‌تری از محیط با نقاط دادهٔ افزونه ایجاد کنیم.

3. اجتناب از برخورد: حس‌کردن عمق به‌صورت بلادرنگ به ربات‌ها اجازه می‌داد حتی اگر سیستم کنترل مرکزی دچار تأخیر ارتباطی می‌شد، یکدیگر را تشخیص دهند و از برخورد با هم اجتناب کنند.

من شروع به آزمایش الگوریتم‌هایی کردم که به Tritonها اجازه می‌داد:

• دیگر Tritonها را با استفاده از شکل مثلثی متمایز و نشانگرهای کره‌ای بازتابی‌شان تشخیص دهند
• موقعیت‌ها و جهت‌گیری‌های نسبی را با استفاده از داده‌های عمق محاسبه کنند
• این اندازه‌گیری‌ها را با داده‌های Optitrack مقایسه کنند تا اختلاف‌ها را شناسایی کنند
• به‌طور بالقوه سیستم مختصات خود را به‌صورت بلادرنگ تنظیم کنند تا دقت حفظ شود

آزمایش‌های بینایی رایانه‌ای

من زمان قابل‌توجهی را صرف آزمایش یک خط لولهٔ بینایی رایانه‌ای کردم که در چند مرحله کار می‌کرد:

پردازش داده‌های عمق: حسگر Intel RealSense D435 هم جریان دادهٔ RGB و هم جریان دادهٔ عمق را فراهم می‌کرد. من عمدتاً با داده‌های عمق کار می‌کردم که به‌صورت یک آرایهٔ 640x480 از اندازه‌گیری‌های فاصله در 30Hz ارائه می‌شد. نخستین چالش، فیلتر کردن این داده‌های پرنویز عمق برای استخراج اطلاعات هندسی معنادار بود.

تلاش‌های تشخیص شیء: من الگوریتم‌های تشخیص چندمرحله‌ای را آزمایش کردم. تا حدی موفق شدم تصویر عمق را بخش‌بندی کنم تا اشیایی را در سطح زمین شناسایی کنم (حذف دیوارها، سقف و غیره) و به‌دنبال اشیایی با ویژگی‌های اندازهٔ مناسب، با سطح اشغال تقریباً 0.3x0.3 متر، بگردم. تلاش کردم از تشخیص لبه و تحلیل هندسی برای شناسایی نمای متمایز Triton استفاده کنم، با نتایج متفاوت.

آزمایش‌های تشخیص نشانگر: سه کرهٔ بازتابی روی هر Triton به‌نظر می‌رسیدند که امیدوارکننده‌ترین ویژگی تشخیص باشند. من الگوریتم‌های تشخیص blob را آزمایش کردم تا الگوی مثلثی مشخصِ سه نقطهٔ روشن در تصویر عمق را شناسایی کنم. در شرایط نوری کنترل‌شده نتایج امیدوارکننده‌ای به‌دست آوردم، هرچند این روش به‌طور مداوم قابل‌اعتماد نبود.

پژوهش ادغام مختصات: من رویکردهایی را برای ادغام برآوردهای موقعیت مبتنی بر بینایی با داده‌های Optitrack بررسی کردم، از جمله پیاده‌سازی‌های پایهٔ فیلتر کالمن. ایده این بود که وقتی داده‌های Optitrack در دسترس هستند به آن‌ها وزن بیشتری داده شود، اما در صورت نیاز به بینایی تکیه شود، هرچند پیش از پایان زمانم در آزمایشگاه موفق نشدم این بخش را به‌طور کامل عملیاتی کنم.

چالش‌های کارایی: رساندن همهٔ این پردازش‌ها به اجرای بلادرنگ در کنار حلقه‌های کنترل ربات، چالش‌برانگیز بود. من رویکردهای بهینه‌سازی را آزمایش کردم تا الگوریتم‌ها را با نرخ حدود 10-15Hz اجرا کنم، بدون آنکه توان پردازشی Jetson Nano را بیش از حد درگیر کنم.

متأسفانه، پیش از آنکه بتوانم این کار بینایی رایانه‌ای را به‌طور کامل به پایان برسانم، مجبور شدم آزمایشگاه را ترک کنم. هرچند در ابتدا نتایج امیدوارکننده‌ای داشتم و چیزهای زیادی دربارهٔ پردازش حسگر عمق یاد گرفتم، اما سیستم را به یک حالت کاملاً قابل‌اعتماد نرساندم. این مسیر پژوهشی همچنان جالب باقی ماند و دیگران بالقوه می‌توانستند آن را ادامه دهند.

این هم ویدیویی از من در حال آزمایش الگوریتم‌های بینایی رایانه‌ای:

این هم نمای حسگر عمق در جریان آزمایش‌هایم بود:

هرچند کار یکپارچه‌سازی حسگر عمق را کامل نکردم، این مفهوم برای کاربردهایی مانند شبیه‌سازی سناریوهای خودروهای خودران نویدبخش بود، جایی که وسایل نقلیه باید بدون تکیهٔ صرف بر زیرساخت خارجی از یکدیگر آگاه باشند. مسیر پژوهشی‌ای که شروع به کاوش آن کردم، می‌توانست به کارهای آینده در آزمایشگاه کمک کند.

مستندسازی و حفظ دانش

یکی از مهم‌ترین مشارکت‌های من در HCR Lab، و شاید همان موردی که به آن بیشترین افتخار را دارم، سازمان‌دهی و حفظ همهٔ مستندات پروژه بود. وقتی به آزمایشگاه پیوستم، دانش مربوط به پروژهٔ Triton در چندین پلتفرم و قالب پراکنده بود. اطلاعات حیاتی در میان موارد زیر پخش شده بود:

• حساب‌های مختلف Google Drive متعلق به دانشجویان گوناگونی که فارغ‌التحصیل شده بودند
• ایمیل‌های قدیمی که در صندوق‌های ورودی دفن شده بودند
• پوشه‌های پراکندهٔ Dropbox
• چندین مخزن GitHub
• مخزن‌های GitLab با سازمان‌دهی ناسازگار
• یادداشت‌های دست‌نویسی که فقط افراد خاصی می‌توانستند آن‌ها را تفسیر کنند

این مستندات تکه‌تکه یک مشکل بزرگ بود. دانشجویان جدید هفته‌ها وقت صرف می‌کردند فقط تا بفهمند از کجا باید شروع کنند، و دانش ارزشمند به‌طور مداوم وقتی افراد فارغ‌التحصیل می‌شدند یا آزمایشگاه را ترک می‌کردند از بین می‌رفت.

من خودم را موظف کردم این مشکل را به‌صورت نظام‌مند حل کنم. ساعت‌های بی‌شماری را صرف پیدا کردن هر قطعهٔ مستندات، کد، ویدیو و یادداشت مرتبط با پروژهٔ Triton کردم. سپس همه‌چیز را در یک مخزن مرکزی GitLab با ساختاری شفاف و منطقی سازمان‌دهی کردم.

مستندات مرکزی شامل موارد زیر بود:

• راهنماهای ساخت: دستورالعمل‌های گام‌به‌گام برای مونتاژ Tritonها از صفر
• راه‌اندازی نرم‌افزار: راهنماهای کامل برای تنظیم محیط توسعه
• مستندات کد: کدی با توضیحات خوب و شرح‌های روشن
• مشخصات سخت‌افزار: فهرست دقیق قطعات، نمودارهای سیم‌کشی، و طراحی‌های PCB
• راهنماهای عیب‌یابی: مشکلات رایج و راه‌حل‌های آن‌ها
• آموزش‌های ویدیویی: من ویدیوهای آموزشی را ایجاد و در YouTube بارگذاری کردم، از جمله آموزش‌های مفصل کالیبراسیون Optitrack:

همچنین استانداردهای مستندسازی را برقرار کردم تا اطمینان حاصل شود که مشارکت‌های آینده سازمان‌یافته و در دسترس خواهند بود. ساختار مخزنی که ایجاد کردم به پایه و اساس همهٔ کارهای بعدی در آزمایشگاه تبدیل شد.

فراتر از صرفاً سازمان‌دهی مستندات موجود، من چندین راهنمای و آموزش اصیل ایجاد کردم که شکاف‌های حیاتی موجود در پایگاه دانش را پر می‌کردند. این‌ها شامل دستورالعمل‌های راه‌اندازی دقیق برای اعضای جدید آزمایشگاه، راهنماهای جامع عیب‌یابی، و راهنمای ویدیویی مراحل پیچیده بودند.

اثر این کار فوری و ماندگار بود. دانشجویان جدید می‌توانستند به‌جای هفته‌ها، ظرف چند روز به سطح آمادگی برسند. مخزن مستنداتی که ایجاد کردم، هنوز هم سال‌ها پس از ترک من از آزمایشگاه مورد استفاده قرار می‌گیرد. این مخزن به منبع واحد حقیقت برای پروژهٔ Triton تبدیل شد و ساعت‌ها/روزهای بی‌شماری را برای پژوهشگران آینده صرفه‌جویی کرد.

راهنمایی و انتقال دانش

یکی از رضایت‌بخش‌ترین جنبه‌های زمان من در HCR Lab فرصت راهنمایی دیگران و به‌اشتراک‌گذاری دانشی بود که به دست آورده بودم. با پیشرفت کارم و افزایش تجربه‌ام در سیستم‌های Triton، مسئولیت بیشتری در آموزش اعضای جدید تیم بر عهده گرفتم.

راهنمایی جانشینان آزمایشگاه

وقتی خود را برای ترک آزمایشگاه در آینده آماده می‌کردم تا روی تمام‌کردن مدرکم و کارم در eBay تمرکز کنم، مطمئن شدم که دو نفر را به‌طور کامل آموزش می‌دهم تا پس از رفتن من پروژهٔ Triton را ادامه دهند. این فقط دربارهٔ نشان دادن نحوهٔ کار چیزها نبود؛ بلکه دربارهٔ اطمینان از این بود که آن‌ها واقعاً اصول زیربنایی را درک می‌کنند تا بتوانند به نوآوری ادامه دهند.

من هفته‌ها به‌صورت نزدیک با آن‌ها کار کردم و موارد زیر را مرور کردیم:

• مبانی ریاضی سامانه‌های کنترل PID
• معماری چندپردازشی برای هماهنگ‌سازی چندین ربات
• یکپارچه‌سازی حسگر عمق و الگوریتم‌های بینایی رایانه‌ای
• سیستم مستندسازی و نحوهٔ نگهداری آن
• تکنیک‌های اشکال‌زدایی و حالت‌های خرابی رایج

انتقال دانش فوق‌العاده کامل بود. ما با هم جلسات واقعی اشکال‌زدایی را طی کردیم، از آن‌ها خواستم کد موجود را تغییر دهند و گسترش دهند، و مطمئن شدم که می‌توانند به‌طور مستقل Tritonهای جدید را از صفر راه‌اندازی کنند.

برنامهٔ راهنمایی دانش‌آموز دبیرستانی

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

من یک برنامهٔ درسی جامع طراحی کردم که موارد زیر را پوشش می‌داد:

مبانی علوم رایانه:

• مفاهیم برنامه‌نویسی با استفاده از Python به‌عنوان زبان اصلی
• مقدمه‌ای بر برنامه‌نویسی شیءگرا
• درک الگوریتم‌ها و ساختارهای داده

مفاهیم رباتیک:

• حسگرها چگونه کار می‌کنند و چگونه با آن‌ها ارتباط برقرار می‌شود
• کنترل عملگر و سامانه‌های موتوری
• مبانی سامانه‌های خودمختار و کنترل بازخوردی

ROS (Robot Operating System):

• درک سامانهٔ پیام‌رسانی publish/subscribe
• ایجاد nodeها و serviceها
• کار با launch fileها و parameter serverها

کار عملی روی پروژه:

• ما با هم روی ایجاد یک ROS service همکاری کردیم که سامانهٔ LED روی سر Triton را کنترل می‌کرد
• او یاد گرفت کدی تمیز و مستند بنویسد که با سیستم‌های موجود ما یکپارچه می‌شد
• سرویس کنترل LED که او ایجاد کرد، به بخشی دائمی از کدبیس Triton تبدیل شد

آنچه این راهنمایی را به‌طور خاص ویژه می‌کرد، دیدن پیشرفت او از کسی که تقریباً هیچ چیز دربارهٔ برنامه‌نویسی نمی‌دانست به فردی بود که کد معناداری به یک پروژهٔ پژوهشی فعال کمک می‌کرد. او از پرسیدنِ «متغیر چیست؟» به اشکال‌زدایی مستقل مشکلات ارتباطی ROS و نوشتن پیاده‌سازی‌های سرویس خودش رسید.

سیستم کنترل LED که او توسعه داد، به پژوهشگران اجازه می‌داد به‌سادگی رنگ‌ها و الگوهای LEDهای سرِ Triton را از طریق فرمان‌های سادهٔ ROS تغییر دهند. این شاید ساده به نظر برسد، اما به درک معماری ROS، اتصال‌دهی سخت‌افزار، و الگوهای مناسب طراحی نرم‌افزار نیاز داشت. سهم او هنوز هم امروز در آزمایشگاه استفاده می‌شود.

این راهنمایی و منتورینگ به همان اندازه که برای او آموزشی بود، برای من هم آموزشی بود. این کار مرا وادار کرد مفاهیم پیچیده را به بخش‌های قابل‌هضم تقسیم کنم و واقعاً دربارهٔ مبانی کاری که انجام می‌دادیم فکر کنم. آموزش دادن به شخصی دیگر مرا به مهندس و پژوهشگر بهتری تبدیل کرد.

همکاری با پژوهش دکتری

یکی از حرفه‌ای‌ترین و پاداش‌بخش‌ترین جنبه‌های زمانی که در آزمایشگاه بودم، کار نزدیک با پنگ، دانشجوی دکتری‌ای بود که پژوهش او بر الگوریتم‌های خودروهای خودران متمرکز بود. بهبودهای نرم‌افزاری‌ای که من در سیستم Triton انجام داده بودم، به پشتیبانی از پژوهش دکتری او کمک کرد.

پژوهش پنگ به هماهنگی دقیق و قابل‌اعتمادِ چندرباته نیاز داشت تا سناریوهای خودروهای خودران را شبیه‌سازی کند. پیش از بهبودهای من در کنترل حرکت و سیستم‌های چندرباته، انجام این آزمایش‌ها بسیار دشوارتر بود. ربات‌ها کندتر بودند، دقت کمتری داشتند، و نمی‌توانستند به همان اندازه مؤثر با هم کار کنند.

سهم‌های من به پژوهش پنگ در چندین حوزه کمک کرد:

مطالعات مدیریت تقاطع: با کنترل‌کننده‌های PID بهبود‌یافته و هماهنگی چندرباته، پنگ می‌توانست سناریوهای تقاطع را شبیه‌سازی کند که در آن چند «وسیلهٔ نقلیه» (Tritonها) باید حرکت خود را هماهنگ می‌کردند. زمان‌بندی و موقعیت‌یابی بهتر این مطالعات را عملی‌تر کرد.

ارتباطات خودرویی با خودرویی: چارچوب چندپردازشی‌ای که من توسعه دادم به پنگ اجازه داد پروتکل‌های ارتباطی میان خودروهای شبیه‌سازی‌شده را پیاده‌سازی و آزمایش کند. هر Triton می‌توانست در حالی که همچنان با دیگران هماهنگ می‌شد، تصمیم‌گیری کند، مشابه این‌که خودروهای خودران چگونه ممکن است نیاز به کارکردن داشته باشند.

پژوهش SLAM و نقشه‌برداری: کار یکپارچه‌سازی حسگر عمق، داده‌های بیشتری را برای پژوهش پنگ در زمینهٔ مکان‌یابی و نقشه‌برداری هم‌زمان فراهم کرد. داشتن چندین ربات با قابلیت‌های حسگری هماهنگ، آزمایش‌های نقشه‌برداری جامع‌تری را ممکن ساخت.

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

ساعت‌های زیادی را با هم در آزمایشگاه گذراندیم، سناریوها را اشکال‌زدایی می‌کردیم، دربارهٔ راهبردهای مختلف کنترل بحث می‌کردیم، و بررسی می‌کردیم که پلتفرم Triton چه کارهایی می‌تواند انجام دهد. پنگ همکار و دوستی برای من شد، و کار کردن با او چیزهای زیادی دربارهٔ این‌که پژوهش دانشگاهی واقعاً چگونه کار می‌کند به من آموخت.

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

حتی پس از آن‌که آزمایشگاه را ترک کردم، من و پنگ همچنان در تماس ماندیم. دانستن این‌که کار من حتی پس از رفتنم همچنان به پژوهش مهم کمک می‌کرد، بسیار پاداش‌بخش بود.

چشم‌انداز: دوران پیش از LLM در توسعه

ارزش دارد که یادآوری شود تمام این کارها در دوران پیش از LLM در توسعهٔ نرم‌افزار انجام شد. همهٔ این‌ها بین 2020 تا 2021 (عمدتاً 2021)، پیش از وجود ChatGPT، Claude، Perplexity، یا ابزارهای توسعهٔ مبتنی بر هوش مصنوعی مانند Cursor IDE رخ داد.

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

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

همه‌چیز را به‌صورت دستی پژوهش کنم: فهم نظریهٔ کنترل PID یعنی خواندن کتاب‌های درسی و مقالات علمی. فهم تبدیل‌های مختصات نیاز داشت که ریاضیات را به‌صورت دستی گام‌به‌گام پیش ببرم. هر مفهومی باید پیش از پیاده‌سازی کاملاً درک می‌شد.

بدون کمک هوش مصنوعی اشکال‌زدایی کنم: وقتی ربات‌ها در جهات غیرمنتظره حرکت می‌کردند یا اطراف اهداف نوسان می‌کردند، باید با دقت منطق را ردگیری می‌کردم، خروجی‌های اشکال‌زدایی اضافه می‌کردم، و فرضیه‌ها را یکی‌یکی آزمایش می‌کردم. هیچ هوش مصنوعی‌ای برای پیشنهاد مشکلات احتمالی یا کمک به تفسیر الگوهای خطا وجود نداشت.

از اصول نخستین یاد بگیرم: بدون امکان این‌که سریع بپرسم «چطور پردازش چندگانه را در Python برای رباتیک پیاده‌سازی کنم؟» باید مفاهیم زیربنایی را عمیقاً می‌فهمیدم. این مرا واداشت تا پایه‌ای محکم در برنامه‌نویسی هم‌زمان، سامانه‌های کنترلی، و بینایی رایانه‌ای بسازم.

مستندسازی حیاتی بود: چون نمی‌توانستم بعداً برای توضیح کد به هوش مصنوعی تکیه کنم، باید مستندات و توضیحات فوق‌العاده روشنی می‌نوشتم. این انضباط در انتقال دانش به دیگران بسیار ارزشمند از کار درآمد.

وقتی به گذشته نگاه می‌کنم، اگرچه ابزارهای مدرن هوش مصنوعی بسیاری از جنبه‌های توسعه را شتاب می‌دادند، کار کردن بدون آن‌ها مرا واداشت مهارت‌های عمیق‌تری در حل مسئله و درک کامل‌تری از سیستم‌های زیربنایی توسعه دهم. جالب است فکر کنم اگر ابزارهای توسعهٔ امروزی در دسترس بودند، این پروژه چقدر می‌توانست متفاوت باشد.

تصمیم دشوار برای ترک

هرچند کار کردن در HCR Lab را بسیار دوست داشتم، تا اواخر 2021 با تصمیمی دشوار روبه‌رو شدم که بسیاری از دانشجویان با آن مواجه می‌شوند: متعادل‌کردن فرصت‌ها و مسئولیت‌های متعدد. هم‌زمان به‌صورت تمام‌وقت به‌عنوان مهندس نرم‌افزار در eBay کار می‌کردم، مدرک علوم رایانه‌ام را در Mines به پایان می‌رساندم، و به پژوهش در HCR Lab کمک می‌کردم.

فرصت eBay مهم بود؛ این نخستین نقش عمدهٔ من در مهندسی نرم‌افزار بود، تجربهٔ صنعتی ارزشمندی فراهم کرد، و درآمدی ثابت به من داد. بااین‌حال، تلاش برای حفظ کار تمام‌وقت، تکمیل مدرک، و مشارکت معنادار در پژوهش، به‌سادگی پایدار نبود. چیزی باید کنار گذاشته می‌شد.

وقتی نزد دکتر ژانگ رفتم و احتمال کاهش حجم دروسم را مطرح کردم تا بیشتر بر کار آزمایشگاه تمرکز کنم، او به‌شدت با این کار مخالفت کرد. استدلال او منطقی بود: تکمیل مدرکم باید اولویت باشد، و تجربهٔ صنعتی در eBay برای رشد حرفه‌ای من ارزشمند خواهد بود. او احساس می‌کرد که حذف درس‌ها برای تمرکز بر پژوهش، هرچند وسوسه‌انگیز، شاید بهترین تصمیم بلندمدت نباشد.

پس در سپتامبر 2021، پس از حدود 8 ماه کار فشرده در آزمایشگاه، تصمیم دشوار را گرفتم که از نقش دستیار پژوهشی‌ام کنار بروم تا بر تکمیل مدرکم و کارم در eBay تمرکز کنم. این یکی از سخت‌ترین تصمیم‌های حرفه‌ای‌ای بود که تا آن زمان گرفته بودم.

حتی پس از ترک رسمی آزمایشگاه، هر زمان کسی برای کمک با سیستم‌هایی که ساخته بودم نیاز داشت، همچنان پشتیبانی ارائه می‌دادم. هرجا لازم بود مستندات را به‌روزرسانی می‌کردم، به پرسش‌ها دربارهٔ اشکال‌زدایی پاسخ می‌دادم، و از راه دور به برطرف‌کردن مشکلات کمک می‌کردم. ارتباطاتی که ساخته بودم و سرمایه‌گذاری‌ای که در موفقیت پروژه داشتم، فقط چون دیگر رسماً بخشی از تیم نبودم، از بین نرفت.

تأملات و نگاه به گذشته

اکنون، در 2025، چهار سال بعد، خودم را در حال تأمل دربارهٔ آن زمان با احساسات پیچیده می‌یابم. مسیر شغلی‌ام مرا عمیقاً به توسعهٔ وب و مهندسی AI/ML برده است، حوزه‌هایی که به‌طرز فوق‌العاده‌ای پاداش‌بخش بوده‌اند و فرصت‌های عظیمی برای رشد و اثرگذاری فراهم کرده‌اند.

بااین‌حال بخشی از من می‌پرسد «اگر». رباتیک، و صادقانه بگویم هنوز هم، اشتیاق واقعی من بود. چیزی در کار با سیستم‌های فیزیکی هست، در دیدن این‌که کد شما به حرکت و رفتار دنیای واقعی تبدیل می‌شود، که توسعهٔ وب و حتی کار AI به‌طور کامل نمی‌توانند بازآفرینی‌اش کنند.

گاهی فکر می‌کنم اگر مسیر متفاوتی را انتخاب کرده بودم چه می‌شد. اگر راهی برای ماندن در پژوهش رباتیک پیدا می‌کردم چه؟ اگر بلافاصله پس از پایان دورهٔ کارشناسی وارد تحصیلات تکمیلی می‌شدم چه؟ اگر تصمیم می‌گرفتم کار آزمایشگاه را بر تجربهٔ صنعتی اولویت بدهم چه؟

اما همچنین می‌دانم که هر مسیری هزینه‌ها و فایده‌های خودش را دارد. مهارت‌هایی که در توسعهٔ وب و AI به دست آوردم فوق‌العاده ارزشمند بوده‌اند. تجربهٔ صنعتی به من دربارهٔ مهندسی نرم‌افزار در مقیاس بزرگ، طراحی تجربهٔ کاربر، و چالش‌های عملی ساخت محصولاتی که میلیون‌ها نفر از آن‌ها استفاده می‌کنند، آموخت. این تجربه‌ها مرا به‌طور کلی مهندس بهتری کرده‌اند.

کاری که در HCR Lab انجام دادم همچنان بر شیوهٔ مواجههٔ من با مسائل امروز تأثیر می‌گذارد. تفکر نظام‌مند لازم برای سیستم‌های کنترل PID در این‌که چگونه حلقه‌های بازخورد را در سامانه‌های نرم‌افزاری طراحی می‌کنم دیده می‌شود. مهارت‌های مستندسازی و حفظ دانش که توسعه دادم در هر نقشی از آن زمان تاکنون بسیار ارزشمند بوده‌اند. تجربهٔ راهنمایی و آموزش، شیوهٔ کار من با توسعه‌دهندگان کم‌تجربه‌تر و مشارکت من در اشتراک‌گذاری دانش تیم را شکل داده است.

مهم‌تر از همه، این تجربه به من آموخت که وقتی روی مسائل فنی چالش‌برانگیزی کار می‌کنم که اثر واقعی در دنیای واقعی دارند، شکوفا می‌شوم. چه بهینه‌سازی الگوریتم‌های حرکت ربات باشد و چه ساخت سامانه‌های هوش مصنوعی که به کاربران کمک می‌کنند اهدافشان را محقق کنند، رضایت از حل مسائل سختی می‌آید که اهمیت دارند.

تأثیر ماندگار

وقتی به تجربهٔ HCR Lab نگاه می‌کنم، تحت تأثیر این قرار می‌گیرم که در زمانی نسبتاً کوتاه چه‌قدر دستاورد داشتم. سیستم‌هایی که ساختم، به‌طور بنیادی نحوهٔ کارکرد پلتفرم Triton را تغییر دادند، و بسیاری از آن بهبودها هنوز هم امروز استفاده می‌شوند. مخزن مستندسازی‌ای که ایجاد کردم به پایگاه دانش کل پروژه تبدیل شد. روابط منتورینگی‌ای که شکل دادم تأثیری ماندگار بر افرادی گذاشت که با آن‌ها کار می‌کردم.

اما شاید مهم‌تر از همه، این تجربه به من نشان داد که وقتی روی مسائلی کار می‌کنم که واقعاً به آن‌ها علاقه‌مندم، تا چه اندازه توانایی دارم. در آن هشت ماه، من:

• سامانهٔ کنترل حرکت ربات را که پلتفرم را محدود می‌کرد بهبود دادم
• یک سامانهٔ هماهنگی چندرباتی را از صفر ساختم
• قابلیت‌های بینایی ماشین و همجوشی حسگرها را یکپارچه کردم
• یک سامانهٔ جامع مستندسازی و مدیریت دانش ایجاد کردم
• چندین نفر را راهنمایی کردم و در انتقال دانش کمک کردم
• از پژوهش در سطح دکتری در خودروهای خودران پشتیبانی کردم

این فقط دربارهٔ دستاوردهای فنی نبود، هرچند آن‌ها برای من معنادار بودند. مسئله این بود که یاد بگیرم با پشتکار و تفکر نظام‌مند، حتی به‌عنوان یک دانشجوی کارشناسی هم می‌توانی مشارکت‌های مفیدی داشته باشی.

آینده و رباتیک

هرچند مسیر شغلی‌ام مرا به سمت‌های دیگری برده است، اما اشتیاقم به رباتیک کم نشده است. من هنوز تحولات این حوزه را دنبال می‌کنم، از پیشرفت‌ها در یادگیری ربات و سامانه‌های خودران هیجان‌زده می‌شوم، و گاهی در اوقات فراغتم روی پروژه‌های شخصی رباتیک کار می‌کنم.

چه کسی می‌داند آینده چه در پیش دارد؟ مهارت‌هایی که در هوش مصنوعی و یادگیری ماشین در حال توسعهٔ آن‌ها هستم، به‌طور فزاینده‌ای برای رباتیک مرتبط‌اند. تجربهٔ صنعتی‌ای که به دست آورده‌ام به من آموخته است که چگونه سامانه‌های مقاوم و مقیاس‌پذیر بسازم. شاید آینده‌ای وجود داشته باشد که در آن این رشته‌های گوناگون از تجربهٔ من به شیوه‌هایی غیرمنتظره در کنار هم قرار بگیرند.

فعلاً، بابت زمانی که در آزمایشگاه HCR گذراندم و تجربه‌هایی که به من داد سپاسگزارم. آن دوره، دوره‌ای شکل‌دهنده بود که هم مهارت‌های فنی من و هم درکم از این‌که چه نوع کاری برایم بیشترین رضایت را دارد، شکل داد. حتی اگر گاهی دلتنگش می‌شوم، می‌دانم درس‌هایی که آموختم و رویکردهایی که توسعه دادم همچنان بر هر کاری که انجام می‌دهم اثر می‌گذارند.

ربات‌های Triton هنوز آنجا هستند، هنوز به پژوهشگران خدمت می‌کنند، هنوز کاری مهم را ممکن می‌سازند. و این واقعاً فوق‌العاده است.