Моя глава досліджень у робототехніці

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

Передумови

Я розпочав своє навчання на бакалавраті в Школі гірничої справи Колорадо в осінньому семестрі 2018 року. Моя спеціальність була комп’ютерні науки з акцентом на робототехніку та інтелектуальні системи. І я закінчив навчання навесні 2022 року.

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

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

Клас Людиноцентричної Робототехніки (CSCI473)

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

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. Ми також використовували Stingray симуляційне середовище Gazebo, надане курсом. Stingray складався з моделі Triton і фізичної логіки. Нам також надали лабіринт, за яким повинен слідувати робот. Загалом, середовище виглядало так:

Я ніколи не публікував своє рішення на GitHub або в Інтернеті, оскільки воно було не дуже хорошим і сильно недосконалим. Також, щоб запустити код у правильному середовищі, досить складно і дратує. Проте, у мене є демонстраційне відео, яке я подав до класу, що показує моє рішення. Ви можете переглянути його тут:

Для повного опису проекту перегляньте csci473-p2.pdf

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

Для третього проекту опис проекту був таким:

У цьому проекті студенти реалізують кілька представлень на основі скелетів (Доставлення 1) та використовують методи опорних векторів (SVM) (Доставлення 2) для класифікації людської поведінки, використовуючи публічний набір даних про активність, зібраний з сенсора Kinect V1. Крім того, студенти повинні написати звіт, дотримуючись формату стандартних конференцій з робототехніки IEEE, використовуючи LATEX у Доставленні 3.

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

Висновок CSCI473

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

Польова сесія з комп’ютерних наук (літо 2020)

Під час літа 2020 року, між завершенням CSCI473 і приєднанням до HCR Lab, я проходив курс CSCI370 або “Розширене програмне забезпечення” в рамках моєї програми бакалаврату з комп’ютерних наук у Школі гірничої справи Колорадо. CSCI370 - це курс, який змушує студентів проектувати, реалізовувати та документувати рішення, пов’язані з програмним забезпеченням, для компанії. Це дозволяє студентам застосовувати свої знання з курсу до реальних проблем комп’ютерних наук. Ви можете дізнатися більше про курс тут.

На курсі ви можете вирішити, над яким проектом/компанією ви будете працювати. Курс надавав PDF-файли, що детально описують кожен проект і компанію. Врешті-решт я вирішив працювати над проектом, опублікованим компанією Lunar Outpost, під назвою “Виявлення ковзання коліс у реальному часі та виправлення помилок для покращеної навігації на Місяці”. Оскільки назва довга, давайте дамо проекту псевдонім “Виявлення ковзання коліс”.

Проблема

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

Команда

Цей проект не був простим, тому його потрібно було виконувати в команді. Команда складалася з п’яти студентів Школи гірничої справи Колорадо:

Цей проект не був простим, тому його потрібно було виконувати в команді. Ця команда складалася з Мехмета Йілмаза (мене), Кейна Бруса, Брейдона О’Каллагана, Ліама Вільямса та Кевіна Гранта.

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

Виклики

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

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

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

Висновок

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

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

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

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

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

Мій проєкт

Протягом мого часу в лабораторії HCR я в основному зосереджувався на проєкті Triton. Проєкт Triton — це мобільний робот, розроблений Лабораторією Людської Центрованої Робототехніки у Колорадському університеті. Це трикутний робот з омні-колесами, що працює на базі NVIDIA Jetson Nano.

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

• NVIDIA Jetson Nano
• Плата-носій NVIDIA Seed Studio A205
• Arduino Mega
• 64 ГБ Micro SD карта
• Індивідуально надрукований на 3D-принтері корпус
• 3 механум-колеса
• 1 AR акумулятор
• Індивідуальні схеми для оптимізованого розподілу потужності та проводки
• Камера 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 спочатку повертався, змінюючи свій альфа, поки не вказував на цільову точку в межах певного допустимого відхилення. Потім він мчав вперед, і після того, як його тета відхилилася від цілі на певну величину, він зупинявся і знову починав повертатися, поки альфа не потрапляла в цей прийнятний діапазон для цільової мети. Потім він знову мчить і продовжує це робити, поки не досягне точки. Також, коли він наближався до цільової точки, швидкість повороту та спринту ставала значно повільнішою, щоб не перевищити ціль. Це призвело до того, що Triton мав неприродний рух, витрачав багато часу, щоб дістатися до цільової точки, і вимагав так багато простору, просто щоб дістатися до конкретної цільової точки. Отже, з усіма цими проблемами, і враховуючи, наскільки важливою була ця функція для розвитку проєкту Triton, коли я почав працювати в лабораторії HCR, моїм першим завданням було розробити більш ефективні рішення, які дозволили б Triton краще орієнтуватися до цільової точки.

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

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

