Мій розділ досліджень з робототехніки

Ця публікація розповідає про мою подорож у робототехніці, починаючи з того, як я відкрив для себе пристрасть до робототехніки в FRC під час школи у 2015 році, і до мого часу як асистента-дослідника в Лабораторії робототехніки, орієнтованої на людину (HCR) Колорадської школи гірничої справи з лютого 2021 року по вересень 2021 року. Зауважте, що з кінця 2022 року HCR Lab переїхала з Colorado School of Mines до Університету Массачусетса в Амгерсті, разом із сайтом з hcr.mines.edu на hcr.cs.umass.edu.

Передісторія

Я розпочав навчання на бакалавраті в Colorado School of Mines восени 2018 року. Моєю спеціальністю була інформатика з фокусом на робототехніку та інтелектуальні системи. І я закінчив навчання навесні 2022 року.

Мені пощастило рано знайти свою пристрасть у житті. Під час школи я витратив чимало часу, щоб зрозуміти, що мені подобається і в чому я можу бути хорошим. Після деяких спроб і помилок я зміг зрозуміти, що моєю пристрастю є інформатика. Але саме в цей час я також відкрив, що маю надзвичайну любов до створення через код.

У Mines я отримав можливість працювати в Лабораторії робототехніки, орієнтованої на людину (HCR), під керівництвом доктора Хао Чжана. Я вперше познайомився з доктором Чжаном навесні 2020 року на його курсі «Human Centered Robotics» (CSCI473), а після хаосу COVID і навчальних завдань мені вдалося почати працювати в його лабораторії на початку весни 2021 року.

Курс Human Centered Robotics (CSCI473)

Human Centered Robotics (CSCI473) у Mines був одним із небагатьох курсів у моєму університетському досвіді, що справив на мене глибокий вплив. Курс викладав доктор Хао Чжан. Увесь наш підсумковий бал складався лише з трьох проєктів, кожен з яких пропонував складну проблему, що вводила в основні концепції робототехніки. Ці проєкти складалися з:

1. Вивчення Robot Operating System (ROS)
2. Навчання з підкріпленням для слідування робота вздовж стіни
3. Розуміння роботом людської поведінки за допомогою скелетних представлень

Вивчення Robot Operating System (ROS)

Це був перший проєкт, який нам призначили. Проєкт складався з трьох завдань:

1. Налаштувати середовище розробки
2. Зрозуміти симулятор Gazebo
3. Написати ROS «Hello World»

Для завдань 1 і 2 нам просто потрібно було налаштувати середовище розробки та пройти вступний урок із Gazebo. Це включало:

• Налаштування ROS Melodic, яке я зробив на своєму ноутбуці HP 2011 року, і цього було достатньо
• Встановлення та налаштування ROS і Gazebo
• Проходження підручника gazebosim та підручника e-manual.

Завдання 3, з іншого боку, було справжнім викликом. Завдання полягало у використанні turtlesim і тому, щоб черепаха намалювала логотип Mines «M»:

Хоча це завдання звучало просто, воно було складнішим, ніж здавалося. Зрештою цей проєкт познайомив мене з поняттям систем з розімкненим і замкненим контуром. Повний опис проєкту можна знайти в 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) і використовуватимуть машини опорних векторів (SVMs) (Поставка 2) для класифікації людської поведінки за допомогою загальнодоступного набору даних про активності, зібраного з датчика Kinect V1. Крім того, студенти повинні написати звіт у форматі стандартних робототехнічних конференцій IEEE з використанням LATEX у Поставці 3.

Цей проєкт був складним, але не таким важким, як другий проєкт. Основною метою було використати дані датчика Kinect V1 з MSR Daily Activity 3D Dataset і машини опорних векторів для класифікації певних людських дій/поведінок. Повний опис проєкту можна знайти в csci473-p3.pdf, або ж ви можете дізнатися більше про цей проєкт і моє рішення в дописі блогу Predict Human Actions Using LIBSVM.

Висновок CSCI473

CSCI473 — це один із найкращих, якщо не найкращий курс, який я проходив під час бакалаврату в Mines. Усі ці проєкти багато чому мене навчили й дали мені чудовий каталог проєктів, на які я можу озиратися та які можу згадувати в резюме. Це також був перший курс, на якому я відчув, що перебуваю у своїй стихії, оскільки я ніколи не був хорошим у складанні іспитів, але чудово виконував проєкти. Саме через цей курс я також познайомився з доктором Хао Чжаном, який згодом допоміг мені отримати посаду асистента-дослідника в Лабораторії робототехніки, орієнтованої на людину (HCR), у Mines.

Польова сесія з інформатики (літо 2020)

Протягом літа 2020 року, між завершенням CSCI473 і приєднанням до HCR Lab, я пройшов CSCI370 або «Advanced Software Engineering» у межах моєї бакалаврської програми з інформатики в Colorado School of Mines. CSCI370 — це курс, який змушує студентів проєктувати, реалізовувати та документувати програмні рішення для компанії. Він дає студентам змогу застосовувати знання, здобуті на курсах, до реальних проблем інформатики. Дізнатися більше про курс можна тут.

