Дослідження робототехніки лабораторії HCR

Цей пост розповідає про мою подорож у світі робототехніки, починаючи з відкриття моєї пристрасті до робототехніки у FRC під час high school у 2015 році до мого часу як наукового асистента в Colorado School of Mines’s Human Centered Robotics (HCR) Lab з лютий 2021 до вересень 2021. Зауважте, що з кінця 2022, HCR Lab переїхала з Colorado School of Mines до University of Massachusetts Amherst, разом зі своїм сайтом з hcr.mines.edu на hcr.cs.umass.edu.

Фон

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

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

У Mines я отримав можливість працювати в лабораторії Human Centered Robotics (HCR) під керівництвом Dr Hao Zhang. Я вперше зустрів доктора Чжана навесні 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’s tutorial та e-manual’s tutorial.

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

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

🧩 Підкріплювальне навчання для слідування робота за стіною

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

У цьому проєкті студенти розроблять та впровадять алгоритми підкріплювального навчання, щоб навчити автономного мобільного робота слідувати за стіною та уникати зіткнень з перешкодами. Студенти будуть використовувати симуляцію Gazebo у ROS Melodic для моделювання всебічного мобільного робота під назвою Triton, використовуючи надану карту середовища. На роботі буде використовуватись лазерний дальномір для здійснення сенсорики та навчання, при цьому робот керується командами керма та швидкості. Студенти повинні програмувати цей проєкт на C++ або Python у ROS Melodic на Ubuntu 18.04 LTS (тобто в тому ж середовищі розробки, що й у Проєкті 1). Крім того, студенти повинні написати звіт у форматі стандартних конференцій IEEE з робототехніки, використовуючи LATEX.

Для алгоритму підкріплювального навчання нам було вказано використовувати Q-Learning. Ми також використали симуляційне середовище Gazebo Stingray, надане курсом. Stingray складався з моделі Triton та фізичної логіки. Нам також надали лабіринт, яким робот мав слідувати. У підсумку, середовище виглядало так:

Для повного опису проєкту перегляньте csci473-p2.pdf. Я ніколи не публікував своє рішення на GitHub чи в інтернеті, оскільки воно було не дуже хорошим і сильно недосконалим. Крім того, запуск коду в правильному середовищі досить складний і дратівливий. Однак у мене є демонстраційне відео, яке я подав у клас, показуючи моє рішення. Ви можете переглянути його тут:

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

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

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

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

Висновок CSCI473

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

Сесія CS Field (літо 2020)

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

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

Проблема

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

Команда

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

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

Для проєкту нам потрібно було знати 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, моєї CS Field Session у літку 2020 року та осіннього семестру 2020 року, я вирішив зайнятися дослідженнями в галузі робототехніки. Я отримав такі чудові враження від CSCI473 та CS Field Session, що захотів проводити дослідження в лабораторії HCR. Оскільки я зустрів доктора Чжана минулого року, я вирішив написати йому електронного листа і запитати про можливі можливості в лабораторії у січні 2021 року. Протягом приблизно 2 тижнів доктор Чжанг виявив інтерес, представив мені варіанти досліджень і запропонував роль у лабораторії. Я розпочав роботу в лабораторії у лютому 2021 року.

Відео вступу

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

Мій проєкт

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

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

• NVIDIA Jetson Nano
• Плата‑носій Seed Studio A205 від NVIDIA
• Arduino Mega
• 64 ГБ Micro SD карта
• Індивідуальний 3D‑друкований корпус
• 3 колеса mecanum
• 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 утворювали унікальний трикутний шаблон, який система могла відстежувати як жорстке тіло.

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

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

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

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

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

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

Метод 1: Контролер відстані‑тети

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

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

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

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

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

This approach treated the robot like a 2D plotter, with independent control of X and Y movement:

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

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

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

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

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

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

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

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