Метод 1: Контролер Відстань-Тета

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

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

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

Це призвело до того, що 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, який демонструє всіх Tritons в дії з новими методами.

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

Виклики в розробці та налагодженні

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

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

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

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

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

Система управління Multi-Triton

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

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

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

Дизайн архітектури Multi-Robot

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

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

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

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

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

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

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

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

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

Ось як виглядала установка лабораторії з кількома Tritons, що працюють одночасно:

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

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

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

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

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

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

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

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

3. Уникнення зіткнень: Системи глибини в реальному часі дозволять роботам виявляти та уникати один одного, навіть якщо центральна система управління має затримки в комунікації.

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

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

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

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

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

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

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

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

Виклики продуктивності: Зробити так, щоб вся ця обробка працювала в реальному часі разом з контрольними петлями робота, виявилося складним завданням. Я експериментував з підходами до оптимізації, щоб запустити алгоритми на частоті близько 10-15 Гц, не перевантажуючи обчислювальні можливості Jetson Nano.

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

Ось відео, на якому я тестую алгоритми комп’ютерного зору:

Ось як виглядав вигляд сенсора глибини під час моїх експериментів:

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

Документація та збереження знань

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

• Різними обліковими записами Google Drive, що належать різним студентам, які закінчили навчання
• Старими електронними листами, похованими в поштових скриньках
• Випадковими папками Dropbox
• Кількома репозиторіями GitHub
• Репозиторіями GitLab з непослідовною організацією
• Ручними записами, які могли інтерпретувати лише конкретні люди

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

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

Централізована документація включала:

• Посібники зі складання: Покрокові інструкції для складання Тритонів з нуля
• Налаштування програмного забезпечення: Повні посібники для налаштування середовища розробки
• Документація коду: Добре прокоментований код з чіткими поясненнями
• Технічні специфікації: Докладні списки частин, схеми з’єднань та проекти друкованих плат
• Посібники з усунення несправностей: Загальні проблеми та їх рішення
• Відеоуроки: Я створив та завантажив навчальні відео на YouTube, включаючи детальні посібники з калібрування Optitrack:

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

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

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

Менторство та передача знань

Одним з найприємніших аспектів мого часу в лабораторії HCR була можливість наставляти інших і ділитися знаннями, які я здобув. Коли моя робота просувалася, і я ставав більш досвідченим у системах Тритон, я взяв на себе все більшу відповідальність за навчання нових членів команди.

Наставництво наступників лабораторії

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

Я витратив тижні, працюючи з ними, проходячи через:

• Математичні основи систем керування PID
• Архітектуру багатопроцесорності для координації кількох роботів
• Інтеграцію сенсора глибини та алгоритми комп’ютерного зору
• Систему документації та як її підтримувати
• Техніки налагодження та загальні режими відмови

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

Програма наставництва для старшокласників

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

Я розробив всебічну навчальну програму, яка охоплювала:

Основи комп’ютерних наук:

• Концепції програмування з використанням Python як основної мови
• Вступ до об’єктно-орієнтованого програмування
• Розуміння алгоритмів та структур даних

Концепції робототехніки:

• Як працюють сенсори та як з ними взаємодіяти
• Керування актуаторами та системи двигунів
• Основи автономних систем та зворотного зв’язку

ROS (Операційна система роботів):

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

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

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

Те, що робило це наставництво особливо особливим, - це спостереження за її прогресом від практично нульових знань про програмування до внесення значущого коду в активний дослідницький проект. Вона пройшла шлях від запитання “Що таке змінна?” до самостійного налагодження проблем з комунікацією ROS та написання власних реалізацій сервісів.

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

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

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

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

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

Мої внески допомогли дослідженню Пінга в кількох сферах:

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

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

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

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

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

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

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

Перспектива: Ера розвитку до LLM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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