На курсі ви самі вирішуєте, над яким проєктом/компанією будете працювати. Курс надавав PDF-файли з описом кожного проєкту та компанії. Зрештою я вирішив працювати над проєктом, розміщеним компанією Lunar Outpost, під назвою «Real Time Wheel Slip Detection and Error Corrections for Enhanced Lunar Navigation». Оскільки назва довга, назвімо цей проєкт «Виявлення ковзання коліс».

Проблема

Lunar Outpost — це стартап, який намагається створити автономні місяцеходи. На Місяці є багато місячного пилу, який, як відомо, спричиняє значне ковзання коліс. Це небажано, тому що ковзання коліс може призвести до втрати автономними системами їхнього реального місцеположення. На Землі це вирішується використанням даних GPS для корекції будь-якого зсуву, спричиненого ковзанням коліс. Але проблема GPS полягає в тому, що він працює лише завдяки 30+ навігаційним супутникам, які постійно обертаються навколо Землі на орбіті та передають унікальні сигнали, що дозволяють комп’ютерам обчислювати своє місцеположення. Але на Місяці наразі нічого подібного до GPS не існує. З огляду на це, для виявлення ковзання коліс потрібно використати інший метод, ніж GPS. Детальніший звіт про проблему проєкту можна переглянути тут.

Команда

Цей проєкт не був простим, тому його потрібно було виконувати в команді. Команда складалася з п’ятьох інших студентів Colorado School of Mines:

Цей проєкт не був простим, тому його потрібно було виконувати в команді. Ця команда складалася з Mehmet Yilmaz (мене), Kane Bruce, Braedon O’Callaghan, Liam Williams і Kevin Grant.

Проєкт вимагав від нас знань ROS, C++, Python, Linux, Raspberry Pi та Arduino. Більшість із нас мала досвід роботи з однією або кількома з цих технологій, але я був єдиним, хто мав досвід у ROS, оскільки я використовував ROS на курсі Human Centered Robotics (CSCI473) протягом весняного семестру 2020 року. Через це на початку я допомагав усім швидко освоїтися з ROS і тим, як для нього розробляти.

Виклики

У цьому проєкті було багато викликів. Але найбільшим викликом, з яким ми зіткнулися, було те, що ми не мали доступу до реального робота для тестування. Це було пов’язано з COVID, який перевів усе в дистанційний формат і не дозволяв нам працювати в лабораторії/будівлях Lunar Outpost. Через це нам довелося використовувати симуляції.

Також ми ознайомилися з деякими академічними дослідженнями з WVU Navigation Lab, щоб отримати уявлення про те, як можна розв’язати проблему ковзання коліс для сценарію використання Lunar Outpost, що для нас, як для студентів другого й третього курсів бакалаврату, було складніше, ніж ми очікували.

Ще одним викликом був обсяг часу, який ми мали на роботу над цим проєктом. CSCI370 — це одномісячний курс. Але сама проблема є масштабною проблемою, яку багато компаній і науковців намагаються розв’язати/вдосконалити десятиліттями. Тож одного місяця аж ніяк не достатньо, щоб розв’язати цю проблему. Але, попри всі ці виклики, ми продовжували рухатися вперед і подбали про те, щоб завершити роботу.

Висновок

Після роботи над усіма дослідженнями та розробкою ми дійшли висновку, що практично неможливо коректно симулювати місячну фізику в цифровому середовищі, тож справді випробовувати цей алгоритм у симуляції не має сенсу і це не дасть жодних змістовних результатів дослідження щодо виявлення ковзання коліс у космосі та на Місяці. Ми зробили висновок, що налаштування належного тестового середовища з використанням чогось на кшталт піску та реального обладнання, наприклад робота Husky, є набагато важливішим для такого типу досліджень. Ми оновили код виявлення ковзання коліс, щоб він працював як вузол ROS, і він функціонував належним чином та легко міг бути перенесений на реальне обладнання для тестування. Цей проєкт дав мені змогу взяти на себе лідерську роль, навчити моїх колег розробці для ROS і отримати досвід роботи з Python, ROS та Gazebo, одночасно розв’язуючи складну проблему, з якою я раніше ніколи не стикався. Найважливіше, цей досвід ще більше зміцнив мою пристрасть до робототехніки та підсилив моє бажання займатися дослідженнями в цій галузі, заклавши основу для того, що мало статися далі в моїй робототехнічній подорожі.

Початок у лабораторії HCR

Після завершення CSCI473, мого літнього польового заняття з комп’ютерних наук у 2020 році та осіннього семестру 2020 року я вирішив займатися дослідженнями в робототехніці. У мене були такі чудові враження і від CSCI473, і від польового заняття з комп’ютерних наук, що я вирішив, що хочу проводити дослідження в лабораторії HCR. Оскільки я познайомився з доктором Чжаном ще за рік до того, я вирішив написати йому електронного листа та дізнатися про будь-які можливості, які могла мати лабораторія, у січні 2021 року. Приблизно за 2 тижні доктор Чжан виявив зацікавленість, представив мені варіанти досліджень і запропонував мені роль у лабораторії. Після цього я почав працювати в лабораторії в лютому 2021 року.

Вступне відео