• Coordinate System Transformations: Одним із найскладніших аспектів було правильне виконання перетворень координат. Система Optitrack надавала дані у власній системі координат, у робота була локальна система координат, і мені потрібно було точно конвертувати їх між собою. Перші реалізації змушували роботів рухатися в неправильному напрямку через помилкові обчислення матриці обертання.
• Real-World vs. Ideal Behavior: Найбільшим викликом було врахування реальних факторів, які не згадуються в підручниках з теорії керування. Колеса робота мали різні характеристики тертя, мотори реагували не ідентично, і завжди була певна затримка у ланцюжку передачі даних від Optitrack до програмного забезпечення керування та Arduino робота. Я провів кілька тижнів, налаштовуючи пропорційні підсилення та додаючи фільтри мертвого діапазону, щоб врахувати ці фізичні реальності.
• Oscillation and Stability Issues: Перші реалізації страждали від проблем осциляції, коли роботи перевищували свої цілі та коливалися вперед-назад. Це навчило мене важливості диференціальних членів у PID‑контролерах та необхідності правильного налаштування підсилень. Зрештою я зупинився на переважно пропорційному керуванні з ретельно налаштованими підсиленнями, а не на повному PID, оскільки вбудоване демпфування системи достатньо для більшості застосувань.
• Multi-Robot Interference: Коли кілька роботів працювали одночасно, я виявив несподівані патерни взаємних завад. Роботи іноді «боролися» за один і той самий простір або створювали ситуації блокування, коли вони безкінечно блокували один одного. Це змусило мене впровадити механізми координації та алгоритми уникнення зіткнень.

Система керування Multi‑Triton

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

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

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

Проект архітектури мульти‑роботів

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

• Main Controller Process: Служив центральним координатором, обробляючи взаємодії користувацького інтерфейсу, планування траєкторій та високорівневу координацію між роботами. Він підтримував глобальний стан і розподіляв команди до окремих процесів роботів.
• Individual Robot Processes: Кожен Triton мав власний процес Python, який обробляв:
  • Розрахунки PID‑керування в реальному часі приблизно 50 Гц
  • Комунікацію з апаратурою робота (Arduino/Jetson)
  • Виконання локальної траєкторії та уникнення перешкод
  • Звіт про стан, що повертається до головного контролера
• Shared Memory Communication: Я використав multiprocessing.shared_memory та об’єкти Queue у Python для забезпечення ефективної комунікації між процесами. Це дозволило здійснювати координацію в реальному часі без накладних витрат мережевого зв’язку.
• Synchronization Mechanisms: Щоб запобігти конфліктам, коли кілька роботів потребували координації (наприклад, уникнення зіткнень), я впровадив семафори та блокування, які дозволяли роботам запитувати виключний доступ до певних ділянок робочого простору.

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

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

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

Ось як виглядав лабораторний стенд з одночасно працюючими кількома Triton’ами:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наставництво та передача знань

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

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

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

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

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

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

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

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

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

Основи інформатики:

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

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

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

ROS (Robot Operating System):

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

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

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

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

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

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

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

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

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

My contributions helped Peng’s research in several areas:

Дослідження управління перехрестями: With the improved PID controllers and multi-robot coordination, Peng could simulate intersection scenarios where multiple “vehicles” (Tritons) needed to coordinate their movements. The better timing and positioning helped make these studies more feasible.

Комунікація між транспортними засобами: The multi-processing framework I developed allowed Peng to implement and test communication protocols between simulated vehicles. Each Triton could make decisions while still coordinating with others, similar to how self-driving cars might need to operate.

Дослідження SLAM та картографії: The depth sensor integration work provided Peng with additional data for his simultaneous localization and mapping research. Having multiple robots with coordinated sensing capabilities allowed for more comprehensive mapping experiments.

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

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

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

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

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

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

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

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

Досліджувати все вручну: Understanding PID control theory meant reading textbooks and academic papers. Figuring out coordinate transformations required working through the math by hand. Every concept had to be fully understood before implementation.

Відлагоджувати без допомоги AI: When robots moved in unexpected directions or oscillated around targets, I had to methodically trace through the logic, add debug outputs, and test hypotheses one by one. There was no AI to suggest potential issues or help interpret error patterns.

Вчитися з перших принципів: Without the ability to quickly ask “how do I implement multi-processing in Python for robotics?” I had to understand the underlying concepts deeply. This forced me to build a solid foundation in concurrent programming, control systems, and computer vision.

Документація була критичною: Since I couldn’t rely on AI to explain code later, I had to write extremely clear documentation and comments. This discipline proved invaluable when transferring knowledge to others.

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

Складне рішення залишити

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But perhaps most significantly, the experience showed me what I’m capable of when working on problems I’m truly passionate about. In those eight months, I:

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

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

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

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

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

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

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