Ось моє вступне відео, яке я записав через кілька місяців після початку роботи в лабораторії HCR. Воно було записане в травні 2021 року і висвітлює дослідження, яким я зосереджувався в лабораторії HCR протягом літа 2021 року:

Мій проєкт

Протягом усього часу в лабораторії HCR я переважно зосереджувався на проєкті Triton. Проєкт Triton — це мобільний робот, розроблений Human Centered Robotics Lab у Colorado School of Mines. Це наземний трикутний омніколісний робот, що працює на NVIDIA Jetson Nano.

Triton, у простому огляді, складався з таких частин:

• NVIDIA Jetson Nano
• плата-носій NVIDIA Seed Studio A205
• Arduino Mega
• Micro SD-карта на 64 ГБ
• спеціально виготовлений корпус, надрукований на 3D-принтері
• 3 колеса mecanum
• 1 AR Battery
• спеціальні схеми для оптимізованого розподілу живлення та прокладання проводки
• камера Intel Realsense D435
• кілька світлодіодів

Його спроєктували, зібрали та виготовили приблизно у 2018–2020 роках як робота для освітніх цілей. На той момент, коли я приєднався, Triton уже був доволі усталеним проєктом, і лабораторія розглядала можливість створення нової версії. Однак головною проблемою Triton було його програмне забезпечення. Triton міг рухатися, заряджатися та функціонувати в базовому сенсі, але насправді не робив нічого розумного. Йому навіть бракувало здатності виконувати більш складні рухи.

Щоб почати розв’язувати цю проблему, лабораторія облаштувала зону, де ми могли відстежувати Triton. Для цього вони створили ділянку 2 метри на 2 метри з 8 камерами Optitrack Flex (інфрачервоними) у квадратоподібній конфігурації приблизно на висоті 6–7 футів над підлогою.

Окрім створення цієї зони, до верхньої частини кожного Triton було прикріплено три сірі кульки-сфери.

З такою конфігурацією ми фактично побудували власну GPS-систему в малому масштабі, що дозволяла нам отримувати точні координати Triton у метрах у нашій зоні інтересу. Використовуючи інфрачервоні камери Optitrack і сірі сфери Optitrack у трикутному розташуванні, ми могли точно визначати координати Triton у нашій зоні. Це дозволяло нам застосовувати систему із замкненим контуром для кращої точності руху.

Система Optitrack надавала дані про позицію та орієнтацію приблизно з частотою 120 Гц із субміліметровою точністю за належного калібрування. Три відбивні маркери кожного Triton утворювали унікальний трикутний візерунок, який система могла відстежувати як жорстке тіло. Система координат була відкалібрована так, що (0,0) знаходилася в центрі зони відстеження, а осі X і Y були вирівняні за геометрією кімнати. Але попри такі точні дані про позицію, Triton усе одно мав труднощі з рухом.

З такою конфігурацією однією з ключових функцій, яку ми хотіли надати Triton, була здатність рухатися до конкретної координати. Користувач або його програмне забезпечення могли задавати координату (x, y) у межах своєї зони інтересу. Потім робот мав рухатися до цієї координати якомога швидше, точніше й плавніше. Коли я приєднався, ця функція вже існувала, але працювала не дуже добре. Ось проста анімація, що показує, як працювала початкова логіка руху:

Я не записував початкове рішення в дії, тому створив цю просту анімацію, яка показує стару логіку руху в роботі. Знаючи це, які проблеми має цей метод?

1. Він дуже повільний
2. Через нього роботу потрібно займати багато місця лише для того, щоб дістатися до конкретної точки. Це ускладнювало використання цього рішення, коли одночасно рухалися кілька Triton.

То чому ж така поведінка виникала? Проблема була в тому, що Triton спочатку розвертався, змінюючи свій alpha, доки не починав дивитися в бік цільової точки в межах певної похибки. Потім він ривком рухався вперед, і коли його theta відхилялася від цілі на певну величину, він зупинявся й знову починав повертатися, доки alpha не потрапляла в прийнятний діапазон для цільової точки. Потім він знову ривком рухався вперед і продовжував так робити, доки не досягав точки. Також, чим ближче він підходив до цільової точки, тим повільнішими ставали поворот і ривок уперед, щоб не перетнути ціль. У результаті Triton рухався неприродно, витрачав вічність, щоб дістатися до цільової точки, і потребував занадто великої площі лише для того, щоб досягти конкретної цільової точки. Отже, з усіма цими проблемами, і з огляду на те, наскільки важливою була ця функція для розвитку проєкту Triton, коли я почав працювати в лабораторії HCR, моїм першим завданням було розробити ефективніші рішення, які дозволили б Triton краще пересуватися до цільової точки.

Розуміючи це, я витратив багато часу на дослідження найкращого можливого способу розв’язання цієї проблеми. Іронічно, я проходив курс під назвою Introduction to Feedback Control Systems (EENG307) у Mines. На початку цього курсу ми вивчали концепцію розімкнених систем керування та замкнених систем керування. Знаючи це, і після певної розмови з викладачем цього курсу та моїм кмітливим сусідом по кімнаті, стало зрозуміло, що ця мета — довести Triton до цільової точки — є проблемою замкненої системи.

Тепер, після масштабного тестування та дослідження, я розробив два різні підходи контролерів для Triton:

Метод 1: Контролер Distance-Theta

Цей підхід використовував два окремі пропорційні контролери, що працювали одночасно:

• Контролер відстані: Обчислював евклідову відстань до цілі та застосовував пропорційний коефіцієнт для визначення швидкості руху вперед/назад
• Контролер Theta: Обчислював кутову похибку між поточним напрямком робота та бажаним напрямком до цілі, застосовуючи окремий пропорційний коефіцієнт для кутової швидкості

Алгоритм безперервно обчислював евклідову відстань до цілі та кутову похибку між поточним напрямком робота і бажаним напрямком. Для формування лінійної та кутової швидкостей відповідно застосовувалися два окремі пропорційні коефіцієнти.

У результаті Triton природно повертав у бік цілі, одночасно рухаючись уперед, створюючи плавні криволінійні траєкторії. Головною перевагою було те, що робот завжди тримав свою передню частину орієнтованою до пункту призначення, що було критично важливо для застосувань на основі камери.

Метод 2: Контролер координат X-Y

Цей підхід розглядав робота як 2D-плотер із незалежним керуванням рухом по X та Y:

• Контролер X: Безпосередньо керував рухом на схід-захід на основі похибки координати X
• Контролер Y: Безпосередньо керував рухом на північ-південь на основі похибки координати Y

Реалізація окремо обчислювала похибки координат X та Y, застосовувала окремі коефіцієнти пропорційного підсилення, а потім перетворювала ці глобальні компоненти швидкості в локальну систему координат робота за допомогою матриць обертання. Це перетворення було необхідним, оскільки омніколісна ходова частина робота вимагала швидкостей у власній системі відліку, а не в глобальних координатах. Цей метод забезпечував найпряміші траєкторії до цілей і був значно швидшим, але орієнтація робота дрейфувала, оскільки не було явного керування напрямком.

Щодо методу #1, я докладно описав цей метод у своєму блозі про Move Turtle (TurtleSim). Дуже рекомендую вам прочитати цей блог, щоб отримати всі деталі про те, як загалом працюють PID-контролери, а також як працює метод #1. Я розробив метод #1 за допомогою TurtleSim від ROS, а потім переніс цей код на Triton і оновив його, щоб врахувати більш реальне середовище.

Метод #2 використовував зовсім інший, але не менш ефективний підхід. Замість того щоб думати про орієнтацію робота та відстань до цілі, цей метод трактує рух як задачу на координатній площині. Контролер безперервно окремо обчислює похибку в напрямках X і Y. Наприклад, якщо роботу потрібно переміститися з (0,0) до (2,3), він сприймає це як потребу виправити похибку в 2 метри по X і похибку в 3 метри по Y. Два пропорційні контролери працювали одночасно: один коригував швидкість робота в напрямку X на основі похибки X, тоді як інший обробляв рух у напрямку Y на основі похибки Y. Це створювало більш пряму траєкторію до цілі, подібно до того, як рухається головка 3D-принтера, і дозволяло плавні діагональні переміщення. Роботу не потрібно було явно повертатися, щоб “дивитися” на ціль, що робило цей метод особливо ефективним у тісних просторах або там, де потрібне точне позиціонування.

Обидва методи виявилися значно швидшими та надійнішими за початковий підхід. Щоб побачити ці нові методи в дії, перегляньте плейлист Tritons in Action, який показує всіх Triton у роботі з новими методами.

Те, що раніше займало 30–45 секунд для простого переміщення з точки в точку, тепер займало приблизно 8–12 секунд. Що важливіше, Triton тепер міг ефективніше пересуватися в тісних просторах, що стало корисним для наших сценаріїв із кількома роботами.

Виклики розробки та налагодження

Впровадження цих контролерів не було простим і включало кілька суттєвих викликів із налагодженням:

Перетворення систем координат: Одним із найскладніших аспектів було правильно виконати перетворення координат. Система Optitrack надавала дані у власній системі координат, робот мав свою локальну систему координат, і мені потрібно було точно перетворювати дані між ними. Ранні реалізації призводили до руху роботів у неправильних напрямках, тому що я переплутав обчислення матриць обертання.

Реальна поведінка проти ідеальної: Найбільшим викликом було врахування реальних факторів, які не з’являються в підручниковій теорії керування. Колеса робота мали різні характеристики тертя, двигуни не реагували однаково, і в ланцюгу зв’язку від Optitrack до програмного забезпечення керування та до Arduino робота завжди була певна затримка. Я витратив тижні на налаштування коефіцієнтів пропорційного підсилення та додавання фільтрів мертвої зони, щоб врахувати ці фізичні реалії.

Проблеми осциляції та стабільності: Мої перші реалізації страждали від проблем з осциляцією, коли роботи перелітали цілі та коливалися вперед-назад. Це навчило мене важливості диференціальних членів у PID-контролерах і потреби в належному налаштуванні коефіцієнтів. Зрештою я зупинився переважно на пропорційному керуванні з ретельно налаштованими коефіцієнтами, а не на повному PID, оскільки внутрішнього демпфування системи було достатньо для більшості застосувань.

Взаємний вплив кількох роботів: Коли кілька роботів працювали одночасно, я виявив неочікувані патерни взаємного впливу. Роботи іноді “боролися” за той самий простір або створювали ситуації взаємного блокування, коли вони безкінечно заважали один одному. Це спонукало мене впровадити механізми координації та алгоритми уникнення зіткнень.

Система керування кількома Triton

Після того як я розв’язав проблему руху одного Triton, наступним викликом лабораторії стало змусити кілька Triton працювати разом одночасно. Це стало одним із моїх головних напрямів роботи й зрештою виявилося значним внеском у проєкт.

Початкова система могла керувати лише одним Triton за раз, що серйозно обмежувало дослідницькі можливості. Лабораторія хотіла моделювати сценарії, у яких кілька автономних транспортних засобів мали координувати свої переміщення, як-от автомобілі з автопілотом, що обмінюються даними між собою для оптимізації транспортного потоку та створення кращих карт SLAM (одночасна локалізація та побудова карти).

Щоб розв’язати це, я реалізував підхід із багатопроцесністю, використовуючи бібліотеку multiprocessing у Python. Кожен Triton отримав власний окремий процес, який міг працювати незалежно, але все ще координувався центральною системою керування. Це дозволило кільком Triton рухатися одночасно, не заважаючи контрольним циклам один одного.

Проєктування архітектури для кількох роботів

Розроблена мною архітектура системи складалася з кількох ключових компонентів:

Основний процес контролера: Він виконував роль центрального координатора, обробляючи взаємодію з інтерфейсом користувача, планування траєкторій і координацію високого рівня між роботами. Він підтримував глобальний стан і розподіляв команди між окремими процесами роботів.

Окремі процеси роботів: Кожен Triton мав власний виділений процес Python, який виконував:

• Обчислення PID-керування в реальному часі з частотою ~50 Гц
• Обмін даними з апаратною частиною робота (Arduino/Jetson)
• Виконання локальної траєкторії та уникнення перешкод
• Надсилання звітів про стан назад до основного контролера

Обмін через спільну пам’ять: Я використовував multiprocessing.shared_memory у Python та об’єкти Queue для забезпечення ефективного обміну даними між процесами. Це дозволяло координувати все в реальному часі без накладних витрат на мережевий зв’язок.

Механізми синхронізації: Щоб запобігти конфліктам, коли кілька роботів мали координуватися (наприклад, уникати зіткнень), я реалізував семафори та блокування, які дозволяли роботам запитувати виключний доступ до певних ділянок робочого простору.

Завдання полягало в тому, щоб усі роботи могли незалежно виконувати свої цикли керування, водночас підтримуючи глобальну координацію. Кожен процес робота виконував власні PID-обчислення та надсилав команди двигунам безпосередньо на апаратну частину, тоді як основний процес займався координацією вищого рівня, як-от уникнення зіткнень і планування траєкторій.

Система з кількома Triton відкрила абсолютно нові дослідницькі можливості. Тепер ми могли моделювати:

• Сценарії зв’язку між транспортними засобами
• Координоване планування траєкторій з уникненням перешкод
• Поведінку рою роботів
• Побудову карт SLAM для кількох агентів
• Керування формацією та поведінку слідування

Ось як виглядало лабораторне налаштування, коли одночасно працювали кілька Triton:

Я також розробив зручний інтерфейс, який дозволяв дослідникам візуально задавати траєкторії для кожного Triton. Ви буквально могли намалювати шлях, яким має рухатися кожен робот, і вони виконували ці траєкторії з ідеальною координацією. Це було неймовірно корисно для налаштування складних експериментів без потреби вручну програмувати кожен рух.

Система могла одночасно обробляти до 5 Triton, і кожен з них запускав власні PID-контролери, водночас координуючись через центральну систему керування. Продуктивність була вражаючою: усі роботи зберігали індивідуальну точність і водночас працювали разом як команда.

Ось плейлист, який показує Triton у дії — від керування одним роботом до координації кількох роботів: Tritons in Action Playlist

Інтеграція датчика глибини та корекція координат

Ще одним великим досягненням, над яким я працював, було використання камер глибини Intel RealSense D435, встановлених на кожному Triton. Хоча система Optitrack надавала нам неймовірно точні дані про позицію, я хотів дослідити, як роботи можуть використовувати свої бортові датчики, щоб покращити просторову обізнаність і скоригувати похибки координат.

Ідея полягала в тому, що Triton могли б використовувати свої датчики глибини для виявлення інших Triton поблизу та зіставляти їхні позиції. Це мало б кілька цілей:

1. Корекція похибок: Якщо система Optitrack мала б будь-який дрейф калібрування або тимчасове перекриття, роботи могли б використовувати візуальне підтвердження позицій один одного для підтримання точних систем координат.

2. Покращений SLAM: Маючи кілька роботів із датчиками глибини, що працюють разом, ми могли б створювати значно багатші карти середовища з надлишковими точками даних.

3. Уникнення зіткнень: Вимірювання глибини в реальному часі дозволило б роботам виявляти одне одного й уникати зіткнень навіть якщо центральна система керування мала б затримки зв’язку.

Я почав експериментувати з алгоритмами, які дозволили б Tritons:

• Виявляти інших Tritons за їхньою характерною трикутною формою та відбивними сферичними маркерами
• Обчислювати відносні положення та орієнтації, використовуючи дані глибини
• Порівнювати ці вимірювання з даними Optitrack, щоб виявляти розбіжності
• Потенційно коригувати свою систему координат у реальному часі, щоб підтримувати точність

Експерименти з комп’ютерним зором

Я витратив чимало часу на експерименти з конвеєром комп’ютерного зору, який працював у кілька етапів:

Обробка даних глибини: Intel RealSense D435 надавав як RGB, так і потоки даних глибини. Я переважно працював із даними глибини, які надходили у вигляді масиву 640x480 вимірювань відстані з частотою 30 Гц. Першим викликом було відфільтрувати ці шумні дані глибини, щоб виділити змістовну геометричну інформацію.

Спроби виявлення об’єктів: Я експериментував із багатоступеневими алгоритмами виявлення. Мені частково вдалося сегментувати зображення глибини, щоб ідентифікувати об’єкти на рівні підлоги (відфільтровуючи стіни, стелю тощо) та шукати об’єкти з потрібними характеристиками розміру, приблизно з відбитком 0.3x0.3 метра. Я намагався використовувати виявлення країв і геометричний аналіз, щоб ідентифікувати характерний профіль Triton, але результати були змішаними.

Експерименти з розпізнаванням маркерів: Три відбивні сфери на кожному Triton здавалися найперспективнішою ознакою для виявлення. Я експериментував із алгоритмами blob detection, щоб ідентифікувати характерний трикутний патерн із трьох яскравих точок на зображенні глибини. У контрольованих умовах освітлення я отримав кілька обнадійливих результатів, хоча це не було стабільно надійним.

Дослідження злиття координат: Я досліджував підходи до поєднання оцінок положення на основі зору з даними Optitrack, зокрема базові реалізації фільтра Калмана. Ідея полягала в тому, щоб надавати більшу вагу даним Optitrack, коли вони доступні, але повертатися до зору за потреби, хоча мені не вдалося повністю реалізувати це до завершення моєї роботи в лабораторії.

Проблеми продуктивності: Домогтися, щоб уся ця обробка працювала в реальному часі паралельно з контурами керування робота, виявилося складно. Я експериментував із підходами до оптимізації, щоб запускати алгоритми приблизно на 10-15 Гц, не перевантажуючи обчислювальні можливості 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 (Robot Operating System):

• Розуміння системи обміну повідомленнями publish/subscribe
• Створення вузлів і сервісів
• Робота з файлами запуску та серверами параметрів

Практична проєктна робота:

• Ми співпрацювали над створенням ROS-сервісу, який керував LED-системою на голові Triton
• Вона навчилася писати чистий, задокументований код, який інтегрувався з нашими наявними системами
• Створений нею сервіс керування LED став постійною частиною кодової бази Triton

Що робило це наставництво особливо особливим, так це спостереження за її прогресом: від майже повної відсутності знань із програмування до внесення змістовного коду в активний дослідницький проєкт. Вона пройшла шлях від запитання «Що таке змінна?» до самостійного налагодження проблем зв’язку ROS і написання власних реалізацій сервісів.

Розроблена нею система керування LED дозволила дослідникам легко змінювати кольори та шаблони світлодіодів на голові Triton за допомогою простих команд ROS. Це може звучати просто, але вимагало розуміння архітектури ROS, взаємодії з обладнанням і належних шаблонів проєктування програмного забезпечення. Її внесок досі використовується в лабораторії сьогодні.

Менторство було для мене настільки ж навчальним, як і для неї. Воно змусило мене розкладати складні концепції на зрозумілі частини й справді замислитися над основами того, що ми робили. Навчання іншої людини зробило мене кращим інженером і дослідником.

Співпраця з PhD-дослідженнями

Одним із найцінніших у професійному плані аспектів мого часу в лабораторії була тісна робота з Пенгом, аспірантом, чиї дослідження були зосереджені на алгоритмах для самокерованих автомобілів. Програмні вдосконалення, які я вніс у систему Triton, допомогли підтримати його докторське дослідження.

Дослідження Пенга вимагали точної, надійної координації кількох роботів, щоб моделювати сценарії самокерованих автомобілів. До моїх удосконалень системи керування рухом і багатороботних систем ці експерименти було значно важче проводити. Роботи були повільнішими, менш точними і не могли працювати разом так ефективно.

Мій внесок допоміг дослідженням Пенга в кількох напрямах:

Дослідження керування перехрестями: Завдяки вдосконаленим ПІД-регуляторам і координації кількох роботів Пенг міг моделювати сценарії перехресть, де кілька “транспортних засобів” (Triton) мали координувати свої рухи. Кращий таймінг і позиціювання зробили ці дослідження більш здійсненними.

Комунікація між транспортними засобами: Фреймворк багатопроцесної обробки, який я розробив, дозволив Пенгу впроваджувати й тестувати протоколи зв’язку між змодельованими транспортними засобами. Кожен Triton міг ухвалювати рішення, водночас координуючись з іншими, подібно до того, як це можуть робити самокеровані автомобілі.

Дослідження SLAM і картографування: Робота з інтеграції сенсора глибини надала Пенгу додаткові дані для його досліджень одночасної локалізації та побудови карти. Наявність кількох роботів із координованими сенсорними можливостями дала змогу проводити більш комплексні експерименти з картографування.

Особливо цінною нашу співпрацю робило те, що це не було просто моєю допомогою його дослідженням — це було справжнє партнерство. Розуміння Пенгом теоретичних аспектів автономних транспортних засобів допомагало спрямовувати мої практичні реалізації. Його зворотний зв’язок і вимоги спонукали мене робити системи надійнішими й функціональнішими.

Ми проводили багато годин разом у лабораторії, налагоджуючи сценарії, обговорюючи різні стратегії керування та досліджуючи, чого могла досягти платформа Triton. Пенг став для мене і колегою, і другом, а робота з ним навчила мене багато чому про те, як насправді працюють академічні дослідження.

Системи, які я створив, стали корисною частиною дисертаційної роботи Пенга. Бачити, як мої практичні інженерні внески підтримують дослідження технологій автономних транспортних засобів, було справді надихаюче. Це ще більше зміцнило мій інтерес до того, як надійна інженерія та дослідження можуть працювати разом, створюючи корисні результати.

Навіть після того, як я залишив лабораторію, ми з Пенгом підтримували зв’язок. Усвідомлення того, що моя робота й надалі сприяла важливим дослідженням навіть після мого відходу, було надзвичайно приємним.

Перспектива: епоха розробки до LLM

Варто зазначити, що вся ця робота була виконана в дорозі до епохи LLM у розробці програмного забезпечення. Усе це відбувалося між 2020 та 2021 роками (переважно у 2021-му), до появи ChatGPT, Claude, Perplexity чи інструментів розробки на основі ШІ, таких як Cursor IDE.

Кожен рядок коду писався з нуля, кожен алгоритм досліджувався за академічними статтями й підручниками, а кожен сеанс налагодження передбачав традиційні методи, як-от виведення через print, відлагоджувачі та методичне тестування. Коли я застрягав на проблемі перетворення координат або налаштування ПІД-регулятора, я не міг просто запитати в асистента ШІ, щоб той пояснив концепцію або допоміг знайти помилку.

Це зробило процес розробки значно складнішим, але й більш навчальним. Мені доводилося:

Досліджувати все вручну: Розуміння теорії ПІД-керування означало читання підручників і академічних статей. Розбирання перетворень координат вимагало проробляти математику вручну. Кожну концепцію треба було повністю зрозуміти до реалізації.

Налагоджувати без допомоги ШІ: Коли роботи рухалися в неочікуваних напрямках або коливалися навколо цілей, мені доводилося методично простежувати логіку, додавати відладні виводи та тестувати гіпотези одну за одною. Не було ШІ, який міг би підказати можливі проблеми чи допомогти інтерпретувати шаблони помилок.

Вчитися з перших принципів: Без можливості швидко запитати: “як реалізувати багатопроцесну обробку в Python для робототехніки?” — мені доводилося глибоко розуміти базові концепції. Це змусило мене побудувати міцний фундамент у паралельному програмуванні, системах керування та комп’ютерному зорі.

Документація була критично важливою: Оскільки я не міг покладатися на ШІ, щоб пізніше пояснив код, мені доводилося писати надзвичайно чітку документацію та коментарі. Ця дисципліна виявилася неоціненною під час передавання знань іншим.

Озираючись назад, я розумію, що сучасні інструменти ШІ прискорили б багато аспектів розробки, але робота без них змусила мене розвинути глибші навички розв’язання проблем і набагато повніше зрозуміти базові системи. Цікаво уявити, наскільки інакшим міг би бути цей проєкт, якби сучасні інструменти розробки були доступні тоді.

Важке рішення піти

Як би сильно я не любив працювати в HCR Lab, наприкінці 2021 року я зіткнувся з важким рішенням, яке постає перед багатьма студентами: як збалансувати кілька можливостей і обов’язків. Я одночасно працював повний робочий день як програмний інженер в eBay, завершував навчання на спеціальності комп’ютерних наук у Mines і робив внесок у дослідження в HCR Lab.

Можливість в eBay була значущою; це була моя перша велика роль у програмній інженерії, вона надала неоціненний досвід у галузі та забезпечила мені стабільний дохід. Однак намагатися одночасно працювати повний день, завершувати навчання й робити вагомий внесок у дослідження було просто неможливо. Чимось довелося поступитися.

Коли я звернувся до д-ра Чжана з пропозицією, що, можливо, варто зменшити навчальне навантаження, щоб більше зосередитися на роботі в лабораторії, він рішуче не порадив цього робити. Його міркування були слушними: завершення навчання мало бути пріоритетом, а досвід роботи в eBay був би цінним для мого кар’єрного розвитку. Він вважав, що відмова від курсів заради досліджень, хоч і здавалася привабливою, може бути не найкращим довгостроковим рішенням.

Тож у вересні 2021 року, після приблизно 8 місяців інтенсивної роботи в лабораторії, я прийняв важке рішення відійти від ролі асистента-дослідника, щоб зосередитися на завершенні навчання та роботі в eBay. Це було одне з найважчих професійних рішень, які мені доводилося ухвалювати на той час.

Навіть офіційно залишивши лабораторію, я продовжував надавати підтримку, коли комусь була потрібна допомога із системами, які я створив. За потреби я оновлював документацію, відповідав на запитання щодо налагодження та допомагав віддалено розв’язувати проблеми. Зв’язки, які я встановив, і моя зацікавленість у успіху проєкту не зникли лише тому, що я більше не був офіційно частиною команди.

Роздуми та погляд назад

Тепер, у 2025 році, через чотири роки, я ловлю себе на тому, що з подвійними почуттями згадую той час. Мій кар’єрний шлях завів мене глибоко у веброзробку та інженерію ШІ/ML — сфери, які були неймовірно цінними й дали величезні можливості для зростання та впливу.

І все ж є частина мене, яка запитує: “а що як.” Робототехніка була і, чесно кажучи, досі залишається моєю справжньою пристрастю. Є щось особливе в роботі з фізичними системами, коли бачиш, як твій код перетворюється на реальний рух і поведінку, чого веброзробка і навіть робота зі ШІ не можуть повністю відтворити.

Іноді я замислююся, що сталося б, якби я обрав інший шлях. Що якби я знайшов спосіб залишитися в дослідженнях з робототехніки? Що якби я вступив до аспірантури одразу після завершення бакалаврату? Що якби я вирішив віддати пріоритет роботі в лабораторії, а не досвіду в індустрії?

Але я також усвідомлюю, що кожен шлях має свої компроміси. Навички, які я розвинув у веброзробці та ШІ, були неймовірно цінними. Досвід у галузі навчив мене програмної інженерії в масштабі, дизайну користувацького досвіду та практичним труднощам створення продуктів, якими користуються мільйони людей. Усе це зробило мене кращим інженером загалом.

Робота, яку я виконав у HCR Lab, і досі впливає на те, як я сьогодні підходжу до розв’язання проблем. Системне мислення, потрібне для ПІД-систем керування, проявляється в тому, як я проєктую петлі зворотного зв’язку в програмних системах. Навички документації та збереження знань, які я розвинув, були неоціненними в кожній наступній ролі. Досвід наставництва та навчання сформував те, як я працюю з молодшими розробниками й сприяю обміну знаннями в команді.

Найважливіше те, що цей досвід навчив мене: я процвітаю, коли працюю над складними технічними проблемами, що мають реальний вплив. Чи то оптимізація алгоритмів руху роботів, чи створення систем ШІ, які допомагають користувачам досягати своїх цілей — задоволення приходить від розв’язання складних проблем, які мають значення.

Тривалий вплив

Озираючись на досвід у HCR Lab, я вражений тим, скільки я встиг зробити за відносно короткий час. Системи, які я створив, фундаментально змінили роботу платформи Triton, і багато з цих покращень досі використовуються. Репозиторій документації, який я створив, став базою знань для всього проєкту. Наставницькі стосунки, які я сформував, мали тривалий вплив на людей, з якими я працював.

Але, можливо, найважливіше те, що цей досвід показав мені, на що я здатний, коли працюю над проблемами, які мене по-справжньому захоплюють. За ці вісім місяців я:

• Покращив систему керування рухом робота, яка обмежувала платформу
• Створив систему координації кількох роботів з нуля
• Інтегрував можливості комп’ютерного зору та злиття сенсорних даних
• Створив комплексну систему документації та управління знаннями
• Наставляв кількох людей і допомагав із передачею знань
• Підтримував дослідження на рівні PhD в автономних транспортних засобах

Однак це було не лише про технічні досягнення, хоч вони й були для мене значущими. Йшлося про те, щоб навчитися, що з наполегливістю та системним мисленням можна робити корисний внесок навіть будучи студентом бакалаврату.

Майбутнє і робототехніка

Хоча моя кар’єра повела мене в інших напрямках, моя пристрасть до робототехніки не зменшилася. Я й досі стежу за розвитком у цій галузі, мене надихають досягнення в навчанні роботів та автономних системах, і я час від часу працюю над особистими робототехнічними проєктами у вільний час.

Хто знає, що готує майбутнє? Навички, які я розвиваю в ШІ та машинному навчанні, дедалі більше актуальні для робототехніки. Досвід роботи в індустрії навчив мене, як створювати надійні, масштабовані системи. Можливо, настане майбутнє, у якому ці різні нитки мого досвіду несподівано зійдуться разом.

Наразі я вдячний за час, проведений у лабораторії HCR, і за досвід, який вона мені дала. Це був формувальний період, що сформував і мої технічні навички, і моє розуміння того, яка робота приносить мені найбільше задоволення. Хоча іноді я за цим сумую, я знаю, що уроки, які я засвоїв, і підходи, які я розробив, і далі впливають на все, що я роблю.

Роботи Triton досі там, досі служать дослідникам, досі дають змогу виконувати важливу роботу. І це справді чудово.